Erstellen Sie eine End-to-End-MLOps-Pipeline für die visuelle Qualitätsprüfung am Edge – Teil 1 | Amazon Web Services

Eine erfolgreiche Bereitstellung eines Modells für maschinelles Lernen (ML) in einer Produktionsumgebung hängt stark von einer End-to-End-ML-Pipeline ab. Obwohl die Entwicklung einer solchen Pipeline eine Herausforderung sein kann, wird sie im Umgang mit einer noch komplexer Edge-ML-Anwendungsfall. Maschinelles Lernen am Edge ist ein Konzept, das die Möglichkeit bietet, ML-Modelle lokal auf Edge-Geräten auszuführen. Um diese Modelle am Edge bereitzustellen, zu überwachen und zu warten, ist eine robuste MLOps-Pipeline erforderlich. Eine MLOps-Pipeline ermöglicht die Automatisierung des gesamten ML-Lebenszyklus von der Datenkennzeichnung bis zum Modelltraining und der Bereitstellung.

Die Implementierung einer MLOps-Pipeline am Edge führt zu zusätzlichen Komplexitäten, die die Automatisierungs-, Integrations- und Wartungsprozesse aufgrund des damit verbundenen höheren Betriebsaufwands schwieriger machen. Durch die Verwendung speziell entwickelter Dienste wie z Amazon Sage Maker und AWS IoT Greengrass können Sie diesen Aufwand deutlich reduzieren. In dieser Serie führen wir Sie durch den Prozess der Architektur und des Aufbaus einer integrierten End-to-End-MLOps-Pipeline für einen Computer-Vision-Anwendungsfall am Edge mit SageMaker, AWS IoT Greengrass und dem AWS Cloud-Entwicklungskit (AWS-CDK).

Dieser Beitrag konzentriert sich auf den Entwurf der gesamten MLOps-Pipeline-Architektur; Teil 2 und Teil 3 Der Schwerpunkt dieser Serie liegt auf der Umsetzung der einzelnen Komponenten. Im beiliegenden Dokument haben wir eine Beispielimplementierung bereitgestellt GitHub-Repository damit du es selbst ausprobieren kannst. Wenn Sie gerade erst mit MLOps am Edge auf AWS beginnen, lesen Sie weiter MLOps am Rand mit Amazon SageMaker Edge Manager und AWS IoT Greengrass für einen Überblick und eine Referenzarchitektur.

Anwendungsfall: Überprüfung der Qualität von Metallschildern

Als ML-Ingenieur ist es wichtig, den Geschäftsfall zu verstehen, an dem Sie arbeiten. Bevor wir uns also mit der MLOps-Pipeline-Architektur befassen, schauen wir uns den Beispielanwendungsfall für diesen Beitrag an. Stellen Sie sich eine Produktionslinie eines Herstellers vor, der Metallanhänger graviert, um individuelle Gepäckanhänger herzustellen. Der Qualitätssicherungsprozess ist kostspielig, da die Rohmetallanhänger manuell auf Mängel wie Kratzer überprüft werden müssen. Um diesen Prozess effizienter zu gestalten, nutzen wir ML, um fehlerhafte Tags frühzeitig im Prozess zu erkennen. Dies trägt dazu bei, kostspielige Mängel in späteren Phasen des Produktionsprozesses zu vermeiden. Das Modell soll mögliche Defekte wie Kratzer nahezu in Echtzeit erkennen und markieren. In Fertigungsumgebungen müssen Sie sich oft mit fehlender Konnektivität oder eingeschränkter Bandbreite und erhöhter Latenz auseinandersetzen. Daher möchten wir eine hochmoderne ML-Lösung für die visuelle Qualitätsprüfung implementieren, die lokal in der Werkstatt Rückschlüsse ziehen und die Anforderungen an die Konnektivität senken kann. Um unser Beispiel einfach zu halten, trainieren wir ein Modell, das erkannte Kratzer mit Begrenzungsrahmen markiert. Das folgende Bild ist ein Beispiel eines Tags aus unserem Datensatz mit drei markierten Kratzern.

Definieren der Pipeline-Architektur

Wir haben jetzt Klarheit über unseren Anwendungsfall und das spezifische ML-Problem gewonnen, das wir angehen wollen und bei dem es um die Objekterkennung am Rand geht. Jetzt ist es an der Zeit, eine Architektur für unsere MLOps-Pipeline zu entwerfen. Zum jetzigen Zeitpunkt betrachten wir noch keine Technologien oder spezifischen Dienstleistungen, sondern vielmehr die hochrangigen Komponenten unserer Pipeline. Für eine schnelle Umschulung und Bereitstellung müssen wir den gesamten End-to-End-Prozess automatisieren: von der Datenkennzeichnung über das Training bis hin zur Inferenz. Es gibt jedoch einige Herausforderungen, die das Einrichten einer Pipeline für einen Randfall besonders schwierig machen:

• Der Aufbau verschiedener Teile dieses Prozesses erfordert unterschiedliche Fähigkeiten. Datenkennzeichnung und -schulung haben beispielsweise einen starken Fokus auf Datenwissenschaft, die Edge-Bereitstellung erfordert einen Internet-of-Things-Spezialisten (IoT) und die Automatisierung des gesamten Prozesses wird normalerweise von jemandem mit DevOps-Kenntnissen durchgeführt.
• Abhängig von Ihrer Organisation kann dieser gesamte Prozess sogar von mehreren Teams implementiert werden. Für unseren Anwendungsfall gehen wir davon aus, dass separate Teams für die Kennzeichnung, Schulung und Bereitstellung verantwortlich sind.
• Mehr Rollen und Fähigkeiten bedeuten unterschiedliche Anforderungen an Werkzeuge und Prozesse. Beispielsweise möchten Datenwissenschaftler möglicherweise ihre vertraute Notebook-Umgebung überwachen und damit arbeiten. MLOps-Ingenieure möchten mit IaC-Tools (Infrastructure as Code) arbeiten und sind möglicherweise besser damit vertraut AWS-Managementkonsole.

Was bedeutet das für unsere Pipeline-Architektur?

Zunächst ist es wichtig, die Hauptkomponenten des End-to-End-Systems klar zu definieren, das es verschiedenen Teams ermöglicht, unabhängig voneinander zu arbeiten. Zweitens müssen klar definierte Schnittstellen zwischen Teams definiert werden, um die Effizienz der Zusammenarbeit zu verbessern. Diese Schnittstellen tragen dazu bei, Störungen zwischen den Teams zu minimieren und ermöglichen es ihnen, ihre internen Prozesse nach Bedarf zu ändern, solange sie sich an die definierten Schnittstellen halten. Das folgende Diagramm veranschaulicht, wie dies für unsere Computer-Vision-Pipeline aussehen könnte.

Schauen wir uns die Gesamtarchitektur der MLOps-Pipeline im Detail an:

1. Der Prozess beginnt mit einer Sammlung von Rohbildern von Metalletiketten, die mit einer Edge-Kamera in der Produktionsumgebung erfasst werden, um einen ersten Trainingsdatensatz zu bilden.
2. Der nächste Schritt besteht darin, diese Bilder zu beschriften und Fehler mithilfe von Begrenzungsrahmen zu markieren. Es ist wichtig, den gekennzeichneten Datensatz zu versionieren, um die Rückverfolgbarkeit und Verantwortlichkeit für die verwendeten Trainingsdaten sicherzustellen.
3. Nachdem wir einen beschrifteten Datensatz haben, können wir mit dem Training, der Feinabstimmung, der Bewertung und der Versionierung unseres Modells fortfahren.
4. Wenn wir mit der Leistung unseres Modells zufrieden sind, können wir das Modell auf einem Edge-Gerät bereitstellen und Live-Inferenzen am Edge ausführen.
5. Während das Modell in Produktion läuft, generiert das Edge-Kameragerät wertvolle Bilddaten, die bisher nicht sichtbare Fehler und Edge-Cases enthalten. Wir können diese Daten nutzen, um die Leistung unseres Modells weiter zu verbessern. Um dies zu erreichen, speichern wir Bilder, für die das Modell mit geringer Zuverlässigkeit vorhersagt oder fehlerhafte Vorhersagen trifft. Diese Bilder werden dann wieder unserem Rohdatensatz hinzugefügt, wodurch der gesamte Prozess erneut eingeleitet wird.

Es ist wichtig zu beachten, dass die Rohbilddaten, der beschriftete Datensatz und das trainierte Modell als klar definierte Schnittstellen zwischen den verschiedenen Pipelines dienen. MLOps-Ingenieure und Datenwissenschaftler haben die Flexibilität, die Technologien in ihren Pipelines auszuwählen, solange sie diese Artefakte konsistent produzieren. Am wichtigsten ist, dass wir eine geschlossene Feedbackschleife etabliert haben. Fehlerhafte oder ungenügende Vorhersagen in der Produktion können dazu genutzt werden, unseren Datensatz regelmäßig zu erweitern und das Modell automatisch neu zu trainieren und zu verbessern.

Zielarchitektur

Nachdem die High-Level-Architektur nun etabliert ist, ist es an der Zeit, eine Ebene tiefer zu gehen und zu prüfen, wie wir diese mit AWS-Services aufbauen können. Beachten Sie, dass die in diesem Beitrag gezeigte Architektur davon ausgeht, dass Sie die volle Kontrolle über den gesamten Data-Science-Prozess übernehmen möchten. Wenn Sie jedoch gerade erst mit der Qualitätsprüfung am Rande beginnen, empfehlen wir Ihnen Amazon Lookout für Vision. Es bietet eine Möglichkeit, Ihr eigenes Qualitätsprüfmodell zu trainieren, ohne ML-Code erstellen, warten oder verstehen zu müssen. Weitere Informationen finden Sie unter Amazon Lookout for Vision unterstützt jetzt die visuelle Inspektion von Produktfehlern am Rand.

Wenn Sie jedoch die volle Kontrolle übernehmen möchten, zeigt das folgende Diagramm, wie eine Architektur aussehen könnte.

Lassen Sie uns ähnlich wie zuvor den Workflow Schritt für Schritt durchgehen und ermitteln, welche AWS-Services unseren Anforderungen entsprechen:

1. Amazon Simple Storage-Service (Amazon S3) wird zum Speichern von Rohbilddaten verwendet, da es uns eine kostengünstige Speicherlösung bietet.
2. Der Etikettierungsworkflow wird mit orchestriert AWS Step-Funktionen, eine serverlose Workflow-Engine, die es einfach macht, die Schritte des Etikettierungs-Workflows zu orchestrieren. Im Rahmen dieses Workflows verwenden wir Amazon Sagemaker Ground Truth die Etikettierung mithilfe von Etikettieraufträgen und verwalteten menschlichen Arbeitskräften vollständig zu automatisieren. AWS Lambda wird verwendet, um die Daten vorzubereiten, die Etikettierungsaufträge zu starten und die Etiketten zu speichern Amazon SageMaker Feature Store.
3. Der SageMaker Feature Store speichert die Beschriftungen. Es ermöglicht uns die zentrale Verwaltung und gemeinsame Nutzung unserer Funktionen und stellt uns integrierte Funktionen zur Datenversionierung zur Verfügung, die unsere Pipeline robuster machen.
4. Wir orchestrieren die Modellbildungs- und Trainingspipeline mithilfe von Amazon SageMaker-Pipelines. Es lässt sich über integrierte Schritte in die anderen erforderlichen SageMaker-Funktionen integrieren. SageMaker-Schulungsjobs werden verwendet, um das Modelltraining zu automatisieren, und SageMaker Processing-Jobs werden zur Aufbereitung der Daten und zur Bewertung der Modellleistung verwendet. In diesem Beispiel verwenden wir die Ultralytics YOLOv8 Python-Paket- und Modellarchitektur zum Trainieren und Exportieren eines Objekterkennungsmodells in die ONNX ML-Modellformat für Portabilität.
5. Wenn die Leistung akzeptabel ist, wird das trainierte Modell registriert Amazon SageMaker-Modellregistrierung mit angehängter inkrementeller Versionsnummer. Es fungiert als unsere Schnittstelle zwischen den Modelltrainings- und Edge-Bereitstellungsschritten. Auch den Zulassungsstand von Modellen verwalten wir hier. Ähnlich wie bei den anderen genutzten Diensten ist es vollständig verwaltet, sodass wir uns nicht um den Betrieb unserer eigenen Infrastruktur kümmern müssen.
6. Der Edge-Deployment-Workflow wird mithilfe von Schrittfunktionen automatisiert, ähnlich dem Labeling-Workflow. Wir können die API-Integrationen von Step Functions verwenden, um die verschiedenen erforderlichen AWS-Service-APIs wie AWS IoT Greengrass einfach aufzurufen, um neue Modellkomponenten zu erstellen und die Komponenten anschließend auf dem Edge-Gerät bereitzustellen.
7. Als Edge-Geräte-Laufzeitumgebung wird AWS IoT Greengrass verwendet. Es verwaltet den Bereitstellungslebenszyklus für unsere Modell- und Inferenzkomponenten am Edge. Es ermöglicht uns die einfache Bereitstellung neuer Versionen unserer Modell- und Inferenzkomponenten mithilfe einfacher API-Aufrufe. Darüber hinaus laufen ML-Modelle am Rande normalerweise nicht isoliert; Wir können die verschiedenen nutzen AWS und community Bereitstellung von Komponenten von AWS IoT Greengrass zur Verbindung mit anderen Diensten.

Die skizzierte Architektur ähnelt unserer zuvor gezeigten High-Level-Architektur. Amazon S3, SageMaker Feature Store und SageMaker Model Registry fungieren als Schnittstellen zwischen den verschiedenen Pipelines. Um den Aufwand für den Betrieb der Lösung zu minimieren, nutzen wir, wo immer möglich, verwaltete und serverlose Dienste.

Zusammenführung zu einem robusten CI/CD-System

Die Datenkennzeichnung, das Modelltraining und die Edge-Bereitstellungsschritte sind der Kern unserer Lösung. Daher sollte jede Änderung im Zusammenhang mit dem zugrunde liegenden Code oder den zugrunde liegenden Daten in einem dieser Teile eine neue Ausführung des gesamten Orchestrierungsprozesses auslösen. Um dies zu erreichen, müssen wir diese Pipeline in ein CI/CD-System integrieren, das es uns ermöglicht, Code- und Infrastrukturänderungen automatisch aus einem versionierten Code-Repository in der Produktion bereitzustellen. Ähnlich wie bei der vorherigen Architektur ist hier die Autonomie des Teams ein wichtiger Aspekt. Das folgende Diagramm zeigt, wie dies mithilfe von AWS-Diensten aussehen könnte.

Lassen Sie uns durch die CI/CD-Architektur gehen:

1. AWS-CodeCommit fungiert als unser Git-Repository. Der Einfachheit halber haben wir in unserem bereitgestellten Beispiel die einzelnen Teile (Kennzeichnung, Modelltraining, Edge-Bereitstellung) über Unterordner in einem einzigen Git-Repository getrennt. In einem realen Szenario könnte jedes Team für jedes Teil unterschiedliche Repositorys verwenden.
2. Die Infrastrukturbereitstellung wird mithilfe des AWS CDK automatisiert und jeder Teil (Beschriftung, Schulung und Edge) erhält seine eigene AWS CDK-App, um unabhängige Bereitstellungen zu ermöglichen.
3. Die AWS CDK-Pipeline-Funktion verwendet AWS CodePipeline um die Infrastruktur und Codebereitstellungen zu automatisieren.
4. Das AWS CDK stellt für jeden Schritt zwei Code-Pipelines bereit: eine Asset-Pipeline und eine Workflow-Pipeline. Wir haben den Workflow von der Asset-Bereitstellung getrennt, um die Workflows separat starten zu können, falls keine Asset-Änderungen vorliegen (z. B. wenn neue Bilder für das Training verfügbar sind).
   • Die Asset-Code-Pipeline stellt die gesamte Infrastruktur bereit, die für die erfolgreiche Ausführung des Workflows erforderlich ist, z AWS Identity and Access Management and (IAM)-Rollen, Lambda-Funktionen und Containerbilder, die während des Trainings verwendet werden.
   • Die Workflow-Code-Pipeline führt den eigentlichen Labeling-, Trainings- oder Edge-Deployment-Workflow aus.
5. Asset-Pipelines werden automatisch beim Festschreiben sowie beim Abschluss einer vorherigen Workflow-Pipeline ausgelöst.
6. Der gesamte Prozess wird nach einem Zeitplan mithilfe eines ausgelöst Amazon EventBridge Regel für regelmäßige Umschulungen.

Mit der CI/CD-Integration ist die gesamte End-to-End-Kette nun vollständig automatisiert. Die Pipeline wird immer dann ausgelöst, wenn sich Code in unserem Git-Repository ändert, sowie nach einem Zeitplan, um Datenänderungen zu berücksichtigen.

Voraus denken

Die beschriebene Lösungsarchitektur stellt die Grundkomponenten zum Aufbau einer End-to-End-MLOps-Pipeline am Edge dar. Abhängig von Ihren Anforderungen können Sie jedoch darüber nachdenken, zusätzliche Funktionen hinzuzufügen. Nachfolgend einige Beispiele:

Zusammenfassung

In diesem Beitrag haben wir unsere Architektur für den Aufbau einer End-to-End-MLOps-Pipeline für die visuelle Qualitätsprüfung am Edge mithilfe von AWS-Services beschrieben. Diese Architektur rationalisiert den gesamten Prozess, der Datenkennzeichnung, Modellentwicklung und Edge-Bereitstellung umfasst, und ermöglicht es uns, neue Versionen des Modells schnell und zuverlässig zu trainieren und zu implementieren. Mit serverlosen und verwalteten Diensten können wir unseren Fokus auf die Bereitstellung von Geschäftswerten statt auf die Verwaltung der Infrastruktur richten.

In Teil 2 In dieser Serie werden wir eine Ebene tiefer eintauchen und uns die Implementierung dieser Architektur genauer ansehen, insbesondere die Beschriftung und den Modellaufbau. Wenn Sie direkt zum Code springen möchten, können Sie sich den beigefügten Code ansehen GitHub Repo.

---

Über die Autoren

Michael Roth ist Senior Solutions Architect bei AWS und unterstützt Fertigungskunden in Deutschland bei der Lösung ihrer geschäftlichen Herausforderungen mithilfe der AWS-Technologie. Neben Beruf und Familie interessiert er sich für Sportwagen und genießt italienischen Kaffee.

Jörg Wöhrle ist Solutions Architect bei AWS und arbeitet mit Fertigungskunden in Deutschland. Mit einer Leidenschaft für Automatisierung hat Joerg in seinem Leben vor AWS als Softwareentwickler, DevOps-Ingenieur und Site Reliability Engineer gearbeitet. Außerhalb der Cloud ist er ein ehrgeiziger Läufer und genießt die schöne Zeit mit seiner Familie. Wenn Sie also eine DevOps-Herausforderung haben oder einen Lauf machen möchten: Sagen Sie ihm Bescheid.

Johannes Langer ist Senior Solutions Architect bei AWS und arbeitet mit Unternehmenskunden in Deutschland. Johannes setzt sich leidenschaftlich dafür ein, maschinelles Lernen zur Lösung realer Geschäftsprobleme einzusetzen. Privat arbeitet Johannes gerne an Heimwerkerprojekten und verbringt gerne Zeit im Freien mit seiner Familie.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/