La mayoría de los equipos de ingeniería chocan con el mismo muro con la generación aumentada por recuperación (RAG). Siguen el manual de los tutoriales: dividen los documentos en fragmentos (chunks) fijos de quinientos doce o mil veinticuatro tokens, los pasan por un único modelo de embedding y realizan una búsqueda top-k en una base de datos vectorial. En una presentación, esto parece sólido. En producción, se desmorona.
Los fragmentos fijos no tienen en cuenta el contenido. Dividirán sin problemas un contrato legal a mitad de una frase, dejando cláusulas de responsabilidad colgando entre dos piezas de texto no relacionadas. Volcarán la descripción completa de un endpoint de una API en un fragmento inflado tan grande que el parámetro específico por el que preguntó el usuario se ahogará en el ruido. Y cuando la recuperación es lenta, cada milisegundo de latencia se traslada directamente a la experiencia del usuario. Aprendimos esto por las malas. Entonces, desmantelamos nuestra capa de recuperación y la reconstruimos. Nuestro recall a diez saltó del setenta y ocho por ciento al noventa y cinco por ciento. La latencia no aumentó. Se desplomó.
El problema del RAG de copiar y pegar
El stack de RAG estándar se ha convertido en una especie de configuración predeterminada. Fragmentos pequeños, un modelo de embedding, búsqueda vectorial y listo. Ese enfoque sobrevive a una demostración porque las demos utilizan preguntas limpias y documentos ordenados. Los datos de producción nunca son ordenados.
Los documentos legales tienen una estructura jerárquica. Las secciones contienen subsecciones. Las subsecciones contienen cláusulas. Si los atraviesas con un contador de tokens tosco, destruyes las relaciones mismas que el modelo necesita para razonar. La documentación de la API también tiene estructura, pero es diferente. La firma de una función, sus parámetros, su valor de retorno y un ejemplo de uso forman una unidad lógica. Si fuerzas eso en una ventana de tokens fija, o bien truncas el ejemplo o rellenas el fragmento con funciones no relacionadas. Los tickets de soporte son desordenados, conversacionales y están llenos de cambios repentinos de tema. Las wikis son extensas y tienen referencias cruzadas. Una sola estrategia de fragmentación no puede servir para todo esto y, sin embargo, los equipos implementan rutinariamente exactamente eso. Nosotros dejamos de fingir que era posible.
Fragmentación estratégica: adaptar el método al material
Pasamos a una fragmentación consciente del contenido. Para documentos legales, utilizamos una fragmentación recursiva que respeta la jerarquía del documento. Mantiene las cláusulas intactas y preserva las relaciones padre-hijo entre las secciones. Para la documentación de la API, creamos una fragmentación consciente de las funciones que trata cada función o endpoint como un límite. Si la descripción de un parámetro es larga, el fragmento se expande alrededor de esa función, no alrededor de un límite de tokens. Para los tickets de soporte, utilizamos una fragmentación semántica que detecta los límites naturales de los temas. Cuando un cliente cambia repentinamente de una queja de facturación a un error técnico, la división ocurre en ese giro. Para las wikis y las bases de conocimiento no estructuradas, utilizamos una fragmentación agéntica en la que un LLM ligero evalúa el texto y decide dónde debe caer un límite significativo. Esto es más lento de configurar que una división por caracteres, pero es la diferencia entre una recuperación que funciona y una que adivina.
Recuperación híbrida: por qué la búsqueda vectorial por sí sola no es suficiente
La búsqueda vectorial entiende el significado, pero puede perder las coincidencias exactas. Si un usuario pega un código de error como ERR_CONNECTION_RESET_0x5F3, la similitud semántica podría posicionarlo por debajo de párrafos que simplemente discuten errores de red en general. BM25, por otro lado, encuentra cadenas exactas pero pierde la relación conceptual. Necesitas ambos.
Ejecutamos la búsqueda vectorial y BM25 en paralelo. Luego combinamos los resultados con Reciprocal Rank Fusion, o RRF, que normaliza las puntuaciones de los dos espacios de búsqueda diferentes sin forzarlas a la misma escala. Después de la fusión, enviamos los mejores candidatos a través de un re-clasificador (reranker) de cross-encoder. Esto añade una pequeña cantidad de latencia, pero la ganancia en precisión es significativa. El reranker lee la consulta y cada candidato juntos y asigna una puntuación de relevancia que es mucho más precisa que la similitud de coseno del embedding inicial. En la práctica, esta combinación captura códigos de error exactos que la búsqueda vectorial pura pasa por alto, al tiempo que hace emerger pasos de resolución de problemas conceptualmente relacionados que la búsqueda por palabras clave ignoraría.
Expansión de consultas: corregir la entrada del usuario antes de que llegue al índice
Los usuarios no escriben consultas de búsqueda perfectas. Hacen preguntas de múltiples pasos (multi-hop) como "¿por qué falló mi último despliegue y cómo lo revierto?", lo que requiere encontrar dos cuerpos de conocimiento distintos y conectarlos. O hacen preguntas vagas que se relacionan mal con el índice.
Transformamos las consultas antes de realizar la búsqueda. Una pregunta de múltiples saltos se desglosa en subpreguntas. Una intención vaga se expande en múltiples consultas de búsqueda específicas. Descubrimos que expandir una sola consulta de usuario en cinco consultas de búsqueda distintas puede elevar el recall del setenta y ocho por ciento al noventa y seis por ciento. No se trata de aplicar un prompting más intenso al LLM. Se trata de darle al sistema de recuperación más oportunidades de encontrar el contexto adecuado. Cada consulta generada captura un ángulo o terminología diferente, y los resultados combinados ofrecen una visión completa.
Optimización Bayesiana: Deja de adivinar
Una vez que cuentas con múltiples estrategias de fragmentación (chunking), recuperación híbrida y expansión de consultas, te enfrentas a un nuevo problema. Hay demasiados parámetros que ajustar. El tamaño del fragmento (chunk size), el porcentaje de solapamiento, el peso vectorial frente al peso de BM25, los umbrales de reordenación (reranking) y los valores top-k interactúan todos de forma no lineal. El ajuste manual se convierte en un juego de adivinanzas.
Dejamos de adivinar. Tratamos el