El despliegue como último paso del pipeline

El desplazamiento mental de este módulo termina aquí: desplegar no es una tarea que alguien hace después, es el último nodo del grafo. Cuando el despliegue vive dentro del pipeline, solo llega a producción lo que pasó por los pasos anteriores — validación de datos, entrenamiento reproducible, evaluación— y deja de existir la categoría «modelo que alguien subió a mano».

01 — El abismo

Por qué fallan los proyectos entre el portátil y producción

Entrenar un modelo en local es relativamente fácil. Llevarlo a un sitio donde atienda peticiones reales, con disponibilidad y vigilancia, es donde se cae la mayoría de los proyectos. El material lo llama el abismo de MLOps y señala dos causas concretas:

Causa	Cómo se manifiesta
No se puede recrear el entorno de quien entrenó	Versiones de librerías y variables de sistema que solo existían en su máquina
Nadie vigila el modelo desplegado	Funciona el primer mes y se degrada sin que salte ninguna alarma

Las dos tienen la misma raíz: el despliegue está fuera del proceso. Lo que estaba dentro —código, datos, entrenamiento— tiene control de versiones y trazabilidad; lo que quedó fuera, no.

02 — El paso de despliegue

Cómo se mete dentro del grafo

@pipeline
def entrenar_y_desplegar(model_trainer, deployer):
    modelo = model_trainer()
    deployer(model=modelo)

Ese deployer es un step como cualquier otro, salvo que su efecto es levantar un servicio de inferencia. Y como es un step, hereda todas las propiedades del resto: recibe un artifact versionado, queda registrado en la ejecución y puede tener pasos antes que lo condicionen.

Esa última parte es la que importa de verdad. El patrón completo no es entrenar y desplegar, sino entrenar, evaluar, decidir y desplegar:

Paso	Qué aporta
Entrenar	Produce el modelo como artifact
Evaluar	Mide contra un conjunto de prueba y devuelve la métrica
Decidir	Compara con el umbral o con el modelo en producción
Desplegar	Solo si la decisión fue afirmativa

Con ese paso intermedio, «solo se despliega lo que mejora lo que ya hay» deja de ser una norma que alguien tiene que recordar y pasa a ser código que se ejecuta siempre.

// una norma que depende de que alguien se acuerde no es una norma, es una esperanza

03 — Después de desplegar

El paso que casi nadie escribe

Un modelo desplegado no es un problema resuelto: es un problema que empieza. Los datos que llegan hoy no son los de hace seis meses, y la degradación no avisa — el sistema sigue respondiendo, solo que peor. Por eso el material insiste en no desplegar sin un paso que vigile la salud del modelo.

Ese bucle de vuelta —el servicio manda métricas, alguien las mira, y si se degradan se lanza un reentrenamiento— es lo que cierra el ciclo y convierte el pipeline en algo vivo. Y conviene decir lo que el material no dice: vigilar la degradación es más difícil que desplegar, porque exige saber cuál era el rendimiento bueno, tener con qué comparar y disponer de las respuestas correctas reales, que casi nunca llegan a la vez que las predicciones.

La versión honesta y modesta, que ya vale mucho: registrar las predicciones con su fecha, y comparar la distribución de las entradas de esta semana con la del conjunto de entrenamiento. No dice si el modelo acierta, pero sí si el mundo cambió — que es la pregunta que precede a la otra.

Auditoría Dos cosas de este material. Una: el ejemplo de despliegue depende de una integración externa, de tener contenedores instalados y de que el stack tenga registrado un desplegador — tres dependencias de entorno cuyos comandos concretos cambian entre versiones. Lo que sobrevive es el patrón (el despliegue como nodo del grafo); los comandos, no. Dos, y es la más interesante: el módulo dice «no despliegues modelos sin un paso de monitorización» y no muestra ninguno. No hay código de un paso de vigilancia en ninguna de sus siete unidades. Es un consejo correcto, dado en la única parte del temario que podía enseñarlo — ¿con qué medirías tú esa degradación, y contra qué referencia?

Para hacer

Escribir el paso de decisión

Aunque no despliegues nada, escribe el step que falta: una función que reciba la métrica del modelo recién entrenado y la del que está en producción, y devuelva un booleano. Diez líneas.

Lo difícil no es el código, es responder a las preguntas que obliga a hacerse: ¿cuál es tu umbral y de dónde sale? ¿Qué haces si el modelo nuevo es un poco peor pero mucho más rápido? ¿Y si no hay modelo anterior con el que comparar? Esas tres respuestas son tu política de despliegue — y ahora mismo, si no la has escrito, existe igualmente: es «desplegar siempre».