Depura la pipeline, no el LLM: Un modelo mental para situaciones de fallo en RAG en entornos de producción
Cuando un bot RAG responde incorrectamente, rara vez es el LLM la causa. Rastrea los fallos a través de la ingestión, recuperación, generación, evaluación y el bucle para encontrar la capa responsable.
Fuentes: RAG Is Not Just Vector Search
Imagínese un bot de soporte en una empresa SaaS de tamaño medio que un día responde de manera diferente a dos clientes cuando ambos preguntan sobre el plazo de reembolso.
Se abre un incidente, y el primer pensamiento del ingeniero de turno es que el LLM está generando alucinaciones y que se necesita un modelo diferente. Esa es el diagnóstico inicial. Trata a RAG como una caja negra, cambia el modelo y espera que el síntoma desaparezca.
Un ingeniero experimentado comienza desde otro ángulo y pregunta en qué etapa del proceso ha fallado. Decir que el modelo genera alucinaciones con los nombres es solo un síntoma y no explica nada más.
Dos días después aparece el verdadero problema. La política de reembolso había sido modificada, pero nadie eliminó el PDF obsoleto del corpus de recuperación, por lo que ambas versiones seguían apareciendo con puntuaciones de relevancia similares, y el modelo resumía fielmente un contexto contradictorio. En absoluto estaba alucinando. (Este es un escenario compuesto a efectos ilustrativos, pero sus variantes son comunes.)
Esta es la diferencia entre la versión teórica de RAG y la forma en que falla RAG en producción. Los tutoriales suelen resumirla en una sola línea:
Embed → Search → Generate
Es suficiente para una demostración, pero no para el uso en producción. Un sistema real cuenta con varios límites de fallo. La pregunta técnica importante no es solo si el LLM puede escribir una buena respuesta, sino si cada capa que genera esa respuesta funciona correctamente.
Ingestión: la calidad se determina antes de comenzar la recuperación
La mayoría de las tareas de depuración en RAG comienzan desde el extremo equivocado. La gente ajusta los prompts, cambia los modelos de embedding y modifica los parámetros top-k, cuando en realidad el problema se introdujo semanas antes, durante la fase de ingestión.
Analizar por estructura
Las tablas, los bloques de código, los títulos y las listas transmiten significado a través de su estructura. Si se convierte una tabla de precios en prosa simple, el vínculo entre una fila y su encabezado de columna puede desaparecer. Un pipeline de ingestión debe mantener esa estructura y elegir una representación adecuada para la recuperación, en lugar de tratar cada documento como un bloque de texto indiferenciado.
El enfoque adecuado depende del contenido. Una tabla podría requerir una extracción estructurada, una serialización de texto, metadatos o una combinación de recuperación léxica y semántica.
Fragmentación por significado
El método simple divide el texto cada 512 tokens. Sin embargo, el conteo de tokens y el significado no coinciden, por lo que un fragmento puede comenzar con una introducción y terminar a mitad del punto al que se dirigía.
La fragmentación semántica busca dividir el texto en función de los cambios de tema en lugar de contar tokens. No constituye una mejora universal y requiere más recursos durante la ingestión. En materiales extensos como políticas, contratos y documentación técnica, mantener las ideas completas suele mejorar los resultados de la recuperación.
Proporcionar contexto a cada fragmento antes de su incrustación
Un fragmento tomado de la página 40 de un documento de 60 páginas puede ser un texto perfectamente válido, pero seguir siendo ambiguo fuera de su contexto original. Tomemos una oración que indica que un límite aplica únicamente a los clientes empresariales: sin la sección que lo rodea, nada indica al sistema a qué se refiere ese “límite”.
La recuperación contextual soluciona esto al añadir antes del fragmento el contexto a nivel de documento: el título, la ruta de la sección, el producto, la versión o una breve nota generada sobre dónde se encuentra el fragmento. El objetivo es que cada fragmento conserve el contexto que, de otro modo, el proceso de fragmentación eliminaría.
Adjuntar metadatos
Trate los metadatos como datos funcionales. En las etapas posteriores se necesitan la fuente, la fecha, el tipo de documento, el usuario, los permisos y la versión para filtrado, control de acceso, verificaciones de actualidad y depuración.
Eso plantea una de las preguntas más importantes sobre la producción en el proceso de ingestión: ¿qué sucede cuando un documento de origen cambia mañana? Si el pipeline solo puede volver a indexar todo, una pequeña edición de contenido se convierte en una carga operativa. Idealmente, la ingestión debería ser incremental e idempotente, de modo que una actualización sea detectada, procesada y propagada sin tener que reconstruir todo el corpus.
En el caso presentado al inicio, la antigua política de reembolsos nunca fue un error del LLM. Se debió a la forma en que se gestionaba la ingestión y el corpus.
La recuperación de información es un pipeline y no una búsqueda simple
La palabra sugiere un único paso. En la práctica, la recuperación de información es una cadena de decisiones, y la secuencia de estas tiene consecuencias.
1. Reescribir
La gente no escribe consultas de búsqueda de forma natural. Preguntan algo como si el reembolso ya fue enviado. Un LLM puede transformar eso en algo más útil para la recuperación de información, quizás integrando el historial de conversaciones o dividiendo una pregunta compleja en otras más específicas. Sin embargo, reescribir no es gratis: una mala reescritura puede omitir detalles clave o añadir suposiciones. Considérelo como otro componente más a evaluar y no como algo mágico.
2. Alcance antes de buscar
Este es uno de los detalles más importantes en la implementación práctica. Si el sistema es multiinquilino o tiene control de permisos, el espacio de búsqueda debe respetar esos límites. El inquilino, los permisos, la visibilidad, la fecha y la fuente deben aplicarse dentro de la operación de recuperación siempre que el sistema subyacente lo permita.
El filtrado después de aplicar el criterio global top-k genera dos problemas. Primero, los documentos útiles podrían ya haber sido excluidos del top-k por documentos que el usuario no tiene permiso para ver. Segundo, la lógica de autorización acaba estando peligrosamente separada del proceso de recuperación de información. En pocas palabras, no busque todo primero y luego pregunte qué puede ver el usuario; limite la búsqueda primero.
3. Búsqueda de dos maneras
La búsqueda vectorial densa maneja bien la cercanía semántica. Alguien que pregunta cómo cancelar puede coincidir con texto que indica que los clientes pueden finalizar su plan cuando lo deseen, a pesar de no compartir ninguna palabra en común.
No obstante, los embeddings son menos efectivos con identificadores exactos. Piense en cadenas de texto como estas:
ERR_CONNECTION_RESET
SKU-48392
API-v3-beta
En este tipo de consultas, el token literal es la señal, y es allí donde la recuperación léxica como BM25 cobra importancia. La recuperación en producción suele combinar la búsqueda densa para el significado con la búsqueda léxica para cadenas exactas.
4. Fusión
Ahora existen dos listas ordenadas. La búsqueda densa tiene su propio orden, BM25 tiene el suyo, y sus puntuaciones brutas no son necesariamente comparables. La Fusión de Rangos Recíprocos (RRF) ofrece una forma sencilla de combinarlas utilizando la posición en el ranking:
RRF_score(d) = Σ 1 / (k + rank_i(d))
Cada lista aporta según la posición que ocupa un documento en ella, lo que evita la necesidad de calibrar las distribuciones de puntuación de dos sistemas no relacionados entre sí.
5. Reclasificación
Fusión proporciona un conjunto de candidatos, no necesariamente el contexto final. Un reclasificador con codificador cruzado lee la consulta y cada candidato junto, y genera una puntuación de relevancia para esa pareja específica. Esto difiere fundamentalmente de incrustar la consulta y el documento de forma independiente y comparar los vectores.
El costo radica en los cálculos, por lo que no se aplicaría un codificador cruzado a todo el corpus. La recuperación podría devolver los 20 o 50 candidatos principales, y el reclasificador seleccionaría el contexto más sólido de entre ellos.
Por lo tanto, el modelo mental de implementación es: recuperación densa, luego recuperación léxica, luego fusión, y finalmente reclasificación. No se trata de simplemente “usar una base de datos vectorial y listo”.
Generación: un buen contexto aún no garantiza una buena respuesta
Encontrar los documentos adecuados es necesario, pero no suficiente. El LLM todavía debe utilizarlos correctamente.
Gestión de la ventana de contexto
Más contexto no implica automáticamente una mejor respuesta. Los modelos no utilizan los contextos largos de manera uniforme. Las investigaciones han demostrado que la información situada en medio de un contexto largo puede ser recordada con menos fiabilidad que la información cercana al inicio o al final. Por lo tanto, incluir los 20 fragmentos principales en el prompt puede empeorar la respuesta. El objetivo es contar con el máximo contexto útil y no con el máximo contexto posible.
Límites del prompt y atribución
Indique claramente en el prompt cómo deben utilizarse los fragmentos obtenidos. El modelo debe tratarlos como evidencia a citar, nunca como instrucciones a seguir.
Las citaciones también ayudan con la confianza y la depuración. Cuando una respuesta indica que los clientes empresariales tienen 30 días para cancelar, es necesario encontrar una forma de rastrear esa afirmación hasta una fuente fiable.
Abstención
La abstención marca una diferencia importante entre un sistema de demostración y uno fiable. Si la búsqueda no arroja resultados, el modelo seguirá intentando ayudar, a menos que rechazar la solicitud esté permitido. Un sistema en producción debería poder responder que la evidencia no es suficiente. Esa suele ser la decisión correcta y no un defecto.
Si no hay abstención, cada fallo en la búsqueda puede convertirse en una alucinación convincente. El LLM asume la responsabilidad por dar una respuesta incorrecta, aunque el verdadero fallo pudo ocurrir en capas anteriores del proceso.
La evaluación precede a cualquier solución
RAG tiene una característica problemática: la calidad puede disminuir mientras el código de la aplicación permanece sin cambios. Un nuevo modelo de incrustación, un método de fragmentación diferente, documentos añadidos o eliminados, ajustes en la configuración de recuperación o una modificación en el prompt pueden cambiar las respuestas, incluso cuando el código desplegado del día anterior es idéntico, carácter por carácter. Por lo tanto, el RAG en entornos de producción debe evaluarse en varios niveles.
Calidad de la recuperación. La precisión del contexto se refiere a cuánto del contexto recuperado era relevante. El recuerdo del contexto se refiere a cuánta de la información relevante disponible fue realmente encontrada por el sistema de recuperación. Juntos, permiten distinguir entre “nunca lo encontramos” y “lo encontramos pero quedó oculto entre ruido”.
Calidad de la generación. La fidelidad (también llamada fundamentación) verifica que la respuesta se derive de las pruebas obtenidas, mientras que la precisión en las citaciones asegura que las fuentes mencionadas respalden cada afirmación. Una respuesta bien redactada aún puede carecer de fundamentación.
Salud del sistema. También son importantes las métricas operativas: latencia p95, costo por consulta y tasa de abstenencia. No se trata únicamente de cuestiones relacionadas con la infraestructura. Si la latencia se duplica porque un agente comienza a ejecutar varios ciclos de recuperación, eso forma parte de la calidad del sistema. Un aumento repentino en las abstenencias puede indicar que la recuperación de información ha empeorado. Un incremento en el costo por consulta puede significar que un cambio aparentemente inocuo introdujo un proceso costoso.
Separar las mediciones resulta útil para el diagnóstico. Un recuerdo saludable junto con una disminución en la groundedness apunta hacia la generación. Una disminución en la precisión indica problemas en la ingestión, los filtros, la recuperación o el ranking. Si solo se monitorea la calidad general de las respuestas, cada regresión parece idéntica y no ofrece nada sobre lo cual actuar.
De la cadena de procesamiento al bucle de retroalimentación
La cadena de procesamiento básica sigue siendo sencilla:
Ingestion → Retrieval → Generation → Evaluation
Muchos sistemas no necesitan nada más. Una base de conocimientos bien indexada y preguntas claras rara vez requieren que un agente elija el siguiente paso. Sin embargo, existen preguntas más difíciles.
Tomemos como ejemplo una solicitud para comparar las cifras de ingresos del segundo trimestre con lo que se informó en la presentación del consejo de administración, y luego explicar la diferencia. La respuesta podría requerir los números del Q2, la presentación del consejo, las secciones relevantes de cada una, una comparación y, posiblemente, una consulta a otra fuente de datos. Una sola búsqueda puede no ser suficiente, y ahí es donde el RAG con agente resulta útil. En lugar de un paso simple de buscar y luego generar, se puede ejecutar un bucle:
Retrieve
↓
Evaluate
↓
Enough evidence?
↓ no
Retrieve again
↓
Generate
Un sistema de este tipo puede concluir que las pruebas disponibles son insuficientes, reformular la consulta, buscar nuevamente o transferir una subpregunta a una base de datos SQL, un grafo de conocimiento o una API en tiempo real. La recuperación de información se vuelve iterativa y deja de ser un proceso único.
No obstante, el RAG con agente no es necesariamente mejor. Cada bucle adicional aumenta la latencia, el costo en tokens y las posibilidades de fallo, y puede provocar búsquedas innecesarias cuando el agente no tiene una razón clara para continuar. Su complejidad resulta útil cuando las preguntas son ambiguas, requieren múltiples pasos o necesitan varias fuentes. Una pregunta sobre la política de reembolsos probablemente debería responderse en una sola pasada mediante un pipeline estático bien diseñado. La comparación entre mazos de cartas podría justificar la iteración.
La pregunta relevante es si el sistema tiene una razón medible para buscar nuevamente, y no si debería contar con un agente en absoluto. Realizar bucles sin una regla clara de finalización solo genera demoras y costos adicionales.
Un modelo mental para la producción
Empezar con el LLM es el error de depuración más común. Una respuesta incorrecta es solo el último síntoma que se manifiesta, y la causa puede estar mucho más arriba en el proceso. Los documentos desactualizados se asemejan a alucinaciones, una mala división en fragmentos se parece a un fallo en la recuperación de información, una recuperación deficiente se asemeja a un error en la generación, y la falta de evaluación oculta todos estos problemas hasta que los clientes se quejan.
Así que no preguntes qué modelo usar. Pregunta qué capa está fallando.
INGESTION
↓
RETRIEVAL
↓
GENERATION
↓
EVALUATION
↖
└── feedback loop / Agentic RAG
Los datos obsoletos significan que hay que corregir el proceso de ingestión. Un documento faltante implica corregir el mecanismo de recuperación. Un documento encontrado pero con una clasificación baja significa que hay que ajustar el sistema de ranking. Un contexto correcto con una respuesta incorrecta indica que es necesario analizar el proceso de generación. Si no puedes determinar cuál de estos casos aplica, primero crea una evaluación más precisa. Y cuando una sola pasada nunca sea suficiente, considera utilizar un bucle de tipo agente.
Comienza con la pipeline y deja el modelo para el final.
De dónde provienen las ideas
Para una lectura adicional, el artículo original sobre generación mejorada mediante recuperación de Lewis y colaboradores (NeurIPS 2020) define el patrón básico. El informe de Anthropic de 2024 sobre recuperación contextual indica una disminución significativa en los fallos de recuperación gracias a los embeddings contextuales, BM25 contextual y el reordenamiento de resultados, aunque se trata de mediciones realizadas por el propio proveedor. Cormack, Clarke y Büttcher (SIGIR 2009) introdujeron la Fusión de Rangos Recíprocos. El artículo “Lost in the Middle” de Liu y colaboradores estudia cómo los modelos utilizan contextos extensos; el artículo RAGAs describe la evaluación automática de RAG, y el artículo Self-RAG de Asai y colaboradores aborda la recuperación autoreflexiva y basada en agentes.
Lecturas relacionadas
- Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y el — Guía paso a paso de las Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y el: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- El significado como coordenadas: De las embeddings a las bases de datos vectoriales y RAG — Explicación sencilla de las embeddings de oraciones, la similitud coseno, las bases de datos vectoriales y el ciclo RAG, con cuatro oraciones cortas sobre perros, gatos y París que muestran cómo funciona la búsqueda por significado.