Construir un sistema RAG es relativamente sencillo en 2024. Decidir si funciona bien es mucho más difícil. Muchos equipos despliegan sistemas que parecen impresionantes en demos internas y decepcionan en producción porque nunca establecieron un proceso riguroso de evaluación. Este artículo cubre cómo medir la calidad de un RAG honestamente, qué métricas usar, cómo construir conjuntos de evaluación y los errores más comunes.
Por qué la intuición engaña
La tentación natural al evaluar un sistema RAG es probar un puñado de preguntas, ver respuestas aparentemente razonables, y declarar éxito. Este enfoque falla por varias razones. Las preguntas que un ingeniero construye para probar son distintas de las que los usuarios reales formularán. Los casos fáciles son sobrerrepresentados. El sesgo de confirmación lleva a interpretar respuestas ambiguas como correctas. La variabilidad entre modelos es alta y una muestra pequeña no la captura.
Sin medición estructurada, el equipo desarrolla mejoras sin saber si mejoran algo. Peor aún, pueden empeorar sin darse cuenta hasta que los usuarios se quejan.
Las cuatro dimensiones clave
La calidad de un RAG no es una métrica única sino una combinación. Las cuatro dimensiones que capturan la mayoría de problemas son las siguientes.
La fidelidad mide si la respuesta está respaldada por el contexto recuperado. Una respuesta puede ser plausible pero contener información que el contexto no soportaba — alucinaciones. Detectar esto requiere comparar cada afirmación de la respuesta con el contexto.
La relevancia de la respuesta mide si la respuesta efectivamente responde la pregunta formulada. Un sistema puede devolver respuestas correctas pero tangenciales al intent del usuario.
La precisión del contexto mide qué fracción del contexto recuperado es realmente relevante para la pregunta. Recuperar cien documentos de los cuales sólo dos son útiles penaliza al generador y genera ruido.
La cobertura del contexto mide si el contexto recuperado contiene toda la información necesaria para responder completamente. Requiere una respuesta de referencia para comparar.
Frameworks como Ragas automatizan el cálculo de estas métricas usando un LLM como juez. TruLens ofrece una visión similar con variaciones. Para empezar, Ragas es punto de entrada pragmático.
Construir un conjunto dorado
El activo más valioso en la evaluación de un RAG no es el framework sino el conjunto dorado — un conjunto cuidadosamente curado de pares pregunta-respuesta que representan casos reales. Construirlo requiere esfuerzo inicial pero paga dividendos.
El punto de partida son los logs reales de usuarios si ya tienes producción. Si es sistema nuevo, entrevistas con usuarios objetivo y expertos de dominio generan las preguntas más realistas. Un conjunto dorado típico tiene entre cien y quinientas preguntas, con cobertura deliberada de casos fáciles, medios, difíciles, ambiguos y fuera-de-alcance.
Para cada pregunta, el conjunto dorado debe incluir la respuesta correcta (curada por humanos) y, opcionalmente, los documentos de la base de conocimiento que deberían recuperarse. Este último detalle permite medir recall del retrieval independiente de la generación.
El mantenimiento del conjunto dorado es actividad continua. A medida que el producto evoluciona y nuevos casos emergen, se añaden preguntas. El conjunto nunca está completo pero debe ser representativo.
LLM como juez: usos y límites
Muchas evaluaciones modernas usan un LLM como juez para calificar respuestas. Es escalable y relativamente barato. Pero tiene limitaciones que conviene entender.
El juez LLM tiene sesgos. Tiende a preferir respuestas más largas, más formales, con estructura más sofisticada. Puede ser demasiado lenient en ciertos errores sutiles que humanos detectarían. Si se usa el mismo modelo tanto para generar como para juzgar, el sesgo es aún mayor.
La mitigación habitual pasa por usar un modelo distinto al generador para juzgar, validar regularmente con muestreo humano, y usar prompts de evaluación cuidadosamente diseñados. Algunos equipos usan varios jueces LLM y promedian — consenso entre tres modelos reduce sesgos individuales.
Nunca conviene usar solo LLM como juez sin validación humana periódica. Un muestreo mensual de cincuenta respuestas revisadas por humano, comparado con el veredicto automático, muestra si el juez está calibrado con realidad.
Evaluación continua en el pipeline
Una vez construido el conjunto dorado y definidas las métricas, la evaluación debe integrarse en el ciclo de desarrollo. Cada cambio de prompt, cada cambio de modelo, cada cambio de chunking debería pasar por la evaluación automatizada antes de merge.
El patrón que funciona en producción incluye umbrales en las métricas clave. Si la fidelidad cae debajo del 0.8, el build falla. Si la relevancia de respuesta cae más de un cinco por ciento respecto a la línea base, alerta. Los umbrales se calibran con datos históricos.
Adicionalmente, muestras de tráfico real en producción deben pasar por evaluación continua — no sólo el conjunto dorado. Esto detecta derivas cuando los usuarios empiezan a formular preguntas fuera de los patrones originalmente anticipados.
Errores comunes
He visto repetirse varios patrones de error. El más frecuente es optimizar métricas que no correlacionan con satisfacción del usuario. Un sistema puede tener fidelidad alta pero respuestas que el usuario percibe como inútiles. La validación con usuarios reales es irremplazable.
Otro error es tener conjunto dorado demasiado fácil. Si el sistema obtiene 95% en todas las métricas pero los usuarios se quejan, el conjunto no captura la dificultad real. Añadir casos difíciles deliberadamente es sano.
También es común no versionar el conjunto dorado con el código. Si el conjunto cambia sin trazabilidad, no se pueden comparar resultados entre versiones del sistema. Git es suficiente.
Coste y tiempo
Evaluar un conjunto de 500 preguntas con un LLM frontier como GPT-4o cuesta entre diez y cincuenta euros por ejecución, dependiendo de la longitud de las respuestas y del número de métricas. Para releases frecuentes, ajustar tamaño del conjunto o usar modelos más baratos en CI diario y el conjunto completo sólo en releases.
El tiempo de evaluación también es real. Quinientas preguntas con varias métricas pueden tardar entre quince y sesenta minutos. Para pipelines CI, paralelizar es posible pero no siempre trivial.
Métricas cualitativas complementarias
Las métricas cuantitativas no capturan todo. Señales cualitativas importantes incluyen feedback explícito de usuarios (pulgares arriba/abajo), tiempo que los usuarios pasan con cada respuesta, tasa de seguimiento con pregunta relacionada, y tasa de abandono.
Un sistema con métricas automáticas excelentes pero tasa alta de abandono de usuarios tiene problema que las métricas no capturan. Combinar ambas fuentes da visión completa.
Conclusión
Evaluar un RAG con rigor es la diferencia entre un sistema que funciona bien y uno que parece funcionar bien. El coste de implementar evaluación continua es moderado; el coste de no hacerlo es sistemas que decepcionan en producción sin que el equipo sepa por qué. Herramientas como Ragas democratizaron la infraestructura; el conjunto dorado y la disciplina de medir consistentemente son ahora la parte difícil. Para equipos que arrancan, un conjunto mínimo de cincuenta preguntas bien seleccionadas y las cuatro métricas básicas ya es salto enorme respecto a evaluar sin estructura. La iteración refina el proceso con el tiempo.
Síguenos en jacar.es para más sobre evaluación RAG, calidad LLM y producción IA.
