En el módulo 3 terminaste con un run ganador: la configuración que dio el mejor F1, registrada con sus métricas y su versión de datos. Falta el último paso del bloque básico, y es más sutil de lo que parece: convertir ese run en el modelo oficial. Un experimento es una prueba entre muchas; producción necesita un modelo bendecido, con nombre, versión y un sello que diga “este es el que va”. Pasar de “el run 47 se ve bien” a “la versión 3 está en producción” es lo que hace un model registry.

La tesis del módulo

El experiment tracking guarda todo lo que probaste; el model registry decide qué de eso va a producción. Sin un registro, nadie sabe con certeza qué modelo está sirviendo ahora mismo ni cómo volver al anterior cuando el nuevo falla.

Qué es un model registry

Un model registry (registro de modelos) es un catálogo central de los modelos entrenados que merecen sobrevivir. No guarda los 50 runs: guarda los candidatos serios, versionados, con tres cosas que un .pkl suelto nunca te da:

Aliases (alias): punteros con nombre que apuntan a una versión — champion (la que sirve de verdad), challenger (la candidata en prueba). Promover es mover el alias de una versión a otra.
Linaje (lineage): la trazabilidad de qué produjo ese modelo — de qué run salió, con qué datos, con qué código y con qué métrica. Es la respuesta a “¿de dónde vino esto?”.
Aprobación de promociones: mover champion de la v3 a la v4 es una decisión explícita, registrada (con un tag de quién aprobó) y reversible, no un archivo que alguien copió a mano.

La razón de fondo: saber exactamente qué modelo está en producción y poder volver a una versión anterior — el rollback de modelo. El día que la versión 4 empieza a predecir mal, quieres devolver la versión 3 a producción en un comando, no reconstruirla de memoria.

Aliases y tags: el viaje de una versión

Cada modelo registrado tiene versiones (v1, v2, v3…). Lo que dice en qué punto del ciclo está cada una son dos cosas: los aliases (un puntero con nombre que apunta a una sola versión) y los tags (etiquetas libres clave = valor). Este es el recorrido típico:

Puntero	Qué significa	Quién la ve
Sin alias	Recién registrada, sin evaluar	Nadie en prod
`challenger` (alias)	En validación: se prueba contra datos reales	Entorno de pruebas
`champion` (alias)	El modelo oficial, sirviendo peticiones	Los usuarios
Sin alias, reemplazada	Perdió el alias; queda registrada para auditar y rollback	Nadie, pero no se borra

La regla de oro: un alias apunta a una sola versión a la vez. Cuando mueves champion a la v4, la v3 deja de tener el alias automáticamente — pero no se borra, queda lista para volver si hace falta. Un tag como validation_status = approved deja escrito quién aprobó y cuándo.

El flujo: del experimento al registro

Así se conecta el módulo 3 con este. El run ganador se registra como una versión del modelo; esa versión recibe el alias challenger y, si aprueba, el alias champion se mueve hacia ella.

   EXPERIMENTO                 MODEL REGISTRY
  (run ganador)            "clasificador-fraude"
 ┌─────────────┐         ┌───────────────────────┐
 │ run 47      │         │ v1                    │
 │ f1 = 0.91   │ register│ v2                    │
 │ datos v3    ├──────►  │ v3   @champion        │
 └─────────────┘         │ v4   @challenger      │
                         └──────────┬────────────┘
                                    ▼
                         ┌───────────────────────┐
                         │ mover @champion a v4; │
                         │ v3 queda registrada   │
                         │ (rollback = apuntar   │
                         │ @champion a v3)       │
                         └───────────────────────┘

Fíjate en el movimiento: la v4 entra como challenger (probándose); si aprueba, el alias champion se mueve a la v4 y la v3 se queda sin alias, pero registrada. Si la v4 fallara ya en producción, el rollback es el mismo gesto al revés: vuelves a apuntar champion a la v3. El registry hace ambos movimientos triviales.

Código: registrar y promover con MLflow

MLflow Model Registry se construye sobre el tracking del módulo 3. Primero registras el modelo de un run; luego le pones un alias a su versión.

import mlflow
from mlflow import MlflowClient

mlflow.set_tracking_uri("http://localhost:5000")

# --- 1. Registrar el modelo del run ganador ---
# El modelo se logueó en el run con mlflow.sklearn.log_model(..., name="modelo")
run_id = "a1b2c3d4e5f6"          # el run ganador del módulo 3
model_uri = f"runs:/{run_id}/modelo"

result = mlflow.register_model(
    model_uri=model_uri,
    name="clasificador-fraude",  # el nombre oficial en el registry
)
print(f"Registrada versión {result.version}")   # ej: 4

# --- 2. Marcarla como candidata y, si aprueba, promoverla ---
client = MlflowClient()
client.set_registered_model_alias(
    name="clasificador-fraude",
    alias="challenger",
    version=result.version,      # la v4, en validación
)
# ... pasa la validación contra producción (módulo 7) ...
client.set_model_version_tag(
    "clasificador-fraude", result.version,
    "validation_status", "approved",   # queda escrito que aprobó
)
client.set_registered_model_alias(
    name="clasificador-fraude",
    alias="champion",
    version=result.version,      # champion se mueve de la v3 a la v4
)

Como un alias solo puede apuntar a una versión, mover champion a la v4 le quita el alias a la v3 sin que hagas nada más: esa es la regla de “una sola en producción”. Para servir el modelo, tu API pide siempre “la versión que hoy es champion”, sin hardcodear un número:

# El servicio de serving carga la versión que hoy tenga el alias champion
model = mlflow.sklearn.load_model(
    model_uri="models:/clasificador-fraude@champion"
)
# Cuando promuevas otra versión, este mismo código sirve la nueva
# sin cambiar una línea.

Ojo: si ves tutoriales con transition_model_version_stage(..., stage="Production") o URIs tipo models:/nombre/Production, son los stages clásicos (Staging / Production / Archived). MLflow los declaró obsoletos en la 2.9 y en la 3.x se mantienen solo por compatibilidad, mapeados a aliases por debajo. La idea es idéntica —un puntero estable que tu serving consulta y que tú mueves entre versiones—, pero lo que hay que aprender hoy son aliases y tags.

Errores comunes

Servir un modelo hardcodeando la ruta a un .pkl. El día del rollback tienes que editar y redeployar código. Con el registry, apuntas a @champion y mueves el puntero.
No registrar el linaje. Un modelo en producción sin saber de qué run y qué datos salió es imposible de auditar y peligroso de reproducir.
Servir por número de versión en vez de por alias. Si el serving carga models:/clasificador-fraude/4, cada promoción exige tocar código y redeployar. El alias (@champion) es el puntero que mueves sin tocar el servicio.
Borrar la versión anterior al promover una nueva. Quitarle el alias no es borrarla: la versión vieja es tu paracaídas de rollback. Consérvala.
Confundir registrar con desplegar. Registrar pone el modelo en el catálogo y le mueve el alias; el despliegue real (servirlo) es otro paso, que veremos en serving.

La frase para llevarse

“El registry es la fuente de verdad de qué modelo manda hoy. Con él, saber qué corre en producción y volver a la versión anterior son dos comandos — sin él, son dos horas de arqueología.”

Qué viene

Con esto cierras el bloque básico: ya sabes qué es MLOps, cómo reproducir, cómo trackear experimentos y cómo registrar el modelo oficial. El módulo 5 abre el siguiente bloque con los pipelines de entrenamiento: automatizar la cadena datos → features → entrenar → registrar para que producir un nuevo modelo sea un botón, no un ritual manual.

MLOps — Módulo 4: model registry — del experimento al modelo oficial