Model Monitoring: Warum KI-Modelle in der Produktion veralten
Ein Modell kann technisch einwandfrei laufen — und trotzdem monatlich schlechter werden. Ohne Monitoring bemerkt das niemand, bis ein Fehler teuer wird.
Was Model Monitoring leistet, welche zwei Arten von Drift ihr kennen müsst, und warum eine Baseline alles entscheidet.
Zwei Ebenen — und warum beide nötig sind
Model Monitoring teilt sich in zwei grundlegend verschiedene Aufgaben:
Operational Monitoring
Läuft die Infrastruktur? Ist Uptime ok? Liegen Latenzen im Bereich? Das ist die klassische DevOps-Aufgabe — bekannt, gelöst, verantwortet.
Functional Monitoring
Macht das Modell noch das, wofür es gebaut wurde? Sind die Input-Daten noch die, auf denen es trainiert wurde? Stimmen die Predictions noch? Das ist die ML-spezifische Aufgabe — weniger bekannt, oft nicht verantwortet.
Der blinde Fleck: Ein Modell kann operational perfect laufen — 100% Uptime, <10ms Latenz — und functional komplett versagen. Wenn die Daten-Distribution sich verändert, merkt kein Infrastruktur-Alert das. Nur Functional Monitoring erkennt es.
Was das für euch bedeutet
Wer nur Operational Monitoring hat, hat kein ML Monitoring. Er hat Server-Monitoring mit einem ML-Modell im Hintergrund.
Data Drift und Concept Drift: Zwei verschiedene Ursachen
Data Drift
Data Drift bedeutet, dass sich die statistische Verteilung der Eingangsdaten gegenüber den Trainingsdaten verändert. Das Modell sieht in Produktion eine andere Welt als die, auf der es trainiert hat.
Vor COVID-19 trainierte Modelle für Supply Chain oder Customer Behaviour trafen auf Daten, die sich fundamental von allem unterschieden, was ihre Trainingssets enthalten hatten. Nicht weil die Modelle schlecht waren — sondern weil die Welt sich verändert hatte.
Concept Drift
Concept Drift ist subtiler: Die Verteilung der Eingangsdaten sieht gleich aus — aber die Bedeutung hat sich verändert. Der Zusammenhang zwischen Features und Target-Variable hat sich verschoben. Das Modell liefert Predictions auf Basis von Mustern, die nicht mehr gelten.
Data Drift
- Erkennbar durch statistische Profil-Vergleiche
- Keine Ground Truth nötig
- Frühzeitiger Indikator
Concept Drift
- Erkennbar nur durch Vergleich mit echten Outcomes
- Ground Truth nötig
- Bestätigt echten Performance-Verlust
Was das für euch bedeutet
Data Drift ist ein Frühwarnsignal. Concept Drift ist die Bestätigung, dass Performance bereits gesunken ist. Wer nur Concept Drift monitort, reagiert immer zu spät.
Die Baseline: Der Anker ohne den nichts funktioniert
Bevor ihr irgendetwas monitoren könnt, braucht ihr einen Referenzpunkt: die statistische Baseline eurer Trainingsdaten. Was ist der Mittelwert, der Median, die Null-Rate, der Wertebereich jedes Features? Was ist die erwartete Accuracy, Precision, Recall?
Baseline erfassen
Beim Deployment: statistische Profile aller Features speichern, Modell-Performance-Metriken festhalten. Format: nicht Rohdaten, sondern statistische Zusammenfassungen (schützt PII).
Schwellenwerte definieren
Ab welcher Abweichung soll ein Alert ausgelöst werden? Das ist eine Business-Entscheidung, keine technische: Was ist die Konsequenz eines Alerts? Was kostet ein falscher Alarm?
Monitoring aktivieren
Kontinuierlicher Vergleich von Production-Daten mit der Baseline. Bei Überschreitung: Alert an den Feature/Model-Owner.
„Eine Baseline ist kein einmaliges Artefakt — sie ist an die Modell-Version gebunden. Wenn das Modell sich ändert, muss die Baseline neu erstellt werden."
Was das für euch bedeutet
Die Baseline muss beim Deployment erstellt werden — nicht retrospektiv. Wer das verschiebt, hat kein Monitoring. Er hat Dashboards ohne Referenz.
Tool-Auswahl: Cloud-nativ oder flexibel
Der Markt bietet heute drei Kategorien von Monitoring-Tools:
Cloud-nativ (SageMaker Model Monitor, Azure ML Monitor)
Enge Integration mit der Deployment-Infrastruktur. Visualisierung, Explainability und Bias-Detection inklusive. Nachteil: Bindet an den Cloud-Provider. Gut wenn ihr ohnehin auf AWS/Azure seid und bleiben wollt.
Vendor-neutrale Plattformen (Arize, Fiddler, Superwise)
Funktionieren cloud-unabhängig, bieten reichhaltige Feature-Sets. Kostenpflichtig. Gut für Teams die mehrere Cloud-Environments oder On-Premise betreiben.
Open-Source (Evidently AI, Whylogs)
Python-Libraries die ohne Vendor-Lock-in funktionieren. Evidently generiert Reports aus zwei Datasets (Training vs. Production). Whylogs loggt statistische Profile ohne Rohdaten. Einstiegshürde niedrig — Infrastruktur für Alerting muss selbst gebaut werden.
Was das für euch bedeutet
Die Tool-Entscheidung ist eine Deployment-Entscheidung — nicht eine Post-Deployment-Entscheidung. Wer nach dem Launch fragt welches Tool er nutzt, hat keine Baseline.