Estrategia de Rollback de Modelos en Producción
1. Introducción
A pesar de las pruebas de integración y validación, los modelos pueden fallar en producción por razones imprevistas:
-
Cambios en la distribución de los datos de entrada (drift).
-
Degradación del rendimiento no detectada en staging.
-
Efectos colaterales de la nueva versión en sistemas downstream.
La capacidad de revertir rápidamente a una versión anterior es tan importante como el propio despliegue.
Un rollback efectivo debe cumplir tres condiciones:
-
Rápido (segundos o pocos minutos, no horas).
-
Automático (disparado por alertas o por decisión manual con un solo clic).
-
Auditable (dejar traza en el registro de modelos y en los logs de auditoría).
Este capítulo describe estrategias concretas usando MLflow, KServe/Istio y Docker, así como su integración con CI/CD.
2. El Patrón Champion‑Challenger con Alias
El model registry es el componente central para gestionar versiones. Se utilizan tres alias:
| Alias | Propósito |
|---|---|
champion | Modelo que recibe tráfico real. |
candidate | Modelo en pruebas (staging o canary). |
archived | Versiones retiradas pero conservadas por auditoría. |
Cuando se despliega una nueva versión, se mueve el alias champion al nuevo modelo tras las validaciones. El rollback consiste en revertir el alias champion a la versión anterior.
Diagrama de flujo del patrón champion‑challenger
2.1. Ejemplo con MLflow
Supongamos un modelo fraud_detector con versiones 1, 2, 3, …
El endpoint de inferencia siempre carga el modelo apuntado por @champion. El rollback es instantáneo (solo actualiza la referencia, no reinicia pods).
3. Rollback Automático con KServe e Istio
En entornos Kubernetes, KServe (o un service mesh como Istio) permite dividir el tráfico entre versiones. Combinado con MLflow y Prometheus, se puede automatizar el rollback.
3.1. Flujo con KServe (Canary)
KServe define un InferenceService con canaryTrafficPercent. El rollback consiste en poner ese porcentaje a 0.
Si las métricas del canary superan umbrales, un script automático elimina el tráfico del canary:
Simultáneamente, se revierte el alias en MLflow a la versión anterior.
3.2. Integración con Prometheus y Alertas
Un controlador (script, pod o función serverless) escucha las alertas de Prometheus y ejecuta el rollback.
Diagrama de componentes para rollback automático
4. Rollback con Regeneración de Imagen Docker
Cuando el modelo está empaquetado dentro de la imagen (y no se carga dinámicamente desde un registry), el rollback implica reconstruir y desplegar la imagen anterior.
4.1. Estrategia: Etiquetado canónico
Cada imagen se etiqueta con la versión del modelo y con el alias champion solo en la versión activa.
Para hacer rollback:
Este método es más lento (requiere reinicio) y se recomienda solo para modelos simples o entornos legacy.
5. Flujo de Rollback Recomendado (Integrado con CI/CD)
Diagrama de decisión para rollback
5.1. Automatización con GitHub Actions
Se puede crear un workflow manual (o automático) para ejecutar rollback desde la interfaz de GitHub.
6. Comparativa de Estrategias de Rollback
| Estrategia | Velocidad | Complejidad | Dependencias | Caso de uso |
|---|---|---|---|---|
| MLflow alias | Instantánea | Baja | MLflow, endpoint dinámico | Modelos cargados desde registry |
| KServe canary | Rápida (segundos) | Media | Kubernetes, KServe, Prometheus | Infraestructura cloud nativa |
| Docker tag + rollout | Lenta (minutos) | Baja | Docker, Kubernetes | Modelos empaquetados en imagen |
7. Buenas Prácticas
-
Mantener al menos las últimas 3 versiones de cada modelo en el registry.
-
Probar el rollback regularmente en entornos de staging (simular fallos).
-
Documentar cada rollback en el audit trail (quién, cuándo, por qué, desde/hacia qué versión).
-
Separar la lógica de rollback del código de inferencia: el servicio no debe contener reglas de selección de versión; debe delegar en MLflow y en el controlador de tráfico.
Documentos relacionados
- MLflow para la Gestión del Ciclo de Vida de Modelos Estadísticos: registry desde el cual se selecciona la versión anterior para el rollback.
- Monitoreo de Modelos en Producción: alertas que disparan el proceso de rollback automático.
- Guía de Despliegue: pipeline de despliegue que gestiona la transición de versiones.