1 · Qué es MLOps
Tu modelo entrenado en un notebook no es un producto. MLOps es la disciplina de llevar un modelo a producción y mantenerlo sano — las prácticas que cierran la brecha entre 'funciona en mi máquina' y 'sirve a usuarios reales de forma confiable'.
MLOps es DevOps adaptado al machine learning: añade el versionado de DATOS y MODELOS, el seguimiento de experimentos y el monitoreo de DRIFT (deriva) sobre la automatización habitual de build/test/deploy — porque un sistema de ML puede pudrirse en silencio a medida que cambian los datos del mundo, aunque el código nunca cambie.
Sin esto:
Sin MLOps despliegas un modelo una vez, pierdes el rastro de qué versión está en producción, no puedes reproducir cómo se entrenó y nunca notas cuándo se degrada silenciosamente — el clásico fallo de 'lo desplegamos y nos olvidamos'.
Terminaste el capstone de scikit-learn en bc-py-59: un Pipeline ajustado con GridSearchCV, evaluado en un conjunto reservado y guardado con joblib.dump. Ese archivo .joblib es un artefacto real y valioso — pero no es un producto. Nadie puede usarlo. Está en tu laptop. Para hacerlo útil tienes que envolverlo en una API, empaquetarlo para que corra en cualquier lugar, desplegarlo en un servidor y seguir vigilándolo después del lanzamiento. Todo ese viaje — del artefacto entrenado a un servicio confiable y monitoreado — es lo que cubre MLOps.
La brecha del notebook a producción. Un notebook es interactivo, de un solo usuario y está lleno de estado oculto (celdas ejecutadas en desorden, variables que quedaron de experimentos anteriores). Producción es lo opuesto: desatendida, multiusuario, y debe dar la misma respuesta cada vez para la misma entrada. Cerrar esa brecha es el problema central que resuelve MLOps.
El ciclo de vida del ML es un bucle, no una línea. El software tradicional se lanza y queda "terminado". El ML nunca está terminado, porque los datos siguen cambiando. El ciclo de vida da vueltas continuamente:
datos ─▶ entrenar ─▶ evaluar ─▶ desplegar ─▶ monitorear
▲ │
└──────────────────────────────────────────────┘
(drift detectado → recolectar datos nuevos → reentrenar)
Recolectas datos, entrenas un modelo, lo evalúas, lo despliegas y lo monitoreas en producción. Cuando el monitoreo detecta que los datos en vivo se han alejado de aquello con lo que el modelo fue entrenado, vuelves atrás: reúnes datos frescos y reentrenas. El bucle nunca se cierra para siempre.
Deuda técnica oculta. El famoso artículo de Google "Hidden Technical Debt in Machine Learning Systems" (Sculley et al., 2015) hizo una observación ya clásica: el código del modelo de ML es solo una cajita diminuta dentro de un sistema mucho más grande. A su alrededor están la recolección de datos, la extracción de características, la configuración, la infraestructura de serving y el monitoreo — y esa maquinaria de alrededor es donde viven la mayoría del costo y el riesgo a largo plazo. Ignorarla es cómo un modelo que obtuvo puntajes hermosos en un notebook se convierte en un lastre imposible de mantener seis meses después.
DevOps vs MLOps. MLOps toma casi todo de DevOps — control de versiones, pruebas automatizadas, pipelines de CI/CD, contenedores, infraestructura como código. Pero el ML añade problemas que el software normal no tiene. En el software normal las entradas son código; si el código no cambia, el comportamiento no cambia. En ML, los datos también son una entrada que cambia por su cuenta. Así que MLOps añade tres preocupaciones específicas del ML: versionado de datos + modelos (no solo código), seguimiento de experimentos (qué datos + hiperparámetros produjeron qué métricas) y monitoreo de drift (detectar cuándo el mundo en vivo ya no coincide con el mundo de entrenamiento).
El bucle del ciclo de vida del ML y exactamente qué añade MLOps sobre DevOps: versionado de datos/modelos, seguimiento de experimentos y monitoreo de drift.
¿Qué distingue principalmente a MLOps de DevOps a secas?
- Un modelo `.joblib` entrenado es un artefacto, no un producto; MLOps es la disciplina de convertirlo en un servicio confiable y monitoreado y mantenerlo sano.
- El ciclo de vida del ML es un bucle — datos → entrenar → evaluar → desplegar → monitorear → de vuelta a los datos — porque el drift implica que un modelo nunca está 'terminado' para siempre.
- MLOps = DevOps + añadidos específicos del ML: versionado de datos/modelos, seguimiento de experimentos y monitoreo de drift; el código del modelo es solo una cajita en un sistema mucho más grande (Sculley et al., 2015).
Todo modelo que llega a servir a un usuario real — un detector de fraude, un recomendador, un predictor de churn — vive o muere por las prácticas de MLOps que lo envuelven: empaquetado, despliegue, versionado y monitoreo.
Si lo quitas: Construirías grandes modelos que nunca salen del notebook, o los desplegarías una vez sin forma de reproducir, rastrear ni notar cuándo se rompen — la brecha que este track entero existe para cerrar.