Módulo 6 · Sesión 14 · 3.5 h

MLOps: trazabilidad y despliegue

4 lecciones 2 notebooks2 ejerciciosAutoevaluaciónQuiz
Ruta del módulo 0%
  1. 01 Trazabilidad: experimentos, corridas y registro de modelos S14
  2. 02 APIs para modelos: del predict_proba al servicio S14
  3. 03 Empaquetado y despliegue: serializar, contener, ejecutar S14
  4. 04 Monitoreo y drift: el modelo después del despliegue ◈S14
NotebooksÁbrelos en Colab sin instalar nada —ejecuta la primera celda, que carga los datos del curso— o descárgalos para el entorno local.
  • 01

    Trazabilidad con MLflow: registrar, comparar y promover un modelo

    aplicado

    Seis candidatos de M4–M5 sobre Wine Quality como corridas de MLflow con contexto, métricas de calidad y de despliegue (tamaño, latencia), artefactos y modelo con firma; search_runs; registro con alias campeon y produccion; reproducción exacta de una corrida; exportación para la API

  • 02

    Drift: qué se ve sin etiquetas, qué no, y cuándo reentrenar

    intuición

    24 meses simulados con drift plantado: PSI y KS por variable, distribución de las predicciones, carta de control del RMSE; drift de datos sin daño y drift de concepto invisible sin etiquetas; diagnóstico por coeficientes; cuatro estrategias de reentrenamiento medidas

Visualizadores Interactivos del módulo; cada uno vive dentro de su lección.

Estado: completo (Fase 6 de ../PLAN.md).

Objetivos

Al finalizar el módulo, el estudiante será capaz de registrar y comparar experimentos de forma trazable y reproducible, elegir el modelo de producción con las métricas de calidad y de despliegue a la vista, exponerlo como un servicio HTTP con un contrato validado, empaquetarlo en un contenedor, y describir —con números— cómo se monitorea en producción, qué cambio detecta cada capa del monitoreo y cuándo y con qué datos reentrenar.

Contenidos

✅ Núcleo

  • S14 — MLflow: experimentos, corridas, artefactos, modelos con firma; qué registrar (hash de datos, commit, versiones, semilla, tamaño y latencia); search_runs; registro de modelos con versiones y alias; reproducir una corrida.
  • S14 — Serialización y versionado del modelo: joblib, skops, ONNX; el modelo como paquete (modelo + columnas + umbral + metadatos).
  • S14 — APIs: HTTP en lo que importa, el contrato (entrada con rangos, salida con umbral y versión, errores 422), FastAPI y Pydantic, pruebas del contrato.
  • S14 — Empaquetado con Docker: imagen, capas, dependencias mínimas fijadas, usuario sin privilegios; dónde ejecutar; cómo se cambia un modelo en producción (sombra, canario, reversión).
  • S14 — Monitoreo y drift: de datos, de concepto, de etiquetas; PSI, KS y distribución de las predicciones (sin etiquetas); carta de control del error (con etiquetas); diagnóstico; políticas de reentrenamiento y con qué datos.

🔵 Opcional

  • mlflow models serve y otros servidores de modelos (teoría 03).
  • Integración continua: las pruebas de api/probar_api.py como puerta antes de construir la imagen.
  • Cierre: sustentación de los proyectos integradores.

Materiales

Teoría

#DocumentoTema
01teoria/01-trazabilidad-mlflow.mdPor qué tracking; corridas, artefactos, modelos con firma y dependencias; registro con alias; reproducir; alternativas
02teoria/02-apis-para-modelos.mdPor qué una API; HTTP mínimo; el contrato; la aplicación línea a línea; probar; lo que falta para producción
03teoria/03-empaquetado-y-despliegue.mdFormatos de serialización y sus riesgos; el Dockerfile explicado; dónde ejecutar; despliegue con criterio
04teoria/04-monitoreo-y-drift.mdTipos de drift; monitoreo sin y con etiquetas; diagnóstico; reentrenar cuándo y con qué; un sistema mínimo

Notebooks

#NotebookTipoContenido
01notebooks/01-mlflow-aplicado.ipynbaplicadoSeis candidatos de M4–M5 sobre Wine Quality como corridas de MLflow con contexto, métricas de calidad y de despliegue (tamaño, latencia), artefactos y modelo con firma; search_runs; registro con alias campeon y produccion; reproducción exacta de una corrida; exportación para la API
02notebooks/02-drift-intuicion.ipynbintuición24 meses simulados con drift plantado: PSI y KS por variable, distribución de las predicciones, carta de control del RMSE; drift de datos sin daño y drift de concepto invisible sin etiquetas; diagnóstico por coeficientes; cuatro estrategias de reentrenamiento medidas

Hallazgo del notebook 01. El mejor modelo en AP (Extra-Trees, 0.589) pesa 12 MB y predice 20 veces más lento que el gradient boosting de 0.15 MB que pierde 0.04 de AP. El campeón y el modelo de producción no tienen por qué ser el mismo, y las métricas que lo deciden —tamaño, latencia— no aparecían en ninguna tabla de los módulos anteriores. Con los parámetros, la semilla y el hash de los datos registrados, la AP se reproduce hasta el sexto decimal.

Hallazgo del notebook 02. El drift de datos (mes 13: PSI de trabaja de 0 a 0.3–0.4, nota predicha media de 3.42 a 3.16) se detecta el mismo mes sin etiquetas y no degrada al modelo (RMSE 0.34, dentro de la carta de control): la relación no cambió y el modelo era correcto en la región nueva. El drift de concepto (mes 19) sube el RMSE un 30 % y no se ve en ninguna entrada. Tras reentrenar, todo el historial apenas ayuda (0.42); solo los datos posteriores al cambio recuperan el error de referencia (0.36): con drift de concepto, más datos no es mejor.

Código de despliegue

RutaContenido
api/main.pyAPI FastAPI: modelo cargado en el lifespan, /health, /predict, /predict/lote
api/esquemas.pyEl contrato en Pydantic: 11 medidas con rango válido + tipo; salida con probabilidad, decisión, umbral y versión
api/entrenar_modelo.pyEntrena el HistGradientBoostingClassifier de la versión produccion y escribe modelo-ejemplo.joblib con columnas, umbral por costos y metadatos
api/modelo-ejemplo.joblibEl modelo servido (0.15 MB; versionado)
api/probar_api.pySeis pruebas del contrato con TestClient
api/requirements-api.txtDependencias mínimas de la API con las versiones exactas de uv.lock
api/README.mdCómo ejecutar, probar y reentrenar; decisiones de diseño; latencia medida
docker/DockerfileImagen del servicio sobre la imagen oficial de uv con Python 3.11
docker/README.mdConstruir, ejecutar, el Dockerfile línea a línea, por qué no se instala todo el pyproject.toml
.dockerignoreLo que no entra en la imagen

Verificado: las seis pruebas pasan; la API levantada con uvicorn responde a curl (/health, /predict, 422 fuera de rango) con mediana 2.7 ms y p95 3.7 ms por petición; y arranca desde un entorno construido solo con requirements-api.txt (272 MB), que es lo que hace el Dockerfile. La imagen no se construyó con docker build (sin Docker en la máquina del docente); ver la nota en docker/README.md.

Datos

ArchivoDescripciónPor qué este
datos/wine-quality.csvLos mismos vinos de los módulos 4 y 5El notebook 01 registra en MLflow los modelos ya conocidos (AP 0.52–0.59) y la API sirve el elegido
datos/preparar-wine-quality.pyDescarga y prepara Wine Quality (copiado del módulo 4)Procedencia
datos/cohortes-estudiantes.csv24 meses × 300 estudiantes del proceso de rendimiento-estudiantes.csv, con drift de datos desde el mes 13 (más estudiantes que trabajan, promedio 0.15 menor) y drift de concepto desde el 19 (coeficiente de horas 0.055 → 0.020, intercepto +0.45)Conocer el proceso generador permite comprobar qué detecta cada herramienta de monitoreo y cuál se queda ciega, como en el módulo 1
datos/generar-cohortes-drift.pyGenerador con semilla fija; documenta qué cambia y cuándoReproducible byte a byte

Ejercicios

#EnunciadoSoluciónDuración
01ejercicios/ej01-mlflow.mdej01-mlflow-sol.md60 min
02ejercicios/ej02-api.mdej02-api-sol.md90 min

El 01 registra en MLflow los modelos de Adult Census (módulos 4 y 5) con métricas de despliegue —y descubre que allí campeón y producción sí coinciden (LightGBM: mejor AP, 0.15 MB, el más rápido)— y rompe la reproducibilidad a propósito: cambiar una fila del CSV deja la AP idéntica hasta el sexto decimal; solo el hash lo detecta. El 02 construye de punta a punta la API del modelo de estudiantes (contrato, entrenamiento, pruebas, imagen) y su plan de monitoreo sobre las cohortes, con una trampa medida: la AP mensual del clasificador de aprobo dispara con el drift de datos —porque la prevalencia bajó de 0.74 a 0.65— y vuelve a subir con el de concepto; el AUC, que no depende de la prevalencia, cuenta la historia correcta.

Quiz

ArchivoClavePreguntasDuración
quiz/quiz-modulo-6.mdquiz-modulo-6-sol.md1030 min

Entrega del proyecto integrador

E6 — Entrega final. Los modelos del proyecto registrados en MLflow (una corrida por modelo evaluado desde E3, con hash de datos, métricas de calidad con error estándar y métricas de despliegue), el modelo final promovido con alias produccion, expuesto como API con contrato validado y pruebas, empaquetado (Dockerfile, aunque no se construya), un documento de monitoreo de una página (qué se registra, qué se calcula en cada capa, con qué umbrales, y el protocolo ante alarma), más el informe final del caso y su sustentación. Ver ../proyecto-integrador/.


Docker solo se necesita en este módulo; si no puedes instalarlo, la API se ejecuta igual con uv run uvicorn api.main:app y el empaquetado se demuestra con un entorno mínimo (uv venv + uv pip install -r api/requirements-api.txt). Ver docker/README.md y ../docs/guia-entorno.md.

Los notebooks se ejecutan de principio a fin con el entorno de ../pyproject.toml; el notebook 01 crea mlflow.db y mlruns/ en notebooks/ (ambos fuera de Git). Reglas de estilo en ../docs/convenciones.md.