18 · Capstone: el camino de extremo a extremo
Cada pieza de este track fue un eslabón. El capstone los encadena en una sola cadena: entrenar → trackear con MLflow → versionar con DVC → envolver en FastAPI + Docker → controlar con CI/CD → push a ECR → desplegar en la nube → monitorear el drift → reentrenar. Ese bucle, no una etapa cualquiera, es MLOps.
MLOps no es una herramienta cualquiera — es el **bucle** que las conecta. El camino de extremo a extremo es: **entrenar** el modelo → **trackear** el run con MLflow → **versionar** datos y el artefacto con DVC → envolverlo en un servicio **FastAPI** y una imagen **Docker** → controlar cada cambio con **CI/CD de GitHub Actions** → push de la imagen a **ECR** → **desplegar** en la nube (Beanstalk / EC2 / un endpoint gestionado) → **monitorear** el drift → cuando el drift dispara, **reentrenar** y enviar el nuevo modelo de vuelta por el mismo pipeline. Cada etapa de este track fue un eslabón; el capstone es la cadena entera — y el bucle cerrándose de vuelta al reentrenamiento es lo que lo hace MLOps en vez de un despliegue de una sola vez.
Sin esto:
Sin el bucle que conecta, tienes capacidades aisladas — un modelo en un notebook aquí, un Dockerfile allá, un archivo de CI en otro lado — pero ningún camino confiable y repetible de un cambio de código a un modelo en producción monitoreado que se reentrena cuando el mundo cambia. Las piezas no suman MLOps hasta que se encadenan.
Has construido cada eslabón. Ahora encadénalos en una sola cadena. Este capstone recorre el camino completo de extremo a extremo que lleva la pipeline de scikit-learn de bc-py-59 — un modelo en un notebook — hasta un servicio en producción monitoreado y reentrenable. Léelo como la historia de toda la infraestructura que sostiene una sola solicitud de predicción.
1. Entrenar (Ch 1–2). Empieza con el modelo. Un proyecto reproducible — dependencias fijadas, una semilla fija, una estructura src/ — entrena la pipeline y la serializa a un único artefacto (model.joblib). Reproducibilidad primero, porque todo lo de abajo asume que puedes reconstruir este modelo exacto.
2. Trackear con MLflow (Ch 4). Cada run de entrenamiento registra sus parámetros, métricas y el artefacto en MLflow, así "¿qué run fue el mejor?" es una consulta, no un recuerdo. El registry promueve un run elegido None → Staging → Production.
3. Versionar con DVC (Ch 5). Git versiona el código; DVC versiona los datos y el modelo. Una pipeline dvc.yaml hace reproducible el camino de datos crudos → artefacto entrenado: dvc repro vuelve a correr solo lo que cambió.
4. Servir con FastAPI + Docker (Ch 2–3). El modelo se envuelve en un endpoint FastAPI /predict (un esquema de solicitud Pydantic valida las entradas antes de predecir) con una verificación /healthz, luego se contenedoriza en una imagen Docker — la misma imagen en todas partes.
5. Controlar con CI/CD (Ch 6). GitHub Actions corre las pruebas y el linter en cada PR (CI), y en el merge a main construye la imagen, la sube y despliega (CD) — con secretos y una compuerta de aprobación de producción. Un cambio roto nunca llega a producción.
6. Push a ECR (Ch 7). La imagen construida se etiqueta con el SHA de git y se sube a un registry (ECR en AWS): login → tag → push. La nube hace pull de este exacto artefacto — sin reconstrucción, sin drift entre lo probado y lo desplegado.
7. Desplegar en la nube (Ch 7). La imagen corre en el peldaño correcto del espectro de gestionado-vs-control: Beanstalk para un contenedor gestionado, EC2 para control total, un endpoint de SageMaker/Azure ML para serving nativo de ML con autoescalado. El modelo ya está en vivo tras un endpoint HTTPS.
8. Monitorear el drift (Ch 8). Cada predicción se registra; PSI/KS vigilan la distribución de entrada en vivo contra la referencia de entrenamiento. Las métricas operativas (latencia, errores) van al lado.
9. Reentrenar — y volver al bucle. Cuando el drift cruza el umbral, una alerta dispara y gatilla el reentrenamiento: trae datos etiquetados frescos, reentrena (paso 1), trackea (2), versiona (3) — y el nuevo modelo fluye de vuelta por servir → CI/CD → push → desplegar → monitorear. Esa flecha de retorno es el punto. Un despliegue de una sola vez es un proyecto; el bucle — desplegar → monitorear → detectar → reentrenar → desplegar — es MLOps.
El workflow de CI/CD consolidado de abajo ata build + push + deploy en un solo archivo, y el pipeline animado traza la cadena completa. Este es todo el track en un solo aliento: de un modelo en un notebook a un modelo en producción que se vigila a sí mismo y se renueva a sí mismo.
Un workflow `mlops.yml` consolidado: un job `ci` (pruebas + lint en cada PR) y un job `deploy` que, solo en el merge a main y tras CI en verde, construye la imagen, la sube a ECR (login → tag → push por SHA de git) y despliega — build + push + deploy atados en un solo archivo.
Pipeline de CI/CD: cada etapa debe pasar antes de la siguiente — un fallo detiene el despliegue.
¿Qué secuencia ordena correctamente las etapas centrales del ciclo de vida de ML de extremo a extremo que construyó este track?
- El camino de extremo a extremo es una cadena: entrenar → trackear (MLflow) → versionar (DVC) → servir (FastAPI + Docker) → CI/CD → push (ECR) → desplegar (nube) → monitorear → reentrenar.
- Un workflow de CI/CD consolidado ata build + push + deploy: las pruebas controlan cada PR, y un merge a main construye la imagen, la sube a ECR por SHA de git y despliega tras una compuerta de aprobación.
- MLOps es el bucle que conecta, no una herramienta cualquiera — la flecha de retorno de monitorear → reentrenar → desplegar es lo que convierte un despliegue de una sola vez en un modelo que perdura y se renueva.
Un equipo de ML maduro corre exactamente este bucle en producción: cada cambio de modelo fluye entrenar → trackear → versionar → servir → CI/CD → registry → desplegar → monitorear, y una alerta de drift reabre el bucle en el reentrenamiento — el pipeline que les permite enviar y operar modelos continuamente.
Si lo quitas: Tendrías capacidades aisladas — un modelo en notebook, un Dockerfile suelto, un archivo de CI solitario — pero ningún camino confiable y repetible de un cambio de código a un modelo en producción monitoreado y que se reentrena solo.