Surveiller la dérive d'un modèle déployé : entrées, sorties et étiquettes différées

Objectif

Détecter, avant les utilisateurs, qu'un modèle déployé a cessé de se comporter comme son score de test le promettait, et distinguer les trois causes possibles : les entrées ont changé, le pipeline de service calcule les caractéristiques différemment de l'entraînement, ou le monde a changé de sorte que les mêmes entrées produisent désormais des résultats différents.

Prérequis

Un échantillon de référence des caractéristiques et prédictions d'entraînement, stocké avec la version du modèle ; un code de service qui journalise, pour chaque prédiction, la version du modèle, le vecteur de caractéristiques tel que servi, la sortie et un identifiant de requête ; et un circuit par lequel les résultats réels arrivent plus tard avec le même identifiant.

Étapes

1. Journaliser les caractéristiques exactement telles que le modèle les a vues au moment du service. Les Rules of Machine Learning de Google définissent l'écart entraînement-service (training-serving skew) comme une différence de performance entre l'entraînement et le service, désignent les écarts de pipeline et les changements de données comme causes, et recommandent de sauvegarder l'ensemble des caractéristiques utilisées au moment du service et de les acheminer vers un journal destiné à l'entraînement, afin de pouvoir vérifier la cohérence entre le service et l'entraînement.
2. Comparer, par caractéristique et par fenêtre temporelle, la distribution servie à la référence d'entraînement : pour les caractéristiques numériques, un test à deux échantillons tel que le test de Kolmogorov-Smirnov (scipy.stats.ks_2samp compare les distributions continues sous-jacentes de deux échantillons indépendants) ou une distance entre histogrammes discrétisés ; pour les caractéristiques catégorielles, la fréquence de chaque valeur et la part de valeurs jamais vues.
3. Comparer de la même manière la distribution des prédictions (histogramme des scores, taux de positifs) à la référence ; un déplacement ici alors que les entrées sont inchangées pointe vers le pipeline de service.
4. Lorsque les étiquettes arrivent, les réconcilier par identifiant de requête et calculer la métrique hors ligne sur la fenêtre que ces étiquettes couvrent ; la représenter à côté des signaux de dérive des entrées, avec le décalage connu.
5. Alerter sur des déplacements soutenus, pas sur une seule fenêtre, et conserver les seuils par caractéristique dans une configuration liée à la version du modèle.
6. En cas de déplacement confirmé, choisir entre un réentraînement sur des données récentes, une correction de l'écart de pipeline ou un retour arrière ; consigner la décision avec les preuves.

Résultat attendu

Un tableau de bord par version de modèle montrant la dérive des caractéristiques, la dérive des prédictions et la performance réelle avec décalage ; l'écart causé par des différences de pipeline est séparé d'un changement réel des données.

Limites et base de vérification

Sur de grandes fenêtres, les tests de distribution signalent des déplacements minimes et sans conséquence ; le seuil relève d'un jugement propre à chaque caractéristique. Une dérive des entrées ne prouve pas une baisse de performance, et la performance peut baisser sans dérive visible des entrées. Le délai d'arrivée des étiquettes borne la vitesse à laquelle une dégradation réelle peut être confirmée. Aucun taux de détection n'est revendiqué.