Evaluación RAG en producción: métricas, datasets y gates antes de cambiar tu pipeline

Checklist

Qué problema resuelve la evaluación RAG

RAG promete respuestas con fuentes, pero esa promesa se rompe en varias capas. Puede fallar el chunking, el embedding, el filtro por permisos, el reranker, el prompt, el modelo o el formato de citas. La respuesta final puede sonar razonable aunque la evidencia recuperada sea pobre.

Por eso evaluar RAG como una sola caja negra es cómodo y peligroso. Necesitas separar al menos dos preguntas: `¿recuperé el contexto correcto?` y `¿el modelo usó ese contexto sin inventar?`. Si mezclas ambas, arreglarás prompts cuando el problema era retrieval, o tocarás embeddings cuando el modelo estaba ignorando fuentes buenas.

La evaluación seria no intenta demostrar que el RAG funciona. Intenta encontrar dónde deja de funcionar antes que tus usuarios.

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import Faithfulness, AnswerRelevancy, ContextPrecision, ContextRecall

rows = [
    {
        "question": "¿Cómo se rota una clave de API en producción?",
        "answer": run_rag("¿Cómo se rota una clave de API en producción?").answer,
        "contexts": run_rag("¿Cómo se rota una clave de API en producción?").contexts,
        "ground_truth": "Rotar clave, desplegar secreto nuevo, invalidar el anterior y auditar uso.",
    },
]

dataset = Dataset.from_list(rows)
result = evaluate(
    dataset,
    metrics=[Faithfulness(), AnswerRelevancy(), ContextPrecision(), ContextRecall()],
)

print(result)

MIN_SCORES = {
    "faithfulness": 0.85,
    "answer_relevancy": 0.80,
    "context_precision": 0.70,
    "context_recall": 0.75,
}

for metric, minimum in MIN_SCORES.items():
    score = float(result[metric])
    if score < minimum:
        raise SystemExit(f"RAG regression: {metric}={score:.2f} < {minimum}")

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Puntos a revisar

Lo que conviene comprobar

Context recall pregunta si recuperaste la evidencia necesaria. Es la métrica que detecta el fallo contrario: el modelo responde mal porque el dato correcto nunca llegó al contexto. Si recall cae, tocar el prompt rara vez arregla el fondo.

Faithfulness o groundedness mide si la respuesta está soportada por el contexto. Es el antídoto contra la alucinación con fuentes decorativas. Answer relevancy mide si la respuesta contesta la pregunta. Factual correctness o response completeness comparan contra una referencia cuando existe ground truth.

Checklist

Dataset: empieza pequeño, pero con dientes

Un dataset útil para RAG debe guardar `query`, `expected_answer`, `expected_sources` o qrels, usuario/tenant cuando hay permisos, categoría de pregunta, dificultad y notas de fallo. Si solo guardas pregunta y respuesta, no podrás saber si falló retrieval o generación.

Incluye preguntas negativas: `no lo sé`, documentos inexistentes, términos parecidos, permisos cruzados y datos obsoletos. Un RAG que siempre contesta es más peligroso que uno que sabe negarse.

Cada incidente real debería producir al menos un caso de evaluación. Si soporte reporta una respuesta falsa, no lo cierres solo cambiando prompt. Añade una prueba que falle antes del fix y pase después. Ese hábito convierte producción en fuente de evals, no en un sitio donde repetir errores.

Checklist

Retrieval: mide ranking, no solo similitud

El retrieval no termina en embeddings. También importan filtros, permisos, búsqueda híbrida, reranking, deduplicación, ventanas de contexto y orden final. Un cambio de `top_k=5` a `top_k=12` puede mejorar recall y empeorar faithfulness porque mete ruido que el modelo no sabe ignorar.

Cuando tienes documentos relevantes etiquetados, usa métricas de ranking como recall@k, MRR o NDCG. Cuando no los tienes, usa jueces LLM para estimar relevancia del contexto, pero conserva ejemplos revisables. Un juez sin auditoría puede esconder errores sistemáticos.

Mi regla práctica: antes de cambiar embeddings o reranker, congela 30 consultas y compara exactamente qué documentos entran en el prompt. Si no puedes explicar diferencias de retrieval, todavía no estás haciendo optimización; estás tocando knobs.

Puntos a revisar

Lo que conviene comprobar

Mide coste por dimensión. Retrieval puede degradar por latencia antes de degradar calidad. Un reranker puede subir relevancia y duplicar coste. Un modelo generador mejor puede ocultar retrieval mediocre durante un tiempo. Sin costes por paso, la optimización queda incompleta.

En producción, guarda traces suficientes: query normalizada, filtros aplicados, documentos candidatos, documentos finales, prompt, modelo, respuesta, scores y feedback. Sin trazas, cada bug de RAG se convierte en una discusión subjetiva.

Fuentes y referencias

• Ragas: available metrics
• LangSmith: evaluate a RAG application
• OpenAI API: working with evals
• LlamaIndex: evaluating
• Microsoft Foundry: RAG evaluators
• DeepEval: RAG evaluation guide
• arXiv: Retrieval Augmented Generation Evaluation in the Era of Large Language Models

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.