MLOps-Architekturdiagramm: Von Trainingsdaten zu einem überwachten Modell

Ein Modell in einem Notebook ist kein System. Die bekannte Abbildung aus Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015) zeigt es mit Kästen: Nur ein kleiner Teil eines realen ML-Systems ist ML-Code. Der Rest ist Datenerfassung, Feature-Extraktion, Serving, Monitoring und die Verrohrung dazwischen, und genau dort entstehen die Probleme in der Produktion.

Ein MLOps-Architekturdiagramm zeichnet diesen Rest. Dieser Beitrag baut eines für ein Fraud-Scoring-Modell auf, erklärt die zwei Schleifen, die jedes produktive Modell hat, und listet auf, was du beschriften solltest, damit das Diagramm die Fragen beantwortet, die aufkommen, wenn sich ein Modell falsch verhält.

Zwei Schleifen und ein Auslöser

Jedes produktive Modell hat eine Trainingsschleife und eine Serving-Schleife:

• Trainingsschleife. Daten werden gesammelt, in Features verwandelt, zum Trainieren eines Kandidaten genutzt, mit dem aktuellen Modell verglichen und registriert.
• Serving-Schleife. Eine Anfrage kommt an, Features werden nachgeschlagen, das Modell bewertet sie, und die Vorhersage wird protokolliert.
• Der Auslöser verbindet beide. Die Überwachung der Serving-Schleife, ein Zeitplan oder neue Daten starten die Trainingsschleife erneut.

Googles MLOps-Leitfaden beschreibt drei Reifegrade: Stufe 0 ist ein manueller Prozess, Stufe 1 automatisiert die Trainingspipeline für kontinuierliches Training, und Stufe 2 ergänzt CI/CD für die Pipeline selbst. Zeichne die Stufe, die du hast, nicht die, die du planst, und markiere die manuellen Schritte.

Training-Serving-Skew

Der Fehler, den ein MLOps-Diagramm am häufigsten verhindert, ist der Training-Serving-Skew: ein Feature, das im Trainings-SQL auf eine Weise und im Serving-Code auf eine andere berechnet wird. Das Modell sieht offline gut aus und in Produktion schlechter, und niemand kann sagen, warum. Derselbe Google-Leitfaden empfiehlt einen Feature Store als einzige Quelle für Experimente, kontinuierliches Training und Online-Serving, damit ein Feature genau eine Definition hat.

Der zweite Klassiker ist ein Leck über die Zeit. Eine Trainingszeile für eine Zahlung muss Feature-Werte so verwenden, wie sie zum Zeitpunkt dieser Zahlung waren, nicht so, wie sie heute sind. Schreib diese Point-in-Time-Anforderung an die Kante vom Feature Store zur Trainingspipeline.

Das Beispiel: Fraud-Scoring für Kartenzahlungen

Eine Zahlungs-API fragt ein Modell nach einem Fraud-Score, bevor sie eine Kartenzahlung autorisiert. Der Entwurf:

1. Ereignisse. Die Zahlungs-API veröffentlicht jede Zahlung in Kafka. Ein Streaming-Job hält gleitende Features, etwa Zahlungen pro Karte in der letzten Stunde, in einem Online-Speicher vor. Dieselben Ereignisse landen im Data Warehouse.
2. Labels. Ob eine Zahlung Betrug war, erfährt man aus Chargebacks, die Wochen oder Monate später eintreffen. Sie werden ins Data Warehouse geladen und mit den ursprünglichen Zahlungen verknüpft.
3. Features. Der Feature Store definiert jedes Feature einmal, berechnet die Offline-Werte aus dem Data Warehouse und schreibt die neuesten Werte in den Online-Speicher.
4. Training. Eine orchestrierte Pipeline baut einen Point-in-Time-Trainingsdatensatz, validiert die Daten, trainiert einen Kandidaten, vergleicht ihn auf demselben Evaluierungsdatensatz mit dem Live-Modell und registriert ihn mit seinen Metriken.
5. Release. Eine freigegebene Version wird auf den Scoring-Endpunkt deployt, zuerst im Shadow-Modus, in dem sie Kopien des Live-Traffics bewertet, ohne Entscheidungen zu beeinflussen, dann für einen kleinen Teil des Traffics, dann für alles.
6. Monitoring. Jeder Score wird mit seinen Features protokolliert. Das Monitoring vergleicht die Verteilungen von Eingaben und Scores mit den Trainingsdaten und berechnet Precision und Recall, sobald Labels eintreffen. Ein Drift- oder Qualitäts-Alert startet das Retraining.

So liest du es:

• Obere Reihe, Training. Chargeback-Labels und Ereignishistorie treffen sich im Data Warehouse. Der Feature Store baut Trainingsdatensätze für die Pipeline, die Kandidaten in der Model Registry registriert.
• Untere Reihe, Serving. Die Zahlungs-API veröffentlicht Ereignisse in Kafka und ruft den Scoring-Endpunkt synchron auf. Der Endpunkt liest Features aus dem Online-Speicher und schreibt jeden Score ins Vorhersage-Log.
• Die Registry-Kante ist der einzige Weg, auf dem ein Modell in Produktion kommt: eine freigegebene Version, nie eine aus einem Notebook kopierte Datei.
• Rechts, die Rückschleife. Das Monitoring liest Vorhersagen und späte Labels. Drift oder ein Qualitätsabfall löst einen Alert aus, der die Trainingspipeline startet.

Was du beschriften solltest

• Point-in-Time-Regeln an der Kante zum Trainingsdatensatz.
• Modellversion und Stage am Endpunkt und an der Registry.
• Latenzbudgets für Feature-Abfragen und Scoring, denn die Zahlung wartet darauf.
• Label-Verzögerung. Wenn Labels Wochen brauchen, schreib es hin: Das bestimmt, wie schnell du Qualität messen kannst.
• Retraining-Auslöser: Zeitplan, Drift-Schwelle, Datenmenge.
• Verantwortliche. Daten, Features, Modelle und der Endpunkt gehören oft verschiedenen Teams.

Häufige Fehler

• Ein Kasten namens „ML-Modell“. Er verbirgt Feature Store, Registry und Monitoring-Schleife, also genau die Stellen, an denen Incidents beginnen.
• Kein Rückkanal. Wenn Labels nie zurückkommen, weiß niemand, wann das Modell schlechter wurde.
• Notebooks im Produktionspfad. Ein Modell sollte das Serving nur über die Pipeline und die Registry erreichen.
• Zwei Implementierungen eines Features. Trainings-SQL und Serving-Code, die „denselben“ Wert unterschiedlich berechnen, erzeugen Skew.
• Kein Rollback. Behalte die vorherige Version in der Registry und zeichne, wie der Endpunkt zurückschaltet.
• Nur Infrastruktur-Monitoring. Latenz und Fehlerraten können perfekt sein, während das Modell falsch liegt; überwache auch Eingaben, Scores und Ergebnisse.

Die Serving-Seite ist normale Arbeit an verteilten Systemen. Das Event-driven-Architekturdiagramm deckt die Kafka-Seite ab, und für Sprachmodelle mit Retrieval behandelt das RAG-Architekturdiagramm Indexierung und Serving.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem ML-Pack einen Merkmalsspeicher als Feature Store hinzu, ein Modell für die Registry und einen Endpunkt fürs Scoring.
3. Füge aus dem Daten-Pack Kafka, ein Datenlager als Data Warehouse, Redis für den Online-Speicher und ein Thema für das Vorhersage-Log hinzu.
4. Füge aus dem DevOps-Pack eine CI/CD-Pipeline für das Training hinzu, einen Node Metriken fürs Modell-Monitoring und einen Alarm als Retraining-Auslöser.
5. Füge aus dem C4-Modell-Pack einen Container für die Zahlungs-API und ein Externes System für die Chargebacks des Kartennetzwerks hinzu.
6. Verbinde sie, beschrifte jede Kante mit den Daten, die sie transportiert, und zeichne die späten Labels und den Retraining-Auslöser gestrichelt. Füge aus dem Basis-Pack einen Markdown-Block mit den Release-Schritten hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan. Mit einem über MCP verbundenen KI-Agenten kannst du die Pipeline beschreiben, ihn die Nodes platzieren lassen und danach die Beschriftungen anpassen.

FAQ

Brauche ich einen Feature Store? Nicht am ersten Tag. Du brauchst eine Definition pro Feature, die Training und Serving gemeinsam nutzen. Ein Feature Store ist der übliche Weg dorthin, sobald mehrere Modelle Features teilen oder du frische Features online brauchst.

Was ist der Unterschied zwischen einer Model Registry und einem Artefakt-Speicher? Ein Artefakt-Speicher hält Dateien. Eine Registry ergänzt Versionen, Metriken, Herkunft und einen Freigabestatus, sodass der Deployment-Schritt nach der freigegebenen Version fragen kann statt nach einem Pfad.

Wie oft sollte ein Modell neu trainiert werden? So oft, wie sich die Daten auf eine Weise ändern, die zählt. Starte mit einem Zeitplan, ergänze Drift- und Qualitäts-Auslöser, sobald das Monitoring steht, und halte fest, warum jedes Retraining lief.

Wie überwache ich ein Modell, wenn Labels spät kommen? Beobachte, was du jetzt sehen kannst, etwa Eingabeverteilungen, Score-Verteilungen und den Anteil markierter Zahlungen, und berechne Precision und Recall, sobald die Labels da sind. Zeichne beide Pfade.

Sollten Training und Serving dieselbe Infrastruktur teilen? Sie können die Feature-Definitionen und die Registry teilen, haben aber unterschiedliche Lastprofile. Zeichne sie als getrennte Pfade, die sich im Feature Store und in der Registry treffen.

Kostenlos starten — ein Seat, keine Kreditkarte.