Evaluar y operar sistemas de IA en producción: calidad, fiabilidad, observabilidad e incidentes · Módulo 3: Trazas y monitorización

Monitorizar calidad, deriva, latencia y coste

Monitorización por capas que combina golden signals, calidad diferida, drift, autonomía, seguridad y economía con alertas accionables.

Objetivo de aprendizaje

Diseñar paneles y alertas segmentados que distingan degradación técnica, semántica y económica y permitan investigar sus causas.

Monitorizar IA no consiste en crear un dashboard con tokens y latencia. Un servicio puede estar técnicamente sano y producir resultados peores; también puede mantener calidad y volverse demasiado caro.

Necesitas señales inmediatas, diferidas y por segmento.

Empieza por las señales clásicas

Google SRE identifica cuatro golden signals:

  • latency;
  • traffic;
  • errors;
  • saturation.

En IA tradúcelas al pipeline completo.

Latency

  • p50;
  • p95;
  • p99;
  • time to first token;
  • tiempo a outcome.

Traffic

  • solicitudes;
  • jobs;
  • tokens;
  • tool calls.

Errors

  • 4xx/5xx;
  • rate limits;
  • timeouts;
  • invalid outputs;
  • failed tools.

Saturation

  • workers;
  • colas;
  • concurrencia;
  • límites del proveedor.

Añade calidad

La calidad suele llegar con retraso.

Fuentes:

  • feedback;
  • revisión humana;
  • muestreo;
  • eval programática;
  • outcome.

Crea una ventana:

sample production cases → review → score → dashboard

No presentes el score de ayer como señal instantánea.

Añade métricas de IA

Por ejemplo:

  • abstención;
  • groundedness;
  • invalid schema;
  • tool selection;
  • approval rate;
  • edit rate;
  • escalado;
  • retrieval misses.

Selecciona las que responden a riesgos reales.

Deriva no es degradación

Puedes detectar que cambió la distribución de inputs:

  • longitud;
  • idioma;
  • categorías;
  • documentos;
  • tools.

Eso es drift.

No implica automáticamente peor calidad.

Proceso:

detectar cambio → identificar segmento → ejecutar eval → decidir

Evita alarmas por cada diferencia estadística.

Monitoriza modelos y agentes después del deploy

Las evals pre-deployment no muestran todos los patrones de uso real. Anthropic ha señalado la importancia de monitorización post-deployment para comprender cómo se usan agentes en la práctica.

Mide:

  • duración;
  • pasos;
  • tools;
  • intervenciones;
  • stop reasons;
  • outcomes.

Coste

Dashboard:

  • coste total;
  • por usuario;
  • por tenant;
  • por tarea;
  • por outcome;
  • por modelo;
  • retries.

No alertes solo por gasto absoluto. Una campaña o pico de uso legítimo puede elevarlo.

Usa:

  • budget;
  • forecast;
  • coste por unidad.

Segmenta

Siempre por:

  • version;
  • task;
  • risk;
  • tenant;
  • tool;
  • language.

Una media global puede ocultar un segmento roto.

Alertas accionables

Cada alerta necesita:

  • owner;
  • severidad;
  • runbook;
  • ventana;
  • acción.

Buenos ejemplos:

  • cross-tenant > 0;
  • error budget burn;
  • invalid output +300 %;
  • p95 duplicado sostenido;
  • coste por outcome > límite;
  • tool failure alto.

No pagines humanos por una métrica que no requiere actuación inmediata.

Correlación

Une:

  • deploy markers;
  • model changes;
  • index changes;
  • provider incidents.

Si una degradación empezó exactamente con prompt_v18, la investigación es más rápida.

Diseña ventanas

Una alerta puede usar:

  • 5 min;
  • 1 h;
  • 24 h.

Un p95 alto 30 segundos no siempre justifica paging.

Diferencia:

  • page;
  • ticket;
  • dashboard.

Burn rate

Para SLOs técnicos, el burn rate indica la velocidad a la que consumes error budget.

Una alerta multi-window puede detectar:

  • fallos rápidos;
  • degradación lenta.

No copies una fórmula sin entender el SLO.

Calidad con muestreo

Si revisas 100 casos al día, muestra:

  • tamaño;
  • confianza;
  • segmento.

No presentes 82 % como precisión exacta de millones de consultas sin contexto estadístico.

Delayed labels

Algunos outcomes tardan.

Ejemplo:

  • ¿el informe fue aceptado?
  • ¿el ticket se reabrió?

Conecta eventos posteriores a la ejecución.

Leading y lagging

Leading invalid schema.

Lagging cliente corrige.

Usa ambas.

Monitoriza abstención

Un aumento puede indicar:

  • corpus vacío;
  • modelo más conservador;
  • permisos;
  • nuevo segmento.

Investiga causa.

Data quality

Añade señales:

  • documentos no sincronizados;
  • campos nulos;
  • index lag;
  • tool payload invalid.

No todo problema de IA es del modelo.

Cost anomalies

Descompón:

  • más tráfico;
  • más tokens;
  • más retries;
  • nuevo modelo.

Una factura alta tiene causas distintas.

Alert fatigue

Revisa alertas:

  • fired;
  • actionable;
  • false positive.

Elimina las que nunca producen acción.

Status de proveedores

Puedes integrar señales externas, pero no dependas únicamente de ellas.

Tu servicio puede fallar aunque la página del proveedor esté verde.

Dashboard ejecutivo

No muestres 80 métricas.

Dirección puede necesitar:

  • utilidad;
  • riesgo;
  • coste;
  • incidentes.

Operaciones necesita detalle.

Diseña audiencias.

Ejercicio

Diseña un dashboard de máximo 12 paneles.

Incluye:

  • 4 técnicos;
  • 3 calidad;
  • 2 coste;
  • 2 seguridad/operación;
  • 1 release.

Para cada alerta escribe el runbook que ejecutaría el on-call.

Resultado de la lección

Debes terminar con una monitorización que detecta impacto, no ruido. La siguiente lección utilizará esas señales para versionar y desplegar cambios con un radio de impacto limitado.