Detectando drift de modelos ML antes de llegar a producción

El drift de modelos ML no es un fenómeno único — es una familia de patrones de degradación relacionados que se acumulan silenciosamente. Comprender la taxonomía es el prerrequisito para construir una detección que realmente funcione. Hay tres tipos primarios de drift: drift de features (también llamado drift de datos o cambio de covariables), drift de concepto (la relación entre features y etiquetas cambia), y drift de sesgo (errores sistemáticos en los outputs del modelo que se acumulan con el tiempo). El drift de features es el más común y el más detectable. La distribución de las features de entrada cambia después del entrenamiento. Si tu modelo de fraude fue entrenado con patrones de transacciones pre-pandemia, las distribuciones de features de las transacciones de 2025 pueden haber derivado lo suficiente como para invalidar las importancias de features aprendidas por el modelo.

El drift de concepto es más difícil de detectar porque requiere datos de producción etiquetados — que llegan lentamente o no llegan para muchas aplicaciones de ML. Un modelo de predicción de churn entrenado en Q1 puede encontrar una relación fundamentalmente diferente entre patrones de uso y churn en Q3 si se lanzó un producto competitivo a mediados de año. El drift de sesgo se acumula desde bucles de retroalimentación. Un modelo de recomendación que sobre-recomienda ligeramente una categoría hará que los usuarios interactúen más con esa categoría, lo que sesga el siguiente dataset de entrenamiento hacia esa categoría, amplificando el sesgo original. Cada ciclo de re-entrenamiento aprieta el bucle de retroalimentación.

El ML Reliability Score (MRS) proporciona una señal de salud compuesta que agrega estas señales de drift en una única métrica accionable. La fórmula pondera el drift de features (40%), la confianza de predicción (30%), la estabilidad de distribución de outputs (20%) y la frescura de datos (10%). Un MRS por encima de 0.90 es saludable; 0.75-0.90 justifica investigación; por debajo de 0.75 dispara una revisión automática del modelo. La detección de drift basada en z-score computa distancias estadísticas entre las distribuciones actuales de features y los baselines rolling. Para cada feature, calculamos el z-score de la media actual contra la distribución de medias de las últimas N=5 ejecuciones del pipeline. Un z-score por encima de 3.0 en cualquier feature dispara una alerta de drift.

La implementación práctica requiere tres componentes de infraestructura: un almacén de baselines (DynamoDB con retención basada en TTL funciona bien para baselines de ventana rolling), una capa de cómputo de drift (integrada en el paso de validación del pipeline Gold), y una ruta de alertas (circuit breakers de SENTINEL que retienen los refreshes del modelo cuando el MRS cae por debajo del umbral). El patrón de circuit breaker es crítico. Cuando se detecta drift, tienes dos opciones: re-entrenar inmediatamente (costoso, lento) o mantener el modelo en modo seguro (servir la versión anterior, alertar al equipo, recopilar datos etiquetados adicionales). El circuit breaker implementa la ruta de retención y alerta automáticamente. Resultados observados en despliegues en producción: la detección de drift con baselines de z-score detecta cambios distribucionales un promedio de 11 días antes de que aparezcan en métricas de negocio.