Despliegues Seguros de Modelos con Deployments Canary

El Problema del Deployment

Desplegar un modelo de machine learning a produccion es fundamentalmente diferente de desplegar software tradicional. Cuando publicas una nueva version de una aplicacion web, puedes escribir tests de integracion que verifiquen que la salida es correcta para inputs conocidos. Cuando publicas un nuevo modelo, la correccion es probabilistica. El modelo podria funcionar maravillosamente en tu conjunto de prueba pero comportarse inesperadamente con datos de produccion que caen fuera de la distribucion en la que fue entrenado. Un feature que siempre estuvo presente durante el entrenamiento podria llegar como null en produccion. Un valor categorico que el modelo nunca ha visto podria aparecer por primera vez. Las interacciones entre las predicciones del modelo y la logica de negocio downstream podrian producir casos extremos que ninguna evaluacion offline anticipo.

Estos modos de fallo hacen que los deployments de ML sean inherentemente mas riesgosos que las publicaciones de software tipicas. Las consecuencias van desde levemente embarazosas (un motor de recomendaciones sugiriendo productos irrelevantes) hasta financieramente catastroficas (un modelo de deteccion de fraude permitiendo una oleada de transacciones fraudulentas). La estrategia de deployment que elijas determina cuanto riesgo aceptas y que tan rapido puedes recuperarte cuando algo sale mal.

Comparacion de Estrategias de Deployment

CorePlexML soporta cuatro estrategias de deployment, cada una adecuada para diferentes perfiles de riesgo y requisitos operacionales. Entender cuando usar cada una es critico para construir una practica de ML en produccion confiable.

Deployment Directo

El deployment directo reemplaza el modelo actual con el nuevo instantaneamente. Todo el trafico cambia al nuevo modelo en una sola operacion. Esta es la estrategia mas rapida pero no ofrece red de seguridad. Si el nuevo modelo esta roto, cada usuario se ve afectado inmediatamente, y el rollback requiere un segundo deployment.

El deployment directo es apropiado solo para entornos de desarrollo, para modelos no criticos donde una degradacion breve es aceptable, o cuando ya has validado el modelo extensivamente por otros medios (como un shadow deployment completado).

Canary Deployment

El canary deployment es la estrategia principal para ML en produccion. Enruta una pequena fraccion del trafico al nuevo modelo mientras el modelo existente continua sirviendo a la mayoria. Monitoreas el comportamiento del nuevo modelo en trafico real y gradualmente aumentas su participacion si las metricas se mantienen estables. Si las metricas se degradan, el sistema automaticamente hace rollback antes de que ocurra un dano significativo.

El nombre proviene de la practica minera de enviar un canario a la mina para detectar gases toxicos. El modelo canary prueba el entorno de produccion con un radio de impacto minimo.

Blue-Green Deployment

El blue-green deployment mantiene dos entornos paralelos. El entorno blue ejecuta el modelo actual y el entorno green ejecuta el nuevo. Cuando cambias, todo el trafico se mueve de blue a green de forma atomica. Si surgen problemas, vuelves a blue instantaneamente.

La ventaja sobre canary es que el rollback es instantaneo y completo. No hay estado parcial, no hay trafico dividido, no hay necesidad de esperar a que las metricas converjan. La desventaja es el costo: ambos entornos deben estar corriendo simultaneamente, duplicando los requisitos de computo durante la ventana de transicion.

Shadow Deployment

El shadow deployment ejecuta el nuevo modelo junto al actual, procesando cada solicitud, pero nunca sirviendo sus predicciones a los usuarios. Las salidas de ambos modelos se registran y comparan offline. Esta es la estrategia mas segura porque el nuevo modelo tiene cero impacto en produccion, pero requiere la mayor cantidad de recursos (cada solicitud pasa por dos modelos) y no produce datos de resultados de negocio (ya que las predicciones shadow nunca se actuan).

Como Funcionan los Canary Deployments

Un canary deployment en CorePlexML sigue una progresion estructurada a traves de etapas de trafico. En cada etapa, el sistema evalua la salud del modelo canary contra umbrales configurables. Si el canary pasa, avanza a la siguiente etapa. Si falla, hace rollback automaticamente.

Aqui una configuracion tipica de canary:

from coreplexml import CorePlexClient

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

deployment = client.deployments.create(
    project_id="proj_abc123",
    model_id="model_gbm_v4",
    name="Fraud Detector v4 (Canary)",
    strategy="canary",
    canary_config={
        "stages": [
            {"traffic_percentage": 5, "duration_minutes": 60},
            {"traffic_percentage": 25, "duration_minutes": 120},
            {"traffic_percentage": 50, "duration_minutes": 180},
            {"traffic_percentage": 100, "duration_minutes": 0}
        ],
        "health_checks": {
            "error_rate_threshold": 0.01,
            "latency_p99_threshold_ms": 200,
            "prediction_quality_metric": "auc",
            "prediction_quality_threshold": 0.85,
            "min_samples_per_stage": 500
        },
        "auto_advance": True,
        "auto_rollback": True,
        "rollback_on_error_spike": True
    }
)

print(f"Deployment ID: {deployment.id}")
print(f"Current stage: {deployment.current_stage}")
print(f"Traffic on canary: {deployment.canary_traffic_percentage}%")

El array stages define la progresion de trafico. Cada etapa especifica un porcentaje de trafico y una duracion minima. El canary debe sobrevivir la duracion completa en cada etapa antes de avanzar. Esto asegura que picos transitorios no provoquen un avance prematuro, y que el modelo sea probado con suficiente trafico para revelar patrones que solo emergen a escala.

El parametro min_samples_per_stage agrega un requisito de conteo de muestras ademas de la duracion. Incluso si han pasado 60 minutos, el canary no avanzara del 5% de trafico hasta que haya procesado al menos 500 solicitudes. Esto previene el avance en periodos de bajo trafico donde la duracion ha transcurrido pero la evidencia estadistica es insuficiente.

Health Checks en Detalle

CorePlexML evalua la salud del canary en tres dimensiones: confiabilidad, rendimiento y calidad de prediccion.

Metricas de Confiabilidad

La tasa de error mide la fraccion de solicitudes de prediccion que resultan en errores (HTTP 5xx, timeouts, respuestas malformadas). Un modelo saludable deberia tener una tasa de error cercana a cero. El parametro error_rate_threshold define la tasa maxima aceptable. Si la tasa de error del canary excede este umbral durante cualquier ventana de evaluacion, se activa el rollback.

La tasa de exito de solicitudes es el inverso de la tasa de error pero a veces es mas facil de razonar. Un umbral de tasa de error de 0.01 equivale a requerir una tasa de exito del 99%.

Metricas de Rendimiento

Los percentiles de latencia capturan que tan rapido responde el modelo a las solicitudes de prediccion. CorePlexML rastrea la latencia p50, p95 y p99. El p99 es particularmente importante para la evaluacion canary porque revela problemas de latencia en la cola que afectan la peor experiencia de usuario. Un modelo podria tener latencia mediana aceptable pero ocasionalmente tardar varios segundos en responder debido a patrones de input que activan rutas de computacion costosas.

# Checking canary health during deployment
health = client.deployments.get_canary_health(
    deployment_id=deployment.id
)

print(f"Stage: {health.current_stage}")
print(f"Canary traffic: {health.canary_traffic_percentage}%")
print(f"Samples processed: {health.canary_samples}")
print(f"\nReliability:")
print(f"  Error rate: {health.error_rate:.4f} "
      f"(threshold: {health.error_rate_threshold})")
print(f"\nPerformance:")
print(f"  Latency p50: {health.latency_p50_ms:.1f}ms")
print(f"  Latency p95: {health.latency_p95_ms:.1f}ms")
print(f"  Latency p99: {health.latency_p99_ms:.1f}ms "
      f"(threshold: {health.latency_p99_threshold_ms}ms)")
print(f"\nPrediction Quality:")
print(f"  AUC: {health.prediction_quality:.4f} "
      f"(threshold: {health.prediction_quality_threshold})")
print(f"\nOverall: {health.status}")
print(f"Next advancement in: {health.minutes_until_advancement} minutes")

Metricas de Calidad de Prediccion

La calidad de prediccion compara las predicciones del modelo canary contra las predicciones del modelo base o contra etiquetas ground truth cuando estan disponibles. Para modelos de clasificacion, CorePlexML puede calcular AUC, accuracy, precision y recall en tiempo real recolectando pares prediccion-resultado. Para modelos de regresion, rastrea RMSE y MAE.

Cuando las etiquetas ground truth estan retrasadas (lo cual es comun en muchas aplicaciones ML), CorePlexML recurre a comparar la distribucion de predicciones del canary contra la del baseline. Una divergencia distribucional significativa, incluso sin etiquetas, puede indicar un problema.

Rollback Automatizado

El rollback automatizado es el mecanismo de seguridad que hace que los canary deployments sean practicos a escala. Sin el, un operador humano necesitaria monitorear cada deployment continuamente e intervenir manualmente si surgen problemas. Con auto-rollback, el sistema detecta problemas y se recupera sin intervencion humana.

El rollback se activa cuando cualquier metrica de health check cruza su umbral configurado. El proceso es inmediato: el trafico se redirige completamente al modelo base, el modelo canary se desactiva y se envia una alerta a todos los canales de notificacion configurados con detalles sobre que provoco el rollback.

# Configure rollback alerts
client.alerts.create(
    deployment_id=deployment.id,
    name="Canary rollback notification",
    event_type="canary_rollback",
    channels=[
        {
            "type": "slack",
            "webhook_url": "https://hooks.slack.com/services/T00/B00/xxx"
        },
        {
            "type": "email",
            "address": "ml-team@company.com"
        }
    ]
)

La alerta de rollback incluye la razon del disparo (que metrica excedio que umbral), la duracion que el canary estuvo activo, el numero de solicitudes que proceso y una comparacion de metricas entre el canary y el baseline. Esta informacion es critica para el analisis post-mortem: entender por que fallo el canary guia la investigacion que lleva a una solucion.

CorePlexML tambien soporta un modo rollback_on_error_spike que activa el rollback ante aumentos repentinos de la tasa de error incluso si la tasa absoluta permanece por debajo del umbral. Esto captura escenarios donde la tasa de error salta del 0% al 0.5% en una ventana corta, lo cual, aunque aun esta por debajo de un umbral del 1%, puede indicar un problema sistematico que esta empeorando.

Blue-Green Deployments

Para situaciones donde necesitas un cambio instantaneo y completo sin estado parcial de trafico, el blue-green deployment es la opcion apropiada:

deployment = client.deployments.create(
    project_id="proj_abc123",
    model_id="model_gbm_v4",
    name="Fraud Detector v4 (Blue-Green)",
    strategy="blue-green",
    blue_green_config={
        "rollback_window_minutes": 30,
        "health_checks": {
            "error_rate_threshold": 0.005,
            "latency_p99_threshold_ms": 150
        },
        "auto_rollback": True
    }
)

# Switch traffic from blue to green
client.deployments.switch(deployment_id=deployment.id)

# If needed, rollback is instant
# client.deployments.rollback(deployment_id=deployment.id)

El parametro rollback_window_minutes define cuanto tiempo ambos entornos permanecen activos despues del cambio. Durante esta ventana, el sistema monitorea el entorno green y automaticamente hace rollback a blue si los health checks fallan. Despues de que la ventana cierra sin problemas, el entorno blue se descomisiona.

Blue-green se prefiere sobre canary cuando el costo de servir incluso un pequeno porcentaje de trafico con un modelo malo es inaceptable. Sistemas financieros en tiempo real, aplicaciones criticas de seguridad y modelos donde predicciones individuales malas tienen altas consecuencias son buenos candidatos para blue-green deployment con una ventana de monitoreo corta.

Shadow Deployments

El shadow deployment elimina el riesgo de produccion por completo al nunca servir las predicciones del nuevo modelo a los usuarios:

deployment = client.deployments.create(
    project_id="proj_abc123",
    model_id="model_gbm_v4",
    name="Fraud Detector v4 (Shadow)",
    strategy="shadow",
    shadow_config={
        "comparison_window_days": 7,
        "log_predictions": True,
        "compare_metrics": ["auc", "precision", "recall", "latency_p99"],
        "async_inference": True
    }
)

# After the comparison window, review results
comparison = client.deployments.get_shadow_comparison(
    deployment_id=deployment.id
)

print(f"Comparison period: {comparison.start_date} to {comparison.end_date}")
print(f"Total requests compared: {comparison.total_requests}")
print(f"\n{'Metric':<20} {'Baseline':<12} {'Shadow':<12} {'Delta':<12}")
print("-" * 56)
for metric in comparison.metrics:
    print(f"{metric.name:<20} {metric.baseline_value:<12.4f} "
          f"{metric.shadow_value:<12.4f} {metric.delta:+<12.4f}")

El flag async_inference es importante para el rendimiento en produccion. Cuando esta habilitado, el modelo shadow procesa las solicitudes de forma asincrona, por lo que el tiempo de respuesta orientado al usuario esta determinado unicamente por el modelo baseline. Las predicciones del modelo shadow se calculan en segundo plano y se registran para analisis posterior. Esto elimina la sobrecarga de latencia de ejecutar dos modelos en serie.

El shadow deployment es ideal cuando estas haciendo un cambio importante en la arquitectura de tu modelo, datos de entrenamiento o conjunto de features, y quieres validar el comportamiento en produccion antes de exponer a los usuarios al nuevo modelo. Despues de la ventana de comparacion, puedes promover el modelo shadow a un canary o blue-green deployment para la transicion final.

Un Flujo de Trabajo de Deployment Real

En la practica, la mayoria de los equipos usan una combinacion de estrategias en secuencia. Aqui un flujo de trabajo que equilibra seguridad con velocidad de deployment:

Etapa 1: Validacion shadow. Despliega el nuevo modelo como shadow junto al modelo de produccion actual. Ejecuta durante 3-7 dias, comparando predicciones y latencia. Revisa el informe de comparacion buscando anomalias, cambios distribucionales o patrones de prediccion inesperados.

Etapa 2: Rollout canary. Si la comparacion shadow esta limpia, promueve a un canary deployment. Comienza con 5% de trafico con umbrales estrictos de health check. Avanza a traves de 25%, 50% y 100% durante el curso de 24-48 horas. El auto-rollback protege contra regresiones en cada etapa.

Etapa 3: Monitoreo post-deployment. Despues de que el canary alcance el 100%, el nuevo modelo es el modelo de produccion. Continua monitoreando con alertas estandar para data drift, degradacion de rendimiento y tasas de error. El model registry registra el historial completo de deployment para propositos de auditoria.

# Promote shadow to canary after successful comparison
promotion = client.deployments.promote(
    deployment_id=shadow_deployment.id,
    target_strategy="canary",
    canary_config={
        "stages": [
            {"traffic_percentage": 5, "duration_minutes": 120},
            {"traffic_percentage": 25, "duration_minutes": 240},
            {"traffic_percentage": 50, "duration_minutes": 360},
            {"traffic_percentage": 100, "duration_minutes": 0}
        ],
        "auto_advance": True,
        "auto_rollback": True
    }
)

print(f"Promotion ID: {promotion.id}")
print(f"Strategy: shadow -> canary")
print(f"Starting at: {promotion.initial_traffic_percentage}%")

Mejores Practicas

Comienza de forma conservadora. Inicia los canary deployments al 5% o menos. El costo de un rollout mas lento se mide en horas. El costo de un mal deployment alcanzando el 100% del trafico puede medirse en ingresos y confianza del usuario.

Establece umbrales significativos. Los umbrales de health check deben basarse en el rendimiento real de tu modelo base, no en numeros arbitrarios. Si tu modelo actual tiene una latencia p99 de 120ms, establecer el umbral en 200ms es razonable. Establecerlo en 50ms causara falsos rollbacks.

Monitorea metricas de negocio, no solo metricas de modelo. Un modelo podria tener AUC y latencia aceptables pero aun causar problemas downstream. Si tu modelo alimenta un motor de precios, monitorea los resultados de precios, no solo la precision predictiva del modelo.

Usa auto-advance para deployments estandar. El avance manual a traves de etapas canary es apropiado para el primer deployment de un nuevo tipo de modelo, pero para actualizaciones rutinarias (reentrenamiento con datos frescos, cambios menores de features), el auto-advance reduce la carga operacional sin sacrificar seguridad.

Mantiene ambos modelos calientes. Durante un canary deployment, el modelo base debe permanecer completamente cargado y listo para absorber el 100% del trafico en cualquier momento. No reduzcas los recursos del baseline hasta que el canary haya completado todas las etapas y el deployment este finalizado.

Revisa los post-mortems de rollback. Cada rollback es una oportunidad de aprendizaje. CorePlexML registra el historial completo de cada deployment, incluyendo que metrica activo el rollback, en que etapa y con que valores. Revisar estos post-mortems te ayuda a mejorar tanto tus modelos como tus configuraciones de deployment con el tiempo.

El deployment seguro de modelos no se trata de eliminar el riesgo por completo. Se trata de controlar tu exposicion, medir resultados en trafico real y tener salvaguardas automatizadas que protejan a tus usuarios y tu negocio cuando las cosas no salen como se planeo. Los canary deployments proporcionan ese equilibrio, y combinados con estrategias blue-green y shadow, te dan un toolkit completo para ML en produccion a cualquier escala.

Para mas detalles sobre las estrategias de deployment y capacidades de monitoreo de CorePlexML, visita la pagina de funcionalidades MLOps.