Semestre 02, 2026
Los modelos de las lecciones anteriores terminaron en un notebook con una métrica de evaluación.
El valor aparece cuando el modelo recibe datos reales, responde a otros sistemas y se mantiene correcto mientras los datos cambian.
Sculley et al. (NeurIPS 2015), a partir de los sistemas de ML de Google.
Un sistema maduro puede llegar a ser como máximo 5 % código de aprendizaje automático y al menos 95 % código de integración.
Costo futuro de mantenimiento que se acumula por decisiones rápidas tomadas hoy. En ML aparece en formas que el software tradicional no conoce.
Los autores atribuyen buena parte de esta deuda a la separación entre los roles de investigación y de ingeniería.
Muchos proyectos industriales de ML nunca llegan a producción por la dificultad de automatizarlos y operarlos, no por la calidad del modelo.
Paradigma que reúne buenas prácticas, conceptos y una cultura de desarrollo para la conceptualización, implementación, monitoreo, despliegue y escalabilidad de productos de aprendizaje automático de extremo a extremo. Su objetivo es llevar sistemas de ML a producción cerrando la brecha entre desarrollo y operación.
| Aspecto | DevOps | MLOps |
|---|---|---|
| Se versiona | Código | Código, datos y modelo |
| CI prueba | Código y componentes | Además, esquemas y calidad de datos |
| CD entrega | Un servicio | Un pipeline que despliega el modelo |
| Falla | Con un error visible | En silencio, con predicciones peores |
| Exclusivo | — | Entrenamiento continuo (CT) |
Un programa que funcionaba ayer funciona hoy mientras no cambie su código.
Un modelo que funcionaba ayer puede fallar hoy sin que cambie una sola línea, porque cambiaron los datos que recibe.
Ocho etapas, cada una manual o automática. El grado de automatización define la madurez.
El monitoreo de la etapa 8 alimenta de nuevo la etapa 1.
Nueve principios identificados por Kreuzberger et al.
En la lección de preparación de datos la reproducibilidad dependía de la documentación. En MLOps la garantiza el pipeline, que versiona automáticamente cada insumo de cada ejecución.
Clasificación de Google Cloud según cuánto del ciclo está automatizado.
Los datos se transforman de una forma al entrenar y de otra al servir, porque son dos implementaciones escritas por dos equipos distintos.
Cuando el pipeline cambia con frecuencia, probar y desplegar a mano cada cambio vuelve a ser un cuello de botella.
Aun en el nivel 2, el análisis de datos y el análisis del modelo los hace una persona. Lo automatizado es todo lo que se repite.
Una organización puede automatizar una etapa a la vez, sin pasar de un nivel al siguiente de golpe.
Cada ejecución consume cómputo, y reentrenar sobre datos defectuosos propaga el defecto a producción.
Antes de entrenar, los datos nuevos se comparan contra un esquema construido con los datos anteriores.
Columnas inesperadas, columnas faltantes o valores de otro tipo. El pipeline se detiene para que una persona investigue.
Los datos son válidos pero sus estadísticas cambiaron de forma significativa. El pipeline continúa y reentrena.
Una cadena de supermercados usa un modelo de pronóstico de demanda para decidir cuánto inventario pedir a cada proveedor. El modelo debe reentrenarse cada semana con las ventas recientes, sin intervención humana, y nunca debe reemplazarse por una versión que pronostique peor que la actual.
Cada característica se define una sola vez y se sirve desde dos bases de datos.
Histórico de características con latencia normal, para entrenamiento y experimentación.
Valor más reciente con latencia baja, para predicciones en producción.
Entrenamiento y predicción leen la misma definición, así que el training-serving skew desaparece por construcción.
Cuando falla, devuelve un error y una alerta de infraestructura lo detecta.
Cuando falla, sigue devolviendo predicciones con el formato correcto, solo que equivocadas. Ninguna alerta de infraestructura lo detecta.
Un modelo de impago de préstamos conoce su error meses después de la predicción.
Distribución de las entradas y de las predicciones, valores faltantes y latencia.
Exactitud, precisión, recall y F1, calculadas cuando llegan las etiquetas reales.
En un sistema que funciona, la proporción de clases predichas coincide con la proporción de clases observadas.
Siete roles identificados por Kreuzberger et al.
Un modelo genera retorno únicamente mientras está en producción y sus predicciones son correctas.
| Métrica técnica | Métrica de negocio |
|---|---|
| Recall del detector de fraude | Pérdidas evitadas |
| Precisión del modelo de abandono | Costo de las campañas de retención |
| Error del pronóstico de demanda | Inventario sobrante y ventas perdidas |
| Latencia del recomendador | Tasa de conversión |
Mide el efecto del modelo sobre la métrica de negocio con tráfico real, y conecta las dos columnas.
Cada equipo usaba herramientas distintas, entrenaba con lo que cabía en una computadora y construía su propio contenedor de serving. No existía un camino establecido a producción.
La empresa compraba casas a un precio fijado por modelos de valuación y las revendía.
Las predicciones del modelo no se usaban para informar a una persona, sino para fijar directamente el precio de compra de miles de casas.
Cuando las predicciones se convierten en compras, el tiempo que tarda en detectarse que el modelo ya no refleja el mercado se mide en dinero.
Breck et al. (Google, 2017). Cuatro secciones, datos, modelo, infraestructura y monitoreo.
La mejora se concentra primero en la sección más débil.
| Puntaje | Interpretación |
|---|---|
| 0 | Más cercano a un proyecto de investigación |
| (0, 1] | Algunas pruebas, con huecos de confiabilidad |
| (1, 2] | Productización básica |
| (2, 3] | Razonablemente probado |
| (3, 5] | Pruebas y monitoreo automatizados sólidos |