El monitoreo de modelos en producción es la fase de MLOps que garantiza que tus predicciones sigan siendo confiables después del despliegue. Aquí aprenderás cómo vigilar la calidad de los datos, detectar data drift y concept drift, y elegir métricas según el tipo de serving que uses.

¿Qué estrategias existen para monitorear un modelo en producción?

Hay dos enfoques que conviene combinar para tener un control real sobre el comportamiento del modelo en vivo.

La primera estrategia es comparar contra un modelo baseline, una versión más sencilla que sirve de referencia [01:00]. A veces, los modelos en producción son demasiado complejos y un baseline basado en reglas o heurísticas funciona igual o mejor. El baseline responde a una pregunta concreta: ¿realmente vale la pena mantener algo tan complejo en producción?

La segunda estrategia, y la más importante, es monitorear el modelo actualmente en producción comparando dos conjuntos de datos [02:30]:

• Data actual: las predicciones más recientes, por ejemplo el último batch.
• Data de referencia: los datos con los que se entrenó originalmente el modelo.

Si entra una población nueva que el modelo nunca vio, las predicciones se degradan. Esa es la señal para reentrenar o incluso replantear el diseño.

¿Qué se puede identificar al monitorear un modelo?

Monitorear va más allá de revisar si el modelo acierta. Hay tres focos críticos: calidad de datos, data drift y concept drift.

¿Por qué importa la calidad de los datos en producción?

La calidad de los datos o data quality exige almacenar tanto el input raw como su representación procesada [04:10]. En un problema de clasificación de tickets, el input es texto, pero el modelo consume vectores numéricos. Si de un momento a otro aumentan los datos faltantes, errores o inconsistencias, es señal de volver a las etapas de limpieza y procesamiento.

¿Qué es data quality en MLOps? Es el monitoreo de la entrada del modelo, tanto los datos crudos como su representación procesada, para detectar valores faltantes, errores o inconsistencias antes de que afecten las predicciones.

¿Qué es el data drift y cuándo aparece?

El data drift ocurre cuando la distribución de los datos nuevos difiere significativamente de la usada en entrenamiento [05:30]. Si entrenaste con una región o población específica y mañana llegan datos de una distribución desconocida, las predicciones se vuelven anómalas. La acción correcta es reentrenar con esa nueva población para que el modelo la incorpore.

¿Qué es el concept drift y cómo se diferencia?

El concept drift se refiere a un cambio en la relación entre tus features y tu target [07:00]. Imagina una inmobiliaria que predice precios de alquiler con tres variables: número de habitaciones, número de baños y ubicación. Las variables siguen siendo las mismas, pero con el tiempo la ubicación gana muchísimo más peso sobre el precio. La relación cambió, no los datos. Eso obliga a integrar alarmas o triggers para reentrenar y, si no basta, volver a la etapa de diseño.

¿Cuál es la diferencia entre data drift y concept drift? El data drift es un cambio en la distribución de las variables de entrada. El concept drift es un cambio en cómo esas variables se relacionan con la variable que quieres predecir.

¿Cómo obtener estas métricas en producción?

No basta con guardar predicciones. Necesitas almacenar también las características o features que entran al modelo, porque son la base para los análisis de data drift y concept drift comparando data actual contra data de referencia [09:00].

No olvides las métricas operacionales: consumo de memoria, CPU, GPU y otros recursos. Si mañana toca escalar y la iniciativa no tiene presupuesto suficiente, esas métricas son las que te permiten optimizar la arquitectura para que sea más escalable sin disparar el costo.

¿Qué métricas usar según el tipo de serving?

Las métricas dependen de cómo despliegas el modelo. Las dos formas más comunes son batch serving y real time serving.

Batch serving

En batch serving divides los datos en lotes de N elementos y obtienes N predicciones [10:30]. Aquí interesan:

• Métricas de predicción cuando hay target disponible: accuracy, precisión, exactitud.
• Tasa de procesamiento y tasa de ejecución.
• Métricas de infraestructura, aunque con menos exigencia que en tiempo real.

Un ejemplo: un sistema de recomendación predice si un cliente va a comprar en una página web. Cuando el cliente compra (o no), tienes el target real y puedes calcular métricas de desempeño.

Real time serving

En real time serving las predicciones son bajo demanda y las métricas cambian de naturaleza [12:00]:

• Latencia.
• Tasa de solicitudes.
• Tráfico de red y ancho de banda.
• Capacidad de almacenamiento y memoria.

Aquí no importa tanto la precisión como la velocidad de respuesta. Por eso necesitas tener bien definidos los requerimientos de infraestructura antes de disponibilizar el modelo.

¿Cuándo activar el trigger de reentrenamiento?

Esta es la pregunta práctica que cierra el ciclo. Para detectar drift puedes apoyarte en librerías open source como Evidently [14:00], pero el umbral de tolerancia lo define tu negocio.

No existe una regla universal del tipo: hay fuga de datos por encima de 0.4 o 0.5. Ese valor depende del método estadístico que uses, ya sea una anomalía en la media, una desviación estándar fuera de rango, u otra técnica. Lo importante es que tu equipo defina qué es tolerable y qué no, según el método y el impacto en el negocio.

¿Qué métricas estás monitoreando hoy en tus modelos en producción? Cuéntalo en los comentarios.