En el módulo anterior dejamos tu modelo servido como API: recibe features, devuelve predicciones, responde rápido. Funciona. Y ahí está la trampa — “funciona” para un servicio significa que responde sin errores, pero un modelo puede responder perfecto y estar equivocándose en cada predicción. El endpoint está sano; el modelo, muerto por dentro. En el módulo 1 lo dijimos: el fallo peligroso de un modelo no lanza excepción. Este módulo te da los ojos para ver esa muerte silenciosa antes de que un cliente la vea por ti.

La tesis del módulo

Monitorear software es preguntar “¿respondió?”; monitorear un modelo es preguntar “¿acertó?” — y esas son preguntas distintas. El software no cambia solo: si no lo tocas, sigue igual. Un modelo se degrada porque el MUNDO cambia bajo sus pies, sin que nadie edite una línea. Por eso el monitoreo de un modelo tiene tres capas, no una.

Monitorear un modelo no es monitorear software

Cuando monitoreas un servicio web común, vigilas que responda: que no tire errores, que no se demore, que no se caiga. Eso sigue valiendo para un modelo — pero es apenas la capa de afuera. Un modelo puede tener latencia perfecta, cero errores HTTP, uptime del 100%… y estar prediciendo basura porque los datos que le llegan hoy no se parecen a los que vio al entrenar.

La diferencia está en qué puede fallar. En software, el fallo es un crash: visible, ruidoso, con traceback. En un modelo, el fallo es una degradación: silenciosa, gradual, sin ningún error. El servicio te dice “todo bien” mientras el acierto se desangra. Monitorear un modelo es, entonces, vigilar tres cosas a la vez.

Las tres capas del monitoreo

Capa 1 — métricas operativas. Es la observabilidad clásica de cualquier servicio: latencia, tasa de error, throughput, uso de recursos. Esto ya lo cubrimos como base en Observabilidad y seguridad del curso de Deploy: logs estructurados, tracing, percentiles p95/p99 en vez de promedios. No lo repetimos — lo damos por sabido y construimos encima. Si esta capa falla, el problema es de infraestructura, no de modelo.

Capa 2 — métricas de datos. Aquí empieza lo propio de MLOps. Vigilas las distribuciones de las entradas: cómo se ven las features que le están llegando al modelo en producción, comparadas con las que vio al entrenar. Si al modelo lo entrenaste con clientes de edad promedio 35 y hoy le llegan de edad promedio 55, algo cambió en el mundo — y el modelo no se enteró. Esta capa detecta el problema antes de que el desempeño caiga, porque las entradas cambian antes que el resultado se note.

Capa 3 — métricas de modelo. Las predicciones mismas y, cuando se puede, el desempeño real. Vigilas cómo se distribuyen las predicciones (si de golpe el modelo aprueba a casi todos los solicitantes cuando antes rechazaba a la mitad, sospecha) y, sobre todo, comparas predicción contra realidad cuando la realidad llega. Esa “realidad” tiene nombre: ground truth (glosado: la etiqueta verdadera, el resultado real que el modelo intentaba predecir — si predijo “este cliente pagará” y meses después efectivamente pagó o no, ese “sí pagó / no pagó” es el ground truth).

El problema del ground truth: llega tarde

Acá está el detalle que hace difícil el monitoreo de modelos y que el software nunca sufre. En un test de software sabes al instante si pasó o falló. En un modelo, el ground truth suele llegar con retraso — a veces enorme.

Piénsalo con un modelo de riesgo crediticio: predices hoy que un cliente pagará su crédito a 24 meses. ¿Cuándo sabes si acertaste? En 24 meses. Para entonces, si el modelo se equivocó, ya prestó mal miles de veces. El ground truth existe, pero llega tarde y te deja ciego durante el intervalo.

Por eso las capas 2 y 3 no son redundantes: mientras esperas el ground truth (capa 3, desempeño real), la capa 2 (distribuciones de entrada) es tu alarma temprana. Un cambio en las entradas hoy predice una caída de desempeño que solo confirmarás dentro de meses. El data drift es la señal que llega a tiempo justamente porque no necesita el ground truth.

No confundas “el modelo responde” con “el modelo acierta”. Un dashboard de latencia verde no dice nada sobre la calidad de las predicciones. Puedes tener el mejor uptime del mercado sirviendo predicciones equivocadas. La capa operativa es necesaria pero jamás suficiente.

El flujo del monitoreo de un modelo

 producción                       ground truth
 (predicciones)                   (llega con delay)
     │                                  │
     ▼                                  ▼
 ┌──────────────────┐          ┌──────────────────┐
 │ log de features  │          │ etiquetas reales │
 │ + predicción     │          │ (días o meses    │
 │ + timestamp      │          │  después)        │
 └────────┬─────────┘          └────────┬─────────┘
          │                             │
          └──────────────┬──────────────┘
                         ▼
              ┌────────────────────┐
              │ comparar contra la │
              │ referencia (train) │
              └─────────┬──────────┘
                        ▼
              ┌────────────────────┐
              │ dashboards +       │
              │ alertas de drift   │
              └────────────────────┘

La clave operativa: loguea cada predicción con sus features y un timestamp, y guarda un identificador para poder unirla después con el ground truth cuando llegue. Sin ese log, cuando la etiqueta real aparezca en tres meses no tendrás con qué compararla.

Las señales que se monitorean en un modelo

Señal	Capa	Qué mide	Por qué importa
Latencia p95/p99	Operativa	Tramo lento de respuestas	El servicio sano no garantiza modelo sano, pero un servicio lento igual duele
Tasa de error	Operativa	% de requests que fallan	Fallo de infra, no de modelo — pero hay que verlo
Data drift	Datos	Cambio en la distribución de las entradas	Alarma temprana: cambia antes que el desempeño
Distribución de predicciones	Modelo	Cómo reparte el modelo sus salidas	Un vuelco brusco delata que algo cambió
Desempeño real	Modelo	Accuracy / F1 vs ground truth	La verdad final — pero llega tarde
Volumen de tráfico	Operativa	Cuántas predicciones por hora	Un bajón puede significar que algo aguas arriba se rompió

La fila que separa MLOps de DevOps es data drift: es la única señal que te avisa a tiempo, y es el tema completo del próximo módulo.

Un reporte real con Evidently

Evidently es una librería open source de Python para monitoreo de modelos: compara un dataset de referencia (típicamente el de entrenamiento o una ventana estable) contra el actual (lo que llega en producción) y genera reportes de drift y calidad. Junto a plataformas administradas como Arize (lo mismo, a mayor escala y con servicio), es de las herramientas estándar del oficio.

El siguiente código arma un reporte comparando referencia contra producción con la API actual de Evidently — la que es default desde la versión 0.7 (abril de 2025): from evidently import Report y presets desde evidently.presets. Si ves tutoriales con from evidently.report import Report o evidently.metric_preset, son de la API antigua, que ya no existe en las versiones actuales.

import pandas as pd
from evidently import Report
from evidently.presets import DataDriftPreset, DataSummaryPreset

# referencia: los datos con que se entrenó (distribución "sana").
# actual: lo que está llegando en producción ahora.
# Ambos son DataFrames de pandas con las MISMAS columnas de features.
referencia = pd.read_parquet("features_entrenamiento.parquet")
actual = pd.read_parquet("features_produccion_ultima_semana.parquet")

# Un Report agrupa métricas. Los presets son paquetes listos:
# DataDriftPreset revisa drift en cada columna; DataSummaryPreset
# revisa nulos, rangos y estadísticas básicas.
reporte = Report([
    DataDriftPreset(),
    DataSummaryPreset(),
])

# run() calcula todo comparando ambos DataFrames y devuelve un snapshot.
snapshot = reporte.run(current_data=actual, reference_data=referencia)

# El snapshot se puede guardar como HTML (para revisar a ojo) o
# extraer como dict/JSON (para automatizar alertas en un pipeline).
snapshot.save_html("reporte_monitoreo.html")
resultado = snapshot.dict()

# En un job automatizado NO abres el HTML: lees el dict y decides.
# La métrica DriftedColumnsCount del preset dice cuántas columnas
# driftearon (count) y qué fracción del total son (share).
drift = next(m for m in resultado["metrics"]
             if m["metric_name"].startswith("DriftedColumnsCount"))
share = drift["value"]["share"]
hubo_drift = share >= 0.5   # umbral por defecto del preset (drift_share)
print(f"Columnas con drift: {share:.0%} -> ¿dataset en drift? {hubo_drift}")

La gracia: ese hubo_drift es un booleano que un pipeline puede leer para disparar una alerta o, más adelante, un reentrenamiento. El HTML es para que un humano investigue; el dict() es para que la máquina decida sola.

El monitoreo que exige que alguien mire el HTML todos los días ya fracasó. Igual que las alertas del curso de Deploy: define umbrales, extrae la señal como dato y que la alerta te busque a ti. Un reporte hermoso que nadie abre a las 3 AM no salvó jamás a un modelo.

Errores comunes

Monitorear solo la capa operativa. Latencia y errores verdes no dicen nada sobre si el modelo acierta. Es el error más caro porque da falsa tranquilidad.
No loguear las predicciones con sus features. Cuando el ground truth llegue en tres meses, no tendrás con qué compararlo. El log se arma antes, no cuando lo necesitas.
Esperar el ground truth para reaccionar. Si tu etiqueta real tarda meses, esperar es prestar mal miles de veces. El data drift (capa 2) es la alarma que llega a tiempo.
Monitorear el promedio en vez de percentiles. Misma lección de siempre: el promedio esconde a los casos que sufren. p95/p99 o nada.
Comparar producción contra una referencia mal elegida. Si tu referencia no representa el estado “sano” del modelo, cada comparación miente. La referencia suele ser el set de entrenamiento o una ventana estable reciente.

La frase para llevarse

“Un servicio sano responde; un modelo sano acierta. El monitoreo de MLOps existe para vigilar la segunda pregunta — porque un modelo puede tener el mejor uptime del mundo mientras se equivoca en silencio en cada predicción.”

Qué viene

Módulo 10: drift, el corazón de MLOps. Ya sabes que hay que vigilar las distribuciones; ahora veremos por qué cambian y cómo medirlo con rigor. La diferencia entre data drift y concept drift, los tests estadísticos que lo detectan (KS, PSI) y el reporte de Evidently que lo automatiza. Es la razón por la que un modelo se pudre solo.

MLOps — Módulo 9: monitoreo de modelos — lo que no ves te degrada