Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon av PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon

Amazon Prognose er en fullstendig administrert tjeneste som bruker statistiske og maskinlæringsalgoritmer (ML) for å levere svært nøyaktige tidsserieprognoser. Nylig, basert på Amazon Forecast, hjalp vi en av våre detaljkunder med å oppnå nøyaktig etterspørselsprognose innen 8 uker. Løsningen forbedret den manuelle prognosen med gjennomsnittlig 10 % i forhold til WAPE metrisk. Dette fører til en direkte besparelse på 16 arbeidstimer månedlig. I tillegg estimerte vi at ved å oppfylle riktig antall varer, kan salget øke med opptil 11.8 %. I dette innlegget presenterer vi arbeidsflyten og de kritiske elementene for å implementere – fra proof of concept (POC) til produksjon – et etterspørselsprognosesystem med Amazon Forecast, fokusert på utfordringer i detaljhandelen.

Bakgrunn og aktuelle utfordringer med etterspørselsprognoser i detaljhandelen

Målet med etterspørselsprognoser er å estimere fremtidig etterspørsel fra historiske data, og å hjelpe butikkpåfyll og kapasitetstildeling. Med etterspørselsprognoser kan forhandlere plassere riktig mengde beholdning på hvert sted i nettverket for å møte etterspørselen. Derfor kan et nøyaktig prognosesystem gi et bredt spekter av fordeler på tvers av ulike forretningsfunksjoner, for eksempel:

  • Øke salget fra bedre produkttilgjengelighet og redusere innsatsen for overføring av avfall mellom butikker
  • Gir mer pålitelig innsikt for å forbedre kapasitetsutnyttelsen og proaktivt unngå flaskehalser i kapasitetsforsyningen
  • Minimere lager- og produksjonskostnader og forbedre lageromsetningen
  • Presentere en samlet bedre kundeopplevelse

ML-teknikker viser stor verdi når et stort volum av data av god kvalitet er tilstede. I dag er erfaringsbasert etterfyllingsstyring eller etterspørselsprognose fortsatt hovedstrømmen for de fleste forhandlere. Med mål om å forbedre kundeopplevelsen, er flere og flere forhandlere villige til å erstatte opplevelsesbaserte behovsprognosesystemer med ML-baserte prognoser. Forhandlere står imidlertid overfor flere utfordringer når de implementerer ML-baserte etterspørselsprognosesystemer i produksjon. Vi oppsummerer de ulike utfordringene i tre kategorier: datautfordringer, ML-utfordringer og operasjonelle utfordringer.

Datautfordringer

Et stort volum av rene data av høy kvalitet er et nøkkelkrav for å gi nøyaktige ML-baserte spådommer. Kvalitetsdata, inkludert historiske salgs- og salgsrelaterte data (som inventar, varepriser og kampanjer), må samles inn og konsolideres. Mangfoldet av data fra flere ressurser krever en moderne dataplattform for å forene datasiloer. I tillegg er tilgang til data i tide nødvendig for hyppige og finmaskede etterspørselsprognoser.

ML utfordringer

Å utvikle avanserte ML-algoritmer krever ekspertise. Implementering av riktige algoritmer for riktig problem krever både dybdekunnskap og ML-kompetanse. I tillegg krever læring fra store tilgjengelige datasett en skalerbar ML-infrastruktur. Dessuten krever vedlikehold av ML-algoritmer i produksjon ML-kompetanse for å analysere årsaken til modellforringelse og omskolere modellen på riktig måte.

For å løse praktiske forretningsproblemer er det å produsere nøyaktige prognoser bare en del av historien. Beslutningstakere trenger sannsynlighetsprognoser ved forskjellige kvantiler gjør viktige kundeopplevelser kontra økonomiske resultater avveininger. De må også forklare spådommer til interessenter, og utføre hva-hvis-analyser for å undersøke hvordan ulike scenarier kan påvirke prognoseresultatene.

Operasjonelle utfordringer

Å redusere den operative innsatsen for å opprettholde et kostnadseffektivt prognosesystem er den tredje hovedutfordringen. I et vanlig scenario med etterspørselsprognoser har hver vare på hvert sted sin egen prognose. Det kreves et system som kan administrere hundretusenvis av prognoser når som helst. I tillegg trenger bedriftens sluttbrukere at prognosesystemet integreres i eksisterende nedstrømssystemer, slik som eksisterende plattformer for forsyningskjedestyring, slik at de kan bruke ML-baserte systemer uten å endre eksisterende verktøy og prosesser.

Disse utfordringene er spesielt akutte når virksomheten er stor, dynamisk og i vekst. For å møte disse utfordringene deler vi en kundesuksesshistorie som reduserer innsatsen for raskt å validere den potensielle forretningsgevinsten. Dette oppnås gjennom prototyping med Amazon Forecast – en fullstendig administrert tjeneste som gir nøyaktige prognoseresultater uten behov for å administrere underliggende infrastrukturressurser og algoritmer.

Rask prototyping for et ML-basert prognosesystem med Amazon Forecast

Basert på vår erfaring ser vi ofte at privatkunder er villige til å sette i gang en proof of concept på sine salgsdata. Dette kan gjøres i løpet av noen få dager til noen uker for rask prototyping, avhengig av datakompleksiteten og tilgjengelige ressurser for å iterere gjennom modelljusteringsprosessen. Under prototyping foreslår vi å bruke sprints for å effektivt administrere prosessen, og dele POC i datautforskning, iterativ forbedring og automatiseringsfaser.

Data leting

Datautforskning involverer ofte intens diskusjon med dataforskere eller business intelligence-analytikere for å bli kjent med det historiske salgsdatasettet og tilgjengelige datakilder som potensielt kan påvirke prognoseresultater, for eksempel inventar og historiske reklamehendelser. En av de mest effektive måtene er å konsolidere salgsdataene, som måldatasettet, fra datavarehuset på et tidlig stadium av prosjektet. Dette er basert på det faktum at prognoseresultater ofte domineres av måldatasettet. Datavarehus lagrer ofte daglige forretningsdata, og en uttømmende forståelse innen kort tid er vanskelig og tidkrevende. Vårt forslag er å konsentrere seg om å generere måldatasettet og sørge for at dette datasettet er riktig. Disse datautforskningen og basislinjeresultatene kan ofte oppnås i løpet av noen få dager, og dette kan avgjøre om måldataene kan forutses nøyaktig. Vi diskuterer dataforutsigbarhet senere i dette innlegget.

køyring

Etter at vi har grunnlagsresultatene, kan vi fortsette å legge til flere relaterte data for å se hvordan disse kan påvirke nøyaktigheten. Dette gjøres ofte gjennom et dypdykk i tilleggsdatasett; for mer informasjon, se Bruke relaterte tidsseriedatasett og Bruke elementmetadatadatasett.

I noen tilfeller kan det være mulig å forbedre nøyaktigheten i Amazon Forecast ved å trene modellene med undersett av datasettet som oppfører seg på samme måte, eller ved å fjerne sparsomme data fra datasettet. I løpet av denne iterative forbedringsfasen er den utfordrende delen – sant for alle ML-prosjekter – at den nåværende iterasjonen avhenger av den forrige iterasjonens nøkkelfunn og innsikt, så grundig analyse og rapportering er nøkkelen til suksess.

Analyse kan gjøres kvantitativt og empirisk. Det kvantitative aspektet refererer til evaluering under tilbaketestingen og sammenligning av nøyaktighetsmålingen, som f.eks. WAPE. Det empiriske aspektet refererer til å visualisere prediksjonskurven og faktiske måldata, og bruke domenekunnskapen til å inkorporere potensielle faktorer. Disse analysene hjelper deg å iterere raskere for å bygge bro mellom prognoseresultater og måldata. I tillegg kan det å presentere slike resultater via en ukentlig rapport ofte gi tillit til sluttbrukere.

Automatisering

Det siste trinnet involverer ofte diskusjon av POC til produksjonsprosedyre og automatisering. Fordi ML-prosjektet er begrenset av den totale prosjektvarigheten, har vi kanskje ikke nok tid til å utforske alle muligheter. Derfor kan det ofte tjene tillit til å angi det potensielle området gjennom funnene under prosjektet. I tillegg kan automatisering hjelpe bedriftens sluttbrukere med å evaluere Forecast for en lengre periode, fordi de kan bruke en eksisterende prediktor til å generere prognoser med de oppdaterte dataene.

Suksesskriteriene kan evalueres med genererte resultater, både fra teknisk og forretningsmessig perspektiv. I løpet av evalueringsperioden kan vi estimere potensielle fordeler for følgende:

  • Øke prognosenøyaktigheten (teknisk) – Beregn prediksjonsnøyaktigheten med hensyn til faktiske salgsdata, og sammenlign med det eksisterende prognosesystemet, inkludert manuelle prognoser
  • Redusere avfall (virksomhet) – Reduser overprognoser for å redusere avfall
  • Forbedre lagerpriser (bedrift) – Reduser underprognoser for å forbedre lagerratene
  • Estimere økningen i bruttofortjeneste (virksomhet) – Reduser svinn og forbedre lagerpriser for å øke bruttofortjenesten

Vi oppsummerer utviklingsarbeidsflyten i følgende diagram.

I de følgende avsnittene diskuterer vi de viktige elementene som må tas i betraktning under implementeringen.

Trinn-for-trinn arbeidsflyt for å utvikle et prognosesystem

Generering av måldatasett

Det første trinnet er å generere måldatasettet for Forecast. I detaljhandelen refererer dette til historiske tidsserieetterspørsels- og salgsdata for detaljhandelsvarer (SKU-er). Når du utarbeider datasettet, er et viktig aspekt granularitet. Vi bør vurdere datagranulariteten fra både forretningskrav og tekniske krav.

Virksomheten definerer hvordan prognoser resulterer i produksjonssystemet:

  • Horizon – Antall tidstrinn som blir anslått. Dette avhenger av det underliggende forretningsproblemet. Hvis vi ønsker å fylle på lagernivået hver uke, så virker en ukentlig prognose eller dagsprognose passende.
  • Detaljnivå – Granulariteten til prognosene dine: tidsfrekvens som daglig eller ukentlig, forskjellige butikkplasseringer og forskjellige størrelser på samme vare. Til slutt kan prediksjonen være en kombinasjon av hver butikk-SKU, med daglige datapunkter.

Selv om den nevnte prognosehorisonten og granulariteten bør defineres for å prioritere forretningskravet, kan det hende vi må gjøre avveininger mellom krav og gjennomførbarhet. Ta skobransjen som ett eksempel. Hvis vi ønsker å forutsi salg av hver skostørrelse på hvert butikknivå, blir dataene fort sparsomme og mønsteret vanskelig å finne. For å fylle på lager må vi imidlertid estimere denne granulariteten. For å gjøre dette kan alternative løsninger kreve å estimere et forhold mellom ulike skostørrelser og bruke dette forholdet til å beregne finkornede resultater.

Vi må ofte balansere forretningsbehovet og datamønsteret som kan læres og brukes til prognoser. For å gi en kvantitativ kvalifisering av datamønstrene foreslår vi å bruke dataforutsigbarhet.

Dataforutsigbarhet og datamønsterklassifisering

En av de viktigste innsiktene vi kan samle inn fra måldatasettet er evnen til å produsere kvalitetsprognoser. Dette kan analyseres helt i den tidlige fasen av ML-prosjektet. Prognosen lyser når data viser sesongvariasjoner, trender og sykliske mønstre.

For å bestemme forutsigbarhet er det to hovedkoeffisienter: variasjon i etterspørselstiming og variasjon i etterspørselsmengde. Variasjon i etterspørselstiming betyr intervallet mellom to tilfeller av etterspørsel, og det måler etterspørselsregulariteten i tid. Variasjon i etterspørselsmengde betyr variasjon i mengder. Følgende figur illustrerer noen forskjellige mønstre. Nøyaktighet i prognosen avhenger sterkt av produktets forutsigbarhet. For mer informasjon, se Etterspørselsklassifisering: hvorfor forutsigbarhet er viktig.

Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon av PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.Det er verdt å merke seg at denne forutsigbarhetsanalysen er for hver finkornet vare (for eksempel SKU-Store-Color-Size). Det er ganske vanlig at i et produksjonssystem for etterspørselsprognose følger forskjellige varer forskjellige mønstre. Derfor er det viktig å skille elementene etter forskjellige datamønstre. Et typisk eksempel er gjenstander som beveger seg raskt og sakte; et annet eksempel ville være tette og sparsomme data. I tillegg har en finkornet gjenstand større sjanser til å gi et klumpete mønster. For eksempel i en klesbutikk kan salget av én populær vare gå ganske jevnt daglig, men hvis vi skiller salget av varen ytterligere for hver farge og størrelse, blir det fort sparsomt. Derfor kan reduksjon av granulariteten fra SKU-Store-Color-Size til SKU-Store endre datamønsteret fra klumpete til glatt, og omvendt.

Dessuten bidrar ikke alle varene like mye til salget. Vi har observert at varebidrag ofte følger Pareto-fordelingen, hvor toppvarer bidrar med det meste av salget. Salget av disse toppvarene går ofte jevnt. Varer med lavere salgsrekord er ofte klumpete og uberegnelige, og derfor vanskelig å anslå. Å legge til disse varene kan faktisk redusere nøyaktigheten til de beste salgsvarene. Basert på disse observasjonene kan vi dele varene inn i ulike grupper, trene Forecast-modellen på toppsalgsvarer og håndtere de lavere salgsvarene som hjørnesaker.

Dataanriking og ekstra datasettvalg

Når vi ønsker å bruke flere datasett for å forbedre ytelsen til prognoseresultater, kan vi stole på tidsseriedatasett og metadatadatasett. I detaljhandelsdomenet, basert på intuisjon og domenekunnskap, kan funksjoner som inventar, pris, kampanjer og vinter- eller sommersesonger importeres som den relaterte tidsserien. Den enkleste måten å identifisere nytten av funksjoner på er via funksjonens betydning. I Forecast gjøres dette ved forklaringsanalyse. Prognose Prediktorforklaringsevne hjelper oss å bedre forstå hvordan attributtene i datasettene påvirker prognosene for målet. Prognose bruker en beregning kalt effektscore for å kvantifisere den relative effekten av hvert attributt og bestemme om de øker eller reduserer prognoseverdier. Hvis ett eller flere attributter har en effektscore på null, har disse attributtene ingen signifikant innvirkning på prognoseverdier. På denne måten kan vi raskt fjerne funksjonene som har mindre innvirkning og legge til de potensielle iterativt. Det er viktig å merke seg at effektskåre måler den relative virkningen av attributter, som er normalisert sammen med effektskåre for alle andre attributter.

Som alle ML-prosjekter krever forbedring av nøyaktigheten med tilleggsfunksjoner iterative eksperimenter. Du må eksperimentere med flere kombinasjoner av datasett, mens du observerer virkningen av inkrementelle endringer på modellens nøyaktighet. Du kan prøve å kjøre flere prognoseeksperimenter via prognosekonsollen eller med Python-notatbøker med Forecast APIer. I tillegg kan du ombord med AWS skyformasjon, som distribuerer AWS, leverte ferdige løsninger for vanlige brukstilfeller (for eksempel Forbedre prognosenøyaktigheten med maskinlæringsløsning). Prognose skiller automatisk datasettet og produserer nøyaktighetsmålinger for å evaluere prediktorer. For mer informasjon, se Evaluering av prediktors nøyaktighet. Dette hjelper dataforskere med å iterere raskere for å oppnå den beste modellen.

Avansert forbedring og håndtering av hjørnesaker

Vi nevnte at prognosealgoritmer kan lære sesongvariasjoner, trender og sykliske funksjoner fra data. For varer med disse egenskapene, og passende datatetthet og volum, kan vi bruke Forecast til å generere estimater. Men når vi står overfor klumpete datamønstre, spesielt når datavolumet er lite, må vi kanskje håndtere dem annerledes, for eksempel med empirisk estimering basert på et regelsett.

For tette SKU-er forbedrer vi prognosenøyaktigheten ytterligere ved å trene modellene med lignende oppførende undersett av tidsseriedatasettet. Delsettseparasjonsstrategiene vi brukte er forretningslogikk, produkttype, datatetthet og mønstre lært av algoritmen. Etter at undersettene er generert, kan vi trene flere prognosemodeller for de forskjellige undersettene. For et slikt eksempel, se Klyngetidsseriedata for bruk med Amazon Forecast.

Mot produksjon: Oppdatering av datasettet, overvåking og omskolering

La oss utforske et eksempelarkitektur med Forecast, som vist i følgende diagram. Hver gang en sluttbruker konsoliderer et nytt datasett på Amazon enkel lagringstjeneste (Amazon S3), trigger den AWS trinnfunksjoner å orkestrere forskjellige komponenter, inkludert opprettelse av datasettimportjobben, opprette en automatisk prediktor og generere prognoser. Etter at prognoseresultatene er generert, eksporterer trinnet Create Forecast Export dem til Amazon S3 for nedstrømsforbrukere. For mer informasjon om hvordan du klargjør denne automatiserte rørledningen, se Automatisering med AWS CloudFormation. Den bruker en CloudFormation-stabel for automatisk å distribuere datasett til en S3-bøtte og utløse en prognosepipeline. Du kan bruke samme automatiseringsstabel til å generere prognoser med dine egne datasett.

Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon av PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Det er to måter å innlemme nyere trender i prognosesystemet: oppdatering av data eller omskolering av prediktoren.

For å generere prognosen med oppdaterte data som gjenspeiler nylige trender, må du laste opp den oppdaterte inndatafilen til en S3-bøtte (de oppdaterte inndataene skal fortsatt inneholde alle dine eksisterende data). Prognose omskoler ikke automatisk en prediktor når du importerer et oppdatert datasett. Du kan generere prognoser som du pleier. Prognose forutsier prognosehorisonten fra den siste dagen i de oppdaterte inndataene. Derfor er nyere trender innlemmet i alle nye slutninger produsert av Forecast.

Men hvis du vil at prediktoren din skal trenes opp fra de nye dataene, må du opprette en ny prediktor. Du må kanskje vurdere å omskolere modellen når datamønstre (sesongvariasjoner, trender eller sykluser) endres. Som nevnt i Overvåk prediktorens nøyaktighet kontinuerlig med Amazon Forecast, vil ytelsen til en prediktor fluktuere over tid, på grunn av faktorer som endringer i det økonomiske miljøet eller i forbrukeratferd. Derfor kan det hende at prediktoren må omskoleres, eller en ny prediktor må opprettes for å sikre at svært nøyaktige prediksjoner fortsetter å bli gjort. Med hjelp av prediktorovervåking, Forecast kan spore kvaliteten på prediktorene dine, slik at du kan redusere operativ innsats, samtidig som det hjelper deg å ta mer informerte beslutninger om å beholde, omskolere eller gjenoppbygge prediktorene dine.

konklusjonen

Amazon Forecast er en tidsserieprognosetjeneste basert på ML og bygget for analyse av forretningsmålinger. Vi kan integrere etterspørselsprognoser med høy nøyaktighet ved å kombinere historisk salg og annen relevant informasjon som inventar, kampanjer eller sesong. I løpet av 8 uker hjalp vi en av våre detaljkunder med å oppnå nøyaktig etterspørselsprognose – 10 % forbedring sammenlignet med den manuelle prognosen. Dette fører til en direkte besparelse på 16 arbeidstimer månedlig og estimert salg øker med opptil 11.8 %.

Dette innlegget delte vanlige praksiser for å bringe prognoseprosjektet ditt fra proof of concept til produksjon. Kom i gang nå med Amazon Prognose for å oppnå svært nøyaktige prognoser for virksomheten din.


Om forfatterne

Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon av PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.Yanwei Cui, PhD, er en maskinlæringsspesialistløsningsarkitekt ved AWS. Han startet forskning på maskinlæring ved IRISA (Research Institute of Computer Science and Random Systems), og har flere års erfaring med å bygge kunstig intelligens-drevne industrielle applikasjoner innen datasyn, naturlig språkbehandling og online brukeratferdsprediksjon. Hos AWS deler han domeneekspertisen og hjelper kundene med å låse opp forretningspotensialer og å oppnå handlingsrettede resultater med maskinlæring i stor skala. Utenom jobben liker han å lese og reise.

Implementering av Amazon Forecast i detaljhandelen: En reise fra POC til produksjon av PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.Gordon Wang er senior dataforsker i Professional Services-teamet hos Amazon Web Services. Han støtter kunder i mange bransjer, inkludert media, produksjon, energi, detaljhandel og helsevesen. Han er lidenskapelig opptatt av datasyn, dyp læring og MLOps. På fritiden elsker han løping og fotturer.

Tidstempel:

Mer fra AWS maskinlæring