El modelo de churn de MercaFresh ya está en producción: batch nocturno, API, Docker, despliegue gradual. Sería tentador dar el proyecto por terminado — y sería un error. Un modelo de machine learning es de los pocos componentes de software que se degradan sin que nadie toque el código: el modelo es una fotografía de los patrones del pasado, y el mundo que genera los datos sigue moviéndose. En esta lección aprenderás por qué ocurre (data drift y concept drift), cómo detectarlo con herramientas que ya conoces (histogramas, percentiles y tests estadísticos del módulo 2), qué monitorizar en un dashboard, y cómo organizar el reentrenamiento y el versionado para que el modelo siga siendo útil año tras año.

1. Por qué los modelos se degradan
2. Data drift: cambia lo que entra
3. Concept drift: cambia la relación con la respuesta
4. Detección de drift en las entradas
5. Monitorizar predicciones y métricas (con etiquetas que llegan tarde)
6. Dashboards y alertas: qué vigilar
7. Reentrenamiento: cuándo y cómo
8. Registro de modelos y versionado
9. El ciclo de vida completo en producción

Cuando entrenaste el modelo de churn, el módulo 6 insistió en una condición para que las métricas de test fueran creíbles: que los datos de producción se parezcan a los de entrenamiento. Esa condición se cumple el día del despliegue… y empieza a erosionarse al día siguiente. Las causas se agrupan en dos fenómenos con nombre propio:

La distinción importa porque se detectan y se tratan de forma distinta, como veremos. Y ambas comparten un rasgo peligroso: el servicio sigue funcionando. La API responde en milisegundos, el batch nocturno termina sin errores, las probabilidades tienen buena pinta… y son cada vez peores. Sin monitoreo específico, la degradación de un modelo es invisible hasta que el negocio la nota.

Data drift (también llamado covariate shift) es el caso más común: la población sobre la que predices deja de parecerse a la de entrenamiento.

Ejemplos concretos en MercaFresh:

• Expansión a una ciudad nueva: el modelo se entrenó con clientes de cinco ciudades; ahora el 15 % de las peticiones llega de Zaragoza, una categoría que el codificador del pipeline ni siquiera conocía. La distribución de antiguedad_meses se desploma (todos son clientes nuevos).
• Cambio de hábitos: tras lanzar la suscripción mensual, la distribución de frecuencia_90d se desplaza hacia arriba y la de recencia_dias hacia abajo. El modelo ve valores en zonas donde tuvo pocos ejemplos para aprender.
• Cambios técnicos aguas arriba: alguien modifica el sistema origen y gasto_medio pasa de euros a céntimos. Drift brutal e instantáneo — y sorprendentemente frecuente: muchas "degradaciones del modelo" son en realidad bugs de datos.

El modelo no falla de golpe: simplemente extrapola cada vez más lejos de lo que conoció, y su fiabilidad cae de forma gradual y silenciosa.

En el concept drift, las entradas pueden tener el mismo aspecto de siempre, pero lo que significan para la respuesta ha cambiado: la función que el modelo aprendió ya no es la que rige el mundo.

Ejemplos en MercaFresh:

• Una campaña cambia quién abandona: retención contacta sistemáticamente a los clientes de alto riesgo (¡usando nuestro modelo!) y muchos se quedan. Ahora un perfil que históricamente significaba "abandono casi seguro" ya no lo es. Nótese la ironía: el éxito del modelo altera la realidad que el modelo describía — los sistemas de ML que actúan sobre el mundo generan este bucle de forma natural.
• Un competidor nuevo con envío gratis: clientes de perfil "fiel" (alta frecuencia, baja recencia) empiezan a irse. Las X no han cambiado; el significado de las X sí.
• Estacionalidad: el patrón de compra navideño no implica lo mismo en enero. Si el entrenamiento no cubrió ciclos anuales completos, cada estación nueva es un pequeño concept drift.

El concept drift es más difícil de detectar que el data drift, porque no basta con mirar las entradas: hace falta comparar predicciones con resultados reales — y estos llegan tarde, como veremos.

La buena noticia: para detectar data drift no necesitas etiquetas, solo comparar la distribución actual de cada variable con la de referencia (los datos de entrenamiento). Y las herramientas son las del módulo 2.

Nivel 1 — Estadísticos descriptivos y percentiles (02-01): guarda, junto al modelo, media, desviación y percentiles (p5, p25, p50, p75, p95) de cada variable en entrenamiento. Cada noche, calcula los mismos números sobre los datos del scoring y compara. Es simple, barato y detecta los casos gruesos (el bug de euros/céntimos salta a la vista en la mediana).

Nivel 2 — Tests estadísticos (02-04): para detectar desplazamientos más finos, formaliza la comparación como un test de hipótesis: H0 = "ambas muestras vienen de la misma distribución".

• Variables numéricas → test de Kolmogorov-Smirnov (compara las distribuciones acumuladas completas).
• Variables categóricas → test chi-cuadrado sobre las frecuencias de cada categoría.

Dos matices de uso profesional:

• Con muestras grandes, todo sale "significativo" (lo viste en 02-04: con n enorme, diferencias triviales dan p-valores minúsculos). Por eso en monitoreo se mira también el tamaño del efecto — el estadístico KS (proporción máxima de separación entre distribuciones) más que su p-valor, con umbrales prácticos acordados (p. ej. investigar si KS > 0,1).
• El test señala que hay cambio, no si importa. Un drift grande en una variable de poca importancia para el modelo es menos urgente que uno moderado en la variable principal. Cruzar el drift con la importancia de variables (07-03) prioriza las alertas.

Mirar las entradas no basta; hay que mirar también lo que sale del modelo, en dos niveles según lo que esté disponible:

Nivel A — La distribución de las predicciones (disponible siempre, al instante). Guarda cada noche el histograma y los percentiles de prob_churn sobre toda la base de clientes. Si la probabilidad media de churn pasa de 0,18 a 0,31 en dos semanas, o el porcentaje de clientes sobre el umbral de acción se duplica, algo ha cambiado — en los datos, en el mundo o en el propio pipeline — y hay que investigar antes de saber si las predicciones aciertan. Este es el canario en la mina: barato y sin retardo.

Nivel B — Las métricas reales (disponibles con retraso). Aquí aparece la dificultad específica del churn: la etiqueta verdadera tarda meses en conocerse. Si defines churn como "sin compras en 90 días", la predicción que haces hoy solo puede evaluarse dentro de 90 días. Consecuencias prácticas:

• Organiza la evaluación por cohortes: "los scores emitidos en mayo" se evalúan en agosto, cuando sus etiquetas maduran, calculando precision, recall, AUC y la matriz de confusión de 06-02 sobre esa cohorte.
• Grafica cada métrica por cohorte a lo largo del tiempo: una pendiente descendente sostenida es la firma de la degradación (y, si las entradas no muestran drift, apunta a concept drift).
• Cuidado con el sesgo de intervención: si retención actúa sobre los clientes señalados, sus etiquetas ya no reflejan lo que habría pasado sin actuar. Mantener un pequeño grupo de control sin contactar (como en el A/B de 08-02) mantiene la evaluación honesta.

El monitoreo completo combina ambos niveles: el A da alarmas tempranas sin confirmación; el B da la verdad, con meses de retraso.

Todo lo anterior se materializa en un dashboard que cualquiera del equipo pueda leer, con alertas automáticas cuando algo cruza un umbral. Qué debe contener, en dos bloques:

Dos principios de diseño:

• Cada alerta debe tener un dueño y una acción. Una alerta que nadie atiende entrena al equipo a ignorar alertas. Pocas, bien calibradas, accionables.
• El dashboard de negocio manda. El modelo puede tener un AUC estable y estar fallando al negocio (o viceversa). El objetivo nunca fue el AUC: era retener clientes con un presupuesto (06-04).

Detectado el deterioro (o antes de que llegue), la respuesta natural es reentrenar con datos recientes. Las dos preguntas clave:

¿Cuándo reentrenar? Dos estrategias, no excluyentes:

En la práctica, la combinación es lo habitual: un reentrenamiento trimestral programado, más la posibilidad de adelantarlo si las alertas lo justifican. Para MercaFresh: reentrenamiento trimestral del modelo de churn, adelantable ante eventos como la apertura de una ciudad.

¿Cómo reentrenar? No es "ejecutar fit otra vez y a correr":

1. Ventana de datos: decide con qué historia entrenar. ¿Todo el histórico (más datos, pero arrastra patrones viejos) o una ventana móvil de los últimos 18–24 meses (más fresco, menos volumen)? Con concept drift confirmado, la ventana reciente suele ganar; puede compararse empíricamente.
2. Mismo rigor que el original: el reentrenamiento repite el proceso completo de los módulos 6 y 7 — división temporal correcta, CV, búsqueda de hiperparámetros sobre el pipeline— de forma automatizada (un script o pipeline de entrenamiento, no un notebook a mano).
3. Validación antes de reemplazar: el candidato debe superar al modelo en producción sobre un conjunto de evaluación común y reciente que ninguno vio en entrenamiento. Si no lo supera, no se despliega — reentrenar no garantiza mejorar.
4. Despliegue gradual y rollback: el candidato aprobado entra por el mismo camino que viste en 08-02 (sombra → A/B → rollout), con la versión anterior lista para volver. El reentrenamiento no es un evento especial: es otro despliegue.

Con reentrenamientos periódicos, en un año tendrás v3, v4, v5… y preguntas como "¿qué modelo generó los scores del 12 de marzo?" o "¿con qué datos se entrenó el que falló?". Responderlas exige disciplina de registro. Para cada versión, guarda como mínimo:

• El artefacto (pipeline serializado) y su suma de verificación.
• Datos: ventana temporal y consulta/snapshot con que se entrenó.
• Código y entorno: commit del repositorio y requirements.txt exacto.
• Métricas de validación y comparación con la versión anterior.
• Historial de despliegue: cuándo entró en producción, cuándo salió, por qué.

Esto puede empezar siendo una convención de carpetas y un fichero de metadatos (como en 08-02). Cuando el volumen crece, se usa un registro de modelos dedicado: herramientas como MLflow ofrecen exactamente esto — seguimiento de experimentos (parámetros y métricas de cada entrenamiento), un registro central de modelos con etapas (staging/producción/archivado) y trazabilidad entre datos, código y artefacto. Conceptualmente no añade nada que no hayas visto: sistematiza la disciplina de esta sección para que no dependa de la memoria de nadie. No lo desarrollamos aquí; su documentación es accesible con lo que ya sabes.

El diagrama que resume el módulo hasta ahora — y explica por qué a esta práctica se la llama a veces MLOps: tratar el ciclo entero como un proceso de ingeniería continuo, no como un proyecto con final.

Obsérvese que es un ciclo, no una línea: el estado normal de un modelo útil es estar dando vueltas por este grafo durante años.

• "Desplegado = terminado". El error de mentalidad del que nacen todos los demás: sin monitoreo, la primera noticia de la degradación te la dará el negocio, meses tarde.
• Monitorizar solo el servicio (latencia, errores) y no el modelo. Una API sana al 100 % puede estar sirviendo predicciones cada vez peores. Son dos monitoreos distintos y hacen falta ambos.
• Fiarse del p-valor con muestras enormes. Con cien mil filas, un KS con p < 0,001 puede reflejar una diferencia irrelevante. Mira el tamaño del efecto y fija umbrales prácticos.
• Olvidar el retardo de las etiquetas. Evaluar "el recall de esta semana" con etiquetas de churn inmaduras infraestima el churn real y da una falsa sensación de acierto. Evalúa por cohortes maduras.
• Reentrenar y desplegar sin validar contra el modelo actual. Reentrenar con datos con drift no garantiza un modelo mejor; sin la comparación previa, puedes reemplazar un modelo mediocre por uno peor.
• Ignorar el efecto de las propias intervenciones. Si actúas sobre los clientes que el modelo señala, las etiquetas posteriores están contaminadas por tu intervención; sin grupo de control, el modelo parecerá "equivocarse" justo cuando funciona.
• Consejo: guarda desde el primer día un snapshot de referencia (datos de entrenamiento con sus estadísticos) junto al artefacto. Sin referencia no hay comparación, y reconstruirla meses después suele ser imposible.

Ejercicio 1. Clasifica cada situación como data drift, concept drift o bug de datos, y justifica: (a) tras integrar un proveedor logístico nuevo, incidencias_entrega pasa a llegar casi siempre a 0 porque el proveedor no reporta incidencias; (b) MercaFresh lanza una tarjeta de fidelización con envío gratis y, con los mismos perfiles RFM de siempre, la tasa real de churn de los clientes de alta frecuencia cae a la mitad; (c) una campaña de captación en redes trae una oleada de clientes jóvenes con cestas pequeñas, un segmento minoritario en el entrenamiento.

Ejercicio 2. El monitoreo nocturno de MercaFresh aplica KS a gasto_medio con los datos de referencia (n = 80.000) frente a los del día (n = 75.000) y obtiene KS = 0,012 con p = 0,00004. El responsable propone reentrenar de inmediato. ¿Qué le dirías?

Ejercicio 3. Diseña en 5-7 líneas el plan de evaluación continua del modelo de churn sabiendo que la etiqueta se define como "sin compras en 90 días": qué se monitoriza cada día, qué se calcula cada mes, y qué papel juega el grupo de control.

Solución 1. (a) Bug de datos (aunque se manifieste como drift): la variable no ha cambiado en el mundo, ha dejado de medirse bien. La acción es corregir la integración aguas arriba, no reentrenar — reentrenar aprendería que "0 incidencias" no significa nada. (b) Concept drift: P(X) apenas cambia (mismos perfiles RFM), pero la relación X→y sí — el mismo perfil ahora abandona menos. Solo se detectará en las métricas por cohorte, no en los tests sobre las entradas. (c) Data drift: cambia la composición de la población de entrada (P(X)); la relación perfil→churn puede seguir siendo la misma, pero el modelo predice ahora a menudo en una zona donde tuvo pocos ejemplos. Vigilar métricas de ese segmento y valorar reentrenar incluyéndolo mejor representado.

Solución 2. Que distinga significancia de relevancia (02-04): con n ≈ 80.000 por muestra, el test KS detecta como "significativa" cualquier diferencia minúscula; el tamaño del efecto es KS = 0,012 — las distribuciones acumuladas se separan como máximo un 1,2 %, un cambio casi con seguridad irrelevante para el modelo. Antes de reentrenar: comparar percentiles para ver dónde está la diferencia, revisar si la variable es importante para el modelo y comprobar el resto de indicadores (distribución de predicciones, métricas de cohortes). Reentrenar por un p-valor con efecto despreciable es coste y riesgo sin beneficio.

Solución 3. Plan tipo: Diario — estadísticos y KS/chi² de cada variable frente a la referencia; distribución de prob_churn (media y percentiles) y % de clientes sobre el umbral; salud del batch y de la API. Mensual — se "cierra" la cohorte de scores emitida hace 90 días (sus etiquetas ya han madurado) y se calculan precision, recall y AUC de esa cohorte, añadiéndolas a la serie temporal de métricas para ver tendencia. Grupo de control — una fracción aleatoria pequeña de clientes en riesgo no se contacta; sus etiquetas permiten medir el churn "sin intervención", de modo que la evaluación del modelo no quede distorsionada por el éxito de las campañas, y de paso mide el beneficio causal real de la retención frente al control.

Ya sabes por qué un modelo perfecto el día del despliegue deja de serlo: el data drift mueve las entradas (la ciudad nueva, los hábitos que cambian) y el concept drift reescribe la relación con la respuesta (la campaña que cambia quién abandona). Y sabes vigilarlo con un sistema en capas: estadísticos y tests KS/chi-cuadrado sobre las entradas cada noche, la distribución de predicciones como canario, las métricas reales por cohortes cuando las etiquetas maduran, y un dashboard donde negocio y técnica se leen juntos — todo alimentando un ciclo de reentrenamiento validado, versionado y con rollback, que convierte el modelo en un sistema vivo. Queda una dimensión que ningún dashboard mide sola: el modelo de churn decide a qué personas se contacta, con qué ofertas y usando qué datos — y eso plantea preguntas de sesgo, equidad, transparencia y privacidad. A ellas dedicamos la última lección del módulo: las consideraciones éticas de poner machine learning delante de personas reales.