Observabilidad: qué monitorizar cuando ya está en marcha

Un RAG en producción falla de una forma incómoda: sigue respondiendo. No devuelve un error, no dispara una alerta de disponibilidad, no se cae. Simplemente empieza a responder peor, y sin instrumentación específica nadie se entera hasta que alguien se queja. Esta entrega trata de qué hay que registrar y qué hay que mirar.

El fallo silencioso

La monitorización clásica —tasa de error, latencia, uso de CPU, disponibilidad— es necesaria y completamente insuficiente aquí. Un sistema RAG puede tener el cien por cien de disponibilidad, latencia impecable y cero excepciones mientras un cambio en el pipeline de ingesta ha dejado de indexar una carpeta entera, o un ajuste de umbral ha empezado a descartar los fragmentos buenos, o el proveedor ha actualizado el modelo generador y ahora ignora la instrucción de citar.

De ahí la primera regla: la observabilidad de un RAG se construye alrededor de la traza por consulta, no de las métricas de infraestructura. Las métricas dicen que algo va mal; la traza es lo único que permite averiguar qué. Y la traza sólo sirve si se emitió cuando ocurrió el problema, así que se instrumenta desde el primer despliegue, no cuando aparece el primer incidente.

La traza por consulta

Una traza es el registro completo de lo que pasó al responder a una pregunta concreta. Debe permitir a alguien que no estaba delante reconstruir la decisión entera semanas después. Estos son los campos que hay que guardar.

Identificación y contexto

• trace_id, marca de tiempo, identificador de conversación y de turno.
• tenant_id, identificador de usuario seudonimizado, y el conjunto de grupos o permisos resuelto para la consulta.
• Versiones: del prompt, del modelo generador, del modelo de embeddings, del reranker, y del código o configuración del pipeline. Sin esto no se puede correlacionar una caída de calidad con un despliegue.

Entrada y transformación

• Pregunta original tal cual la escribió el usuario.
• Consulta transformada: reescritura, resolución de anáforas, subconsultas generadas si hubo descomposición.
• Filtros aplicados, incluidos los de permisos y los de metadatos derivados de la pregunta.

Recuperación

• Lista de candidatos de primera fase con puntuación, identificador de fragmento, identificador y versión de documento.
• Si hay búsqueda híbrida: puntuación densa, puntuación léxica y puntuación fusionada, por separado.
• Orden posterior al reranking con la puntuación del reranker, para poder comparar antes y después.
• Fragmentos finalmente seleccionados y cuáles se descartaron por presupuesto de tokens.

Generación

• Prompt final completo, o su hash más las referencias necesarias para reconstruirlo.
• Respuesta generada y citas emitidas.
• Motivo de finalización, y si hubo abstención, el motivo de la abstención.

Rendimiento y coste

• Latencia por etapa —transformación, embedding, búsqueda, reranking, montaje, primer token, total— y no sólo la total.
• Tokens de entrada y de salida, y coste estimado de la consulta.
• Indicadores de caché: acierto o fallo, y de qué caché. Una respuesta servida desde caché semántica debe ser identificable siempre.

Señales posteriores

• Voto del usuario, si lo hay.
• Si abrió alguna de las citas.
• Si reformuló la pregunta en el turno siguiente, y si escaló a un humano.

Dos advertencias sobre los datos. La traza contiene preguntas de usuarios y contenido de documentos, así que es información sensible: tiene su propia política de retención, su control de acceso y, si el dominio lo exige, seudonimización. Y guardar el prompt completo de cada consulta es caro en volumen; un patrón razonable es guardar la traza completa de una muestra y de todos los casos con voto negativo o abstención, y la traza reducida del resto.

Métricas agregadas

Sobre las trazas se construyen los agregados. Los que importan de verdad son pocos.

De recuperación. Distribución de la puntuación del mejor fragmento por consulta: es el indicador más sensible que existe para detectar que algo se ha roto en el índice. Si la mediana de la puntuación máxima cae, el sistema ha dejado de encontrar material bueno, y eso ocurre antes de que nadie se queje. Vigila también la proporción de consultas que no superan el umbral y la distribución de documentos recuperados: si el diez por ciento del corpus responde al noventa por ciento de las consultas, o el resto sobra o hay un sesgo de recuperación que investigar.

De generación. Tasa de abstención —«no lo sé»— y tasa de respuestas sin citas. Ambas deben ser estables; un salto en cualquiera de las dos casi siempre coincide con un despliegue. Si haces evaluación continua con un modelo como juez sobre una muestra, la fidelidad media es la métrica de calidad más útil, con la cautela que ya se comentó en la entrega 38 sobre lo que ese método mide realmente.

De negocio. Proporción de conversaciones resueltas sin escalado, reformulaciones por conversación, y tasa de apertura de citas. Son las únicas que le importan a quien paga el sistema, y suelen correlacionar mejor con la satisfacción real que cualquier métrica interna.

Preguntas sin respuesta útil

El activo más valioso que genera un RAG en producción no son las respuestas: es la lista de preguntas que no supo responder. Cada una es una de tres cosas, y las tres son accionables: un hueco de documentación, un fallo de recuperación, o una expectativa mal calibrada del usuario sobre lo que el sistema hace.

Se detectan combinando señales: puntuación máxima de recuperación por debajo del umbral, abstención explícita, voto negativo, reformulación inmediata, escalado a humano. El paso que convierte eso en algo útil es agrupar por similitud semántica: cien preguntas distintas sobre el mismo hueco son un problema, no cien. Un ciclo semanal de revisión de los diez grupos más frecuentes, con una decisión por grupo —documentar, corregir recuperación, o responder que está fuera de alcance—, es la rutina de mejora continua con mejor relación entre esfuerzo y resultado en todo el ciclo de vida de un RAG.

Deriva

Dos derivas distintas y ambas lentas.

La deriva del corpus es que el material cambia bajo el sistema. Se vigila con métricas de la ruta de indexación: documentos indexados por día, edad mediana del contenido, retardo entre modificación en la fuente e indexación, proporción de fragmentos que fallaron la extracción, número de documentos en la cola de mensajes muertos. Una fuente que deja de emitir documentos nuevos es casi siempre un conector roto, no una fuente que se quedó quieta, y es un fallo que puede pasar semanas inadvertido.

La deriva de las preguntas es que los usuarios cambian lo que preguntan: una campaña, un producto nuevo, una crisis, un cambio normativo. Se detecta agrupando las consultas por periodo y comparando la distribución de temas. Importa porque tu golden dataset envejece: un conjunto de evaluación construido con las preguntas de hace un año mide un sistema que ya no es el que se usa. Refrescarlo con consultas reales recientes es parte del mantenimiento, no una tarea extraordinaria.

El panel mínimo y las alertas

Desde el primer día en producción, seis paneles bastan: volumen de consultas y tasa de error; latencia por etapa en percentiles 50, 95 y 99; puntuación máxima de recuperación (distribución y mediana); tasa de abstención y de respuestas sin citas; coste por consulta y coste diario acumulado; salud de la ingesta con retardo de indexación y cola de fallos. Y un buscador de trazas que permita llegar a una consulta concreta por identificador, por usuario o por documento citado: sin eso, ningún panel sirve para diagnosticar nada.

En cuanto a alertas, la disciplina es la de siempre: pocas y accionables. Merecen la pena estas cinco.

• Caída de la mediana de puntuación de recuperación respecto a la semana anterior. Es la alerta más específica de un RAG y la que antes detecta un desastre silencioso.
• Salto en la tasa de abstención o de respuestas sin citas. Casi siempre apunta a un cambio de modelo o de prompt.
• Retardo de indexación por encima del compromiso, o una fuente sin documentos nuevos durante más tiempo del que es plausible.
• Coste diario por encima de un umbral, que suele delatar un bucle de reintentos, un agente que no converge o un abuso.
• Latencia p95 hasta el primer token fuera de presupuesto, desglosada por etapa para saber a quién culpar.

Lo que no merece alerta: métricas de calidad calculadas sobre volúmenes pequeños, que oscilan por azar y enseñan al equipo a ignorar las alarmas.

Límites

La observabilidad no mide la corrección. Mide indicios de que el sistema está funcionando como la última vez que alguien comprobó que funcionaba bien. Un RAG puede tener todos los paneles en verde y estar respondiendo mal de forma sistemática, si respondía mal desde el principio. Por eso la instrumentación no sustituye a la evaluación del bloque sexto: la evaluación te dice si el sistema es bueno, la observabilidad te dice si ha dejado de ser lo que era. Hacen falta las dos, y la segunda sin la primera es un termómetro sin escala.

Qué viene ahora

La entrega siguiente cierra la serie mirando hacia delante: qué está madurando de verdad en recuperación multimodal, agentes y memoria a largo plazo, qué miden los benchmarks que han aparecido para evaluar RAG en serio, y la discusión honesta sobre si el crecimiento de las ventanas de contexto hace innecesario todo este aparato. Con un repaso final a los siete bloques del recorrido.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.