Un mapa de campos de RAG: de los principios básicos a los fallos en producción
Dos pipelines, tres pasos y una lista de fallos con nombre: cómo funciona la generación mejorada por recuperación de información, dónde falla y qué soluciones abordan cada problema.
Fuentes: The Complete RAG Roadmap: From “What Is It?” to Production
La generación mejorada por recuperación de información es fácil de mostrar, pero difícil de hacer bien. Un prototipo funcional se puede crear en cuarenta líneas y en una tarde. Luego viene la ardua tarea de averiguar por qué da respuestas incorrectas tres veces de cada diez, o por qué un chatbot cita con confianza una cláusula de contrato que nunca se escribió. Esta guía abarca ambos aspectos: comienza sin ningún jerga y termina con las técnicas que diferencian una demostración de fin de semana de un sistema en el que la gente confía para manejar dinero.
La idea en términos sencillos
Imagínese un modelo de lenguaje como un graduado muy culto que nunca ha visto sus archivos. Ha absorbido gran parte de Internet público, pero nada de sus acuerdos de alquiler, políticas de recursos humanos, catálogo de productos o la presentación del consejo de administración del último trimestre.
RAG convierte un examen de libro cerrado en uno de libro abierto. En lugar de confiar en que el modelo haya memorizado sus datos, el sistema primero busca las páginas relevantes, se las entrega y le indica al modelo que responda únicamente a partir de ellas. El nombre del método enumera tres pasos:
- Recuperar: buscar en sus documentos y extraer los pocos fragmentos importantes.
- Mejorar: incluir esos fragmentos en la instrucción junto a la pregunta.
- Generar: hacer que el modelo escriba una respuesta basada en lo que le fue proporcionado.
Esa es toda la idea. Cada mejora posterior, desde herramientas de reclasificación hasta gráficos, existe únicamente para hacer que uno de esos tres pasos sea menos deficiente.
Para los lectores no técnicos, la ventaja radica en poder explicar qué está construyendo un equipo de ingeniería, por qué falla de la manera en que lo hace y qué preguntas hacer durante una demostración del proveedor. Para los ingenieros, se trata de los mecanismos, los compromisos y los modos de fallo, lo que implica preguntarse por qué la similitud coseno es un sustituto extraño para la relevancia, por qué los bloques de 512 tokens arruinan las tablas y por qué un conjunto de evaluación tiene más importancia que la elección del modelo. Nadie considera que “simplemente use una base de datos vectorial” sea una respuesta completa.
Dos pipelines, no uno
Un punto estructural confunde a casi todos. Un sistema RAG no es un único pipeline; son dos pipelines que nunca se ejecutan al mismo tiempo.
La vía A está indexando. Se realiza por adelantado, generalmente como tarea por lotes. Los documentos se dividen en partes, cada parte se convierte en una lista de números que capturan su significado, y esos números se incluyen en un índice buscable. Es el proceso más lento, y es donde se determina aproximadamente el 80% de la calidad de la respuesta final.
La vía B está realizando consultas. Funciona en tiempo real cada vez que un usuario hace una pregunta. La pregunta se convierte en números mediante exactamente el mismo método, se encuentran las partes almacenadas más cercanas, se incluyen en una solicitud y se obtiene una respuesta.
Si los dos enfoques difieren en cuanto a la codificación, nada funciona, algo similar a ordenar documentos alfabéticamente y luego buscar por color. La gente tiende a centrarse en el Enfoque B, es decir, en la instrucción, el modelo y la temperatura, mientras que la mayor parte de los problemas radica en el Enfoque A. El indexado se ejecuta una vez, las consultas se realizan cada vez, y la mayoría de los errores se ocultan en el espacio entre ambos.
Las etapas, desde lo básico hasta la producción
Fundamentos
El primer tema trata de dónde proviene realmente la alucinación, y no se debe a que el modelo sea tonto. Las ideas relacionadas incluyen qué es una ventana de contexto, por qué no se puede pegar toda una base de datos en una sola y qué significa un límite de conocimiento. Luego está la pregunta que la gente entiende mal: RAG, el ajuste fino y una ventana de contexto más grande son tres herramientas separadas para tres problemas distintos, pero constantemente se recomienda usarlas para las tareas de las demás.
Una compañía de seguros cuyas cláusulas de póliza cambian cada trimestre demuestra la diferencia. Ajustarlas significaría volver a entrenar el modelo cada trimestre. RAG implica actualizar una carpeta.
Ingestión y fragmentación
Obtener los documentos ya es un desafío en sí mismo: PDFs que en realidad son imágenes escaneadas, tablas, encabezados, pies de página y un apéndice de 40 páginas que nadie necesita. Luego está la fragmentación, la decisión sobre cómo dividir un documento. Parece trivial, pero no lo es. Si se dividen en partes demasiado pequeñas, un fragmento podría decir “el depósito será reembolsable” sin indicar las condiciones. Si se dividen en partes demasiado grandes, el modelo se saturará de ruido. Los métodos principales son la división de tamaño fijo, la que tiene en cuenta las oraciones y la división recursiva, además de un truco de superposición que evita que las oraciones se corten bruscamente.
Tomemos un contrato de arrendamiento de 60 páginas cuya cláusula de penalización depende de una definición dada 40 páginas antes. Los límites de fragmentación determinan si esa conexión se mantiene.
Embebidos y búsqueda vectorial
Esta etapa parece mágica, pero no lo es. El texto se convierte en una lista de números, organizados de tal manera que una frase sobre cancelar un pedido queda cerca de una sobre devolver una compra y lejos de una sobre pedir más stock. Las ideas relacionadas incluyen las dimensiones, la similitud coseno y el hecho de que la cercanía en el espacio vectorial no garantiza una respuesta.
A continuación viene el almacenamiento: qué hace realmente una base de datos vectorial, por qué la búsqueda por fuerza bruta falla a gran escala y qué sacrifica la búsqueda aproximada de vecinos más cercanos en pos de la velocidad.
El bucle de recuperación
Aquí se ensamblan las piezas. Elegir el valor top-k, es decir, la cantidad de fragmentos a obtener, forma parte de este proceso, y más no significa mejor calidad. El filtrado de metadatos permite que la búsqueda abarque únicamente documentos del año 2024 o solo la región de Mumbai. También es importante la forma en que se organiza el contexto recuperado, ya que el orden en que se presenta afecta la respuesta.
A continuación vienen los fundamentos y las citaciones. El modelo debe referirse a algo como la Sección 4.2 y no limitarse a mostrar seguridad excesiva. Igualmente crucial es que indique que la respuesta no se encuentra en los documentos, probablemente la característica más subestimada de cualquier sistema RAG.
Evaluación
Casi todos omiten esta etapa, lo que explica por qué casi todos entregan RAG defectuoso. Un problema que no se mide no puede corregirse. La calidad se divide en dos preguntas: ¿se recuperó el material adecuado? ¿El modelo se mantuvo fiel a él? Cada uno de estos aspectos falla por sí solo y requiere su propia corrección. La herramienta incluye un conjunto ideal de preguntas de prueba tomadas de usuarios reales, la recuperación se evalúa en términos de precisión y recuperación, la generación se evalúa en cuanto a fidelidad y relevancia con respecto a la pregunta, y un LLM actúa como juez, observando dónde falla ese enfoque.
Un sistema obtuvo un 90% en recuperación y un 55% en fidelidad. Su búsqueda fue correcta, pero sus respuestas seguían siendo erróneas.
Mejoras, cada una relacionada con un fallo
Mejor recuperación
La búsqueda híbrida combina búsquedas basadas en el significado con la coincidencia de palabras clave tradicional, ya que los embeddings manejan muy mal los identificadores exactos como los números de modelo y los IDs de factura. El reordenamiento permite obtener 50 candidatos de forma económica y luego deja que un modelo más lento pero más inteligente elija los 5 mejores. La transformación de consultas reescribe una pregunta vaga en una que se pueda buscar, divide una pregunta compuesta en partes o utiliza HyDE, que genera una respuesta ideal falsa y la utiliza para realizar la búsqueda en lugar de la pregunta original.
Una solicitud para comparar dos proyectos en Bangalore según la fecha de posesión y el precio es una sola pregunta que requiere tres búsquedas separadas.
Mejor indexación
Corregir adecuadamente la Línea A implica varias técnicas. Las búsquedas de tipo padre-hijo analizan fragmentos pequeños y precisos, pero suministran al modelo la sección más amplia que los rodea. El particionamiento semántico se realiza donde cambia el tema y no según un conteo arbitrario de caracteres. Los índices de resumen e jerárquicos primero buscan resúmenes de documentos y luego profundizan en ellos. Graph RAG almacena las relaciones entre entidades y no solo texto, por lo que puede responder preguntas como cuáles proveedores también son clientes.
Una consulta de cumplimiento es un buen ejemplo: necesita una norma, su enmienda de 2023 y una nota de exención, tres documentos para una sola respuesta.
Comportamiento agente
Después de este punto, RAG deja de ser un proceso fijo y comienza a tomar decisiones. El enrutamiento dirige una pregunta al índice adecuado, a una base de datos SQL o a ninguna recuperación en absoluto. La recuperación multi-paso lee los datos, detecta una laguna y vuelve a buscar. Self-RAG y Corrective RAG permiten que el sistema evalúe su propio contexto recuperado y lo descarte si es irrelevante, recurriendo luego a una búsqueda en la web o a una admisión honesta de que no tiene respuesta.
Tomemos como ejemplo una pregunta sobre por qué se rechazó una reclamación. Para responderla, se recuperan sucesivamente la póliza, el archivo de la reclamación y el código de rechazo.
Documentos desordenados
El conocimiento real de los negocios rara vez se presenta en forma de párrafos ordenados. Llega en forma de hojas de cálculo, escaneos, planos, capturas de pantalla y diagramas. Las habilidades necesarias incluyen el análisis teniendo en cuenta el diseño, la extracción de tablas que maneja celdas combinadas, la integración de imágenes y la búsqueda en documentos donde una gráfica contiene la respuesta. El caso típico es una pregunta sobre precios cuyo número solo se encuentra en una tarifa escaneada.
Consideraciones de producción
Todo falla después de la demostración. Los presupuestos de latencia muestran dónde se van los milisegundos. El costo por consulta es importante, al igual que el caché que realmente ayuda. El índice debe mantenerse actualizado cuando los documentos cambian cada hora. El control de acceso debe garantizar que el usuario A no pueda recuperar los fragmentos del usuario B, una fuga común y real. Los documentos envenenados pueden inyectar instrucciones. La supervisión y el registro revelan cuándo la calidad ha empeorado silenciosamente. Un sistema que funcionaba perfectamente con 200 documentos puede colapsar al llegar a 200,000.
Conozca primero las fallas
Si hay un punto clave que debe recordarse, sea este: el RAG avanzado no es una versión más sofisticada del RAG básico. Es un conjunto de soluciones, cada una para una falla específica con un nombre. Una vez que se comprende la falla, la técnica de coincidencia es el paso obvio.
Tres principios mantienen este enfoque honesto:
- Ningún culto a los frameworks. Los conceptos vienen antes que las herramientas, y cualquiera que entienda el método de fragmentación puede implementarlo en cualquier lugar.
- Ningún código copiado y pegado sin explicación. El código solo se muestra después de que quede claro el motivo por el cual se presenta de esa manera.
- Ninguna pretensión de que siempre funcione. Algunos casos hacen que RAG sea la respuesta incorrecta, y algo más simple resulta mejor.
Los principiantes deberían abordar los temas en orden, ya que cada uno presupone el anterior. Quienes tengan un sistema en funcionamiento que les decepcione pueden pasar directamente a la fase de evaluación.
Leer más
- Notas prácticas: Llevar RAG a producción: Errores integrales a partir de experiencias reales — Guía paso a paso de las Notas prácticas: Llevar RAG a producción: Errores integrales a partir de experiencias reales: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Búsqueda híbrida en Postgres para un asistente de salud: Esquema, fragmentación, RRF y evaluaciones — Construcción de la capa de recuperación de información de un asistente de salud en Postgres: fragmentación basada en la estructura, búsqueda híbrida con pgvector y RRF, cuantización binaria, umbrales y evaluaciones.