MLOps für Unternehmen: Vom Pilotmodell zur Produktion

MLOps für Unternehmen: Vom Pilotmodell zur Produktion

MLOps umfasst die Verfahren, mit denen ein Machine-Learning-Modell aus dem Notizbuch eines Data Scientists in die Praxis gelangt und zuverlässig bleibt, sobald echte Nutzer und echte Daten damit interagieren. Für ein Unternehmen bedeutet das versionierte Daten und Modelle, automatisierte Pipelines, kontrollierte Releases, Monitoring und klar geregelte Verantwortlichkeiten. AWS beschreibt dies als Verfahren, die ML-Workflows und -Bereitstellungen automatisieren und vereinfachen und die Entwicklung von ML-Systemen mit deren Bereitstellung und Betrieb zusammenführen.

Die meisten Unternehmen haben keine Schwierigkeiten, ein vielversprechendes Modell zu entwickeln. Schwierigkeiten bereitet ihnen, es bereitzustellen, zu überwachen, neu zu trainieren und gegenüber Prüfern zu erklären. Dieser Leitfaden behandelt den Ablauf eines produktiven ML-Lebenszyklus, die Bewertung Ihres Reifegrads, die wichtigsten Verfahren sowie die Auswahl eines passenden Ansatzes, ohne mehr Plattform zu kaufen, als Sie benötigen.

Wichtigste Erkenntnisse

• MLOps überträgt die Disziplin der Softwareentwicklung auf ML. Gleichzeitig muss MLOps auch sich verändernde Daten und Modelle verwalten – nicht nur sich verändernden Code.
• Betrachten Sie den Reifegrad als Stufenmodell. Die meisten Teams profitieren zunächst stärker von der Automatisierung von Training und Bereitstellung, als wenn sie am ersten Tag eine vollständige Plattform einführen.
• Sicherheit, Audit-Trails und Pläne für ein Rollback gehören von Anfang an in die Pipeline und nicht erst in eine abschließende Prüfung.
• Wählen Sie Tools nach ihrem Typ – Open Source, Managed Cloud oder hybrid – und berücksichtigen Sie dabei Ihre bestehende Cloud, die Kompetenzen Ihres Teams und Ihre Compliance-Anforderungen.
• Beginnen Sie mit einem für das Geschäft wichtigen Modell, gestalten Sie seinen Weg in die Produktion wiederholbar und nutzen Sie diesen Weg anschließend erneut.

Inhaltsverzeichnis

• Was MLOps für ein Unternehmen bedeutet
• Der produktive ML-Lebenszyklus Schritt für Schritt
• Wo stehen Sie? Eine Prüfung des MLOps-Reifegrads
• MLOps-Best Practices, die sich in der Produktion bewähren
• Vergleich der Ansätze für MLOps-Plattformen
• So wählen Sie einen Ansatz, der zu Ihrem Unternehmen passt
• Der geschäftliche Nutzen einer richtigen Umsetzung
• Wie wir Sie unterstützen können
• FAQ
• Quellen

Was MLOps für ein Unternehmen bedeutet

Ein herkömmlicher Webservice muss ausfallsicher sein und Last bewältigen. Ein Modell steht vor denselben Herausforderungen und vor weiteren. Der Leitfaden für MLOps in der Praxis von Google weist darauf hin, dass bei der Bereitstellung eines Modells auch Veränderungen an den Daten und am Modell sowie Nutzer berücksichtigt werden müssen, die versuchen, das System zu manipulieren. Code, der sich nicht verändert hat, kann im nächsten Quartal dennoch schlechtere Vorhersagen liefern, weil sich die Welt verändert hat.

Deshalb ist eine standardmäßige DevOps-Pipeline notwendig, aber nicht ausreichend. Derselbe Leitfaden nennt die Vorteile einer Standardisierung des Prozesses: kürzere Entwicklungszyklen, bessere Zusammenarbeit, höhere Zuverlässigkeit und Sicherheit, eine effizientere Governance und eine bessere Rendite von ML-Projekten.

Auf Unternehmensebene treten schnell drei Herausforderungen auf:

• Viele Modelle, viele Teams. Ohne gemeinsame Standards entwickelt jedes Team seinen eigenen Bereitstellungsweg, und niemand kann beantworten, welche Modellversion wo ausgeführt wird.
• Regulierte oder sensible Daten. Jemand muss nachweisen können, woher die Trainingsdaten stammen und wer einen Release genehmigt hat.
• Betriebliche Verantwortung. Ein Modell, dessen Leistungsabfall unbemerkt bleibt, ist ein Geschäftsproblem und kein Data-Science-Problem. Jemand im Bereitschaftsdienst muss dafür verantwortlich sein.

MIT Technology Review MIT Technology Review stellt den zentralen Nutzen als Automatisierung der wiederholbaren Schritte von Entwicklung und Training bis hin zu Bereitstellung und Betrieb dar. Dadurch werden Risiken reduziert und Entwickler von Routineaufgaben entlastet. Im selben Artikel wird eine McKinsey-Studie aus dem Jahr 2021 zitiert, der zufolge Unternehmen, die KI erfolgreich skalieren, ihre Ergebnisse vor Zinsen und Steuern um bis zu 20 Prozent steigern können.

Der Lebenszyklus von ML in der Produktion, Schritt für Schritt

Jeder große Cloud-Anbieter veröffentlicht eine Referenzarchitektur, und sie weisen alle dieselbe Grundstruktur auf. Microsofts MLOps-v2-Architektur führt von der Datenlandschaft und Administration über die Modellentwicklung und Modellregister bis hin zu Staging und Tests sowie der Bereitstellung und Überwachung in der Produktion. Auslöser können ein Modell erneut trainieren und es wieder in das Staging oder die Entwicklung zurückführen.

Googles Leitfaden für Continuous Delivery und Automatisierung gliedert die Arbeit in sechs Phasen. Hier sind sie in einfachen Worten:

1. Entwicklung und Experimentieren. Datenwissenschaftler testen Features, Algorithmen und Parameter. Das Ergebnis ist Quellcode für eine Pipeline, nicht nur ein Notebook.
2. Continuous Integration der Pipeline. Änderungen am Pipeline-Code werden automatisch erstellt und getestet.
3. Continuous Delivery der Pipeline. Die Pipeline selbst wird in der Zielumgebung bereitgestellt.
4. Automatisierte Auslösung. Das Training wird nach einem Zeitplan, bei neuen Daten oder aufgrund eines Leistungssignals ausgeführt.
5. Continuous Delivery des Modells. Das trainierte Modell wird als Vorhersagedienst bereitgestellt.
6. Überwachung. Aktuelle Statistiken zur Modellleistung fließen in den nächsten Zyklus zurück.

Ein akademisches Rahmenwerk für das Management des Unternehmensmodelllebenszyklus fügt einen wichtigen Punkt hinzu: ML in der Produktion ist iterativ und ereignisgesteuert statt sequenziell und endgültig. Der letzte Schritt lautet nicht „Bereitstellen“. Er lautet: überwachen, lernen, erneut trainieren oder außer Betrieb nehmen. Planen Sie auch die Außerbetriebnahme ein, denn ein nicht betreutes Modell, das niemand abzuschalten wagt, stellt eine Belastung dar.

Was Sie vor einer Veröffentlichung dokumentieren sollten

Googles Leitfaden für den Produktiveinsatz ist erfreulich praxisorientiert. Für die Bereitstellung sollten Teams Folgendes schriftlich festhalten:

• die erforderlichen Genehmigungen für den Beginn der Bereitstellung
• wie ein Modell in die Produktion überführt wird
• wo es zuerst bereitgestellt wird (Staging- oder Canary-Umgebungen)
• was zu tun ist, wenn eine Bereitstellung fehlschlägt
• wie ein bereits in der Produktion eingesetztes Modell zurückgesetzt wird

Wenn Ihr Team heute für Ihr wichtigstes Modell diese fünf Punkte nicht beantworten kann, haben Sie Ihr erstes MLOps-Projekt gefunden.

Wo stehen Sie? Eine Prüfung des MLOps-Reifegrads

Reifegradmodelle helfen Ihnen, den nächsten Schritt statt des endgültigen Ziels auszuwählen. Microsofts MLOps-Reifegradmodell definiert fünf Stufen:

AWS bietet in seiner MLOps-Grundlagen-Roadmap: Initial, Wiederholbar, Zuverlässig und Skalierbar. In dieser Roadmap umfasst die Phase „Wiederholbar“ automatisierte Pipelines und eine Modellregistrierung, „Zuverlässig“ ergänzt automatische Tests in einer isolierten Staging-Umgebung mit manuellen Genehmigungen für die Freigabe, und „Skalierbar“ nutzt Vorlagen, um die Entwicklungszeit von Wochen auf Tage zu verkürzen.

Zwei ehrliche Beobachtungen aus der Praxis. Erstens benötigt nicht jedes Modell Level 4. Ein vierteljährliches Prognosemodell, das ein Finanzteam manuell prüft, kann auf Level 2 ausreichen, während ein Betrugsmodell, das Live-Transaktionen bewertet, ein höheres Level anstreben sollte. Zweitens funktioniert das Überspringen von Levels selten. Automatisiertes Retraining auf nicht nachvollziehbaren Daten automatisiert lediglich die Verwirrung.

MLOps-Best Practices, die sich in der Produktion bewähren

Best Practices sind nur dann nützlich, wenn sie am Montag das Handeln des Teams verändern. Für Unternehmen sind dies die wichtigsten, gruppiert nach der Frage, die sie beantworten.

Können wir sicher ausliefern und zurückrollen?

• Versionieren Sie Daten, Code und Modelle gemeinsam, damit jede Vorhersage auf die exakten Artefakte zurückgeführt werden kann, durch die sie erzeugt wurde.
• Führen Sie Modelle über Staging- und Canary-Umgebungen ein, mit einer namentlich benannten genehmigenden Person für die Produktion.
• Halten Sie einen getesteten Rollback-Pfad bereit. Das Zurückrollen eines Modells sollte genauso routinemäßig sein wie das Zurückrollen eines Anwendungs-Releases.
• Verwenden Sie einen Checklistenansatz. Die MLOps-Checkliste von AWS deckt neun Bereiche ab: Datenmanagement, Experimentierung, Observability, Pipelines, Continuous Integration, Monitoring, Bereitstellung, Training und Governance. Sie eignet sich gut als Lückenanalyse, bevor Sie etwas kaufen.

Ist es sicher?

Modell-Pipelines vergrößern die Angriffsfläche, die bei herkömmlichen Sicherheitsprüfungen von Anwendungen übersehen werden kann. Das OpenSSF-MLSecOps-Whitepaper warnt, dass ungesichertes MLOps Systeme Datenvergiftung, gegnerischen Angriffen auf Modelle und Schwachstellen in Open-Source-Bibliotheken aussetzt. Es empfiehlt, Pipelines bereits ab der Planungsphase abzusichern und Sicherheit als gemeinsame Verantwortung von ML-Entwicklern, Sicherheitsexperten und Betriebsteams zu behandeln. Zu den Kontrollen gehören sichere Tools, Patch-Management und Zugriffskontrollen nach dem Prinzip der geringsten Berechtigung.

Auf der Container-Seite empfiehlt Microsofts AKS-Leitfaden für MLOps das Scannen von Open-Source-Container-Images für Modelle auf bekannte Schwachstellen sowie die Aufbewahrung von Audit-Trails zu aufgenommenen Daten und Modelländerungen. Derselbe Leitfaden verweist auf die Unterstützung von Frameworks wie SOC 2, HIPAA und DSGVO, sofern diese auf Sie zutreffen.

Können wir es erklären und verwalten?

Governance scheitert, wenn sie ein Dokument statt eines Pipeline-Schritts ist. Integrieren Sie sie direkt:

• eine Modellregistrierung, die Eigentümer, die Herkunft der Trainingsdaten, Bewertungsergebnisse und den Genehmigungsstatus erfasst
• automatisierte Prüfungen, die die Freigabe blockieren, wenn die Bewertungsschwellenwerte nicht erreicht werden
• regelmäßige Überprüfungen der überwachten Modelle, mit einer namentlich benannten verantwortlichen Person für jedes Modell
• ein Verfahren zur Außerbetriebnahme, damit Modelle nach dem Ende ihres Zwecks nicht weiterlaufen

Wenn Ihre Modelle Entscheidungen über Personen beeinflussen oder EU-Nutzern zugänglich sind, können Vorschriften für Sie gelten. Unsere eigenen Ausarbeitungen zu der Governance agentenbasierter KI und der Bereitschaft für den EU-KI-Rechtsakt zeigen, wie Kontrollen mit automatisierten Entscheidungen Schritt halten müssen. Lassen Sie von Ihrer Rechtsberatung bestätigen, welche Pflichten für Ihre konkreten Systeme gelten.

Ansätze für den Vergleich von MLOps-Plattformen

Es gibt keine einzelne beste Plattform, und ein Vergleich anhand einzelner Funktionen ist in der Regel nicht der richtige erste Schritt. Beginnen Sie mit den Fähigkeiten, die jedes Unternehmen benötigt, und prüfen Sie anschließend, welcher Ansatz sie für Ihr Team mit dem geringsten operativen Aufwand bereitstellt. Zu den Kernfunktionen gehören das Nachverfolgen von Experimenten, die Versionierung von Modellen, die Orchestrierung von Pipelines sowie das Bereitstellen und Überwachen von Modellen.

Die Ansätze lassen sich in drei grobe Typen einteilen:

Der häufigste Fehler besteht darin, „kostenlos“ mit „günstig“ gleichzusetzen. Open-Source-Tools verursachen keine Lizenzgebühren, aber Sie betreiben weiterhin Cluster, aktualisieren Komponenten und müssen jemanden beschäftigen, der sie versteht. Der umgekehrte Fehler besteht darin, anzunehmen, dass ein verwalteter Dienst den Bedarf an Engineering beseitigt: Sie entwerfen weiterhin die Pipelines, Tests und Freigabestufen. Die Preise für verwaltete Dienste ändern sich häufig. Bestätigen Sie daher die aktuellen Tarife auf der jeweiligen Preisseite des Anbieters, bevor Sie eine Wirtschaftlichkeitsbetrachtung erstellen.

So wählen Sie einen Ansatz, der zu Ihrem Unternehmen passt

Wir empfehlen, diese Schritte der Reihe nach durchzugehen.

1. Erfassen Sie den vorhandenen Bestand. Listen Sie Ihre Modelle auf, wer für sie verantwortlich ist, wo sie ausgeführt werden und wie sie derzeit bereitgestellt werden. Die meisten Unternehmen stellen fest, dass es mehr nicht offiziell erfasste Modelle gibt als erwartet.
2. Richten Sie sich nach Ihrer Cloud und der Datenbindung. Wenn Ihre Daten in einer Cloud liegen, verringern die nativen Dienste dieser Cloud in der Regel den Integrationsaufwand. Die Übertragung großer Datenmengen ist ein eigenes Projekt.
3. Stimmen Sie die Tools auf die Kompetenzen Ihres Teams ab. Eine Plattform, die Kubernetes-Kenntnisse erfordert, ist für ein Team ohne diese Kenntnisse und ohne Einstellungsplan eine schlechte Wahl.
4. Listen Sie unverzichtbare Kontrollen auf. Audit-Trails, Zugriffskontrolle, Datenresidenz und Genehmigungs-Workflows ergeben sich aus Compliance und Sicherheit, nicht aus der Funktionsliste des Anbieters.
5. Wählen Sie ein besonders wertvolles Modell als Pilotprojekt aus. Bauen Sie seinen Weg bis zur Produktion vollständig auf, messen Sie die Release-Zeit und die Incident-Rate und machen Sie diesen Weg anschließend zu einer Vorlage, die andere Teams wiederverwenden.
6. Prüfen Sie die Interoperabilität. Bevorzugen Sie Komponenten mit offenen Formaten und APIs, damit der spätere Austausch eines einzelnen Bausteins nicht bedeutet, alles neu aufbauen zu müssen.
7. Schätzen Sie die Gesamtbetriebskosten. Berücksichtigen Sie Infrastruktur, Lizenzen, Engineering-Aufwand und die Kosten von Modell-Ausfallzeiten.

Ein Pilotprojekt liefert Ihnen außerdem etwas, das bei Plattformentscheidungen selten ist: Erkenntnisse aus Ihrer eigenen Umgebung statt einer Anbieterdemo.

Der geschäftliche Nutzen der richtigen Entscheidung

Der Nutzen von MLOps zeigt sich an einigen Kennzahlen, die Führungskräfte bereits verfolgen: eine kürzere Zeit von der genehmigten Idee bis zur Produktion, weniger durch degradierte Modelle verursachte Incidents, weniger doppelte Tools und geringerer Aufwand bei Audits. Doppelte Tools sind der stille Kostenfaktor. Wenn jedes Team seinen eigenen Stack zusammenstellt, steigen die versteckten Kosten durch den Betrieb mehrerer voneinander getrennter Plattformen – in Form von Lizenzen, Integrationsaufwand und häufigem Kontextwechsel. Ein gemeinsamer, auf Vorlagen basierender Weg bis zur Produktion ist die Lösung, mit der Unternehmen das vermeiden.

Für Technologieleiter verändert sich dadurch auch das Gespräch mit dem Fachbereich. Statt „Das Modell ist fast fertig“ können Sie die Release-Häufigkeit, die Zeit bis zum Rollback und den überwachten Zustand des Modells berichten.

Wie wir helfen können

Bei Ridiculous Engineering arbeiten Kunden von der Analyse bis zur langfristigen Weiterentwicklung direkt mit erfahrenen Ingenieuren zusammen. Wenn Sie Pilotprojekte in Produktionssysteme überführen, decken unsere KI-Entwicklungs- und Automatisierungsservices maßgeschneiderte KI-Lösungen und die Automatisierung in ihrem Umfeld ab, und unsere Beratung und Unterstützung bei der Softwarebereitstellung kann dabei helfen, den aktuellen Stand Ihres Bereitstellungsprozesses zu beurteilen. Außerdem können Sie unsere frühere Perspektive zu industrialisierten KI-Systemen und MLOpslesen. Maßgeschneiderte KI-Projekte werden individuell festgelegt und auf Anfrage bepreist. Deshalb fordern Sie ein Angebot an mit einer kurzen Beschreibung Ihres ersten Modells. Anschließend besprechen wir den passenden, angemessen dimensionierten Weg.

FAQ

Was ist der Unterschied zwischen MLOps und DevOps?

DevOps automatisiert das Erstellen, Testen und Veröffentlichen von Anwendungscode. MLOps übernimmt dies ebenfalls und verwaltet zusätzlich Daten, Training, Modellversionen und die Leistung nach der Veröffentlichung, da sich ein Modell auch ohne Codeänderung verschlechtern kann. Teams erweitern in der Regel ihre bestehende CI/CD-Praxis, anstatt sie zu ersetzen.

Wo sollte ein Unternehmen mit MLOps beginnen?

Wählen Sie ein für das Unternehmen wichtiges Modell aus und dokumentieren Sie, wie es heute in die Produktion gelangt. Schließen Sie anschließend die größten Lücken: Versionskontrolle für Daten und Modelle, automatisierte Tests, eine Staging-Umgebung und einen Rollback-Plan. Verwenden Sie diesen Weg für das nächste Modell erneut.

Benötigen wir eine dedizierte MLOps-Plattform?

Nicht immer. Manche Teams kommen mit ihrem bestehenden CI/CD-System und einigen spezialisierten Tools für Tracking, Registry und Monitoring weit. Eine umfassendere Plattform ist sinnvoll, sobald viele Teams und Modelle gemeinsame Standards und Governance benötigen.

Wie unterstützt MLOps Sicherheit und Compliance?

MLOps macht Kontrollen wiederholbar. Audit-Trails, Zugriffe nach dem Prinzip der geringsten Berechtigung, Schwachstellenscans von Modell-Containern und Genehmigungsschranken laufen innerhalb der Pipeline statt in manuellen Prüfungen ab. Welche Vorschriften gelten, etwa HIPAA oder DSGVO, hängt von Ihren Daten ab und sollte mit Ihrem Compliance-Team bestätigt werden.

Wie lange dauert es, eine ausgereifte MLOps-Praxis zu erreichen?

Das hängt von Ihrem Ausgangspunkt, der Anzahl Ihrer Modelle und Ihrem Team ab. Reifegradmodelle beschreiben eine Entwicklung über mehrere Stufen. Die meisten Unternehmen durchlaufen diese Stufen in aufeinanderfolgenden Projekten Schritt für Schritt und nicht in einem einzigen Programm.

Quellen

• Was ist MLOps? (AWS)
• Ein Framework für kontinuierliche Bereitstellung und Automatisierung von ML: Leitfaden für Praktiker zu MLOps (Google)
• Machine-Learning-Operations bieten Agilität und fördern Innovationen (MIT Technology Review)
• Machine-Learning-Operations v2 (Azure Architecture Center)
• MLOps-Reifegradmodell (Azure Architecture Center)
• MLOps: Pipelines für kontinuierliche Bereitstellung und Automatisierung (Google Cloud)
• Management des Lebenszyklus von Machine-Learning-Modellen in Unternehmen (IJISAE)
• Überführung in den Produktionsbetrieb (Google for Developers)
• MLOps-Grundlagen-Roadmap für Unternehmen (AWS)
• AWS-MLOps-Checkliste (AWS Prescriptive Guidance)
• OpenSSF-MLSecOps-Whitepaper
• MLOps-Best Practices auf AKS (Microsoft Learn)

Empfohlen

• Warum Enterprise-KI nach der Demo scheitert
• Enterprise-KI: Dem Pilotprojekt-Dilemma entkommen
• Enterprise-KI: Dem Pilotprojekt-Dilemma entkommen
• MLOps: Industrialisierte KI für verbesserte Geschäftsstrategien mit Ridiculous Engineering