En un cliente del sector energético desplegamos RAG sobre normas técnicas y directrices operativas. Tras las dos primeras semanas en producción, los operarios reportaban que el sistema «a veces responde bien, a veces no». Al investigar más de cerca, resultó que el problema tenía dos causas completamente distintas: en algunos casos el retrieval cargaba documentos incorrectos — la respuesta correcta existía en la knowledge base, pero el sistema no la encontraba. En otros casos el retrieval funcionaba bien, pero el modelo generativo ignoraba el contexto cargado y alucinaba su propia respuesta. Desde el punto de vista del usuario, ambos errores tenían el mismo aspecto. Sin métricas no éramos capaces de distinguirlos.
Este es el núcleo del problema con la evaluación de sistemas RAG: retrieval y generation son dos componentes distintos, cada uno puede fallar por razones diferentes, y si los medimos conjuntamente perdemos la capacidad de diagnosticar. Este artículo describe cómo abordarlo — por separado, de forma sistemática, con las herramientas que existen para ello.
Por qué las métricas clásicas no son suficientes
El primer instinto al evaluar un sistema RAG es preguntarse: «¿Es correcta la respuesta?» Y medirlo manualmente o mediante una comparación simple con el resultado esperado. Este enfoque tiene un problema fundamental: no te dice *dónde* falló el pipeline.
Imagina tres escenarios:
- El retrieval cargó el documento correcto, el modelo respondió correctamente a partir de él — buen resultado.
- El retrieval cargó el documento incorrecto, el modelo respondió de forma coherente a partir de él — mal resultado, pero faithfulness es alta (el modelo no alucinó, solo tenía un contexto incorrecto).
- El retrieval cargó el documento correcto, el modelo lo ignoró y alucinó — mal resultado, faithfulness es baja.
Tres escenarios distintos, dos lugares de fallo diferentes, un síntoma común: respuesta incorrecta. Si solo mides el resultado final, corriges el retrieval y descubres que la generación sigue alucinando — o viceversa.
Por eso la evaluación moderna de RAG divide la medición en dos capas: métricas de retrieval (context precision, context recall) y métricas de generation (faithfulness, answer relevancy). Y esta es precisamente la filosofía detrás de la herramienta RAGAS.
RAGAS — qué es y qué no es
RAGAS (Retrieval-Augmented Generation Assessment) es un framework de evaluación open-source que mide la calidad de un pipeline RAG sin necesidad de anotaciones manuales para cada caso. En su lugar utiliza el enfoque LLM-as-judge: un enunciado o afirmación es evaluado por otro modelo de lenguaje.
Qué es RAGAS: un framework para la evaluación offline de pipelines RAG mediante un dataset de gold standard (denominado golden set). Le proporcionas preguntas, respuestas de referencia, los contextos cargados por tu retrieval y las respuestas generadas — y calcula cuatro métricas clave.
Qué no es RAGAS: monitorización de producción en tiempo real, sustituto de la evaluación completa de una aplicación LLM, ni herramienta para medir la corrección factual de la knowledge base en sí misma. Si tus documentos contienen información incorrecta, RAGAS no lo detectará — mide consistencia y relevancia, no la veracidad de las fuentes.
Distinción importante frente a otros tipos de evaluación: RAGAS se centra exclusivamente en el componente RAG. Si quieres medir la calidad de la respuesta LLM independientemente del retrieval, o evaluar un modelo fine-tuned, usas otras métricas — estas pertenecen a un ámbito de evals separado. Del mismo modo, la evaluación de fine-tuning (por ejemplo, medir si el fine-tuning ayudó) es una disciplina distinta a la evaluación RAG.
Las cuatro métricas clave de RAGAS
Context Precision
Context precision mide si los documentos que devolvió el retrieval son realmente relevantes para la pregunta formulada. Concretamente: ¿qué parte del contexto cargado es útil para generar la respuesta correcta?
Una context precision alta significa que el retrieval no devuelve ruido — cada chunk cargado contribuye a la respuesta. Una context precision baja indica que el sistema está cargando demasiados documentos no relacionados, lo que degrada la calidad de la generación (el LLM debe orientarse a través de material relevante e irrelevante simultáneamente).
En la práctica: si tienes una context precision baja, el problema suele estar en el modelo de embedding, en una segmentación de documentos deficiente (chunking), o en la configuración del top-K (estás cargando demasiados documentos). Más sobre la selección y configuración de los componentes de retrieval encontrarás en el artículo sobre búsqueda híbrida.
Context Recall
Context recall es la métrica complementaria: ¿qué parte de la información necesaria para la respuesta correcta se encuentra en el contexto cargado? Se mide contra la respuesta de referencia del golden set.
Si el context recall es bajo, el retrieval se está perdiendo documentos relevantes — la información existe en la knowledge base, pero el sistema no la encuentra. Las causas habituales son: calidad insuficiente del modelo de embedding para el idioma o dominio concreto, chunking deficiente (la información está dividida en múltiples fragmentos y ninguno de ellos por sí solo es suficiente), o un K demasiado pequeño (cargas solo el top-3, por ejemplo, pero el documento relevante quedó en la posición 7).
Faithfulness
Faithfulness mide en qué medida la respuesta generada está respaldada por el contexto cargado. RAGAS lo hace descomponiendo la respuesta en afirmaciones individuales y verificando para cada una si está explícita o implícitamente respaldada en el contexto.
Esta es la métrica más importante desde el punto de vista de la fiabilidad de un sistema RAG. Una faithfulness baja significa que el modelo alucina — genera información que está ausente en el contexto cargado pero suena plausible. Es fundamental comprender: faithfulness ≠ corrección factual. Un modelo puede ser perfectamente faithful (el 100 % de la respuesta está respaldado por el contexto), pero el propio contexto puede ser incorrecto. Si quieres medir la precisión factual, debes gestionar la calidad de la knowledge base por separado.
Una faithfulness baja se corrige típicamente a nivel del system prompt (instrucciones para que el modelo responda exclusivamente desde el contexto), en la elección del modelo (algunos modelos son más consistentes siguiendo instrucciones), o añadiendo una capa de guardrails. Más sobre guardrails para agentes de IA, incluidas las comprobaciones de faithful-answer, encontrarás en el artículo sobre guardrails para agentes de IA.
Answer Relevancy
Answer relevancy evalúa si la respuesta realmente aborda la pregunta formulada. RAGAS lo mide generando de forma retroactiva varias preguntas hipotéticas a partir de la respuesta generada y verificando si son similares a la consulta original.
Una answer relevancy baja puede darse incluso con una faithfulness alta: el modelo puede ser fiel al contexto pero responder a una pregunta diferente a la formulada — típicamente cuando el contexto es vago o cuando el system prompt no es suficientemente directivo. En la práctica, esta métrica revela problemas con el prompting y la formulación de las preguntas.
Golden set — la base de toda evaluación
Las métricas de RAGAS son tan buenas como el dataset sobre el que las calculas. El gold standard (golden set) es un conjunto de casos de prueba con el formato:
- Pregunta — consulta real o representativa
- Respuesta de referencia — respuesta correcta verificada (ground truth)
- Contexto cargado — documentos devueltos por tu retrieval para esa consulta
- Respuesta generada — salida de tu sistema RAG
El problema es que construir un golden set tiene un coste: típicamente 100–300 casos para una evaluación básica, 500–1 000 para una más robusta. La creación manual de cada caso por un experto de dominio es lenta y cara.
Aquí entran en juego dos estrategias:
Generación sintética del golden set: RAGAS y otras herramientas incluyen funciones para generar automáticamente preguntas de prueba directamente desde tus documentos. El LLM lee un fragmento, genera una pregunta y una respuesta de referencia. Ventaja: velocidad y escalabilidad. Desventaja: las preguntas sintéticas pueden ser demasiado simples o no corresponderse con las consultas reales de los usuarios. En la práctica recomendamos mezclar: 60–70 % de casos sintéticos como base, 30–40 % de consultas reales de logs de producción anotados por un experto.
Extracción de logs de producción: cuando el sistema RAG está en producción, guardas pares (pregunta, respuesta). La selección de casos representativos, la anotación con feedback de usuarios (thumbs up/down) o de expertos de dominio — y tienes un golden set realista basado en el uso real.
Principio importante: el golden set debe mantenerse vivo. Cuando la knowledge base se actualiza, parte de los casos de prueba queda obsoleta. En actualizaciones importantes de la documentación, verifica siempre si el golden set sigue reflejando el estado actual.
RAGAS en la práctica — integración en el pipeline
RAGAS es una librería Python que se integra fácilmente en un workflow RAG existente. El caso de uso básico funciona así: para cada caso de prueba del golden set, llamas a la evaluación con la pregunta, la respuesta de referencia, el contexto cargado y la respuesta generada. El resultado son puntuaciones para cada métrica, tanto agregadas como por caso individual.
Lo que es importante saber antes del despliegue:
Coste: RAGAS llama internamente a un LLM para el cálculo de métricas (LLM-as-judge). Para un golden set de 200 casos puedes esperar cientos o miles de llamadas LLM, lo que con modelos frontier representa costes no despreciables. En la práctica se recomienda usar un modelo más pequeño y económico para la función de juez (por ejemplo, tier Haiku/Flash), o donde sea posible, un modelo open-weight local. El cálculo de faithfulness es especialmente intensivo en tokens, ya que descompone la respuesta en afirmaciones.
Evaluación cadenciada, no solo ad-hoc: la evaluación tiene sentido como proceso regular — con cada cambio en el componente de retrieval, actualización de la knowledge base, o ajuste de prompts. Recomendamos incorporar la evaluación RAGAS al pipeline CI/CD al menos como sanity check sobre un subconjunto del golden set antes de cada despliegue.
Interpretación de cifras absolutas: una puntuación de 0,80 para faithfulness no es objetivamente buena ni mala — depende del caso de uso. Para documentación médica, 0,80 es insuficiente. Para un helpdesk interno puede ser suficiente. Lo que importa son las tendencias: si tras ajustar el prompt la faithfulness cayó de 0,85 a 0,72, tienes una señal clara.
Separar la eval de retrieval de la eval de generation
Una práctica clave que vemos infrautilizada: la eval del componente de retrieval y la eval del componente de generation deben realizarse también de forma independiente, no solo a través del end-to-end de RAGAS.
Eval de retrieval por separado: puedes evaluar el retrieval sin ninguna generación LLM. Para cada pregunta de prueba sabes qué documentos debería idealmente encontrar el retrieval (del golden set). Mides precision@K y recall@K — cuántos de los documentos relevantes terminaron en los top-K resultados. Esto te da una señal limpia sobre la calidad del modelo de embedding, la estrategia de indexación y la configuración de búsqueda — sin que el modelo generativo oculte los problemas o compense los errores del retrieval.
Eval de generation por separado: puedes fijar el contexto — en lugar de documentos cargados dinámicamente, le das al modelo siempre el mismo contexto verificado manualmente — y medir solo faithfulness y answer relevancy. Esto prueba de forma aislada la capacidad del modelo para seguir instrucciones y extraer información del texto proporcionado.
La combinación de ambas perspectivas con las métricas end-to-end de RAGAS ofrece una imagen completa de dónde exactamente pierde calidad el pipeline.
Lo que RAGAS no mide — y en qué hay que tener cuidado
RAGAS es una herramienta poderosa, pero tiene límites que hay que conocer explícitamente.
Corrección factual de la knowledge base: como hemos mencionado, RAGAS mide la consistencia de la respuesta con el contexto. Si los documentos de la knowledge base contienen información desactualizada o incorrecta, RAGAS no lo detectará. La calidad de la knowledge base debe gestionarse por separado — mediante revisión de dominio, datación de documentos y mecanismos de actualización.
Latencia y costes en producción: RAGAS es una herramienta de evaluación offline. No te dirá cómo se comporta el pipeline bajo un alto volumen de consultas, cuál es la latencia real para el usuario, ni cuáles son los costes de tokens en producción. Para estas métricas necesitas monitorización de producción — herramientas como LangSmith, Langfuse, o una capa de logging propia. Sobre la observabilidad de agentes de IA y la monitorización de producción escribimos con más detalle en el artículo sobre observabilidad de agentes de IA.
Propiedades de seguridad: RAGAS no mide la resistencia frente a prompt injection, la capacidad del sistema para rechazar consultas inapropiadas, ni el cumplimiento de los guardrails de seguridad. Esto pertenece a la security eval, que es una disciplina separada.
Calidad lingüística y registro: si tus usuarios se comunican en español y la knowledge base está en inglés, la puntuación de RAGAS no te dice nada sobre la calidad de la traducción o la naturalidad de las respuestas en español. Si trabajas con un setup multilingüe, necesitas evaluación humana de la calidad lingüística.
Preguntas frecuentes
¿Cuántos casos necesito en el golden set para obtener resultados fiables?
Para un primer baseline, 50–100 casos son suficientes para hacerse una idea. Para decisiones como «cambiar el modelo de embedding» o «ajustar la estrategia de chunking» recomendamos 200–400 casos que cubran distintos tipos de preguntas y partes de la knowledge base. Por debajo de 50 casos los resultados son demasiado sensibles a outliers individuales.
¿Puedo usar RAGAS para monitorización de producción en tiempo real?
No directamente — cada medición de RAGAS cuesta llamadas LLM, lo que es demasiado caro para cada consulta de producción. El enfoque típico es el muestreo: en lugar de medir cada consulta, tomas un sample aleatorio del 1–5 %, ejecutas la evaluación RAGAS de forma asíncrona y observas tendencias en el tiempo. Para la monitorización en tiempo real en producción son más adecuadas señales más simples: feedback thumbs up/down de los usuarios, latencia, número de respuestas de fallback.
¿Cómo sé si el problema está en el retrieval o en la generation?
El test más sencillo: copia manualmente el documento relevante directamente en el contexto (saltándote el retrieval) y envíaselo al modelo. Si la respuesta es buena, el problema está en el retrieval. Si incluso con un contexto perfecto el modelo alucina o responde de forma irrelevante, el problema está en la capa de generation — en el prompt, en el modelo, o en la forma en que formateas el contexto. Este test manual es más rápido que una eval completa y detecta la mayoría de los problemas en minutos.
¿Es fiable el LLM-as-judge? ¿No puede evaluar de forma errónea?
El LLM-as-judge tiene sus propios puntos ciegos — por ejemplo, valora más las respuestas largas aunque sean menos precisas, o da preferencia a estilos cercanos a los datos de entrenamiento del modelo juez. RAGAS lo compensa parcialmente descomponiendo faithfulness en afirmaciones concretas y verificando cada una por separado. Para casos de uso críticos (sectores regulados, sistemas con sensibilidad de seguridad) recomendamos combinar la evaluación automática con revisión humana al menos para un subconjunto de casos.
¿Qué modelo usar como juez en RAGAS?
Para la mayoría de los casos es suficiente un modelo frontier de nivel medio (tier Sonnet/Flash/Haiku) — es suficientemente preciso y significativamente más económico que el nivel máximo. Si tienes requisitos on-prem o datos sensibles, RAGAS admite también modelos locales a través de la API compatible con OpenAI — un modelo open-weight potente de la familia Qwen3 o Llama en inferencia con vLLM funciona bien para tareas de judgment.
*Si dudas por dónde empezar con la evaluación de tu sistema RAG, o quieres comprobar dónde exactamente pierde precisión tu pipeline — en MP Industrial Solutions realizamos diagnósticos de despliegues RAG y ayudamos a establecer un proceso de evaluación que genera resultados accionables, no solo cifras.*