Frameworks de evaluación para retrieval: Ragas y similares

javi
Herramientas de medición sobre mesa oscura representando evaluación cuantitativa

Construir un sistema RAG es relativamente fácil hoy: embeddings + vector DB + LLM. Medir si funciona bien es el desafío real. ¿Las respuestas son fieles al contexto? ¿El contexto retrieved es relevante? ¿La respuesta responde la pregunta? Ragas (Retrieval Augmented Generation Assessment) es el framework más usado. Este artículo cubre qué métricas importan, cómo integrar Ragas, y las alternativas.

Las métricas que importan

Ragas define cuatro métricas principales:

Faithfulness

¿La respuesta está respaldada por el contexto retrieved?

  • Score 0-1: fracción de claims en respuesta soportados por contexto.
  • Detecta hallucinations (claims inventados).

Answer Relevance

¿La respuesta responde la pregunta?

  • Genera preguntas hipotéticas desde la respuesta, compara con la original.
  • Score alto = responde bien la intent original.

Context Precision

Del contexto retrieved, ¿qué fracción es relevante a la pregunta?

  • Penaliza retrieval con mucho “ruido”.
  • Útil para tuning chunk size y top-k.

Context Recall

¿El contexto retrieved contiene toda la info necesaria para responder?

  • Requires ground truth answer.
  • Detecta cuándo el retrieval “se deja” info importante.

Uso básico de Ragas

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

data = {
    "question": ["¿Qué es RAG?", "¿Qué ventajas tiene?"],
    "answer": ["RAG combina retrieval...", "Menor hallucination..."],
    "contexts": [
        ["RAG (Retrieval Augmented Generation) combina..."],
        ["Las ventajas de RAG incluyen..."]
    ],
    "ground_truth": ["RAG es una técnica...", "Ventajas principales..."]
}

dataset = Dataset.from_dict(data)
result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
print(result)

Ejecuta LLM calls para calcular cada métrica. Usa OpenAI por default pero configurable.

Dataset de evaluación

Construir golden set:

  • Extraer preguntas reales de logs de users.
  • Anotar ground truth con humanos expertos.
  • 50-500 ejemplos es razonable para empezar.
  • Incluir edge cases: preguntas ambiguas, out-of-scope, multi-step.

Dataset de calidad es el activo más valioso para evaluación iterativa.

Integración en CI

Objetivo: detectar regresiones cuando cambias prompts, modelos, chunking.

# .github/workflows/rag-eval.yml
- name: Evaluate RAG
  run: |
    python evaluate.py --threshold-faithfulness 0.8
# evaluate.py
results = evaluate(dataset, metrics=[faithfulness])
if results["faithfulness"] < 0.8:
    sys.exit(1)

Thresholds from historical baseline. Un cambio que baja faithfulness 10% = red flag.

Alternativas a Ragas

TruLens:

  • Similar métricas + triad (context_relevance, groundedness, answer_relevance).
  • Dashboard web built-in.
  • Integración fuerte con LangChain.

DeepEval:

  • Framework pytest-like.
  • Métricas custom fáciles.
  • Integración CI/CD.

Giskard:

  • RAG eval + seguridad + bias.
  • Comercial con free tier.

Arize Phoenix:

  • Observability para LLM apps incluyendo eval.
  • Open source + SaaS.

Cada uno tiene focos distintos. Ragas es el más directo para RAG quality.

LLM como judge

La mayoría de frameworks usan LLM (GPT-4 típicamente) para juzgar:

  • Ventaja: escalable, múltiples facetas.
  • Desventaja: bias del juez, coste, non-determinismo.

Mejoras emergentes:

  • Small LLMs fine-tuned como evaluadores (más baratos).
  • Consenso multi-LLM (3 modelos votan).
  • Human-in-the-loop periodic validation.

Métricas vs humanos

No confíes solo en LLM-as-judge. Periódicamente:

  • Revisión humana de 50-100 respuestas.
  • Compara con métricas automáticas.
  • Ajusta thresholds si diverge.

Métricas son proxy; humano es ground truth.

Casos donde falla evaluación

  • Dataset no representativo: métricas buenas en test, malas en prod.
  • Overfitting al evaluator: prompts optimizados para LLM-judge, no usuario.
  • Métricas no alineadas con negocio: score alto ≠ cliente feliz.
  • Gaming metrics: si el sistema optimiza solo la métrica.

Ragas en producción

Patrones:

  • Pre-deploy evaluation: eval dataset en CI.
  • Production sampling: eval 1% de queries reales.
  • A/B testing: comparar versiones con mismo dataset.
  • Drift detection: alertar si métricas bajan en tiempo.

Cost considerations

Evaluar con GPT-4 es caro:

  • 500 preguntas × 4 métricas × 2-3 LLM calls = ~6000 calls.
  • A ~$0.01-0.05 per call = $60-300 por eval full.

Estrategias:

  • Subset mode: 50 preguntas por CI, full en releases.
  • Cheaper evaluator: GPT-4o mini para mayoría, GPT-4 para critical.
  • Cache: resultados persisten mientras dataset y modelo no cambien.

Semántica más allá de Ragas

Además de metrics tradicionales:

  • Citation quality: ¿la respuesta cita las fuentes bien?
  • Reasoning steps: ¿chain-of-thought válida?
  • Safety: ¿la respuesta es safe?
  • Factual accuracy: con external knowledge base.

Ragas incluye algunas; otros frameworks (Giskard) tienen más énfasis en safety.

Conclusión

Evaluar RAG con rigor es diferencia entre sistema que “funciona en demo” y “funciona en producción”. Ragas ofrece métricas estándar con implementación accesible. TruLens, DeepEval y Giskard son alternativas válidas con distintos focos. Construir dataset propio representativo es el activo más valioso — las herramientas son baratas, el dataset no. Integrar evaluación en CI desde día 1 paga dividendos: detecta regresiones antes de producción, permite iteración basada en datos, y da credibilidad al sistema ante stakeholders.

Síguenos en jacar.es para más sobre RAG, evaluación de LLMs y observabilidad AI.

Entradas relacionadas