Deteccion de Drift y Configuracion de Alertas en Produccion

El Fallo Silencioso de los Modelos ML

Los modelos de machine learning se degradan en produccion, y lo hacen de forma silenciosa. A diferencia de un servicio web que se cae con un stack trace o una base de datos que se queda sin espacio en disco, un modelo que sufre drift sigue devolviendo predicciones. Los codigos HTTP son todos 200. La latencia esta dentro de los limites. Todos los health checks pasan. Pero las predicciones se vuelven progresivamente menos precisas a medida que la relacion entre los datos de entrada y el mundo real se desplaza bajo los pies del modelo.

Esto es el drift, y es la causa mas comun de fallo de modelos ML en produccion. Un modelo entrenado con el comportamiento de clientes del ano pasado puede no capturar las preferencias de este ano. Un modelo de deteccion de fraude entrenado antes de que surgiera un nuevo vector de ataque pasara por alto el nuevo patron por completo. Un modelo de prediccion de demanda entrenado durante condiciones economicas estables producira predicciones poco fiables durante una recesion.

La deteccion de drift y la configuracion de alertas son las practicas que convierten un fallo silencioso en un evento observable y accionable. En lugar de descubrir la degradacion semanas despues a traves de metricas de negocio en declive, la detectas en cuestion de horas y respondes antes de que se produzca un dano significativo.

Tipos de Drift

Comprender las distintas formas de drift es esencial para configurar un monitoreo efectivo. Cada tipo tiene causas diferentes, metodos de deteccion distintos y estrategias de remediacion propias.

Data Drift

El data drift, tambien llamado covariate shift, ocurre cuando la distribucion de los features de entrada cambia entre el momento del entrenamiento y el momento de la inferencia. La relacion aprendida por el modelo entre features y variable objetivo puede seguir siendo valida, pero el modelo ahora opera sobre datos que se ven diferentes de aquellos con los que fue entrenado.

Por ejemplo, un modelo entrenado con datos de transacciones donde el monto promedio era de 50 dolares puede empezar a recibir transacciones con un promedio de 200 dolares debido a patrones de compra estacionales o un cambio en la mezcla de productos. Las distribuciones de features se han desplazado, y el modelo puede estar haciendo predicciones en regiones del espacio de features donde tiene datos de entrenamiento limitados.

El data drift es la forma mas facil de detectar porque solo requiere los features de entrada, no las etiquetas de verdad fundamental. Se pueden comparar las distribuciones actuales de features contra las distribuciones de entrenamiento y senalar desviaciones significativas.

Concept Drift

El concept drift ocurre cuando la relacion entre los features de entrada y la variable objetivo cambia. Los features pueden seguir teniendo las mismas distribuciones, pero el mapeo de features a resultados se ha desplazado. Esto es mas peligroso que el data drift porque las predicciones del modelo se vuelven sistematicamente incorrectas aunque las entradas parezcan normales.

Un ejemplo clasico es el credit scoring. Los factores que predicen el impago pueden cambiar durante una recesion economica. Los ingresos y el historial laboral significaban una cosa en una economia estable y algo diferente durante una crisis. Las distribuciones de features podrian no cambiar dramaticamente (las personas siguen teniendo el mismo rango de ingresos), pero la relacion predictiva entre ingresos y riesgo de impago se ha alterado.

El concept drift requiere etiquetas de verdad fundamental para ser detectado directamente. Dado que las etiquetas suelen llegar con retraso (no sabes si un cliente abandono hasta que cierra la ventana de abandono), la deteccion de concept drift tipicamente se basa en monitorear metricas de calidad de prediccion sobre ventanas deslizantes y buscar una degradacion sostenida.

Prediction Drift

El prediction drift se centra en la distribucion de las salidas del modelo en lugar de sus entradas. Si las predicciones del modelo se desplazan significativamente (por ejemplo, la probabilidad promedio de churn predicha aumenta del 8% al 15%), esto puede indicar un problema subyacente incluso si no se ha identificado data drift ni concept drift especifico.

El prediction drift es una senal agregada muy util. Puede detectar problemas que la deteccion de drift a nivel de feature individual no capta, como interacciones entre features que se han desplazado solo ligeramente de forma individual pero que juntas producen un cambio grande en las predicciones.

Indice de Estabilidad Poblacional

El Indice de Estabilidad Poblacional (PSI, por sus siglas en ingles) es la metrica principal que CorePlexML utiliza para la deteccion de drift. El PSI mide cuanto ha cambiado la distribucion de un feature entre dos periodos de tiempo comparando la frecuencia de valores a traves de bins.

Para un feature numerico, el PSI divide el rango de valores en bins (tipicamente 10 a 20) basandose en los cuantiles de la distribucion de entrenamiento. Para cada bin, calcula la proporcion de valores en los datos de entrenamiento y la proporcion en los datos actuales, y luego computa una divergencia ponderada. Para features categoricos, cada categoria se trata como un bin.

La formula para un bin individual es: (proporcion_actual - proporcion_esperada) multiplicado por el logaritmo natural de (proporcion_actual dividido entre proporcion_esperada). El PSI total es la suma a traves de todos los bins.

Los valores de PSI tienen umbrales de interpretacion bien establecidos. Un PSI por debajo de 0.1 indica que no hay drift significativo y las distribuciones son esencialmente estables. Un PSI entre 0.1 y 0.25 indica drift moderado que justifica investigacion. Un PSI superior a 0.25 indica drift significativo que probablemente requiere accion, como re-entrenar el modelo o investigar la fuente de datos.

Configuracion del Monitoreo de Drift

El monitoreo de drift de CorePlexML se ejecuta continuamente en segundo plano, comparando los datos de solicitud de prediccion actuales contra la distribucion de entrenamiento a intervalos configurables:

from coreplexml import CorePlexClient

client = CorePlexClient(
    base_url="https://api.coreplexml.io",
    api_key="your-api-key"
)

# Configure drift monitoring for a deployment
drift_config = client.monitoring.configure_drift(
    deployment_id="dep_fraud_v3",
    config={
        "evaluation_window_minutes": 60,
        "reference_dataset_version_id": "dsv_train_2025q4",
        "features_to_monitor": "all",
        "psi_bins": 20,
        "thresholds": {
            "feature_psi_warning": 0.1,
            "feature_psi_critical": 0.25,
            "overall_drift_warning": 0.15,
            "overall_drift_critical": 0.30
        },
        "prediction_drift": {
            "enabled": True,
            "window_size_hours": 24,
            "comparison_window_size_hours": 168
        }
    }
)

print(f"Drift monitoring configured for deployment: {drift_config.deployment_id}")
print(f"Monitoring {drift_config.feature_count} features")
print(f"Evaluation interval: every {drift_config.evaluation_window_minutes} minutes")

El parametro features_to_monitor puede establecerse como "all" para monitorear cada feature de entrada, o puedes especificar una lista de nombres de features para enfocarte en los mas importantes. Monitorear todos los features proporciona cobertura completa pero puede generar ruido si algunos features son naturalmente volatiles. Un punto intermedio comun es monitorear todos los features pero solo alertar sobre los principales por importancia.

La seccion prediction_drift habilita el monitoreo de la distribucion de salida del modelo. Compara la distribucion de predicciones en una ventana reciente (24 horas en este ejemplo) contra una ventana de linea base mas amplia (168 horas, o una semana). Esto permite captar cambios en el comportamiento del modelo que podrian no ser visibles a nivel de feature individual.

El Sistema de Alertas

La deteccion de drift solo es util si desencadena una respuesta. El sistema de alertas de CorePlexML soporta seis metricas configurables, cada una orientada a un aspecto diferente de la salud del modelo:

• drift_psi: Se dispara cuando el PSI general o el PSI de algun feature individual supera un umbral
• accuracy_degradation: Se dispara cuando la precision de las predicciones cae por debajo de un nivel definido (requiere etiquetas de verdad fundamental)
• error_rate: Se dispara cuando el porcentaje de solicitudes de prediccion fallidas supera un umbral
• latency_p99: Se dispara cuando el tiempo de respuesta en el percentil 99 supera un limite
• model_staleness: Se dispara cuando el modelo no ha sido re-entrenado dentro de un periodo definido
• prediction_anomaly: Se dispara cuando la distribucion de predicciones se desvia significativamente del rango esperado

Creacion de Canales de Alerta

Antes de crear reglas de alerta, se configuran los canales a traves de los cuales se entregan las alertas. CorePlexML soporta Slack, email y webhooks genericos:

# Create a Slack alert channel
slack_channel = client.alerts.create_channel(
    project_id="proj_abc123",
    name="ML Team Slack",
    channel_type="slack",
    config={
        "webhook_url": "https://hooks.slack.com/services/T00/B00/xxxxx",
        "channel_name": "#ml-alerts",
        "mention_on_critical": "@ml-oncall"
    }
)

# Create an email alert channel
email_channel = client.alerts.create_channel(
    project_id="proj_abc123",
    name="ML Team Email",
    channel_type="email",
    config={
        "recipients": [
            "ml-team@company.com",
            "data-engineering@company.com"
        ],
        "subject_prefix": "[CorePlexML Alert]"
    }
)

# Create a webhook channel for integration with PagerDuty or custom systems
webhook_channel = client.alerts.create_channel(
    project_id="proj_abc123",
    name="PagerDuty Integration",
    channel_type="webhook",
    config={
        "url": "https://events.pagerduty.com/v2/enqueue",
        "method": "POST",
        "headers": {
            "Content-Type": "application/json",
            "Authorization": "Token token=your-pagerduty-token"
        },
        "payload_template": {
            "routing_key": "your-routing-key",
            "event_action": "trigger",
            "payload": {
                "summary": "{{alert_name}}: {{metric_value}}",
                "severity": "{{severity}}",
                "source": "coreplexml"
            }
        }
    }
)

Creacion de Reglas de Alerta

Las reglas de alerta conectan una condicion sobre una metrica con uno o mas canales. Cada regla define que monitorear, cuando dispararse y donde enviar las notificaciones:

# Alert on high drift
drift_alert = client.alerts.create_rule(
    deployment_id="dep_fraud_v3",
    name="Fraud model drift warning",
    metric="drift_psi",
    condition="greater_than",
    threshold=0.15,
    severity="warning",
    channels=[slack_channel.id],
    evaluation_window_minutes=60,
    cooldown_minutes=240,
    description="Overall PSI drift score exceeds warning threshold"
)

# Alert on critical drift with escalation
drift_critical = client.alerts.create_rule(
    deployment_id="dep_fraud_v3",
    name="Fraud model drift critical",
    metric="drift_psi",
    condition="greater_than",
    threshold=0.30,
    severity="critical",
    channels=[slack_channel.id, email_channel.id, webhook_channel.id],
    evaluation_window_minutes=30,
    cooldown_minutes=60,
    description="Overall PSI drift score exceeds critical threshold"
)

# Alert on accuracy degradation
accuracy_alert = client.alerts.create_rule(
    deployment_id="dep_fraud_v3",
    name="Fraud model accuracy drop",
    metric="accuracy_degradation",
    condition="less_than",
    threshold=0.90,
    severity="critical",
    channels=[slack_channel.id, webhook_channel.id],
    evaluation_window_minutes=120,
    cooldown_minutes=360,
    description="Model accuracy has dropped below 90% threshold"
)

# Alert on model staleness
staleness_alert = client.alerts.create_rule(
    deployment_id="dep_fraud_v3",
    name="Fraud model staleness",
    metric="model_staleness",
    condition="greater_than",
    threshold=30,
    severity="warning",
    channels=[email_channel.id],
    evaluation_window_minutes=1440,
    cooldown_minutes=1440,
    description="Model has not been retrained in 30+ days"
)

Niveles de Severidad y Escalamiento

CorePlexML soporta tres niveles de severidad: info, warning y critical. El nivel de severidad determina la urgencia de la notificacion y puede usarse para enrutar alertas a diferentes canales. Un patron comun es enviar alertas de tipo info y warning solo a Slack, mientras que las alertas critical se envian simultaneamente a Slack, email y PagerDuty.

El parametro cooldown_minutes previene la fatiga de alertas al suprimir notificaciones duplicadas durante un periodo configurado despues de que se dispara una alerta. Sin cooldown, un modelo con drift generaria una nueva alerta en cada ciclo de evaluacion hasta que el drift se resuelva, potencialmente inundando tus canales con cientos de notificaciones identicas.

Ventanas de Supresion

Durante mantenimientos planificados, migraciones de datos o cambios conocidos en el pipeline de datos, puede ser conveniente suprimir temporalmente las alertas para evitar falsos positivos:

# Create a suppression window for planned maintenance
suppression = client.alerts.create_suppression(
    deployment_id="dep_fraud_v3",
    name="Q1 data migration window",
    start_time="2026-03-15T02:00:00Z",
    end_time="2026-03-15T06:00:00Z",
    suppress_severities=["warning", "info"],
    notes="Planned data pipeline migration. "
          "Critical alerts remain active."
)

Observa que la ventana de supresion solo suprime alertas de nivel warning e info. Las alertas critical permanecen activas incluso durante el mantenimiento, porque los problemas verdaderamente criticos (como una tasa de error del 50%) necesitan atencion inmediata independientemente de las actividades planificadas.

Politicas de Re-entrenamiento Automatico

Detectar el drift es solo la mitad de la solucion. Cerrar el ciclo implica re-entrenar automaticamente el modelo cuando se detecta drift, validar el nuevo modelo y promoverlo a produccion si cumple los umbrales de calidad.

CorePlexML soporta tres tipos de disparadores de re-entrenamiento: programado, basado en drift y basado en rendimiento.

Re-entrenamiento Programado

El re-entrenamiento programado se ejecuta en una cadencia fija independientemente de si se ha detectado drift. Esto garantiza la frescura del modelo para aplicaciones donde los datos se acumulan a un ritmo predecible:

scheduled_policy = client.retraining.create_policy(
    deployment_id="dep_fraud_v3",
    name="Weekly fraud model refresh",
    trigger="schedule",
    schedule_config={
        "frequency": "weekly",
        "day_of_week": "sunday",
        "hour_utc": 3,
        "timezone": "UTC"
    },
    training_config={
        "max_runtime_secs": 900,
        "max_models": 30,
        "stopping_metric": "AUC",
        "balance_classes": True
    },
    validation_config={
        "min_improvement": 0.0,
        "validation_dataset_version_id": "dsv_holdout_2026q1",
        "metrics_to_compare": ["auc", "precision", "recall"]
    },
    auto_promote=True,
    promotion_strategy="canary"
)

Re-entrenamiento por Drift

El re-entrenamiento disparado por drift se activa cuando el sistema de monitoreo detecta drift significativo, proporcionando una respuesta reactiva a los cambios del entorno:

drift_policy = client.retraining.create_policy(
    deployment_id="dep_fraud_v3",
    name="Drift-triggered fraud retrain",
    trigger="drift",
    drift_config={
        "metric": "drift_psi",
        "threshold": 0.25,
        "sustained_minutes": 120
    },
    training_config={
        "max_runtime_secs": 600,
        "max_models": 20,
        "stopping_metric": "AUC",
        "balance_classes": True
    },
    validation_config={
        "min_improvement": 0.005,
        "metrics_to_compare": ["auc", "precision"]
    },
    auto_promote=False,
    max_retrains_per_week=3
)

El parametro sustained_minutes requiere que el drift persista durante un tiempo minimo antes de disparar el re-entrenamiento. Esto evita re-entrenamientos espurios causados por anomalias transitorias en los datos que se resuelven solas. El parametro max_retrains_per_week limita el numero de re-entrenamientos automatizados para prevenir un consumo descontrolado de recursos durante periodos de alta volatilidad.

Re-entrenamiento por Rendimiento

El re-entrenamiento basado en rendimiento se dispara cuando la calidad de las predicciones cae por debajo de un umbral definido. A diferencia del re-entrenamiento por drift, que responde a cambios en las entradas, este responde a cambios en los resultados:

performance_policy = client.retraining.create_policy(
    deployment_id="dep_fraud_v3",
    name="Performance-triggered fraud retrain",
    trigger="performance",
    performance_config={
        "metric": "auc",
        "threshold": 0.88,
        "evaluation_window_days": 7,
        "min_samples": 10000
    },
    training_config={
        "max_runtime_secs": 600,
        "max_models": 20,
        "stopping_metric": "AUC"
    },
    validation_config={
        "min_improvement": 0.01,
        "metrics_to_compare": ["auc", "precision", "recall"]
    },
    auto_promote=True,
    promotion_strategy="canary"
)

El requisito de min_samples asegura que la metrica de rendimiento se calcule sobre suficientes datos para ser fiable. Sin esta proteccion, un pequeno numero de ejemplos mal etiquetados podria disparar un re-entrenamiento innecesario.

Validacion del Re-entrenamiento

Ya sea disparado por programacion, drift o rendimiento, cada trabajo de re-entrenamiento automatizado pasa por un paso de validacion antes de que el nuevo modelo pueda ser promovido. CorePlexML compara las metricas del modelo candidato contra el modelo de produccion actual y aplica el umbral min_improvement.

Si auto_promote es verdadero y el candidato cumple el umbral de mejora, se despliega utilizando la estrategia de promocion especificada (tipicamente canary). Si el candidato no cumple el umbral, se registra en el registro de modelos con etapa "development" y se envia una alerta notificando al equipo que el re-entrenamiento automatizado no produjo una mejora.

Este paso de validacion es critico. Re-entrenar con datos que presentan drift no garantiza un modelo mejor. Si el drift es causado por un problema de calidad de datos (un pipeline roto, etiquetas incorrectas o features corruptos), re-entrenar con datos malos producira un modelo malo. El paso de validacion captura esto al requerir que el nuevo modelo supere al actual en un conjunto de validacion retenido.

El Flujo de Trabajo End-to-End

Cuando todos los componentes estan configurados, el sistema de monitoreo y re-entrenamiento opera como un ciclo cerrado:

• El sistema de monitoreo de drift evalua las distribuciones de features y predicciones a intervalos configurados.
• Cuando el drift supera un umbral, se dispara una alerta a traves de los canales configurados, notificando al equipo.
• Si existe una politica de re-entrenamiento configurada para el disparador detectado, se encola automaticamente un trabajo de re-entrenamiento.
• El trabajo de re-entrenamiento entrena un nuevo modelo utilizando los datos mas recientes disponibles.
• El paso de validacion compara el candidato contra el modelo de produccion actual.
• Si el candidato cumple el umbral de mejora y auto-promote esta habilitado, se despliega mediante un rollout canary.
• El despliegue canary monitorea la salud del nuevo modelo y avanza al trafico completo o hace rollback automaticamente.
• El registro de modelos graba la cadena completa: el evento de drift, el trabajo de re-entrenamiento, los resultados de validacion, el despliegue y el resultado final.

Este ciclo cerrado transforma el mantenimiento de modelos de un proceso manual y reactivo en uno automatizado y proactivo. El equipo sigue siendo notificado en cada paso y conserva la capacidad de intervenir (deshabilitando auto-promote o ajustando umbrales), pero el trabajo rutinario de monitoreo, re-entrenamiento y despliegue ocurre sin intervencion humana.

Mejores Practicas

Combina multiples disparadores de re-entrenamiento. El re-entrenamiento programado proporciona una garantia base de frescura, el re-entrenamiento por drift responde a cambios ambientales y el re-entrenamiento por rendimiento captura la degradacion de cualquier causa. Juntos, ofrecen una cobertura integral.

Establece umbrales de auto-promote conservadores. Una mejora minima del 0% significa que el nuevo modelo solo necesita igualar al actual. Un umbral del 1% o superior proporciona una senal mas fuerte de que el nuevo modelo es genuinamente mejor, no simplemente diferente.

Monitorea a los monitores. Revisa tus metricas de drift y el historial de alertas de forma regular. Si recibes falsas alarmas frecuentes, tus umbrales pueden ser demasiado sensibles. Si nunca recibes alertas, tus umbrales pueden ser demasiado laxos, o tu monitoreo podria no estar funcionando como se espera.

Usa ventanas de supresion con criterio. Las ventanas de supresion son una herramienta necesaria para periodos de mantenimiento, pero deben ser cortas y estar bien documentadas. Una ventana de supresion olvidada que dura semanas anula por completo el proposito del monitoreo.

Documenta tus rutas de escalamiento. Cuando una alerta critica se dispara a las 3 AM, el ingeniero de guardia necesita saber exactamente que hacer. Documenta los procedimientos de respuesta para cada tipo de alerta: a quien contactar, que dashboards consultar y que acciones de remediacion estan disponibles.

La deteccion de drift y las alertas no son opcionales para ML en produccion. Son la capa de observabilidad que convierte un modelo desplegado de una caja negra en un sistema gestionado. Invierte en configurarlas de forma cuidadosa, y protegeran tus modelos, tus usuarios y tu negocio de los fallos silenciosos que hacen del ML en produccion un desafio tan grande.

Para mas informacion sobre la infraestructura de monitoreo y re-entrenamiento de CorePlexML, visita la pagina de funcionalidades MLOps.