MLOps: Monitoring, Retraining & Drift

MLOps: Monitoring, Retraining und Drift

2020 kaufte Zillows iBuying-Algorithmus unauffällig Häuser zu Preisen, die die Modelle für angemessen hielten. Trainiert worden waren die Modelle auf einem Immobilienmarkt, den es nicht mehr gab. Ende 2021 hatte Zillow Offers bei tausenden Objekten zu viel bezahlt, schrieb mehr als 500 Millionen Dollar ab, entließ ein Viertel der Belegschaft und stellte das Geschäft ein. Die Modelle sind nicht abgestürzt. Sie haben keine Fehler geworfen. Sie lieferten selbstbewusste Prognosen, bis zu dem Tag, an dem das Unternehmen die Einheit dichtmachte. Genau das kennzeichnet den Failure Mode, für den Sie jetzt verantwortlich sind: Ein Modell im Produktivbetrieb fällt nicht laut aus. Es verrottet still und nimmt die P&L mit.

Im Fundamentals-Track haben Sie gelernt, wie ein Modell gebaut und deployt wird. Diese Lektion behandelt die achtzehn Monate *nach* dem Deployment, also die operative Disziplin, die ein Modell ehrlich hält, während sich die Welt darunter bewegt. Die meisten Organisationen stecken 90 % ihres ML-Aufwands in das erste Deployment und fast nichts in das, was danach passiert. Genau in dieser Asymmetrie stirbt der Wert.

Die zwei Arten von Verfall und warum die Unterscheidung Ihre Reaktion bestimmt

Das Wort „Drift“ wird in Status-Meetings großzügig verwendet. Als CDO müssen Sie drei klar getrennte Phänomene auseinanderhalten, denn jedes verlangt eine andere Intervention und einen anderen Owner.

Data Drift ist eine Veränderung der Verteilung der *Inputs* des Modells. Ihr Fraud-Modell wurde trainiert, als 20 % der Transaktionen mit physischer Karte stattfanden; heute, nach der Pandemie, sind 70 % online. Der Zusammenhang zwischen Features und Outcome kann intakt sein, aber das Modell sieht jetzt Inputs, mit denen es kaum trainiert wurde. Das ist oft harmlos oder selbstkorrigierend, aber es ist Ihr frühestes Warnsignal.

Concept Drift ist eine Veränderung des Zusammenhangs zwischen Inputs und dem *Ziel selbst*. Dasselbe Kundenprofil, das 2019 niedrigen Churn vorhersagte, sagt heute hohen Churn voraus, weil ein Wettbewerber in den Markt eingetreten ist. Ihre Inputs können statistisch identisch aussehen, während sich die zugrunde liegende Realität umgedreht hat. Das ist der gefährliche Fall, denn Input-Monitoring allein erkennt ihn nicht. Zillow erlitt Concept Drift: Die Abbildung von Hausmerkmalen auf den künftigen Verkaufspreis verschob sich unter einem Modell, das weiterhin vertraut aussehende Häuser sah.

Label Drift / verzögerte Ground Truth ist das operative Problem, das Concept Drift so heimtückisch macht. In vielen wertvollen Use Cases, etwa Kreditausfall, Versicherungsschäden, Churn mit langem Zyklus, *kennen* Sie das tatsächliche Ergebnis monatelang nicht. Sie können die Prognosegüte nicht in Echtzeit messen, weil die Antwort noch nicht vorliegt. Das zwingt Sie, Proxys statt Wahrheit zu überwachen.

Die praktische Konsequenz: Je länger Ihre Ground-Truth-Latenz, desto mehr müssen Sie in Input-seitiges und Proxy-Monitoring investieren, denn Ihre Accuracy-Metriken sind ein Rückspiegel, der auf eine Straße zeigt, die Sie vor Monaten gefahren sind.

Ein Monitoring-Stack, der zu diesen drei Phänomenen passt

Bauen Sie Monitoring in drei Schichten und bestehen Sie darauf, dass jedes Produktionsmodell alle drei hat, bevor es live geht:

Input-Monitoring (erfasst Data Drift, sofort verfügbar). Verfolgen Sie Feature-Verteilungen gegen eine Trainingsreferenz. Population Stability Index (PSI) und Kolmogorov-Smirnov-Statistiken sind die Arbeitspferde. PSI über 0,2 bei einem relevanten Feature ist ein „jetzt hinschauen“-Signal; über 0,25 ist ein Alert.

Prediction-Monitoring (erfasst Drift, die Sie sehen können, bevor Labels eintreffen). Verfolgen Sie die Verteilung der *Outputs* des Modells. Wenn Ihr Approval-Rate-Modell plötzlich 40 % statt 25 % genehmigt, hat sich etwas bewegt, noch bevor Sie wissen, ob diese Genehmigungen gut waren.

Performance-Monitoring (erfasst Concept Drift, verzögert). Verfolgen Sie Accuracy, Precision/Recall, Kalibrierung und Business-KPIs, sobald Ground Truth eintrifft. Das ist Wahrheit, aber spät.

python

# Population Stability Index — the one metric to put on the wall
def psi(expected, actual, buckets=10):
    breakpoints = np.quantile(expected, np.linspace(0, 1, buckets + 1))
    e = np.histogram(expected, breakpoints)[0] / len(expected)
    a = np.histogram(actual, breakpoints)[0] / len(actual)
    e, a = np.clip(e, 1e-4, None), np.clip(a, 1e-4, None)
    return np.sum((a - e) * np.log(a / e))
# <0.1 stable | 0.1–0.25 investigate | >0.25 significant shift

Der häufigste Fehler, den ich sehe: Teams überwachen nur Schicht 3, weil das die „echte“ Metrik ist. Wenn sich Schicht 3 bei einem Modell mit langsamen Labels bewegt, haben Sie ein Quartal lang verschlechterte Entscheidungen ausgeliefert. Schicht 1 und 2 sind Ihre Rauchmelder; Schicht 3 ist die Feuerwehr, die eintrifft.

Entscheiden, wann retrainiert wird: vom Reflex zur Policy

Es gibt drei Retraining-Philosophien, und die Wahl dazwischen ist eine echte Führungsentscheidung, kein Data-Science-Default.

Geplantes Retraining, also Retraining in festem Rhythmus (wöchentlich, monatlich). Einfach, auditierbar, budgetierbar. Es ist aber entweder verschwenderisch (Retraining eines stabilen Modells) oder zu langsam (eine schnelle Domäne driftet zwischen den Zyklen). Nutzen Sie es als Untergrenze, nicht als Strategie.

Getriggertes Retraining, also Retraining, wenn ein Monitoring-Signal eine Schwelle überschreitet. Hier leben reife Organisationen. Das Modell wird neu trainiert, wenn PSI eine Linie überschreitet, wenn die Accuracy unter ein SLA fällt oder wenn eine Business-Metrik nachlässt. Effizient, erfordert aber disziplinierte Schwellenwerte und eine Governance-Schicht, damit sich das Modell nicht in einen schlechteren Zustand hinein retrainiert.

Kontinuierliches / Online Learning, das Modell aktualisiert sich fortlaufend aus Streaming-Daten. Stark für Recommendation- und Ad-Ranking-Systeme, fast überall sonst gefährlich. Es entfernt den menschlichen Checkpoint und erlaubt einem vergifteten oder anomalen Datenstrom, das Modell nahezu in Echtzeit zu korrumpieren. Reservieren Sie es für hochfrequente Probleme mit kleinem Blast Radius und Selbstkorrektur.

Das Entscheidungs-Framework für Retraining

Lassen Sie „die Metrik ist gefallen“ nicht automatisch „retrainieren“ bedeuten. Retraining ist *Kosten und Risiko*, kein kostenloser Reset. Gehen Sie die Entscheidung über vier Fragen durch:

Ist die Verschlechterung echt oder Rauschen? Ein einzelner schlechter Tag ist keine Drift. Verlangen Sie, dass das Signal über ein definiertes Fenster bestehen bleibt, bevor Sie handeln. Stellen Sie die Sensitivität auf Ihren Entscheidungsrhythmus ein, nicht auf das minütliche Zittern der Daten.

Wird Retraining es tatsächlich beheben? Diese Frage überspringen Teams. Wenn sich die Welt wirklich verändert hat (Concept Drift), hilft Retraining auf frischen gelabelten Daten. Liegt das Problem aber an einer kaputten Upstream-Data-Pipeline, etwa einem Feature, das plötzlich null liefert, dann backt Retraining die Korruption in das neue Modell ein. Diagnostizieren Sie die Ursache, bevor Sie retrainieren. Ein erschreckender Anteil von „Drift“ ist in Wahrheit ein still gescheiterter ETL-Job.

Haben Sie genug frische gelabelte Daten für das Retraining? In Domänen mit verzögerten Labels erkennen Sie Drift möglicherweise lange, bevor Sie genug neue Ground Truth haben, um ein besseres Modell zu trainieren. Manchmal ist der richtige Schritt, auf ein einfacheres, robusteres Modell oder eine menschliche Prüfung zurückzufallen, *nicht* auf dünnen Daten zu retrainieren.

Wie groß ist der Blast Radius, wenn das Retraining schiefgeht? Eine neue Modellversion ist ein neues Deployment mit eigenem Risiko. Sie muss dieselben Validierungs-Gates passieren wie das Original. Retraining unter Druck, mit übersprungener Validierung, ist der Weg, ein langsam degradierendes Modell durch ein schnell versagendes zu ersetzen.

Netflix und andere Häuser mit hoher Reife lösen das, indem sie jedes retrainierte Modell als Kandidaten behandeln, nicht als Ersatz. Der Kandidat läuft im Shadow Mode, bewertet Live-Traffic ohne Einfluss auf Entscheidungen und wird vor der Promotion auf Live-Daten gegen den Amtsinhaber verglichen. Die Champion/Challenger-Disziplin, die Sie aus dem Experimentieren kennen, gilt direkt: Der Amtsinhaber bleibt Champion, bis ein Challenger ihn *nachweisbar* auf den relevanten Metriken und auf aktuellen Daten schlägt.

Machine Learning Monitoring & Drift Detection Explained

Watch on YouTube

Referenzdaten: die still entscheidende Wahl

Jede Drift-Metrik vergleicht „jetzt“ mit einer „Referenz“. Was ist Ihr Referenzfenster? Wenn Sie für immer gegen das ursprüngliche Trainingsset vergleichen, schreien saisonale Geschäfte jeden Dezember „Drift!“. Wenn Sie gegen ein rollierendes, aktuelles Fenster vergleichen, normalisieren Sie eine echte Verschlechterung möglicherweise langsam weg, das Frosch-im-Topf-Problem, bei dem die Referenz mit den Daten mitdriftet und nie auslöst. Die richtige Antwort ist meist *beides*: ein fixer Vergleich mit der Trainingsreferenz für absolute Drift und ein rollierender Vergleich für die Geschwindigkeit. Machen Sie das zu einer expliziten, dokumentierten Entscheidung, nicht zu einem Default, den jemand im Notebook gewählt hat.

Wissenscheck

1. Was kennzeichnet, wie ein Modell im Produktivbetrieb „verrottet“, wie am Zillow-Beispiel illustriert?

2. Ein Team stellt fest, dass sich die Input-Verteilung seines Modells verschoben hat (z. B. weit mehr Online- als Karten-präsente Transaktionen), der Zusammenhang zwischen Features und Outcomes aber intakt erscheint. Welches Phänomen ist das, und wie sollte damit umgegangen werden?

3. Warum gilt Concept Drift als das gefährlichere Phänomen im Vergleich zu Data Drift?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die drei in der Lektion beschriebenen Phänomene (Data Drift, Concept Drift, Label Drift) korrekt unterscheiden.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Gründe, die die Lektion dafür nennt, warum verzögerte Ground Truth (Label Drift) Concept Drift besonders heimtückisch macht.

Wählen Sie alle richtigen Antworten aus.

Das MLOps, das ein CDO finanzieren, verantworten und einfordern muss

Sie schreiben den Monitoring-Code nicht. Ihre Aufgabe ist sicherzustellen, dass das *Betriebssystem* um Modelle herum existiert, finanziert ist und klare Owner hat. Vier Fähigkeiten trennen Organisationen, die Modelle betreiben, von solchen, die sie nur deployen.

Ein Model Registry und Lineage-System. Sie müssen für jede Prognose, die ein geschäftliches oder regulatorisches Problem verursacht hat, beantworten können: Welche Modellversion hat sie erzeugt, auf welchen Daten wurde sie trainiert, wer hat sie freigegeben und wann. Wenn Ihr Team das nicht in Minuten rekonstruieren kann, haben Sie ein Audit- und Haftungsrisiko, nicht bloß eine technische Lücke. Das ist das operative Rückgrat der AI-Governance, die Sie ohnehin verantworten.

Ein Feature Store mit Training-Serving-Konsistenz. Der häufigste Produktionsbug ist *Training-Serving-Skew*: Ein Feature wird in der Trainings-Pipeline auf eine Weise berechnet und im Live-Serving-Pfad subtil anders. Das Modell sieht in der Validierung großartig aus, unterperformt in Produktion, und alle schieben es auf Drift. Ein Feature Store, der *dieselbe Berechnung* für Training und Inference liefert, eliminiert eine ganze Kategorie stiller Fehler. Wenn ein Team „unerklärliche Drift“ meldet, ist Skew der erste Verdächtige.

Automatisierte Validierungs-Gates in der Deployment-Pipeline. Keine Modellversion, auch keine retrainierte, erreicht Produktion, ohne Tests zu bestehen: Performance-Schwellen, Fairness-Checks über geschützte Segmente, Kalibrierung und Verhaltenstests auf bekannten Edge Cases. Genau das macht getriggertes Retraining sicher. Das Gate steht zwischen „das Modell hat nachgelassen“ und „wir sind in Panik geraten und haben etwas Schlechteres ausgeliefert“.

Ein Rollback-Pfad. Jedes deployte Modell braucht eine Rückkehr zur Vorgängerversion per Klick und idealerweise einen Fallback auf eine einfache, robuste Baseline (auch eine Heuristik aus Geschäftsregeln). Wenn das ausgefeilte Modell um 2 Uhr nachts Unsinn macht, sollte der On-Call-Engineer nichts retrainieren. Er sollte zurückrollen. Stellen Sie Ihrem Team die direkte Frage: *„Wenn unser wichtigstes Umsatzmodell jetzt sofort Müll produziert, wie lange, bis wir sicher auf der Vorgängerversion sind?“* Lautet die Antwort mehr als Minuten, ist das Ihre Priorität für Montag.

Die Frage des Org-Designs, die darunter liegt

Hier ist das Fehlermuster, das kein Tool behebt. Data Scientists bauen das Modell, übergeben es an Engineering und gehen zum nächsten Projekt. Sechs Monate später degradiert das Modell und *niemand verantwortet es*. Die Scientists sind weg, die Engineers verstehen die Modelllogik nicht, und das Business merkt es erst, wenn der KPI einbricht.

Die Lösung ist organisatorisch, und sie liegt bei Ihnen. Weisen Sie jedem Produktionsmodell einen namentlichen Owner zu, der für die laufende Performance verantwortlich ist, das ML-Äquivalent eines Product Managers. Etablieren Sie ein Model Performance Review in festem Rhythmus, in dem Owner Drift-Status, Retraining-Entscheidungen und Business-Impact berichten, genauso wie Sie eine Produktlinie reviewen würden. Und definieren Sie eine Model-Retirement-Policy: Modelle erreichen wie Produkte ein End-of-Life. Ein Modell, dessen Weiterbetrieb niemand begründen kann, sollte außer Dienst gestellt werden und nicht weiterlaufen, weil Löschen sich riskant anfühlt. Ein Inventar unverantworteter, unüberwachter Modelle ist kein Asset; es ist eine Sammlung nicht detonierter Verbindlichkeiten in Ihrer Bilanz.

Das Reifesignal, auf das Sie zielen: Ihre Organisation erkennt ein degradierendes Modell über Instrumentierung und Prozess und reagiert darauf, *bevor* die Fachabteilung sich beschwert. Wenn das Business Ihnen vor Ihrem Monitoring sagt, dass das Modell kaputt ist, ist Ihr MLOps Dekoration.

Key Takeaways

Überwachen Sie in drei Schichten und verlassen Sie sich nie allein auf Accuracy. Input-Drift (PSI, KS) und Prediction-Drift sind Ihr Frühwarnsystem; Performance-Metriken kommen in jeder Domäne mit verzögerten Labels zu spät, um Ihre einzige Verteidigung zu sein. Je länger Ihre Ground-Truth-Latenz, desto mehr müssen Sie weiter vorn investieren.

Behandeln Sie Retraining als governte Entscheidung, nicht als Reflex. Bestätigen Sie vor dem Retraining, dass die Verschlechterung echt ist, prüfen Sie, dass die Ursache keine kaputte Pipeline ist (die Retraining einbacken würde), kontrollieren Sie, ob genug frische gelabelte Daten vorliegen, und leiten Sie jedes retrainierte Modell durch dieselben Validierungs-Gates und den Shadow-Mode-Vergleich wie ein neues Deployment.

Beseitigen Sie Training-Serving-Skew, bevor Sie Drift beschuldigen. Ein Feature Store mit konsistenter Berechnung über Training und Inference entfernt die häufigste Quelle „unerklärlicher“ Produktionsverschlechterung. Skew sollte der erste Verdächtige sein, nicht Drift.

Finanzieren Sie die vier MLOps-Pflichtstücke: ein Model Registry mit Lineage, einen Feature Store, automatisierte Validierungs-Gates und einen schnellen Rollback-Pfad auf eine robuste Baseline. Fragen Sie Ihr Team, wie viele Minuten der Rollback Ihres wichtigsten Umsatzmodells dauert, die Antwort verrät Ihre echte Reife.

Weisen Sie jedem Produktionsmodell einen namentlichen Owner zu und führen Sie ein Model Performance Review. Unverantwortete Modelle verrotten still. Ihr Reifeziel: Die Instrumentierung markiert ein degradierendes Modell, bevor die Fachabteilung sich überhaupt beschwert.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Produktionsmodelle über die Ebenen Input, Prediction und Performance hinweg mit namentlich benannten Ownern überwachen

Vollständiges Action Playbook ansehen →