Modelos de lenguaje (LLM)

Evaluación de RAG (RAGAS, retrieval metrics)

La evaluación de RAG es el conjunto de métricas y procesos para medir la calidad de un sistema de Retrieval-Augmented Generation. Cubre dos dimensiones: la calidad del recuperador (¿se encuentran los fragmentos relevantes?) y la calidad de la generación (¿la respuesta usa bien lo recuperado?). Frameworks de referencia en 2026: RAGAS, Ragas, ARES, TruLens, DeepEval.

Por Ana María González Actualizado: 9 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

Un sistema RAG tiene dos componentes que pueden fallar por separado: (1) el recuperador, que busca en el corpus los fragmentos relevantes para la pregunta; (2) el generador (el LLM), que produce la respuesta a partir de esos fragmentos. Métricas de recuperador: hit rate (¿el fragmento correcto está en el top-k?), MRR (mean reciprocal rank, en qué posición media aparece), recall@k, precision@k. Métricas de generación: faithfulness (¿la respuesta es fiel a los fragmentos sin inventar?), answer relevance (¿responde realmente a la pregunta?), context precision (¿los fragmentos usados son relevantes?), context recall (¿se usaron todos los fragmentos relevantes?). RAGAS, el framework más popular, automatiza muchas de estas métricas usando un LLM como juez. La evaluación requiere un dataset de pares pregunta-respuesta-contexto-correcto, que normalmente hay que construir (50-200 ejemplos para arrancar). Sin evaluación, mejorar un RAG es ajustar a ojo: cualquier cambio (chunking, embeddings, reranker, prompt) puede mejorar una cosa y romper otra.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa con un RAG en producción, evaluar es lo que diferencia "está mejor" o "está peor" entre versiones. Sin métricas, las decisiones se toman por percepción (peligrosa). Con métricas, las decisiones son contrastables. La regla práctica: cualquier RAG con más de unos pocos miles de consultas/mes merece un sistema de evals que se ejecute con cada cambio. La inversión inicial son 1-2 semanas de trabajo (dataset + integración de RAGAS o similar) y ahorra meses de iteración a ciegas. Para sistemas RAG sensibles (asesoramiento, soporte técnico, atención cliente), las métricas de faithfulness son especialmente importantes para detectar alucinaciones.

Ejemplo concreto

Caso real

Una empresa de seguros tenía un asistente RAG sobre su documentación de productos. Tras 4 meses recibían quejas dispersas pero no podían diagnosticar la causa. Implementaron RAGAS con dataset de 120 preguntas reales con respuestas expertas. Hallazgos por métrica: hit rate 71% (un 29% de respuestas no recuperaban el fragmento correcto), faithfulness 84% (un 16% de respuestas inventaban detalles no presentes en los fragmentos). Plan correctivo: cambio del modelo de embeddings y añadir reranker (hit rate al 91%); ajuste de prompt para forzar grounding y citas (faithfulness al 96%). Tiempo: 3 semanas. Las quejas cayeron al medirse cuantitativamente y atacar las dos causas principales en lugar de adivinar.