Evaluación de RAG: métricas de retrieval, groundedness y calidad de respuesta

Una evaluación fiable de RAG responde al menos a tres preguntas distintas: si el retriever encontró la evidencia necesaria, si la respuesta se apoya en el contexto recuperado y si resuelve la tarea del usuario. Una puntuación agregada oculta la causa del fallo. Un groundedness alto no ayuda si el sistema resume fielmente un chunk irrelevante, y una respuesta correcta no demuestra la calidad del retrieval porque el modelo pudo reproducir el dato desde su memoria paramétrica.

Construye la evaluación como un árbol de diagnóstico. Primero fija la versión del corpus, la query, los documentos permitidos y las etiquetas de relevancia. Después guarda IDs recuperados, ranks y textos, y solo entonces la respuesta, las citas y los verdicts de los graders. Este trace permite distinguir un defecto de ingestion de un retrieval miss, una regresión del reranker, un claim sin soporte o una mala forma de respuesta. El release gate debe componerse de umbrales separados y failure cases críticos, no de una media atractiva.

• Retrieval: si los documentos o chunks necesarios aparecen en el top-k y en qué posiciones.
• Grounding: si el contexto respalda cada afirmación verificable de la respuesta.
• Calidad de respuesta: si la respuesta es correcta, relevante, completa y útil para la tarea.
• Operación: latencia, coste, retrieval vacío, timeout y resultados con fuentes obsoletas.
• Safety: fugas de ACL, prompt injection, citas inseguras y abstention correcta.

Para cada query de evaluación, etiqueta los IDs de documentos o chunks relevantes, idealmente con relevancia graduada: evidencia crítica, contexto útil y material irrelevante. Recall@k muestra qué proporción de los objetos necesarios encontró el sistema entre los primeros k resultados; precision@k muestra cuántos de esos resultados son realmente relevantes. Mean Reciprocal Rank es útil cuando importa el primer resultado correcto, mientras que nDCG tiene en cuenta el orden y varios niveles de relevancia.

Relaciona la métrica con la UX y el contrato del generator. Si la respuesta solo puede usar cuatro chunks, Recall@50 no describe el contexto efectivo. Evalúa por separado el retrieval a nivel de documento y de chunk: el documento correcto con un mal chunking puede parecer un éxito parcial. Para metadata filters, ACL de tenant y consultas temporales, añade constraint correctness: un documento relevante pero no autorizado u obsoleto es un error, no un resultado positivo.

Divide la respuesta en afirmaciones verificables y, para cada una, guarda supported, contradicted o not-in-context junto con los source spans concretos. Groundedness o faithfulness mide el apoyo del contexto proporcionado, pero no garantiza que la propia fuente sea verdadera. Evalúa citation correctness por separado: la cita debe llevar al fragmento que demuestra la afirmación, no simplemente a un documento temáticamente parecido.

Un judge sin referencia es útil para una regression suite amplia, pero su verdict no es ground truth. Calibra el judge sobre un slice etiquetado por humanos, mide agreement y estabilidad entre runs, fija la versión del judge y el prompt, y deriva casos fronterizos o de alto riesgo a una persona. Añade ejemplos negativos con chunks contradictorios, respuestas ausentes e intentos de inducir al modelo a usar conocimiento externo; de lo contrario el grader enseña al equipo a optimizar solo casos positivos fáciles.

Answer correctness compara el resultado con una reference answer o una rubric, pero el literal match rara vez basta en respuestas abiertas. Define facts obligatorios, formulaciones aceptables, claims prohibidos, formato requerido y condiciones de abstention. Para extraction sirven precision y recall a nivel de campo; para support, resolution correctness y escalation; para research, cobertura de claims clave, provenance y representación de la incertidumbre.

Answer relevance comprueba si el sistema respondió realmente a la pregunta, mientras completeness comprueba si omitió partes necesarias. No premies la verbosidad: una respuesta corta y respaldada puede ser mejor que un texto completo pero arriesgado. Introduce un abstention score separado para queries que el corpus no cubre. Un RAG que se niega a responder sin evidencia puede tener un answer rate superficial menor y, aun así, controlar mejor los errores.

Empieza con un conjunto pequeño de queries similares a producción verificadas manualmente y un manifest versionado. Estratifícalo por intent, dificultad, idioma, longitud de respuesta, tipo de fuente, freshness, ACL y coste del error. Añade lookups sencillos, preguntas multi-hop, formulaciones ambiguas, casos sin respuesta, instrucciones adversarias dentro de documentos y queries posteriores a actualizaciones del corpus. No dividas train y test con near-duplicates aleatorios del mismo documento.

Las preguntas sintéticas ayudan a ampliar cobertura, pero no sustituyen la revisión humana: un generator puede crear una query que repita de forma antinatural el chunk y eleve artificialmente el retrieval score. Marca la procedencia de cada case y reporta por separado slices humanos, de producción y sintéticos. Cada incident o corrección confirmada del usuario debe generar un regression case saneado cuando la política de datos lo permita.

Si el retrieval recall es bajo, investiga ingestion coverage, límites de chunks, query rewriting, embeddings, filters y hybrid search antes de cambiar el prompt del generator. Si recall es bueno pero precision o nDCG son débiles, ajusta ranking, deduplication y top-k. Si la evidencia es correcta pero cae groundedness, revisa context assembly, instruction hierarchy, claim scope y citation generation. Si groundedness es alto pero el answer score es bajo, el problema puede ser un corpus incompleto o una task rubric mal alineada.

Cambia un solo factor controlado por experimento y conserva retrieved snapshots para comparación pareada. Si cambias chunking, embedding model y prompt al mismo tiempo, no podrás explicar improvement o regression. Los resultados por segmento importan más que la media del portfolio: las mejoras en FAQ sencillas no deben ocultar deterioro en ACL, no-answer o queries multilingües.

• Evidencia no encontrada → investigar ingestion, query, filter, embedding o retrieval.
• Evidencia con rank bajo → investigar reranking, hybrid weights, deduplication o top-k.
• Contexto respaldado, claim sin soporte → investigar generation, context assembly o judge.
• Respuesta correcta, cita errónea → tratar citation alignment como defecto independiente.
• Buen score offline, mal resultado en producción → investigar dataset drift o rubric mismatch.

En CI ejecuta métricas deterministas de retrieval contra un corpus snapshot fijado y graders basados en modelos con versiones, prompts y retry policy fijados. El gate puede exigir cero fugas críticas de ACL, no-answer false confidence por debajo de un umbral acordado, non-regression en slices clave y límites de latencia y coste. Define thresholds concretos a partir del baseline y del risk appetite de tu sistema; no existe un número seguro universal.

Tras el canary recopila traces compatibles con privacidad, correcciones de usuarios, aperturas de citas, retrieval vacío y resultados de escalation, pero no trates un clic implícito como prueba de correctness. El sampling envía casos difíciles a review y los fallos confirmados vuelven al conjunto de evaluación. Rollback restaura las versiones anteriores de corpus, retriever, reranker y prompt como un bundle coordinado. El audit debe mostrar qué dataset, código, datos y graders autorizaron el release.