En la lección anterior vimos por qué la mayoría de los modelos mueren en el notebook y qué aporta MLOps. Ahora toca dibujar el mapa completo: ¿qué etapas atraviesa un modelo desde que alguien detecta un problema de negocio hasta que sus predicciones se usan —y se vigilan— en producción? Entender este ciclo de vida es imprescindible, porque cada módulo del curso equipa una de sus etapas con herramientas y automatización. Además, veremos una idea que estructura todo el MLOps: en ML no versionamos un artefacto sino tres (código, datos y modelo), y cada uno evoluciona a su propio ritmo.

1. Visión general: un ciclo, no una línea recta
2. Las etapas del ciclo de vida, una a una
3. Los tres artefactos versionables y sus ritmos de cambio
4. Los bucles de realimentación
5. Ciclo de vida de software clásico vs. ciclo de vida de ML

La palabra clave es ciclo. Un proyecto de ML no termina cuando el modelo se despliega; en cierto sentido, ahí es cuando empieza. El modelo en producción genera datos y evidencia que alimentan la siguiente vuelta: reentrenamientos, nuevas features, incluso la redefinición del problema.

Este es el ciclo completo que iremos desgranando:

Fíjate en que hay tres caminos de vuelta: el reentrenamiento rutinario (con datos frescos), la vuelta a preparación de datos (cuando hacen falta nuevas features o correcciones) y, en casos extremos, la vuelta a la definición del problema (cuando el negocio cambia tanto que el planteamiento original ya no sirve).

Recorramos cada etapa usando CineClick como ilustración conceptual. Recuerda que aquí describimos qué pasa en cada etapa; las herramientas concretas se ven en los módulos indicados.

Todo empieza (o debería empezar) con una pregunta de negocio, no con un algoritmo. En CineClick, la pregunta es: "perdemos suscriptores cada mes; ¿podemos saber quién va a irse para intentar retenerlo?".

En esta etapa se decide:

• El objetivo de negocio: reducir el churn mensual, por ejemplo del 5% al 4%.
• La traducción a un problema de ML: clasificación binaria — dado un suscriptor, predecir si abandonará en los próximos 30 días.
• Las métricas de éxito, en dos niveles: la métrica de ML (por ejemplo, recall sobre la clase "abandona") y la métrica de negocio (bajas evitadas, ingresos retenidos). Un modelo puede mejorar la primera sin mover la segunda; ambas hay que definirlas antes de entrenar nada.
• Las restricciones operativas: ¿necesitamos predicciones en tiempo real o basta una lista diaria? ¿Qué latencia y coste son aceptables? Estas decisiones condicionarán el patrón de despliegue (lo veremos en el módulo 4).

Es la etapa más barata de corregir y la más cara de corregir tarde: un modelo excelente que responde a la pregunta equivocada es un fracaso caro.

Aquí se localizan las fuentes (en CineClick: base de datos de suscripciones, logs de visualización, sistema de tickets de soporte), se extraen, se limpian y se transforman en un dataset de entrenamiento con sus features (antigüedad, horas semanales, tickets...) y su etiqueta (¿abandonó o no?).

Puntos clave de la etapa:

• Suele consumir la mayor parte del tiempo del proyecto (la cifra folclórica del "80% del tiempo es preparar datos" es exagerada pero apunta bien).
• Definir la etiqueta es más sutil de lo que parece: ¿qué cuenta como "abandono"? ¿Cancelar? ¿No renovar? ¿Y si vuelve a los dos meses?
• Aquí nace el primer requisito de reproducibilidad: el dataset exacto usado para entrenar debe poder recuperarse después. De su versionado se ocupa el módulo 2 (DVC).

La etapa que todo el mundo asocia con "hacer ML": elegir algoritmos, entrenar, ajustar hiperparámetros, comparar resultados en un conjunto de prueba. Es un proceso inherentemente iterativo y experimental: decenas o cientos de ejecuciones con pequeñas variaciones.

Desde la óptica MLOps, lo importante es que cada experimento quede registrado: qué código, qué datos, qué parámetros y qué métricas. Sin ese registro, "el mejor modelo" es un recuerdo, no un hecho. El tracking de experimentos es el tema del módulo 3 (MLflow).

Antes de desplegar, el modelo candidato pasa un control de calidad que va más allá de "buena métrica en test":

• Validación técnica: ¿funciona con el formato de datos real? ¿Su latencia y tamaño son aceptables?
• Validación de comportamiento: ¿rinde de forma aceptable en subgrupos relevantes (planes premium vs. básicos, clientes nuevos vs. antiguos), o su buena métrica global esconde subgrupos donde falla?
• Comparación con el modelo actual: ¿es realmente mejor que el que ya está en producción (o que una regla simple de negocio)?
• Revisión y aprobación: alguien —humano— decide que el modelo es apto y queda constancia de ello. En el módulo 3 veremos cómo el model registry formaliza esta promoción, y en el módulo 5 cómo automatizar parte de estas comprobaciones.

El modelo validado se integra donde el negocio lo necesita. Para el churn de CineClick podría ser un proceso batch nocturno que puntúa a todos los suscriptores, o una API que responde en tiempo real; la elección entre batch, online y streaming es justamente el arranque del módulo 4, y el empaquetado y escalado (FastAPI, Docker, Kubernetes) su desarrollo.

Lo esencial en esta etapa, conceptualmente: el despliegue debe ser repetible (no un ritual manual) y reversible (poder volver al modelo anterior en minutos si algo va mal).

El modelo está en producción; ahora hay que vigilarlo en dos planos:

• Como servicio de software: ¿está vivo? ¿responde a tiempo? ¿cuántos errores da? (lo mismo que cualquier API).
• Como modelo: ¿los datos que recibe se parecen a los de entrenamiento? ¿sus predicciones siguen siendo buenas? Esto último es difícil porque la verdad llega con retraso: para saber si un suscriptor "iba a abandonar" hay que esperar semanas.

La degradación silenciosa —deriva de datos y de concepto— y su detección son el corazón del módulo 6.

Tarde o temprano el modelo se queda anticuado y hay que reentrenarlo con datos frescos. Puede dispararse por calendario (cada mes), por alerta de monitorización (la deriva superó un umbral) o manualmente. El reentrenamiento reutiliza las etapas 2-4: por eso conviene que estén automatizadas en un pipeline (módulos 2 y 5), y por eso el ciclo es un ciclo. El módulo 6 trata cuándo y cómo automatizarlo.

Ya adelantamos en la lección anterior que un sistema de ML tiene tres artefactos cambiantes. Ahora podemos precisarlo: cada uno tiene su propio ritmo de evolución, y esa asincronía es la razón de que necesiten versionado independiente pero enlazado.

Tres observaciones importantes:

• El modelo es un artefacto derivado: modelo = f(código, datos, configuración). Si versionas el código y los datos exactos, puedes regenerar el modelo; si solo guardas el binario, tienes un resultado sin receta.
• Pueden cambiar de forma independiente: CineClick puede reentrenar el mismo código con datos de junio (nuevo modelo, mismo código) o refactorizar el código de servicio sin tocar el modelo (nuevo despliegue, mismo modelo). Cada combinación necesita su trazabilidad.
• La pregunta de auditoría clave es transversal: "para la predicción que hizo el sistema el día X, ¿qué versión del modelo se usó, con qué código se entrenó y sobre qué datos?". Toda la cadena de herramientas del curso (Git para código, DVC para datos, MLflow para modelos) existe para poder responderla.

Un sistema de ML en producción no solo consume datos: los genera. Este es el rasgo que más diferencia su ciclo de vida del software clásico, y tiene una cara buena y otra peligrosa.

La cara buena: el modelo en producción produce la materia prima de su propia mejora.

1. El modelo de CineClick puntúa hoy a cada suscriptor con su riesgo de abandono.
2. Durante las semanas siguientes, la realidad "etiqueta" esos casos: algunos se dan de baja, otros no.
3. Esas parejas (features del momento de la predicción, resultado real) son ejemplos de entrenamiento nuevos y perfectamente etiquetados.
4. El siguiente reentrenamiento usa esos datos: el sistema aprende del presente, no solo del pasado.

Para que este bucle funcione hay que diseñarlo: registrar las predicciones con sus features en el momento de hacerlas, y unir después cada predicción con su resultado real. Si no se registra, la información se pierde y cada reentrenamiento parte de cero.

La cara peligrosa: si el negocio actúa sobre las predicciones, el modelo contamina sus propios datos futuros. Es el bucle oculto que vimos en la lección anterior: retención llama a los clientes de alto riesgo, muchos se quedan, y los datos futuros dicen que ese perfil "no abandona". Un reentrenamiento ingenuo aprendería justo lo contrario de la realidad.

No hace falta resolver esto hoy (hay técnicas: registrar qué clientes recibieron intervención, mantener grupos de control...); lo que sí hace falta desde el diseño es saber que el bucle existe y registrar la información necesaria para tratarlo. Volveremos sobre ello al hablar de reentrenamiento en el módulo 6.

Cerremos el mapa con la comparación de los dos ciclos de vida, que resume por qué el de ML necesita disciplinas adicionales:

La conclusión práctica: planifica el proyecto de ML como un ciclo permanente, no como un proyecto con final. Presupuestar solo hasta el primer despliegue es el error de planificación más común en equipos que vienen del software tradicional.

• Error: empezar por la etapa 3 (entrenar) saltándose la 1 (negocio). Es tentador ir directo al modelo. Sin métrica de negocio definida, no sabrás si el modelo sirve, solo si acierta. Escribe el objetivo de negocio y su métrica antes de la primera línea de código.
• Error: tratar la validación como "mirar el accuracy en test". La validación pre-producción incluye subgrupos, latencia, comparación con el modelo vigente y aprobación explícita. Un modelo con mejor métrica global puede ser peor para el negocio si falla en el segmento que más importa.
• Error: no registrar las predicciones de producción. Sin ese registro no hay bucle de realimentación bueno: no podrás construir datasets frescos ni medir el rendimiento real del modelo. Registrar predicciones (con sus features y timestamp) es barato hoy e impagable dentro de seis meses.
• Error: versionar solo el modelo (el binario). Un .pkl sin el código y los datos que lo generaron es una caja negra irrecuperable. Versiona la receta, no solo el plato.
• Consejo: dibuja el ciclo de vida de tu proyecto actual y marca en rojo las etapas que hoy son manuales, indocumentadas o inexistentes (típicamente: validación formal, monitorización y reentrenamiento). Ese dibujo es tu hoja de ruta MLOps personal, y encaja con los niveles de madurez que veremos en la próxima lección.

Ordena cronológicamente estas actividades del equipo de CineClick y asigna cada una a su etapa del ciclo de vida:

• (a) Se detecta que las predicciones de julio son notablemente peores que las de marzo.
• (b) Se acuerda que el objetivo es reducir el churn mensual y que la métrica de ML será el recall de la clase "abandona".
• (c) Se lanza un proceso que vuelve a entrenar el modelo con los datos de los últimos seis meses.
• (d) Se construye el dataset uniendo suscripciones, logs de visualización y tickets de soporte.
• (e) Se comprueba que el modelo candidato supera al actual también en el segmento de clientes con plan básico, y un responsable aprueba su paso a producción.
• (f) Se prueban tres algoritmos con distintas combinaciones de hiperparámetros.
• (g) El modelo aprobado empieza a puntuar suscriptores cada noche.

El modelo de churn de CineClick lleva 3 meses en producción. El equipo de retención ha estado ofreciendo un descuento a todos los clientes que el modelo marca con riesgo alto, y el 60% de ellos ha permanecido. Ahora toca reentrenar. Explica: (1) qué problema tiene usar directamente los datos de estos 3 meses como si nada, y (2) qué información debería haberse registrado desde el principio para poder tratarlo.

Para cada uno de estos tres cambios en CineClick, indica cuál(es) de los tres artefactos (código, datos, modelo) cambia(n) de versión, razonando la cadena de efectos:

1. Un ingeniero corrige un bug en la función que calcula horas_semana (contaba también las horas con el reproductor en pausa).
2. Llega el cierre de mes y se incorporan los datos de junio para el reentrenamiento programado, sin tocar nada más.
3. Se refactoriza el código del servicio de predicción para hacerlo más rápido, sin cambiar el preprocesado ni el entrenamiento.

Solución 1:

Orden: b → d → f → e → g → a → c

• (b) Etapa 1, definición del problema de negocio.
• (d) Etapa 2, obtención y preparación de datos.
• (f) Etapa 3, entrenamiento y evaluación.
• (e) Etapa 4, validación (comportamiento por subgrupos + aprobación humana).
• (g) Etapa 5, despliegue (patrón batch nocturno).
• (a) Etapa 6, monitorización (detección de degradación).
• (c) Etapa 7, reentrenamiento, que reabre el ciclo por la etapa 3 (o la 2, si además se revisan los datos).

Solución 2:

1. El problema: es el bucle de realimentación peligroso. Los clientes marcados como "riesgo alto" recibieron una intervención (descuento) que cambió su comportamiento: muchos que iban a abandonar no lo hicieron. Si se reentrena con esos datos tal cual, el modelo aprenderá que los perfiles de riesgo alto "no abandonan", es decir, aprenderá a desaprender justo la señal que lo hacía útil. El modelo se degradaría precisamente por haber funcionado.
2. Qué registrar: como mínimo, (a) las predicciones de cada cliente con sus features y fecha; (b) qué clientes recibieron la intervención (el descuento) y cuándo; e idealmente (c) un grupo de control: una fracción de clientes de riesgo alto a los que no se ofreció el descuento. Con esa información se puede entrenar excluyendo o corrigiendo los casos intervenidos, y el grupo de control permite además medir el efecto real de la campaña. Sin ese registro, los datos de los 3 meses son irrecuperablemente ambiguos.

Solución 3:

1. Código, datos y modelo, los tres. Cambia el código (nueva versión de la función). Al recalcular horas_semana, el dataset de entrenamiento regenerado es distinto (nueva versión de los datos). Y con datos distintos, el reentrenamiento produce un modelo distinto (nueva versión del modelo). Es un ejemplo perfecto de CACE: un "arreglo pequeño" propaga versiones nuevas por toda la cadena — y por eso los tres versionados deben quedar enlazados.
2. Datos y modelo. El código no cambia; los datos sí (incorporan junio) y el modelo resultante también. Es el caso rutinario de reentrenamiento: mismo código, receta nueva por ingredientes nuevos.
3. Solo código. El servicio es más rápido, pero el preprocesado y el entrenamiento no se tocan: el modelo desplegado sigue siendo exactamente el mismo binario, y los datos ni intervienen. Hay que desplegar la nueva versión del servicio, pero no reentrenar ni revalidar el modelo (sí conviene revalidar que el servicio devuelve las mismas predicciones que antes).

Hemos recorrido el mapa completo del ciclo de vida de un modelo en producción: definición del problema de negocio, datos, entrenamiento, validación, despliegue, monitorización y reentrenamiento — un ciclo que se realimenta, no una línea con final. Hemos visto que en ML se versionan tres artefactos (código, datos, modelo) que evolucionan a ritmos distintos pero deben quedar enlazados, y que el modelo en producción genera los datos de su propia mejora... y a veces de su propia contaminación, si no se diseñan los bucles de realimentación con cuidado.

Este mapa nos dice qué hay que hacer, pero no cuánto de ello está automatizado en un equipo dado, ni quién se encarga de cada etapa. Esas son exactamente las dos preguntas de la siguiente lección: los niveles de madurez MLOps —del proceso completamente manual al CI/CD completo— y los roles del equipo que colaboran a lo largo del ciclo. Allí situaremos a CineClick en su punto de partida y trazaremos hacia dónde lo llevará este curso.