Ragas: evalúa tu RAG con honestidad en vez de medirlo a ojo

Pregúntale a cualquiera que tenga un sistema con recuperación aumentada en producción cómo sabe que funciona, y casi siempre vas a oír alguna versión de "probé unas cuantas preguntas y se sintió mejor". Eso no es una medición, es una corazonada, y las corazonadas no aguantan un cambio de tamaño de chunk, un embedder nuevo, ni un ajuste de prompt que hiciste a las 11 de la noche. Ragas es una librería open-source que convierte ese "se siente mejor" en un delta que puedes defender, puntuando tu pipeline RAG con métricas como fidelidad y precisión del contexto, casi todas calculadas por un LLM que actúa de juez. Aquí va qué es en realidad, cuándo se gana su lugar frente a las alternativas, un quickstart listo para pegar, y las concesiones de calificar un modelo con otro modelo.

01 · Qué es en realidad

Ragas calcula métricas sobre un dataset en el que cada fila es una pregunta junto con los artefactos que tu pipeline produjo para ella: la pregunta, los contextos recuperados, la respuesta generada y, para algunas métricas, una referencia (la respuesta de ground-truth). No le pasas tu código; le pasas los resultados, y él los puntúa.

Las métricas se dividen en dos familias, y ahí está toda la gracia:

• Métricas de generación juzgan la respuesta contra el contexto que recibió. La fidelidad pregunta si cada afirmación de la respuesta de verdad está respaldada por el contexto recuperado (la métrica anti-alucinación). La relevancia de la respuesta pregunta si la respuesta de verdad responde la pregunta en vez de irse por las ramas.
• Métricas de recuperación juzgan el contexto en sí. La precisión del contexto pregunta si los chunks relevantes quedaron rankeados cerca del tope. El recall del contexto pregunta si el contexto traía todo lo necesario para responder, lo que exige una referencia con la cual comparar.

A casi todas las calcula un LLM juez: Ragas le pide a un modelo que descomponga la respuesta en afirmaciones, verifique cada una contra el contexto y devuelva una puntuación. Unas pocas se basan en embeddings. En cualquier caso, no estás escribiendo la rúbrica desde cero, Ragas trae los prompts y la agregación ya hechos.

Esa división en dos familias es justo lo que hace que Ragas le gane a una sola puntuación de punta a punta del tipo "¿esta respuesta es buena?". Una puntuación general baja te dice que algo se rompió; la descomposición te dice dónde.

02 · Por qué importa: separar recuperación de generación

Lo más útil que hace Ragas es que dejas de mezclar dos fallas completamente distintas. Cuando una respuesta de RAG sale mal, sale mal por una de dos razones, y cada una pide un arreglo opuesto:

1. Falló la recuperación. El chunk correcto nunca llegó al contexto, así que el modelo respondió sin nada en la mano, o alucinó para tapar el hueco. Ningún ajuste de prompt arregla esto; arreglas el chunking, los embeddings, el reranker o el top-k.
2. Falló la generación. El contexto correcto sí estaba ahí, pero el modelo lo ignoró, lo leyó mal o metió afirmaciones sin respaldo. Ningún cambio en la recuperación arregla esto; arreglas el prompt, el modelo o cómo se formatea el contexto.

Sin métricas, las dos se ven iguales desde afuera, una mala respuesta es una mala respuesta y punto. Ragas las separa: recall de contexto bajo con fidelidad alta apunta de lleno a la recuperación; recall de contexto alto con fidelidad baja apunta de lleno a la generación.

Me apoyo en esta división todo el tiempo. En la capa de recuperación del CME Platform, una caída de calidad en las respuestas no me dice nada hasta que sé de qué lado de esa línea cayó, y Ragas es lo que me lo dice, en vez de ponerme a releer transcripciones y adivinar.

03 · Cuándo usarlo (y cuándo no)

Usa Ragas cuando:

• Estás por cambiar cualquier cosa en el camino de recuperación, tamaño de chunk, solapamiento, embedder, reranker, top-k, y quieres un delta de antes/después en vez de una corazonada.
• Quieres un gate de CI para que un ajuste de prompt o un bump de dependencia no degrade la calidad en silencio. Corre el set de evaluación en cada cambio y haz fallar el build si una métrica cae por debajo de un umbral.
• Estás comparando opciones, dos embedders, dos rerankers, tres estrategias de chunking, y necesitas un scorecard consistente para decidir.

No lo uses cuando:

• Todavía no tienes un set etiquetado. Ragas sin un dataset real es puro teatro; arma primero el dataset (mira la sección 5).
• Tu pipeline no es RAG. Ragas está pensado para pregunta → contexto → respuesta. Para un agente general o una tarea de clasificación, te encaja mejor una rúbrica simple de LLM-como-juez o un eval específico de la tarea.
• Necesitas un pass/fail sobre una sola respuesta en producción. Ragas es para evaluación offline sobre un set, no un guardrail en tiempo real sobre un solo request, el juez es demasiado lento y demasiado ruidoso para eso.

Cómo se compara

• vs. armar tu propio LLM-como-juez, claro que puedes, y para una sola métrica quizá hasta deberías. Ragas se gana su lugar porque trae prompts de juez ya probados, la lógica para descomponer en afirmaciones y la agregación, para que no estés reinventando "qué significa fidelidad" desde cero. El costo es una dependencia más y algo de opacidad sobre cómo se calcula cada puntuación.
• vs. una plataforma de evals más pesada (DeepEval, TruLens, Phoenix), esas vienen con tracing, dashboards y tipos de prueba más amplios. Ragas es más acotado y ligero: una librería de métricas enfocada que llamas desde un script o un test. Si lo único que quieres son números en CI, ese enfoque acotado es una ventaja, no una carencia.
• vs. revisión humana, los humanos son el ground-truth y la calibración, no el caballito de batalla del día a día. No puedes meter a un humano en CI en cada commit. Usa Ragas para el loop por cada cambio, y a los humanos para verificar de vez en cuando que la métrica sigue pegada a la realidad.

04 · Quickstart

Instálalo junto a lo que ya estés usando para llamar a tu modelo:

pip install ragas

El flujo central es este: armas un dataset de pregunta/contexto/respuesta (más una referencia cuando la métrica la pide), eliges métricas y llamas a «evaluate». Aquí va una corrida mínima que puntúa fidelidad y precisión del contexto sobre un set de evaluación muy pequeño:

from ragas import evaluate
from ragas.dataset_schema import EvaluationDataset, SingleTurnSample
from ragas.metrics import Faithfulness, LLMContextPrecisionWithReference

# Cada sample = una fila de evaluación de la salida de tu pipeline.
samples = [
    SingleTurnSample(
        user_input="¿En qué puerto escucha el proxy?",
        retrieved_contexts=["Traefik escucha en el 443 para tráfico HTTPS."],
        response="El proxy escucha en el puerto 443.",
        reference="443",
    ),
    # ... idealmente ~20 preguntas reales y representativas ...
]

dataset = EvaluationDataset(samples=samples)

result = evaluate(
    dataset=dataset,
    metrics=[Faithfulness(), LLMContextPrecisionWithReference()],
    # Fija el juez de forma explícita, nunca lo dejes flotar a un default.
    # llm=tu_modelo_juez_envuelto,
)

print(result)               # puntuaciones agregadas por métrica
df = result.to_pandas()     # puntuaciones por fila, para leer los fallos

La línea más importante es justo la que descomentas: fija el modelo y la versión del juez de forma explícita. Si el juez por defecto te cambia por debajo, tus puntuaciones se mueven por razones que no tienen nada que ver con tu pipeline, y tu "regresión" en realidad es un upgrade del juez.

05 · El dataset es la parte difícil

Esto es lo que el README no te cuenta bien: Ragas es el 20% fácil. El 80% difícil y valioso es el set de evaluación. Una corrida de métricas sobre un dataset malo te da números muy convincentes que no significan nada.

Arma el set con intención:

1. Usa preguntas reales. Sácalas de queries reales de usuarios, de tickets de soporte, o de las preguntas que tú y tu equipo de verdad le hacen al sistema. Las preguntas sintéticas prueban una distribución de fantasía.
2. Mantenlo pequeño y representativo, y luego hazlo crecer. Veinte preguntas que cubran tus modos de falla reales le ganan a doscientas casi calcadas. Agrega una fila cada vez que descubras una forma nueva en que se rompe, tu set de evaluación debería ir acumulando cada bug pasado como test de regresión.
3. Escribe referencias donde la métrica las pida. El recall del contexto y la precisión basada en referencia necesitan una respuesta de ground-truth o el contexto relevante etiquetado. Esta es la parte tediosa; también es de donde sale la señal.
4. Fija todo. Mismo modelo de juez, misma versión, mismo set de métricas, mismo dataset entre corridas. Un eval que no puedes reproducir no es un eval.

06 · Concesiones honestas

Ragas es genuinamente útil, pero no es una máquina de la verdad, y creer que lo es te va a salir caro:

• El juez es un modelo, así que las puntuaciones traen ruido. La misma respuesta puede sacar 0.82 en una corrida y 0.76 en la siguiente. Corre suficientes muestras para que la señal se imponga sobre esa varianza, y mira con desconfianza los deltas pequeños, un movimiento de dos puntos lo más probable es que sea ruido, no progreso.
• Juzgar cuesta tokens y tiempo. La fidelidad descompone cada respuesta en afirmaciones y verifica cada una, o sea, varias llamadas al juez por cada fila. Unos cientos de filas por varias métricas se traducen en una factura real y un paso de CI lento. Cachea donde puedas y no corras la suite completa en cada commit trivial.
• Una puntuación baja es una invitación a investigar, no un veredicto. Una fidelidad baja puede significar que tu respuesta alucinó, o que el juez leyó mal una respuesta correcta pero escueta. Lee las filas que fallan antes de creerte el número, sobre todo al principio.
• Tienes que calibrar contra humanos. Cada cierto tiempo pon a una persona a calificar un puñado de filas y verifica que el ranking humano y el de Ragas coincidan. Si se separan, tu métrica se despegó de la realidad y tu gate de CI ahora está frenando builds por la razón equivocada.

La disciplina que hace que Ragas valga la pena es aburrida e innegociable: un set real etiquetado, un juez fijo, suficientes muestras para ganarle a la varianza, y un loop de calibración humana. Hazlo bien y la calidad de tu RAG deja de ser una discusión y pasa a ser un número que puedes defender en un PR. Sáltatelo y lo que armaste es una forma muy convincente de mentirte a ti mismo con decimales.