English · Español

04 — Evaluar RAG: métricas de recuperación, métricas end-to-end, faithfulness¶

Evaluar RAG (Retrieval-Augmented Generation) requiere tres planos: ¿el retriever trae el documento bueno? (retrieval), ¿la respuesta es factualmente correcta? (accuracy), ¿la respuesta cita el contexto? (faithfulness). Cada uno puede fallar de forma independiente. Sin un eval set bien construido, el pipeline entero se vuelve una caja negra.

Tres capas de evaluación¶

Un pipeline RAG tiene tres capas. Cada una puede evaluarse de forma independiente:

Evaluación de retrieval (recuperación): ¿el retriever devuelve el o los chunks correctos en el top-k?
Evaluación del reader: dado el contexto correcto, ¿el reader produce una respuesta correcta?
Evaluación end-to-end: dada una consulta, ¿el pipeline completo produce una respuesta correcta y fiel (faithful)?

Un fallo en cualquier capa se propaga. Diagnosticar qué capa falló exige evaluar cada una por separado.

El eval set¶

Necesitas un gold standard: un conjunto de triples (query, expected_chunk_id, expected_answer).

Construcción para nuestra KB:

Redactar a mano ~30-50 consultas que cubran la matriz verbo-tiempo-persona de §A13.
"What's the past participle of eat?"
"How do you conjugate work for she in present simple?"
"What's the Spanish translation of I have gone?"
Para cada consulta, identificar el expected chunk ID (el chunk que debería responderla).
Para cada consulta, escribir la expected answer (la respuesta correcta).

Evitar: consultas que sean paráfrasis directas de los chunks de la KB (el modelo simplemente las regurgitaría). Preferir: consultas que requieran síntesis o extracción específica del chunk.

El eval set debe estar curado a mano, versionado, y tratado como la verdad de referencia (ground truth) de la fase.

Métricas de retrieval¶

Hit-rate@k¶

Para cada consulta, ¿aparece el expected_chunk_id en el top-k del retriever?

\[ \text{hit-rate@k} = \frac{1}{|Q|} \sum_{q \in Q} \mathbb{1}[\text{expected\_chunk}(q) \in \text{top-k}(q)] \]

Una señal binaria por consulta. Fácil de interpretar.

Rango: 0 a 1. Más alto es mejor.

Objetivo DoD: hit-rate@5 ≥ 0.80 para la Fase 29 (es decir, el 80% de las consultas tiene el documento correcto en el top-5).

MRR (Mean Reciprocal Rank)¶

Para cada consulta, halla el rango r del chunk esperado en la salida del retriever (1 = top, 2 = segundo, etc.). Si no se recupera en absoluto: 1/r := 0.

\[ \text{MRR} = \frac{1}{|Q|} \sum_{q \in Q} \frac{1}{\text{rank}_q(\text{expected\_chunk})} \]

Una señal continua. Captura cómo de cerca del top está el chunk esperado.

Rango: 0 a 1. Más alto es mejor.

Objetivo DoD: MRR ≥ 0.60. Implica que el chunk esperado se sitúa, en promedio, en la posición 1-2 a lo largo de las consultas.

Recall@k¶

Para consultas con varios chunks relevantes (múltiples chunks podrían responder): fracción de chunks relevantes recuperados.

Para las consultas de relevancia única de la Fase 29, recall@k ≡ hit-rate@k.

Precision@k¶

Para consultas con varios relevantes: fracción del top-k que es relevante.

Para la relevancia única de la Fase 29, precision@k = 1/k si hay acierto, 0 si hay fallo.

Métricas del reader (closed-book sobre contexto recuperado)¶

Dado el contexto correcto (gold chunk + quizá algún distractor), ¿el reader produce una respuesta correcta?

Exact match (EM)¶

¿La respuesta contiene la cadena de la respuesta esperada?

Frágil: "the past participle is eaten" vs "eaten is the past participle" — ambas correctas, pero EM puede divergir.

Útil para respuestas muy plantilladas; menos útil para texto libre.

F1 (solapamiento de tokens)¶

F1 entre los tokens de la respuesta esperada y los tokens de la respuesta predicha.

Para respuestas de gramática verbal (a menudo cortas y léxicamente restringidas), F1 es razonable.

LLM-judge¶

Usar un LLM (modelo de lenguaje grande, LLM) separado (grande, fuerte) como juez. Prompt: "Dada la pregunta, la respuesta de referencia y la respuesta candidata, puntúa la candidata de 0 a 1."

Caro (una llamada al LLM grande por consulta de evaluación). Se usa en producción. Se menciona por completitud.

Para la Fase 29: el lab 03 usa F1 + inspección cualitativa manual sobre 30 consultas seleccionadas a mano. Sin LLM-judge.

Métricas end-to-end¶

Combinan retrieval y lectura: dada la consulta, produce una respuesta; evalúa la respuesta contra el gold.

El end-to-end es más difícil de interpretar porque los fallos podrían ser de retrieval o de lectura. Incluye siempre métricas de retrieval por separado.

Faithfulness¶

La idea central: la respuesta debe estar respaldada por el contexto recuperado, no extraída de los pesos del modelo.

Por qué importa esto¶

Si la respuesta coincide con el gold pero no está respaldada por el contexto recuperado, el modelo está usando su propio conocimiento (closed-book), no RAG. Esto hace al sistema frágil:

Las actualizaciones en la KB no se propagan a las respuestas.
Pueden colarse alucinaciones (el modelo dice algo que no está en el contexto).
Las citas son inexactas (los chunks citados no contienen realmente la afirmación).

Faithfulness heurística¶

Para cada par (frase_de_respuesta, texto_de_chunks_recuperados), calcula el solapamiento de tokens. Si los tokens de la frase están cubiertos en su mayoría por los tokens de los chunks, marca "soportada". Si no, "no soportada".

Umbral: p. ej., el 70% de los tokens de la respuesta (excluyendo stopwords) deben aparecer en los chunks citados.

Es frágil pero cuantitativo. Captura la forma del anclaje sin verificar implicación lógica.

Faithfulness con LLM-judge¶

A un LLM más fuerte se le pasan la respuesta y los chunks; se le pregunta "¿todas las afirmaciones de la respuesta están soportadas por los chunks?" Puntuado 0-1.

Más preciso; más caro.

Para la Fase 29 usamos faithfulness heurística. DoD: ≥ 70% sobre un eval cualitativo de 30 consultas.

Precisión de las citas¶

Independiente de la faithfulness: ¿las citas se refieren realmente a los chunks que contienen la afirmación?

Si la respuesta cita chunk-12 para una afirmación, ¿contiene chunk-12 esa afirmación?
Si la respuesta hace una afirmación sin cita, ¿está esa afirmación al menos respaldada por algún chunk recuperado?

Para la Fase 29 pedimos al reader que emita las citas como tags [chunk-id]. El lab 03 las verifica.

Dónde suele fallar cada métrica¶

Métrica	Modo de fallo habitual
hit-rate@5	el retriever trae chunks semánticamente cercanos pero incorrectos
MRR	el retriever encuentra el gold chunk pero en un rango bajo
F1	el reader reformula la respuesta; F1 pierde variaciones léxicas
Faithfulness (heurística)	el reader extrae de los chunks pero usa sinónimos — la heurística no detecta el solapamiento
Precisión de citas	el reader cita un chunk que en realidad no usó

Una buena evaluación las incluye todas. El lab 02 + lab 03 lo hacen.

Evaluación solo del reader (contexto oracle)¶

Un diagnóstico útil: alimentar al reader directamente con el gold chunk (saltándose el retrieval). Medir F1.

Si F1 es alto en modo oracle pero bajo en end-to-end → el retrieval es el cuello de botella.

Si F1 es bajo incluso en modo oracle → el reader es el cuello de botella.

Para la Fase 29: el Block E opcional del lab 03 hace esto. Espera F1 del reader ≥ 80% en modo oracle (la tarea es simple dado el contexto correcto); el F1 end-to-end debería ser más bajo en proporción al hit-rate del retrieval.

Calibración de expectativas¶

Para una KB de 50 documentos con all-MiniLM-L6-v2:

hit-rate@5 ~ 0.85-0.95 (KB pequeña, chunks bien anclados).
MRR ~ 0.65-0.80.
F1 del reader (oracle) ~ 0.80-0.90.
F1 del reader (end-to-end) ~ 0.70-0.85.
Faithfulness heurística ~ 0.70-0.85.

Son rangos esperados, no garantías. Las medidas del lab pueden desplazarlos.

Taxonomía de modos de fallo¶

Cuando la respuesta end-to-end es errónea, clasifica qué capa falló:

Capa	Síntoma
Retrieval miss	Gold chunk no está en el top-k
Retrieval distract	Gold chunk está en el top-k pero el reader lo ignora y escoge un distractor
Reader miss	Gold chunk llega al reader; el reader extrae el sub-hecho incorrecto
Reader hallucination	El reader añade detalles que no están en ningún chunk recuperado
Reader format	La respuesta es correcta pero en formato erróneo (falla el exact match)

El informe de la fase debe clasificar los fallos del eval set. Habitual: retrieval-distract (el gold está en el top-3 pero el distractor es más "saliente" para el reader).

Ejercicios¶

Soluciones tras la apertura de la fase en solutions/04-evaluation-ref.md.

Una consulta tiene el gold chunk en el rango 3 de 10. ¿Cuál es el MRR para esta única consulta? ¿Y si está en el rango 1? ¿En el rango 10? ¿No recuperado?
El reader produce "eaten is the past participle of eat". Esperada: "the past participle of eat is eaten". Calcula F1 sobre tokens.
Esboza una taxonomía de fallos de 30 consultas seleccionadas a mano: 5 retrieval miss, 8 retrieval distract, 4 reader miss, 13 aciertos. ¿Cuánto vale hit-rate@5 frente a accuracy end-to-end?
Heurística de faithfulness: los tokens de la respuesta (excluyendo stopwords) deben aparecer en los chunks recuperados ≥ 70%. Aplícalo a "the past participle of eat is eaten" dado un chunk que contiene "the past participle of the irregular verb eat is eaten (Spanish: comido)". ¿Pasa o falla?
Argumenta: si hit-rate@5 es del 90% pero F1 end-to-end es del 60%, ¿dónde está el cuello de botella? ¿Qué harías a continuación?

Recapitulación en un párrafo¶

La evaluación de RAG requiere tres capas: retrieval (hit-rate@k, MRR), lectura (F1 sobre contexto oracle), end-to-end (F1 sobre el pipeline completo). Más faithfulness (¿la respuesta cita el contexto?) y precisión de citas (¿las citas se refieren a chunks relevantes?). Cada una puede fallar de forma independiente. El eval set son triples (query, expected_chunk, expected_answer) curados a mano — pequeño pero de alta calidad. Para la Fase 29 apuntamos a hit-rate@5 ≥ 0.80, MRR ≥ 0.60, faithfulness ≥ 70%. El informe de la fase clasifica los fallos por capa; eso guía mejoras dirigidas.

Siguiente: lab/00-kb-curation.md.