MLOps erklärt: von der Modellentwicklung zum produktiven Betrieb

Ein trainiertes Modell benötigt mehr als eine Bereitstellung. Erfahren Sie, wie MLOps Entwicklung, Validierung, Freigabe und Überwachung verbindet, damit Teams Entscheidungen nachvollziehen und Änderungen kontrollieren können.

MLOps, kurz für Machine Learning Operations, verbindet die Modellentwicklung mit den Praktiken, die zum Testen, Freigeben, Überwachen und Warten von ML-Systemen erforderlich sind. Dazu gehören wiederholbare Arbeitsabläufe, Nachvollziehbarkeit, Automatisierung und Zusammenarbeit über den gesamten Lebenszyklus hinweg.

Ein erfolgreicher Trainingslauf ist ein Schritt. Bevor Menschen Vorhersagen nutzen, muss das Team wissen, welche Version eingesetzt wird, wie sie bewertet wurde, ob eingehende Daten geeignet sind und wer bei einem Fehler reagiert.

Wenn Sie die Grundlagen des Modelltrainings verstehen, aber mit dem produktiven Betrieb weniger vertraut sind, lohnt sich ein genauerer Blick auf diese Zusammenhänge. Mit der Bereitstellung beginnt eine fortlaufende Verantwortung für das System.

Was MLOps zur Modellentwicklung beiträgt

MLOps unterstützt eine wiederholbare Modellentwicklung und macht ihre Ergebnisse während des laufenden Betriebs nachvollziehbar und verwaltbar.

Ein Notebook kann ein nützliches Experiment enthalten. Andere Personen benötigen dennoch einen zuverlässigen Weg, um die Verarbeitung zu wiederholen, die Bewertung zu prüfen und das entstandene Modell zu verwenden. Abhängigkeiten, Konfiguration, Datenaufbereitung und Freigabeentscheidungen spielen dabei eine Rolle.

Die MLOps-Architekturanleitung von Google Cloud beschreibt die zusätzlichen Daten- und Modellprüfungen, die neben herkömmlichen Softwaretests erforderlich sind.

MLOps baut auf DevOps auf. DevOps verbindet Softwareentwicklung und Betrieb durch Praktiken wie Zusammenarbeit, Tests, Versionsverwaltung und Automatisierung. Bei ML-Systemen kommen Fragen zu Trainingsdaten, erlerntem Modellverhalten, Bewertung und veränderten Eingaben hinzu.

Praktische Fragen sind:

• Lässt sich der Prozess wiederholen?

• Kann ein Modell seinen Entwicklungsaufzeichnungen zugeordnet werden?

• Welche Prüfungen müssen vor der Freigabe bestanden werden?

• Wie werden Probleme erkannt?

• Wer untersucht und genehmigt Änderungen?

Tools unterstützen diese Aufgaben. Die Installation einer Plattform beantwortet diese Fragen jedoch nicht von selbst.

Der MLOps-Lebenszyklus: wie die Phasen zusammenhängen

Betrachten Sie ein hypothetisches System, das die wöchentliche Produktnachfrage vorhersagt. Das Planungsteam benötigt nützliche Vorhersagen vor jedem Planungszyklus.

Die folgenden sechs Phasen sind eine Möglichkeit, den Lebenszyklus zu erklären. Sie beschreiben verbundene Tätigkeiten und keinen allgemeingültigen Standard mit festen Grenzen. Neue Erkenntnisse können dazu führen, dass das Team zu einer früheren Phase zurückkehrt.

Einen wiederholbaren Trainingsprozess entwickeln

Beginnen Sie mit der Vorhersageaufgabe und ihren Anforderungen. Legen Sie Produkte, Prognosezeitraum, verfügbare Eingaben und Kriterien zur Bewertung eines Modellkandidaten fest.

Prüfen Sie die Daten und dokumentieren Sie die Aufbereitungsschritte. Vergleichen Sie Ansätze und erfassen Sie dabei Konfigurationen und Ergebnisse.

Eine ML-Pipeline verbindet Verarbeitungsschritte wie Validierung, Aufbereitung, Training und Bewertung. Wiederverwendbare Komponenten verringern die Abhängigkeit davon, dass jemand Notebook-Zellen manuell ausführt.

Im Nachfragebeispiel sollte das Team nachvollziehen können, wie aus Verkaufsdaten Modelleingaben entstehen und wie ein Trainingslauf konfiguriert ist.

Phasenergebnis: ein Modellkandidat, seine Bewertungsergebnisse und die Aufzeichnungen, die seine Entstehung nachvollziehbar machen.

Den Modellkandidaten vor der Freigabe validieren

Die Validierung prüft, ob der Kandidat die festgelegten Anforderungen für seinen vorgesehenen Einsatz erfüllt.

Bewerten Sie die Vorhersagequalität mit geeigneten Datenaufteilungen und Kennzahlen. Vergleichen Sie den Kandidaten mit einem einfachen Referenzverfahren, einer sogenannten Baseline, oder gegebenenfalls mit dem aktuell eingesetzten Modell.

Bei Nachfrageprognosen muss die Bewertung die zeitliche Reihenfolge berücksichtigen. Untersuchen Sie relevante Fehlermuster, statt ausschließlich einen Durchschnitt über alle Produkte zu betrachten.

Testen Sie außerdem die Softwarekomponenten. Prüfen Sie, ob erwartete Ein- und Ausgaben zur Vorhersageschnittstelle passen.

Ein besserer Durchschnittswert allein entscheidet nicht über die Freigabe. Möglicherweise müssen schlechte Ergebnisse für einzelne Produkte oder Unvereinbarkeiten mit dem bestehenden Arbeitsablauf untersucht werden.

Phasenergebnis: ein Validierungsprotokoll als Grundlage für Freigabe, Ablehnung oder weitere Untersuchung.

Das Modell und seine zugehörigen Aufzeichnungen versionieren

Weisen Sie dem Kandidaten eine eindeutige Version zu und verknüpfen Sie diese mit den relevanten Entwicklungsnachweisen.

Ein Modellartefakt ist das gespeicherte Trainingsergebnis, das für Vorhersagen verwendet wird. Seine Version sollte von früheren Kandidaten unterscheidbar sein.

Eine Modellregistrierung hilft, Modelle, Versionen und zugehörige Informationen zu organisieren. Das Team kann damit einen Kandidaten identifizieren und die ursprünglichen Experimente oder Bewertungsaufzeichnungen finden.

Die Registrierung bedeutet keine Freigabe. Eine neu erfasste Version kann sich weiterhin in Prüfung befinden.

Im hypothetischen Projekt sollte klar erkennbar sein, welche Version getestet wird und welche derzeit die Ergebnisse für die Planung erzeugt.

Phasenergebnis: ein identifizierbarer Kandidat mit nachvollziehbaren Begleitaufzeichnungen.

Die Version kontrolliert bereitstellen

Paketieren Sie die erforderlichen Modell- und Softwarekomponenten. Prüfen Sie Abhängigkeiten, Konfiguration und Kompatibilität mit der Zielumgebung.

Inferenz bezeichnet die Verwendung des Modells zur Erstellung von Vorhersagen. Diese können stapelweise erzeugt oder auf Anfrage einer Anwendung zurückgegeben werden.

Für die wöchentliche Nachfrageplanung genügt möglicherweise ein zeitgesteuerter Stapelverarbeitungsprozess. Andere Anwendungen benötigen einen Dienst, der Vorhersagen auf Anfrage liefert.

Führen Sie vor der Freigabe die relevanten Prüfungen durch und holen Sie die vorgesehene Genehmigung ein. Legen Sie fest, wie Probleme erkannt werden und welche Wiederherstellungsoptionen verfügbar sind. Eine schrittweise Einführung kann gegebenenfalls den Anteil der Anfragen oder Verarbeitungsvorgänge begrenzen, die zunächst von der neuen Version bearbeitet werden.

Phasenergebnis: eine freigegebene Version in ihrer Zielumgebung, mit dokumentierter Bereitstellung und klarer Zuständigkeit.

Methoden zur Bereitstellung von Vorhersagen und konkrete Umsetzungsentscheidungen behandelt unser Leitfaden zur Bereitstellung von Machine-Learning-Modellen.

Das System und die Vorhersagequalität überwachen

Die Überwachung beantwortet unterschiedliche Fragen.

Die Anleitung zur Modellüberwachung von Microsoft unterscheidet Signale zu Datenqualität, Drift und Modellleistung.

Datendrift bedeutet, dass sich die Verteilung der Eingaben verändert hat. Sie kann eine Untersuchung rechtfertigen, beweist aber allein keine Verschlechterung der Vorhersagegenauigkeit.

Im Nachfragebeispiel liegen tatsächliche Ergebnisse erst nach dem Prognosezeitraum vor. Verarbeitungsfehler können sofort geprüft werden, während die Bewertung der Vorhersagequalität zeitversetzt erfolgt.

Phasenergebnis: Überwachungsergebnisse mit ausreichend Kontext für eine verantwortliche Person, um sie zu untersuchen.

Erkenntnisse untersuchen, bevor eine Aktualisierung gewählt wird

Eine Warnmeldung zeigt einen Zustand an, der untersucht werden sollte. Die angemessene Reaktion hängt von der Ursache ab.

Verwendet die wöchentliche Eingabedatei eine geänderte Produktkennung, kann zunächst eine Datenkorrektur oder Anpassung der Validierung erforderlich sein. Ein erneutes Modelltraining würde dieses Problem nicht unbedingt beheben.

Andere Erkenntnisse können eine Codekorrektur, Konfigurationsänderung, ein neues Experiment oder erneutes Training rechtfertigen. Die Wiederherstellung einer früheren Version kann unter bestimmten Umständen sinnvoll sein. Ein älteres Modell kann unter veränderten Bedingungen jedoch ebenfalls ungeeignet sein.

Jeder Ersatzkandidat sollte erneut die relevanten Bewertungs- und Freigabeprüfungen durchlaufen.

Phasenergebnis: eine begründete Reaktion und, falls erforderlich, eine validierte Aktualisierung.

CI, Continuous Delivery und Continuous Training erklärt

Diese Begriffe beschreiben unterschiedliche Tätigkeiten. Werden sie gleichgesetzt, bleibt unklar, was automatisiert ist und wo weiterhin eine Entscheidung erforderlich ist.

Continuous Deployment geht über Continuous Delivery hinaus: Änderungen werden automatisch bereitgestellt, wenn sie die erforderlichen Prüfungen bestehen.

Eine ML-Pipeline führt verbundene ML-Aufgaben aus. CI/CD-Prozesse prüfen und veröffentlichen Änderungen an relevanten Komponenten. Continuous Training kann neue Modellkandidaten erzeugen, ohne dass sich der Code geändert hat.

Für das Nachfragesystem könnte ein geplanter Trainingslauf jeden Monat einen Kandidaten erstellen. Das bedeutet nicht, dass jeder Kandidat das eingesetzte Modell ersetzen sollte. Er muss weiterhin die Annahmekriterien erfüllen.

Die Architekturanleitung von Google Cloud beschreibt CI, CD und CT als verbundene, aber unterschiedliche Bestandteile der ML-Automatisierung. Einen Modellkandidaten automatisch freizugeben und bereitzustellen ist eine Gestaltungsentscheidung, keine Voraussetzung für jeden MLOps-Prozess.

Was Sie über den Lebenszyklus hinweg dokumentieren sollten

Nachvollziehbarkeit verbindet ein Vorhersagesystem mit den zugehörigen Entwicklungsaufzeichnungen und Entscheidungen.

Die Dokumentation zur Modellregistrierung von MLflow beschreibt Versionierung, Herkunftsnachweise, Aliase, Tags und Anmerkungen. Die Modellherkunft, häufig als Lineage bezeichnet, beschreibt, woher ein Modell stammt und wie es mit seiner ursprünglichen Entwicklung zusammenhängt.

Diese Aufzeichnungen erleichtern Untersuchungen. Verändern sich Ergebnisse nach einer Bereitstellung, kann das Team das relevante Modell, den Code, die Konfiguration und die Datenreferenzen prüfen.

Eine Modellregistrierung unterstützt Organisation und Nachvollziehbarkeit. Sie belegt nicht eigenständig Vorhersagequalität, Eignung zur Freigabe oder Rechtskonformität.

Mit den Kontrollen beginnen, die Ihr Projekt benötigt

Machen Sie die Arbeit zunächst verständlich und wiederholbar. Ergänzen Sie Automatisierung dort, wo sie ein definiertes Betriebsproblem löst.

Ein überschaubarer Einstieg ist:

1. Die Verarbeitung wiederholbar machen. Dokumentieren Sie Ausführung, Abhängigkeiten und Konfiguration.

2. Aussagekräftige Prüfungen ergänzen. Validieren Sie relevante Daten, Codefunktionen und das Modellverhalten.

3. Versionen und Entscheidungen erfassen. Halten Sie fest, was bewertet und freigegeben wurde.

4. Überwachung und Zuständigkeiten definieren. Legen Sie fest, was geprüft wird und wer reagiert.

5. Wiederkehrende Schritte bei Bedarf automatisieren. Behalten Sie Validierungs- und Freigabekontrollen bei.

Ein kleines System mit seltenen Aktualisierungen benötigt möglicherweise eine einfachere Lösung als ein System mit vielen Anfragen und regelmäßigen Bereitstellungen.

Zu den Toolkategorien gehören Experimentverfolgung, Modellregistrierung, Orchestrierung, CI/CD und Überwachung. Orchestrierung koordiniert die Ausführung von Aufgaben und deren Abhängigkeiten.

Wählen Sie Produkte nach den Anforderungen und den betrieblichen Fähigkeiten des Teams. Kubernetes, ein Feature-Store zur zentralen Verwaltung von Eingangsmerkmalen oder eine bestimmte Cloud-Plattform sind keine allgemeingültigen Voraussetzungen.

Häufige MLOps-Fehler vermeiden

Nur auf Grundlage von Softwaretests freigeben. Bestandene Codetests belegen nicht, dass Eingabedaten oder Modellverhalten geeignet sind. Ergänzen Sie relevante Daten- und Modellprüfungen.

Registrierung mit Freigabe gleichsetzen. Eine erfasste Modellversion ist identifizierbar. Die Entscheidung über ihren Einsatz benötigt weiterhin belastbare Nachweise.

Nach jeder Driftwarnung erneut trainieren. Untersuchen Sie, was sich geändert hat und ob es die Anwendung beeinflusst. Eine Daten- oder Verarbeitungskorrektur kann angemessener sein.

Wiederherstellungsverfahren und Zuständigkeiten offenlassen. Eine Betriebsübersicht hilft wenig, wenn niemand weiß, wer reagieren soll. Dokumentieren Sie Verantwortlichkeiten und ein praktikables Wiederherstellungsverfahren einschließlich der Grenzen einer Rücksetzung auf frühere Versionen.

Auch diese Kontrollen müssen bei Systemänderungen gepflegt werden. Ein Verfahren für eine frühere Schnittstelle oder Abhängigkeit stellt den aktuellen Dienst möglicherweise nicht mehr wieder her.

Ihr Verständnis für ML im produktiven Betrieb vertiefen

Nehmen Sie ein bestehendes Projekt und verfolgen Sie ein Modell von der Entwicklung bis zum Betrieb. Identifizieren Sie Aufzeichnungen, Validierung, Freigabeentscheidung, Überwachung und Reaktionsverfahren. Fehlende Verbindungen ergeben konkrete Lernaufgaben.

Der GCI-Kurs Machine Learning Engineer Professional Diploma nennt im veröffentlichten Lehrplan Themen zu produktivem ML und MLOps, darunter Bereitstellungsarchitekturen, CI/CD und Tests, Überwachung und Modelldrift sowie den Umgang mit Störungen. Zu den veröffentlichten Voraussetzungen gehören grundlegende Python-Kenntnisse und Grundlagen in Mathematik und Statistik.

Der Kursabschluss allein belegt keine Kompetenz für den eigenständigen Betrieb und garantiert keine Beschäftigung.

Prüfen Sie den Lehrplan und die Teilnahmevoraussetzungen, um einzuschätzen, wie der Kurs zu Ihrem Lernbedarf passt.