En el módulo anterior aprendiste a detectar el drift y terminamos con una distinción clave: el drift es una señal, no una orden. Detectar que el mundo cambió no sirve de nada si no haces algo al respecto. Este módulo es ese “algo”: el reentrenamiento, la flecha de vuelta que en el módulo 1 dibujamos yendo de “monitorear” de vuelta a “datos”. Aquí el loop deja de ser un diagrama y se vuelve un pipeline que corre solo. Un modelo vivo es uno que da esta vuelta una y otra vez.

La tesis del módulo

Detectar drift sin reentrenar es un tablero de alarmas que nadie apaga. El valor de todo el monitoreo se realiza recién cuando la señal dispara una acción: un modelo nuevo, entrenado con datos frescos, validado y desplegado con red. Reentrenar es cerrar el loop — pero cerrarlo mal, promoviendo un modelo peor a ciegas, es peor que no cerrarlo.

Los triggers de reentrenamiento

Un trigger (glosado: la condición que dispara automáticamente un reentrenamiento — el “cuándo” del retraining) puede ser de tres tipos, y elegir bien evita tanto reentrenar de más como de menos.

1. Programado (schedule). Reentrenas cada cierto tiempo fijo — cada semana, cada mes — sin importar si hubo drift. Simple y predecible; bueno cuando sabes que tus datos evolucionan a ritmo constante. El riesgo: reentrenas aunque nada haya cambiado (gasto inútil) o te quedas corto si el mundo cambió antes del próximo ciclo.

2. Por drift detectado. El pipeline del módulo 10 marca drift y eso dispara el reentrenamiento. Reaccionas a la causa real, no al calendario. El riesgo: como vimos, drift no siempre implica caída de desempeño, así que conviene combinarlo con el tercer trigger.

3. Por caída de desempeño. Cuando llega el ground truth y las métricas reales (accuracy, F1) caen bajo un umbral, reentrenas. Es el trigger más honesto porque mide el daño real, no un proxy. Su límite ya lo conoces: el ground truth llega tarde, así que por sí solo reacciona lento.

En la práctica se combinan: un schedule de fondo como red de seguridad, más disparo por drift y por caída de desempeño para reaccionar rápido cuando algo se mueve.

Trigger	Cuándo usarlo	Ventaja	Límite
Programado	Datos que evolucionan a ritmo estable	Simple, predecible	Ciego a cambios entre ciclos
Por drift	Entradas que pueden cambiar de golpe	Reacciona a la causa, sin esperar ground truth	Drift no siempre implica daño
Por desempeño	Cuando el ground truth llega razonablemente rápido	Mide el daño real	Reacciona tarde si la etiqueta demora

Automatizar el retraining pipeline

Reentrenar a mano cada vez no escala. La idea es que el trigger dispare el mismo pipeline de entrenamiento que ya construiste en el módulo de pipelines de entrenamiento — no un script nuevo hecho al apuro. Reusas el pipeline versionado; solo cambia el detonante y los datos frescos.

El siguiente pseudocódigo muestra la lógica de orquestación. Es conceptual — la orquestación real la hace una herramienta de pipelines (Airflow, Kubeflow, el mismo pipeline del módulo 5) — pero la secuencia de decisiones es exactamente esta:

# CONCEPTUAL: la lógica que envuelve un retraining automatizado.
# En producción esto vive dentro de un orquestador de pipelines,
# no en un script suelto. Muestra el ORDEN de las decisiones.

def loop_de_reentrenamiento(estado):
    # 1. ¿Algún trigger se activó?
    if not (estado.drift_detectado
            or estado.desempeno_bajo_umbral
            or estado.toca_por_schedule):
        return "sin cambios: el champion sigue en producción"

    # 2. Reentrenar reusando el pipeline versionado del módulo 5,
    #    con una ventana de datos frescos.
    challenger = pipeline_de_entrenamiento(datos=ventana_reciente())

    # 3. Validar ANTES de promover (módulo de CI/CT, módulo 7).
    #    Se compara el challenger contra el champion en un holdout.
    if not validar(challenger, referencia=estado.champion):
        return "challenger rechazado: el champion se queda"

    # 4. Registrar la nueva versión (módulo 4: model registry).
    registrar_version(challenger, etiqueta="challenger")

    # 5. Promover con red, no de golpe (siguiente sección).
    return promover_con_cuidado(challenger, champion=estado.champion)

La regla de oro que ese código impone: nunca promuevas a ciegas. Un modelo reentrenado no es automáticamente mejor. Con datos ruidosos o un bug en el pipeline, el nuevo puede ser peor que el que reemplaza. Por eso el paso 3 es un portón, no un trámite.

Validar antes de promover

La validación reusa lo del módulo de CI/CD y CT para ML: antes de que el modelo nuevo toque tráfico real, pasa por pruebas automáticas. No solo “¿entrena sin error?”, sino “¿es realmente mejor o al menos igual que el que está en producción?”. Se evalúa el challenger contra el champion sobre un conjunto de validación reservado, con las métricas que le importan al negocio — las mismas de Evaluar un modelo. Si el challenger no supera (o al menos iguala) al champion, se descarta y el champion sigue reinando.

Desplegar con red: las estrategias

Aun validado, un modelo nuevo se despliega con cuidado, no con un cambio de golpe. Cuatro estrategias, de la más conservadora a la más directa:

Champion/challenger (glosado: el modelo en producción es el “campeón”; el candidato nuevo es el “retador”. Se comparan cara a cara y el retador solo reemplaza al campeón si demuestra ser mejor). Es el marco mental de todo el proceso.

Shadow deployment (glosado: el modelo nuevo corre en paralelo con el viejo recibiendo el mismo tráfico real, pero sus predicciones no deciden nada — solo se registran para compararlas contra las del champion). Es la prueba más segura: mides el challenger con tráfico de verdad sin arriesgar una sola decisión real.

Canary para modelos. Igual que en Rollout y confiabilidad: el challenger empieza atendiendo un 5% del tráfico real (ahí sí decidiendo), vigilas sus métricas, y subes el porcentaje solo si se porta bien. Si algo falla, el daño quedó acotado a esa fracción.

Rollback de modelo. La red final: si el nuevo modelo se porta mal en producción, vuelves al anterior al instante. Esto solo es posible porque el model registry guardó la versión previa lista para reactivar. Rollback de modelo = volver a apuntar el serving a la versión anterior registrada.

El loop completo del reentrenamiento

 START
   │
   ▼
 ┌──────────────┐  sin señal   ┌──────────────┐
 │ MONITOREAR   ├────────────► │ champion se  │
 │ (drift/perf) │              │ queda        │
 └──────┬───────┘              └──────────────┘
        │ trigger
        ▼
 ┌──────────────┐
 │ REENTRENAR   │  (pipeline del módulo 5,
 │ challenger   │   con datos frescos)
 └──────┬───────┘
        ▼
 ┌──────────────┐  no supera   ┌──────────────┐
 │ VALIDAR vs   ├────────────► │ descartar    │
 │ champion     │              │ challenger   │
 └──────┬───────┘              └──────────────┘
        │ mejor o igual
        ▼
 ┌──────────────┐  se porta mal  ┌────────────┐
 │ PROMOVER     ├──────────────► │ ROLLBACK   │
 │ (shadow y    │                │ al champion│
 │  canary)     │                └────────────┘
 └──────┬───────┘
        │ estable
        ▼
 challenger es el nuevo champion  ──►  MONITOREAR

Fíjate que el loop no tiene END: un modelo vivo nunca “termina”. Cada challenger promovido se vuelve el champion que el próximo ciclo intentará destronar. Ese es el sentido literal de “cerrar el loop”.

El rollback no es opcional ni es una vergüenza. Un modelo que se puede revertir en segundos es un modelo que puedes desplegar sin miedo. El equipo que no tiene rollback listo termina dejando en producción un modelo malo “porque volver atrás es un enredo” — y esa fricción se paga en predicciones equivocadas.

Errores comunes

Promover el modelo reentrenado sin validarlo. Nuevo no es sinónimo de mejor. Sin comparar challenger contra champion, puedes estar degradando en cada ciclo.
Reentrenar solo por schedule. Un calendario fijo reentrena de más cuando nada cambió y de menos cuando el mundo cambió antes del próximo ciclo. Combina triggers.
Desplegar el modelo nuevo de golpe al 100%. Sin shadow ni canary, un error del challenger golpea a todos tus usuarios a la vez. Libera de a poco.
No tener rollback listo. Si volver atrás es un proyecto, te quedas atrapado con el modelo malo. El registry del módulo 4 existe precisamente para esto.
Reentrenar con datos contaminados por el propio modelo. Ojo con los loops de retroalimentación: si el modelo influyó en los datos nuevos (aprobó ciertos créditos y solo de esos ves el resultado), la ventana fresca puede estar sesgada. Vigila de dónde salen tus datos de reentrenamiento.

La frase para llevarse

“Monitorear te dice que el modelo envejeció; reentrenar es lo único que lo rejuvenece. Pero un modelo nuevo desplegado sin validar ni red es apostar la producción a que ‘esta vez salió mejor’ — y el loop se cierra bien solo cuando cada vuelta puede deshacerse.”

Qué viene

Módulo 12 — el cierre del curso: gobernanza y madurez. Ya tienes el ciclo completo funcionando de punta a punta; falta lo que convierte piezas sueltas en una práctica de organización. Model governance, auditoría y linaje, model cards, fairness y compliance (clave en banca), los niveles de madurez de MLOps y el checklist condensado de los doce módulos. Cerramos la serie.

MLOps — Módulo 11: reentrenamiento — cerrar el loop