Si trabajas con machine learning, es muy probable que hayas vivido esta escena: un modelo con métricas excelentes en el notebook, celebrado en la reunión de resultados... y que seis meses después sigue sin usarse en ningún sistema real. No es mala suerte ni un caso aislado: es el destino de la mayoría de los modelos que se entrenan en la industria. En esta lección veremos qué es MLOps, por qué existe como disciplina, qué añade respecto al DevOps clásico y por qué el salto del notebook a producción es tan difícil. También conoceremos a CineClick, la plataforma ficticia de streaming que nos acompañará durante todo el curso como hilo conductor.

1. La escena del crimen: un modelo que nunca llegó a producción
2. Definición de MLOps
3. Qué añade MLOps respecto al DevOps clásico
4. La brecha notebook → producción
5. La deuda técnica oculta de los sistemas de ML
6. Beneficios de adoptar MLOps
7. CineClick: nuestro ejemplo motivador

Imagina al equipo de datos de CineClick, una plataforma de streaming por suscripción. Una data scientist ha entrenado un modelo que predice qué suscriptores van a darse de baja (churn). El modelo funciona bien en su notebook: buenas métricas, gráficas convincentes, aplausos en la demo.

Y entonces empiezan las preguntas incómodas:

• ¿Cómo lo usamos? El equipo de retención quiere una lista diaria de clientes en riesgo. El modelo vive en un .ipynb en el portátil de la data scientist.
• ¿Puedes reentrenarlo con los datos de este mes? El CSV original ya no existe; se sobrescribió. Nadie sabe exactamente con qué datos se entrenó.
• ¿Por qué hoy da resultados distintos que ayer? Nadie fijó semillas aleatorias ni versiones de librerías.
• ¿Quién lo mantiene cuando la data scientist esté de vacaciones? Silencio.

Ninguna de estas preguntas es sobre machine learning. Todas son sobre ingeniería, procesos y operación. Ese es exactamente el hueco que MLOps viene a cubrir.

MLOps (Machine Learning Operations) es el conjunto de prácticas, procesos y herramientas que permiten llevar modelos de machine learning a producción y mantenerlos funcionando de forma fiable, reproducible y auditable a lo largo del tiempo.

Dicho de otra forma: MLOps es la disciplina que convierte un experimento de ML en un producto de software con todas sus garantías. Combina tres mundos:

• Machine Learning: entrenar y evaluar modelos.
• Ingeniería de software: código versionado, testeado, empaquetado y desplegable.
• Operaciones (Ops): automatización, monitorización, respuesta a incidencias.

Conviene subrayar lo que MLOps no es:

• No es una herramienta concreta (aunque usaremos varias en este curso).
• No es "subir el modelo a un servidor" y olvidarse.
• No es un rol de una sola persona: es una forma de trabajar de todo el equipo.

Una definición operativa que usaremos durante el curso: un modelo está "en producción" cuando otros sistemas o personas dependen de sus predicciones, y el equipo puede reentrenarlo, redesplegarlo y vigilarlo sin heroicidades.

Si vienes del mundo del software, quizá pienses: "esto ya existe y se llama DevOps". Es una buena intuición, y de hecho MLOps hereda casi todo de DevOps: integración continua, despliegue continuo, infraestructura como código, monitorización. Pero hay una diferencia fundamental.

En el software clásico hay un artefacto cambiante: el código. Si el código no cambia, el sistema se comporta igual mañana que hoy.

En un sistema de ML hay tres artefactos cambiantes e interdependientes:

1. El código (preprocesado, entrenamiento, servicio).
2. Los datos (cambian constantemente, y con ellos el comportamiento del modelo).
3. El modelo (un binario generado a partir de los dos anteriores, con su propia versión y ciclo de vida).

Esta tabla resume las diferencias clave:

El punto más contraintuitivo para quien viene de software es el tercero: un sistema de ML puede romperse sin que nadie haya desplegado nada. Si CineClick cambia sus planes de precios, el modelo de churn entrenado con los planes antiguos empezará a fallar silenciosamente, aunque su código lleve meses sin tocarse. Esto obliga a monitorizar y reentrenar de forma continua, algo que en DevOps clásico no tiene equivalente directo (lo veremos en profundidad en el módulo 6).

Las cifras que circulan en la industria varían según el estudio, pero apuntan en la misma dirección: una gran mayoría de los modelos que se entrenan nunca llegan a producción, o tardan meses en hacerlo. ¿Por qué?

El notebook es una herramienta magnífica para explorar: iterar rápido, visualizar, probar ideas. Pero todo lo que lo hace bueno para explorar lo hace malo para producir:

• Ejecución fuera de orden: las celdas pueden ejecutarse en cualquier orden, así que el estado final depende de la historia de clics, no del código escrito. Dos personas con el mismo notebook pueden obtener resultados distintos.
• Estado oculto: variables definidas en celdas ya borradas siguen vivas en memoria. El notebook "funciona" hasta que reinicias el kernel.
• Sin tests ni modularidad: todo es un script largo; no hay funciones reutilizables ni pruebas automáticas.
• Dependencias implícitas: rutas absolutas al disco local, librerías instaladas a mano sin registrar versiones.
• Datos sin versionar: el CSV que usaste puede haber cambiado o desaparecido.

El resultado es la llamada brecha notebook → producción: el trabajo necesario para pasar de "funciona en mi máquina" a "funciona de forma fiable para el negocio" suele ser mucho mayor que el trabajo de entrenar el modelo. Los equipos sin prácticas MLOps cruzan esa brecha a mano, una vez, con dolor... y no pueden repetirlo.

Importante: la respuesta no es prohibir los notebooks. Son la herramienta correcta para la fase de exploración. El problema es quedarse en ellos. En el módulo 2 veremos precisamente cómo extraer el trabajo del notebook a código estructurado y reproducible.

En 2015, un grupo de ingenieros de Google publicó un paper muy influyente, "Hidden Technical Debt in Machine Learning Systems", cuya idea central se resume en una frase: en un sistema de ML real, el código del modelo es una fracción diminuta del sistema total. Alrededor de ese pequeño núcleo hay una enorme infraestructura de recogida de datos, verificación, gestión de recursos, servicio, monitorización... y ahí es donde se acumula la deuda.

Explicado con nuestras palabras, el paper identifica formas de deuda técnica que solo existen en sistemas de ML (o que en ML son mucho peores):

• Erosión de fronteras (entanglement): en software clásico puedes cambiar un módulo sin tocar los demás si respetas las interfaces. En ML, todo afecta a todo: cambiar una feature, añadir una columna o retocar el preprocesado cambia el comportamiento de todo el modelo. Lo resumen como "CACE": Changing Anything Changes Everything (cambiar cualquier cosa lo cambia todo).
• Dependencias de datos: son más peligrosas que las dependencias de código porque no hay compilador ni linter que las detecte. Si el equipo de facturación de CineClick renombra la columna metodo_pago o cambia sus valores posibles, el modelo de churn se degrada sin que salte ningún error.
• Bucles de realimentación ocultos: el modelo influye en el mundo que luego genera sus datos. Si el modelo de churn de CineClick hace que retención llame a los clientes en riesgo y muchos se queden, los datos futuros dirán que "esos perfiles no abandonan"... precisamente porque el modelo actuó. El modelo acaba aprendiendo de sus propias consecuencias.
• Código pegamento y "junglas de pipelines": sistemas de ML reales acumulan scripts sueltos que conectan fuentes de datos, transformaciones y salidas, frágiles y sin dueño claro.
• Configuración como ciudadano de segunda: umbrales, listas de features, hiperparámetros... a menudo viven en celdas de notebook o en la cabeza de alguien, sin versionar, cuando deberían tratarse con el mismo rigor que el código.
• Experimentos zombis: ramas de código con condicionales de experimentos antiguos que nadie se atreve a borrar.

La lección práctica: la deuda de ML no se ve en el notebook. Se manifiesta meses después, cuando hay que cambiar algo y nadie puede predecir las consecuencias. MLOps es, en gran parte, un conjunto de prácticas para pagar esa deuda de forma sistemática en lugar de acumularla.

Adoptar MLOps tiene un coste inicial (herramientas, procesos, aprendizaje), así que conviene tener claro qué se obtiene a cambio:

Hay un beneficio menos tangible pero igual de real: la moral del equipo. Los data scientists que ven sus modelos usados en producción, generando valor medible, están más motivados que los que acumulan notebooks en un cajón.

Durante todo el curso trabajaremos con CineClick, una plataforma ficticia de streaming por suscripción (piensa en un servicio de series y películas con planes mensuales). Su situación de partida es deliberadamente típica:

• El equipo de datos ha entrenado un modelo de predicción de churn: dado un suscriptor, estimar la probabilidad de que se dé de baja próximamente, usando datos ficticios como antigüedad, horas de visualización o tickets de soporte.
• El modelo vive en un notebook en el portátil de una data scientist, con todos los problemas que hemos descrito en esta lección.
• El negocio quiere usarlo de verdad: campañas de retención dirigidas a los clientes en riesgo.

A lo largo de los seis módulos convertiremos ese notebook en una plataforma MLOps completa: proyecto reproducible, experimentos registrados, servicio de predicción desplegado, automatización CI/CD y monitorización en producción. En la lección 01-04 presentaremos el proyecto en detalle, incluido el dataset y el notebook inicial; de momento quédate con la foto general: CineClick está exactamente en el punto donde mueren la mayoría de los modelos, y nuestro trabajo será sacarlo de ahí.

• Error: pensar que MLOps es comprar una herramienta. Las herramientas ayudan, pero MLOps es sobre todo proceso y cultura. Un equipo con Git, disciplina y scripts bien organizados hace mejor MLOps que uno con una plataforma carísima y notebooks caóticos.
• Error: demonizar los notebooks. El notebook es la herramienta correcta para explorar. El antipatrón es usarlo como entorno de producción, no usarlo a secas.
• Error: dejar el "paso a producción" para el final del proyecto. La brecha notebook→producción se cruza mejor si se piensa desde el día uno: rutas relativas, semillas fijadas, dependencias anotadas. Pequeños hábitos ahorran semanas.
• Error: creer que un sistema de ML estable no necesita mantenimiento. A diferencia del software clásico, un modelo se degrada aunque nadie toque el código, porque los datos del mundo cambian. Presupuesta mantenimiento continuo desde el principio.
• Consejo: cuando evalúes la salud de un proyecto de ML, no preguntes "¿qué métricas tiene el modelo?", pregunta "¿podrías reentrenarlo y redesplegarlo mañana si hiciera falta?". La respuesta a esa pregunta es la métrica MLOps más honesta.

Clasifica cada uno de estos problemas según sea (a) un problema de machine learning, (b) un problema que también existiría en software clásico (DevOps) o (c) un problema específico de sistemas de ML que MLOps debe resolver:

1. El modelo tiene un recall demasiado bajo en la clase minoritaria.
2. Nadie sabe qué versión del código está desplegada en el servidor.
3. El modelo funcionaba bien en enero, pero en junio sus predicciones son mucho peores, sin que nadie haya cambiado nada.
4. El servicio de predicción se cae cuando recibe muchas peticiones simultáneas.
5. No es posible reproducir el modelo entrenado hace tres meses porque el CSV original se sobrescribió.

En la lección hemos visto el concepto CACE (Changing Anything Changes Everything) del paper de deuda técnica en ML. Describe un escenario concreto en CineClick donde cambiar algo aparentemente inocuo en los datos de entrada degrade el modelo de churn sin producir ningún error visible.

Piensa en un modelo (real o hipotético) de tu propio trabajo que viva en un notebook. Escribe una lista de al menos cinco preguntas del tipo "¿qué pasaría si...?" que revelarían su fragilidad operativa (usa como inspiración las preguntas incómodas de la primera sección).

Solución 1:

1. (a) — Es un problema de modelado: elección de algoritmo, balanceo de clases, umbral de decisión. MLOps no lo resuelve (aunque sí ayuda a detectarlo y a iterar más rápido).
2. (b) — Es un problema clásico de DevOps: falta de trazabilidad de despliegues. Existe igual en cualquier aplicación web.
3. (c) — Deriva de datos o de concepto: el mundo cambió y el modelo no. Es el problema específico de ML por excelencia; no existe equivalente en software determinista. Lo trataremos en el módulo 6.
4. (b) — Escalabilidad de un servicio: problema clásico de operaciones, aunque en ML tiene matices propios (lo veremos en el módulo 4).
5. (c) — Falta de versionado de datos: en software clásico basta versionar el código; en ML, sin los datos exactos no puedes reproducir el artefacto. Lo resolveremos con DVC en el módulo 2.

Solución 2 (ejemplo de respuesta):

El equipo de producto de CineClick decide que el campo tickets_soporte deje de contar los tickets resueltos automáticamente por el chatbot y solo cuente los atendidos por humanos. Es un cambio razonable de negocio y no rompe ningún esquema: la columna sigue existiendo y sigue siendo un entero. Pero su distribución cambia (los valores bajan drásticamente), y el modelo de churn —que aprendió que "muchos tickets" señalaba riesgo de abandono— empieza a subestimar el riesgo de clientes insatisfechos. No hay error, no hay excepción, no hay alerta: solo predicciones cada vez peores. Esto ilustra tanto CACE como la fragilidad de las dependencias de datos.

Solución 3 (ejemplo de respuesta, las tuyas dependerán de tu caso):

1. ¿Qué pasaría si tuviera que reentrenar el modelo hoy con datos nuevos? ¿Sabría exactamente qué pasos seguir?
2. ¿Qué pasaría si mi portátil se estropeara? ¿Sobreviviría el modelo y su historia?
3. ¿Qué pasaría si un compañero ejecutara mi notebook de arriba abajo en su máquina? ¿Obtendría el mismo modelo?
4. ¿Qué pasaría si me preguntaran con qué datos exactos se entrenó la versión que está en uso?
5. ¿Qué pasaría si la fuente de datos cambiara una columna mañana? ¿Cómo me enteraría?
6. ¿Qué pasaría si el modelo empezara a predecir mal? ¿Quién lo notaría primero: mi equipo o el negocio?

Si varias respuestas son "no lo sé" o "sería un desastre", tienes un candidato perfecto para aplicar lo que aprenderás en este curso.

En esta lección hemos definido MLOps como el conjunto de prácticas que convierten experimentos de ML en productos de software fiables, y hemos visto por qué es necesario: a diferencia del software clásico, un sistema de ML tiene tres artefactos cambiantes (código, datos y modelo), puede degradarse sin que nadie toque nada, y acumula formas de deuda técnica propias —del entrelazamiento CACE a los bucles de realimentación ocultos— que el paper de Google sobre deuda oculta describió magistralmente. La brecha notebook→producción no se cruza con heroicidades puntuales, sino con procesos repetibles, y eso es exactamente lo que construiremos para CineClick.

Ahora que sabemos por qué existe MLOps, el siguiente paso es entender qué hay que gestionar: en la próxima lección recorreremos el ciclo de vida completo de un modelo de ML en producción, desde la definición del problema de negocio hasta la monitorización y el reentrenamiento, y veremos cómo los tres artefactos versionables evolucionan a ritmos distintos a lo largo de ese ciclo.