Ein produktives Modell auf Drift überwachen: Eingaben, Ausgaben und verzögerte Labels

Ziel

Erkennen, bevor Nutzer es tun, dass ein produktives Modell nicht mehr so funktioniert, wie es sein Testscore versprach, und die drei Ursachen unterscheiden: Die Eingaben haben sich geändert, die Serving-Pipeline berechnet Features anders als das Training, oder die Welt hat sich verändert, sodass dieselben Eingaben nun andere Ergebnisse bedeuten.

Voraussetzungen

Eine mit der Modellversion gespeicherte Referenzstichprobe aus Trainingsfeatures und -vorhersagen; Serving-Code, der pro Vorhersage die Modellversion, den ausgelieferten Feature-Vektor, die Ausgabe und eine Anfrage-Kennung protokolliert; sowie einen Weg, auf dem tatsächliche Ergebnisse später mit derselben Kennung eintreffen.

Schritte

1. Die Features genau so protokollieren, wie das Modell sie zum Serving-Zeitpunkt gesehen hat. Googles Rules of Machine Learning definiert Training-Serving-Skew als Unterschied zwischen der Leistung beim Training und beim Serving, nennt Pipeline-Diskrepanzen und Datenänderungen als Ursachen und rät, die zum Serving-Zeitpunkt verwendeten Features zu speichern und in ein Trainingslog zu leiten, damit die Konsistenz zwischen Serving und Training überprüft werden kann.
2. Pro Feature und pro Zeitfenster die ausgelieferte Verteilung mit der Trainingsreferenz vergleichen: bei numerischen Features ein Zwei-Stichproben-Test wie der Kolmogorow-Smirnow-Test (scipy.stats.ks_2samp vergleicht die zugrunde liegenden stetigen Verteilungen zweier unabhängiger Stichproben) oder eine Distanz zwischen gebinnten Histogrammen; bei kategorialen Features die Häufigkeit jedes Werts und der Anteil bisher ungesehener Werte.
3. Die Vorhersageverteilung (Score-Histogramm, Positivrate) auf dieselbe Weise mit der Referenz vergleichen; eine Verschiebung hier bei unveränderten Eingaben deutet auf die Serving-Pipeline hin.
4. Wenn Labels eintreffen, sie über die Anfrage-Kennung joinen und die Offline-Kennzahl über das von den Labels abgedeckte Zeitfenster berechnen; sie mit der bekannten Verzögerung neben die Eingabe-Drift-Signale plotten.
5. Auf anhaltende Verschiebungen alarmieren, nicht auf einzelne Zeitfenster, und die Schwellenwerte pro Feature zusammen mit der Modellversion in der Konfiguration halten.
6. Bei einer bestätigten Verschiebung entscheiden zwischen erneutem Training mit aktuellen Daten, dem Beheben der Pipeline-Diskrepanz oder einem Rollback; die Entscheidung mit den Belegen festhalten.

Erwartetes Ergebnis

Ein Dashboard pro Modellversion mit Feature-Drift, Vorhersage-Drift und verzögerter tatsächlicher Leistung; durch Pipeline-Unterschiede verursachter Skew wird von echter Veränderung in den Daten getrennt.

Grenzen und Prüfbasis

Verteilungstests über grosse Zeitfenster markieren winzige, harmlose Verschiebungen; der Schwellenwert ist eine Ermessensentscheidung pro Feature. Drift in den Eingaben beweist keinen Leistungsabfall, und die Leistung kann ohne sichtbare Eingabe-Drift sinken. Die Label-Verzögerung begrenzt, wie schnell eine echte Verschlechterung bestätigt werden kann. Es werden keine Erkennungsraten behauptet.