Sie haben es vielleicht schon oft gehört, aber nur ein kleiner Teil der Modelle für maschinelles Lernen geht in Produktion. Die Bereitstellung und der Betrieb eines maschinellen Lernmodells ist für die meisten Branchen, die ML für ihre Anwendungsfälle einsetzen, eine Herausforderung. In diesem Artikel werde ich einige der besten MLOps-Praktiken und Tipps vorstellen, die es Ihnen ermöglichen, Ihr ML-Modell in der Produktion richtig zu betreiben. Bevor wir beginnen, lassen Sie uns über den typischen Lebenszyklus eines ML-Projekts sprechen, den wir vielleicht alle kennen.
ML-Projekt-Lebenszyklus
Ein typischer ML-Lebenszyklus lässt sich mit dem folgenden Diagramm zusammenfassen, das hauptsächlich aus 3 Phasen besteht.
In der ersten Phase, bevor wir uns in unsere Daten vertiefen, ist es wichtig, dass wir uns auf den Erfolg vorbereiten. Deshalb müssen wir zusammen mit den Wirtschaftsexperten unser Problem und die Unternehmensziele sorgfältig definieren! Wir müssen einige wichtige Fragen beantworten, die es uns ermöglichen, Entscheidungen bezüglich der Gestaltung des Modells und der Produktionspipeline zu treffen. Zum Beispiel:
- Was ist das ideale Ergebnis?
- Was ist unser Bewertungsmaßstab? Wie können wir einen ROI definieren?
- Was sind die Erfolgs- und Misserfolgskriterien?
- Wie hoch sind die Latenzanforderungen? Und können wir jede Funktion innerhalb der Latenzzeitanforderungen bereitstellen? …
In der zweiten Phase erstellen wir einen Prototyp unseres ersten ML-Modells, oder anders gesagt, wir führen eine ML-Machbarkeitsstudie durch.
Wir weisen also den ML-Geschäftswert anhand der in der ersten Phase definierten Metrik nach. Denken Sie daran, dass die beste Praxis für ML-Engineering Regel Nummer 1 lautet: „Halten Sie das erste Modell einfach und sorgen Sie für die richtige Infrastruktur“. Das erste Modell bietet den größten Nutzen für unser Produkt, daher muss es zu Beginn nicht das ausgefallenste Modell sein.
In der dritten Phase gehen wir in die Produktion über. Da dies das Hauptthema dieses Artikels ist, werden wir in den kommenden Abschnitten näher darauf eingehen. Sobald unsere Produktionspipeline fertig und gut konzipiert ist, können wir viel schneller und effizienter Erkenntnisse sammeln und neue Ideen umsetzen.
Was machen Data Scientists heute hauptsächlich?
Heute sehen die meisten ML-Prozesse, um ein maschinelles Lernmodell in die Produktion zu bringen, in etwa so aus. Als Datenwissenschaftler beginnt man mit einem ML-Anwendungsfall und einem Geschäftsziel. Mit dem Anwendungsfall in der Hand beginnen wir, die Daten, die uns relevant erscheinen, aus verschiedenen Datenquellen zu sammeln und zu untersuchen, um ihre Qualität zu verstehen und zu bewerten.
Sobald wir ein Gefühl für unsere Daten bekommen haben, beginnen wir mit der Ausarbeitung und Entwicklung einiger Merkmale, die wir für unser Problem als interessant erachten. Dann gehen wir in die Modellierungsphase über und beginnen mit einigen Experimenten. In dieser Phase führen wir die verschiedenen experimentellen Schritte regelmäßig manuell durch. Bei jedem Experiment führen wir eine Datenvorbereitung, ein Feature-Engineering und Tests durch. Dann führen wir ein Modelltraining und eine Abstimmung der Hyperparameter für alle Modelle oder Modellarchitekturen durch, die wir für besonders vielversprechend halten.
Zu guter Letzt evaluieren wir alle generierten Modelle, testen sie anhand eines Holdout-Datensatzes, evaluieren die verschiedenen Metriken, betrachten die Leistung und vergleichen die Modelle miteinander, um zu sehen, welches am besten funktioniert oder die höchste Bewertungsmetrik liefert. Der gesamte Prozess ist iterativ und wird immer wieder manuell ausgeführt, bis wir das beste Modell mit der bestmöglichen Leistung erhalten.
Sobald wir das leistungsstärkste Modell erhalten haben, legen wir es in der Regel in einem Speicher ab und übergeben es an das IT- und Betriebsteam, dessen Aufgabe es dann ist, das Modell als Vorhersagedienst in der Produktion einzusetzen. Und damit ist unsere Arbeit leider schon beendet.
ML Operations Pitfalls – Was ist falsch an diesem Ansatz?
Hier ist, was mit dem obigen Ansatz falsch ist.
Manuell: Die Schritte sind sehr manuell und werden jedes Mal von Grund auf neu geschrieben. Jedes Mal, wenn der Datenwissenschaftler ein neues Experiment durchführen muss, muss er seine Notizbücher durchgehen, sie aktualisieren und sie manuell ausführen. Wenn das Modell mit neuen Trainingsdaten aufgefrischt werden muss, muss der Datenwissenschaftler seinen Code erneut manuell ausführen.
Zeitaufwändig: Dieser manuelle Prozess ist zeitaufwändig und nicht effizient.
Nicht wiederverwendbar: Der in den Notebooks geschriebene benutzerdefinierte Code kann nur vom Autor selbst verstanden werden und kann nicht von anderen Datenwissenschaftlern oder für andere Anwendungsfälle wiederverwendet oder genutzt werden. Sogar den Autoren selbst fällt es manchmal schwer, ihre Arbeit nach einer gewissen Zeit zu verstehen.
Unreproduzierbarkeit: Reproduzierbarkeit ist die Fähigkeit, neu erstellt oder kopiert zu werden. Beim maschinellen Lernen ist es wichtig, das Modell genau reproduzieren zu können. Bei einem manuellen Prozess wie hier ist es wahrscheinlich nicht möglich, eine ältere Version eines Modells zu reproduzieren, da sich die zugrundeliegenden Daten geändert haben könnten, der Code selbst überschrieben worden sein könnte oder Abhängigkeiten und ihre genauen Versionen nicht aufgezeichnet worden sind. Daher ist im Falle eines Problems jeder Versuch, zu einer älteren Version eines Modells zurückzukehren, unter Umständen unmöglich.
Fehleranfällig: Dieser Prozess kann zu vielen Fehlern führen, wie z. B. Verzerrung der Trainingsdaten, Leistungsabfall des Modells, Verzerrung des Modells, Absturz der Infrastruktur im Laufe der Zeit…
- Training Serving Skew: Wenn wir unser Modell einsetzen, werden wir manchmal feststellen, dass die Online-Leistung unseres Modells völlig unter der Leistung liegt, die wir erwartet und auf dem Holdout-Datensatz gemessen haben. Dieses Phänomen tritt sehr häufig bei Modellen für maschinelles Lernen auf. Diskrepanzen zwischen Trainings- und Serving-Pipelines können zu Trainings-Serving-Skew führen. Ein Trainings-Serving-Skew ist sehr schwer zu erkennen und kann die Vorhersagen eines Modells völlig unbrauchbar machen. Um dieses Problem zu vermeiden, müssen wir sicherstellen, dass die exakten Verarbeitungsfunktionen sowohl für die Trainings- als auch für die Serving-Daten ausgeführt werden, die Verteilung der Trainings- und Serving-Daten überwachen und die Echtzeitleistung des Modells überwachen und mit der Offline-Leistung vergleichen.
- Modellverfall: In den meisten Anwendungsfällen sind die Datenprofile dynamisch und ändern sich mit der Zeit. Wenn sich die zugrunde liegenden Daten ändern, lässt die Modellleistung nach, da die vorhandenen Muster nicht mehr aktuell sind. Statische Modelle sind nur selten noch von Nutzen. Wir müssen dafür sorgen, dass die Modelle regelmäßig mit neuen Daten aktualisiert werden, und die Echtzeitleistung der bereitgestellten Modelle überwachen, um einen Modellverfall auszulösen. Die folgende Abbildung zeigt, wie ein eingesetztes Modell mit der Zeit verfällt und wie notwendig es ist, das Modell ständig durch ein neues zu aktualisieren.
- Voreingenommenheit des Modells: Anwendungen von KI-Systemen können kritischer Natur sein, wie z. B. medizinische Diagnosen oder Prognosen, die Zuordnung der Fähigkeiten von Menschen zu Arbeitsplätzen oder die Prüfung der Eignung einer Person für einen Kredit. So praktisch diese Anwendungen auch erscheinen mögen, die Auswirkungen von Verzerrungen in solchen Systemen können sehr schädlich sein. Eine wichtige Eigenschaft künftiger KI-Systeme ist daher Fairness und Inklusivität für alle. Daher ist es für jedes Modell des maschinellen Lernens wichtig, die Fairness in Bezug auf sensible Merkmale (Geschlecht, Rasse …) zu messen. Die sensiblen Merkmale hängen vom Kontext ab. Auch bei nicht sensiblen Merkmalen ist es wichtig, die Leistung der KI-Systeme für die verschiedenen Untergruppen zu bewerten, um sicherzustellen, dass wir uns vor dem Einsatz eines Modells bewusst sind, welche Untergruppen unterdurchschnittliche Leistungen erbringen.
- Scalability: Scalability matters in machine learning because training a model can take a long time and hence optimizing a model that takes multiple weeks of training, is not workable. A model can be so big that it can’t fit into the working memory of the training device. Even if we decide to scale vertically, it is going to be more expensive than scaling horizontally. There might be some cases where the data quantity is not big and hence scalability might not be needed at the beginning, but we should think if, with continuous training, the amount of training data that we expect to receive will increase with time and might introduce a memory problem for the infrastructure that we set in place.
Die wichtigsten Komponenten eines ML-Systems
In diesem Abschnitt beschreiben wir die Hauptkomponenten eines ML-Systems und die besten Praktiken, die es uns ermöglichen, die oben genannten Fallstricke zu vermeiden.
Der Prozess der Bereitstellung eines integrierten ML-Systems und seines kontinuierlichen Betriebs in der Produktion umfasst die folgenden Schritte:
Lassen Sie uns die einzelnen Komponenten der Pipeline etwas näher erläutern.
Dateneingabe:
Diese Komponente ist in der Regel extern und liegt außerhalb der ML-Pipeline unseres Anwendungsfalls. In ausgereiften Datenprozessen sollten Dateningenieure die kontinuierliche Datenaufnahme und ‑umwandlung optimieren, um den verschiedenen Datenanalyseeinheiten innerhalb des Unternehmens, die sich auf datengestützte Erkenntnisse und besser informierte Entscheidungen freuen, stets aktuelle Daten zu liefern.
Datenvalidierung:
In dieser Komponente liegt unser Schwerpunkt auf der Validierung der Eingabedaten, die in unsere Pipeline eingespeist werden. Die Bedeutung dieses Problems in ML-Systemen ist nicht zu unterschätzen. Unabhängig von den verwendeten ML-Algorithmen können Fehler in den Daten die Qualität des generierten Modells stark beeinträchtigen. Ein bekanntes Konzept der Datenwissenschaft besagt: „Garbage in, garbage out“. Daher ist es von entscheidender Bedeutung, Datenfehler frühzeitig zu erkennen.
Eine weitere Rolle, die fehlerfreie Daten spielen können, ist die Analyse der Modellausgabe. Diese Komponente ermöglicht es uns, die Ausgabe unseres ML-Modells richtig zu verstehen und zu debuggen. Folglich müssen Daten in ML-Systemen als Bürger erster Klasse betrachtet werden, genau wie Algorithmen und Infrastruktur. Sie müssen bei jeder Ausführung der ML-Pipeline kontinuierlich überwacht und validiert werden.
Dieser Schritt wird auch vor dem Modelltraining verwendet, um zu entscheiden, ob wir das Modell neu trainieren (im Falle einer Datendrift) oder die Ausführung der Pipeline stoppen sollten (im Falle von Datenanomalien).
So sollte ein typisches Verhalten der Datenvalidierungskomponente aussehen:
- Es berechnet und zeigt deskriptive Statistiken über die Daten an und kann auch die deskriptiven Statistiken von aufeinanderfolgenden Datenbereichen anzeigen (d. h. zwischen der aktuellen Pipeline-Ausführung N und der letzten Pipeline-Ausführung N‑1), um zu sehen, wie sich die Datenverteilung verändert hat.
- Daraus wird das Datenschema abgeleitet, das die verwendeten Daten repräsentiert.
- It detects data anomalies. It should check if the dataset matches the predefined validated schema. It should detect data drift between consecutive spans of data (i.e., between current pipeline execution N and last pipeline execution N‑1), such as between different days of training data. It should also detect training serving skew by comparing the training data with the online serving data.
In der Produktion, mit kontinuierlichem Training, sieht eine schematische Ansicht, die Statistiken über neu eintreffende Daten generiert, sie validiert und Berichte über Anomalien erstellt, wie folgt aus:
Daten transformieren
In diesem Schritt werden die Daten für die ML-Aufgabe vorbereitet. Dazu gehören Datenbereinigung, Filterung, Datentransformationen und die Bearbeitung von Merkmalen. Sie sollte Dinge wie die Generierung von Merkmalen zu Ganzzahl-Mappings erledigen. Außerdem bereitet diese Komponente Merkmals-Metadaten vor, die in der Trainerkomponente benötigt werden könnten (dazu gehören z. B. die Meta-Parameter, die im Trainingsschritt für die Merkmalsnormalisierung benötigt werden, die Wörterbücher, die für die Kodierung kategorialer Variablen benötigt werden, usw…). Diese werden Transformationsartefakte genannt; sie helfen bei der Konstruktion der Modelleingaben.
Entscheidend ist, dass alle erzeugten Mappings gespeichert und zum Zeitpunkt des Servings (wenn das trainierte Modell zur Erstellung von Vorhersagen verwendet wird) wiederverwendet werden müssen. Wird dies nicht konsequent durchgeführt, kommt es zu dem bereits erwähnten Problem der „Training Serving Skew“.
Modell Training
Die Komponente Modellschulung ist für das Training unseres Modells verantwortlich. In den meisten Anwendungsfällen können Modelle stunden‑, tage- oder sogar wochenlang trainiert werden. Die Optimierung eines Modells, das mehrere Wochen Training benötigt, ist nicht praktikabel. In anderen Fällen passen die zum Trainieren des Modells verwendeten Daten nicht einmal in den Speicher.
In diesem Fall sollte die Komponente zum Trainieren des Modells in der Lage sein, die Parallelität von Daten und Modell zu unterstützen und auf eine große Anzahl von Mitarbeitern zu skalieren. Sie sollte auch in der Lage sein, Out-of-Memory-Daten zu verarbeiten.
Idealerweise sollten alle Komponenten unseres ML-Systems skalierbar sein und auf einer Infrastruktur laufen, die Skalierbarkeit unterstützt.
Diese Komponente für die Modellschulung sollte auch in der Lage sein, alles während der Schulung automatisch zu überwachen und zu protokollieren. Wir können ein maschinelles Lernmodell nicht über einen längeren Zeitraum trainieren, ohne zu sehen, wie es sich schlägt, und ohne sicherzustellen, dass es korrekt konfiguriert ist, um die Verlustfunktion mit der Anzahl der Iterationen zu minimieren. Schließlich sollte die Trainingskomponente auch die Abstimmung der Hyperparameter unterstützen.
Modellanalyse
In der Modellanalysekomponente führen wir eine gründliche Analyse der Trainingsergebnisse durch und stellen sicher, dass unsere exportierten Modelle leistungsfähig genug sind, um in die Produktion überführt zu werden.
Mit diesem Schritt können wir sicherstellen, dass das Modell nur dann für die Produktion freigegeben wird, wenn es die Qualitätskriterien erfüllt, die wir in der Framing-Phase festgelegt haben. Zu den Kriterien gehören eine verbesserte Leistung im Vergleich zu den zuvor bereitgestellten Modellen und eine faire Leistung in den verschiedenen Datenuntergruppen/-scheiben. In der folgenden Abbildung sehen Sie die Leistung unseres trainierten Modells für das Feature Slice trip_start_hour.
Das Ergebnis dieses Schritts ist eine Reihe von Leistungsmetriken und eine Entscheidung darüber, ob das Modell in die Produktion überführt werden soll.
Modell-Betrieb
Im Gegensatz zur Schulungskomponente, bei der wir uns normalerweise um die Skalierung mit den Daten und der Modellkomplexität kümmern. Bei der Serving-Komponente sind wir daran interessiert, auf variable Nutzeranforderungen zu reagieren, indem wir die Antwortlatenz minimieren und den Durchsatz maximieren.
Daher sollte die Serving-Komponente eine niedrige Latenz haben, um schnell auf die Nutzer reagieren zu können, hocheffizient sein, so dass bei Bedarf viele Instanzen gleichzeitig ausgeführt werden können, horizontal skalierbar, zuverlässig und robust gegenüber Ausfällen.
Außerdem muss unsere Serving-Komponente leicht auf neue Versionen des Modells aktualisiert werden können. Wenn wir neue Daten erhalten, einen neuen Pipeline-Lauf auslösen oder neue Ideen für die Modellarchitektur testen, wollen wir eine neue Version des Modells bereitstellen, und das System soll nahtlos auf diese neue Version übergehen.
Überwachung
Wie bereits erwähnt, kann die Leistung unserer bereitgestellten ML-Modelle aufgrund der sich ständig verändernden Datenprofile mit der Zeit abnehmen, und wir müssen sicherstellen, dass unser System diese Verschlechterung überwacht und darauf reagiert.
Daher müssen wir zusammenfassende Statistiken unserer Daten verfolgen und die Online-Leistung unseres Modells überwachen, um Benachrichtigungen zu senden, ein Rollback durchzuführen, wenn die Werte von unseren Erwartungen abweichen, oder möglicherweise eine neue Iteration im ML-Prozess auszulösen.
Daher ist die Online-Überwachung der Schlüssel zur Erkennung von Leistungseinbußen und Modellstagnation. Sie dient als Anhaltspunkt für eine neue Versuchsiteration und ein erneutes Training des Modells anhand neuer Daten.
Pipeline-Organisationskomponente
Der Automatisierungsgrad der soeben beschriebenen Schritte definiert den Reifegrad unseres ML-Systems und spiegelt auch die Geschwindigkeit des Trainings neuer Modelle wider, die durch den Verfall des Modells oder durch neue Daten ausgelöst wird.
Ein manueller Prozess ist derzeit in vielen Anwendungsfällen sehr verbreitet. Er mag ausreichend sein, wenn Modelle aufgrund einer statischen Datenverteilung nur selten geändert werden. In der Praxis ist dies jedoch selten der Fall. Die Daten sind oft dynamisch und die Modelle brechen häufig, wenn sie in der realen Welt eingesetzt werden. Statische Modelle werden sich mit Sicherheit nicht an Änderungen in den Daten, die die Umgebung beschreiben, anpassen können.
Ein manueller Prozess kann auch gefährlich sein, da er eine Trennung zwischen ML-Training und ML-Betrieb bewirkt. Es trennt die Datenwissenschaftler, die das Modell erstellen, von den Ingenieuren, die das Modell als Vorhersagedienst betreiben. Und dieser Prozess kann zu dem Problem der Schieflage beim Trainingsservice führen.
Das Ziel der Orchestrierungskomponente ist es, die verschiedenen Komponenten des Systems zu verbinden. Sie führt die Pipeline in einer Sequenz aus und wechselt automatisch von einem Schritt zum nächsten, basierend auf den definierten Bedingungen. Dies ist der erste Schritt zur Automatisierung, da wir nun automatisch neue Modelle in der Produktion mit frischen Daten auf der Grundlage von Live-Pipeline-Auslösern trainieren können.
Wir müssen beachten, dass wir in der Produktion nicht ein trainiertes Modell als Vorhersagedienst bereitstellen. Vielmehr wird eine ganze Trainingspipeline bereitgestellt, die automatisch und wiederholt ausgeführt wird, um das trainierte Modell als Vorhersagedienst bereitzustellen.
Speicherung von Pipeline-Metadaten
Die Aufgabe des Pipeline-Metadatenspeichers besteht darin, alle Details über unsere ML-Pipeline-Ausführungen aufzuzeichnen. Dies ist sehr wichtig, um die Abstammung zwischen den Komponenten aufrechtzuerhalten und eingesetzte Modelle bei Bedarf zu reproduzieren. Außerdem hilft es uns bei der Fehlersuche im Falle eines Fehlers.
Jedes Mal, wenn wir die Pipeline ausführen, zeichnet der Speicher alle Details über unsere Pipeline-Ausführung auf, z. B:
- Die Versionen der Quellcodes unserer Pipeline und Komponenten, die ausgeführt wurden.
- Die Eingabeargumente, die an unsere Pipeline übergeben wurden.
- Die Artefakte/Ausgaben, die von jeder ausgeführten Komponente unserer Pipeline erzeugt werden, wie z. B. der Pfad zu den Rohdaten, die transformierten Datensätze, die Validierungsstatistiken und Anomalien, das trainierte Modell…
- Die Metriken zur Modellbewertung und die Entscheidung zur Modellvalidierung hinsichtlich des Modelleinsatzes, die während der Komponente zur Modellanalyse und ‑validierung erstellt wird…
CI/CD-Pipeline-Automatisierung
Bisher haben wir nur darüber gesprochen, wie wir die kontinuierliche Ausführung der ML-Pipeline automatisieren können, um neue Modelle auf der Grundlage von Auslösern wie der Verfügbarkeit neuer Daten oder dem Verfall des Modells neu zu trainieren, um neu entstehende Muster zu erfassen.
Was aber, wenn wir eine neue Funktion, eine neue Modellarchitektur oder einen neuen Hyperparameter testen wollen? Genau darum geht es bei einer automatisierten CI/CD-Pipeline. Eine CI/CD-Pipeline ermöglicht es uns, neue Ideen und Experimente schnell zu erforschen. Sie ermöglicht die automatische Erstellung, Prüfung und Bereitstellung der neuen Pipeline und ihrer Komponenten in der vorgesehenen Umgebung.
So ergänzt die Automatisierung der CI/CD-Pipeline die Automatisierung der kontinuierlichen ML-Pipeline:
- Bei einer neuen Implementierung/Code (neue Modellarchitektur, Feature-Engineering und Hyperparameter …) stellt eine erfolgreiche CI/CD-Pipeline eine neue kontinuierliche ML-Pipeline bereit.
- Bei Vorliegen neuer Daten (oder eines Auslösers für den Modellverfall) stellt eine erfolgreiche automatisierte kontinuierliche Pipeline einen neuen Vorhersagedienst bereit. Um ein neues ML-Modell mit neuen Daten zu trainieren, wird die zuvor bereitgestellte ML-Pipeline mit den neuen Daten ausgeführt.
Eine vollständige automatisierte End-to-End-Pipeline sollte wie folgt aussehen:
- Wir probieren iterativ neue ML-Ideen aus, bei denen einige unserer Pipeline-Komponenten aktualisiert werden (wenn wir zum Beispiel eine neue Funktion einführen, aktualisieren wir die Datentransformationskomponente…). Das Ergebnis dieser Phase ist der Quellcode der neuen ML-Pipeline-Komponenten, die dann in ein Quellcode-Repository der Zielumgebung eingestellt werden.
- Das Vorhandensein eines neuen Quellcodes löst die CI/CD-Pipeline aus, die im Gegenzug die neuen Komponenten und die Pipeline erstellt, die entsprechenden Unit- und Integrationstests durchführt, um sicherzustellen, dass alles korrekt kodiert und konfiguriert ist, und schließlich die neue Pipeline in der Zielumgebung bereitstellt, wenn alle Tests bestanden wurden. Die Unit- und Integrationstests für ML-Systeme verdienen einen eigenen Artikel.
- Die neu bereitgestellte Pipeline wird automatisch in der Produktion auf der Grundlage eines Zeitplans, bei Vorhandensein neuer Trainingsdaten oder als Reaktion auf einen Auslöser ausgeführt. Das Ergebnis dieser Phase ist ein trainiertes Modell, das in die Modellregistrierung übertragen und kontinuierlich überwacht wird.
Quelle: medium
Erfahren Sie hier mehr über Lösungen im Bereich Data Management oder besuchen Sie eines unserer kostenlosen Webinare.
