Monitorización de un modelo desplegado para detectar deriva: entradas, salidas y etiquetas tardías

Objetivo

Detectar, antes de que lo hagan los usuarios, que un modelo desplegado ha dejado de comportarse como prometía su puntuación en el conjunto de prueba, y distinguir entre tres causas: han cambiado las entradas, el pipeline de servicio calcula las características de forma distinta a como se hizo en el entrenamiento, o ha cambiado el mundo y las mismas entradas ahora corresponden a resultados distintos.

Requisitos previos

Una muestra de referencia de las características y predicciones del entrenamiento, almacenada junto con la versión del modelo; un código de servicio que registre, por cada predicción, la versión del modelo, el vector de características tal como se sirvió, la salida y un identificador de la petición; y un canal por el que los resultados reales lleguen más tarde con ese mismo identificador.

Pasos

1. Registra las características exactamente como las vio el modelo en el momento del servicio. Las Rules of Machine Learning de Google definen el training-serving skew (sesgo entre entrenamiento y servicio) como una diferencia entre el rendimiento durante el entrenamiento y durante el servicio, citan como causas las discrepancias en el pipeline y los cambios en los datos, y recomiendan guardar el conjunto de características usado en el servicio y enviarlo a un log para el entrenamiento, de modo que se pueda verificar la coherencia entre servicio y entrenamiento.
2. Compara, por característica y por ventana de tiempo, la distribución servida con la referencia de entrenamiento: en las características numéricas, con una prueba de dos muestras como la de Kolmogorov-Smirnov (scipy.stats.ks_2samp compara las distribuciones continuas subyacentes de dos muestras independientes) o con una distancia entre histogramas agrupados en intervalos; en las categóricas, con la frecuencia de cada valor y la proporción de valores no vistos.
3. Compara del mismo modo la distribución de las predicciones (histograma de puntuaciones, tasa de positivos) con la referencia; si cambia mientras las entradas no lo hacen, el problema apunta al pipeline de servicio.
4. Cuando lleguen las etiquetas, únelas por el identificador de la petición y calcula la métrica offline sobre la ventana que cubren; represéntala junto a las señales de deriva de las entradas, teniendo en cuenta el retraso conocido.
5. Genera alertas ante cambios sostenidos, no ante una única ventana, y guarda en la configuración, junto con la versión del modelo, los umbrales de cada característica.
6. Ante un cambio confirmado, decide entre reentrenar con datos recientes, corregir la discrepancia del pipeline o hacer un rollback; registra la decisión junto con las pruebas.

Resultado esperado

Un panel por versión del modelo con la deriva de las características, la deriva de las predicciones y el rendimiento real con retraso; el sesgo causado por diferencias en el pipeline queda separado del cambio genuino en los datos.

Límites y base de verificación

Las pruebas de distribución sobre ventanas grandes señalan cambios diminutos e inocuos; el umbral es una decisión de criterio para cada característica. La deriva en las entradas no demuestra una caída del rendimiento, y el rendimiento puede caer sin que se vea deriva en las entradas. El retraso de las etiquetas limita la rapidez con que se puede confirmar una degradación real. No se afirma ninguna tasa de detección.