MLOps mit einem bewährten Lösungsentwurf meistern | von Ashanti Terraneo | ELCA IT | Juni 2023

Autoren: Ashanti Terraneo, Daniel Spicar

Maschinelles Lernen (ML) hat die Artwork und Weise, wie wir an Problemlösungen und Entscheidungen herangehen, revolutioniert. Mit der Fähigkeit, aus Daten zu lernen und die Leistung im Laufe der Zeit zu verbessern, nimmt der Einsatz von ML-Algorithmen zur Unterstützung und Automatisierung komplexer Aufgaben und Prozesse stetig zu.

Das Erstellen und Bereitstellen von ML-Modellen ist jedoch kein einmaliger Aufwand. Es erfordert eine kontinuierliche Verwaltung und Überwachung des gesamten ML-Anwendungslebenszyklus, um sicherzustellen, dass die Modelle wie erwartet funktionieren und einen Mehrwert liefern.

In diesem Artikel wird die Notwendigkeit eines dedizierten Lebenszyklus für Machine Studying Operations (MLOps) beschrieben. Wir präsentieren eine Fallstudie und den bewährten Lösungsentwurf von ELCA. Unser Design optimiert die Effizienz des ML-Anwendungsbetriebs für unsere Kunden, ermöglicht DevOps-Ingenieuren die Durchführung von Wartungsarbeiten und beschleunigt neue Information-Science-Initiativen.

Die Herausforderung

Das Coaching und die Bereitstellung leistungsstarker ML-Modelle ist nur die Spitze des MLOps-Lebenszyklus-Eisbergs. ML-Anwendungen sind in Dienste oder Produkte eingebettet und erfordern eine kontinuierliche Überwachung und Wartung, um Probleme zu erkennen und kostspielige Eingriffe zu vermeiden. Der Aufbau einer robusten Infrastruktur für den ML-Anwendungsbetrieb birgt jedoch viele (oft übersehene) Herausforderungen. Unter ihnen sind:

• Zerfall des ML-Modells: Verschlechterung der Modellleistung im Laufe der Zeit.
• Wenig Kontrolle über eingehende Daten.
• Fehlende Unterstützung für die Überwachung der Modellleistung.
• Anforderungen an Fachkenntnisse für die Entwicklung und Wartung von ML-Modellen. Diese Fähigkeiten könnten Mangelware sein.
• Der „Wenn man etwas ändert, ändert sich alles” (Abbildung unten) Paradigma: Isolierte Änderungen an Daten, Modellen oder Code können eine Kaskade von Änderungen über den gesamten ML-Lebenszyklus auslösen.

MLOps, kurz für Machine Studying Operations, ist eine Reihe von Praktiken und Instruments, die den ML-Lebenszyklus rationalisieren und die Bereitstellung, Verwaltung und Überwachung von Modellen und Anwendungen für maschinelles Lernen in Produktionsumgebungen automatisieren. Es unterstützt Einzelpersonen und Organisationen dabei, ML-Anwendungen vom Experiment (Entwicklung) in die Produktion zu bringen und die Herausforderungen zu bewältigen, die mit der Aufrechterhaltung der Leistung über einen längeren Zeitraum verbunden sind.

Mit der Verfügbarkeit neuer Technologien und Instruments und der Landschaft kommerzieller Lösungen Da sich die MLOps-Praxis schnell weiterentwickelt, wird sie immer häufiger eingesetzt.

Die meisten großen Cloud-Anbieter bieten Lösungen als Teil ihrer Plattformdienste an. Zum Beispiel, Amazon SageMaker, Microsoft Azure Machine Learning, Google Vertex AIUnd Datensteine bieten automatisierte Modelloptimierungs-, Versionskontroll- und Überwachungsfunktionen, um Unternehmen dabei zu helfen, Kosten zu senken und die Zuverlässigkeit bei der Bereitstellung von Modellen für maschinelles Lernen zu verbessern. Dedizierte ML-Plattformdienste wie Gewichte und Voreingenommenheiten, Datenroboter, DataikuUnd Neptune.ai bieten auch MLOps-Funktionen an. Integrationen dieser MLOps-Lösungen erscheinen auch in verwalteten Datenplattformen wie z Schneeflocke.

Open-Supply-Frameworks sind attraktiv, weil sie vor Ort ohne Lizenz- oder Nutzungskosten bereitgestellt werden können oder wenn Cloud-Dienste aufgrund von Kosten-, Rechts- oder Richtlinienbeschränkungen keine Choice sind. Kubeflow Und Seldon Core sind Frameworks, die für ML-Workloads und die Modellbereitstellung auf Kubernetes geeignet sind. Eine weitere beliebte Lösung (die auch in unserer Architektur verwendet wird) ist MLfloweine Plattform für ML-Experimente sowie Modellverfolgung und -verwaltung.

Dies sind nur einige der derzeit verfügbaren Lösungen. Es sei daran erinnert, dass nur einige Instruments, insbesondere Open-Supply-Frameworks, verfügbar sind Unterstützen Sie einen Teil des MLOps-Lebenszyklus. Die Auswahl des richtigen Instruments-Combine für die Integration in die bestehende Infrastruktur kann eine Herausforderung sein.

Bei ELCA hatten wir die Gelegenheit, einen unserer Kunden auf seinem Weg zur Implementierung einer lokalen MLOps-Lösung zu unterstützen. Cloud-Angebote waren in diesem Projekt aufgrund unternehmensinterner Einschränkungen keine Choice. Dennoch ist unsere Architektur nicht an bestimmte Instruments gebunden. Für alle Teile ist eine Migration in Cloud-Umgebungen möglich.

Der Bedarf unseres Kunden an einer MLOps-Infrastruktur entstand aus der Schwierigkeit, viele ML-Anwendungen zu betreiben, die bereits seit mehreren Jahren in Produktion waren. Jede ML-Anwendung wurde auf Advert-hoc-Projektbasis entwickelt, was bedeutet, dass sie ein bestimmtes, zu einem bestimmten Zeitpunkt bestehendes Downside lösen sollte. Seit den ersten Implementierungen hat sich auch die Bereitstellungsumgebung erheblich verändert.

Infolgedessen stellte der Kunde fest, dass die verschiedenen ML-Anwendungen immer schwieriger zu verwalten waren. Ihre Leistung hatte im Laufe der Zeit nachgelassen und Ressourcen für alles andere als einfache Betriebswartung waren nicht verfügbar.

Nach einer Untersuchung ihrer Infrastruktur und Anwendungen haben wir die folgenden Hauptprobleme identifiziert:

• Der Betrieb conflict nicht standardisiert: Für die Wartung waren spezielle ML-Kenntnisse und Anwendungs-Know-how erforderlich.
• Keine Modellüberwachung: Blindheit hinsichtlich der tatsächlichen Leistung der bereitgestellten Modelle.
• Keine Reproduzierbarkeit: ML-Modelle konnten nicht zuverlässig reproduziert werden, da die Parameter des eingesetzten Modells nicht erfasst wurden oder einfach veraltet waren.

Mangelnde Standardisierung ist eines der Hauptressourcenprobleme, die die Wartung teuer machen. Dies kann zu verkürzten Wartungszyklen führen, was den Leistungsabfall der Anwendung verschlimmert. Um diesem Kreislauf zu entkommen, haben wir Modellpipelines standardisiert und automatisiert. Eine Pipeline führt Aufgaben wie Datenverarbeitung, Modell-(Neu-)Schulung und Dienstbereitstellung aus. Diese Automatisierung ermöglicht es DevOps-Ingenieuren oder automatisierten Systemen, diese Aufgaben auszulösen. Spezialisierte ML-Kenntnisse können für nicht routinemäßige Aufgaben und neue Initiativen reserviert werden.

Das Fehlen einer Überwachung verzögert die Wartung bis zu einem Punkt, an dem Probleme für Endbenutzer offensichtlich werden. Zu diesem Zeitpunkt bietet das Modell keinen optimalen Wert mehr und die Benutzer beginnen, das Vertrauen zu verlieren. Wir haben die Modellbereitstellung standardisiert und verfügen nun standardmäßig über eine Modellüberwachung für alle ML-Anwendungen. Die Modellleistung kann verfolgt und Interventionen frühzeitig geplant und sogar automatisiert werden.

Die Unfähigkeit, ML-Modelle zu reproduzieren, führt dazu, dass selbst für eine einfache Umschulung des ML-Modells ein Information Scientist erforderlich ist. Um dieses Downside anzugehen und Modellversionen zu verwalten, verwenden wir jetzt MLflow, um alle Eingaben (Parameter) und Ausgaben (Modelle, Berichte, Metriken) von ML-Trainingsläufen aufzuzeichnen. Dies unterstützt auch Information Scientists, indem es ihnen ermöglicht, ihre Experimente einfach zu verfolgen und zu vergleichen.

Wir haben unserem Kunden einen Überwachungsdienst und CI/CD-Pipelines (Steady Integration / Steady Supply) zur Verfügung gestellt, um alle Prozesse zu orchestrieren und alle Dienste bereitzustellen. Diese Komponenten wurden in die bereits bestehende CI/CD-Infrastruktur integriert. Darüber hinaus wurden alle bestehenden ML-Anwendungen auf dieses MLOps-Framework migriert.

Wie in der Fallstudie erläutert, wurde unsere Architektur auf einer vorhandenen, lokalen DevOps-Infrastruktur aufgebaut. Das folgende Schema stellt den Arbeitsablauf und die Interaktionen zwischen verschiedenen Komponenten der Lösung auf abstrakte Weise dar.

Unsere Architektur basiert auf vier typischen DevOps-Komponenten (1–4) und vier MLOps-Komponenten (5–8). Diese Infrastruktur kann vollständig vor Ort, in einem Hybridmodus, bei dem einige Komponenten von Cloud-Diensten bereitgestellt werden, oder vollständig in der Cloud gehostet bereitgestellt werden. Darüber hinaus kann die Infrastruktur im Laufe der Zeit zwischen diesen Staaten migriert werden.

1. Quellcode-Repositorys zum Speichern und Versionieren von Anwendungsquellcode und -konfigurationen. Git ist der Customary bei Diensten wie GitHub oder Bit Bucket Bereitstellung zusätzlicher Funktionen und kostenloser Repositories. Azure-Repos Und AWS CodeCommit sind zwei Cloud-Plattform-Optionen.
2. A kontinuierliches Integrationssystem (CI). wie zum Beispiel GitLab CI, Jenkinsoder Cloud-Angebote wie Azure Pipelines oder AWS CodePipeline. Dieses System erstellt bereitstellbare Softwareartefakte. Builds können manuell ausgelöst werden oder auf Code-Repository-Ereignisse wie Commits reagieren.
3. A Steady-Supply-System (CD-System). das auf CI-Ereignisse reagiert und Softwareartefakte in einer Laufzeitumgebung bereitstellen kann. Dies wird durch die oben aufgeführten CI-Systeme oder durch spezialisiertere Systeme wie z. B. bereitgestellt ArgoCD für Kubernetes.
4. A Überwachungs-/Beobachtbarkeitssystem das Metriken und Protokolle laufender Anwendungen sammelt, aggregiert und anzeigt. Gängige Lösungen sind die ELK-Stapel oder ein Prometheus/Grafana Einsatz. In der Cloud werden diese Funktionalitäten durch Dienste wie bereitgestellt Azure Monitor oder AWS CloudWatch.
5. Experimentverfolgung: Instruments zur einfachen oder automatischen Verfolgung von Metadaten (Parametern und Metriken) und Artefakten (trainierte Modelle, Berichte, Diagramme) ermöglichten die Ausführung von Information Science-Quellcode. Wir gebrauchen MLflow-Tracking in der Fallstudie. Eine Übersicht der Instruments finden Sie hier Hier.
6. Modellshop/Registrierung: Eine Reihe von Instruments zur Verwaltung des ML-Modelllebenszyklus. Es versioniert und kommentiert Modelle und verbindet das Modell mit den Trainingsmetadaten. Wir benutzen das MLflow-Modellregistrierung. Weitere Lösungen sind aufgeführt Hier.
7. Modelldienst: Ein standardisierter Dienst oder Modul, das ML-Modelle lädt, ermöglicht die Durchführung von Inferenzen über eine standardisierte API. In der Fallstudie werden Modelle als Internet-Companies bereitgestellt. Wir nutzen den Scoring-Server von MLflow-Modelle die erweitert wurde, um mit unserem Überwachungsdienst integriert zu werden. MLflow-Angebote Seldon ML-ServerApache Spark, AWS SageMaker und Azure ML als various Bereitstellungsmethoden.
8. Modellüberwachung: Ein Dienst, der die Eingabe- oder Ausgabebeispiele bereitgestellter ML-Modelle nutzt und sie mit den Daten zur Trainingszeit vergleicht, um festzustellen, ob ein signifikanter Unterschied (Drift) besteht. Metriken wie die Driftwahrscheinlichkeit werden in den Komponenten der Überwachungsinfrastruktur veröffentlicht. Wir haben einen benutzerdefinierten Webdienst entwickelt, der verwendet Alibi-Erkennung um Kennzahlen zu berechnen.

Maschinelles Lernen hat die Problemlösung revolutioniert, aber die Erstellung und Bereitstellung von ML-Modellen erfordert eine kontinuierliche Verwaltung. Hier kommt MLOps ins Spiel. Es rationalisiert den ML-Lebenszyklus, indem es die Komplexität von Abläufen reduziert und Information-Science-Initiativen beschleunigt. Durch die Bewältigung von Herausforderungen wie Modellverfall, Datenkontrolle, Überwachung und Qualifikationsanforderungen ist MLOps von entscheidender Bedeutung, um die Kontrolle (wieder) zu erlangen und ML-Anwendungen zu skalieren.

Eine Fallstudie aus der Praxis zeigte die Herausforderungen bei der Verwaltung von ML-Anwendungen. Der vorgestellte MLOps-Lösungsentwurf hat sich in der Produktion bewährt und geht auf alle in der Fallstudie identifizierten Hauptprobleme ein:

• Automatisierte Modellpipelines: Datenvorbereitung, Modellschulung und -validierung, Paketierung und Bereitstellung werden für jedes Modell automatisiert und standardisiert. Wenn aktualisierte Trainingsdaten zur Verfügung gestellt werden (manuell kuratiert oder automatisch von einem Suggestions-System gesammelt), können DevOps-Ingenieure Modelle neu trainieren und bereitstellen ohne spezifische ML-Kenntnisse oder tiefes Anwendungs-Know-how.
• Automatisierte Bereitstellung: Alle ML-Anwendungen verwenden dasselbe Standardmodell als Servierkomponente. Zusammen mit der kontinuierlichen Bereitstellung werden Betrieb und Wartung erheblich vereinfacht.
• Überwachung: Ein Überwachungsdienst ermöglicht die Überwachung aller eingesetzten Modelle auf Verfall. Die Integration erfolgt in der Modellbereitstellungskomponente. Daher können alle ML-Modelle auf Modellverfall überwacht werden.
• Reproduzierbarkeit: Metadaten und Artefakte aller Modelltrainingsläufe werden aufgezeichnet, Gewährleistung der Reproduzierbarkeit Und Unterstützung von Datenwissenschaftlern bei der Entwicklung neuer Modelle.

Der Übergang zu einem MLOps-Framework ist eine Investition, aber Unternehmen können während des gesamten ML-Lebenszyklus nachhaltige Leistung, Effizienz und Innovation sicherstellen und so Klarheit und Kontrolle in ihre ML-Anwendungen bringen. Seit der Umstellung ist unser Kunde eher geneigt, neue ML-Anwendungen einzuführen, und die zusätzliche Transparenz schafft Vertrauen in die Anwendungen.