Forbedring af stabilitet og fleksibilitet af ML-pipelines hos Amazon Packaging Innovation med Amazon SageMaker Pipelines

For at glæde kunderne og minimere emballagespild skal Amazon vælge den optimale emballagetype for milliarder af pakker, der sendes hvert år. Hvis der bruges for lidt beskyttelse til en skrøbelig genstand som et kaffekrus, kommer varen beskadiget frem, og Amazon risikerer deres kundes tillid. Brug af for meget beskyttelse vil resultere i øgede omkostninger og overfyldte genbrugsspande. Med hundredvis af millioner af tilgængelige produkter er der behov for en skalerbar beslutningsmekanisme for løbende at lære af produkttest og kundefeedback.

For at løse disse problemer udviklede Amazon Packaging Innovation-teamet maskinlæringsmodeller (ML), der klassificerer, om produkter er egnede til Amazon-emballagetyper såsom postforsendelser, poser eller kasser, eller endda kunne sendes uden yderligere emballage. Tidligere udviklede teamet en tilpasset pipeline baseret på AWS-trinfunktioner at udføre ugentlig træning og daglige eller månedlige slutningsjob. Men med tiden gav pipelinen ikke tilstrækkelig fleksibilitet til at lancere modeller med nye arkitekturer. Udviklingen af ​​de nye rørledninger gav en overhead og krævede koordinering mellem dataforskere og udviklere. For at overvinde disse vanskeligheder og forbedre hastigheden af ​​implementeringen af ​​nye modeller og arkitekturer, valgte teamet at orkestrere modeltræning og konklusioner med Amazon SageMaker Pipelines.

I dette indlæg diskuterer vi den tidligere orkestreringsarkitektur baseret på Step Functions, skitserer trænings- og inferensarkitekturer ved hjælp af Pipelines og fremhæver den fleksibilitet, som Amazon Packaging Innovation-teamet opnåede.

Udfordringer fra den tidligere ML-pipeline hos Amazon Packaging Innovation

For at inkorporere kontinuerlig feedback om ydeevne af pakker trænes en ny model hver uge ved hjælp af et stigende antal etiketter. Konklusionen for hele beholdningen af ​​produkter udføres månedligt, og en daglig slutning udføres for at levere just-in-time forudsigelser for den nyligt tilføjede beholdning.

For at automatisere processen med at træne flere modeller og give forudsigelser, havde teamet udviklet en tilpasset pipeline baseret på Step Functions for at orkestrere følgende trin:

• Dataforberedelse til trænings- og slutningsjob og indlæsning af forudsigelser til databasen (Amazon rødforskydning) med AWS Lim.
• Modeltræning og slutning med Amazon SageMaker.
• Beregning af model performance metrics på valideringssættet med AWS batch.
• Ved brug af Amazon DynamoDB at gemme modelkonfigurationer (såsom dataopdelingsforhold for træning og validering, modelartefaktplacering, modeltype og antal forekomster til træning og inferens), modelpræstationsmålinger og den seneste veluddannede modelversion.
• Beregning af forskellene i modellens præstationsscore, ændringer i fordelingen af ​​træningsmærkerne og sammenligning af størrelsen af ​​inputdata mellem den tidligere og den nye modelversion med AWS Lambda funktioner.
• I betragtning af det store antal trin krævede pipelinen også et pålideligt alarmeringssystem ved hvert trin for at advare interessenterne om eventuelle problemer. Dette blev opnået via en kombination af Amazon Simple Queue Service (Amazon SQS) og Amazon Simple Notification Service (Amazon SNS). Alarmerne blev oprettet for at underrette forretningsinteressenter, dataforskere og udviklere om eventuelle fejlslagne trin og store afvigelser i modellen og datamålingerne.

Efter at have brugt denne løsning i næsten 2 år, indså teamet, at denne implementering kun fungerede godt for et typisk ML-workflow, hvor en enkelt model blev trænet og scoret på et valideringsdatasæt. Men løsningen var ikke tilstrækkelig fleksibel til komplekse modeller og var ikke modstandsdygtig over for fejl. For eksempel kunne arkitekturen ikke nemt rumme sekventiel modeltræning. Det var svært at tilføje eller fjerne et trin uden at duplikere hele rørledningen og ændre infrastrukturen. Selv simple ændringer i databehandlingstrinnene såsom justering af dataopdelingsforholdet eller valg af et andet sæt funktioner krævede koordinering fra både en dataforsker og en udvikler. Når rørledningen fejlede på et hvilket som helst trin, skulle den genstartes fra begyndelsen, hvilket resulterede i gentagne kørsler og øgede omkostninger. For at undgå gentagne kørsler og at skulle genstarte fra det mislykkede trin, ville teamet oprette en ny kopi af en forkortet tilstandsmaskine. Denne fejlfinding førte til en udbredelse af statsmaskinerne, der hver startede fra de almindeligvis fejlende trin. Endelig, hvis et træningsjob stødte på en afvigelse i fordelingen af ​​etiketter, modelscore eller antal etiketter, måtte en dataforsker gennemgå modellen og dens metrics manuelt. Derefter ville en dataforsker få adgang til en DynamoDB-tabel med modelversionerne og opdatere tabellen for at sikre, at den korrekte model blev brugt til det næste slutningsjob.

Vedligeholdelsen af ​​denne arkitektur krævede mindst én dedikeret ressource og en ekstra fuldtidsressource til udvikling. På grund af vanskelighederne med at udvide pipelinen til at rumme nye use cases, var dataforskerne begyndt at udvikle deres egne arbejdsgange, hvilket igen havde ført til en voksende kodebase, flere datatabeller med lignende dataskemaer og decentraliseret modelovervågning. Akkumulering af disse problemer havde resulteret i lavere teamproduktivitet og øget overhead.

For at løse disse udfordringer evaluerede Amazon Packaging Innovation-teamet andre eksisterende løsninger til MLOps, herunder SageMaker Pipelines (Udgivelsesmeddelelse i december 2020). Pipelines er en funktion i SageMaker til at bygge, administrere, automatisere og skalere end-to-end ML-arbejdsgange. Pipelines giver dig mulighed for at reducere antallet af trin på tværs af hele ML-arbejdsgangen og er fleksibel nok til at tillade dataforskere at definere en tilpasset ML-arbejdsgang. Den sørger for at overvåge og logge trinene. Den kommer også med et modelregister, der automatisk versionerer nye modeller. Modelregistret har indbyggede godkendelsesarbejdsgange til at vælge modeller til slutning i produktionen. Pipelines giver også mulighed for at cache trin kaldet med de samme argumenter. Hvis en tidligere kørsel er fundet, oprettes en cache, som giver mulighed for en nem genstart i stedet for at genberegne de gennemførte trin.

I evalueringsprocessen skilte Pipelines sig ud fra de andre løsninger for sin fleksibilitet og tilgængelighed af funktioner til at understøtte og udvide nuværende og fremtidige arbejdsgange. Skiftet til Pipelines frigjorde udviklernes tid fra platformvedligeholdelse og fejlfinding og omdirigerede opmærksomheden mod tilføjelsen af ​​de nye funktioner. I dette indlæg præsenterer vi designet til trænings- og slutningsarbejdsgange hos Amazon Packaging Innovation-teamet ved hjælp af Pipelines. Vi diskuterer også fordelene og reduktionen i omkostninger, som teamet realiserede ved at skifte til Pipelines.

Træningspipeline

Amazon Packaging Innovation-teamet træner modeller for hver pakketype ved hjælp af et stigende antal etiketter. Følgende diagram viser hele processen.

Arbejdsgangen begynder med at udtrække etiketter og funktioner fra en Amazon Redshift-database og udlæse dataene til Amazon Simple Storage Service (Amazon S3) via et planlagt udtræk, transformer og indlæs (ETL) job. Sammen med inputdataene placeres et filobjekt med modeltype og parametre i S3-bøtten. Denne fil fungerer som pipeline-trigger via en Lambda-funktion.

De næste trin kan tilpasses fuldstændigt og defineres udelukkende af en dataforsker, der bruger SageMaker Python SDK for Pipelines. I det scenarie, vi præsenterer i dette indlæg, opdeles inputdataene i trænings- og valideringssæt og gemmes tilbage i en S3-spand ved at starte et SageMaker Processing-job.

Når dataene er klar i Amazon S3, starter et SageMaker træningsjob. Efter at modellen er blevet trænet og oprettet med succes, udføres modelevalueringstrinnet på valideringsdataene via et SageMaker batch-transformationsjob. Modelmålingerne sammenlignes derefter med den foregående uges modelmålinger ved hjælp af et SageMaker Processing-job. Teamet har defineret flere tilpassede kriterier til evaluering af afvigelser i modellens ydeevne. Modellen er enten afvist eller godkendt ud fra disse kriterier. Hvis modellen afvises, bruges den tidligere godkendte model til de næste slutningsjob. Hvis modellen er godkendt, registreres dens version, og denne model bruges til slutningsjob. Interessenterne modtager besked om udfaldet via amazoncloudwatch alarmer.

Følgende skærmbillede fra Amazon SageMaker Studio viser trinene i træningspipeline.

Pipelines sporer hver pipelinekørsel, som du kan overvåge i Studio. Alternativt kan du forespørge om kørslens fremskridt vha Boto3 eller AWS kommandolinjegrænseflade (AWS CLI). Du kan visualisere modelmålingerne i Studio og sammenligne forskellige modelversioner.

Inferens pipeline

Amazon Packaging Innovation-teamet opdaterer forudsigelser for hele lageret af produkter hver måned. Daglige forudsigelser genereres for at give just-in-time emballageanbefalinger for nyligt tilføjet beholdning ved hjælp af den seneste trænede model. Dette kræver, at inferenspipelinen kører dagligt med forskellige mængder data. Følgende diagram illustrerer denne arbejdsgang.

I lighed med træningspipelinen begynder konklusionen med at losse dataene fra Amazon Redshift til en S3-spand. Et filobjekt placeret i Amazon S3 udløser Lambda-funktionen, der starter inferenspipelinen. Funktionerne er forberedt til slutninger, og dataene opdeles i passende størrelse filer ved hjælp af et SageMaker Processing-job. Dernæst identificerer pipelinen den seneste godkendte model til at køre forudsigelserne og indlæse dem i en S3-spand. Til sidst indlæses forudsigelserne tilbage til Amazon Redshift ved hjælp af boto3-data API i SageMaker Processing-jobbet.

Følgende skærmbillede fra Studio viser detaljerne i inferenspipeline.

Fordele ved at vælge at bygge ML arbejdsgange med SageMaker Pipelines

I dette afsnit diskuterer vi de gevinster, som Amazon Packaging Innovation-teamet opnåede ved at skifte til Pipelines til modeltræning og konklusioner.

Out-of-the-box MLOps-funktioner på produktionsniveau

Mens han sammenlignede forskellige interne og eksterne løsninger til den næste ML-pipeline-løsning, var en enkelt dataforsker i stand til at prototype og udvikle en fuld version af en ML-workflow med Pipelines i et Studio Jupyter-miljø på mindre end 3 uger. Selv på prototypestadiet blev det klart, at Pipelines leverede alle nødvendige infrastrukturkomponenter, der var nødvendige for et produktionsniveau: modelversionering, caching og alarmer. Umiddelbar tilgængelighed af disse funktioner betød, at der ikke ville blive brugt ekstra tid på at udvikle og tilpasse dem. Dette var en klar demonstration af værdi, som overbeviste Amazon Packaging Innovation-teamet om, at Pipelines var den rigtige løsning.

Fleksibilitet i udvikling af ML-modeller

Den største gevinst for dataforskerne på holdet var evnen til nemt at eksperimentere og iterere gennem forskellige modeller. Uanset hvilke rammer de foretrak for deres ML-arbejde og antallet af trin og funktioner, det involverede, imødekom Pipelines deres behov. Datavidenskabsmændene fik beføjelse til at eksperimentere uden at skulle vente på at komme på softwareudviklingssprintet for at tilføje en ekstra funktion eller et trin.

Reducerede omkostninger

SageMakers pipelines-kapacitet er gratis: du betaler kun for computerressourcerne og lageret, der er forbundet med træning og konklusioner. Men når du tænker på omkostningerne, skal du ikke kun tage højde for omkostningerne ved de anvendte tjenester, men også de udviklertimer, der er nødvendige for at vedligeholde arbejdsgangen, fejlfinde og rette den. Orkestrering med Pipelines er enklere, fordi det består af færre stykker og velkendt infrastruktur. Tidligere krævede tilføjelse af en ny funktion mindst to personer (dataforsker og softwareingeniør) hos Amazon Packaging Innovation-teamet for at implementere den. Med den omdesignede pipeline rettes ingeniørindsatsen nu mod yderligere tilpasset infrastruktur omkring pipelinen, såsom oprettelse af et enkelt lager til sporing af maskinlæringskoden, forenkling af modelimplementeringen på tværs af AWS-konti, udvikling af de integrerede ETL-job og fælles genanvendelige funktioner.

Muligheden for at cache trinene med et lignende input bidrog også til reduktionen i omkostningerne, fordi holdene var mindre tilbøjelige til at køre hele pipelinen igen. I stedet kunne de nemt starte det fra et fiasko.

Konklusion

Amazon Packaging Innovation-teamet træner ML-modeller på månedsbasis og opdaterer regelmæssigt forudsigelser for de anbefalede produktemballagetyper. Disse anbefalinger hjalp dem med at nå flere team- og virksomhedsomfattende mål ved at reducere spild og glæde kunderne med hver ordre. Trænings- og slutningspipelines skal køre pålideligt på en regelmæssig basis, men alligevel tillade konstant forbedring af modellerne.

Overgangen til Pipelines gjorde det muligt for teamet at implementere fire nye multimodale modelarkitekturer til produktion under 2 måneder. Implementering af en ny model ved brug af den tidligere arkitektur ville have krævet 5 dage (med samme modelarkitektur) til 1 måned (med en ny modelarkitektur). Implementering af den samme model ved hjælp af Pipelines gjorde det muligt for teamet at reducere udviklingstiden til 4 timer med den samme modelarkitektur og til 5 dage med en ny modelarkitektur. Det svarer til en besparelse på næsten 80 % af arbejdstiden.

Yderligere ressourcer

For mere information, se følgende ressourcer:

---

Om forfatterne

Ankur Shukla er Principal Data Scientist hos AWS-ProServe med base i Palo Alto. Ankur har mere end 15 års konsulenterfaring med at arbejde direkte med kunden og hjælpe dem med at løse forretningsproblemer med teknologi. Han leder adskillige globale anvendt videnskab og ML-Ops-initiativer inden for AWS. I sin fritid nyder han at læse og tilbringe tid med familien.

Akash Singla er Sr. System Dev Engineer med Amazon Packaging Innovation-team. Han har mere end 17 års erfaring med at løse kritiske forretningsproblemer gennem teknologi til flere forretningsvertikaler. Han fokuserer i øjeblikket på at opgradere NAWS infrastruktur til forskellige emballagecentrerede applikationer for at skalere dem bedre.

Vitalina Komashko er dataforsker med AWS Professional Services. Hun har en ph.d. i farmakologi og toksikologi, men gik over til datavidenskab fra eksperimentelt arbejde, fordi hun ville "eje datagenerering og fortolkningen af ​​resultaterne". Tidligere i sin karriere arbejdede hun med biotek- og medicinalvirksomheder. Hos AWS nyder hun at løse problemer for kunder fra forskellige brancher og lære om deres unikke udfordringer.

Prasanth Meiyappan er en Sr. Applied Scientist med Amazon Packaging Innovation i 4+ år. Han har 6+ års brancheerfaring i maskinlæring og har sendt produkter for at forbedre søgekundeoplevelsen og forbedre kundeemballageoplevelsen. Prasanth brænder for bæredygtighed og har en ph.d. i statistisk modellering af klimaændringer.

Matthew Bales er en seniorforsker, der arbejder på at optimere valg af pakketype ved hjælp af kundefeedback og maskinlæring. Før Amazon arbejdede Matt som post doc med at udføre simuleringer af partikelfysik i Tyskland og i et tidligere liv som produktionsleder af radioaktive medicinske implantater i en startup. Han har en ph.d. i fysik fra University of Michigan.