Un RAG que responde bonito puede estar fallando justo donde importa: recuperar evidencia, citar contexto correcto y no inventar. Esta guía baja la evaluación RAG a ingeniería operable.
Evaluación RAG en producción significa medir por separado recuperación, generación, groundedness, completitud, coste y regresiones. Si solo miras si la respuesta suena bien, estás evaluando una demo, no un sistema.
TL;DR
La keyword principal es evaluación RAG producción. La intención de búsqueda en español es práctica: construir un set de pruebas, elegir métricas y poner gates antes de cambiar embeddings, chunking, reranking, prompts o modelos.
Mi postura: el primer dashboard de RAG no debería ser bonito. Debería decirte qué pregunta falló, qué documentos recuperó, qué evidencia faltó, qué parte inventó el modelo y qué cambio del pipeline lo provocó.
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.
El pipeline sano mide componentes, no solo respuestas: dataset, retrieval, generación, jueces, umbrales, trazas y revisión humana de fallos.
La arquitectura mental: dataset, pipeline, jueces y gates
Un sistema de evaluación RAG tiene cuatro piezas. Primero, un dataset con preguntas reales, respuestas esperadas y, cuando se pueda, documentos relevantes. Segundo, una forma reproducible de ejecutar el pipeline contra esas preguntas. Tercero, evaluadores que midan retrieval y respuesta. Cuarto, gates que bloqueen cambios cuando hay regresión.
El dataset no tiene que empezar grande. Prefiero 40 preguntas bien elegidas a 1.000 preguntas sintéticas que nadie revisó. Debe mezclar casos frecuentes, preguntas ambiguas, consultas con permisos, preguntas sin respuesta, cambios recientes y ejemplos donde el RAG haya fallado en producción.
Los gates no deberían exigir perfección. Deberían exigir que no empeores lo que ya funcionaba y que los fallos importantes queden visibles. Un umbral imperfecto con trazas revisables gana a una promesa manual de que alguien revisará respuestas de vez en cuando.
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}")
Métricas que sí separan el problema
Context precision pregunta si los chunks recuperados eran útiles para responder. Es la métrica que castiga meter basura en el prompt. Un top-k lleno de documentos vagamente parecidos puede parecer generoso, pero baja precisión y encarece cada respuesta.
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.
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.
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.
Generación: groundedness no es lo mismo que utilidad
Una respuesta puede ser grounded y mala: cita el contexto correcto, pero no ayuda al usuario. Otra puede ser útil y peligrosa: contesta perfecto, pero añade una afirmación que no estaba en las fuentes. Por eso necesitas varias métricas, no una nota final.
Groundedness mira precisión contra contexto: no inventar fuera de la evidencia. Completeness mira recall contra una respuesta esperada: no omitir partes críticas. Relevance mira si contestas la pregunta. Correctness mira si el contenido coincide con ground truth.
Para decisiones de producto, muestra los fallos con trazas: pregunta, chunks, respuesta, score, razón del juez y diff contra versión anterior. Un número agregado sirve para ver tendencia; el ejemplo concreto sirve para arreglar.
Jueces LLM: útiles, pero no oráculos
Los evaluadores basados en LLM son prácticos porque muchas respuestas no tienen una única cadena exacta. OpenAI Evals, LangSmith, Ragas, LlamaIndex, Microsoft Foundry y DeepEval convergen en la misma idea: define criterios, pasa ejemplos y usa jueces para puntuar dimensiones concretas.
Pero un juez LLM también es un modelo. Debes fijar modelo, temperatura, prompt del juez, versión del dataset y umbrales. Si cambias el juez al mismo tiempo que cambias el RAG, no sabrás si mejoró el sistema o cambió la regla de medición.
Reserva revisión humana para muestras de alto impacto: respuestas con baja confianza, discrepancias entre jueces, cambios grandes en ranking y preguntas de seguridad, privacidad o cumplimiento. La automatización reduce volumen; no elimina responsabilidad.
Cómo poner gates sin bloquear todo el equipo
Divide los gates en tres niveles. En PR, ejecuta un subset pequeño y barato: smoke tests, preguntas críticas y regresiones recientes. En nightly, ejecuta dataset completo con métricas y comparación contra baseline. En producción, monitoriza muestras, feedback de usuario, coste y drift de recuperación.
No uses un único umbral global. Un RAG legal, financiero o de soporte interno puede exigir groundedness muy alta. Un buscador exploratorio puede tolerar más ruido si cita fuentes y deja claro el nivel de confianza.
Los gates deben fallar con información accionable. faithfulness baja no basta. El informe debe decir qué pregunta, qué respuesta, qué chunks y qué cambio introdujo la regresión.
Coste, latencia y evaluación continua
Evaluar también cuesta. Si cada cambio dispara cien llamadas a un juez caro, el equipo acabará saltándose evals. Usa capas: métricas deterministas para retrieval cuando hay qrels, jueces baratos para smoke tests y jueces más fuertes para releases importantes.
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.
Errores comunes que veo en equipos
- Evaluar solo diez preguntas felices porque son las que salen bien en demo.
- Cambiar chunking, embedding, reranker y prompt en el mismo PR.
- Medir respuesta final sin guardar documentos recuperados.
- Usar un juez LLM sin versionar su prompt ni revisar ejemplos fallidos.
- Optimizar answer relevancy mientras context recall está roto.
- No incluir preguntas sin respuesta, permisos, datos caducados y casos hostiles.
- Tratar las citas como HTML bonito en vez de evidencia verificable.
Plan de adopción en cinco días
- Día 1: exporta 40 preguntas reales y clasifícalas por tipo, riesgo y frecuencia.
- Día 2: añade expected answer y fuentes esperadas para los casos donde tengas ground truth.
- Día 3: ejecuta tu pipeline actual y guarda respuesta, chunks, modelo, coste y latencia.
- Día 4: calcula context precision, context recall, faithfulness y answer relevancy; revisa manualmente los diez peores casos.
- Día 5: crea un gate de CI con subset crítico y un informe nightly con dataset completo.
Conclusión
La evaluación RAG no va de encontrar la métrica perfecta. Va de crear una máquina de aprendizaje técnico: cada fallo produce un caso, cada cambio compara contra baseline y cada release sabe qué ganó y qué perdió.
Mi recomendación es empezar menos ambicioso y más disciplinado: dataset pequeño, trazas completas, métricas separadas, gates modestos y revisión humana de fallos. Cuando eso funcione, amplía corpus, jueces y monitorización. El orden contrario produce dashboards bonitos y RAG frágil.
Preguntas frecuentes
¿Qué es evaluación RAG?
Evaluación RAG es el proceso de medir si un sistema retrieval-augmented generation recupera evidencia relevante y genera respuestas correctas, completas y fieles al contexto.
¿Qué métricas usar para RAG en producción?
Empieza con context precision, context recall, faithfulness o groundedness, answer relevancy, correctness cuando tengas referencia, coste y latencia por paso.
¿Necesito ground truth para evaluar RAG?
No siempre. Puedes evaluar relevancia y groundedness con query, contexto y respuesta, pero los casos con ground truth permiten medir recall, completitud y regresiones con más precisión.
¿Ragas, LangSmith, LlamaIndex o DeepEval?
Elige según stack. Lo importante es versionar dataset, criterios, juez y baseline; la herramienta concreta importa menos que la disciplina de evaluación.
¿Cuántas preguntas necesito para empezar?
Con 30-50 preguntas reales y bien etiquetadas puedes detectar fallos importantes. Después amplía con incidentes, logs de búsqueda y casos sintéticos revisados.
¿La evaluación automática reemplaza revisión humana?
No. Reduce volumen y detecta regresiones, pero los fallos de alto impacto siguen necesitando revisión humana y trazas auditables.
Cómo montar una evaluación RAG mínima en producción
- Inventariar casos. Reúne preguntas reales, incidentes, consultas frecuentes, preguntas sin respuesta y casos con permisos.
- Etiquetar evidencia. Añade respuesta esperada y documentos relevantes cuando exista ground truth; marca categoría y riesgo.
- Capturar trazas. Guarda query, filtros, chunks candidatos, chunks finales, prompt, modelo, respuesta, coste y latencia.
- Medir retrieval. Calcula context precision, context recall y ranking cuando tengas documentos relevantes etiquetados.
- Medir respuesta. Evalúa groundedness, answer relevancy, completeness y correctness según el tipo de pregunta.
- Crear baseline. Fija versión de dataset, prompt, modelo, judge y umbrales antes de optimizar.
- Bloquear regresiones. Ejecuta un subset crítico en PR y el dataset completo en nightly o antes de release.
- Cerrar el bucle. Convierte cada fallo real en una prueba nueva y revisa manualmente los casos de alto riesgo.
Regla operativa
Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.
¿Te sirve esto? Cada semana resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos, en español y sin ruido. Suscríbete gratis a DevAI Semanal.
Top comments (0)