9 · Registro de modelos y DagsHub
El tracking te dice qué corrida fue la mejor; el registro de modelos es lo que la promueve a producción. Registra un modelo, muévelo por etapas — None → Staging → Production — y cárgalo por etapa, para que el serving nunca codifique a mano un ID de corrida.
El registro de modelos de MLflow es un catálogo versionado ENCIMA del tracking: REGISTRAS el modelo de una corrida bajo un nombre, cada registro es una nueva VERSIÓN, y transicionas las versiones por ETAPAS (None → Staging → Production → Archived). El serving carga el modelo por NOMBRE y ETAPA (`models:/churn/Production`) — así promover un modelo nuevo es una transición de etapa, no un re-despliegue con un ID de corrida codificado a mano.
Sin esto:
Sin un registro, 'el modelo de producción' es un puntero informal — un ID de corrida pegado en una configuración, un nombre de archivo en un servidor. Promover un modelo nuevo significa rastrear esa referencia y re-desplegar, sin rastro de auditoría de qué versión estuvo en vivo y cuándo.
El tracking (lección 8) responde "¿cuál corrida fue la mejor?". Pero conocer la mejor corrida no es lo mismo que enviarla a producción. Necesitas una forma controlada de decir "esta versión del modelo es ahora la que sirve producción" — y de cambiar esa decisión de forma segura cuando lleguen modelos mejores. Eso es el registro de modelos.
El registro se asienta encima del tracking y añade tres ideas:
1. Modelos registrados (por nombre). Le das al modelo un nombre estable — churn-classifier — independiente de cualquier corrida individual. El código de serving se refiere a ese nombre, no a un ID de corrida enterrado en un notebook.
2. Versiones. Cada vez que registras un modelo bajo ese nombre, obtienes una nueva versión (v1, v2, v3, ...). MLflow las conserva todas. La versión 7 podría estar en vivo mientras la 8 se evalúa — ambas existen en el registro.
3. Etapas (stages). Cada versión se ubica en una etapa, y la transicionas entre etapas:
- None — recién registrada, aún sin asignar a ningún lugar.
- Staging — una candidata en evaluación (recibiendo tráfico en sombra, pruebas A/B, verificaciones finales).
- Production — la versión que realmente sirve tráfico en vivo.
- Archived — retirada, conservada para auditoría/rollback.
El flujo de promoción es None → Staging → Production, y cuando una nueva versión se promueve a Production, la antigua típicamente se mueve a Archived (o se conserva como objetivo de rollback). Esto se hace con MlflowClient().transition_model_version_stage(name, version, stage).
El beneficio está en la carga. El código de serving carga el modelo por nombre y etapa: mlflow.pyfunc.load_model("models:/churn-classifier/Production"). Nunca nombra un número de versión ni un ID de corrida. Así que cuando promueves la v8 a Production, cada servicio que carga .../Production toma el modelo nuevo en su siguiente carga — sin cambio de código, sin re-despliegue con un ID codificado a mano, con rastro de auditoría completo de qué versión fue Production y cuándo.
DagsHub es un hogar alojado para todo esto. Te da un servidor de tracking de MLflow gratuito y gestionado (así tus corridas y registro viven en la nube, no solo en tu laptop) y un remoto de DVC (lección 10) para tus datos — más Git, en un solo lugar. Apuntas MLflow a él fijando la tracking URI a tu repo de DagsHub y autenticándote con un token. Las mismas llamadas mlflow.log_* y de registro escriben entonces a la nube en lugar de a una carpeta local.
Los servidores de MLflow y DagsHub no se pueden ejecutar en el navegador, así que el código de abajo es solo para leer — la forma (registrar → transicionar → cargar por etapa) es la conclusión.
Registra el modelo de una corrida bajo un nombre (creando una versión), transiciónalo None → Staging → Production con `MlflowClient`, luego cárgalo por etapa con `models:/churn-classifier/Production`.
Fija `MLFLOW_TRACKING_URI` (y credenciales) a un repo de DagsHub para que las corridas y el registro vivan en la nube, y añade DagsHub como remoto de DVC — tracking, versionado de datos y Git en un solo lugar.
En el registro de modelos de MLflow, ¿cuál es el flujo estándar de promoción para una versión de modelo?
- El registro de modelos se asienta encima del tracking: registras el modelo de una corrida bajo un NOMBRE estable, cada registro es una nueva VERSIÓN, y cada versión se ubica en una ETAPA.
- Promueve una versión hacia adelante None → Staging → Production con `transition_model_version_stage`, archivando la antigua versión de Production; el serving carga por etapa (`models:/name/Production`), nunca por ID de corrida.
- DagsHub provee un servidor de tracking de MLflow alojado Y un remoto de DVC (más Git) en un repo — fija `MLFLOW_TRACKING_URI` a él y las mismas llamadas de logging/registro escriben a la nube.
Las plataformas de ML en producción controlan los lanzamientos mediante un registro: un modelo se promueve a Production solo tras pasar las verificaciones de Staging, y el serving siempre carga la etapa, dando rollback instantáneo y un rastro de auditoría completo.
Si lo quitas: 'El modelo de producción' sería una referencia informal y codificada a mano, así que promover o hacer rollback de un modelo significa editar configuraciones y re-desplegar — propenso a errores y sin registro de qué estuvo en vivo y cuándo.