Machine Learning Ops: So funktioniert‘s in der Praxis

Machine Learning Operations (MLOps) ist ein interdisziplinärer Verbund von Praktiken aus DevOps, Data Science und Data Engineering. Es dreht sich um den Lebenszyklus von ML-Systemen: Daten, Training, Inferenz, Überwachung und vieles mehr.

Was genau macht ein MLOps-Spezialist eigentlich?

Es kommt drauf an... ML-Produkte entwickeln sich in Phasen über mehrere Monate hinweg. Sie beginnen mit datenwissenschaftlich orientierten Analysen und Experimenten und enden in einem robusten, funktionsfähigen System, das ständig verbessert wird. Im Folgenden handelt es sich um ein Echtzeit-Beispiel. Es gibt aber auch Systeme, die stattdessen Batches verarbeiten und daher einige Anpassungen der Architektur erfordern. 

Lasst uns einen genaueren Blick auf die Phasen werfen und darauf, was man als MLOps in unserem Team macht!

Phase 1: Exploration

In Phase 1 hat unser Team noch kein Produkt. Wir haben einen Anwendungsfall identifiziert, bei dem ML ein Problem lösen oder Nicht-ML-Algorithmen ersetzen könnte. Ein Beispiel dafür könnte sein, dass ein Kollege manuell angeordnete Seiten identifiziert und diese Anordnung automatisieren oder sogar personalisieren möchte.

In dieser Explorationsphase unterstützt ihr als MLOps Spezialist die Data Scientists durch das Extrahieren, Transformieren und Laden (Speichern) von Daten (ETL). Gegebenenfalls analysiert ihr diese, um "unsaubere" Daten zu identifizieren, die bereinigt werden müssen. Es wird eng mit den Data Scientists zusammengearbeitet und besprochen, welche Daten für unseren Fall zuverlässig und nützlich sind. Daher solltet ihr in der Lage sein, vorausschauend Probleme zu erkennen, die bei der Reifung des Systems auftreten könnten – zum Beispiel, wenn man von historischen Daten zur Echtzeit-Erfassung übergeht.

Je nach Team verwenden wir bei OTTO geteilte Data-Science-Plattformen oder eigene Lösungen. Daher stellt ihr vielleicht eine Umgebung bereit, in der unsere Data Scientists arbeiten und sich austauschen können. Dabei kann es sich um ein Git-Repository oder selbst gehostete Runner handeln, auf denen die Data Scientists Modelle trainieren können.

Um Phase 1 zusammenzufassen: Ein Großteil der Arbeit, die euch hier erwarten, besteht aus Data Engineering, Ops und Diskussionen über Daten.

Auf der Seite der Datenentwicklung (beige) kümmern wir uns um die Beschaffung, Umwandlung und Speicherung von Daten. Dies wird häufig durch ein Workflow-Management-Tool wie z. B. Airflow gesteuert. Bei den Data-Science-Aufgaben (rot) geht es darum, Modelle auszuprobieren und zu iterieren, bis wir einen vielversprechenden Modellansatz gefunden haben.

Es gibt eine ständige Feedbackschleife zwischen den Disziplinen und Rollen, damit sie sich gegenseitig unterstützen können.

Phase 2: Live-Schaltung

Nach der Explorationsphase gehen wir direkt zum Testen und zum Konzeptnachweis (POC) über.

Nun sollte unser Team ein trainiertes Modell haben, das wir auf jede geeignete Weise exportieren können, zum Beispiel ONNX, um es zu hosten. Das Training könnte bereits automatisiert sein, sofern es dem Team geholfen hat, in Phase 1 schneller zu testen.

Als nächstes muss die Live-Inferenz implementiert werden. Wir wollen schnell iterieren – anstatt also den perfekten Modellvalidierungszyklus zu erstellen, konzentriert ihr euch wahrscheinlich auf den Inferenzservice und das Einspeisen von Echtzeitdaten. Je nach den Anforderungen an die Latenzzeit wählt ihr die geeignete Technologie für die Inferenz (z. B. eine vorgefertigte Lösung wie NVIDIA Triton oder eine benutzerdefinierte Lösung, die gut mit Multiprocessing umgehen kann).

Das Monitoring ist wichtig, da wir ohne dieses unseren POC nicht in einem A-B-Test verifizieren können. Grafana in Kombination mit Prometheus ist für die meisten unserer Teams genau das Richtige. Ihr sammelt und visualisiert also Informationen darüber, wie gut unser Modell funktioniert, zum Beispiel Wie oft interagieren die Benutzer mit dem Ergebnis unseres Modells?, Wie groß ist das Ergebnis?, Wie schnell ist unsere Inferenz? und über unsere Leistungskennzahlen (KPI).

CI/CD wird dort eingesetzt, wo es uns hilft. Manuelle Schritte können in dieser Phase weiterhin bestehen, wenn sie keinen Engpass bei der Erstellung unseres POC darstellen.

Zum Abschluss von Phase 2 konzentrieren wir uns darauf, so schnell wie möglich echtes Feedback für unser Modell zu sammeln. Zu diesem Zeitpunkt besteht keine Notwendigkeit, die perfekte Infrastruktur zu schaffen, da wir bei einem Modell, das unsere Erwartungen nicht erfüllt, möglicherweise wieder bei null anfangen müssen.

In Phase 2 kommen zahlreiche Ops-Aufgaben hinzu. CI/CD hilft uns, unser System zu automatisieren, um es zuverlässig zu machen. Der eigentliche Inferenzserver muss hinzugefügt und überwacht werden. Die zuvor bei Bedarf durchgeführte Datenextraktion muss auf Echtzeit- oder produktiven Batchdaten ausgeführt werden. Die Daten sollten ebenfalls überwacht werden, um zu sehen, ob sich unsere Features ändern.

Phase 3: Das Produkt verbessern und am Leben erhalten

Glückwunsch, wir haben nun ein Produkt! Unser A-B-Test war erfolgreich und wir können unser Modell dauerhaft umsetzen. Aber die Arbeit ist hier noch nicht beendet, denn bei OTTO gilt: You build it, you run it.

Das bedeutet, dass wir in der dritten Phase ein Gleichgewicht finden müssen, um das alte Modell am Leben zu erhalten (Überwachung, Validierung, Training) und gleichzeitig unser Produkt zu verbessern. Verbesserung kann alles bedeuten – von der Anpassung einiger Hyperparameter bis hin zur Erstellung eines völlig neuen Modells, das ein ähnliches Problem in der Domäne unseres Teams angeht.

Zunächst konzentriert ihr euch auf einen ausgefeilten ML-Lebenszyklus. Einige Teile sind bereits automatisiert und wir müssen uns um den Rest kümmern. Das Ziel ist ein Workflow oder eine Pipeline, die Daten abruft und aufbereitet, ein Modell trainiert, es gegen das aktuelle Live-Modell evaluiert und es schließlich einsetzt (Abbildung 4).

Großartig! Nachdem die Pipeline fertig ist, ist unser System automatisiert, es ist allerdings noch kein Lebenszyklus. Es fehlt noch ein Pipeline-Trigger. Im Idealfall können wir erkennen, wann unser Modell ein neues Training benötigt (z. B. wenn sich die Daten verschieben oder die Vorhersagen ungenau werden) und unsere Pipeline unter dieser Bedingung anstoßen. Dies ist besser als ein zeitlicher Trigger, da wir nicht schätzen müssen, wann ein neues Training ansteht. Wenn das Monitoring aber noch nicht so weit ist, ist ein gut geschätzter zeitlicher Trigger jedoch ein guter Anfang.

Das war's dann, oder? Nun, wenn ihr Glück habt, haben die Data Scientists bereits drei neue Ideen in petto, aber dieses Mal fangen wir nicht bei null an. Ihr erweitert das System, macht es flexibler für verschiedene Modelltypen und verbessert die Performance, um unseren Kunden ein noch besseres Nutzererlebnis zu bieten.

Und wie lernt man das?

Interessiert? Ihr habt gelernt, dass MLOps Fähigkeiten aus verschiedenen Rollen kombiniert, von denen jede lernen kann, MLOps auszuführen. Ich, zum Beispiel, habe als DevOps angefangen und dann alles über Data Engineering gelernt, bevor ich schließlich ein wenig über ML-Modelle dazugelernt habe, um aus den Ideen und Modellen unserer Data Scientists lebendige Produkte zu schaffen.

Mein Ziel ist es, eine ideale, reibungslose Umgebung zu schaffen, damit sich unsere Data Scientists auf die Verbesserung der Modelle konzentrieren können.

Wo auch immer ihr anfangt, schaut euch nach und nach die Tools der anderen Rollen an, bis ihr euch um einen ganzen MLOps-Tech-Stack kümmern könnt. Da die Technologie sehr unterschiedlich sein kann, die Ideen aber ähnlich bleiben, möchte ich euch zeigen, was wir verwenden. Bitte bedenkt aber, dass unsere Teams unterschiedliche Tech-Stacks verwenden und dies nur Beispiele sind.

Erstens: Daten

Data-Science

Exploration und Analyse finden häufig in Python-Notebooks statt, die in Sagemaker Studio gehostet werden. Wir konzentrieren uns auf Pytorch, um die Modelle zu erstellen und zu trainieren.

Inferenz

Wir haben uns für den Einsatz von NVIDIA Triton als Inferenz-Server entschieden. Andere Teams bevorzugen benutzerdefinierte Pytorch-Implementierungen.

Ops

In unserem Team konzentrieren wir uns auf CloudFormation für IaC (Infrastructure as Code), GitHub-Actions für CI/CD und Kotlin + Spring für Front-End-Dienste. Schließlich besteht unser Monitoring-Stack aus Prometheus, Grafana und AWS Cloudwatch.