1. El contexto de negocio: por qué predecir el churn importa
2. El dataset: clientes_churn.csv
3. El notebook inicial, completo y explicado
4. Diagnóstico: qué está mal en este notebook
5. El stack del curso: etapa → herramienta → módulo
6. Hoja de ruta del resto del curso

CineClick es una plataforma de streaming por suscripción con planes mensuales (básico, estándar y premium). Como todo negocio de suscripción, su salud depende de una aritmética sencilla y despiadada:

• Adquirir un cliente nuevo es caro: campañas, descuentos de bienvenida, meses gratis. En el sector se asume que captar un suscriptor cuesta varias veces más que retener a uno existente (una regla habitual dice que entre 5 y 7 veces más, aunque el múltiplo exacto depende del negocio).
• Retener es barato... si sabes a quién retener: una llamada, un descuento puntual o una recomendación de contenido pueden bastar. Pero ofrecer descuentos a todos los clientes destruye margen; la clave es dirigir la retención a quienes realmente están en riesgo.
• El churn compone: un 5% de bajas mensuales parece poco, pero sostenido significa perder cerca de la mitad de la base de clientes en un año si no se compensa con adquisición.

De ahí el proyecto: un modelo que, para cada suscriptor activo, estime la probabilidad de que se dé de baja próximamente, para que el equipo de retención concentre sus recursos en los clientes de mayor riesgo. La métrica de negocio es clara (bajas evitadas e ingresos retenidos frente al coste de las campañas), y la de ML la discutiremos críticamente más abajo — adelanto: el notebook actual usa la equivocada.

Todos los datos del proyecto son ficticios y generados sintéticamente: representan patrones plausibles de un negocio de streaming, pero ningún cliente real. Es la práctica correcta para formación y para desarrollo: nunca uses datos reales de personas donde no toca.

El data engineer de CineClick genera periódicamente un extracto con una fila por suscriptor y estas columnas:

Dos rasgos del dataset que serán importantes durante todo el curso:

• Las clases están desbalanceadas: solo en torno al 15% de las filas tienen abandono = 1. Es lo normal en churn (por suerte para CineClick, la mayoría de los clientes se queda), y tiene consecuencias directas sobre qué métricas sirven y cuáles engañan.
• Mezcla de tipos: numéricas (antiguedad_meses, horas_semana, tickets_soporte), categóricas (plan, metodo_pago) y binarias (descuento_activo). Las categóricas necesitan codificación antes de entrenar.

Este es el estado del arte en CineClick hoy: un único notebook, churn_final_v3_DEFINITIVO.ipynb (el nombre ya cuenta una historia), en el portátil de la data scientist. Su contenido, volcado como un solo bloque, es este:

Expliquémoslo paso a paso, porque como código de exploración es perfectamente razonable y conviene entender qué hace cada parte:

• Carga (pd.read_csv): lee el CSV desde una ruta del escritorio de Laura a un DataFrame de pandas — la estructura tabular con la que trabajaremos siempre.
• Limpieza (dropna, filtro de negativos): elimina las filas con valores nulos y las que tienen horas de visualización negativas (un error conocido del sistema de logs). Decisiones defendibles, pero tomadas sin registrar cuántas filas se pierden ni por qué.
• Eliminación del id (drop): correcto — id_cliente es un identificador arbitrario; dejarlo permitiría al modelo "memorizar" clientes en lugar de aprender patrones.
• One-hot encoding (pd.get_dummies): convierte cada categórica en columnas binarias. plan se convierte en plan_basico, plan_estandar, plan_premium con valores 0/1, y análogamente metodo_pago. Es necesario porque los algoritmos de scikit-learn requieren entradas numéricas.
• Separación X/y: X son las features (todas las columnas menos la etiqueta) e y la etiqueta abandono.
• train_test_split(X, y, test_size=0.2): reserva el 20% de las filas para evaluar el modelo con datos que no ha visto durante el entrenamiento. Fíjate en lo que falta entre los paréntesis; volveremos sobre ello enseguida.
• RandomForestClassifier(n_estimators=100): un bosque aleatorio de 100 árboles de decisión. Elección razonable para tabulares: robusto, admite mezcla de tipos de features y funciona decentemente sin apenas ajuste.
• modelo.fit(...): el entrenamiento propiamente dicho.
• Evaluación con accuracy_score: porcentaje de predicciones correctas sobre el conjunto de test. El comentario # Salió 0.87 es literalmente todo el registro experimental que existe del proyecto.
• pickle.dump(...): serializa el modelo entrenado a un fichero binario .pkl en el escritorio, que es lo que Laura enviaría por chat si alguien le pidiera "el modelo".

Insistamos: este notebook no es obra de una mala profesional. Es el resultado natural de la fase de exploración, y como exploración cumplió su misión: demostró que hay señal en los datos. El problema es que CineClick quiere usarlo en producción tal cual, y para eso acumula todos los pecados que ahora vamos a nombrar.

Pasemos la lista con la mirada MLOps de las lecciones anteriores. Cada problema es concreto y tiene consecuencia concreta:

Merece la pena detenerse en el problema 5, porque es el único que engaña incluso con el notebook delante. Con clases desbalanceadas (85% "no abandona"), la accuracy es una métrica casi vacía: mide sobre todo lo fácil (acertar los que se quedan) e ignora lo valioso (encontrar los que se van). Las métricas adecuadas para este problema —precision y recall sobre la clase positiva, y sus derivadas— aparecerán cuando montemos la evaluación seria del pipeline en el módulo 2 y las comparaciones de experimentos en el módulo 3. De momento, quédate con la sospecha: ese 0.87 no dice lo que Laura cree que dice.

Cada problema del diagnóstico tiene su respuesta en una etapa del ciclo de vida, y cada etapa su herramienta en este curso. Todas son de código abierto o tienen capa gratuita, y todas son estándares de facto o candidatas serias a serlo — pero recuerda la lección 01-01: lo importante es la práctica que encarnan, no la marca.

Un aviso sobre expectativas: este stack es una combinación coherente y muy usada, no la verdad revelada. En tu empresa quizá se use otro orquestador u otra plataforma de tracking; los conceptos que aprenderás se transfieren casi uno a uno, porque todas las herramientas de cada categoría resuelven el mismo problema del ciclo de vida.

Así se desarrollará la transformación de CineClick, módulo a módulo:

• Módulo 2 — Del notebook al código reproducible: refactorizaremos este notebook en un proyecto Python estructurado, con entorno reproducible, el dataset bajo control de DVC y un pipeline de entrenamiento que cualquiera puede ejecutar. Al terminarlo, los problemas 1, 2, 3, 8, 9 y 10 estarán resueltos o encarrilados.
• Módulo 3 — Experimentos y registro: cada entrenamiento quedará registrado en MLflow con sus parámetros y métricas (las correctas, no solo accuracy), y los modelos se versionarán y promocionarán en el model registry. Adiós a los problemas 4, 5 y 7.
• Módulo 4 — Servir en producción: el modelo dejará el .pkl del escritorio para convertirse en un servicio FastAPI empaquetado con Docker y desplegado de forma escalable.
• Módulo 5 — Automatización: tests de código, datos y modelo en CI (problema 6), despliegue automatizado y orquestación de los pipelines — el salto del nivel 1 al nivel 2 de madurez.
• Módulo 6 — Operación: monitorizaremos el servicio y el modelo, detectaremos deriva, automatizaremos el reentrenamiento con cabeza (recordando los bucles de realimentación de la lección 01-02) y cerraremos con gobernanza, documentación y el proyecto final integrador.

• Error: despreciar el notebook de Laura. El notebook demostró que el problema tiene solución con los datos disponibles — eso es la parte difícil e irreemplazable. MLOps no sustituye la exploración: la industrializa. Trata el código exploratorio con respeto y a su autora como aliada, no como culpable.
• Error: fiarse de la accuracy con clases desbalanceadas. Es el error de modelado más común en churn, fraude o detección de fallos. Antes de celebrar una métrica, pregúntate siempre: ¿qué obtendría un modelo trivial que predice siempre la clase mayoritaria?
• Error: "arreglar" el notebook añadiéndole celdas. La tentación es parchear: una celda que fija la semilla, otra que copia el CSV con fecha en el nombre... El notebook seguiría siendo un notebook, con su estado oculto y su ejecución fuera de orden. La solución del módulo 2 es estructural, no cosmética.
• Error: querer aplicar las once herramientas de la tabla la semana que viene. El stack se adopta en el orden del curso por una razón: cada pieza se apoya en la anterior (no puedes hacer CI de un pipeline que no existe). En tu trabajo real, sigue el mismo orden incremental.
• Consejo: guarda una copia de este notebook tal cual está. Al final del curso, compararlo con la plataforma final será la mejor medida de lo aprendido — y un ejercicio de humildad útil: casi todos tenemos un _final_v3_DEFINITIVO en algún cajón.

Sin ejecutar nada, razona numéricamente: el dataset tiene un 15% de clientes con abandono = 1. (1) ¿Qué accuracy obtendría un "modelo" que predice siempre abandono = 0? (2) ¿Cuántos de los clientes que van a abandonar detectaría ese modelo? (3) ¿Qué te dice esto sobre el 0.87 del notebook y sobre qué debería preguntarle el equipo de retención a Laura en lugar de "¿qué accuracy tiene?"?

Ejecutas el notebook de Laura dos veces seguidas, sin cambiar ni una línea ni el CSV, y obtienes accuracy 0.87 la primera vez y 0.86 la segunda. (1) Señala las dos líneas exactas del código responsables de esta variabilidad y explica el mecanismo de cada una. (2) Explica por qué esto es grave más allá de la molestia: ¿qué pregunta fundamental del trabajo experimental resulta imposible de responder?

Relaciona cada problema del diagnóstico con su remedio: para los problemas 3, 5, 6 y 9 de la tabla de diagnóstico, indica qué herramienta del stack (y qué módulo del curso) lo aborda principalmente, y escribe en una frase qué práctica (más allá de la herramienta) es la que realmente lo resuelve.

Solución 1:

1. Prediciendo siempre "no abandona" aciertas en todos los negativos (85%) y fallas en todos los positivos (15%): accuracy = 0.85.
2. Cero. Ese modelo no detecta ni un solo abandono: es perfectamente inútil para retención pese a su 0.85.
3. El 0.87 del notebook está solo dos puntos por encima del modelo trivial, así que la mayor parte de esa accuracy es "acertar lo fácil". Podría estar detectando muchos abandonos o casi ninguno: la accuracy no lo distingue. Retención debería preguntar: "de los clientes que realmente abandonan, ¿qué fracción detecta el modelo?" (recall de la clase positiva) y "de los que el modelo marca como riesgo, ¿cuántos abandonan de verdad?" (precision) — porque esas dos cifras determinan, respectivamente, cuántas bajas puede evitar la campaña y cuánto dinero se malgasta en falsos positivos.

Solución 2:

1. Las dos líneas: train_test_split(X, y, test_size=0.2) — sin random_state, cada ejecución baraja los datos con una semilla distinta, así que train y test contienen filas diferentes cada vez; y RandomForestClassifier(n_estimators=100) — sin random_state, el muestreo bootstrap de cada árbol y la selección aleatoria de features en cada división cambian entre ejecuciones, produciendo bosques distintos incluso con los mismos datos de entrenamiento.
2. Lo grave: resulta imposible responder a la pregunta "¿este cambio mejoró el modelo?". Si mañana Laura añade una feature nueva y la accuracy pasa de 0.86 a 0.875, no hay forma de saber si la mejora se debe a la feature o al mismo ruido aleatorio que ya produce oscilaciones de ±0.01 sin tocar nada. Sin reproducibilidad no hay experimentación válida: todo el proceso de mejora del modelo queda edificado sobre comparaciones sin valor.

Solución 3:

• Problema 3 (datos sin versionar) → DVC, módulo 2. La práctica real: cada dataset de entrenamiento queda inmutablemente identificado y enlazado a la versión del código que lo usó, de modo que cualquier modelo pasado pueda reconstruirse.
• Problema 5 (métrica única engañosa) → MLflow, módulo 3 (con las métricas correctas introducidas ya en el pipeline del módulo 2). La práctica real: definir antes de entrenar un conjunto de métricas alineado con el negocio y registrarlas todas en cada experimento, para comparar modelos sobre lo que importa.
• Problema 6 (sin tests) → GitHub Actions, módulo 5. La práctica real: codificar las expectativas sobre código, datos y modelo como comprobaciones automáticas que se ejecutan en cada cambio — el CI es solo el motor que las ejecuta.
• Problema 9 (preprocesado no reutilizable) → estructura de proyecto Python, módulo 2 (y su reutilización en el servicio, módulo 4). La práctica real: un único módulo de preprocesado, testeado y versionado, compartido por entrenamiento e inferencia, para que sea imposible por construcción que producción transforme los datos de otra manera.

Ya tenemos el punto de partida completo y sin maquillaje: un negocio con un problema real y cuantificable (el churn compone, y retener es mucho más barato que adquirir), un dataset ficticio pero verosímil con sus features numéricas y categóricas y su etiqueta desbalanceada, y un notebook monolítico que demuestra que hay señal en los datos pero que acumula diez problemas concretos —rutas personales, azar sin control, datos y modelo sin versionar, una accuracy que no dice lo que parece, cero tests y un proceso que vive en el portátil de una persona—. También tenemos el plan: un stack de herramientas (Git, DVC, MLflow, FastAPI, Docker, GitHub Actions, Prefect, Evidently) mapeado etapa a etapa sobre el ciclo de vida, y una hoja de ruta que recorre ese mapa módulo a módulo. Con esto cerramos los fundamentos. En el módulo 2 nos remangamos: tomaremos este notebook exactamente como está y lo convertiremos, paso a paso, en un proyecto Python estructurado y reproducible — la primera piedra, y la más importante, del camino de CineClick hacia la producción.