Evaluación RAG: comparativa de RAGAS, TruLens y DeepEval

La evaluación RAG es la comprobación sistemática y medible de la calidad de un sistema de Retrieval-Augmented Generation. Responde a dos preguntas distintas: ¿encuentra la recuperación los documentos correctos? ¿Y se basa la respuesta generada fielmente en esos mismos documentos? Sin esta separación no queda claro si una mala respuesta viene de la recuperación o del modelo de lenguaje. Frameworks como RAGAS, TruLens, DeepEval y LangSmith automatizan esta medición con métricas estandarizadas.

• ¿Qué se mide? Cuatro métricas clave: Faithfulness/Groundedness, Answer Relevance, Context Precision y Context Recall.
• ¿Con qué? RAGAS (estándar de facto), TruLens (tríada RAG), DeepEval (estilo Pytest), LangSmith (tracing + evaluación de datasets) y Arize Phoenix (tracing open source).
• ¿Por qué? Sin evaluación se produce una regresión silenciosa de calidad: un cambio en el pipeline empeora las respuestas sin que nadie lo note hasta que los usuarios se quejan.

Por qué un sistema RAG tiene dos fuentes de error

Un sistema RAG puede fallar de dos maneras independientes entre sí. Primero, la recuperación puede entregar contextos equivocados o incompletos, y entonces el modelo no tiene ninguna posibilidad de dar una respuesta correcta. Segundo, el modelo puede alucinar aunque el contexto sea correcto, es decir, hacer afirmaciones que no aparecen en el material recuperado. Este segundo fenómeno se llama context-unfaithful generation: el modelo cita las fuentes, pero en el contenido se aparta de ellas.

Precisamente por eso no basta con una única nota global. La evaluación RAG descompone la calidad en un eje de recuperación y un eje de generación. Solo esta separación hace posible el debugging: si baja Context Recall, hay que optimizar el chunking, los embeddings o la búsqueda híbrida. Si baja Faithfulness con un buen contexto, hay que optimizar el prompt, el citation forcing o los guardrails.

Las cuatro métricas RAG fundamentales

RAGAS mide la calidad de un RAG a través de Faithfulness, Answer Relevancy, Context Precision y Context Recall. Estos cuatro términos son el vocabulario común de todo el sector, aunque algunas herramientas los llamen de otra manera.

Faithfulness / Groundedness (eje de generación)

Mide si cada afirmación de la respuesta está respaldada por el contexto recuperado. Un LLM-as-Judge descompone la respuesta en afirmaciones atómicas y comprueba cada una contra el contexto. El valor es la proporción de afirmaciones respaldadas. Una Faithfulness baja significa alucinación a pesar del RAG, la trampa de confianza más frecuente en sistemas en producción.

Answer Relevance (eje de generación)

Mide si la respuesta contesta realmente a la pregunta planteada, sin irse por las ramas ni quedarse incompleta. Una respuesta puede ser fiel pero irrelevante, por ejemplo cuando expone correctamente un aspecto secundario pero no da en la pregunta central. Por eso ambas métricas deben analizarse siempre juntas.

Context Precision (eje de recuperación)

Mide si los chunks relevantes aparecen en las primeras posiciones de los resultados de recuperación. Una precisión alta significa poco ruido: los pasajes importantes llegan primero. Esto es decisivo, porque demasiado contexto irrelevante provoca el efecto lost in the middle y reduce la calidad de la generación.

Context Recall (eje de recuperación)

Mide si se ha recuperado toda la información necesaria para la respuesta ideal. El recall necesita una respuesta de referencia (ground truth) con la que se comprueba si cada dato necesario estaba en los contextos recuperados. Un recall bajo es un síntoma clásico de un mal chunking o de un modelo de embeddings poco adecuado para el idioma.

Además, los frameworks ofrecen otras métricas como Answer Correctness, Noise Sensitivity (RAGAS) o Hallucination (DeepEval).

Comparativa de herramientas de evaluación RAG

Los siguientes frameworks son las herramientas consolidadas en 2026. Todos funcionan principalmente según el principio LLM-as-Judge: un segundo modelo evalúa la salida.

Situación a octubre de 2026: las versiones y los nombres de las métricas cambian rápido. Los datos sobre RAGAS siguen la documentación de RAGAS de la actual versión 0.4.3 de enero de 2026. Allí la métrica Answer Relevancy también se llama Response Relevancy, y los datasets usan los campos user_input, response, retrieved_contexts y reference. Los ejemplos de RAGAS 0.1 todavía usan question y ground_truth. El paquete trulens-eval se llama solo trulens desde TruLens 1.0. Antes de usarlo en producción, revisa la documentación actual de cada herramienta.

Crear un dataset de evaluación (goldset)

Toda evaluación fiable necesita un goldset, es decir, un dataset curado de preguntas representativas. Cada entrada suele tener cuatro campos:

• user_input: una pregunta real o realista de un usuario
• reference: la respuesta ideal y correcta en cuanto a los hechos (ground truth)
• reference_contexts (opcional): los chunks que respaldan la respuesta
• metadata (opcional): tenant, fuente, nivel de dificultad

Cómo hacerlo en la práctica:

1. Curar manualmente: reúne entre 30 y 100 preguntas reales de logs de soporte, consultas comerciales o departamentos especializados y añádeles respuestas de expertos. La calidad gana a la cantidad.
2. Completar con datos sintéticos: RAGAS y DeepEval ofrecen generadores de test sets que crean automáticamente pares de pregunta y respuesta a partir de tu propio corpus de documentos. Revísalos sin falta a mano mediante muestreo.
3. Prever los casos límite: preguntas cuya respuesta no está en el corpus (el sistema debe responder entonces «no lo sé»), así como preguntas sobre códigos o ID exactos que los embeddings por sí solos suelen pasar por alto.
4. Versionar: el goldset va en el repositorio. Cada cambio queda trazable y los resultados de la evaluación siguen siendo comparables a lo largo del tiempo.

Si no tienes un goldset completo, puedes usar como solución transitoria métricas sin referencia (Faithfulness, Answer Relevancy) más señales implícitas (clics, pulgar arriba/abajo).

Ejemplo concreto: evaluación en el ciclo de desarrollo

Una pyme de la región DACH (Alemania, Austria y Suiza) usa un asistente RAG interno sobre su documentación técnica. El goldset tiene 60 preguntas. La evaluación se ejecuta automáticamente en cada pull request (pseudocódigo):

goldset = load("eval/goldset_v3.json") # 60 Einträge

metrics = [faithfulness, answer_relevancy, context_precision, context_recall]

results = ragas.evaluate(dataset=goldset, metrics=metrics)

assert results["faithfulness"] >= 0.90

assert results["context_recall"] >= 0.80

assert results["answer_relevancy"] >= 0.85

# jede Unterschreitung bricht den Build ab

En el estado inicial, el pipeline da una Faithfulness de 0,88 y un Context Recall de 0,71. Un desarrollador añade un reranker cross-encoder y cabeceras contextuales por chunk. Anthropic cifra el efecto del Contextual Retrieval en una reducción de la tasa de errores de recuperación del 49 %, y del 67 % en combinación con reranking (Anthropic, datos de 09/2024). En el goldset, Context Recall sube después a 0,86 y Faithfulness a 0,93: se cumplen todos los umbrales y el build pasa.

Tres semanas después, alguien reduce top_k de 8 a 3 a modo de prueba. Faithfulness se mantiene estable, pero Context Recall cae a 0,74. La evaluación automatizada bloquea el merge antes de que el empeoramiento llegue a ningún usuario. Ese es justamente el sentido de la evaluación en la CI: hacer visible la regresión silenciosa de calidad.

Faithfulness como guardrail en tiempo de ejecución

La evaluación no termina con el despliegue. La misma medición de Faithfulness sirve como guardrail en tiempo de ejecución: si la puntuación de Faithfulness de una respuesta concreta queda por debajo de un umbral, el sistema se niega a responder o escala el caso a una persona en lugar de entregar una información posiblemente alucinada. Combinado con citation forcing (cada afirmación debe citar un chunk como fuente), esto da una doble protección contra las alucinaciones. El Reglamento de IA de la UE no exige esta técnica. Pero para los sistemas de alto riesgo sí exige un nivel adecuado de precisión (art. 15) y una supervisión humana efectiva (art. 14). El guardrail y el escalado a una persona son una pieza concreta para cumplir ambas cosas.

Para agencias y B2B

Para agencias de marketing y responsables de decisiones B2B, la evaluación RAG marca la diferencia entre un juguete para demos y un sistema de conocimiento listo para producción. Quien vende a un cliente un asistente RAG debería poder demostrar la calidad con cifras, no con anécdotas. Un goldset documentado más un gate de CI con Faithfulness y Context Recall es una promesa de calidad concreta y verificable, y a la vez un elemento diferenciador en el pitch. Blck Alpaca, desde Viena, acompaña a empresas de toda Europa en la creación de pipelines RAG evaluables, desde la curación del goldset y la elección de herramientas hasta la integración de la evaluación en el ciclo de desarrollo. Escríbenos si quieres que tu sistema RAG sea medible.