Forbedrer stabiliteten og fleksibiliteten til ML-rørledninger hos Amazon Packaging Innovation med Amazon SageMaker Pipelines

For å glede kunder og minimere emballasjeavfall, må Amazon velge den optimale emballasjetypen for milliarder av pakker som sendes hvert år. Hvis det brukes for lite beskyttelse for en skjør gjenstand som for eksempel et kaffekrus, vil varen ankomme skadet og Amazon risikerer kundens tillit. Bruk av for mye beskyttelse vil resultere i økte kostnader og overfulle resirkuleringsbøtter. Med hundrevis av millioner av produkter tilgjengelig, er det nødvendig med en skalerbar beslutningsmekanisme for å kontinuerlig lære av produkttesting og tilbakemeldinger fra kunder.

For å løse disse problemene utviklet Amazon Packaging Innovation-teamet maskinlæringsmodeller (ML) som klassifiserer om produkter er egnet for Amazon-emballasjetyper som forsendelser, poser eller esker, eller til og med kan sendes uten ekstra emballasje. Tidligere utviklet teamet en tilpasset pipeline basert på AWS trinnfunksjoner å utføre ukentlig trening og daglige eller månedlige slutningsjobber. Men over tid ga ikke rørledningen tilstrekkelig fleksibilitet til å lansere modeller med nye arkitekturer. Utviklingen for de nye rørledningene ga en overhead og krevde koordinering mellom dataforskere og utviklere. For å overvinne disse vanskelighetene og forbedre hastigheten på utrullingen av nye modeller og arkitekturer, valgte teamet å orkestrere modelltrening og slutninger med Amazon SageMaker-rørledninger.

I dette innlegget diskuterer vi den forrige orkestreringsarkitekturen basert på Step Functions, skisserer trenings- og slutningsarkitekturer ved bruk av Pipelines, og fremhever fleksibiliteten Amazon Packaging Innovation-teamet oppnådde.

Utfordringer fra den tidligere ML-rørledningen hos Amazon Packaging Innovation

For å inkludere kontinuerlig tilbakemelding om ytelsen til pakkene, trenes en ny modell hver uke ved å bruke et økende antall etiketter. Konklusjonen for hele beholdningen av produkter utføres månedlig, og en daglig slutning utføres for å levere just-in-time prediksjoner for den nylig lagt til beholdningen.

For å automatisere prosessen med å trene flere modeller og gi spådommer, hadde teamet utviklet en tilpasset pipeline basert på Step Functions for å orkestrere følgende trinn:

• Dataforberedelse for opplærings- og slutningsjobber og lasting av spådommer til databasen (Amazon RedShift) med AWS Lim.
• Modelltrening og slutning med Amazon SageMaker.
• Beregning av modellytelsesmålinger på valideringssettet med AWS-batch.
• Ved hjelp av Amazon DynamoDB å lagre modellkonfigurasjoner (som datadelingsforhold for trening og validering, modellartefaktplassering, modelltype og antall forekomster for trening og slutning), modellytelsesberegninger og den siste vellykket trente modellversjonen.
• Beregning av forskjellene i modellytelsesscore, endringer i fordelingen av treningsmerkene, og sammenligning av størrelsen på inputdata mellom forrige og nye modellversjoner med AWS Lambda funksjoner.
• Gitt det store antallet trinn, krevde rørledningen også et pålitelig alarmsystem ved hvert trinn for å varsle interessentene om eventuelle problemer. Dette ble oppnådd via en kombinasjon av Amazon enkel køtjeneste (Amazon SQS) og Amazon enkel varslingstjeneste (Amazon SNS). Alarmene ble opprettet for å varsle forretningsinteressenter, dataforskere og utviklere om eventuelle feilslåtte trinn og store avvik i modellen og databeregningene.

Etter å ha brukt denne løsningen i nesten 2 år, innså teamet at denne implementeringen bare fungerte bra for en typisk ML-arbeidsflyt der en enkelt modell ble trent og scoret på et valideringsdatasett. Løsningen var imidlertid ikke tilstrekkelig fleksibel for komplekse modeller og var ikke motstandsdyktig mot feil. For eksempel kunne ikke arkitekturen enkelt imøtekomme sekvensiell modelltrening. Det var vanskelig å legge til eller fjerne et trinn uten å duplisere hele rørledningen og modifisere infrastrukturen. Selv enkle endringer i databehandlingstrinnene som å justere datadelingsforholdet eller velge et annet sett med funksjoner krevde koordinering fra både en dataforsker og en utvikler. Når rørledningen sviktet på et hvilket som helst trinn, måtte den startes på nytt fra begynnelsen, noe som resulterte i gjentatte kjøringer og økte kostnader. For å unngå gjentatte kjøringer og å måtte starte på nytt fra det mislykkede trinnet, ville teamet opprette en ny kopi av en forkortet tilstandsmaskin. Denne feilsøkingen førte til en spredning av statsmaskinene, hver med start fra de ofte feilende trinnene. Til slutt, hvis en treningsjobb oppdaget et avvik i fordelingen av etiketter, modellpoengsum eller antall etiketter, måtte en dataforsker gjennomgå modellen og dens beregninger manuelt. Deretter ville en dataforsker få tilgang til en DynamoDB-tabell med modellversjonene og oppdatere tabellen for å sikre at den riktige modellen ble brukt til neste slutningsjobb.

Vedlikeholdet av denne arkitekturen krevde minst én dedikert ressurs og en ekstra heltidsressurs for utvikling. Gitt vanskelighetene med å utvide rørledningen for å imøtekomme nye brukstilfeller, hadde dataforskerne begynt å utvikle sine egne arbeidsflyter, som igjen hadde ført til en voksende kodebase, flere datatabeller med lignende dataskjemaer og desentralisert modellovervåking. Akkumulering av disse problemene hadde resultert i lavere teamproduktivitet og økt overhead.

For å møte disse utfordringene, evaluerte Amazon Packaging Innovation-teamet andre eksisterende løsninger for MLOps, inkludert SageMaker Pipelines (Utgivelseskunngjøring for desember 2020). Pipelines er en funksjon i SageMaker for å bygge, administrere, automatisere og skalere ende-til-ende ML-arbeidsflyter. Pipelines lar deg redusere antall trinn på tvers av hele ML-arbeidsflyten og er fleksibel nok til at dataforskere kan definere en tilpasset ML-arbeidsflyt. Den tar seg av overvåking og logging av trinnene. Den kommer også med et modellregister som automatisk versjonerer nye modeller. Modellregisteret har innebygde godkjenningsarbeidsflyter for å velge modeller for slutning i produksjon. Pipelines tillater også hurtigbufring av trinn kalt med de samme argumentene. Hvis en tidligere kjøring blir funnet, opprettes en hurtigbuffer, som muliggjør en enkel omstart i stedet for å beregne de vellykket fullførte trinnene på nytt.

I evalueringsprosessen skilte Pipelines seg ut fra de andre løsningene for sin fleksibilitet og tilgjengelighet av funksjoner for å støtte og utvide nåværende og fremtidige arbeidsflyter. Bytte til Pipelines frigjorde utviklernes tid fra plattformvedlikehold og feilsøking og omdirigerte oppmerksomheten mot tillegg av de nye funksjonene. I dette innlegget presenterer vi designet for opplærings- og slutningsarbeidsflyter hos Amazon Packaging Innovation-teamet ved hjelp av Pipelines. Vi diskuterer også fordelene og kostnadsreduksjonen teamet realiserte ved å bytte til Pipelines.

Opplæringspipeline

Amazon Packaging Innovation-teamet trener modeller for hver pakketype ved å bruke et økende antall etiketter. Følgende diagram skisserer hele prosessen.

Arbeidsflyten begynner med å trekke ut etiketter og funksjoner fra en Amazon Redshift-database og laste ut dataene til Amazon enkel lagringstjeneste (Amazon S3) via en planlagt uttrekking, transformasjon og lasting (ETL) jobb. Sammen med inndataene plasseres et filobjekt med modelltype og parametere i S3-bøtten. Denne filen fungerer som pipeline-utløser via en Lambda-funksjon.

De neste trinnene er fullstendig tilpassbare og definert av en dataforsker som bruker SageMaker Python SDK for Pipelines. I scenariet vi presenterer i dette innlegget, deles inndataene inn i opplærings- og valideringssett og lagres tilbake i en S3-bøtte ved å starte en SageMaker Processing-jobb.

Når dataene er klare i Amazon S3, starter en SageMaker-opplæringsjobb. Etter at modellen er vellykket opplært og opprettet, utføres modellevalueringstrinnet på valideringsdataene via en SageMaker batch-transformeringsjobb. Modellberegningene sammenlignes deretter med forrige ukes modellberegninger ved å bruke en SageMaker Processing-jobb. Teamet har definert flere tilpassede kriterier for å evaluere avvik i modellens ytelse. Modellen blir enten forkastet eller godkjent basert på disse kriteriene. Hvis modellen avvises, brukes den tidligere godkjente modellen for de neste slutningsjobbene. Hvis modellen er godkjent, blir versjonen registrert og den modellen brukes til slutningsjobber. Interessentene får melding om utfallet via Amazon CloudWatch alarmer.

Følgende skjermbilde fra Amazon SageMaker Studio viser trinnene i treningspipelinen.

Pipelines sporer hver pipeline-kjøring, som du kan overvåke i Studio. Alternativt kan du spørre om fremdriften til kjøringen ved å bruke Boto3 eller AWS kommandolinjegrensesnitt (AWS CLI). Du kan visualisere modellberegningene i Studio og sammenligne forskjellige modellversjoner.

Inferensrørledning

Amazon Packaging Innovation-teamet oppdaterer spådommer for hele beholdningen av produkter månedlig. Daglige spådommer genereres for å gi just-in-time emballasjeanbefalinger for nylig lagt til inventar ved å bruke den siste trente modellen. Dette krever at inferensrørledningen kjører daglig med forskjellige datamengder. Følgende diagram illustrerer denne arbeidsflyten.

I likhet med treningspipelinen begynner konklusjonen med å laste ut dataene fra Amazon Redshift til en S3-bøtte. Et filobjekt plassert i Amazon S3 utløser Lambda-funksjonen som starter inferensrørledningen. Funksjonene er forberedt for slutninger, og dataene deles inn i filer med passende størrelse ved hjelp av en SageMaker Processing-jobb. Deretter identifiserer rørledningen den siste godkjente modellen for å kjøre spådommene og laste dem til en S3-bøtte. Til slutt blir spådommene lastet tilbake til Amazon Redshift ved hjelp av boto3-data API i SageMaker Processing-jobben.

Følgende skjermbilde fra Studio viser inferensrørledningsdetaljer.

Fordeler ved å velge å bygge ML arbeidsflyter med SageMaker Pipelines

I denne delen diskuterer vi gevinstene Amazon Packaging Innovation-teamet oppnådde ved å bytte til Pipelines for modellopplæring og slutninger.

Out-of-the-box MLOps-funksjoner på produksjonsnivå

Mens han sammenlignet ulike interne og eksterne løsninger for den neste ML-pipeline-løsningen, var en enkelt dataforsker i stand til å prototype og utvikle en fullversjon av en ML-arbeidsflyt med Pipelines i et Studio Jupyter-miljø på mindre enn 3 uker. Selv på prototypingstadiet ble det klart at Pipelines ga alle nødvendige infrastrukturkomponenter som kreves for en arbeidsflyt på produksjonsnivå: modellversjon, caching og alarmer. Umiddelbar tilgjengelighet av disse funksjonene betydde at det ikke ble brukt ekstra tid på å utvikle og tilpasse dem. Dette var en tydelig demonstrasjon av verdi, som overbeviste Amazon Packaging Innovation-teamet om at Pipelines var den riktige løsningen.

Fleksibilitet i utvikling av ML-modeller

Den største gevinsten for dataforskerne i teamet var muligheten til å eksperimentere enkelt og iterere gjennom forskjellige modeller. Uansett hvilket rammeverk de foretrakk for ML-arbeidet og antall trinn og funksjoner det innebar, imøtekom Pipelines behovene deres. Dataforskerne fikk myndighet til å eksperimentere uten å måtte vente med å komme på programvareutviklingssprinten for å legge til en ekstra funksjon eller et trinn.

Reduserte kostnader

Pipelines-evnen til SageMaker er gratis: du betaler kun for dataressursene og lagringen knyttet til opplæring og slutning. Men når du tenker på kostnadene, må du ikke bare ta hensyn til kostnadene for tjenestene som brukes, men også utviklertimene som trengs for å opprettholde arbeidsflyten, feilsøke og lappe den. Orkestrering med Pipelines er enklere fordi det består av færre stykker og kjent infrastruktur. Tidligere krevde å legge til en ny funksjon minst to personer (dataforsker og programvareingeniør) hos Amazon Packaging Innovation-teamet for å implementere den. Med den redesignede pipelinen rettes nå ingeniørarbeid mot ytterligere tilpasset infrastruktur rundt pipelinen, for eksempel opprettelse av et enkelt depot for sporing av maskinlæringskoden, forenkling av modellimplementeringen på tvers av AWS-kontoer, utvikling av de integrerte ETL-jobbene og felles gjenbrukbare funksjoner.

Muligheten til å cache trinnene med lignende input bidro også til kostnadsreduksjonen, fordi det var mindre sannsynlighet for at teamene ville kjøre hele rørledningen på nytt. I stedet kunne de lett starte det fra feilpunktet.

konklusjonen

Amazon Packaging Innovation-teamet trener ML-modeller på månedlig basis og oppdaterer regelmessig spådommer for de anbefalte produktemballasjetypene. Disse anbefalingene hjalp dem med å oppnå flere team- og bedriftsomfattende mål ved å redusere avfall og glede kunder med hver bestilling. Opplærings- og slutningsrørledningene må kjøre pålitelig med jevne mellomrom, men likevel tillate konstant forbedring av modellene.

Overgangen til Pipelines gjorde at teamet kunne distribuere fire nye multimodale modellarkitekturer til produksjon under 2 måneder. Å distribuere en ny modell ved bruk av den forrige arkitekturen ville ha krevd 5 dager (med samme modellarkitektur) til 1 måned (med en ny modellarkitektur). Ved å distribuere den samme modellen ved hjelp av Pipelines kunne teamet redusere utviklingstiden til 4 timer med samme modellarkitektur og til 5 dager med en ny modellarkitektur. Det tilsvarer en besparelse på nesten 80 % av arbeidstiden.

Tilleggsressurser

For mer informasjon, se følgende ressurser:

---

Om forfatterne

Ankur Shukla er hoveddataforsker ved AWS-ProServe med base i Palo Alto. Ankur har mer enn 15 års konsulenterfaring med å jobbe direkte med kunden og hjelpe dem med å løse forretningsproblemer med teknologi. Han leder flere globale anvendt vitenskap og ML-Ops-initiativer innen AWS. På fritiden liker han å lese og tilbringe tid med familien.

Akash Singla er en Sr. System Dev Engineer med Amazon Packaging Innovation-team. Han har mer enn 17 års erfaring med å løse kritiske forretningsproblemer gjennom teknologi for flere forretningsvertikaler. Han fokuserer for tiden på å oppgradere NAWS-infrastruktur for en rekke emballasjesentrerte applikasjoner for å skalere dem bedre.

Vitalina Komashko er en dataforsker med AWS Professional Services. Hun har en doktorgrad i farmakologi og toksikologi, men gikk over til datavitenskap fra eksperimentelt arbeid fordi hun ønsket "å eie datagenerering og tolkningen av resultatene". Tidligere i karrieren jobbet hun med bioteknologi- og farmaselskaper. Hos AWS liker hun å løse problemer for kunder fra ulike bransjer og lære om deres unike utfordringer.

Prasanth Meiyappan er en Sr. Applied Scientist med Amazon Packaging Innovation i 4+ år. Han har 6+ års bransjeerfaring innen maskinlæring og har sendt produkter for å forbedre søkekundeopplevelsen og forbedre kundeemballasjeopplevelsen. Prasanth brenner for bærekraft og har en doktorgrad i statistisk modellering av klimaendringer.

Matthew Bales er en seniorforsker som jobber med å optimalisere valg av pakketype ved hjelp av tilbakemeldinger fra kunder og maskinlæring. Før Amazon jobbet Matt som postdoktor og utførte simuleringer av partikkelfysikk i Tyskland og i et tidligere liv som produksjonsleder for radioaktive medisinske implantater i en oppstart. Han har en Ph.D. i fysikk fra University of Michigan.