© Enkel/Shutterstock.com
Tools und Prozesse für MLOps

Von Daten zum Modell und wieder zurück


Ein Machine-Learning-Modell zu trainieren, wird immer einfacher. Aber das Modell zu bauen und zu trainieren, ist auch der einfache Teil. Die eigentliche Herausforderung besteht darin, ein Machine-Learning-System in Produktion zu bringen und dort verlässlich zu betreiben. Im Bereich der Softwareentwicklung haben wir dazu eine wesentliche Erkenntnis gewonnen: DevOps ist nicht länger nur nice to have, sondern absolut notwendig. Warum also nicht DevOps-Werkzeuge und Prozesse auch für Machine-Learning-Projekte einsetzen?

Wenn wir unsere vertrauten Tools und Workflows aus der Softwareentwicklung für Data Science und Machine-Learning-Projekte einsetzen wollen, stoßen wir schnell auf Probleme. Data Science und das Erstellen von Machine-Learning-Modellen folgen einem anderen Prozess als der klassische Softwareentwicklungsprozess, der annähernd linear verläuft.

Wenn ich in der Softwareentwicklung einen Branch anlege, dann habe ich ein klares Ziel vor Augen, was das Ergebnis dieses Branch sein wird: Ich möchte einen Bug fixen, eine User Story entwickeln oder eine Komponente überarbeiten. Ich beginne mit der Arbeit an dieser definierten Aufgabe. Sobald ich dann meinen Code in das Versionskontrollsystem hochlade, laufen automatisierte Tests – und ein oder mehrere Teammitglieder führen eine Codereview durch. Dann drehe ich meistens nochmal eine Runde, um die Anmerkungen der Review einzuarbeiten. Wenn alle Probleme behoben sind, wird mein Branch in den Haupt-Branch integriert und die CI/CD-Pipeline läuft los; ein ganz normaler Entwicklungsprozess. Zusammenfassend kann man sagen: Ein Großteil der Branches, die ich anlege, werden auch irgendwann integriert und in eine produktive Umgebung deployt.

Im Bereich des Machine Learning und der Data Science ist das anders. Anstelle eines linearen und fast schon „mechanischen“ Entwicklungsprozesses habe ich hier einen Prozess, der sehr stark von Experimenten getrieben wird. Experimente können fehlschlagen. Das liegt in der Natur eines Experiments. Oft starte ich auch ein Experiment gerade mit dem Ziel, eine These zu widerlegen. Nun ist jedes Training eines Machine-Learning-Modells ein Experiment und ein Versuch, mit einer spezifischen Modell- und Algorithmuskonfiguration und einem Datensatz bestimmte Ergebnisse zu erzielen. Wenn wir uns vorstellen, dass wir zur besseren Übersicht jedes dieser Experimente in einem eigenen Branch verwalten, dann werden wir sehr schnell sehr viele Branches erhalten. Da ein Großteil meiner Experimente nicht zum gewünschten Ergebnis führt, werde ich viele Branches wieder verwerfen. Nur wenige meiner Experimente werden es jemals in eine produktive Umgebung schaffen. Aber dennoch möchte ich einen Überblick darüber haben, welche Experimente ich bereits durchgeführt habe und was die Ergebnisse waren, um diese in Zukunft reproduzieren und weiterverwenden zu können.

Das ist aber nicht der einzige Unterschied zwischen der klassischen Softwareentwicklung und der Entwicklung von Machine-Learning-Modellen. Ein weiterer Unterschied ist das zeitliche Verhalten.

ML-Modelle werden mit der Zeit schlechter

Klassische Software funktioniert nach einem Monat noch genauso gut wie am ersten Tag. Natürlich kann es zu veränderten Anforderungen an Speicher- und Rechenkapazität kommen und natürlich werden Bugs auftreten, aber die grundlegenden Verhaltenscharakteristika der produktiven Software ändern sich nicht. Bei Machine-Learning-Modellen ist das anders. Bei diesen nimmt die Qualität über die Zeit ab. Ein Modell, das in einer produktiven Umgebung arbeitet und nicht nachtrainiert wird, wird sich über die Zeit verschlechtern und nie eine so gute Vorhersagegenauigkeit wie am ersten Tag erreichen.

Schuld ist der Concept Drift [1]. Die Welt außerhalb unseres Machine-Learning-Systems ändert sich und damit ändern sich auch die Daten, die unser Modell als Eingabewerte erhält. Dabei treten verschiedene Arten von Concept Drift auf: So können sich Daten graduell ändern, wenn beispielsweise ein Sensor über einen längeren Zeitraum durch Verschleiß ungenauer wird und eine immer höhere Abweichung zum eigentlichen Messwert zeigt. Auch zyklische Ereignisse wie Jahreszeiten oder Feiertage können eine Auswirkung haben, wenn wir mit unserem Modell Verkaufszahlen vorhersagen wollen.

Aber Concept Drift kann auch sehr abrupt auftreten: Wenn der weltweite Flugverkehr durch COVID-19 zum Erliegen kommt, dann wird unser sorgsam trainiertes Modell zur Vorhersage des täglichen Passagieraufkommens schlechte Ergebnisse liefern. Oder wenn die Sales-Abteilung ohne Vorankündigung eine Instagram-Werbeaktion startet, die zu einer Verdoppelung der Käufer unseres Vitaminpräparats führt, so ist das zwar ein gutes Ergebnis, aber nichts, was unser Modell gut vorhersagen kann.

Dieser Verschlechterung der Vorhersagequalität kann man auf zwei Arten entgegenwirken: Entweder wir befähigen unser Modell, sich selbst aktiv in der produktiven Umgebung neu zu trainieren, oder wir müssen unser Modell häufig updaten. Oder besser noch: so oft updaten, wie es irgendwie geht. Vielleicht haben wir auch eine notwendige Anpassung an einem Algorithmus durchgeführt oder ein neues Modell eingeführt, das möglichst schnell ausgerollt werden soll.

In unserem Machine-Learning-Workflow haben wir also nicht nur das Ziel, Modelle zum User zu liefern. Unser Ziel muss es vielmehr sein, Infrastruktur zu bauen, die unser Team schnell darüber informiert, wenn ein Modell falsche Vorhersagen liefert, und das Team in die Lage zu versetzen, schnellstmöglich ein neues, besseres Modell in die produktiven Umgebungen zu heben.

MLOps als DevOps für Machine Learning

Wir haben gesehen, dass Data Science und das Erstellen von Machine-Learning-Modellen einen anderen Prozess erfordern als die klassische, „lineare“ Softwareentwicklung. Außerdem ist es notwendig, dass wir bei der Entwicklung von Machine-Learning-Modellen eine hohe Iterationsgeschwindigkeit erreichen, um so dem Concept Drift entgegenzuwirken. Aus diesem Grund ist es notwendig, dass wir einen Machine-Learning-Workflow und eine Machine-Learning-Plattform erstellen, die uns bei diesen beiden Anforderungen unterstützen. Hier handelt es sich um einen Satz aus Tools und Prozessen, die für unseren Machine-Learning-Workflow das sind, was DevOps für die Softwareentwicklung ist: ein Prozess, der schnelle, aber kontrollierte Iteration in der Entwicklung ermöglicht, die von Continuous Integration, Continuous Delivery und Continuous Deployment unterstützt werden. So können wir schnell und kontinuierlich qualitativ hochwertige Machine-Learning-Systeme in den produktiven Betrieb bringen, ihre Leistung überwachen und auf Änderungen reagieren. Diesen Prozess nennen wir MLOps [2] oder CD4ML (Continuous Delivery for Machine Learning) [3].

MLOps bietet uns darüber hinaus noch weitere Vorteile: Durch reproduzierbare Pipelines und versionierte Daten schaffen wir Konsistenz und Wiederholbarkeit im Trainingsprozess sowie in produktiven Umgebungen. Das sind notwendige Voraussetzungen, um geschäftskritische ML Use Cases umzusetzen und das Vertrauen aller Beteiligten in die neue Technologie herzustellen.

Im Unternehmensumfeld haben wir eine ganze Reihe von Anforderungen, die es neben dem eigentlichen Use Case umzusetzen ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang