Seit einigen Jahren sind KI- bzw. Machine Learning-Anwendungen in aller Munde und zunehmend erobert diese Technologie immer mehr Branchen. Die Algorithmen sowie Menge und Qualität der verfügbaren Daten für Machine-Learning-Modelle sind bereits fortgeschritten. Doch die Professionalisierung des operativen Betriebs hinkt hinterher. Mittlerweile hat sich ein neuer Ansatz etabliert, um den produktiven Einsatz von Machine Learning zu erleichtern – MLOps, zusammengesetzt aus Machine Learning (ML) und Operations (Ops). MLOps ist eine Sammlung von Methoden und Software-Tools, mit dem Zweck, den operativen Betrieb von KI-Anwendungen zu gewährleisten. Wir klären rund um das Thema MLOps auf und adressieren diese Kernfragen:

• Was bedeutet MLOps im Detail?
• Wie grenzt sich MLOps von DevOps ab?
• Was sind die Herausforderungen des operationalen Betriebs von ML Produkten, die mit MLOps gelöst werden?

Was genau ist MLOps?

Die professionelle Nutzung von Machine Learning weitet sich immer aus: Bereits über 50 Prozent der Unternehmen setzen Machine Learning produktiv ein. Parallel machen Unternehmen sowie involvierte Data Scientists, Engineers und Produktmanager die Beobachtung, dass sich der produktive Betrieb als anspruchsvoll erweist, meist herausfordernder als erwartet. Gartner hat ermittelt, dass es 2022 nur 54% der ML-Projekte in den Produktionsbetrieb geschafft haben [1]. Und auch falls der produktive Betrieb gelingt, ist die Time-to-market bis dahin hoch: in fast der Hälfte aller Fälle verbringen Teams mehr als 30 Tage, um ein fertiges Modell in Produktion zu bringen [2].

Die Antwort auf die ineffektive Entwicklung von ML-Produkten lautet MLOps. MLOps ist eine Sammlung von Methoden und Technologien, um die Entwicklung von Machine Learning Modellen sowie den operativen Betrieb darauf basierender Produkte effizient zu gestalten. Bei der Entwicklung eines ML-Produkts wird zwischen 3 Schritten unterschieden:  Design, Build und Run.

Durch ausgereifte Frameworks für Datenverarbeitung (Pandas, Spark und co.), Machine Learning (PyTorch, Scikit-Learn etc.) und Cloud-Angebote sind die ersten zwei Schritte heutzutage bei geringer bis mittlerer Komplexität eines ML-Produkts gut beherrschbar. Danach entstehen jedoch die wahren Herausforderungen. Das deployte Modell muss überwacht, gewartet und optimiert werden. Und nach “Abschluss” der Entwicklung eines ersten ML-Produkts stehen oft schon Pläne für die nächsten ML-Produktideen in den Startlöchern. Somit nimmt der Aufwand abseits der reinen Entwicklung von Data Pipelines und Machine Learning stetig zu. Die Koordinierung wachsender Teams und die Wahrung von Compliance stehen einer erfolgreichen Skalierung des Einsatzes von Machine Learning zusätzlich im Weg.

Developing and deploying ML systems is relatively fast and cheap, but maintaining them over time is difficult and expensive.

D. Sculley et al., “Hidden Technical Debt in Machine Learning Systems, 2015

MLOps-Methoden und –Software sind folglich Lösungen, um technische Schulden (eng. “technical debt”) abzubauen, die durch ML-Produkte verursacht werden. Am wichtigsten ist, zu verinnerlichen, dass bei MLOps-Methoden und effektive Zusammenarbeit im Fokus stehen und die Wahl des Tech-Stacks zweitrangig ist. Der Schlüssel zum Erfolg lautet, ab dem Start der Entwicklung eines ML-Modells (Design-Phase) bereits eine konkrete Vorstellung zu haben, wie das Modell operationalisiert werden soll. Oder mit anderen Worten: Die MLOps-Methodologie wird idealerweise von Anfang des Projekts an angewandt.

Benötigen Sie Unterstützung bei Ihren MLOps-Projekten? Vom Training über die Reifegradanalyse bis zur vollständigen Entwicklung und Pflege von MLOps-Produkten bietet die Alexander Thamm GmbH seinen Kunden ein weites Spektrum von Dienstleistungen im Bereich MLOps an. Informieren Sie sich auf unserer Dienstleistungsseite und kontaktieren Sie uns jederzeit für eine unverbindliche Beratung:

MLOps-Plattformen helfen, die Zusammenarbeit der Teams zu steigern, Vorgaben aus Regulatorik und Compliance einzuhalten und die Time-to-Market zu reduzieren. Erfahren Sie mehr in unserem Deep Dive zum Thema:

MLOps Plattform – Aufbau, Skalierung und Operationalisierung

Welche Herausforderungen löst MLOps?

Wenn MLOps dazu gedacht ist, technische Schulden zu verringern, was genau ist damit gemeint? Wir verstehen darunter organisatorische und technologische Hindernisse, die sich negativ auf Produktivität und Kosten auswirken, jedoch vermeidbar sind. Dies sind die elementaren wiederkehrenden Probleme bei der Operationalisierung von Machine Learning:

Ausufernder manueller Aufwand für Training und Wartung

Ein ML-Modell basiert i.d.R. auf Daten aus der realen Welt und ändert sich konstant. Daher veralten ML-Modelle rapide und ein regelmäßiges erneutes Training ist notwendig. In einem nicht optimierten Umfeld kann der resultierende Aufwand signifikante Mengen an Arbeitszeit binden. Denken wir uns ein fiktives Beispiel aus: ein Team von Data Scientists und Engineers verbringt ca. 20h monatlich damit, ein einzelnes im Betrieb befindliches ML-Modell zu pflegen. Dieser Aufwand ist bedingt durch einen niedrigen Grad an Automatisierung von Data-Processing, Model Tuning und Deployment neuer Models. Das ML-Produkt selbst ist ein Erfolg und es wird später ein zweites ML-Produkt samt Modell eingeführt. Durch fehlende Automatisierung und Synergien sind es nun schon 40h monatlicher Aufwand. Damit sind übrigens Pflege und Wartung der ML-Modelle im engen Sinne gemeint. Die 20h bzw. 40h monatlich fließen also mitnichten in die Verbesserung von Produkten – es geht ausschließlich darum, den Status Quo aufrecht zu erhalten. Denkt man diese Situation weiter, würde der reine Betrieb weiterer Modelle irgendwann eine komplette Arbeitskraft binden, bis hin zu einem Zustand, in dem keinerlei Kapazität für die Neu- und Weiterentwicklung von ML-Produkten mehr verfügbar ist.

Es gilt auch zu bedenken, dass die Automatisierung in der Machine Learning Entwicklung eine dokumentierende Wirkung hat, so wie es auch auf DevOps-Tools zutrifft. Selbst wenn eine Gruppe von ML-Produkten von einer Hand voll Teammitgliedern verwaltet werden kann, wird dies auch noch weiter funktionieren, sobald diese Mitglieder ausfallen oder das Projekt verlassen (Stichwort “Bus factor”)?

Mangelnde Kosteneffizienz beim ML-Training und ML-Betrieb

Machine Learning kann teuer werden, vor allem dann, wenn es GPU-basiert ist. Vier- bis fünfstellige monatliche Beträge für Rechenkapazitäten für Model-Training und –Betrieb sind bei größeren Organisationen die Regel. Umso ärgerlicher ist es, wenn durch eine ineffektive Architektur oder ein fehlerhaftes Setup Hardware-Ressourcen verschwendet werden. Einsparpotenziale verstreichen somit ungenutzt. Typische Auslöser sind GPU-Instanzen, die aufgrund ineffektiver Skalierung untätig laufen oder redundantes Training von Modellen, obwohl keine Veränderung der Input-Daten oder -Parameter vorliegen. Auch in einer On-Prem-Infrastruktur kann dieses Problem auftreten, was sich dann in Verschwendung knapper Rechenzeit äußert.

Fehlende Kenntnis, wie erfolgreich ein ML-Modell performt

ML-Modelle sind stochastisch, nicht deterministisch. Die zugrundeliegenden Daten veralten rasch (Data Drift) und es muss fortlaufend überwacht werden, ob die produzierten Vorhersagen der geforderten Güte entsprechen, vor allem zwischen Modell-Updates (Model Drift). In jedem Fall müssen KPIs definiert werden, die die Performance eines ML-Produkts quantifizieren. Dies können klassische Aussagen über die Genauigkeit wie Spezifizität oder Sensitivität sein, falls ermittelbar. Alternativ kommen auch Klickzahlen, Engagement-Rate, Menge an Incidents etc. in Frage.

Solange nur wenige Modelle in Betrieb sind und deren Performance nach Deployment neuer Modelle ausreichend manuell erfasst werden können, ist nicht zwingend Automatisierung an dieser Stelle notwendig. Sobald jedoch die Menge der produktiv eingesetzten Modelle oder die Deployment-Frequenz ansteigt, wird automatisiertes Monitoring der Performance notwendig – oder wir sind zurück bei Problem 1 und der manuelle Aufwand erreicht ein untragbares Ausmaß.

Unklare Zuständigkeiten und mangelnde Effizienz bei der Zusammenarbeit

Dieses Problem ist organisatorischer Natur. Ein Team um ein frisches ML-Produkt kann mit wenigen Leuten beginnen, Daten aufzubereiten und ML-Modelle zu trainieren. Für diese und alle folgenden Prozesse müssen die Zuständigkeiten klar definiert sein, oder es kommen zahlreiche Fragen auf, z. B.:

• Wer kümmert sich um den operativen Betrieb des Modells?
• Wer stellt sicher, dass ein Modell den Anforderungen entspricht, sowohl zum Launch als auch 6 Monate später? Falls die Anforderungen überhaupt im Vorfeld klar definiert wurden.
• Wer überprüft, ob die für das Training gelieferten Daten von einer DB oder API vollständig und korrekt sind?

Auch im Zeitalter von DevOps und co. passiert es nur zu häufig, dass Data Scientists ihre trainierten Modelle über den metaphorischen Zaun werfen und kaum in den produktiven Betrieb eingebunden sind. In cross-funktionalen Teams ist es wichtig, dass Zuständigkeiten eindeutig geregelt sind. Zudem sollten über alle ML-Produkte hinweg möglichst einheitliche Tech-Stacks zum Einsatz kommen, also identische Tools für Versionierung, Artefakt-Storage, Auslieferung des Modells, etc. Denn sonst muss jedes Team seine Tools zeitintensiv selbst managen.

Unsicherheit ob der Einhaltung von Compliance-Maßnahmen und der DSGVO

Jedes Unternehmen muss externe Regularien wie die europäische Datenschutzgrundverordnung (DSGVO) sowie interne Compliance-Richtlinien erfüllen. Ungünstigerweise werden Beauftragte für Compliance und Datenschutz oft erst spät oder nie in den Prozess der Produktentwicklung eingebunden. Sobald Unklarheit aufkommt, ob ein ML-Produkt alle relevanten Regelungen einhält, muss im Worst Case sein Einsatz gestoppt werden, selbst wenn tatsächlich kein Verstoß vorliegt. Insbesondere wenn ein Produkt außer Betrieb genommen werden muss, bis die Einhaltung von gesetzlichen Regelungen geprüft ist, können Umsatz- und Produktivitätsverluste enorm ausfallen. Hier muss klar benannt werden, dass Technologie allein diese Anforderungen nicht lösen kann. Nur ein Mensch kann beurteilen, ob ein ML Produkt Anforderungen der DSGVO oder branchenspezifische Regelungen erfüllt oder nicht. Ein einheitlicher Tech-Stack ermöglicht jedoch eine schnellere Evaluierung der Compliance als 10 individuelle Lösungen für 10 ML-Produkte. Wenn eine homogene ML-Infrastruktur vorliegt sowie Compliance- und Datenschutzbeauftragte frühzeitig eingebunden sind, werden Entscheidungsprozesse verkürzt und Compliance-Risiken minimiert.

Fazit

Organisationen, die beabsichtigen, mehrere ML-Produkte zu betreiben, sollten frühestmöglich konsequent die MLOps-Philosophie anwenden, am besten von Anfang an. Die nachträgliche Umsetzung von MLOps ist zwar machbar, wird aber komplexer. Doch egal ob von Anfang an oder erst später: Organisationen, die MLOps anwenden, erzielen signifikante Verbesserungen ihres Projekts – und zwar in 97 Prozent der Fälle [3]. Die regulatorischen Hürden steigen indes wohl bald stark an. 2023 oder 2024 wird voraussichtlich die EU-weite “KI-Verordnung“ in Kraft treten. Spätestens dann ist Compliance nicht mehr nur eine abstrakte Anforderung, sondern entspricht einer konkreten Rechtsgrundlage, der jedes kommerziell genutzte ML-Produkt entsprechen muss.

Doch wie wird MLOps in der Praxis umgesetzt? Wie Teams MLOps sinnvoll implementieren, welche Tools es dafür braucht, und welche weniger – das erfahren Sie bald im zweiten Teil unseres MLOps-Specials.

Begriffe: DevOps vs. DataOps vs. MLOps

Zum Thema Operations und Machine Learning ist ein regelrechtes Begriffs-Wirrwarr entstanden. Wir ordnen die Begriffe an dieser Stelle ein.

• DevOps: Beschreibt das Zusammenrücken von Development (Dev) und Operations (Ops) mithilfe von Praktiken, die den Aufwand reduzieren, Änderungen an einer Software in den produktiven Betrieb zu überführen. Für DevOps kommen in der Praxis Techniken wie Container, Infrastructure-as-code und Continuous Integration (CI) zum Einsatz. DevOps beschreibt allgemeine Methoden für hohe Effizienz im Betrieb von Software und ist nicht speziell auf Machine Learning, KI oder Verarbeitung großer Datenmengen zugeschnitten.
• DataOps: DataOps umfasst alle Methoden von DevOps, erweitert um Methoden rund um die effiziente Verarbeitung und Integration von (großen) Datenmengen. Darunter fallen typischerweise die Implementierung von Data Pipelines, inkl. Monitoring der Pipelines sowie Incident Handling. Der Begriff “DataOps” findet weniger Verwendung, da sich stattdessen “MLOps” als Stichwort durchgesetzt hat, um die operativen Aspekte des Machine Learnings und der dafür benötigten Verarbeitung von Daten zu beschreiben.
• MLOps: Eine Sammlung von Methoden und Tools für die effiziente Erstellung bzw. operativen Betrieb von Machine Learning Modellen und darauf basierender Produkte. Somit inkludiert MLOps alle Aspekte von DevOps und DataOps und ist folglich die komplexeste dieser Disziplinen.

Daneben finden sich im Web und vereinzelt in der Literatur Begriffe wie “ModelOps” oder “AIOps”. Diese können als äquivalent zu MLOps betrachtet werden.

Quellen:

[1] https://www.gartner.com/en/newsroom/press-releases/2022-08-22-gartner-survey-reveals-80-percent-of-executives-think-automation-can-be-applied-to-any-business-decision 
[2] https://cdn2.hubspot.net/hubfs/2631050/0284%20CDAO%20FS/Algorithmia_2020_State_of_Enterprise_ML.pdf , p.12
[3] https://pages.barc.de/hubfs/Marketing/Reports/Report_Driving-Innovation-with-AI.pdf, p.10 
[4] Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. In Advances in Neural Information Processing Systems