MLOps

MLOps — Was steckt dahinter?

Common Sense, die Anforderungen einer Data Science Abteilung, die nicht mehr nur experimentiert und die EU-Regulatorik legen die gleiche Schlussfolgerung nahe: Wir müssen uns mit Machine Learning Operations (MLOps) beschäftigen. Was steckt dahinter?

Der recht neue Begriff MLOps ist aus der schmerzhaften Erfahrung heraus entstanden, dass es gar nicht so einfach ist, zunächst vielversprechend aussehende KI / Machine-Learning Prototypen in einen Produktivbetrieb zu überführen, sie sinnvoll zu betreiben und weiterzuentwickeln. Es braucht eine gemeinsame Perspektive auf explorative Entwicklungsarbeit und Betrieb sowie verantwortliche Menschen dafür. So kam es analog zu DevOps zu MLOps (vereinzelt auch AIOps).

Anfänglich wurde der Data Science-Begriff nicht weiter differenziert. Im Anschluss wurde MLOps für die Betriebsherausforderung und als Zielbild verwendet, ohne dass es dedizierte Lösungsangebote gegeben hätte – weder auf organisatorischer noch auf technischer Ebene.

Mittlerweile ist der Begriff inflationär im Gebrauch für alles, was potenziell Machine Learning-Methoden einfach zugänglich macht. Dabei ist er emotional aufgeladen als Teil eines sich schnell drehenden Hypes. Andererseits (und vielleicht auch deswegen) stehen Data Science- und Data Engineering-Teams dem Begriff und seinen (vagen) Implikationen oft skeptisch gegenüber: Das sieht auf den ersten Blick kompliziert aus. Brauchen wir das wirklich?

Dazu gibt es eine Reihe von Argumenten. Wir sehen sie uns in chronologisch Reihenfolge bzw. mit wachsendem Reifegrad an.

MLOps als Design Pattern

Ein neuer Begriff dieser Art funktioniert wie andere Design Patterns (zum Beispiel “MVC” oder “ESB”) im Software Engineering auch: Er komprimiert einen facettenreichen Blick auf einen Teil eines IT-Systems mit mehreren Umsetzungsvarianten soweit, dass Fachleute mit wenigen Worten darüber reden können. Dafür muss der Begriff nicht einmal präzise definiert sein. Es genügt zunächst, wenn er als Suchbegriff funktioniert, um die Menschen mit dem entsprechendem Diskussionsbedarf in den Austausch zu bringen.

MLOps als Belohnung

Auch wenn sich zunächst MLOps-Plattformen für Data Scientistinnen nach zusätzlichem Arbeitsaufwand und zusätzlich zu beherrschender Komplexität im Vergleich zum Jupyther-Notebook anhören, so kann man diese viel sinnvoller im Sinne der mentalen Hygiene als Belohnung zu betrachten: “Herzlichen Glückwunsch – ihr PoC hat einen wichtigen Meilenstein erreicht.”
Diese in Technologie gegossenen Wertschätzung bietet dann die Möglichkeit, das eigene “Baby” groß zu machen. Um in der Bildsprache zu bleiben: Natürlich ist ein Python-Projekt in der Pubertät anstrengend. Natürlich wollen wir es dennoch erwachsen werden sehen.

Dieser Meilenstein braucht einen Namen. Anders als bei klassischer Software-Entwicklung ist die grundsätzliche Machbarkeit einer Idee nicht gesichert: Viele PoCs werden nur mit Erkenntnissen über Grenzen des Machbaren beendet. Wenn wir darüber hinaus blicken, stellen sich Betriebsfragen.

MLOps im Vergleich zu DevOps

Bis hierhin würde auch der DevOps-Begriff zutreffen. Was macht den ML-Betrieb so anders, dass es noch einen Begriff braucht? Vieles ist ähnlich. Daher ist der Begriff auch ähnlich und die MLOps-Idee baut auf der DevOps-Idee auf.

• In beiden Settings geben wir Entwicklungs- und Betriebsverantwortung zusammen an ein Team.
• In beiden Settings erhoffen wir uns schnellere Entwicklungszyklen und eine höhere Service-Qualität.
• Mit einem gewissen Volumen entsprechender Tätigkeiten lohnt es sich, hierfür dedizierte Spezialisten einzusetzen.

Tatsächlich sind auf der technischen Detail-Ebene auch viele der eingesetzten Werkzeuge ähnlich: Es geht oft um Container, Kubernetes und Pipelines. Warum ist ein DevOps-Engineer dann nicht auch gleich für MLOps zuständig?

Die wesentlichen Unterschiede von MLOps zu DevOps sind:

1. Viele ML-Projekte sind nicht deterministisch. Gleiche Inputs führen nicht zu gleichen Outputs. Ein “grüner” Integrationstest führt nicht zum gleichen Level von Sicherheit, wie er es bei einer klassischen Business-Anwendung tun würde. Das bedeutet, dass Methodenwissen und methoden- bzw. fallspezifische Mechanismen benötigt werden, um die Güte eines neuen Lerndurchlaufs zu bewerten und über einen Go-Live einer Modellversion zu entscheiden.
2. Daten verrotten mit der Zeit. Das gilt also auch für aus Daten abgeleitete Entscheidungsmodelle. Ein produktives Deployment eines ML-Modells ist folglich nur freigegeben auf Zeit und ohne das Mindesthaltbarkeitsdatum zu kennen. Es braucht regelmäßige Überwachung und es braucht Methodenwissen, um etwaige Probleme zu bemerken bzw. die Nutzung des Modells so zu orchestrieren, dass Probleme systematisch auffallen. Bei nicht-KI-Webservices wären wir hier mit einer Überwachung vom Typ “Ist der Dienst erreichbar und performant?” fertig gewesen.

MLOps als Governance-Struktur

Mit komplexen Data Science-Projekten kommen Einzelpersonen aber auch klassische Governance-Strukturen an ihre Grenzen. Daten-Analystinnen…

• installieren selbst ad hoc ausgewählte Linux-Distributionen und Container,
• kaufen GPUs für Desktop-Rechner unter dem eigenen Schreibtisch (weil die Data Center-Lizenzen zu teuer sind),
• halten diese Rechner aktuell und sicher und
• stimmen sich mit der Datenschutzverantwortlichen zur Datenverwendung ab und
• reflektieren die Sicherheit und Lizenz-Situation von mehreren hundert Software-Bibliotheken, die in einem typischen Data Science-Projekt verwendet werden?

Einzelne Testballons können so starten. Ein auf Dauer ausgelegter Betrieb einer Data Science-Abteilung kann so den Erfordernissen der DSGVO sowie den Empfehlungen von Datenschutzkonferenz und EU zum verantwortungsvollen Umgang mit Daten KI nicht gerecht werden. Weitere Schutzziele sind in Gefahr.

Die Data Mesh-Strategie sieht hier vor, einen möglichst großen Teil der Governance-Strukturen zu kodifizieren und auf diese Weise automatisch verbindlich zu machen: Ich entwickle in einer abgesicherten MLOps-Umgebung für deren Sicherheit Spezialisten verantwortlich sind und nutze vorkonfigurierte Ressourcen – weil sie sicherer sind, aber auch, weil es für die einzelne Data Scientistin einfacher ist. Die Plattform protokolliert die Nutzung von Daten und die Qualität von ML-Modellen per Default. Nur so entsteht dann eine verteilte Entscheidungskompetenz und Handlungsfähigkeit. Eine Data Science-Initiative kann hochskalieren in einer Weise, die den an sie gestellten Anforderungen dauerhaft gerecht wird.

MLOps ist sowohl eine Enabler-Technologie als auch eine Kodifizierung von Grenzen und Auditoptionen, ohne die man Technologien mit so weitreichendem Einfluss auf das Handeln und (Er-) Leben von Unternehmen und Einzelpersonen nicht verantworten möchte. Auf den Punkt gebracht: Das Ablehnen von MLOps-Prozessen impliziert das Ablehnen von Verantwortung.

Der Tätigkeitsbereich MLOps ist geprägt von Architektur-Entscheidungen. Es lohnt sich daher auch ein Blick auf die Idee der Data Science Decision Records.

MLOps als Weg aus der “KI-Erfolgsfalle” für Data Scientist:innen

Viele Data Scientist:innen sind durch Neugier motiviert. Sie mögen es, Dinge zu entdecken, auszuprobieren, zu explorieren und Potenziale aufzuzeigen. Dieses Mindset wird in Data Science-Positionen aber vor allem so lange bedient, bis der erste persönliche Erfolg stattgefunden hat. Danach leiden viele unter ihrem Erfolg. Ihr Fokus verkleinert und verändert sich:

• Wenn eine Innovation vielversprechend aussieht, wird dort mehr Zeit investiert.
• Es stellen sich für eine Produktivsetzung technische Detailfragen und Governance-Fragen, welche diese Motive nicht bedienen.
• Nach einer erfolgreichen Produktivsetzung gilt es oft die Lösung zu überwachen und viele Einzelfälle zu erklären.
• Regelmäßig finden sich Sonderfälle die zu berücksichtigen sind oder leicht abgewandelte Aufgabenstellungen auf die man die Lösung übertragen kann.
• Die so entstehende Code-Basis wird ebenso komplex wie das individuelle Fachwissen, das unterwegs aufgebaut wird.
• Wartungsarbeit fällt an.

In Summe wird es mit der Zeit immer weniger attraktiv für ein Unternehmen einer erfolgreichen Data Scientist:in neue Themen zu geben.

Wenn dieser Mechanismus einmal angelaufen ist, wird es schwer, ihn zu verlassen. Die Lösung besteht offensichtlich darin, früh vorauszudenken, dass KI-PoCs erfolgreich sein könnten und dann gleich eine Umgebung anzubieten, in der zunächst das Experimentieren leicht ist, in der aber sofort die richtigen Rahmenbedingungen herrschen, um viele Projekte in geordneten Bahnen produktiv zu setzen und zwischen verantwortlichen Data Scientist:innen übergeben zu können. Damit geben Data Scientist:innen kurzfristig etwas Gestaltungsfreiheit auf — sichern aber ihre langfristige Gestaltungsfreiheit.

Was erreicht man mit MLOps?

Die folgenden Effekte sind zu erwarten:

Einen detaillierten Einblick in MLOps-Prinzipien und unsere Erfahrungen damit geben die Aufzeichnungen der NAVIGATE-Vorträge dazu.

Die Grenzen von MLOps

Während MLOps-Tools im Marketing dazu neigen, „blühende Landschaften“ zu zeigen gibt es natürlich auch Grenzen zu berücksichtigen:

1. Eine Grenze bezüglich der Zielgruppe. Es braucht für die Einrichtung viel Cloud-, DevOps und Data Science-Skills sowie geeignete organisatorische Rahmenbedingungen und IT-Security-Skills. Für die operative Nutzung werden immer noch Python-Skills benötigt, aber eben keine langen YAML-Dateien mehr.
2. Eine Grenze nach „unten“ im Architektur-Stack: MLOps ist im Wesentlichen eine Unterstützung für die o.g. Prozesse. Das bedeutet auch: MLOps-Werkzeuge sind für Datentransformationen und Operationen auf Daten zuständig, aber nicht für die Datenhaltung. Idealerweise sind MLOps-Werkzeuge offen für möglichst viele Datenquellen-Typen.
3. Eine Grenze nach „oben“ im Architektur-Stack: Der Zuständigkeitsbereich von MLOps-Werkzeugen endet mit dem Deployment von ML-Modellen und den zugehörigen Datentransformationen und Monitoring-Maßnahmen. In unserer Erfahrung reicht das nicht aus, um KI-Modelle verantwortungsvoll einzusetzen und sinnvoll zu orchestrieren. Oft ist es notwendig bspw. Anomalien auszusteuern und durch Fachleute bewerten zu lassen. Dazu braucht es eine Steuerungsschicht oberhalb der durch MLOps / Serving-Tools bereitgestellten Web-Services. Diese Schicht kann sehr effizient durch schlanke Workflow-Engines realisiert werden, die dann nach Bedarf unsere bpmn.ai-Muster umsetzen.
4. Auch bei Cloud-Native-MLOps-Werkzeugen wie Kubeflow ist für große Datenmengen und die Zusammenarbeit im MLOps-Team noch besondere Aufmerksamkeit erforderlich.