Was ist MLOps?

Der Lebenszyklus eines Modells in sieben Schritten

Aus einem Experiment im Notebook wird erst dann ein Dienst, auf den sich andere Systeme verlassen können, wenn jeder Schritt dazwischen festgehalten und wiederholbar ist. Eine vollständige MLOps-Kette umfasst diese Stationen:

1. 1

   Daten versionieren

   Der Stand des Trainingsdatensatzes wird festgehalten, sonst lässt sich ein Ergebnis später nicht nachbauen, egal wie sauber der Code verwaltet ist.

2. 2

   Merkmale als Code aufbereiten

   Die Vorverarbeitung läuft als Programm statt als Handgriff im Notebook, damit im Betrieb exakt dieselben Schritte laufen wie beim Training.

3. 3

   Trainieren und protokollieren

   Jeder Lauf hält Parameter, Metriken, Datenstand und Codeversion fest, das sogenannte Experiment Tracking.

4. 4

   In der Registry ablegen

   Das fertige Modell landet mit seiner Herkunft in einer Model Registry, die festhält, welche Version geprüft, freigegeben und produktiv ist.

5. 5

   Ausrollen

   Das Modell geht als reguläres Deployment in Betrieb, meist als Container hinter einer Schnittstelle, oft zuerst für einen kleinen Teil der Anfragen.

6. 6

   Überwachen

   Beobachtet werden neben Verfügbarkeit und Antwortzeit die Verteilung der Eingaben und die Qualität der Vorhersagen.

7. 7

   Nachtrainieren

   Ein festgelegter Auslöser startet das Training mit neuen Daten, und die neue Version durchläuft dieselbe Kette wie die erste.

Reifegrade: wie viel davon automatisiert ist

Google beschreibt in seiner Architekturdokumentation drei Stufen, an denen sich viele Teams orientieren. Sie helfen, den eigenen Stand ehrlich einzuordnen, statt sofort die volle Automatisierung anzustreben:

Für ein einzelnes Modell, das zweimal im Jahr erneuert wird, kann Stufe 0 mit sauberer Dokumentation völlig ausreichen. Die Automatisierung lohnt sich in dem Maß, in dem Modelle, Datenquellen und Aktualisierungen zahlreicher werden.

Warum Modelle im Betrieb altern

Ein Modell lernt die Welt in dem Zustand, in dem sie zum Trainingszeitpunkt war. Ändert sich das Verhalten der Kundschaft, kommt ein neues Produkt dazu oder liefert ein Vorsystem ein Feld plötzlich in anderem Format, weichen die Eingaben von dem ab, worauf trainiert wurde. Die Vorhersagen werden schleichend schlechter, ohne dass irgendwo ein Fehler auftaucht.

Fachlich unterscheidet man zwei Formen. Bei der Datendrift verschiebt sich die Verteilung der Eingaben, etwa weil plötzlich mehr Bestellungen aus einem neuen Land kommen. Bei der Konzeptdrift bleibt die Eingabe gleich, aber der Zusammenhang zum Ergebnis ändert sich, etwa wenn Betrüger ihre Masche umstellen. Datendrift lässt sich sofort an den Eingaben messen, Konzeptdrift oft erst, wenn das tatsächliche Ergebnis mit Wochen Verzug bekannt wird.

Werkzeuge und Plattformen

Für die einzelnen Bausteine gibt es verbreitete Open-Source-Werkzeuge: MLflow für Experiment Tracking und Model Registry, DVC für die Versionierung von Datensätzen, Kubeflow für Pipelines auf Kubernetes. Wer lieber eine Plattform aus einer Hand nutzt, findet den kompletten Kreislauf in Azure Machine Learning, Amazon SageMaker oder Google Vertex AI.

Die Wahl des Werkzeugs ist selten das Problem. Entscheidend ist, dass Datenstand, Code, Parameter und Modell an einer Stelle zusammenhängen und dass jemand die Verantwortung für den Betrieb übernimmt. Ein MLflow-Server, den niemand pflegt, hilft so wenig wie eine Plattform, deren Registry nur zum Ablegen benutzt wird.