Qué hago si mi modelo de ML sufre deriva de datos en producción?
#1
Llevo unos meses trabajando en un proyecto donde aplicamos modelos de aprendizaje automático a datos de sensores industriales, y me ha surgido una duda práctica. Aunque la precisión de los modelos es buena en validación cruzada, cuando llegan a producción su rendimiento parece degradarse sutilmente con el tiempo, sin que haya un cambio claro en los datos de entrada. He estado leyendo sobre el concepto de deriva de datos, pero no termino de entender cómo diagnosticar si eso es lo que está pasando en nuestro caso o si el problema es otra cosa. Me da la impresión de que nuestros pipelines de monitoreo no están captando algo.
Responder
#2
Cuando oigo deriva de datos me imagino un cambio gradual en la relación entre entradas y salidas que no se ve en la validación pero aparece en producción. En tu caso conviene comparar la distribución de cada feature entre el conjunto de entrenamiento y lo que llega en producción y mirar si hay drift ya sea en entrada o en el objetivo. Es útil ver si la métrica de rendimiento se deteriora de forma progresiva y si ese deterioro coincide con cambios sutiles en sensores o en la calibración.
Responder
#3
Me late que eso de la deriva de datos suena frustrante pero real. A veces los sensores envejecen o cambian las condiciones de operación sin que el dataset cambie mucho y el modelo se queda corto. Si la validación era buena pero la producción es distinta, podría ser porque el entorno de producción introduce sesgos que no estaban en el entrenamiento.
Responder
#4
Tal vez no sea deriva de datos sino un fallo en el pipeline de monitorización o en la calibración de sensores. ¿Y si el problema es la forma en que se actualizan los modelos o la latencia para retrain?
Responder
#5
Si el objetivo es entender cuándo aparece la degradación empieza por definir qué significa que funcione bien en producción y qué punto evitar. En lugar de mirar solo la precisión pregunta qué decisiones se apoyan en el modelo. Qué pasaría si cambias el foco hacia la detección de anomalías o la confiabilidad del sistema?
Responder
#6
Prueba un drift simple observa la distribución de cada feature entre entrenamiento y producción con la prueba KS para cada variable y mira si alguna se desborda. También vigila la dispersión de errores a lo largo del tiempo y revisa si hay sesgo de concepto.
Responder
#7
Pensarlo desde ML Ops ayuda. Un monitoreo sólido incorpora drift de datos control de calidad de datos y reglas para retrain. Versionado de datos y pipelines reproducibles facilitan entender si la deriva de datos es la causa.
Responder


[-]
Respuesta rápida
Mensaje
Escribe tu respuesta a este mensaje aquí.

Verificación de la imagen
Escribe el texto que aparece en la imagen, en el campo que está abajo. Este proceso se usa para evitar mensajes automáticos.
Verificación de la imagen
(no distingue MAYÚSC/minúsc)

Salto de foro: