Los sistemas RAG han pasado de ser prototipos interesantes a componentes de produccion en muchas empresas durante el último año. Con esa transición llega el problema que cualquier sistema en produccion tiene: se degrada si nadie lo mira. La diferencia es que un RAG se degrada de forma mas 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.
Este post es un repaso pragmatico de como montar evaluación continua sobre un sistema RAG en produccion. Que métricas sirven, cuales son teatro, que falsos positivos esperar y como construir un cuadro de mando que realmente avise antes de que la calidad caiga de forma visible.
Por que la evaluación inicial no basta
Casi todos los equipos que despliegan un RAG hacen un set de evaluación al principio. Un punado de preguntas de referencia, respuestas esperadas, una pasada manual para verificar que el sistema funciona. 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 después de 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 correctamente con un modelo concreto sobre un índice concreto 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 que se lanza el sistema que seis meses después. Los casos de uso emergentes no estan cubiertos por el conjunto de evaluación inicial, y el RAG puede estar fallando en la cola larga sin que nadie lo note hasta que alguien importante se queja.
Métricas que sirven en produccion
La literatura de evaluación de RAG tiene muchas métricas propuestas. En produccion, un subconjunto pequeño es el que rinde cuentas.
Precisión de recuperacion. Del conjunto de documentos recuperados para una pregunta, que fraccion es relevante. No confundir con recall: en un RAG en produccion, precisión es lo que afecta a la respuesta, porque los chunks irrelevantes confunden al generador y diluyen los relevantes. Una precisión por debajo del 60% es mala señal casi siempre.
Recall efectivo. Para las preguntas que admiten verificacion, si el fragmento que deberia responderlas esta entre los recuperados. Es mas cara de medir porque requiere ground truth, pero en verticales donde la respuesta correcta esta en un documento concreto (soporte, documentación, politica interna) es la métrica que detecta si el retriever se esta perdiendo la información.
Fidelidad de la respuesta al contexto. Mide si la respuesta del modelo se apoya en los chunks recuperados o fabrica contenido. Es la métrica clave para detectar alucinaciones, y es la que mas fácilmente se degrada cuando el modelo generador cambia. Herramientas como Ragas la implementan con LLM-as-judge con resultados razonables.
Relevancia de la respuesta. Si la respuesta aborda la pregunta o se desvia. A veces el modelo escribe correctamente sobre los chunks recuperados pero la pregunta original no era esa. Esta métrica captura esos casos.
Latencia punta a punta y distribución. No solo la media, sino la cola p95 y p99. Los RAG tienen una distribución de latencia muy sesgada porque el reranking o un segundo paso de generación pueden disparar la cola sin afectar la mediana.
El problema de LLM-as-judge
Muchas de las métricas anteriores se implementan usando un LLM como evaluador, el famoso LLM-as-judge. Funciona mejor que no tener evaluación, pero tiene sesgos documentados que conviene conocer.
Los jueces LLM son sensibles a la longitud, prefiriendo respuestas mas largas aunque no sean mejores. Tienen sesgo posicional, favoreciendo la primera opcion cuando evaluan comparativamente. Y tienden a ser excesivamente permisivos cuando evaluan respuestas del mismo modelo o de la misma familia.
Las mitigaciones son conocidas. Usar un modelo juez de distinta familia que el generador, aleatorizar el orden de las respuestas en evaluaciones comparativas, calibrar con un subconjunto de evaluaciones humanas periodicas, y no confiar ciegamente en puntuaciones absolutas sino en tendencias relativas. La evaluación continua es útil sobre todo para detectar cambios, no para establecer verdades absolutas sobre la calidad.
Arquitectura del cuadro de mando
El patron que mejor ha funcionado en sistemas que he ayudado a montar es separar la evaluación en dos capas.
La primera capa es una evaluación en sombra, ejecutada en continuo sobre una muestra de las consultas reales. Se toma un pequeño porcentaje del tráfico, se ejecutan evaluaciones automáticas con LLM-as-judge y se agregan las métricas. Da una señal en tiempo casi real, útil para detectar degradaciones bruscas después de un despliegue.
La segunda capa es evaluación de regresion, 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 criticos con respuestas verificadas, lo que permite medir métricas con ground truth en lugar de LLM-as-judge. Da una señal mas ruidosa pero mas rigurosa, útil para auditar tendencias a mas largo plazo.
El cuadro de mando combina ambas. Las métricas en tiempo casi real de la primera capa van a Grafana o similar con alertas configuradas por banda. Las métricas de regresion alimentan informes semanales con comparaciones entre versiones. Los dos se referencian cruzados: si la primera capa detecta una caida, se confirma con un paso de la segunda capa antes de alertar al equipo.
Ejemplo de alertas útiles
Una caida de precisión de recuperacion por debajo del 60% en ventana de una hora. Indica problema en el retriever, casi siempre por cambio de índice o de modelo de embeddings. Es critico porque afecta al siguiente paso.
Una caida de fidelidad al contexto del 5% o mas en un despliegue. Indica que el generador nuevo esta alucinando mas que el anterior. Es razon para revertir el despliegue automaticamente si el proceso lo permite.
Una divergencia entre métricas automáticas y evaluación humana periodica. Si el LLM-as-judge dice que todo va bien pero los evaluadores humanos senalan regresiones, el juez se ha roto. Es mas comun de lo que parece, especialmente cuando se actualiza el modelo juez.
Un cambio de distribución de preguntas medido por un clasificador sencillo. Indica que los usuarios estan 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 y tutoriales ofrecen poco retorno en produccion. BLEU y ROUGE miran solapamiento lexico y son practicamente ruido para respuestas generativas libres. Métricas de diversidad lexica sobre la salida del modelo no correlacionan con calidad percibida y confunden mas que aclaran. Y medir perplejidad del generador sobre respuestas propias 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 que veinte que requieran interpretacion experta.
Mi lectura
Montar evaluación continua sobre un RAG exige inversion que los equipos a menudo postergan porque el sistema parece funcionar. Esa postergacion tiene un coste escondido. Los incidentes de calidad en RAG suelen ser lentos, acumulativos y dificiles de atribuir a un cambio concreto cuando finalmente se hacen visibles. En ese momento es tarde para medir lo que se degrado.
La inversion razonable es modesta. Con una herramienta como Ragas o DeepEval y un par de semanas de ingenieria se monta un proceso utilizable. La parte cara, siendo honesto, 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 cuestion de meses.
Mi recomendacion a quien esta operando un RAG sin evaluación continua es empezar por la parte mas simple. Una muestra del tráfico, tres métricas bien elegidas, un panel en Grafana con alertas de umbral. Eso solo ya detecta el 80% de las degradaciones. Las métricas mas finas y la evaluación de regresion se anaden después, cuando esta claro que la inversion renta.
