Cómo evaluar un sistema RAG: métricas, fidelidad y monitorización

Evaluar un sistema RAG exige medir dos cosas por separado: si la recuperación trae los fragmentos correctos (recall@k, MRR) y si la respuesta generada es fiel a esos fragmentos y cita bien las fuentes. Sin un conjunto de preguntas reales y una monitorización continua, un RAG que parece funcionar perfectamente en la demo puede fallar en producción sin que nadie se entere durante semanas. Esta guía le muestra qué medir, cómo construir el conjunto de test y qué vigilar una vez el sistema está en manos de usuarios reales.

Por qué no basta con que la respuesta «suene bien»

Un sistema RAG tiene dos etapas con dos tipos de fallo completamente distintos. La primera es la recuperación: el motor de búsqueda puede traer fragmentos irrelevantes aunque el modelo genere una respuesta elocuente con ellos. La segunda es la generación: el modelo puede recibir los fragmentos correctos y aun así inventar datos, mezclar cifras de dos documentos o afirmar algo que el texto no dice. Evaluar solo el resultado final («¿la respuesta parece correcta?») esconde cuál de las dos etapas está fallando y le impide arreglarla. Para entender dónde encaja cada pieza del proceso conviene repasar primero cómo funciona RAG paso a paso: cada etapa necesita su propia métrica.

Métricas de recuperación: recall@k y MRR

Antes de juzgar la respuesta final hay que comprobar si el motor de búsqueda hace bien su trabajo: traer, entre los primeros k resultados, los fragmentos que realmente contienen la información necesaria. Las dos métricas de referencia son recall@k y MRR (mean reciprocal rank).

• Recall@k: de todos los fragmentos relevantes que existen para una pregunta, qué proporción aparece entre los k primeros resultados recuperados. Un recall@5 del 80% significa que, en promedio, 8 de cada 10 fragmentos relevantes están entre los 5 primeros.
• Precision@k: de los k fragmentos recuperados, qué proporción es realmente relevante. Útil cuando el ruido en el contexto confunde al modelo generador.
• MRR (mean reciprocal rank): la media de 1 dividido entre la posición del primer resultado relevante. Penaliza con fuerza que el fragmento correcto aparezca en el puesto 8 en lugar del puesto 1.

Cómo calcular recall@k con un conjunto de referencia

Necesita un conjunto de pares pregunta-fragmento relevante marcado a mano por alguien que conozca los documentos. Para cada pregunta, ejecute la búsqueda, tome los k primeros resultados y compruebe si el fragmento marcado como relevante está entre ellos. Promedie el resultado sobre todas las preguntas del conjunto. Esta métrica depende directamente del motor de búsqueda: un sistema que combina palabras clave y vectores suele recuperar mejor expresiones exactas (referencias legales, códigos de producto, nombres propios) que uno puramente semántico. Si el recall@k es bajo, revise primero cómo funciona la búsqueda híbrida entre palabras clave y vectores antes de tocar el modelo de generación.

MRR: cuándo importa el orden

Si su sistema solo pasa al modelo los 3 o 4 primeros fragmentos (por coste o por límite de contexto), el orden importa tanto como la presencia del fragmento correcto. Un MRR bajo con un recall@10 alto indica que el fragmento relevante existe pero aparece demasiado abajo: el problema no es la cobertura del índice, es el ranking. En ese caso conviene ajustar los pesos entre búsqueda léxica y semántica o revisar el tamaño de los fragmentos, porque trozos demasiado largos o mal cortados diluyen la señal de relevancia. La forma en que se dividen los documentos influye directamente aquí: conviene repasar las estrategias de chunking para RAG si el MRR no mejora al ajustar solo el motor de búsqueda.

Fidelidad de la respuesta (faithfulness): ¿se sostiene en lo recuperado?

La fidelidad (faithfulness) mide algo distinto de la corrección factual: no si la respuesta es verdad en el mundo real, sino si cada afirmación de la respuesta puede justificarse con los fragmentos que se le entregaron al modelo. Un modelo puede generar una respuesta objetivamente correcta pero infiel (porque la sabía de memoria y no del contexto) o una respuesta fiel pero incorrecta (porque el documento fuente tenía un error). Para un sistema RAG en producción, la fidelidad es la métrica que de verdad protege contra las alucinaciones de la IA, porque obliga a que el modelo no rellene huecos con conocimiento externo.

La forma más fiable de medirla sigue siendo la revisión manual con una rúbrica simple, aplicada a una muestra de respuestas cada semana:

• Cada afirmación concreta de la respuesta (cifra, fecha, condición, nombre) tiene un respaldo literal en el pasaje citado.
• El modelo no añade matices, condiciones o excepciones que no aparecen en el texto fuente.
• Cuando el documento es ambiguo, la respuesta refleja esa ambigüedad en lugar de resolverla por su cuenta.
• Si los fragmentos recuperados no contienen la información pedida, el sistema responde que no puede contestar en lugar de inventar algo plausible.

Usar un modelo de lenguaje como juez automático (LLM-as-judge) acelera el proceso para volúmenes grandes, pero conviene calibrarlo contra revisión humana en una muestra periódica: los jueces automáticos tienden a ser indulgentes con respuestas bien redactadas aunque poco fieles.

Precisión de las citas: que la fuente citada diga lo que afirma la respuesta

La precisión de las citas es un fallo distinto y más sutil que la falta de fidelidad: la respuesta puede ser correcta y fiel al contexto, pero citar el fragmento equivocado (uno que habla del mismo tema pero no contiene el dato concreto). Para el usuario esto es grave porque pierde la capacidad de verificar la respuesta: hace clic en la cita, lee el pasaje y no encuentra lo que se le afirmó. Evaluar esto exige comprobar, fragmento por fragmento, que el texto citado contiene literalmente el dato que respalda. Es el mismo criterio que debería aplicar cualquier persona que recibe una respuesta con fuentes antes de confiar en ella: puede repasar el método completo en cómo verificar una respuesta de IA con fuentes citadas. Un sistema como Kopik, que siempre devuelve el pasaje exacto usado para generar la respuesta (o permite trabajar en modo «solo pasajes» sin generación), facilita mucho esta comprobación porque separa claramente qué se recuperó de qué se afirmó.

Construir un conjunto de test con preguntas reales

Las preguntas inventadas por quien construye el sistema tienden a parecerse demasiado al vocabulario de los propios documentos, lo que infla artificialmente las métricas. Un conjunto de test útil se construye con preguntas que la gente hace de verdad, con sus errores de redacción, su vocabulario coloquial y sus ambigüedades.

1. Recoja entre 50 y 150 preguntas reales de tickets de soporte, buscador interno, correos o entrevistas con quienes usan los documentos a diario.
2. Para cada pregunta, marque a mano el fragmento o los fragmentos que deberían responderla (el «ground truth» contra el que se calcula recall@k y MRR).
3. Clasifique las preguntas por tipo: factuales directas, comparativas, que requieren combinar varios documentos, y preguntas fuera de alcance que no deberían tener respuesta en la base.
4. Incluya deliberadamente preguntas trampa (fuera de alcance) para medir si el sistema reconoce cuando no sabe, en lugar de inventar.
5. Vuelva a ejecutar todo el conjunto cada vez que cambie el chunking, el prompt, el modelo o añada documentos nuevos, y guarde el histórico de resultados para detectar regresiones.

Monitorización continua en producción

El conjunto de test se queda anticuado en cuanto los documentos cambian, llegan usuarios nuevos o se añade una categoría de preguntas que nadie previó. Por eso la evaluación puntual debe completarse con una monitorización continua sobre tráfico real.

Cuando una métrica se deteriora, conviene revisar primero si se han añadido documentos nuevos que cambian el equilibrio del índice, o si el tipo de preguntas de los usuarios ha evolucionado hacia un terreno que el conjunto de test original no cubría. En ambos casos, la solución no es ajustar el prompt a ciegas sino ampliar el conjunto de referencia con los casos nuevos que están fallando.

Empezar a medir sin montar un equipo de MLOps

No hace falta una infraestructura compleja para aplicar estos principios. Puede empezar con una hoja de cálculo: una columna con la pregunta, otra con el fragmento esperado, otra con lo que devolvió el sistema y una última con una marca de sí o no para fidelidad y para precisión de la cita. Lo importante no es la herramienta sino la disciplina de repetir la medición cada vez que algo cambia. Herramientas que ya separan recuperación y generación, devuelven pasajes citados y permiten consultar vía API facilitan mucho automatizar este proceso, porque puede comparar programáticamente la respuesta y la cita contra su conjunto de referencia en cada despliegue.

Preguntas frecuentes