Verbesserung der Stabilität und Flexibilität von ML-Pipelines bei Amazon Packaging Innovation mit Amazon SageMaker Pipelines

Um Kunden zu begeistern und Verpackungsabfall zu minimieren, muss Amazon für Milliarden von Paketen, die jedes Jahr verschickt werden, die optimale Verpackungsart auswählen. Wenn ein zerbrechlicher Artikel wie eine Kaffeetasse zu wenig geschützt wird, kommt der Artikel beschädigt an und Amazon riskiert das Vertrauen seiner Kunden. Zu viel Schutz führt zu erhöhten Kosten und überfüllten Recyclingbehältern. Bei Hunderten von Millionen verfügbaren Produkten ist ein skalierbarer Entscheidungsmechanismus erforderlich, um kontinuierlich aus Produkttests und Kundenfeedback zu lernen.

Um diese Probleme zu lösen, hat das Team von Amazon Packaging Innovation Modelle für maschinelles Lernen (ML) entwickelt, die klassifizieren, ob Produkte für Amazon-Verpackungsarten wie Mailer, Taschen oder Kartons geeignet sind oder sogar ohne zusätzliche Verpackung versendet werden könnten. Zuvor entwickelte das Team eine benutzerdefinierte Pipeline basierend auf AWS Step-Funktionen um wöchentliche Schulungen und tägliche oder monatliche Inferenzaufgaben durchzuführen. Im Laufe der Zeit bot die Pipeline jedoch nicht genügend Flexibilität, um Modelle mit neuen Architekturen auf den Markt zu bringen. Die Entwicklung für die neuen Pipelines stellte einen Overhead dar und erforderte eine Koordination zwischen Data Scientists und Entwicklern. Um diese Schwierigkeiten zu überwinden und die Geschwindigkeit der Bereitstellung neuer Modelle und Architekturen zu verbessern, entschied sich das Team für die Orchestrierung von Modelltraining und Inferenz Amazon SageMaker-Pipelines.

In diesem Beitrag diskutieren wir die frühere Orchestrierungsarchitektur basierend auf Step Functions, skizzieren Trainings- und Inferenzarchitekturen mit Pipelines und heben die Flexibilität hervor, die das Team von Amazon Packaging Innovation erreicht hat.

Herausforderungen der ehemaligen ML-Pipeline bei Amazon Packaging Innovation

Um kontinuierliches Feedback zur Leistung von Verpackungen zu integrieren, wird jede Woche ein neues Modell mit einer wachsenden Anzahl von Etiketten trainiert. Die Inferenz für den gesamten Produktbestand wird monatlich durchgeführt, und eine tägliche Inferenz wird durchgeführt, um Just-in-Time-Vorhersagen für den neu hinzugefügten Bestand zu liefern.

Um den Prozess des Trainierens mehrerer Modelle zu automatisieren und Vorhersagen bereitzustellen, hatte das Team eine benutzerdefinierte Pipeline basierend auf Step Functions entwickelt, um die folgenden Schritte zu orchestrieren:

• Datenvorbereitung für Trainings- und Inferenzjobs und Laden von Vorhersagen in die Datenbank (Amazon RedShift) mit AWS-Kleber.
• Modelltraining und Inferenz mit Amazon Sage Maker.
• Berechnung von Modellleistungsmetriken auf dem Validierungsset mit AWS-Charge.
• Die richtigen Amazon DynamoDB zum Speichern von Modellkonfigurationen (z. B. Datenaufteilungsverhältnis für Training und Validierung, Position von Modellartefakten, Modelltyp und Anzahl von Instanzen für Training und Inferenz), Modellleistungsmetriken und die neueste erfolgreich trainierte Modellversion.
• Berechnung der Unterschiede in den Modellleistungswerten, Änderungen in der Verteilung der Trainingslabels und Vergleich der Größe der Eingabedaten zwischen der vorherigen und der neuen Modellversion mit AWS Lambda Funktionen.
• Angesichts der großen Anzahl von Schritten erforderte die Pipeline auch ein zuverlässiges Alarmsystem bei jedem Schritt, um die Beteiligten auf Probleme aufmerksam zu machen. Dies wurde durch eine Kombination von erreicht Amazon Simple Queue-Dienst (Amazon SQS) und Amazon Simple Notification Service (Amazon SNS). Die Alarme wurden erstellt, um die Geschäftsbeteiligten, Datenwissenschaftler und Entwickler über fehlgeschlagene Schritte und große Abweichungen im Modell und in den Datenmetriken zu benachrichtigen.

Nachdem das Team diese Lösung fast zwei Jahre lang verwendet hatte, stellte es fest, dass diese Implementierung nur für einen typischen ML-Workflow gut funktionierte, bei dem ein einzelnes Modell trainiert und anhand eines Validierungsdatensatzes bewertet wurde. Allerdings war die Lösung für komplexe Modelle nicht flexibel genug und nicht ausfallsicher. Beispielsweise war die Architektur nicht einfach für ein sequenzielles Modelltraining geeignet. Es war schwierig, einen Schritt hinzuzufügen oder zu entfernen, ohne die gesamte Pipeline zu duplizieren und die Infrastruktur zu ändern. Selbst einfache Änderungen in den Datenverarbeitungsschritten wie die Anpassung des Datenaufteilungsverhältnisses oder die Auswahl eines anderen Satzes von Funktionen erforderten die Koordination sowohl eines Datenwissenschaftlers als auch eines Entwicklers. Wenn die Pipeline bei irgendeinem Schritt ausfiel, musste sie von Anfang an neu gestartet werden, was zu wiederholten Durchläufen und erhöhten Kosten führte. Um wiederholte Durchläufe und einen Neustart ab dem fehlgeschlagenen Schritt zu vermeiden, erstellte das Team eine neue Kopie einer gekürzten Zustandsmaschine. Diese Problembehandlung führte zu einer Verbreitung der Zustandsmaschinen, die jeweils mit den häufig fehlschlagenden Schritten begannen. Wenn schließlich bei einem Schulungsjob eine Abweichung in der Verteilung der Labels, der Modellpunktzahl oder der Anzahl der Labels festgestellt wurde, musste ein Data Scientist das Modell und seine Metriken manuell überprüfen. Dann greift ein Data Scientist auf eine DynamoDB-Tabelle mit den Modellversionen zu und aktualisiert die Tabelle, um sicherzustellen, dass das richtige Modell für den nächsten Inferenzjob verwendet wird.

Die Wartung dieser Architektur erforderte mindestens eine dedizierte Ressource und eine zusätzliche Vollzeit-Ressource für die Entwicklung. Angesichts der Schwierigkeiten bei der Erweiterung der Pipeline für neue Anwendungsfälle hatten die Data Scientists begonnen, ihre eigenen Workflows zu entwickeln, was wiederum zu einer wachsenden Codebasis, mehreren Datentabellen mit ähnlichen Datenschemata und einer dezentralisierten Modellüberwachung geführt hatte. Die Anhäufung dieser Probleme hatte zu einer geringeren Teamproduktivität und einem erhöhten Overhead geführt.

Um diesen Herausforderungen zu begegnen, hat das Team von Amazon Packaging Innovation andere bestehende Lösungen für MLOps evaluiert, einschließlich SageMaker Pipelines (Ankündigung der Veröffentlichung im Dezember 2020). Pipelines ist eine Funktion von SageMaker zum Erstellen, Verwalten, Automatisieren und Skalieren von End-to-End-ML-Workflows. Mit Pipelines können Sie die Anzahl der Schritte im gesamten ML-Workflow reduzieren und sind flexibel genug, um Data Scientists die Definition eines benutzerdefinierten ML-Workflows zu ermöglichen. Es kümmert sich um die Überwachung und Protokollierung der Schritte. Es wird auch mit einer Modellregistrierung geliefert, die neue Modelle automatisch versioniert. Die Modellregistrierung verfügt über integrierte Genehmigungsworkflows, um Modelle für die Inferenz in der Produktion auszuwählen. Pipelines ermöglichen auch das Zwischenspeichern von Schritten, die mit denselben Argumenten aufgerufen werden. Wenn ein vorheriger Lauf gefunden wird, wird ein Cache erstellt, der einen einfachen Neustart ermöglicht, anstatt die erfolgreich abgeschlossenen Schritte neu zu berechnen.

Im Bewertungsprozess hob sich Pipelines von den anderen Lösungen durch seine Flexibilität und Verfügbarkeit von Funktionen zur Unterstützung und Erweiterung aktueller und zukünftiger Arbeitsabläufe ab. Der Wechsel zu Pipelines sparte den Entwicklern Zeit von der Plattformwartung und Fehlerbehebung und lenkte die Aufmerksamkeit auf die Hinzufügung der neuen Funktionen. In diesem Beitrag stellen wir das Design für Schulungs- und Inferenz-Workflows beim Amazon Packaging Innovation-Team mit Pipelines vor. Wir besprechen auch die Vorteile und die Kostensenkung, die das Team durch den Wechsel zu Pipelines realisiert hat.

Trainingspipeline

Das Team von Amazon Packaging Innovation trainiert Modelle für jeden Verpackungstyp mit einer wachsenden Anzahl von Etiketten. Das folgende Diagramm skizziert den gesamten Prozess.

Der Workflow beginnt mit dem Extrahieren von Labels und Merkmalen aus einer Amazon Redshift-Datenbank und dem Entladen der Daten in Amazon Simple Storage-Service (Amazon S3) über einen geplanten Auftrag zum Extrahieren, Transformieren und Laden (ETL). Zusammen mit den Eingabedaten wird ein Dateiobjekt mit dem Modelltyp und den Parametern im S3-Bucket platziert. Diese Datei dient über eine Lambda-Funktion als Pipeline-Trigger.

Die nächsten Schritte sind vollständig anpassbar und werden vollständig von einem Datenwissenschaftler mithilfe des SageMaker Python SDK for Pipelines definiert. In dem Szenario, das wir in diesem Beitrag vorstellen, werden die Eingabedaten in Trainings- und Validierungssätze aufgeteilt und wieder in einem S3-Bucket gespeichert, indem ein SageMaker-Verarbeitungsjob gestartet wird.

Wenn die Daten in Amazon S3 bereit sind, startet ein SageMaker-Trainingsjob. Nachdem das Modell erfolgreich trainiert und erstellt wurde, wird der Modellauswertungsschritt für die Validierungsdaten über einen SageMaker-Batch-Transformationsauftrag durchgeführt. Die Modellmetriken werden dann mithilfe eines SageMaker-Verarbeitungsjobs mit den Modellmetriken der Vorwoche verglichen. Das Team hat mehrere benutzerdefinierte Kriterien zur Bewertung von Abweichungen in der Modellleistung definiert. Basierend auf diesen Kriterien wird das Modell entweder abgelehnt oder genehmigt. Wenn das Modell abgelehnt wird, wird das zuvor genehmigte Modell für die nächsten Inferenzjobs verwendet. Wenn das Modell genehmigt wird, wird seine Version registriert und dieses Modell wird für Inferenzaufträge verwendet. Die Stakeholder erhalten eine Benachrichtigung über das Ergebnis per Amazon CloudWatch Alarm.

Der folgende Screenshot von Amazon SageMaker-Studio zeigt die Schritte der Trainingspipeline.

Pipelines verfolgt jede Pipelineausführung, die Sie in Studio überwachen können. Alternativ können Sie mit den Fortschritt des Laufs abfragen Boto3 oder im AWS-Befehlszeilenschnittstelle (AWS-CLI). Sie können die Modellmetriken in Studio visualisieren und verschiedene Modellversionen vergleichen.

Inferenzpipeline

Das Team von Amazon Packaging Innovation aktualisiert die Vorhersagen für den gesamten Produktbestand monatlich. Tägliche Vorhersagen werden generiert, um mithilfe des neuesten trainierten Modells Just-in-Time-Verpackungsempfehlungen für neu hinzugefügte Bestände bereitzustellen. Dies erfordert, dass die Inferenzpipeline täglich mit unterschiedlichen Datenmengen ausgeführt wird. Das folgende Diagramm veranschaulicht diesen Workflow.

Ähnlich wie bei der Trainingspipeline beginnt die Inferenz mit dem Entladen der Daten von Amazon Redshift in einen S3-Bucket. Ein in Amazon S3 platziertes Dateiobjekt löst die Lambda-Funktion aus, die die Inferenzpipeline initiiert. Die Merkmale werden für die Inferenz vorbereitet, und die Daten werden mithilfe eines SageMaker-Verarbeitungsauftrags in Dateien geeigneter Größe aufgeteilt. Als Nächstes identifiziert die Pipeline das neueste genehmigte Modell, um die Vorhersagen auszuführen und sie in einen S3-Bucket zu laden. Schließlich werden die Vorhersagen mithilfe der boto3-data-API innerhalb des SageMaker-Verarbeitungsjobs zurück in Amazon Redshift geladen.

Der folgende Screenshot aus Studio zeigt die Details der Inferenzpipeline.

Vorteile der Entscheidung, ML-Workflows mit SageMaker Pipelines zu entwerfen

In diesem Abschnitt diskutieren wir die Vorteile, die das Team von Amazon Packaging Innovation durch den Wechsel zu Pipelines für Modelltraining und Inferenz erzielt hat.

Sofort einsatzbereite MLOps-Funktionen auf Produktionsebene

Beim Vergleich verschiedener interner und externer Lösungen für die nächste ML-Pipeline-Lösung konnte ein einzelner Datenwissenschaftler in weniger als 3 Wochen eine Vollversion eines ML-Workflows mit Pipelines in einer Studio-Jupyter-Umgebung prototypisieren und entwickeln. Bereits in der Prototyping-Phase wurde deutlich, dass Pipelines alle notwendigen Infrastrukturkomponenten bereitstellt, die für einen Workflow auf Produktionsebene erforderlich sind: Modellversionierung, Caching und Alarme. Die sofortige Verfügbarkeit dieser Funktionen bedeutete, dass keine zusätzliche Zeit für deren Entwicklung und Anpassung aufgewendet werden musste. Dies war eine klare Wertdemonstration, die das Team von Amazon Packaging Innovation davon überzeugte, dass Pipelines die richtige Lösung war.

Flexibilität bei der Entwicklung von ML-Modellen

Der größte Gewinn für die Datenwissenschaftler im Team war die Möglichkeit, einfach zu experimentieren und verschiedene Modelle zu durchlaufen. Unabhängig davon, welches Framework sie für ihre ML-Arbeit bevorzugten und wie viele Schritte und Funktionen damit verbunden waren, Pipelines erfüllte ihre Anforderungen. Die Data Scientists konnten experimentieren, ohne auf den Softwareentwicklungssprint warten zu müssen, um eine zusätzliche Funktion oder einen zusätzlichen Schritt hinzuzufügen.

Reduzierte Kosten

Die Pipelines-Funktion von SageMaker ist kostenlos: Sie zahlen nur für die Rechenressourcen und den Speicher, der mit Training und Inferenz verbunden ist. Wenn Sie jedoch über die Kosten nachdenken, müssen Sie nicht nur die Kosten der verwendeten Dienste berücksichtigen, sondern auch die Entwicklerstunden, die für die Wartung des Workflows, das Debuggen und das Patchen benötigt werden. Die Orchestrierung mit Pipelines ist einfacher, da sie aus weniger Teilen und einer vertrauten Infrastruktur besteht. Früher waren für das Hinzufügen einer neuen Funktion mindestens zwei Personen (Data Scientist und Software Engineer) im Amazon Packaging Innovation Team erforderlich, um sie zu implementieren. Mit der neu gestalteten Pipeline richten sich die Engineering-Bemühungen nun auf zusätzliche benutzerdefinierte Infrastruktur rund um die Pipeline, wie z. B. die Erstellung eines einzigen Repositorys zur Verfolgung des maschinellen Lerncodes, die Vereinfachung der Modellbereitstellung über AWS-Konten hinweg, die Entwicklung der integrierten ETL-Jobs und Common Wiederverwendbare Funktionen.

Die Möglichkeit, die Schritte mit einer ähnlichen Eingabe zwischenzuspeichern, trug ebenfalls zur Kostenreduzierung bei, da es weniger wahrscheinlich war, dass die Teams die gesamte Pipeline erneut ausführten. Stattdessen könnten sie es leicht an der Stelle des Scheiterns beginnen.

Zusammenfassung

Das Team von Amazon Packaging Innovation trainiert monatlich ML-Modelle und aktualisiert regelmäßig Vorhersagen für die empfohlenen Produktverpackungstypen. Diese Empfehlungen halfen ihnen, mehrere team- und unternehmensweite Ziele zu erreichen, indem sie Verschwendung reduzierten und Kunden mit jeder Bestellung begeisterten. Die Trainings- und Inferenzpipelines müssen regelmäßig zuverlässig laufen und dennoch eine ständige Verbesserung der Modelle ermöglichen.

Der Übergang zu Pipelines ermöglichte es dem Team, vier neue multimodale Modellarchitekturen in weniger als zwei Monaten für die Produktion bereitzustellen. Die Bereitstellung eines neuen Modells mit der vorherigen Architektur hätte 2 Tage (mit derselben Modellarchitektur) bis 5 Monat (mit einer neuen Modellarchitektur) gedauert. Durch die Bereitstellung desselben Modells mit Pipelines konnte das Team die Entwicklungszeit auf 1 Stunden mit derselben Modellarchitektur und auf 4 Tage mit einer neuen Modellarchitektur verkürzen. Das entspricht einer Einsparung von fast 5 % der Arbeitszeit.

Zusätzliche Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

---

Über die Autoren

Ankur Shukla ist Principal Data Scientist bei AWS-ProServe mit Sitz in Palo Alto. Ankur verfügt über mehr als 15 Jahre Beratungserfahrung in der direkten Zusammenarbeit mit Kunden und hilft ihnen bei der Lösung von Geschäftsproblemen mit Technologie. Er leitet mehrere globale Initiativen für angewandte Wissenschaft und ML-Ops innerhalb von AWS. In seiner Freizeit liest er gerne und verbringt Zeit mit der Familie.

Akash Singla ist Senior System Dev Engineer im Amazon Packaging Innovation Team. Er verfügt über mehr als 17 Jahre Erfahrung in der Lösung kritischer Geschäftsprobleme durch Technologie für mehrere Branchen. Derzeit konzentriert er sich auf die Aktualisierung der NAWS-Infrastruktur für eine Vielzahl von paketorientierten Anwendungen, um sie besser zu skalieren.

Vitalina Komaschko ist Data Scientist bei AWS Professional Services. Sie hat in Pharmakologie und Toxikologie promoviert, wechselte aber von der experimentellen Arbeit zur Datenwissenschaft, weil sie „die Datengenerierung und die Interpretation der Ergebnisse besitzen wollte“. Zu Beginn ihrer Karriere arbeitete sie bei Biotech- und Pharmaunternehmen. Bei AWS löst sie gerne Probleme für Kunden aus verschiedenen Branchen und lernt etwas über ihre einzigartigen Herausforderungen.

Prashant Meiyappan ist seit über 4 Jahren Senior Applied Scientist bei Amazon Packaging Innovation. Er verfügt über mehr als 6 Jahre Branchenerfahrung im maschinellen Lernen und hat Produkte ausgeliefert, um die Suchkundenerfahrung und die Kundenverpackungserfahrung zu verbessern. Prasanth engagiert sich leidenschaftlich für Nachhaltigkeit und hat in statistischer Modellierung des Klimawandels promoviert.

Matthäus Bales ist Senior Research Scientist und arbeitet an der Optimierung der Verpackungstypauswahl mithilfe von Kundenfeedback und maschinellem Lernen. Vor Amazon arbeitete Matt als Postdoc, der Simulationen der Teilchenphysik in Deutschland durchführte, und in einem früheren Leben als Produktionsleiter von radioaktiven medizinischen Implantatgeräten in einem Startup. Er hat einen Ph.D. in Physik von der University of Michigan.