Que cambie la distribución de una variable no demuestra que el modelo haya dejado de ser útil. Y que la precisión histórica sea buena no demuestra que siga funcionando hoy. Drift es una señal para investigar; la decisión de reentrenar necesita relacionarla con rendimiento, impacto y capacidad de actuar.
Separa tres fenómenos
- Drift de entrada: cambia la distribución de variables que recibe el modelo. Puede deberse a estacionalidad, una campaña o un error de captura.
- Cambio de relación: la conexión entre entradas y objetivo evoluciona. Las mismas señales dejan de predecir igual.
- Degradación observada: una métrica relevante empeora cuando llegan etiquetas fiables.
Google Cloud Model Monitoring distingue comparación entre datos de entrenamiento y producción, y comparación de la distribución de producción a lo largo del tiempo. Para interpretar esas comparaciones se necesita un esquema estable: si cambia el tipo, orden o significado de una variable, primero hay un problema de contrato.
Diseña una ficha por señal
Para cada variable vigilada documenta:
| Campo | Ejemplo |
|---|---|
| Referencia | últimas 12 semanas de entrenamiento aceptado |
| Ventana actual | 7 días, mínimo 10.000 predicciones |
| Segmentos | canal, país y tipo de cliente |
| Métrica | distancia o divergencia definida por tipo de dato |
| Umbral | aviso y crítico calibrados con variación histórica |
| Propietario | equipo de riesgo comercial |
| Respuesta | validar fuente, rendimiento e impacto |
Una alerta global puede ocultar que solo falla un segmento pequeño pero importante. Al mismo tiempo, demasiados cortes generan ruido. Prioriza segmentos ligados a decisiones, obligaciones o volumen suficiente.
Qué hacer ante una alerta
- Validar el dato. Comprueba nulos, categorías nuevas, unidades y versión del pipeline. Un cambio de euros a céntimos no se arregla reentrenando.
- Buscar una causa esperada. Estacionalidad o una campaña pueden cambiar entradas sin dañar el modelo.
- Medir rendimiento con etiquetas. Cuando estén disponibles, compara precisión, recall, calibración o coste por segmento con la línea base.
- Evaluar impacto operativo. Observa cuántas decisiones cambian y si la revisión humana puede absorberlas.
- Elegir respuesta. Corregir datos, ajustar umbral, limitar uso, recalibrar o reentrenar.
La validación temporal debe repetirse con una ventana que represente el nuevo entorno. Reentrenar automáticamente al superar un umbral puede incorporar etiquetas defectuosas o normalizar una incidencia.
Criterios para reentrenar
El reentrenamiento está justificado cuando existe una muestra suficiente y fiable, la degradación supera un límite acordado, el nuevo entrenamiento mejora en un conjunto temporal independiente y el cambio no empeora segmentos protegidos o críticos. Define además:
- versión de datos, código y parámetros;
- comparación con el modelo vigente;
- prueba de calibración y capacidad;
- aprobación y estrategia de despliegue gradual;
- criterio de rollback.
Si todavía no hay etiquetas, el drift puede activar mayor muestreo, revisión manual o una limitación temporal. No debería autorizar por sí solo un reemplazo irreversible.
Observabilidad después del cambio
Tras desplegar, compara ambos modelos durante una ventana controlada. Vigila distribución de scores, decisiones, latencia, errores y métricas de negocio. Conserva el modelo anterior recuperable. Comprueba además que no haya data leakage en el nuevo conjunto: una mejora aparente puede venir de información que no existirá al inferir.
Un sistema maduro trata el drift como una hipótesis con contexto. La alerta abre una investigación; la evidencia decide si corregir el dato, ajustar la operación o reentrenar.