Förbättring av stabilitet och flexibilitet för ML-pipelines hos Amazon Packaging Innovation med Amazon SageMaker Pipelines

För att glädja kunder och minimera förpackningsavfall måste Amazon välja den optimala förpackningstypen för miljarder förpackningar som skickas varje år. Om för lite skydd används för en ömtålig vara som en kaffemugg kommer varan fram skadad och Amazon riskerar deras kunds förtroende. Att använda för mycket skydd kommer att resultera i ökade kostnader och överfulla återvinningskärl. Med hundratals miljoner produkter tillgängliga behövs en skalbar beslutsmekanism för att kontinuerligt lära av produkttester och kundfeedback.

För att lösa dessa problem utvecklade Amazon Packaging Innovation-teamet maskininlärningsmodeller (ML) som klassificerar om produkter är lämpliga för Amazon-förpackningstyper som postförsändelser, väskor eller lådor, eller till och med kan skickas utan extra förpackning. Tidigare har teamet utvecklat en anpassad pipeline baserad på AWS stegfunktioner att utföra veckoträning och dagliga eller månatliga slutledningsjobb. Men med tiden gav pipelinen inte tillräcklig flexibilitet för att lansera modeller med ny arkitektur. Utvecklingen av de nya pipelinesna innebar en overhead och krävde samordning mellan datavetare och utvecklare. För att övervinna dessa svårigheter och förbättra hastigheten på implementeringen av nya modeller och arkitekturer, valde teamet att iscensätta modellträning och slutsatser med Amazon SageMaker-rörledningar.

I det här inlägget diskuterar vi den tidigare orkestreringsarkitekturen baserad på stegfunktioner, skisserar utbildnings- och slutledningsarkitekturer med hjälp av Pipelines och lyfter fram flexibiliteten som Amazon Packaging Innovation-teamet uppnådde.

Utmaningar från den tidigare ML-pipelinen på Amazon Packaging Innovation

För att inkludera kontinuerlig feedback om prestanda hos paket, tränas en ny modell varje vecka med ett växande antal etiketter. Slutsatsen för hela lagret av produkter utförs månadsvis, och en daglig slutledning görs för att leverera just-in-time förutsägelser för det nyligen tillagda lagret.

För att automatisera processen att träna flera modeller och ge förutsägelser, hade teamet utvecklat en anpassad pipeline baserad på Step Functions för att orkestrera följande steg:

• Dataförberedelse för utbildnings- och slutledningsjobb och laddning av förutsägelser till databasen (Amazon RedShift) Med AWS-lim.
• Modellträning och slutledning med Amazon SageMaker.
• Beräkning av modellprestandamått på valideringssetet med AWS-batch.
• Använda Amazon DynamoDB för att lagra modellkonfigurationer (som datadelningsförhållande för träning och validering, modellartefaktplacering, modelltyp och antal instanser för träning och slutledning), modellprestandamått och den senaste framgångsrikt tränade modellversionen.
• Beräkning av skillnaderna i modellprestandapoäng, förändringar i fördelningen av träningsetiketterna och jämförelse av storleken på indata mellan den tidigare och den nya modellversionen med AWS Lambda funktioner.
• Med tanke på det stora antalet steg krävde pipelinen också ett tillförlitligt larmsystem vid varje steg för att varna intressenterna om eventuella problem. Detta åstadkoms genom en kombination av Amazon enkel kötjänst (Amazon SQS) och Amazon enkel meddelandetjänst (Amazon SNS). Larmen skapades för att meddela affärsintressenter, datavetare och utvecklare om eventuella misslyckade steg och stora avvikelser i modellen och datamåtten.

Efter att ha använt den här lösningen i nästan två år insåg teamet att den här implementeringen bara fungerade bra för ett typiskt ML-arbetsflöde där en enskild modell tränades och fick poäng på en valideringsdatauppsättning. Lösningen var dock inte tillräckligt flexibel för komplexa modeller och var inte motståndskraftig mot misslyckanden. Till exempel kunde arkitekturen inte lätt rymma sekventiell modellträning. Det var svårt att lägga till eller ta bort ett steg utan att duplicera hela pipelinen och modifiera infrastrukturen. Även enkla ändringar i databearbetningsstegen som att justera datadelningsförhållandet eller välja en annan uppsättning funktioner krävde samordning från både en datavetare och en utvecklare. När pipelinen misslyckades vid något steg var den tvungen att startas om från början, vilket resulterade i upprepade körningar och ökade kostnader. För att undvika upprepade körningar och att behöva starta om från det misslyckade steget skulle teamet skapa en ny kopia av en förkortad tillståndsmaskin. Denna felsökning ledde till en spridning av statliga maskiner, var och en med början från de vanligaste misslyckade stegen. Slutligen, om ett utbildningsjobb stötte på en avvikelse i fördelningen av etiketter, modellpoäng eller antal etiketter, var en dataforskare tvungen att granska modellen och dess mätvärden manuellt. Sedan skulle en dataforskare komma åt en DynamoDB-tabell med modellversionerna och uppdatera tabellen för att säkerställa att rätt modell användes för nästa slutledningsjobb.

Underhållet av denna arkitektur krävde minst en dedikerad resurs och ytterligare en heltidsresurs för utveckling. Med tanke på svårigheterna att utöka pipelinen för att ta emot nya användningsfall, hade dataforskarna börjat utveckla sina egna arbetsflöden, vilket i sin tur hade lett till en växande kodbas, flera datatabeller med liknande datascheman och decentraliserad modellövervakning. Ackumulering av dessa problem hade resulterat i lägre teamproduktivitet och ökade omkostnader.

För att möta dessa utmaningar utvärderade Amazon Packaging Innovation-teamet andra befintliga lösningar för MLOps, inklusive SageMaker Pipelines (Releasemeddelande från december 2020). Pipelines är en kapacitet hos SageMaker för att bygga, hantera, automatisera och skala ML-arbetsflöden från början till slut. Pipelines låter dig minska antalet steg över hela ML-arbetsflödet och är tillräckligt flexibel för att tillåta datavetare att definiera ett anpassat ML-arbetsflöde. Den tar hand om övervakning och loggning av stegen. Den kommer också med ett modellregister som automatiskt versionerar nya modeller. Modellregistret har inbyggda godkännandearbetsflöden för att välja modeller för slutledning i produktionen. Pipelines tillåter också cachning av steg som anropas med samma argument. Om en tidigare körning hittas skapas en cache som möjliggör en enkel omstart istället för att räkna om de framgångsrikt genomförda stegen.

I utvärderingsprocessen skilde sig Pipelines ut från de andra lösningarna för sin flexibilitet och tillgänglighet av funktioner för att stödja och utöka nuvarande och framtida arbetsflöden. Att byta till Pipelines frigjorde utvecklarnas tid från plattformsunderhåll och felsökning och riktade uppmärksamheten mot tillägget av de nya funktionerna. I det här inlägget presenterar vi designen för utbildnings- och slutledningsarbetsflöden hos Amazon Packaging Innovation-teamet med hjälp av Pipelines. Vi diskuterar också fördelarna och minskningen av kostnaderna som teamet uppnådde genom att byta till Pipelines.

Utbildning pipeline

Amazon Packaging Innovation-teamet tränar modeller för varje förpackningstyp med hjälp av ett växande antal etiketter. Följande diagram beskriver hela processen.

Arbetsflödet börjar med att extrahera etiketter och funktioner från en Amazon Redshift-databas och ladda ner data till Amazon enkel lagringstjänst (Amazon S3) via ett schemalagt extrahera, transformera och ladda (ETL) jobb. Tillsammans med indata placeras ett filobjekt med modelltyp och parametrar i S3-skopan. Den här filen fungerar som pipeline-utlösaren via en Lambda-funktion.

Nästa steg är helt anpassningsbara och definieras helt av en dataforskare som använder SageMaker Python SDK för pipelines. I scenariot vi presenterar i det här inlägget delas indata upp i tränings- och valideringsuppsättningar och sparas tillbaka i en S3-hink genom att starta ett SageMaker Processing-jobb.

När datan är klar i Amazon S3 startar ett SageMaker-utbildningsjobb. Efter att modellen framgångsrikt har tränats och skapats, utförs modellutvärderingssteget på valideringsdata via ett SageMaker batchtransformeringsjobb. Modellmätningarna jämförs sedan med föregående veckas modellmått med hjälp av ett SageMaker Processing-jobb. Teamet har definierat flera anpassade kriterier för att utvärdera avvikelser i modellens prestanda. Modellen är antingen underkänd eller godkänd utifrån dessa kriterier. Om modellen förkastas används den tidigare godkända modellen för nästa slutledningsjobb. Om modellen godkänns registreras dess version och den modellen används för slutledningsjobb. Intressenterna får besked om utfallet via amazoncloudwatch larm.

Följande skärmdump från Amazon SageMaker Studio visar stegen i utbildningspipeline.

Pipelines spårar varje pipelinekörning, som du kan övervaka i Studio. Alternativt kan du fråga om körningens förlopp med hjälp av Boto3 eller AWS-kommandoradsgränssnitt (AWS CLI). Du kan visualisera modellmåtten i Studio och jämföra olika modellversioner.

Inferenspipeline

Amazon Packaging Innovation-teamet uppdaterar förutsägelser för hela lager av produkter varje månad. Dagliga förutsägelser genereras för att ge just-in-time förpackningsrekommendationer för nytillkomna inventarier med den senaste utbildade modellen. Detta kräver att slutledningspipelinen körs dagligen med olika mängder data. Följande diagram illustrerar detta arbetsflöde.

I likhet med träningspipelinen börjar slutsatsen med att ladda ner data från Amazon Redshift till en S3-hink. Ett filobjekt placerat i Amazon S3 triggar Lambda-funktionen som initierar inferenspipeline. Funktionerna är förberedda för slutledning och data delas upp i filer av lämplig storlek med hjälp av ett SageMaker Processing-jobb. Därefter identifierar pipelinen den senaste godkända modellen för att köra förutsägelserna och ladda dem till en S3-skopa. Slutligen laddas förutsägelserna tillbaka till Amazon Redshift med hjälp av boto3-data API i SageMaker Processing-jobbet.

Följande skärmdump från Studio visar detaljer om slutledningspipeline.

Fördelar med att välja att utforma ML-arbetsflöden med SageMaker Pipelines

I det här avsnittet diskuterar vi de vinster som Amazon Packaging Innovation-teamet uppnådde genom att byta till Pipelines för modellträning och slutledning.

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

Medan han jämförde olika interna och externa lösningar för nästa ML-pipelinelösning kunde en enskild dataforskare prototyper och utveckla en fullständig version av ett ML-arbetsflöde med Pipelines i en Studio Jupyter-miljö på mindre än 3 veckor. Redan i prototypstadiet blev det tydligt att Pipelines tillhandahöll alla nödvändiga infrastrukturkomponenter som krävs för ett arbetsflöde på produktionsnivå: modellversionering, cachning och larm. Omedelbar tillgänglighet av dessa funktioner innebar att ingen extra tid skulle läggas på att utveckla och anpassa dem. Detta var en tydlig demonstration av värde, som övertygade Amazon Packaging Innovation-teamet om att Pipelines var rätt lösning.

Flexibilitet i att utveckla ML-modeller

Den största vinsten för dataforskarna i teamet var förmågan att experimentera enkelt och iterera genom olika modeller. Oavsett vilket ramverk de föredrog för sitt ML-arbete och antalet steg och funktioner det involverade, tillgodosede Pipelines deras behov. Dataforskarna fick befogenhet att experimentera utan att behöva vänta på att komma igång med mjukvaruutvecklingssprinten för att lägga till ytterligare en funktion eller ett steg.

Reducerade kostnader

Rörledningsförmågan hos SageMaker är kostnadsfria : du betalar endast för beräkningsresurserna och lagringen i samband med utbildning och slutledning. Men när du tänker på kostnaden måste du inte bara ta hänsyn till kostnaden för de tjänster som används utan också de timmar för utvecklaren som behövs för att underhålla arbetsflödet, felsöka och korrigera det. Orkestrering med Pipelines är enklare eftersom det består av färre bitar och välbekant infrastruktur. Tidigare krävde att lägga till en ny funktion minst två personer (datavetare och mjukvaruingenjör) på Amazon Packaging Innovation-teamet för att implementera den. Med den omdesignade pipelinen riktas nu ingenjörsinsatser mot ytterligare anpassad infrastruktur runt pipelinen, såsom skapandet av ett enda arkiv för spårning av maskininlärningskoden, förenkling av modellimplementeringen över AWS-konton, utveckling av de integrerade ETL-jobben och vanliga återanvändbara funktioner.

Möjligheten att cachelagra stegen med en liknande input bidrog också till kostnadsminskningen, eftersom teamen var mindre benägna att köra om hela pipelinen. Istället kunde de enkelt starta det från ett misslyckande.

Slutsats

Amazon Packaging Innovation-teamet utbildar ML-modeller på månadsbasis och uppdaterar regelbundet prognoser för de rekommenderade produktförpackningstyperna. Dessa rekommendationer hjälpte dem att uppnå flera team- och företagsomfattande mål genom att minska slöseriet och glädja kunderna med varje beställning. Utbildnings- och slutledningsledningarna måste löpa tillförlitligt regelbundet men ändå möjliggöra ständiga förbättringar av modellerna.

Övergången till Pipelines gjorde det möjligt för teamet att distribuera fyra nya multimodala modellarkitekturer till produktion under två månader. Att implementera en ny modell med den tidigare arkitekturen skulle ha krävt 2 dagar (med samma modellarkitektur) till 5 månad (med en ny modellarkitektur). Genom att distribuera samma modell med Pipelines kunde teamet minska utvecklingstiden till 1 timmar med samma modellarkitektur och till 4 dagar med en ny modellarkitektur. Det motsvarar en besparing på nästan 5 % av arbetstiden.

Ytterligare resurser

Mer information finns i följande resurser:

---

Om författarna

Ankur Shukla är en Principal Data Scientist på AWS-ProServe med säte i Palo Alto. Ankur har mer än 15 års konsulterfarenhet av att arbeta direkt med kunden och hjälpa dem att lösa affärsproblem med teknik. Han leder flera globala tillämpad vetenskap och ML-Ops-initiativ inom AWS. På fritiden tycker han om att läsa och umgås med familjen.

Akash Singla är en Sr. System Dev Engineer med Amazon Packaging Innovation-team. Han har mer än 17 års erfarenhet av att lösa kritiska affärsproblem genom teknik för flera affärsvertikaler. Han fokuserar för närvarande på att uppgradera NAWS infrastruktur för olika förpackningscentrerade applikationer för att skala dem bättre.

Vitalina Komashko är en dataforskare med AWS Professional Services. Hon har en doktorsexamen i farmakologi och toxikologi men övergick till datavetenskap från experimentellt arbete eftersom hon ville "äga datagenerering och tolkningen av resultaten". Tidigare under sin karriär arbetade hon med bioteknik- och läkemedelsföretag. På AWS tycker hon om att lösa problem för kunder från olika branscher och lära sig om deras unika utmaningar.

Prasanth Meiyappan är en Sr. Applied Scientist med Amazon Packaging Innovation i 4+ år. Han har 6+ års branscherfarenhet av maskininlärning och har skickat produkter för att förbättra sökkundupplevelsen och förbättra kundupplevelsen för förpackning. Prasanth brinner för hållbarhet och har en doktorsexamen i statistisk modellering av klimatförändringar.

Matthew Bales är en senior forskare som arbetar med att optimera val av pakettyp med hjälp av kundfeedback och maskininlärning. Innan han började på Amazon arbetade Matt som post doc med simuleringar av partikelfysik i Tyskland och i ett tidigare liv som produktionsledare för radioaktiva medicinska implantatenheter i en startup. Han har en Ph.D. i fysik från University of Michigan.