RAG falló — ¿Pero qué capa falló realmente? Un método de diagnóstico

Un sistema RAG devuelve una respuesta débil, incorrecta, incompleta o sin respaldo. El diagnóstico habitual es "falló la recuperación" o "el modelo alucinó". Ambas etiquetas son demasiado amplias para ser útiles. Un pipeline RAG en producción puede fallar antes de la recuperación, durante la recuperación, durante el ranking, durante el ensamblaje del contexto, durante la generación o después de la generación, cuando se verifican la evidencia y la validez.

Por qué "RAG falló" no es un diagnóstico

La generación aumentada por recuperación combina varios mecanismos: se interpreta una solicitud del usuario, se construyen una o más búsquedas, se recupera material candidato, se filtran o reordenan los resultados, se inserta la evidencia seleccionada en un contexto del modelo y un modelo genera una respuesta. Los sistemas en producción pueden añadir permisos, filtros de metadatos, reglas de vigencia, citas, reescritura de consultas, búsqueda híbrida, llamadas a herramientas, memoria y estado externo.

Por lo tanto, una respuesta final incorrecta no te dice qué componente falló. El modelo puede haber recibido la evidencia incorrecta. Puede haber recibido la evidencia correcta mezclada con demasiado ruido. La evidencia puede ser correcta pero estar desactualizada. La fuente puede que nunca haya contenido la respuesta. O el modelo puede haber ignorado un contexto perfectamente adecuado.

La guía de RAG de OpenAI ya establece una distinción fundamental entre fallo de recuperación y fallo del modelo: un sistema puede proporcionar el contexto incorrecto, o puede proporcionar el contexto correcto y aun así generar la respuesta incorrecta. AWS de manera similar separa la evaluación de solo recuperación de la evaluación de recuperación y generación. Para el diagnóstico en producción, esa distinción debería llevarse más lejos.

La pila de fallos de RAG

Capa 1 — Cobertura de fuentes: ¿puede el sistema responder esto en absoluto?

Antes de ajustar embeddings, rerankers o prompts, verifica que la respuesta exista en el espacio de conocimiento que el sistema tiene permitido usar. Esto suena obvio, pero muchos fallos de RAG son en realidad fallos del corpus. El hecho solicitado puede estar ausente, oculto en un archivo adjunto no indexado, disponible solo en un documento más reciente, almacenado en un sistema fuera del corpus de RAG o bloqueado por permisos.

Una métrica de recuperación no puede recuperar información que nunca fue indexada. Un top-k más grande no puede recuperar un documento que el pipeline no contiene. Si la prueba de cobertura de fuentes falla, la solución correcta es la ingesta, la selección de fuentes, los permisos o un comportamiento explícito de "no se puede responder con la evidencia disponible".

Capa 2 — Construcción de la consulta: ¿le preguntó el sistema al corpus la pregunta correcta?

La consulta del usuario no siempre es la consulta de recuperación. Los sistemas en producción reescriben preguntas, resuelven pronombres, extraen entidades, traducen idiomas, añaden restricciones de metadatos, dividen preguntas complejas o generan múltiples búsquedas. Cada transformación puede mejorar la recuperación, pero cada transformación también puede destruir información.

Una solicitud como "¿Sigue aplicándose la política a los contratistas en Alemania después de la actualización de septiembre?" contiene al menos una entidad, una población, una jurisdicción y un límite temporal. Una consulta reescrita que se convierte en "política de contratistas" puede recuperar texto semánticamente relacionado mientras pierde las variables que deciden si la respuesta es válida.

Capa 3 — Recuperación de candidatos: ¿entró el conjunto la evidencia relevante?

La recuperación de candidatos es principalmente un problema de exhaustividad. La pregunta de diagnóstico aún no es si el mejor resultado quedó en primer lugar; es si apareció evidencia relevante en algún lugar del conjunto de candidatos. Si la fuente correcta conocida no aparece, investiga la indexación, la fragmentación, las incrustaciones, la coincidencia léxica, los metadatos, la búsqueda híbrida, el manejo del idioma, los sinónimos y la expansión de consultas.

Aquí es donde la evaluación solo de recuperación es valiosa. AWS expone la relevancia del contexto y la cobertura del contexto para la evaluación de RAG solo de recuperación. El hábito de producción importante es evaluar la recuperación antes de la generación para que una respuesta final pulida no pueda ocultar un conjunto de candidatos débil.

Capa 4 — Clasificación y filtrado: ¿se descartó o enterró la evidencia correcta?

Un sistema puede tener buena exhaustividad y aun así fallar porque la evidencia relevante se clasifica por debajo de material ruidoso pero semánticamente similar. Los reranqueadores, los impulsos de recencia, los pesos de autoridad, las preferencias de idioma, los filtros de inquilinos, los controles de acceso, los filtros de estado del producto y la deduplicación cambian lo que sobrevive hasta el contexto final.

Por lo tanto, la depuración debe preservar la lista completa de candidatos, no solo el top-k final. Si la evidencia dorada se recuperó en el puesto 18 y un reranqueador la eliminó, la solución no es la misma que la de un fallo de recuperación.

Capa 5 — Ensamblaje del contexto: ¿se convirtió la evidencia útil en contexto utilizable?

El éxito de la recuperación no garantiza el éxito del contexto. Los fragmentos relevantes pueden truncarse, separarse de sus calificadores, duplicarse hasta dominar el prompt, mezclarse con versiones contradictorias o rodearse de suficiente texto irrelevante como para que el pasaje decisivo pierda prominencia.

Los límites de los fragmentos son especialmente importantes. Una oración puede contener la regla mientras que la siguiente contiene la excepción. Si se indexan por separado y solo se recupera la primera, el recuperador puede parecer relevante mientras que el contexto ensamblado se vuelve engañoso.

Capa 6 — Generación: ¿puede el modelo usar correctamente la evidencia correcta?

Una vez que el sistema ha suministrado de manera demostrable evidencia suficiente, la generación se vuelve comprobable de forma independiente. El modelo puede generalizar en exceso, combinar pasajes incompatibles, ignorar una declaración negativa, no seguir el formato de respuesta solicitado, inventar un puente entre hechos o responder desde la memoria paramétrica en lugar de la evidencia recuperada.

Por eso la corrección de extremo a extremo por sí sola es insuficiente para el diagnóstico. OpenAI recomienda la evaluación como una forma estructurada de comprender el comportamiento de la aplicación, mientras que la guía de evaluación de agentes de Anthropic enfatiza múltiples ensayos, evaluadores, rastros y casos de fallo realistas. Para RAG, el generador debe probarse tanto con recuperación normal como con contexto dorado controlado.

Capa 7 — Atribución de evidencia: ¿está realmente respaldada la respuesta?

Una respuesta plausible con citas aún puede estar débilmente fundamentada. El documento citado puede ser relevante para el tema pero no respaldar la afirmación específica. Una oración puede estar respaldada mientras que otra se infiere. Una cita puede apuntar a una fuente que contradice la respuesta una vez que se leen sus condiciones.

Por lo tanto, la evaluación de citas pertenece después de la generación. AWS distingue la precisión de las citas de la cobertura de las citas: si los pasajes citados están citados correctamente y si la respuesta está suficientemente respaldada por citas. En producción, el respaldo a nivel de afirmación es más útil que tratar la presencia de cualquier cita como calidad de evidencia.

Capa 8 — Validez y actualidad: ¿era la evidencia correcta para esta versión de la realidad?

RAG puede recuperar una fuente perfectamente auténtica, altamente relevante y fielmente citada y aun así producir una respuesta incorrecta si la fuente ya no es válida para la pregunta actual. Las políticas cambian. Las API se deprecan. Los precios se mueven. El comportamiento del software cambia entre versiones. El inventario de productos cambia. Los permisos cambian. Los parches de juegos cambian la mecánica.

Esta es una clase de fallo separada de la alucinación. La evidencia es real; su aplicabilidad es incorrecta. Por lo tanto, un sistema robusto necesita marcas de tiempo, metadatos de versión o jurisdicción cuando sea relevante, autoridad de la fuente, reglas de sustitución y un mecanismo explícito para decidir cuándo debe restringirse o abandonarse la evidencia más antigua.

El método de aislamiento más rápido: la prueba de contexto oráculo

La primera división más útil es simple: proporciona manualmente al generador un pequeño conjunto de evidencia que sabes que es suficiente para responder la pregunta. Mantén la tarea y la respuesta esperada sin cambios.

Una secuencia de diagnóstico en producción

No cambies tres capas a la vez

Un error común de depuración es cambiar los embeddings, los tamaños de fragmento, el top-k, los prompts y el modelo en una sola iteración. Si la puntuación mejora, no sabes por qué. Si empeora, no sabes qué cambio causó la regresión.

Trata la depuración de RAG como un diagnóstico experimental: mantén la mayor parte del pipeline constante y reemplaza un componente incierto con una entrada controlada. Los documentos gold aíslan la recuperación. Los fragmentos gold aíslan la selección de fragmentos. Un contexto fijo aísla la generación. Un modelo fijo aísla los cambios de recuperación. Un corpus fijo aísla los cambios de ingesta e indexación.

Una matriz de fallos para síntomas comunes de RAG

Mide cada capa con la métrica que realmente puede influir

Una respuesta correcta aún puede ocultar un defecto de RAG

El problema inverso también importa. Un sistema RAG puede producir la respuesta correcta mientras la recuperación está rota. El modelo puede ya conocer la respuesta por entrenamiento, inferirla de evidencia débil o adivinar correctamente. Si la evaluación solo mira la respuesta final, el sistema puede parecer saludable hasta que la pregunta alcanza información que existe solo en el corpus privado.

Este es el mismo problema de fiabilidad que aparece en sistemas de agentes de forma más amplia: la corrección del resultado no es suficiente para probar que la ruta de ejecución fue fiable. Para RAG, los rastros deben preservar al menos la consulta de recuperación, el conjunto de candidatos, el ranking, el contexto final, la respuesta, las citas, la versión del modelo, la versión del corpus/índice y los filtros relevantes.

Usa hipótesis competidoras, no una explicación favorita

Si una respuesta incorrecta se convierte inmediatamente en “un problema de embeddings”, la investigación ya está sesgada. Un método de depuración más sólido consiste en anotar hipótesis competidoras antes de modificar el sistema: fuente faltante, reescritura de consulta deficiente, bajo recall de recuperación, reranking deficiente, truncamiento de contexto, versiones en conflicto, fallo de generación, fallo de citación o evidencia obsoleta.

Luego elige una prueba que permita separar esas hipótesis. Esto es más eficiente que recopilar más ejemplos que respalden la primera explicación. El mismo principio se aplica al razonamiento técnico asistido por IA en general: un diagnóstico útil es el que sobrevive a pruebas discriminatorias, no el que simplemente suena plausible.

¿Qué cambiaría esta respuesta?

Las capas de diagnóstico exactas cambian según la arquitectura. Una aplicación RAG simple de un solo documento puede no tener reescritura de consulta, reranker ni capa de citación. Un sistema de recuperación agéntico puede añadir planificación, múltiples búsquedas, selección de herramientas, memoria, permisos y recopilación iterativa de evidencia. Una consulta a una base de datos estructurada puede no usar chunks ni embeddings en absoluto.

El método central sigue siendo válido: identificar los componentes que pueden cambiar el resultado de forma independiente, construir pruebas controladas que reemplacen componentes inciertos por entradas de calidad conocida y medir cada componente con evidencia adecuada para esa capa.

Limitaciones

Los fallos reales suelen estar acoplados. Una consulta débil puede reducir el recall, lo que cambia el reranking, lo que cambia el contexto, lo que aumenta la varianza de generación. La prueba de contexto oráculo es un atajo de diagnóstico, no una prueba de que un componente sea el único responsable. Los conjuntos de datos de evaluación también pueden no ser representativos, y los evaluadores basados en modelos pueden introducir sus propios errores.

Por lo tanto, la pila propuesta se usa mejor como una estructura de investigación: registrar el pipeline, aislar variables, reproducir fallos, probar explicaciones competidoras y mantener la evaluación de extremo a extremo después de las correcciones a nivel de capa.

Conclusión

“RAG falló” debería ser el comienzo de la investigación, no la conclusión. Un diagnóstico útil identifica si al sistema le faltaba la evidencia, buscó incorrectamente, no logró recuperarla, la clasificó mal, ensambló un contexto inutilizable, generó incorrectamente, atribuyó mal las afirmaciones o aplicó evidencia fuera de su límite de validez.

La regla práctica es simple: reemplazar la incertidumbre con evidencia controlada capa por capa. Comienza con la prueba de contexto oráculo. Separa la evaluación solo de recuperación de la evaluación de generación. Conserva el rastro completo. Luego corrige el componente que realmente falló en lugar de ajustar toda la pila RAG por intuición.

Preguntas frecuentes

Glosario

Fuentes primarias y lecturas adicionales