Wie Axfood mit Amazon SageMaker | beschleunigtes maschinelles Lernen im gesamten Unternehmen ermöglicht Amazon Web Services

Dies ist ein Gastbeitrag von Axfood AB. 

In diesem Beitrag teilen wir mit, wie Axfood, ein großer schwedischer Lebensmitteleinzelhändler, den Betrieb und die Skalierbarkeit seiner bestehenden Abläufe im Bereich der künstlichen Intelligenz (KI) und des maschinellen Lernens (ML) durch Prototyping in enger Zusammenarbeit mit AWS-Experten und deren Einsatz verbessert hat Amazon Sage Maker.

Axtfutter ist Schwedens zweitgrößter Lebensmitteleinzelhändler mit über 13,000 Mitarbeitern und mehr als 300 Filialen. Axfood verfügt über eine Struktur mit mehreren dezentralen Data-Science-Teams mit unterschiedlichen Verantwortungsbereichen. Gemeinsam mit einem zentralen Datenplattform-Team bringen die Data-Science-Teams Innovation und digitale Transformation durch KI- und ML-Lösungen in die Organisation. Axfood nutzt Amazon SageMaker, um seine Daten mithilfe von ML zu kultivieren, und verfügt bereits seit vielen Jahren über Modelle in der Produktion. In letzter Zeit nehmen der Grad der Raffinesse und die schiere Anzahl der produzierten Modelle exponentiell zu. Obwohl das Innovationstempo hoch ist, hatten die verschiedenen Teams ihre eigenen Arbeitsweisen entwickelt und waren auf der Suche nach einer neuen Best Practice für MLOps.

Unsere Herausforderung

Um in Bezug auf Cloud-Dienste und KI/ML wettbewerbsfähig zu bleiben, hat sich Axfood für eine Partnerschaft mit AWS entschieden und arbeitet seit vielen Jahren mit ihnen zusammen.

Während einer unserer wiederkehrenden Brainstorming-Sitzungen mit AWS diskutierten wir darüber, wie wir am besten teamübergreifend zusammenarbeiten können, um das Innovationstempo und die Effizienz von Datenwissenschafts- und ML-Praktikern zu erhöhen. Wir haben beschlossen, gemeinsam einen Prototyp auf der Grundlage einer Best Practice für MLOps zu erstellen. Ziel des Prototyps war es, eine Modellvorlage für alle Data-Science-Teams zu erstellen, um skalierbare und effiziente ML-Modelle zu erstellen – die Grundlage für eine neue Generation von KI- und ML-Plattformen für Axfood. Die Vorlage sollte Best Practices von AWS-ML-Experten und unternehmensspezifische Best-Practice-Modelle verbinden und kombinieren – das Beste aus beiden Welten.

Wir haben uns entschieden, einen Prototyp aus einem der derzeit am weitesten entwickelten ML-Modelle innerhalb von Axfood zu bauen: Prognose der Umsätze in Geschäften. Genauer gesagt, die Prognose für Obst und Gemüse kommender Kampagnen für Lebensmitteleinzelhandelsgeschäfte. Präzise tägliche Prognosen unterstützen den Bestellprozess in den Filialen und erhöhen die Nachhaltigkeit durch Minimierung der Lebensmittelverschwendung und Optimierung des Umsatzes durch genaue Vorhersage der benötigten Lagerbestände im Geschäft. Dies war der perfekte Ausgangspunkt für unseren Prototypen – Axfood würde nicht nur eine neue KI/ML-Plattform erhalten, sondern wir würden auch die Chance bekommen, unsere ML-Fähigkeiten zu vergleichen und von führenden AWS-Experten zu lernen.

Unsere Lösung: Eine neue ML-Vorlage auf Amazon SageMaker Studio

Der Aufbau einer vollständigen ML-Pipeline, die auf einen tatsächlichen Geschäftsfall ausgelegt ist, kann eine Herausforderung sein. In diesem Fall entwickeln wir ein Prognosemodell, daher müssen zwei Hauptschritte durchgeführt werden:

1. Trainieren Sie das Modell, um anhand historischer Daten Vorhersagen zu treffen.
2. Wenden Sie das trainierte Modell an, um Vorhersagen über zukünftige Ereignisse zu treffen.

Im Fall von Axfood wurde zu diesem Zweck bereits eine gut funktionierende Pipeline mithilfe von SageMaker-Notebooks eingerichtet und von der Workflow-Management-Plattform Airflow eines Drittanbieters orchestriert. Die Modernisierung und Umstellung unserer ML-Plattform bietet jedoch viele klare Vorteile Amazon SageMaker-Studio und Amazon SageMaker-Pipelines. Der Wechsel zu SageMaker Studio bietet viele vordefinierte, sofort einsatzbereite Funktionen:

• Überwachung der Modell- und Datenqualität sowie der Erklärbarkeit des Modells
• Integrierte Tools der integrierten Entwicklungsumgebung (IDE) wie Debugging
• Kosten-/Leistungsüberwachung
• Modellakzeptanzrahmen
• Modellregistrierung

Der wichtigste Anreiz für Axfood ist jedoch die Möglichkeit, benutzerdefinierte Projektvorlagen zu erstellen Amazon SageMaker-Projekte soll als Blaupause für alle Data-Science-Teams und ML-Praktiker dienen. Das Axfood-Team verfügte bereits über ein robustes und ausgereiftes Niveau der ML-Modellierung, daher lag das Hauptaugenmerk auf dem Aufbau der neuen Architektur.

Lösungsüberblick

Das von Axfood vorgeschlagene neue ML-Framework basiert auf zwei Hauptpipelines: die Modellerstellungspipeline und die Batch-Inferenzpipeline:

• Diese Pipelines werden in zwei separaten Git-Repositorys versioniert: einem Build-Repository und einem Deploy-(Inferenz-)Repository. Zusammen bilden sie eine robuste Pipeline für die Prognose von Obst und Gemüse.
• Die Pipelines werden mithilfe von SageMaker Projects in eine benutzerdefinierte Projektvorlage gepackt und in ein Git-Repository eines Drittanbieters (Bitbucket) und Bitbucket-Pipelines für Komponenten für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) integriert.
• Die SageMaker-Projektvorlage enthält Seed-Code, der jedem Schritt der Build- und Deploy-Pipelines entspricht (wir werden diese Schritte später in diesem Beitrag ausführlicher besprechen) sowie die Pipeline-Definition – das Rezept dafür, wie die Schritte ausgeführt werden sollen.
• Die Automatisierung der Erstellung neuer Projekte basierend auf der Vorlage wird optimiert AWS-Servicekatalog, wo ein Portfolio erstellt wird, das als Abstraktion für mehrere Produkte dient.
• Jedes Produkt führt zu einem AWS CloudFormation Vorlage, die bereitgestellt wird, wenn ein Datenwissenschaftler ein neues SageMaker-Projekt mit unserem MLOps-Blueprint als Grundlage erstellt. Dadurch wird ein aktiviert AWS Lambda Funktion, die ein Bitbucket-Projekt mit zwei Repositorys – Model Build und Model Deploy – erstellt, die den Seed-Code enthalten.

Das folgende Diagramm veranschaulicht die Lösungsarchitektur. Workflow A stellt den komplizierten Ablauf zwischen den beiden Modellpipelines dar – Build und Inferenz. Workflow B zeigt den Ablauf zum Erstellen eines neuen ML-Projekts.

Modellerstellungspipeline

Die Modellerstellungspipeline orchestriert den Lebenszyklus des Modells, angefangen bei der Vorverarbeitung über das Training bis hin zur Registrierung in der Modellregistrierung:

• Anarbeitung – Hier, der SageMaker ScriptProcessor Die Klasse wird für das Feature-Engineering verwendet und ergibt den Datensatz, auf dem das Modell trainiert wird.
• Training und Batch-Transformation – Benutzerdefinierte Trainings- und Inferenzcontainer von SageMaker werden genutzt, um das Modell anhand historischer Daten zu trainieren und mithilfe eines SageMaker Estimators und Transformers für die jeweiligen Aufgaben Vorhersagen zu den Bewertungsdaten zu erstellen.
• Evaluierung – Das trainierte Modell wird einer Bewertung unterzogen, indem die generierten Vorhersagen der Bewertungsdaten mit der Grundwahrheit verglichen werden ScriptProcessor.
• Basisjobs – Die Pipeline erstellt Baselines basierend auf Statistiken in den Eingabedaten. Diese sind für die Überwachung der Daten- und Modellqualität sowie der Merkmalszuordnungen unerlässlich.
• Modellregistrierung – Das trainierte Modell ist für die zukünftige Verwendung registriert. Das Modell wird von benannten Datenwissenschaftlern genehmigt, um das Modell für den Einsatz in der Produktion bereitzustellen.

Für Produktionsumgebungen werden Datenaufnahme und Auslösemechanismen über eine primäre Airflow-Orchestrierung verwaltet. In der Zwischenzeit wird die Pipeline während der Entwicklung jedes Mal aktiviert, wenn ein neuer Commit in das Bitbucket-Repository für die Modellerstellung eingeführt wird. Die folgende Abbildung visualisiert die Modellerstellungspipeline.

Batch-Inferenz-Pipeline

Die Batch-Inferenzpipeline übernimmt die Inferenzphase, die aus den folgenden Schritten besteht:

• Anarbeitung – Daten werden mit vorverarbeitet ScriptProcessor.
• Batch-Transformation – Das Modell verwendet den benutzerdefinierten Inferenzcontainer mit einem SageMaker-Transformer und generiert Vorhersagen anhand der vorverarbeiteten Eingabedaten. Das verwendete Modell ist das zuletzt genehmigte trainierte Modell im Modellregister.
• Nachbearbeitung – Die Vorhersagen durchlaufen eine Reihe von Nachbearbeitungsschritten ScriptProcessor.
• Netzwerk Performance – Die kontinuierliche Überwachung führt Prüfungen auf Abweichungen in Bezug auf Datenqualität, Modellqualität und Merkmalszuordnung durch.

Treten Unstimmigkeiten auf, prüft eine Geschäftslogik innerhalb des Nachverarbeitungsskripts, ob ein erneutes Training des Modells erforderlich ist. Die Pipeline soll in regelmäßigen Abständen laufen.

Das folgende Diagramm veranschaulicht die Batch-Inferenzpipeline. Workflow A entspricht der Vorverarbeitung, Datenqualitäts- und Feature-Attribution-Drift-Prüfungen, Inferenz und Nachverarbeitung. Workflow B entspricht den Driftprüfungen der Modellqualität. Diese Pipelines sind unterteilt, da die Driftprüfung der Modellqualität nur ausgeführt wird, wenn neue Ground-Truth-Daten verfügbar sind.

SageMaker Modellmonitor

Mit der Amazon SageMaker-Modellmonitor Integriert profitieren die Pipelines von einer Echtzeitüberwachung für Folgendes:

• Datenqualität – Überwacht jegliche Abweichungen oder Inkonsistenzen in den Daten
• Modellqualität – Achten Sie auf Schwankungen in der Modellleistung
• Merkmalszuordnung – Überprüft, ob sich die Merkmalszuordnungen ändern

Die Überwachung der Modellqualität erfordert Zugriff auf Ground-Truth-Daten. Obwohl es manchmal schwierig sein kann, die Wahrheit zu ermitteln, dient die Verwendung von Daten oder der Überwachung der Merkmalsattributionsdrift als kompetenter Indikator für die Modellqualität.

Konkret achtet das System im Falle einer Datenqualitätsdrift auf Folgendes:

• Konzeptdrift – Dies betrifft Änderungen in der Korrelation zwischen Input und Output, die eine Grundwahrheit erfordern
• Kovariatenverschiebung – Hier liegt der Schwerpunkt auf Veränderungen in der Verteilung unabhängiger Eingangsvariablen

Die Datendrift-Funktionalität von SageMaker Model Monitor erfasst und prüft die Eingabedaten sorgfältig und setzt Regeln und statistische Prüfungen ein. Warnungen werden immer dann ausgelöst, wenn Anomalien erkannt werden.

Parallel zur Verwendung von Datenqualitätsdriftprüfungen als Proxy für die Überwachung der Modellverschlechterung überwacht das System auch die Merkmalsattributionsdrift mithilfe des NDCG-Scores (Normalized Discounted Cumulative Gain). Dieser Wert reagiert sowohl auf Änderungen in der Rangfolge der Merkmalszuordnung als auch auf die Rohzuordnungswerte von Merkmalen. Durch die Überwachung der Drift bei der Zuordnung einzelner Merkmale und ihrer relativen Bedeutung lässt sich eine Verschlechterung der Modellqualität leicht erkennen.

Modell Erklärbarkeit

Die Erklärbarkeit von Modellen ist ein zentraler Bestandteil von ML-Bereitstellungen, da sie Transparenz bei Vorhersagen gewährleistet. Für ein detailliertes Verständnis verwenden wir Amazon SageMaker klären.

Es bietet sowohl globale als auch lokale Modellerklärungen durch eine modellunabhängige Merkmalszuordnungstechnik, die auf dem Shapley-Wertekonzept basiert. Dies wird verwendet, um zu entschlüsseln, warum während der Inferenz eine bestimmte Vorhersage getroffen wurde. Solche Erklärungen, die von Natur aus kontrastreich sind, können je nach Ausgangslage variieren. SageMaker Clarify hilft bei der Bestimmung dieser Basislinie mithilfe von K-Means oder K-Prototypen im Eingabedatensatz, der dann der Modellerstellungspipeline hinzugefügt wird. Diese Funktionalität ermöglicht es uns, in Zukunft generative KI-Anwendungen zu entwickeln, um das Verständnis der Funktionsweise des Modells zu verbessern.

Industrialisierung: Vom Prototyp zur Produktion

Das MLOps-Projekt beinhaltet einen hohen Automatisierungsgrad und kann als Blaupause für ähnliche Anwendungsfälle dienen:

• Die Infrastruktur kann vollständig wiederverwendet werden, während der Seed-Code für jede Aufgabe angepasst werden kann, wobei sich die meisten Änderungen auf die Pipeline-Definition und die Geschäftslogik für Vorverarbeitung, Training, Inferenz und Nachverarbeitung beschränken.
• Die Trainings- und Inferenzskripte werden mithilfe benutzerdefinierter SageMaker-Container gehostet, sodass eine Vielzahl von Modellen ohne Änderungen an den Daten- und Modellüberwachungs- oder Modellerklärungsschritten berücksichtigt werden können, solange die Daten im Tabellenformat vorliegen.

Nachdem wir die Arbeit am Prototyp abgeschlossen hatten, wandten wir uns der Frage zu, wie wir ihn in der Produktion einsetzen sollten. Zu diesem Zweck hielten wir es für notwendig, einige zusätzliche Anpassungen an der MLOps-Vorlage vorzunehmen:

• Der ursprüngliche Seed-Code, der im Prototyp für die Vorlage verwendet wurde, umfasste Vorverarbeitungs- und Nachverarbeitungsschritte, die vor und nach den ML-Kernschritten (Training und Inferenz) ausgeführt wurden. Bei der Skalierung, um die Vorlage für mehrere Anwendungsfälle in der Produktion zu verwenden, können die integrierten Vorverarbeitungs- und Nachverarbeitungsschritte jedoch zu einer verminderten Allgemeingültigkeit und Reproduktion des Codes führen.
• Um die Allgemeingültigkeit zu verbessern und sich wiederholenden Code zu minimieren, haben wir uns entschieden, die Pipelines noch weiter zu verschlanken. Anstatt die Vorverarbeitungs- und Nachverarbeitungsschritte als Teil der ML-Pipeline auszuführen, führen wir diese als Teil der primären Airflow-Orchestrierung vor und nach dem Auslösen der ML-Pipeline aus.
• Auf diese Weise werden anwendungsfallspezifische Verarbeitungsaufgaben von der Vorlage abstrahiert, und was übrig bleibt, ist eine zentrale ML-Pipeline, die allgemeine Aufgaben für mehrere Anwendungsfälle mit minimaler Codewiederholung ausführt. Parameter, die sich zwischen Anwendungsfällen unterscheiden, werden der ML-Pipeline von der primären Airflow-Orchestrierung als Eingabe bereitgestellt.

Das Ergebnis: Ein schneller und effizienter Ansatz für die Modellerstellung und -bereitstellung

Der Prototyp in Zusammenarbeit mit AWS hat zu einer MLOps-Vorlage geführt, die den aktuellen Best Practices folgt und nun allen Data-Science-Teams von Axfood zur Nutzung zur Verfügung steht. Durch die Erstellung eines neuen SageMaker-Projekts in SageMaker Studio können Datenwissenschaftler schnell mit neuen ML-Projekten beginnen und nahtlos in die Produktion übergehen, was ein effizienteres Zeitmanagement ermöglicht. Dies wird durch die Automatisierung mühsamer, sich wiederholender MLOps-Aufgaben als Teil der Vorlage ermöglicht.

Darüber hinaus wurden unserem ML-Setup mehrere neue Funktionalitäten automatisiert hinzugefügt. Zu diesen Gewinnen gehören:

• Modellüberwachung – Wir können Driftprüfungen für Modell- und Datenqualität sowie Modellerklärbarkeit durchführen
• Modell- und Datenherkunft – Es ist nun möglich, genau nachzuvollziehen, welche Daten für welches Modell verwendet wurden
• Modellregistrierung – Dies hilft uns, Modelle für die Produktion zu katalogisieren und Modellversionen zu verwalten

Zusammenfassung

In diesem Beitrag haben wir besprochen, wie Axfood in Zusammenarbeit mit AWS-Experten und durch den Einsatz von SageMaker und den zugehörigen Produkten den Betrieb und die Skalierbarkeit unserer bestehenden KI- und ML-Operationen verbessert hat.

Diese Verbesserungen werden den Data-Science-Teams von Axfood dabei helfen, ML-Workflows standardisierter zu gestalten, und die Analyse und Überwachung von Modellen in der Produktion erheblich vereinfachen – wodurch die Qualität der von unseren Teams erstellten und gepflegten ML-Modelle sichergestellt wird.

Bitte hinterlassen Sie Feedback oder Fragen im Kommentarbereich.

---

Über die Autoren

Dr. Björn Blomqvist ist Leiter der KI-Strategie bei Axfood AB. Bevor er zu Axfood AB kam, leitete er ein Team von Datenwissenschaftlern bei Dagab, einem Teil von Axfood, und entwickelte innovative Lösungen für maschinelles Lernen mit der Mission, Menschen in ganz Schweden mit guten und nachhaltigen Lebensmitteln zu versorgen. Geboren und aufgewachsen im Norden Schwedens, unternimmt Björn in seiner Freizeit Ausflüge in verschneite Berge und aufs offene Meer.

Oskar Klang ist Senior Data Scientist in der Analyseabteilung von Dagab, wo er gerne mit allem, was mit Analytik und maschinellem Lernen zu tun hat, arbeitet, z. B. mit der Optimierung von Lieferkettenabläufen, dem Aufbau von Prognosemodellen und neuerdings auch mit GenAI-Anwendungen. Er setzt sich dafür ein, effizientere Pipelines für maschinelles Lernen aufzubauen und so die Effizienz und Skalierbarkeit zu verbessern.

Pawel Maslow ist Senior DevOps- und ML-Ingenieur im Analytic Platforms-Team. Pavel verfügt über umfangreiche Erfahrung in der Entwicklung von Frameworks, Infrastruktur und Tools in den Bereichen DevOps und ML/AI auf der AWS-Plattform. Pavel war einer der Hauptakteure beim Aufbau der grundlegenden Fähigkeiten im Bereich ML bei Axfood.

Joakim Berg ist Teamleiter und Product Owner Analytic Platforms mit Sitz in Stockholm, Schweden. Er leitet ein Team von Datenplattform- und DevOps/MLOps-Ingenieuren, die Daten- und ML-Plattformen für die Data Science-Teams bereitstellen. Joakim verfügt über langjährige Erfahrung in der Leitung leitender Entwicklungs- und Architekturteams aus verschiedenen Branchen.

• 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/how-axfood-enables-accelerated-machine-learning-throughout-the-organization-using-amazon-sagemaker/