10 min de lectura
Seis meses después del despliegue, el equipo de retención empieza a notar que el modelo "ya no funciona igual". Las intervenciones semanales siguen saliendo, los clientes marcados como de alto riesgo siguen apareciendo en la cola de contacto, pero la tasa de recuperación bajó respecto del primer trimestre. Nadie puede señalar un momento donde algo se rompió. El modelo sigue devolviendo probabilidades, el proceso sigue ejecutándose, los dashboards siguen abiertos. La sensación es de erosión gradual.
Esa erosión es el estado natural de cualquier modelo en producción. Los supuestos sobre los que se entrenó son una fotografía del negocio en el momento del entrenamiento, y el negocio no deja de moverse. Los clientes cambian de comportamiento, aparecen productos nuevos, el canal de adquisición trae otro tipo de audiencia, el ciclo macroeconómico desplaza la propensión a comprar. El modelo no se entera. Sigue aplicando las reglas que aprendió, y la señal que producía al principio se va volviendo cada vez más ruidosa. Un protocolo de monitoreo acordado antes del despliegue es lo que convierte esa erosión en una señal accionable, en vez de en una queja difusa que llega cuando el daño ya está hecho.
La degradación es gradual, no colapso
Hay dos formas en que un modelo se aleja de la realidad que debería predecir. La primera es el data drift, que ocurre cuando cambia la distribución de las variables que el modelo usa como entrada. Si el modelo de propensión de recompra fue entrenado con una base donde el 60% de los clientes tenía más de 35 años y seis meses después esa proporción cayó al 40%, la entrada que el modelo ve en producción es distinta de la que vio en entrenamiento, aunque la variable objetivo todavía se comporte parecido. El modelo no detecta esta diferencia por sí mismo; simplemente aplica las mismas transformaciones sobre datos que ya no se parecen a los originales.
La segunda es el concept drift, que ocurre cuando cambia la relación entre las entradas y la salida que el modelo intenta predecir. La distribución de las variables de entrada puede seguir siendo la misma, pero el fenómeno subyacente se movió. Un cliente de 40 años con tres compras recientes seguía siendo buen candidato de recompra en el momento del entrenamiento; después de un cambio de catálogo, ese mismo perfil ya no se comporta así. Las entradas se ven iguales, el modelo las procesa de la misma forma, y las predicciones empiezan a ordenar mal los casos.
Las dos formas de drift conviven y se refuerzan. Rara vez un modelo se degrada por una sola causa limpia. Lo habitual es que la base de clientes evolucione (data drift), que el equipo de marketing cambie la mezcla de campañas (concept drift inducido por el cambio de proceso), y que ambos efectos se vayan acumulando sin que nadie los vincule a la caída de performance. La degradación es gradual porque los dos drifts avanzan en paralelo con velocidades distintas, y la señal del modelo se vuelve ruidosa antes de volverse directamente incorrecta.
Cómo se detecta: las métricas que importan
Detectar drift exige mirar dos cosas en paralelo. La primera es la distribución de las variables de entrada entre dos ventanas de tiempo, una de referencia (la de entrenamiento o una ventana reciente estable) y la actual. La métrica más usada para esto es el PSI, Population Stability Index, que mide cuánto se desplazó la distribución de una variable entre dos períodos. El PSI se calcula partiendo cada variable en bins y comparando la proporción de observaciones que cae en cada bin en las dos ventanas. Los umbrales de referencia son conocidos: por debajo de 0.1 la variable se considera estable, entre 0.1 y 0.25 queda en zona de vigilancia, por encima de 0.25 hay drift significativo que amerita revisión. El PSI se calcula variable por variable y también sobre la predicción agregada del modelo, lo que da dos vistas distintas de la misma pregunta.
Un valor de PSI por encima del umbral no es, por sí solo, una indicación de que el modelo haya perdido capacidad predictiva. Significa que la entrada se movió. Si la variable que se desplazó es poco importante para el modelo, la predicción puede seguir siendo útil. Si la variable es una de las que más pesa en la salida del modelo, la señal de drift es prioritaria. Por eso el PSI se mira junto con la importancia de cada variable, no en abstracto.
La segunda cosa a mirar es la performance real del modelo sobre datos recientes, en una ventana rolling. Esto incluye las métricas con las que el modelo se evaluó al principio (AUC, precisión en el top decil, lift sobre baseline, lo que corresponda al tipo de problema) calculadas sobre casos nuevos a medida que el feedback real llega. La trampa habitual es que ese feedback tarda. Un modelo de propensión de recompra a 90 días no sabe hasta pasados 90 días si acertó. Durante esa ventana ciega, el PSI y otras métricas de distribución son los únicos indicadores disponibles. La performance real llega después, confirma o descarta, y permite recalibrar.
Qué investigar antes de decidir reentrenar
La métrica dice que hay drift. La pregunta siguiente no es si reentrenar, sino qué está causando ese drift. Un valor de PSI de 0.3 en una variable crítica puede tener tres orígenes muy distintos, y cada uno pide una acción diferente.
El primer camino es revisar el pipeline de datos. Si una fuente que alimenta al modelo cambió su esquema, si un campo pasó a devolverse como null cuando antes tenía valor, si una integración empezó a cortar registros, el drift que ve el PSI no refleja ningún cambio real en el negocio: refleja un bug. Antes de considerar reentrenar hay que descartar que el input esté roto. Es el chequeo más barato y el que más rápido se cierra o se abre.
El segundo camino es interpretar el drift como señal del negocio. Si la distribución de edad de los clientes se desplazó porque el canal de adquisición cambió, si la propensión promedio cayó porque hay un competidor nuevo con una promoción agresiva, si el ticket medio se movió porque entró un segmento de producto distinto, el drift está detectando un fenómeno real que importa independientemente del modelo. Esa información tiene valor por sí misma: el monitoreo de un modelo bien instrumentado es también un mecanismo de detección temprana de cambios de patrón en el negocio, que de otro modo son difíciles de ver hasta que impactan en los números agregados meses después.
El tercer camino es reentrenar. Se justifica cuando los pipelines están sanos y el drift representa un cambio real del fenómeno que el modelo tiene que seguir prediciendo. Pero reentrenar es la acción más cara de las tres y no es siempre la correcta. Un drift que viene de un cambio operativo transitorio (una campaña de marketing que duró dos semanas) puede resolverse esperando. Un drift que viene de un cambio estructural (la base de clientes se desplazó de forma permanente) sí amerita rehacer el modelo.
Cuándo activar el reentrenamiento
Suponiendo que la investigación anterior descartó bugs y confirmó cambio estructural, la decisión de cuándo reentrenar se apoya en dos dimensiones.
La primera es técnica. ¿Qué tan rápido se está moviendo la señal predictiva? ¿La caída de performance se concentra en un segmento específico de clientes o es generalizada? ¿Las variables que driftearon son las que el modelo usaba con más peso, o son secundarias? Estas preguntas las responde el equipo técnico mirando los números y entendiendo qué parte del modelo quedó más expuesta. El criterio técnico define cuándo la degradación supera el umbral que justifica rehacer el modelo.
La segunda es operativa. Reentrenar un modelo no es gratis, incluso cuando el pipeline está automatizado. Hay tiempo de equipo para validar el modelo nuevo, hay un proceso de aprobación interna, hay sistemas conectados que consumen la predicción y que necesitan testearse contra la salida nueva, y hay una etapa de shadow mode: el modelo nuevo corre en paralelo al que está en producción sin tocar las decisiones, para que el equipo pueda comparar las predicciones de los dos contra el feedback real que va llegando. Solo cuando el nuevo demuestra mejor performance en esa comparación se promueve a producción y se retira el anterior. Ese proceso tiene una cadencia natural propia del equipo. Un equipo de retención que opera con una revisión mensual del modelo puede reentrenar sin fricción cuatro veces al año; un equipo que ejecuta campañas semanales con dependencia operativa fuerte de la predicción tiene una ventana más estrecha.
El reentrenamiento se dispara cuando las dos condiciones se alinean. El criterio técnico crea la necesidad (hay drift estructural suficiente para justificar el esfuerzo), y la realidad operativa define cuándo es viable moverse (hay capacidad del equipo y encaje con el ciclo de uso del modelo). Un protocolo de monitoreo útil declara estos dos umbrales antes del despliegue, para que la respuesta esté lista cuando el drift aparezca y no haya que improvisarla durante la primera crisis. Esta cadencia conversa con la frecuencia con la que el negocio consume la predicción, un tema que se desarrolla con más detalle en integracion-en-el-flujo-de-decision.
El protocolo se acuerda antes del despliegue
Las condiciones que determinan si un modelo llega a producción se desarrollan en detalle en proyectos-que-llegan-a-produccion. El monitoreo es una de esas condiciones. Un modelo que entra en producción sin un protocolo de monitoreo acordado entra con una deuda que se cobra después, cuando el equipo de negocio percibe que algo bajó, el equipo técnico empieza a mirar datos para entender qué, y la conversación sobre qué hacer ocurre bajo presión y sin referencia previa.
El protocolo que funciona declara cuatro cosas antes del día uno. Qué métricas se van a monitorear, con qué frecuencia, y sobre qué ventana rolling. Cuáles son los umbrales que disparan vigilancia y cuáles disparan acción. Quién mira las métricas y en qué cadencia conjunta se revisan entre negocio y técnica. Qué acción concreta sigue a cada umbral superado, desde "nada por ahora" hasta "reentrenar el próximo ciclo" pasando por "revisar la variable específica que driftea". Nada de esto se puede improvisar seis meses después.
Hay una consecuencia menos obvia de pensar el monitoreo antes del despliegue. El modelo que se entrena cuando ya se sabe cómo se va a vigilar es, otra vez, un modelo distinto. Si la cadencia acordada es revisar performance cada seis semanas con tolerancia alta al drift, el modelo puede ser más complejo y usar más variables. Si la cadencia es mensual con tolerancia baja y la restricción es que el modelo tiene que ser estable entre reentrenamientos, el diseño se mueve hacia variables más estables y una arquitectura menos sensible a cambios en la distribución de entrada. La vigilancia moldea cómo se construye el modelo desde el principio.
La proactividad no termina en el despliegue
Un modelo en producción con un protocolo de monitoreo diseñado antes del despliegue es un modelo con guardrails. La degradación sigue siendo inevitable: el mundo cambia, los datos se mueven, los supuestos envejecen. Lo que cambia es que ya no es una sorpresa que llega cuando el daño está hecho. La misma lógica proactiva que caracteriza la construcción de un modelo (probar hipótesis, validar antes de desplegar, cerrar alcance antes de arrancar) es la que corresponde aplicar después del deployment. Anticipar la erosión en vez de reaccionar a ella es lo que distingue un proyecto de Data Science que vive un año en producción de uno que se vuelve ruido operativo en el primer semestre.