Der Zweck dieses Reifegradmodells besteht darin, die Prinzipien und Methoden von Vorgängen des maschinellen Lernens (MLOps) zu verdeutlichen. Das Reifegradmodell zeigt die fortlaufende Verbesserung bei der Erstellung und dem Betrieb der Umgebung einer Anwendung mit maschinellem Lernen auf Produktionsebene. Sie können es als Metrik zum Einrichten der progressiven Anforderungen für das Messen des Reifegrads einer Produktionsumgebung mit maschinellem Lernen und der zugehörigen Prozesse verwenden.
Reifegradmodell
Das MLOps-Reifegradmodell hilft dabei, die für die Ausführung einer erfolgreichen MLOps-Umgebung erforderlichen Prinzipien und Verfahren für Entwicklungsvorgänge (DevOps) zu verdeutlichen. Es soll Lücken in bisherigen Versuchen einer Organisation, eine solche Umgebung zu implementieren, aufdecken. Es zeigt Ihnen auch, wie Sie Ihre MLOps-Funktion in einzelnen Schritten vergrößern, anstatt die komplexen Anforderungen einer vollständig ausgereiften Umgebung erfüllen zu müssen. Verwenden Sie es als Leitfaden für folgende Vorgänge:
Schätzen des Arbeitsumfangs für Neueinsätze
Etablieren realistischer Erfolgskriterien
Identifizieren von Ergebnissen, die am Ende des Einsatzes übergeben werden
Wie bei den meisten Reifegradmodellen bewertet das MLOps-Reifegradmodell die Personen/Kulturen, Prozesse/Strukturen und Objekte/Technologien qualitativ. Mit zunehmendem Reifegrad steigt die Wahrscheinlichkeit, dass Incidents oder Fehler zu Verbesserungen der Qualität der Entwicklungs- und Produktionsprozesse führen.
Das MLOps-Reifegradmodell umfasst fünf Ebenen technischer Funktionen:
| Ebene |
BESCHREIBUNG |
Highlights |
Technologie |
| 0 |
Keine MLOps |
- Schwierig zu verwaltender vollständiger Machine Learning-Modelllebenszyklus
- Teams arbeiten unabhängig, und Releases sind mühsam.
- Die meisten Systeme sind als Blackbox ausgearbeitet, und während/nach der Bereitstellung erfolgt wenig Feedback.
|
- Manuelle Builds und Bereitstellungen
- Manuelles Testen des Modells und der Anwendung
- Keine zentralisierte Nachverfolgung der Modellleistung
- Das Training des Modells erfolgt manuell.
|
| 1 |
DevOps, aber keine MLOps |
- Releases sind weniger mühsam als ohne MLOps, aber für jedes neue Modell auf das Datenteam angewiesen.
- Immer noch eingeschränktes Feedback zur Funktion eines Modells in der Produktion
- Schwierig nachzuverfolgende/reproduzierbare Ergebnisse
|
- Automatisierte Builds
- Automatisierte Tests für Anwendungscode
|
| 2 |
Automatisiertes Training |
- Die Trainingsumgebung ist vollständig verwaltet und nachverfolgbar.
- Einfach reproduzierbares Modell
- Releases erfolgen manuell, aber mit wenigen Konflikten
|
- Automatisiertes Trainieren von Modellen
- Zentralisierte Nachverfolgung der Modelltrainingsleistung
- Modellverwaltung
|
| 3 |
Automatisierte Modellbereitstellung |
- Releases erfolgen mit wenigen Konflikten und automatisch
- Vollständige Nachverfolgbarkeit von der Bereitstellung zurück zu den ursprünglichen Daten
- Gesamte Umgebung verwaltet: Training > Tests > Produktion
|
- Integrierte A/B-Tests der Modellleistung für die Bereitstellung
- Automatisierte Tests für den gesamten Code
- Zentralisierte Nachverfolgung der Modelltrainingsleistung
|
| 4 |
Automatisierte Vorgänge mit vollständigen MLOps |
- Gesamtes System automatisiert und einfach zu überwachen
- Produktionssysteme stellen Informationen zur Verbesserung und in einigen Fällen zur automatischen Verbesserung mit neuen Modellen bereit.
- Annäherung an ein System ohne Ausfallzeiten
|
- Automatisiertes Trainieren und Testen von Modellen
- Ausführliche, zentralisierte Metriken aus dem bereitgestellten Modell
|
In den nachstehenden Tabellen werden die detaillierten Merkmale für diese Ebene des Prozessreifegrads identifiziert. Das Modell wird stetig weiterentwickelt.
Ebene 0: Keine MLOps
| Personen |
Modellerstellung |
Modellfreigabe |
Anwendungsintegration |
- Data Scientists: abgeschottet, nicht in regelmäßiger Kommunikation mit dem restlichen Team
- Datentechniker (sofern vorhanden): abgeschottet, nicht in regelmäßiger Kommunikation mit dem restlichen Team
- Softwareentwickler: abgeschottet, erhalten Modell remote von den anderen Teammitgliedern
|
- Manuelles Sammeln von Daten
- Compute wahrscheinlich nicht verwaltet
- Experimente werden nicht vorhersagbar nachverfolgt.
- Das Endergebnis ist möglicherweise eine einzelne Modelldatei, die manuell mit Eingaben/Ausgaben übergeben wird.
|
- Manueller Vorgang
- Das Bewertungsskript wird möglicherweise nach Experimenten ohne Versionskontrolle manuell erstellt.
- Release nur von Data Scientist oder Datentechniker behandelt
|
- Stark abhängig von der Implementierungserfahrung der Data Scientists
- Immer manuelle Releases
|
Ebene 1: DevOps, keine MLOps
| Personen |
Modellerstellung |
Modellfreigabe |
Anwendungsintegration |
- Data Scientists: abgeschottet, nicht in regelmäßiger Kommunikation mit dem restlichen Team
- Datentechniker (sofern vorhanden): abgeschottet, nicht in regelmäßiger Kommunikation mit dem restlichen Team
- Softwareentwickler: abgeschottet, erhalten Modell remote von den anderen Teammitgliedern
|
- Datenpipeline sammelt Daten automatisch.
- Compute wird verwaltet oder nicht verwaltet.
- Experimente werden nicht vorhersagbar nachverfolgt.
- Das Endergebnis ist möglicherweise eine einzelne Modelldatei, die manuell mit Eingaben/Ausgaben übergeben wird.
|
- Manueller Vorgang
- Das Bewertungsskript wird möglicherweise nach Experimenten manuell erstellt, wahrscheinlich mit Versionskontrolle.
- Wird an Softwareentwickler übergeben
|
- Für das Modell bestehen grundlegende Integrationstests.
- Stark abhängig von der Erfahrung der Data Scientists beim Implementieren von Modellen
- Releases automatisiert
- Anwendungscode umfasst Komponententests.
|
Ebene 2: Automatisiertes Training
| Personen |
Modellerstellung |
Modellfreigabe |
Anwendungsintegration |
- Data Scientists: Direkte Arbeit mit Datentechnikern zum Konvertieren von Experimentcode in wiederholbare Skripts/Aufträge
- Datentechniker: Arbeit mit Data Scientists
- Softwareentwickler: abgeschottet, erhalten Modell remote von den anderen Teammitgliedern
|
- Datenpipeline sammelt Daten automatisch.
- Compute verwaltet
- Experimentergebnisse nachverfolgt
- Sowohl Trainingscode als auch resultierende Modelle mit Versionskontrolle
|
- Manuelles Release
- Bewertungsskript mit Versionskontrolle und Tests
- Release verwaltet durch Softwareentwicklungsteam
|
- Für das Modell bestehen grundlegende Integrationstests.
- Stark abhängig von der Erfahrung der Data Scientists beim Implementieren von Modellen
- Anwendungscode umfasst Komponententests.
|
Ebene 3: Automatisierte Modellbereitstellung
| Personen |
Modellerstellung |
Modellfreigabe |
Anwendungsintegration |
- Data Scientists: Direkte Arbeit mit Datentechnikern zum Konvertieren von Experimentcode in wiederholbare Skripts/Aufträge
- Datentechniker: Arbeit mit Data Scientists und Softwaretechnikern zum Verwalten von Eingaben/Ausgaben
- Softwareentwickler: Arbeit mit Datentechnikern zum Automatisieren der Modellintegration in Anwendungscode
|
- Datenpipeline sammelt Daten automatisch.
- Compute verwaltet
- Experimentergebnisse nachverfolgt
- Sowohl Trainingscode als auch resultierende Modelle mit Versionskontrolle
|
- Automatisches Release
- Bewertungsskript mit Versionskontrolle und Tests
- Durch CI/CD-Pipeline (Continuous Integration/Continuous Delivery) verwaltetes Release
|
- Komponenten- und Integrationstests für jedes Modellrelease
- Weniger abhängig von der Erfahrung der Data Scientists beim Implementieren von Modellen
- Anwendungscode umfasst Komponenten-/Integrationstests.
|
Ebene 4: Automatisiertes erneutes Training mit vollständigen MLOps
| Personen |
Modellerstellung |
Modellfreigabe |
Anwendungsintegration |
- Data Scientists: Direkte Arbeit mit Datentechnikern zum Konvertieren von Experimentcode in wiederholbare Skripts/Aufträge Arbeit mit Softwaretechnikern zum Identifizieren von Markern für Datentechniker
- Datentechniker: Arbeit mit Data Scientists und Softwaretechnikern zum Verwalten von Eingaben/Ausgaben
- Softwareentwickler: Arbeit mit Datentechnikern zum Automatisieren der Modellintegration in Anwendungscode Implementieren einer Metrikerfassung nach der Bereitstellung
|
- Datenpipeline sammelt Daten automatisch.
- Erneutes Training automatisch basierend auf Produktionsmetriken ausgelöst
- Compute verwaltet
- Experimentergebnisse nachverfolgt
- Sowohl Trainingscode als auch resultierende Modelle mit Versionskontrolle
|
- Automatisches Release
- Bewertungsskript mit Versionskontrolle und Tests
- Durch Continuous Integration und CI/CD-Pipeline (Continuous Integration/Continuous Delivery) verwaltetes Release
|
- Komponenten- und Integrationstests für jedes Modellrelease
- Weniger abhängig von der Erfahrung der Data Scientists beim Implementieren von Modellen
- Anwendungscode umfasst Komponenten-/Integrationstests.
|
Nächste Schritte