Módulo final del Curso de Machine Learning. En el módulo 11 vimos los problemas del mundo real: desbalance, interpretabilidad, sesgo y el leakage que aparece en producción. Y justamente ahí quedó flotando la palabra clave: producción. Hasta ahora todo vivió en tu notebook — entrenaste, mediste, afinaste, y el modelo murió cuando cerraste el cuaderno. Este módulo cierra el círculo: cómo sacar ese modelo del laboratorio y ponerlo a predecir de verdad, para usuarios reales, todos los días.

La tesis del módulo

Un modelo que solo corre en tu notebook no le sirve a nadie: el valor aparece cuando predice en producción, sobre datos nuevos, sin ti mirando. Y lo que guardas y despliegas no es el modelo pelado — es el pipeline completo, preprocesamiento incluido. Después empieza el trabajo eterno: vigilar que no se degrade solo.

Serializar: guardar el pipeline completo con joblib

Entrenar un modelo toma tiempo y datos. No quieres reentrenar cada vez que arranca tu servicio: quieres entrenar una vez, guardar el resultado en un archivo, y cargarlo listo para predecir. Eso es serializar (persistir el objeto a disco). En scikit-learn se hace con joblib (dump para guardar, load para cargar), que maneja bien los arrays de numpy que hay dentro de un modelo.

El error que arruina despliegues: guardar solo el modelo y no el preprocesamiento. Si en el módulo 8 escalaste, imputaste y codificaste features dentro de un pipeline, ese pipeline es tu modelo de producción. Si guardas solo el clasificador final, en producción no sabrás escalar los datos nuevos igual que en el entrenamiento, y las predicciones saldrán mal. Guarda el pipeline completo, no solo el estimador.

import joblib
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestClassifier

# El pipeline COMPLETO: preprocesamiento + modelo (módulos 8 y 9).
pipe = Pipeline([
    ("scaler", StandardScaler()),
    ("modelo", RandomForestClassifier(n_estimators=300, random_state=42)),
])
pipe.fit(X_train, y_train)

# Guardar TODO el pipeline en un archivo. Incluye el scaler ya ajustado.
joblib.dump(pipe, "modelo_fraude_v1.joblib")

# --- Después, en el servicio de producción, en otro proceso ---
modelo = joblib.load("modelo_fraude_v1.joblib")

# Los datos nuevos entran CRUDOS: el pipeline los escala solo, igual
# que en el entrenamiento. Por eso guardamos el pipeline entero.
prediccion = modelo.predict(datos_nuevos_crudos)

Ojo: el archivo .joblib depende de las versiones de las librerías con que lo guardaste. Un pipeline serializado con scikit-learn 1.4 puede fallar o comportarse raro al cargarlo con otra versión. Fija las versiones (pin) y guárdalas junto al modelo. Nunca cargues un .joblib de una fuente que no controlas: puede ejecutar código al deserializar.

Exponerlo: API o batch

Con el pipeline guardado, hay dos formas de ponerlo a trabajar, según cómo lo consuman:

API (predicción en línea, online): un servicio web recibe una petición con los datos de un caso y responde con la predicción al instante. Es lo que necesitas cuando un usuario espera respuesta ahora — aprobar o rechazar una transacción en el momento del pago.
Batch (predicción por lotes): un proceso programado que corre cada tanto (cada noche, cada hora), lee un montón de casos de una vez, predice sobre todos y guarda los resultados. Ideal cuando no hay nadie esperando en vivo — calcular el score de churn de todos los clientes cada madrugada.

       ┌───────────────────────┐
       │  modelo.joblib        │
       │  (pipeline completo)  │
       └───────────┬───────────┘
                   │  joblib.load
        ┌──────────┴──────────┐
        ▼                     ▼
 ┌───────────────┐    ┌───────────────┐
 │ API online    │    │ batch         │
 │ 1 caso    ──► │    │ N casos   ──► │
 │ respuesta     │    │ tabla de      │
 │ al instante   │    │ resultados    │
 └───────────────┘    └───────────────┘
   usuario espera        nadie espera

	API (online)	Batch (por lotes)
Cuándo predice	Al instante, por petición	Programado (cada noche, hora)
Volumen	Un caso por vez	Muchos de golpe
Latencia	Debe ser baja	No importa
Ejemplo	Aprobar un pago ahora	Score de churn de toda la base
Complejidad de operar	Más alta (servicio vivo 24/7)	Más baja (un job que corre y termina)

Cómo se empaqueta y despliega ese servicio —contenedores, CI/CD, confiabilidad— es territorio que el Curso de Deploy cubre en serio: la contenerización con Docker y el rollout y la confiabilidad son la continuación natural de este módulo.

Versionar: datos y modelo

En software versionas el código (git). En ML eso no basta: el comportamiento de un modelo depende de tres cosas, y las tres cambian. Debes versionar los datos con que entrenaste, el modelo resultante (modelo_fraude_v1.joblib, v2…) y las métricas que dio cada versión. Sin eso, cuando la v3 rinda peor que la v2 no vas a poder volver atrás ni entender qué cambió. La regla mínima: cada modelo desplegado sabe con qué datos y con qué versiones de librerías nació.

El puente a MLOps: el modelo se degrada solo

Acá está la diferencia más grande entre ML y software normal. Un programa correcto sigue correcto para siempre. Un modelo, no: se degrada solo aunque no toques una línea de código, porque el mundo que modeló cambia debajo de él.

Ese fenómeno se llama drift (deriva): los datos del mundo real cambian con el tiempo y el modelo, entrenado con el mundo de ayer, va perdiendo puntería. Los patrones de fraude mutan, los hábitos de compra cambian tras una crisis, entra un producto nuevo que el modelo nunca vio. El modelo no se rompe con un error: simplemente empieza a acertar menos, en silencio.

 rendimiento del modelo en el tiempo

  bueno │●●●●●●●●
        │        ●●●●●●
        │              ●●●●●        ◄── drift:
        │                   ●●●●         el mundo cambió,
   malo │                       ●●●●     el modelo no
        └──────────────────────────────►
        despliegue                tiempo
                    │
                    ▼
            monitorear + reentrenar

De ahí nace MLOps: la disciplina de operar modelos en producción de forma sostenible. Sus tres pilares, que desarrolla el Curso de MLOps:

Monitoreo: medir en producción no solo que el servicio responde, sino que el modelo sigue acertando — vigilar el drift en los datos de entrada y en el rendimiento.
Reentrenamiento: cuando el drift pega, entrenar una versión nueva con datos frescos y desplegarla (con las validaciones del módulo 9, sin autoengaños).
Observabilidad y seguridad: logs, alertas, protección del endpoint — lo que el Curso de Deploy trata en observabilidad y seguridad.

El mapa completo del curso

 básico          intermedio        avanzado
 fundamentos     modelos y          rigor y
 y evaluación    features           producción
 ┌───────────┐   ┌───────────┐   ┌───────────┐
 │ qué es ML │   │ reg. l/log│   │ validación│
 │ datos/EDA │─► │ árboles   │─► │ y tuning  │
 │ reg/clasif│   │ rand.for. │   │ no superv.│
 │ evaluar   │   │ boost/XGB │   │ mundo real│
 │           │   │ feat/pipe │   │ producción│
 └───────────┘   └───────────┘   └───────────┘
   entender        modelar con      medir bien y
   y medir         potencia         desplegar

La progresión completa: entiendes qué es ML y cómo se mide, construyes modelos serios con buenas features, y luego los validas con rigor y los pones a trabajar en producción. Ese era el contrato del módulo 1, y está cumplido.

Errores comunes

Guardar solo el modelo, no el pipeline. El error que rompe más despliegues. Sin el preprocesamiento ajustado, los datos nuevos entran mal escalados y las predicciones salen basura.
Reentrenar en cada arranque. Entrena una vez, serializa, carga el .joblib. Reentrenar al levantar el servicio es lento y no determinista.
No versionar datos ni modelo. Cuando la versión nueva rinda peor, sin versionado no puedes volver atrás ni saber qué cambió.
Ignorar las versiones de librerías. Un .joblib cargado con otra versión de scikit-learn puede fallar silenciosamente. Fija (pin) y registra las versiones.
Desplegar y olvidarse. El modelo se degrada solo por drift. Sin monitoreo, te enteras cuando el negocio se queja, no antes.
Cargar modelos de fuentes no confiables. Deserializar un .joblib ajeno puede ejecutar código. Trátalo como un binario ejecutable, no como un dato inocente.

La frase para llevarse

“El modelo del notebook es un prototipo; el valor está en el pipeline serializado que predice en producción sin ti. Y a diferencia del código, un modelo correcto hoy se equivoca mañana solo — porque el mundo cambia debajo de él.”

Qué viene: fin del curso

Doce módulos: del “¿qué es Machine Learning y cuándo NO usarlo?” hasta un pipeline serializado prediciendo en producción y vigilado contra drift. Recorrimos los fundamentos y la evaluación, los modelos y las features, y el rigor y el despliegue. Si completaste la serie con tu cuenta de la academia, el certificado es tuyo. El glosario de Machine Learning queda como referencia permanente para cuando dudes de un término.

Dos puentes hacia adelante. Uno lateral: ¿ML clásico o deep learning? El mapa completo del Curso de Redes Neuronales cierra la otra mitad de la IA moderna — cuándo conviene cada uno (regla rápida: datos tabulares y estructurados → ML clásico; imágenes, texto, audio → deep learning). Y uno hacia arriba: este módulo abrió la puerta de MLOps — monitoreo, drift, reentrenamiento, CI/CD de modelos — que tiene curso propio: el Curso de MLOps retoma justo donde este termina. Y el Curso de Deploy cubre la parte de despliegue y confiabilidad. Nos vemos ahí.

Machine Learning — Módulo 12: del notebook a producción