ML Model Monitoring explicado de forma sencilla (con diagramas y código real)
ML Model Monitoring: lo esencial en un artículo — código real, diagramas y pasos concretos, extractos de un curso de 24 lecciones.
Una guía que va al grano: ML Model Monitoring desglosado con diagramas, ejemplos concretos y comandos probados. Todo procede de un curso estructurado de 7 capítulos —aquí tienes lo mejor.
tl;dr
- Introducción al monitoreo de ML
- Deriva de datos
- Deriva del modelo y rendimiento
- Herramientas del mercado
- Monitoreo en producción
~$ cat ./parcours.md # ML Model Monitoring — 6 capítulos
01
Introduction ML Monitoring
→ El síndrome del modelo que se pudre→ Los 3 pilares del monitoreo ML+ 1 más lecciones
02
Data Drift
→ Conceptos y causas del data drift→ Pruebas estadísticas : KS, Chi², PSI, Wasserstein+ 1 más lecciones
03
Model Drift y rendimiento
→ Concept drift vs Performance drift→ Métricas por tipo de problema ML+ 1 más lecciones
04
Herramientas del mercado
→ Panorama de las herramientas ML Monitoring→ Stack open-source completa : Evidently + Prometheus + Grafana+ 1 más lecciones
05
Monitoreo en producción
→ SLO, SLA y presupuestos de error para ML→ Continuous Training (CT) con Airflow+ 2 más lecciones
06
Proyecto final
→ Proyecto final : Pliego de condiciones y arquitectura→ Implementación FraudGuard paso a paso+ 1 más lecciones
🏁
Proyecto final
→ Te vas con un proyecto concreto y demostrable
Configurar las alertas de Prometheus, Slack y PagerDuty
NOTEObjetivo — Transformar tus métricas de monitoreo de ML en alertas accionables: escribir reglas de Prometheus sobre la deriva y la degradación, enrutar las notificaciones mediante Alertmanager hacia Slack y PagerDuty, y evitar la fatiga de alertas.
Objetivos pedagógicos
TIPAl finalizar este módulo
- Escribir reglas de alerta de Prometheus (
alerting_rules.yml) sobre KPI de ML - Configurar Alertmanager para enrutar hacia Slack y PagerDuty
- Distinguir alerta warning y alerta critical por severidad
- Implementar agrupación (
group_by) e inhibición - Reducir la fatiga de alertas con
for, umbrales y silencios
De la métrica a la alerta: la cadena completa
Una métrica expuesta en /metrics no sirve de nada si nadie la mira a las 3 de la madrugada. La cadena de alerting conecta un valor numérico con una acción humana. Consta de cuatro eslabones.
1. Exportar la métrica
Tu servicio de ML publica Gauge y Counter: puntuación de deriva, latencia p95, tasa de error, accuracy móvil.
2. Evaluar la regla
Prometheus evalúa periódicamente expresiones PromQL. Cuando la expresión permanece verdadera durante for, la alerta pasa de pending a firing.
3. Enrutar la alerta
Alertmanager recibe las alertas firing, las agrupa, las deduplica y elige el receiver según las etiquetas.
4. Notificar al humano
El receiver envía un mensaje a Slack (warning) o activa PagerDuty con guardia (critical).
NOTERegla de oro: una alerta que se dispara debe siempre solicitar una acción. Si nadie hace nada cuando suena, elimínala o conviértela en un simple panel de dashboard.
Escribir reglas de alerta de ML en Prometheus
Las reglas viven en un archivo YAML cargado por Prometheus mediante rule_files. Para un modelo en producción se supervisan tres familias: la deriva de datos, la degradación del rendimiento y la salud de la infraestructura (latencia, errores).
| Palanca | Efecto |
|---|---|
for: 15m | Elimina picos transitorios, solo alerta sobre derivas sostenidas |
| Inhibición | Si la API está caída, no se alerta también sobre la deriva (causa raíz única) |
| Silencios | Durante un retraining planificado, se cortan temporalmente las alertas de deriva |
| Umbrales calibrados | Umbrales basados en el histórico, no valores arbitrarios copiados de un tutorial |
Los 3 pilares del monitoreo de ML
Capítulo 00 • Lección 02 • Duración: 45 min
NOTE🎯 Objetivos
- Identificar las 3 categorías de métricas a supervisar
- Comprender qué métricas medir según el tipo de modelo
- Establecer una hoja de ruta progresiva de instrumentación
- Conocer las buenas prácticas de logging en ML
1. Vista general: los 3 pilares
┌─────────────────────────────────────────────────────────────┐ │ MONITORING ML EN PRODUCTION │ └─────────────────────────────────────────────────────────────┘ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ PILIER 1 │ │ PILIER 2 │ │ PILIER 3 │ │ Système │ │ Données │ │ Modèle │ │ (infra) │ │ (data + drift) │ │ (performance) │ └────────────────┘ └────────────────┘ └────────────────┘ - Latence - Distribution X - Accuracy - QPS - Valeurs manqu. - F1, AUC - CPU/Mémoire - Outliers - Calibration - Erreurs 5xx - Drift KS/PSI - Business KPI
2. Pilar 1 — Monitoreo del sistema (infra)
Es el monitoreo clásico de aplicaciones, idéntico al de cualquier API REST.
| Métrica | Herramientas | Umbral típico |
|---|---|---|
| Latencia p50/p95/p99 | Prometheus, Datadog, CloudWatch | p99 < 500 ms |
| QPS (Queries Per Second) | Prometheus, ALB metrics | Seguir tendencia |
| Tasa de error HTTP (5xx) | Prometheus, CloudWatch | < 0.1 % |
| CPU / Memoria | cAdvisor, Datadog | < 80 % |
| Uso de GPU (si aplica) | NVIDIA DCGM, Prometheus | < 90 % |
| Disk I/O | node_exporter | — |
| Saturación de cola (Kafka, SQS) | Kafka exporter | < 10k messages |
TIP
Especificidad ML: La latencia puede explotar en modelos de deep learning por GPUs mal compartidas. Siempre medir la latencia p99, no solo la media.
3. Pilar 2 — Monitoreo de datos (entradas)
3.1 Métricas por característica
| Tipo de característica | Métricas |
|---|---|
| Numérica | Min, max, mean, std, mediana, cuantiles, valores faltantes |
| Categórica | Distribución de clases, nuevas clases, NULL |
| Texto | Longitud media, vocabulario, idiomas detectados |
| Imagen | Tamaño, ratio, histogramas RGB |
| Timestamp | Rangos de fechas, frecuencia por hora del día |
3.2 Detección de deriva
| Prueba estadística | Tipo de característica | Cuándo usar |
|---|---|---|
| Kolmogorov-Smirnov (KS) | Numérica | Prueba continua vs distribución de referencia |
| Chi-squared (χ²) | Categórica | Comparación de frecuencias |
| Population Stability Index (PSI) | Numérica discretizada | Estándar en finanzas y banca |
| Wasserstein distance | Numérica | Más sensible que KS para distribuciones grandes |
| Jensen-Shannon divergence | Categórica | Comparación probabilística |
Detalles y código en el Capítulo 01 lección 02.
3.3 Calidad de los datos
4. Pilar 3 — Monitoreo del modelo
4.1 Métricas de predicción (sin etiquetas)
| Métrica | Descripción |
|---|---|
| Distribución de predicciones | % de cada clase para clasificación |
| Puntuación de confianza media | Indicador de duda del modelo |
| Entropía de las salidas | Cuanto más alta, más incierto es el modelo |
| Tasa de OOD (Out-of-Distribution) | % de entradas fuera de la distribución de entrenamiento |
| Tasa de fallback / unknown | % de predicciones donde el modelo no sabe |
4.2 Rendimiento (con etiquetas)
| Problema | Métricas principales |
|---|---|
| Clasificación binaria | Accuracy, Precision, Recall, F1, AUC-ROC, AUC-PR |
| Clasificación multiclase | Accuracy, F1-macro, F1-weighted, matriz de confusión |
| Regresión | RMSE, MAE, MAPE, R² |
| Ranking / Recomendación | NDCG, MAP, Recall@k, Precision@k |
| Detección de anomalías | Precision/Recall en la clase rara |
| Generación (LLM) | BLEU, ROUGE, perplejidad, evaluación humana |
4.3 Calibración
Un modelo calibrado es aquel cuyas probabilidades predichas coinciden con las frecuencias reales. Ej.: en 100 predicciones al 80 % de confianza, ~80 deben ser correctas.
from sklearn.calibration import calibration_curve
import matplotlib.pyplot as plt
prob_pred = model.predict_proba(X_test)[:, 1]
prob_true, prob_pred = calibration_curve(y_test, prob_pred, n_bins=10)
plt.plot([0, 1], [0, 1], 'k--')
plt.plot(prob_pred, prob_true, 'o-')
plt.xlabel('Probabilidad predicha')
plt.ylabel('Probabilidad observada')
plt.title('Calibration plot')5. El problema del "delayed feedback"
A menudo, la verdad (la etiqueta) solo se conoce días/semanas/meses después de la predicción.
| Caso de uso | Retraso del feedback |
|---|---|
| Detección de spam | Algunos minutos (usuario reporta) |
| Recomendación | Horas (clic) o días (compra) |
| Detección de fraude bancario | Días a semanas (chargeback) |
| Score de crédito | 1-3 años (incumplimiento) |
| Predicción de churn | 30 a 90 días |
| Diagnóstico médico | Semanas a años |
Conceptos y causas de la deriva de datos
Capítulo 01 • Lección 01 • Duración: 45 min
NOTE🎯 Objetivos
- Definir con precisión qué es el data drift (y qué no es)
- Distinguir covariate shift, label shift y concept drift
- Reconocer las causas comunes: estacionalidad, eventos, bugs upstream
- Establecer una estrategia de referencia (reference dataset)
1. Definición formal
El data drift ocurre cuando la distribución estadística de los datos en producción difiere de la utilizada para entrenar el modelo.
P_train(X) ≠ P_prod(X) o más generalmente: P_train(X, Y) ≠ P_prod(X, Y)
Matemáticamente, se habla de covariate shift cuando solo cambia la distribución de las características X, pero la relación P(Y|X) permanece idéntica.
2. Los 3 tipos de shift
| Tipo | Definición | Ejemplo |
|---|---|---|
| Covariate shift | P(X) cambia, P(Y|X) constante | Modelo de salud entrenado en adultos; en prod hay seniors. Pero la relación síntomas → enfermedad es la misma. |
| Label shift | P(Y) cambia, P(X|Y) constante | Detección de spam: 5 % de spam en train, 50 % en prod (campaña masiva de phishing). El perfil de los spam es similar pero su frecuencia explota. |
| Concept drift | P(Y|X) cambia | Reconocimiento de fraude: los estafadores se adaptan, por lo que el mismo perfil = comportamiento diferente. La regla cambia. |
3. Esquema visual
Distribution training Distribution production
* *
*** *
***** ***
******* *****
********* vs ********
*********** **********
************* *************
─────────────────── ──────────────────────────
Pas de drift DRIFT DÉTECTÉ
(la distribution s'est décalée)4. Causas principales de la deriva de datos
4.1 Estacionalidad
| Dominio | Ejemplo estacional |
|---|---|
| E-commerce | Black Friday (volúmenes ×10), período navideño |
| Meteorología | Características de temperatura muy diferentes invierno/verano |
| Tráfico | Fin de semana vs días laborables, horas punta |
| Turismo | Verano en hemisferio sur vs norte |
| Energía | Consumo invierno vs verano (aire acondicionado/calefacción) |
4.2 Eventos externos
4.3 Evolución del negocio
4.4 Bugs y cambios técnicos (a menudo olvidados)
WARNING⚠️ Las causas más insidiosas
- Pipeline ETL upstream que cambia un encoding (UTF-8 vs Latin-1)
- Actualización de la API fuente que devuelve campos de más/menos
- Fix de bug que modifica valores upstream (ej.: redondeo cambiado)
- Cambio de versión de una librería (numpy 1.x vs 2.x diferente)
- Migración de base de datos que altera los tipos
- Nuevo campo opcional: NULL en prod, nunca NULL en train
5. Ejemplo concreto en Python — simular una deriva
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
np.random.seed(42)
n_train = 5000
train_age = np.random.normal(35, 10, n_train)
train_age = np.clip(train_age, 18, 80)
train_income = train_age * 1000 + np.random.normal(0, 5000, n_train)
prod_age = np.random.normal(50, 12, n_train)
prod_age = np.clip(prod_age, 18, 80)
prod_income = prod_age * 1000 + np.random.normal(0, 5000, n_train)
fig, axes = plt.subplots(1, 2, figsize=(14, 5))
axes[0].hist(train_age, bins=30, alpha=0.5, label='Train', color='blue')
axes[0].hist(prod_age, bins=30, alpha=0.5, label='Production', color='red')
axes[0].axvline(train_age.mean(), color='blue', linestyle='--', label=f'Train moy={train_age.mean():.1f}')
axes[0].axvline(prod_age.mean(), color='red', linestyle='--', label=f'Prod moy={prod_age.mean():.1f}')
axes[0].set_title('Distribution de "age" — covariate shift visible')
axes[0].set_xlabel('Age')
axes[0].legend()
axes[1].hist(train_income, bins=30, alpha=0.5, label='Train', color='blue')
axes[1].hist(prod_income, bins=30, alpha=0.5, label='Production', color='red')
axes[1].set_title('Distribution de "income"')
axes[1].set_xlabel('Income')
axes[1].legend()
plt.tight_layout()
plt.savefig('drift_visualization.png')
plt.show()6. El concepto de "reference dataset"
Para detectar deriva hay que comparar con algo conocido. Es el reference dataset.
| Opción | Ventajas | Desventajas |
|---|---|---|
| Dataset de entrenamiento | Muestra de lo que el modelo vio | Puede estar obsoleto (1 año+) |
| Dataset de validación | Independiente del train | Pequeño, a veces sesgado |
| Ventana deslizante prod (semana pasada) | Siempre fresco | Deriva progresiva no detectada |
| Mes anterior | Buen equilibrio | Estacionalidad ignorada |
| Mes anterior N-12 (mismo mes) | Estacionalidad tenida en cuenta | Alteraciones a largo plazo no capturadas |
TIP
Recomendación: Mantener 2 referencias — (1) dataset de validación inicial para la deriva "estructural" (2) ventana deslizante de 30 días para la deriva "comportamental".
7. Granularidad de la detección
| Granularidad | Cuándo usarla |
|---|---|
| Por característica | Identificar con precisión qué variable deriva |
| Multivariada (dataset entero) | Detecta derivas sutiles (correlaciones) |
| Por segmento (cohorte, geografía) | Detecta derivas localizadas |
| Por ventana de tiempo | Tendencia temporal (día, semana, mes) |
8. Frecuencia de análisis
va-plus-loin
Este artículo cubre los extractos más útiles — el curso completo ML Model Monitoring (7 capítulos, 24 lecciones, ejercicios corregidos y proyecto final) te lleva hasta el final.
./acceder-al-curso-completo curso gratuito: Dominar Claude CodeFAQ
¿Cuánto tiempo se necesita para aprender ML Model Monitoring?
Con una progresión estructurada (7 capítulos, 24 lecciones cortas y prácticas), se alcanza un nivel operativo en unas semanas dedicando 30-60 minutos al día. Lo importante es practicar cada concepto de inmediato.
¿Se necesitan requisitos previos?
Con nociones básicas de informática basta. Si sabes usar un terminal y leer código sencillo, estás listo.
¿Por dónde empezar de forma concreta?
Reproduce los comandos de este artículo y luego sigue el curso completo ML Model Monitoring: encadena las 24 lecciones en orden, con ejercicios y proyecto final.
./a-lire-aussi
→ Docker Containerization explicado de forma sencilla (con diagramas y código real)→ Dominar Linux explicado de forma sencilla (con diagramas y código real)→ Python Seguridad Puertos Linux: los 9 pasos clave para pasar de cero a operativo📬 ¿Quieres recibir este tipo de guía cada semana? Suscríbete gratis — código real, cero relleno.