Durante el último año, los sistemas RAG han pasado de prototipo a componente de producción en la empresa. Con esa transición llega el problema que cualquier sistema en producción tiene: se degrada si nadie lo mira. La diferencia es que un RAG se degrada de forma más silenciosa que un servicio tradicional.

No cae, no devuelve errores 500, no dispara la alerta de latencia. Simplemente empieza a responder peor, y los usuarios se dan cuenta antes que los equipos.

Puntos clave

  • La evaluación inicial tiene caducidad corta: el índice cambia, el modelo cambia, las preguntas de los usuarios evolucionan.

  • Las métricas que más rinden en producción son: precisión de recuperación, recall efectivo, fidelidad al contexto, relevancia de la respuesta y latencia p99.

  • LLM-as-judge tiene sesgos documentados de longitud y posición; mitigar requiere modelo juez de familia distinta y calibración periódica con evaluación humana.

  • Una arquitectura de dos capas, con evaluación en sombra continua más evaluación de regresión semanal, cubre el 80 % de los escenarios de degradación.

  • Cuatro métricas bien elegidas con alertas claras valen más que quince métricas que nadie revisa.

Por qué la evaluación inicial no basta

Casi todos los equipos que despliegan un RAG hacen un conjunto de evaluación al principio. Esa evaluación inicial es necesaria pero tiene una caducidad corta.

El índice cambia. Se reindexan documentos nuevos, se retiran otros, los chunks se reparten de forma diferente tras una reingesta. El modelo también cambia: OpenAI publica nuevas versiones, Anthropic renueva Claude, los equipos sustituyen el generador por motivos de coste o latencia. Lo que ayer funcionaba con un modelo y un índice concretos deja de funcionar cuando cualquiera de las dos piezas se mueve.

El tercer factor es la deriva de las preguntas. Los usuarios reales no preguntan lo mismo el mes de lanzamiento que seis meses después. Los casos de uso emergentes no están cubiertos por el conjunto de evaluación inicial, y el RAG puede estar fallando en la cola larga sin que nadie lo note. El coste de esta degradación silenciosa conecta directamente con el análisis de FinOps aplicado a IA: el gasto sube mientras la calidad cae.

Métricas que sirven en producción

La literatura de evaluación de RAG propone un catálogo amplio de métricas. En producción, un subconjunto pequeño rinde cuentas:

  • Precisión de recuperación. Del conjunto de documentos recuperados, qué fracción es relevante. Una precisión por debajo del 60 % es mala señal casi siempre.

  • Recall efectivo. Para preguntas que admiten verificación, si el fragmento que debería responderlas está entre los recuperados. Requiere ground truth pero detecta si el retriever se está perdiendo la información clave.

  • Fidelidad de la respuesta al contexto. Si la respuesta del modelo se apoya en los chunks recuperados o fabrica contenido. Es la métrica clave para detectar alucinaciones, y la que más se degrada cuando el modelo generador cambia.

  • Relevancia de la respuesta. Si la respuesta aborda la pregunta o se desvía hacia lo que hay en los chunks sin responder realmente.

  • Latencia extremo a extremo y distribución. La media no basta: hay que vigilar también la cola p95 y p99. Los RAG tienen distribución de latencia sesgada porque el reranking puede disparar la cola sin afectar la mediana.

El problema de LLM-as-judge

La forma estándar de implementar las métricas anteriores es usar un LLM como evaluador. Funciona mejor que no tener evaluación, pero tiene sesgos documentados en el paper «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»[1] de Zheng et al. y resumidos con datos propios en el repaso de Eugene Yan sobre LLM-evaluators[2]:

  • Sensibilidad a la longitud: prefiere respuestas más largas aunque no sean mejores.

  • Sesgo posicional: favorece la primera opción en evaluaciones comparativas.

  • Excesiva permisividad al evaluar respuestas del mismo modelo o familia.

Incluso el mejor juez del análisis de Yan, GPT-4, solo alcanza una correlación de Spearman ρ ≈ 0,67 con el juicio humano en tareas de corrección. Es suficiente para detectar tendencias, no para sustituir la revisión humana en decisiones críticas.

Las mitigaciones son conocidas: usar un modelo juez de distinta familia que el generador, aleatorizar el orden de las respuestas y calibrar con un subconjunto de evaluaciones humanas periódicas. Sobre todo, no confiar en puntuaciones absolutas sino en tendencias relativas. La evaluación continua sirve sobre todo para detectar cambios, no para establecer verdades absolutas sobre la calidad.

Arquitectura del cuadro de mando

El patrón que mejor ha funcionado separa la evaluación en dos capas.

Primera capa: evaluación en sombra, ejecutada en continuo sobre una muestra del tráfico real. Un pequeño porcentaje de las consultas pasa por evaluaciones automáticas con LLM-as-judge y los resultados se agregan. Da señal en tiempo casi real, útil para detectar degradaciones bruscas tras un despliegue.

Segunda capa: evaluación de regresión, ejecutada en cadencia fija sobre un conjunto de preguntas curado. Se hace después de cada cambio significativo del sistema o al menos semanalmente. El conjunto curado cubre casos de uso críticos con respuestas verificadas, lo que permite medir métricas con ground truth. Da señal más rigurosa, útil para auditar tendencias a largo plazo.

El cuadro de mando combina ambas: las métricas en tiempo casi real van a Grafana con alertas por banda; las de regresión alimentan informes semanales con comparaciones entre versiones. Si la primera capa detecta una caída, se confirma con un paso de la segunda antes de alertar al equipo.

Ejemplos de alertas útiles

  • Caída de precisión de recuperación por debajo del 60 % en ventana de una hora → problema en el retriever, casi siempre por cambio de índice o modelo de embeddings.

  • Caída de fidelidad al contexto del 5 % o más en un despliegue → el generador nuevo está alucinando más que el anterior. Razón para revertir el despliegue automáticamente si el proceso lo permite.

  • Divergencia entre métricas automáticas y evaluación humana periódica → el juez se ha roto. Más común de lo que parece tras actualizar el modelo juez.

  • Cambio de distribución de preguntas medido por un clasificador sencillo → los usuarios están haciendo preguntas distintas, lo que obliga a revisar si el sistema cubre los casos nuevos.

Lo que no merece la pena montar

Algunas métricas que aparecen en papers ofrecen poco retorno en producción:

  • BLEU y ROUGE miran solapamiento léxico y son prácticamente ruido para respuestas generativas libres.

  • Métricas de diversidad léxica sobre la salida del modelo no correlacionan con calidad percibida.

  • Medir perplejidad del generador sobre sus propias respuestas es un circuito cerrado.

También merece la pena evitar el exceso de dashboards. Un cuadro de mando de quince métricas que nadie revisa no sirve. Mejor tener cuatro o cinco bien elegidas con alertas claras.

Mi lectura

Montar evaluación continua sobre un RAG exige inversión que los equipos postergan mientras el sistema parece funcionar. Esa postergación tiene un coste escondido: los incidentes de calidad en RAG son lentos, acumulativos y difíciles de atribuir a un cambio concreto cuando finalmente se hacen visibles.

La inversión razonable es modesta. Con una herramienta como Ragas[3] o DeepEval[4] y un par de semanas de ingeniería se monta un proceso utilizable. La parte cara no es técnica sino organizativa: convencer al equipo de que mantener un conjunto de evaluación curado es trabajo continuo, no un esfuerzo puntual. Sin esa disciplina, el conjunto caduca y el cuadro de mando pierde valor en meses.

Mi recomendación a quien opera un RAG sin evaluación continua es empezar por lo más simple: una muestra del tráfico, tres métricas bien elegidas, un panel en Grafana con alertas de umbral. Eso solo detecta el 80 % de las degradaciones. Las métricas más finas y la evaluación de regresión se añaden después, cuando está claro que la inversión renta. La misma disciplina de observabilidad aplica al profiling continuo con eBPF que describimos en otro artículo.

Este artículo también está disponible en inglés: Continuous evaluation of RAG: dashboards that actually matter.

Fuentes:

  1. Ragas: documentación oficial[3]
  2. DeepEval: documentación oficial[4]
  3. Zheng et al., «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»[1]
  4. Eugene Yan, «Evaluating the Effectiveness of LLM-Evaluators»[2]

Preguntas frecuentes

¿Cada cuánto hay que volver a evaluar un RAG en producción?

En dos capas. La primera es una evaluación en sombra continua sobre una muestra pequeña del tráfico real, con LLM-as-judge y resultados agregados casi en tiempo real. La segunda es una evaluación de regresión sobre un conjunto curado con respuestas verificadas, que se ejecuta tras cada cambio significativo o al menos semanalmente. La evaluación inicial caduca pronto porque el índice se reindexa, el modelo generador cambia y las preguntas de los usuarios derivan a los seis meses.

¿Puedo confiar en un LLM como juez de mi RAG?

Solo para detectar tendencias, no verdades absolutas. Tiene sesgos documentados por Zheng et al.: prefiere respuestas largas, favorece la primera opción en comparativas y es permisivo con su propia familia de modelos. Incluso GPT-4 solo alcanza una correlación de Spearman de aproximadamente 0,67 con el juicio humano. Las mitigaciones son usar un juez de familia distinta al generador, aleatorizar el orden de respuestas y calibrar periódicamente con evaluación humana.

¿Qué umbrales de alerta merecen la pena en el cuadro de mando?

Precisión de recuperación por debajo del 60 % en una ventana de una hora, que casi siempre indica cambio de índice o de modelo de embeddings. Caída de fidelidad al contexto del 5 % o más tras un despliegue, motivo para revertirlo automáticamente. Divergencia entre métricas automáticas y evaluación humana, señal de que el juez se ha roto, y cambio en la distribución de preguntas. Cuatro o cinco métricas con alertas claras valen más que quince que nadie revisa.

Fuentes

  1. «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»
  2. Eugene Yan sobre LLM-evaluators
  3. Ragas
  4. DeepEval