Diagnóstico de fallos en RAG: un mapa de etapas y un evaluador de fundamentación a nivel de afirmación.

Cuando un bot RAG comienza a dar respuestas incorrectas

Desplegar una aplicación RAG no significa que el trabajo esté terminado, y mucho menos en entornos de producción. Con el tiempo comienza a dar respuestas erróneas, y el primer desafío es encontrar la causa. El sistema presenta al menos siete puntos en los que pueden ocurrir fallos silenciosos: el procesamiento en fragmentos, las representaciones vectoriales, la recuperación de información, el reordenamiento de resultados, la compilación del contexto, la generación de respuestas y el prompt que los conecta. Una respuesta final defectuosa casi no revela nada sobre cuál de estos componentes falló. Algunos ingenieros han dedicado una semana a perfeccionar un prompt de generación cuando en realidad la causa era un error en el procesamiento en fragmentos.

Existe un método bastante mecánico para localizar una falla. Después surge un segundo problema: medir el grado de fundamentación a gran escala, ya que leer cada transcripción deja de ser factible una vez superada la fase de prueba de concepto. Un LLM que actúe como juez puede encargarse de esa tarea, pero los jueces también tienen sus propios modos de falla, que son tan fáciles de pasar por alto como los defectos del RAG que se supone deben detectar. Ambos aspectos se tratan a continuación: rastrear las fallas hasta su origen y crear un juez de fundamentación digno de confianza.

Encuentre primero el enlace roto

Un pipeline RAG es una cadena, y la primera tarea es identificar qué enlace ha fallado antes de que alguien edite una instrucción. El mapa que se muestra a continuación es un marco para localizar el problema. No es exhaustivo y puede ampliarse para adaptarse a un sistema o caso de uso específico.

El orden es intencional: se corrige la recuperación antes que la generación. La ingeniería de prompts no puede reparar una ventana de contexto que nunca contuvo el dato correcto. Los equipos suelen trabajar hacia atrás, reescribiendo el prompt del sistema cinco veces mientras el reordenador de resultados degrada al pasaje que sí era relevante. Las soluciones económicas con grandes beneficios, como un mejor particionamiento de los datos o una búsqueda híbrida, deben priorizarse sobre las costosas, como el ajuste fino de un reordenador de resultados o el reentrenamiento de cualquier sistema.

Tres síntomas realistas muestran cómo se utiliza este enfoque:

1. Las respuestas aparecen con confianza aunque los documentos nunca aborden el tema. Esto no es recuperación de información, ya que no existe nada relevante que obtener. Se trata de un fallo en la generación o en la decisión de no responder: el modelo no considera “No tengo esta información” como una respuesta aceptable.
2. El bot proporciona información plausible pero desactualizada. El fragmentado casi nunca es la causa. El índice está obsoleto, ya que los documentos han cambiado y nadie los volvió a integrar.
3. Las preguntas que requieren un solo hecho funcionan, pero cualquier consulta que necesite dos hechos de dos documentos falla. Este es un fallo de recuperación propio de las consultas de múltiples pasos, ya que una sola pasada de recuperación densa no puede obtener dos elementos que no se parezcan al criterio de búsqueda.

El siguiente paso es obtener el contexto realmente recuperado para un ejemplo que haya fallado y leerlo antes de hacer cualquier cambio. Si el hecho no está allí, el problema está en la recuperación. Si está allí y el modelo aún lo interpreta mal, el problema está en la generación. Esa sola verificación puede ahorrar días de trabajo.

Qué significa la fundamentación

Leer transcripciones funciona bien en unos pocos casos, pero es imposible hacerlo con miles. Aquí interviene un juez basado en modelos de lenguaje, específicamente uno para la fundamentación, también conocida como fidelidad. Su pregunta es si cada afirmación en la respuesta puede rastrearse a algo en el contexto recuperado.

Un punto sutil que confunde a muchos es que la fundamentación y la corrección son cosas distintas. Una respuesta correcta puede no estar fundamentada, por ejemplo, cuando el modelo conoce el hecho gracias al entrenamiento y no a los documentos. Una respuesta fundamentada puede ser falsa, si el pasaje recuperado es obsoleto o incorrecto. Al evaluar RAG, la fundamentación es la medida que se desea, ya que revela si la recuperación de información cumplió su función, independientemente de la calidad de los documentos subyacentes.

Un juez a nivel de afirmación

Un único prompt que solicita una calificación de fundamentación del 1 al 5 parece razonable, pero tiende a ser casi inútil. Proporciona un número sin ninguna explicación, y la evaluación de respuestas completas es precisamente donde los LLM son inconsistentes. Dividir la respuesta en afirmaciones individuales y verificar cada una funciona mucho mejor.

El prompt inicial incluye un rol de sistema que define al modelo como evaluador de fundamentación, proporciona una pregunta, el contexto recuperado y la respuesta generada, y deja claro desde el principio que la tarea no consiste en determinar si la respuesta es verdadera en general. Luego solicita que se extraigan afirmaciones y se verifiquen una por una contra el contexto, indicando para cada una un veredicto y el fragmento de texto que lo respalda:

SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.

Do the following:

1. Decompose the ANSWER into a list of atomic claims (each claim = one
   discrete factual statement, not a compound sentence).
2. For each claim, decide:
   - SUPPORTED: directly stated or reasonably entailed by CONTEXT
   - CONTRADICTED: conflicts with CONTEXT
   - UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
   (or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).

Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.

Return valid JSON only:
{
  "claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
  "groundedness_score": 0.0,
  "num_claims": 0
}

QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}

Algunas decisiones de diseño deben ser explícitas, ya que no son obvias al principio:

• Evaluación a nivel de afirmación. Es difícil depurar una sola puntuación general. Las conclusiones por afirmación indican con exactitud qué declaración falló, lo cual es importante cuando alguien debe corregir la causa subyacente.
• Intervalo de evidencia obligatorio. Al exigir que el juez cite el texto de apoyo, se fomenta que las conclusiones se basen en las pruebas y no en la plausibilidad, y permite a un revisor humano verificar rápidamente un juicio sin tener que leer todo el contexto de nuevo.
• NO SOPORTADO frente a CONTRADICIDO. Contradecir las pruebas y simplemente carecer de apoyo son dos fallos distintos con soluciones diferentes. Agrupar ambos bajo una sola etiqueta de “malo” hace que se pierdan los detalles diagnósticos.
• Una instrucción explícita de ser estricto. Los jueces de LLM tienden a ser indulgentes con los casos límite, especialmente cuando una respuesta parece plausible, y solicitar rigor disminuye eso.

Validar al juez frente a personas

Este es el paso que siempre se omite, y es el que determina si el resto tiene valor: un juez debe validarse frente a humanos antes de que se le pueda confiar.

El proceso es sencillo. Toma de 100 a 200 ejemplos, pide a una persona que evalúe de forma independiente si las respuestas están fundamentadas, y calcula el grado de acuerdo con el kappa de Cohen. La precisión bruta engaña cuando la mayoría de las respuestas están fundamentadas, ya que un juez que siempre dice “fundamentado” obtiene buenas puntuaciones pero es inútil. También se deben verificar los sesgos habituales en los jueces:

• Sesgo de posición: ¿cambia el veredicto si se reordenan los pasajes de contexto?
• Sesgo de verbosidad: ¿el juez favorece las respuestas más largas, independientemente de si realmente están mejor fundamentadas?
• Sesgo de auto-preferencia: si el juez pertenece a la misma familia de modelos que el generador, es posible que valore con mayor benevolencia los resultados de esa familia.
• Deriva hacia la indulgencia: ¿la concordancia disminuye gradualmente a lo largo de las semanas a medida que cambia el modelo del juez o la versión de la instrucción?

Un kappa bajo en una categoría es una señal de que hay que ajustar la escala de evaluación para esa categoría. Esto no indica que el sistema RAG esté defectuoso en ese aspecto. La gente confunde constantemente ambos conceptos, y la siguiente sección aborda esa distinción.

Leer un panel de control como un operador

Imagínese un panel de control organizado por tipo de consulta. La actitud adecuada es la de un operador, no la de alguien que solo observa un marcador de puntuación.

El promedio general muestra una ligera disminución, lo cual podría ser engañoso. Fila por fila, los resultados son los siguientes.

1. Búsqueda factual simple se mantiene estable y alta tanto en términos de solidez como de acuerdo. Tanto el sistema como el juez la consideran sencilla. Por sí sola es aburrida, pero una caída indicaría que algo básico falló: el indexado, la recuperación de datos o la indicación del juez, y no el razonamiento o la ambigüedad.
2. Multi-hop y comparación: su rendimiento disminuyó drásticamente. Con κ=0.71, el grado de acuerdo es solo moderado, por lo que el ruido en respuestas largas que resisten la descomposición podría explicar en parte este problema. Antes de declarar una regresión, seleccione cinco transcripciones fallidas y verifique si ambos pasajes necesarios para la respuesta se encuentran en el contexto. Cuando solo llega uno, se trata de un problema de recuperación-recuerdo, ya que la recuperación densa de un solo intento suele pasar por alto dos hechos que no se asemejan a la consulta; la solución radica en la descomposición de la consulta o en la recuperación de múltiples consultas, y no en ajustes menores en el prompt. Cuando ambos pasajes llegan pero la comparación sigue fallando, la culpa recae en la síntesis, siendo el efecto “perdido en el medio” el principal sospechoso: el modelo se basa en el primer pasaje y le da demasiada poca importancia al segundo.
3. Cifras numéricas y financieras muestran κ=0.52. Eso representa un acuerdo débil y es la señal más evidente en la tabla, ya que indica que aún no se puede confiar en el juez en este caso. La equivalencia numérica es realmente difícil para un juez basado en modelos de lenguaje: “20%”, “aproximadamente una quinta parte” y “$20 de descuento en un artículo de $100” son la misma afirmación expresada de diferentes maneras. El instinto sensato es dejar el sistema RAG en paz hasta que se defina claramente la metodología, ya que intentar trabajar con números poco fiables desperdicia tiempo de desarrollo.
4. Aspectos relacionados con políticas y procedimientos presentan un nivel estable y bueno, al igual que la primera fila, pero por una razón diferente: las respuestas suelen provenir de un único documento bien estructurado y no requieren síntesis de varios documentos. Si este indicador disminuye, el razonamiento no es lo primero que se debe sospechar; es más probable que se trate de una lista numerada dividida entre límites de bloques, lo que hace que el modelo solo tenga en cuenta los pasos del 1 al 3 e invente los pasos 4 y 5.
5. Fuera del alcance merece la primera corrección, aunque n=20 lo convierte en el segmento más pequeño. Con κ=0.90 el evaluador es muy fiable aquí, ya que detectar una respuesta inventada sin contexto de apoyo es mucho más fácil que juzgar afirmaciones numéricas sutiles o de múltiples pasos. Esa fiabilidad hace que la disminución sea creíble, y constituye el fallo más peligroso de la tabla. El sistema pasó de admitir correctamente “No lo sé” a inventar respuestas con confianza, lo cual es peor que una cifra incorrecta, ya que no se distingue en tono de una respuesta correcta. Dos causas probables: la recuperación está devolviendo pasajes similares que el modelo interpreta como permiso para responder, o un cambio reciente en la instrucción o en el modelo eliminó silenciosamente la indicación de abstención. Comience analizando las puntuaciones de similitud de recuperación para este segmento.
Si se encuentran cerca del nivel de ruido y el modelo responde de todos modos, falta una barrera de umbral de relevancia antes de la generación.

El método en cinco pasos

Todo el proceso se reduce a esto:

• no confíe en el promedio
• verifique la fiabilidad del evaluador antes de confiar en la puntuación
• segmente por categoría
• haga hipótesis a partir de las pruebas reales sobre qué etapa falló
• priorice según la gravedad multiplicada por la confianza, y no según qué umbral se movió más

Notas prácticas para nuevos evaluadores

1. Cada respuesta evaluada implica una llamada adicional al LLM. Con un volumen real, evalúe una muestra en lugar de todo, y estratífíquela por categoría de consulta para que los segmentos raros pero críticos, como los fuera de alcance, no queden abrumados por consultas fáciles y numerosas.
2. Vuelva a validar el kappa cada vez que cambie el modelo del evaluador o el prompt del evaluador. Cualquiera de estos cambios crea un nuevo evaluador.
3. Un juez adaptado a las particularidades numéricas o al jerga de un dominio no se traslada automáticamente a otro, por lo que debe calibrarse por dominio y no de forma global única.

Todos los ejemplos y figuras aquí presentados son ilustrativos y no provienen de un sistema en producción real. El marco y la estructura de las instrucciones constituyen un punto de partida razonable.

Donde termina esto

El material anterior abarca un mapa para localizar fallos, la brecha entre fundamentación y corrección, un juez a nivel de afirmación y el paso de calibración que muchos omiten. Queda un límite: todo supone la existencia de un bloque de contexto recuperado sin errores. Esa suposición falla cuando un sistema utiliza herramientas, enlaza pasos de recuperación o razona sobre sus propios resultados intermedios, como lo hacen los sistemas agentes. Definir la fundamentación sin un único bloque de contexto al que comparar y reestructurar en consecuencia es un problema aparte.

Leer más

• Notas prácticas: Dónde aprender RAG desde cero en 2026: Los cursos y — Guía detallada de las Notas prácticas: Dónde aprender RAG desde cero en 2026: Los cursos y: contratos, verificaciones y espacios para código adicional para los equipos que implementan este patrón.
• RAG con LangChain desde cero: Cargadores, fragmentos, embeddings, evaluación — Construye un sistema de preguntas y respuestas con documentos paso a paso: carga de archivos, fragmentación, embeddings, las fases de indexación y recuperación, y cómo calificar la recuperación y las respuestas.

Cross-Encoder como juez: Controla tu pipeline RAG con precios de relevancia — Cómo la atención cruzada permite a un cross-encoder calificar la relevancia entre consulta y documento en un rango de 0 a 1, y cómo un umbral puede evitar que las búsquedas de baja calidad lleguen nunca al LLM.