Evaluación continua de RAG: cuadros de mando que importan
Actualizado: 2026-05-03
Los sistemas RAG han pasado de ser prototipos a componentes de producción en muchas empresas durante el último año. 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 —evaluación en sombra continua + 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 tiene muchas métricas propuestas. 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 fácilmente 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. No solo la media, sino 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
Muchas de las métricas anteriores se implementan usando un LLM como evaluador. Funciona mejor que no tener evaluación, pero tiene sesgos documentados:
- 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.
Las mitigaciones son conocidas: usar un modelo juez de distinta familia que el generador, aleatorizar el orden de las respuestas, calibrar con un subconjunto de evaluaciones humanas periódicas y 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 a menudo postergan porque 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[1] o DeepEval[2] 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.
