Entrenaste tu modelo con el dataset RflyMAD y funciona perfecto. Lo instalas en un dron de carga agrícola y es un desastre. ¿Qué ha pasado?
En el artículo anterior solucionamos el «sesgo de protocolo»: limpiamos nuestros datos para que el modelo aprendiera la física del fallo y no el horario del laboratorio. Ahora tienes un modelo robusto, entrenado con los miles de ejemplos del dataset RflyMAD (basado en multicópteros específicos). Tu precisión es estelar en el entorno de pruebas.
Lleno de confianza, decides desplegar ese mismo algoritmo de detección de fallos en una flota nueva: drones de agricultura (hexacópteros), mucho más grandes, pesados y con hélices de diferente paso.
Resulta que el modelo no solo falla, sino que «alucina». Detecta averías donde no las hay o ignora vibraciones catastróficas. La física no ha cambiado (la gravedad es la misma), pero tus datos sí. Te enfrentas a los dos jinetes del apocalipsis en MLOps: Data Drift y Concept Drift.
1. Data Drift: El cambio en la «voz» de los sensores
El Data Drift (o Covariate Shift) ocurre cuando cambia la distribución estadística de tus variables de entrada (X), aunque la relación lógica con la salida (y) se mantenga.
El dataset RflyMAD contiene datos de drones con características mecánicas muy concretas (peso, inercia, KV de los motores).
- Entrenamiento (RflyMAD): Datos generados por un cuadricóptero ágil. Vibraciones de alta frecuencia, respuestas rápidas, chasis rígido.
- Despliegue (Nuevo Dron Agrícola): Hexacóptero pesado. Motores lentos con mucho torque, chasis flexible que absorbe ciertas frecuencias, inercia enorme.
Aunque ambos usen el mismo modelo de acelerómetro (IMU), la «música» que escucha el modelo ha cambiado. En los datos de RflyMAD, una vibración de 50Hz podría ser ruido de fondo normal. En tu nuevo dron gigante, esa misma vibración de 50Hz podría ser la resonancia estructural previa a que una hélice se desintegre.
El modelo recibe inputs que están fuera de su «zona de confort» estadística. No sabe interpretarlos porque nunca vio esa distribución de energía en el dataset original.
2. Concept Drift: Cuando las reglas del juego cambian
El Concept Drift es más peligroso. Aquí, la distribución de entrada puede parecerse, pero el significado ha cambiado. La relación entre X (sensores) e y (fallo) ya no es la misma.
Supongamos que el dataset RflyMAD se grabó mayoritariamente en interiores o condiciones controladas (viento nulo o constante). El modelo aprendió:
«Si el dron se inclina bruscamente sin orden del mando, es un Fallo de Motor.»
Ahora vuelas tu nuevo dron en exteriores, en un día de viento racheado.
- Situación: Una ráfaga de viento golpea el dron.
- Reacción: El dron se inclina y los motores compensan agresivamente para mantener la posición.
- Predicción del Modelo: «¡Fallo de Motor Detectado!»
El modelo no está «equivocado» bajo las reglas que aprendió en RflyMAD, pero el concepto de «inclinación brusca» ha cambiado debido al entorno. En el laboratorio significaba fallo; en el campo de cultivo, significa clima. La realidad operativa ha cambiado y el modelo ha quedado obsoleto.
Estrategia de Monitorización: ¿Cómo saber si tu modelo está «mareado»?
No puedes esperar a que el dron se estrelle para saber que tu modelo está sufriendo drift. Necesitas métricas de vigilancia en tiempo real:
A. Para detectar Data Drift (Vigilando la entrada)
Comparas estadísticamente los datos que entran en vivo contra los datos del dataset RflyMAD (tu baseline).
- Prueba Kolmogorov-Smirnov (K-S Test): Es una prueba estadística ideal para verificar si, por ejemplo, la distribución de la señal del acelerómetro en el eje Z ha cambiado significativamente respecto al entrenamiento.
- Detección de Anomalías con Autoencoders: Puedes entrenar una red neuronal simple que aprenda a «comprimir y descomprimir» los datos de RflyMAD. Si le pasas datos del nuevo dron y el error de reconstrucción es alto, significa que la nueva señal tiene características estructurales que el modelo no reconoce.
B. Para detectar Concept Drift (Vigilando la salida)
Esto es más difícil sin etiquetas reales (no sabes si está fallando de verdad hasta que cae), pero hay indicadores:
- Caída en la Confianza (Confidence Drop): Si tu red neuronal solía predecir fallos o estados normales con una probabilidad del 99% y ahora, con el nuevo dron, sus predicciones rondan el 60-70% de certeza constantemente, es una señal de alerta. El modelo está «dudando» porque los patrones son ambiguos para él.
Reacción: Adaptarse o Morir
Si tus monitores saltan en rojo al cambiar de tipo de dron, ¿qué haces? No siempre es necesario grabar un dataset masivo nuevo tipo RflyMAD.
1. Transfer Learning (La opción pragmática)
Toma tu modelo pre-entrenado con RflyMAD (que ya sabe detectar patrones básicos de fallos en rotores).
- Congela las primeras capas de la red (las que detectan características universales como picos, ruido o cambios de tendencia).
- Re-entrena solo las últimas capas con un conjunto de datos pequeño recolectado con el nuevo dron.
Esto permite al modelo «recalibrar» sus umbrales para la nueva física (la nueva inercia, las nuevas frecuencias) sin tener que aprender desde cero qué es una vibración.
2. Calibración de Dominio
A veces, el problema es simplemente de escala. Si los motores del nuevo dron vibran el doble de fuerte en estado normal que los del dataset original, quizás solo necesites una normalización adaptativa que escale los datos de entrada al rango que el modelo espera.
Conclusión
El hardware cambia. Los sensores se degradan. Un modelo de Ciencia de Datos estático en un mundo físico dinámico es un riesgo de seguridad.
El éxito no es lograr un 99% de accuracy en el dataset RflyMAD. El éxito es construir un sistema MLOps que sepa cuándo ya no sabe, detectando la deriva entre el dataset de origen y la realidad del nuevo dron, y teniendo la flexibilidad para adaptarse mediante re-entrenamientos rápidos.