Model Monitoring

Die Modellüberwachung misst kontinuierlich Eingaben, Ausgaben, Leistung und Betriebszustand eines bereitgestellten Machine-Learning-Modells. Sie löst Warnungen aus, wenn einer dieser Werte außerhalb des erwarteten Bereichs liegt. Modellausfälle bleiben meist unbemerkt: Ein Detektor gibt weiterhin Boxen mit plausibler Konfidenz zurück, nachdem eine Kamera versetzt oder ein Objektiv verschmutzt wurde oder ein Produkt neu gestaltet wurde – lediglich die Genauigkeit ändert sich. Die Überwachung vergleicht das Verhalten im laufenden Betrieb mit einer Referenz, üblicherweise den Validierungsdaten, anhand derer das Modell freigegeben wurde. So erkennen Teams Datenverschiebungen und nachlassende Genauigkeit in Dashboards statt durch Rückmeldungen von Nutzern. Die Überwachung schließt den Betriebskreislauf für maschinelles Lernen (MLOps) nach der Modellbereitstellung und entscheidet, wann ein Modell nachtrainiert werden muss.

Was überwacht werden sollte#

Die Überwachung im Produktivbetrieb umfasst üblicherweise vier Ebenen:

• Inferenzlatenz und Betriebszustand: Anfragerate, Fehlerrate, p95- und p99-Latenz sowie GPU-Speicherverbrauch und -Auslastung, häufig mit Prometheus erfasst und in Grafana visualisiert.
• Eingabedaten: Schemaabweichungen, fehlende Werte und Änderungen der Merkmale oder Bildstatistiken, etwa bei Helligkeit, Auflösung oder Objektgröße.
• Vorhersagekonfidenz und Ausgabeverteilung: Klassenverteilung, Erkennungen pro Bild und Konfidenzwerte. Eine Veränderung dieser Werte, die als Vorhersageverschiebung bezeichnet wird, ist ein Frühwarnsignal, bevor Beschriftungen vorliegen.
• Modellleistung: Genauigkeit, Präzision, Trefferquote oder mAP, berechnet, sobald die Grundwahrheit vorliegt. Betrugskennzeichnungen können erst Wochen später in Form von Rückbuchungen eintreffen. Teams für Computer Vision beschriften eine Stichprobe der Produktionsbilder von Hand.

Ultralytics Platform integriert die Vorhersageebene in seine dedizierten Endpunkte: Der Tab „Monitoring“ stellt die Konfidenzverteilung, die durchschnittliche Konfidenz im Zeitverlauf, die häufigsten Klassen und die Anzahl der Vorhersagen pro Bild für ein bereitgestelltes YOLO-Modell dar. Neuere Bilder lassen sich samt Vorhersagen zur Prüfung und zum erneuten Training in einem Datensatz speichern. Der Leitfaden zu Modellüberwachung und -wartung und die Lektion Beobachtbarkeit und Drift der Ultralytics Academy zeigen, wie sich Verschiebungen bei YOLO-Bereitstellungen prüfen lassen.

Zwei Arten von Veränderungen verursachen den größten Teil des Leistungsabfalls. Eine Datenverschiebung, auch Kovariatenverschiebung genannt, verändert die Eingaben – etwa wenn eine Inspektionskamera an einer Fertigung-Linie versetzt oder die Beleuchtung geändert wird. Eine Konzeptverschiebung verändert den Zusammenhang zwischen den Eingaben und den richtigen Antworten – beispielsweise, wenn Betrüger ihre Methoden ändern und zuvor normale Transaktionen betrügerisch werden. Eingabestatistiken machen Datenverschiebungen direkt sichtbar. Konzeptverschiebungen zeigen sich erst in den Leistungskennzahlen, sobald Beschriftungen vorliegen. Beide gehören zu den häufigsten Gründen für das Versagen von Computer-Vision-Modellen im Produktivbetrieb.

Verschiebungen erkennen#

Bei einer häufigen Prüfung wird die Verteilung einer aktuellen Kennzahl mithilfe eines Zweistichproben-Kolmogorow-Smirnow-Tests mit der Referenz verglichen. Der Test misst den größten Abstand zwischen zwei kumulativen Verteilungen. Dieses Skript wendet den Test auf simulierte Erkennungskonfidenzen an: eine Referenzstichprobe aus der Validierung, eine Produktionswoche mit ähnlichen Werten und eine Woche mit niedrigeren Werten:

import numpy as np
from scipy.stats import ks_2samp

rng = np.random.default_rng(0)

# Detection confidences logged at validation time form the reference distribution
reference = rng.beta(8, 2, size=2000)

# Two simulated production windows: one like the reference, one shifted lower
windows = {"week 1": rng.beta(8, 2, size=500), "week 2": rng.beta(5, 3, size=500)}

for name, live in windows.items():
    # Two-sample Kolmogorov-Smirnov test: do both samples come from one distribution?
    result = ks_2samp(reference, live)
    drift = result.pvalue < 0.01
    print(f"{name}: mean {live.mean():.2f}, KS {result.statistic:.3f}, p {result.pvalue:.1e}, drift {drift}")

Woche 1 besteht den Test mit einer KS-Statistik von 0,037 und p = 0,64. In Woche 2 sinkt die durchschnittliche Konfidenz auf 0,63, gegenüber 0,80 in Woche 1. Eine KS-Statistik von 0,456 bei p = 1.2e-75 weist auf eine Verschiebung hin. Bei vielen Tausend Stichproben werden selbst harmlose Veränderungen statistisch signifikant. Daher lösen Prüfungen im Produktivbetrieb häufig einen Alarm aus, wenn die KS-Statistik oder der Populationsstabilitätsindex (PSI) einen festen Schwellenwert überschreitet. Open-Source-Bibliotheken wie Evidently und NannyML bündeln diese Tests in Berichten zu Verschiebungen. NannyML schätzt außerdem anhand kalibrierter Konfidenzwerte die Genauigkeit eines Klassifikators ohne Beschriftungen. Amazon SageMaker Model Monitor und Vertex AI Model Monitoring bieten dieselben Prüfungen als verwaltete Dienste an. Ein Alarm leitet dann eine Untersuchung ein:

Überwachung im Vergleich zu Beobachtbarkeit und Bewertung#

• Beobachtbarkeit: Protokolle, Ablaufverfolgungen und gespeicherte Eingaben, die erklären, warum ein Alarm ausgelöst wurde. Die Überwachung führt vordefinierte Prüfungen aus. Viele Anbieter bieten beide Funktionen als ML-Beobachtbarkeit gemeinsam an.
• Modellbewertung: Bewertet ein Modell vor der Freigabe anhand eines zurückgehaltenen Testsatzes. Die Überwachung wiederholt diese Messung im laufenden Datenverkehr, solange das Modell eingesetzt wird.
• Experimentverfolgung: Protokolliert Trainingsläufe während der Entwicklung, bevor Produktionsdaten vorliegen.