Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion af PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion

Amazon prognose er en fuldt administreret tjeneste, der bruger statistiske og maskinlæringsalgoritmer (ML) til at levere meget nøjagtige tidsserieprognoser. For nylig, baseret på Amazon Forecast, hjalp vi en af ​​vores detailkunder med at opnå præcise efterspørgselsprognoser inden for 8 uger. Løsningen forbedrede den manuelle prognose med et gennemsnit på 10 % i forhold til WAPE metrisk. Dette fører til en direkte besparelse på 16 arbejdstimer om måneden. Derudover vurderede vi, at ved at opfylde det korrekte antal varer kunne salget stige med op til 11.8 %. I dette indlæg præsenterer vi arbejdsgangen og de kritiske elementer, der skal implementeres – fra proof of concept (POC) til produktion – et efterspørgselsprognosesystem med Amazon Forecast, der fokuserer på udfordringer i detailbranchen.

Baggrund og aktuelle udfordringer for efterspørgselsprognoser i detailbranchen

Målet med efterspørgselsprognose er at estimere fremtidig efterspørgsel ud fra historiske data og at hjælpe med opfyldning af butikker og kapacitetsallokering. Med efterspørgselsprognoser er detailhandlere i stand til at placere den rigtige mængde lager på hver lokation i deres netværk for at imødekomme efterspørgslen. Derfor kan et nøjagtigt prognosesystem skabe en lang række fordele på tværs af forskellige forretningsfunktioner, såsom:

  • Øge salget fra bedre produkttilgængelighed og reducere indsatsen for affald fra butiksoverførsel
  • At give mere pålidelig indsigt for at forbedre kapacitetsudnyttelsen og proaktivt undgå flaskehalse i kapacitetsforsyningen
  • Minimering af lager- og produktionsomkostninger og forbedring af lageromsætning
  • Præsenterer en samlet bedre kundeoplevelse

ML-teknikker viser stor værdi, når en stor mængde data af god kvalitet er til stede. I dag er oplevelsesbaseret opfyldningsstyring eller efterspørgselsprognose stadig mainstream for de fleste detailhandlere. Med det mål at forbedre kundeoplevelsen er flere og flere forhandlere villige til at erstatte oplevelsesbaserede efterspørgselsprognosesystemer med ML-baserede prognoser. Men detailhandlere står over for flere udfordringer, når de implementerer ML-baserede efterspørgselsprognosesystemer i produktionen. Vi opsummerer de forskellige udfordringer i tre kategorier: dataudfordringer, ML-udfordringer og operationelle udfordringer.

Dataudfordringer

En stor mængde rene data af høj kvalitet er et nøglekrav for at opnå nøjagtige ML-baserede forudsigelser. Kvalitetsdata, herunder historiske salgs- og salgsrelaterede data (såsom lager, varepriser og kampagner), skal indsamles og konsolideres. Mangfoldigheden af ​​data fra flere ressourcer kræver en moderne dataplatform til at forene datasiloer. Derudover er adgang til data rettidigt nødvendig for hyppige og finmaskede efterspørgselsprognoser.

ML udfordringer

Udvikling af avancerede ML-algoritmer kræver ekspertise. Implementering af de rigtige algoritmer til det rigtige problem kræver både dybdegående domæneviden og ML-kompetencer. Derudover kræver læring fra store tilgængelige datasæt en skalerbar ML-infrastruktur. Desuden kræver opretholdelse af ML-algoritmer i produktionen ML-kompetencer for at analysere årsagen til modelforringelse og korrekt genoptræne modellen.

For at løse praktiske forretningsproblemer er det kun en del af historien at lave nøjagtige prognoser. Beslutningstagere har brug for probabilistiske prognoser ved forskellige kvantiler, der gør vigtige kundeoplevelser i forhold til økonomiske resultater afvejede beslutninger. De skal også forklare forudsigelser til interessenter og udføre hvad hvis-analyser for at undersøge, hvordan forskellige scenarier kan påvirke prognoseresultater.

Operationelle udfordringer

At reducere den operationelle indsats for at opretholde et omkostningseffektivt prognosesystem er den tredje hovedudfordring. I et almindeligt scenarie med efterspørgselsprognose har hver vare på hver lokation sin egen prognose. Der kræves et system, der til enhver tid kan håndtere hundredtusindvis af prognoser. Derudover har forretningsslutbrugere brug for, at prognosesystemet integreres i eksisterende downstream-systemer, såsom eksisterende supply chain management platforme, så de kan bruge ML-baserede systemer uden at ændre eksisterende værktøjer og processer.

Disse udfordringer er især akutte, når virksomheden er stor, dynamisk og i vækst. For at løse disse udfordringer deler vi en kundesucceshistorie, der reducerer indsatsen for hurtigt at validere den potentielle forretningsgevinst. Dette opnås gennem prototyping med Amazon Forecast - en fuldt administreret tjeneste, der giver nøjagtige prognoseresultater uden behov for at administrere underliggende infrastrukturressourcer og algoritmer.

Hurtig prototyping til et ML-baseret prognosesystem med Amazon Forecast

Baseret på vores erfaring ser vi ofte, at detailkunder er villige til at igangsætte et proof of concept på deres salgsdata. Dette kan gøres inden for et område på et par dage til et par uger for hurtig prototyping, afhængigt af datakompleksiteten og de tilgængelige ressourcer til at iterere gennem modeljusteringsprocessen. Under prototyping foreslår vi at bruge sprints til effektivt at styre processen og adskille POC i dataudforskning, iterativ forbedring og automatiseringsfaser.

Data efterforskning

Dataudforskning involverer ofte intens diskussion med dataforskere eller business intelligence-analytikere for at blive fortrolig med det historiske salgsdatasæt og tilgængelige datakilder, der potentielt kan påvirke prognoseresultater, såsom lagerbeholdning og historiske salgsfremmende begivenheder. En af de mest effektive måder er at konsolidere salgsdata, som måldatasættet, fra datavarehuset på det tidlige stadie af projektet. Dette er baseret på det faktum, at prognoseresultater ofte er domineret af måldatasætmønstrene. Datavarehuse gemmer ofte daglige forretningsdata, og en udtømmende forståelse inden for kort tid er vanskelig og tidskrævende. Vores forslag er at koncentrere sig om at generere måldatasættet og sikre, at dette datasæt er korrekt. Disse dataudforskning og basislinjeresultater kan ofte opnås inden for få dage, og dette kan afgøre, om måldataene kan forudsiges nøjagtigt. Vi diskuterer dataforudsigelighed senere i dette indlæg.

iteration

Når vi har basisresultaterne, kan vi fortsætte med at tilføje flere relaterede data for at se, hvordan disse kan påvirke nøjagtigheden. Dette gøres ofte gennem et dybt dyk ned i yderligere datasæt; for mere information, se Brug af relaterede tidsseriedatasæt , Brug af elementmetadatadatasæt.

I nogle tilfælde kan det være muligt at forbedre nøjagtigheden i Amazon Forecast ved at træne modellerne med ensartede undersæt af datasættet eller ved at fjerne de sparsomme data fra datasættet. I løbet af denne iterative forbedringsfase er den udfordrende del – sandt for alle ML-projekter – at den nuværende iteration afhænger af den tidligere iterations nøgleresultater og indsigter, så streng analyse og rapportering er nøglen til succes.

Analyse kan foretages kvantitativt og empirisk. Det kvantitative aspekt refererer til evaluering under backtesten og sammenligning af nøjagtighedsmetrikken, som f.eks. WAPE. Det empiriske aspekt refererer til at visualisere forudsigelseskurven og faktiske måldata og bruge domæneviden til at inkorporere potentielle faktorer. Disse analyser hjælper dig med at iterere hurtigere for at bygge bro mellem de forventede resultater og måldata. Derudover kan præsentation af sådanne resultater via en ugentlig rapport ofte give tillid til virksomhedernes slutbrugere.

Automation

Det sidste trin involverer ofte diskussionen af ​​POC til produktionsprocedure og automatisering. Fordi ML-projektet er begrænset af den samlede projektvarighed, har vi muligvis ikke tid nok til at undersøge alle muligheder. Derfor kan det ofte skabe tillid at angive det potentielle område gennem resultaterne under projektet. Derudover kan automatisering hjælpe virksomheders slutbrugere med at evaluere Forecast i en længere periode, fordi de kan bruge en eksisterende forudsigelse til at generere prognoser med de opdaterede data.

Succeskriterierne kan evalueres med genererede resultater, både fra teknisk og forretningsmæssigt perspektiv. I løbet af evalueringsperioden kan vi estimere potentielle fordele for følgende:

  • Forøgelse af prognosenøjagtigheden (teknisk) – Beregn forudsigelsesnøjagtigheden med hensyn til faktiske salgsdata, og sammenlign med det eksisterende prognosesystem, inklusive manuelle prognoser
  • Reduktion af affald (forretning) – Reducer overprognoser for at reducere spild
  • Forbedring af lagerpriser (forretning) – Reducer underprognoser for at forbedre lagerpriserne
  • Estimering af stigningen i bruttofortjeneste (forretning) – Reducer spild og forbedre lagerpriserne for at øge bruttofortjenesten

Vi opsummerer udviklingsarbejdsgangen i følgende diagram.

I de følgende afsnit diskuterer vi de vigtige elementer, der skal tages i betragtning under implementeringen.

Trin-for-trin arbejdsgang til udvikling af et prognosesystem

Generering af måldatasæt

Det første trin er at generere måldatasættet til Forecast. I detailbranchen refererer dette til de historiske tidsserieefterspørgsels- og salgsdata for detailvarer (SKU'er). Når du forbereder datasættet, er et vigtigt aspekt granularitet. Vi bør overveje datagranulariteten fra både forretningskrav og tekniske krav.

Virksomheden definerer, hvordan forecasting resulterer i produktionssystemet:

  • Horizon – Antallet af tidstrin, der forudses. Dette afhænger af det underliggende forretningsproblem. Hvis vi ønsker at genopfylde lagerbeholdningen hver uge, så synes en ugentlig prognose eller daglig prognose passende.
  • granularitet – Granulariteten af ​​dine prognoser: tidsfrekvens såsom daglig eller ugentlig, forskellige butiksplaceringer og forskellige størrelser af den samme vare. I sidste ende kan forudsigelsen være en kombination af hver butiks SKU med daglige datapunkter.

Selvom den førnævnte prognosehorisont og granularitet bør defineres for at prioritere forretningskravet, skal vi muligvis foretage afvejninger mellem krav og gennemførlighed. Tag fodtøjsbranchen som et eksempel. Hvis vi ønsker at forudsige salg af hver skostørrelse på hvert butiksniveau, bliver dataene hurtigt sparsomme, og mønsteret er svært at finde. Men for at genopfylde lager skal vi vurdere denne granularitet. For at gøre dette kan alternative løsninger kræve at estimere et forhold mellem forskellige skostørrelser og bruge dette forhold til at beregne finkornede resultater.

Vi har ofte brug for at balancere forretningskravet og det datamønster, der kan læres og bruges til forecasting. For at give en kvantitativ kvalificering af datamønstrene foreslår vi at bruge dataforudsigelighed.

Dataforudsigelighed og datamønsterklassificering

En af de vigtigste indsigter, som vi kan indsamle fra måldatasættet, er dets evne til at producere kvalitetsprognoser. Dette kan analyseres i den meget tidlige fase af ML-projektet. Prognosen lyser, når data viser sæsonudsving, tendenser og cykliske mønstre.

For at bestemme forudsigeligheden er der to hovedkoefficienter: variation i efterspørgselstiming og variabilitet i efterspørgselsmængde. Variation i efterspørgselstiming betyder intervallet mellem to tilfælde af efterspørgsel, og det måler efterspørgselsregulariteten i tid. Variation i efterspørgselsmængde betyder variation i mængder. Følgende figur illustrerer nogle forskellige mønstre. Nøjagtigheden af ​​prognosen afhænger i høj grad af produktets forudsigelighed. For mere information, se Efterspørgselsklassificering: hvorfor forudsigelighed betyder noget.

Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion af PlatoBlockchain Data Intelligence. Lodret søgning. Ai.Det er værd at bemærke, at denne forudsigelige analyse er for hver enkelt finkornet vare (for eksempel SKU-Store-Color-Size). Det er ret almindeligt, at i et efterspørgselsprognoseproduktionssystem følger forskellige varer forskellige mønstre. Derfor er det vigtigt at adskille elementerne efter forskellige datamønstre. Et typisk eksempel er genstande, der bevæger sig hurtigt og langsomt; et andet eksempel ville være tætte og sparsomme data. Derudover har en finkornet genstand flere chancer for at give et klumpet mønster. For eksempel i en tøjbutik kan salget af én populær vare dagligt være ganske jævnt, men hvis vi adskiller salget af varen yderligere for hver farve og størrelse, bliver det hurtigt sparsomt. Derfor kan en reduktion af granulariteten fra SKU-Store-Color-Size til SKU-Store ændre datamønsteret fra klumpet til glat og omvendt.

Desuden er det ikke alle varer, der bidrager lige meget til salget. Vi har observeret, at varebidraget ofte følger Pareto-fordelingen, hvor topvarer bidrager med størstedelen af ​​salget. Salget af disse topvarer er ofte glat. Varer med en lavere salgsrekord er ofte klumpete og uberegnelige, og derfor svære at estimere. Tilføjelse af disse varer kan faktisk reducere nøjagtigheden af ​​topsalgsvarer. Ud fra disse observationer kan vi adskille varerne i forskellige grupper, træne Forecast-modellen på topsalgsvarer og håndtere de lavere salgsvarer som hjørnesager.

Databerigelse og yderligere datasætvalg

Når vi ønsker at bruge yderligere datasæt til at forbedre ydeevnen af ​​prognoseresultater, kan vi stole på tidsseriedatasæt , metadatadatasæt. I detaildomænet, baseret på intuition og domæneviden, kunne funktioner såsom beholdning, pris, kampagner og vinter- eller sommersæsoner importeres som den relaterede tidsserie. Den enkleste måde at identificere anvendeligheden af ​​funktioner er via funktionsvigtighed. I Forecast gøres dette ved forklaringsanalyse. Vejrudsigt Prædiktorforklarlighed hjælper os med bedre at forstå, hvordan attributterne i datasættene påvirker prognoser for målet. Forecast bruger en metrik kaldet effektscore til at kvantificere den relative påvirkning af hver egenskab og bestemme, om de øger eller mindsker prognoseværdier. Hvis en eller flere attributter har en effektscore på nul, har disse attributter ingen væsentlig indflydelse på prognoseværdier. På denne måde kan vi hurtigt fjerne de funktioner, der har mindre indflydelse, og tilføje de potentielle iterativt. Det er vigtigt at bemærke, at effektscore måler den relative effekt af attributter, som er normaliseret sammen med effektscore for alle andre attributter.

Som alle ML-projekter kræver forbedring af nøjagtigheden med yderligere funktioner iterative eksperimenter. Du skal eksperimentere med flere kombinationer af datasæt, mens du observerer virkningen af ​​trinvise ændringer på modelnøjagtigheden. Du kan prøve at køre flere Forecast-eksperimenter via Forecast-konsollen eller med Python-notebooks med Forecast API'er. Derudover kan du ombord med AWS CloudFormation, som implementerer AWS leverede færdige løsninger til almindelige brugssager (for eksempel Forbedring af prognosenøjagtighed med Machine Learning-løsning). Forecast adskiller automatisk datasættet og producerer nøjagtighedsmålinger til at evaluere forudsigelser. For mere information, se Evaluering af prædiktorens nøjagtighed. Dette hjælper dataforskere med at iterere hurtigere for at opnå den bedst ydende model.

Avanceret forbedring og håndtering af hjørnesager

Vi nævnte, at prognosealgoritmer kan lære sæsonbestemte tendenser, og cykliske funktioner fra data. For varer med disse egenskaber og den passende datatæthed og volumen kan vi bruge Forecast til at generere estimater. Men når vi står over for klumpete datamønstre, især når datamængden er lille, kan vi være nødt til at håndtere dem anderledes, såsom med empirisk estimering baseret på et regelsæt.

For tætte SKU'er forbedrer vi prognosenøjagtigheden yderligere ved at træne modellerne med ensartede undersæt af tidsseriedatasættet. De undersætseparationsstrategier, som vi brugte, er forretningslogik, produkttype, datatæthed og mønstre lært af algoritmen. Efter at delmængderne er genereret, kan vi træne flere prognosemodeller for de forskellige delmængder. For et sådant eksempel henvises til Klyngetidsseriedata til brug med Amazon Forecast.

Mod produktion: Opdatering af datasættet, overvågning og genoptræning

Lad os udforske et eksempel på arkitektur med Forecast, som vist i følgende diagram. Hver gang en slutbruger konsoliderer et nyt datasæt på Amazon Simple Storage Service (Amazon S3), udløser den AWS-trinfunktioner at orkestrere forskellige komponenter, herunder oprettelse af datasætimportjobbet, oprettelse af en automatisk forudsigelse og generering af prognoser. Når prognoseresultaterne er genereret, eksporterer trinnet Create Forecast Export dem til Amazon S3 for downstream-forbrugere. For mere information om, hvordan du klargør denne automatiserede pipeline, se Automatisering med AWS CloudFormation. Den bruger en CloudFormation-stak til automatisk at implementere datasæt til en S3-bucket og udløse en prognosepipeline. Du kan bruge den samme automatiseringsstak til at generere prognoser med dine egne datasæt.

Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion af PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

Der er to måder at inkorporere de seneste tendenser i prognosesystemet: opdatering af data eller genoptræning af forudsigeren.

For at generere prognosen med opdaterede data, der afspejler de seneste tendenser, skal du uploade den opdaterede inputdatafil til en S3-bucket (de opdaterede inputdata bør stadig indeholde alle dine eksisterende data). Forecast genoplærer ikke automatisk en forudsigelse, når du importerer et opdateret datasæt. Du kan generere prognoser som du plejer. Forecast forudsiger prognosehorisonten fra den sidste dag i de opdaterede inputdata. Derfor er de seneste tendenser indarbejdet i alle nye konklusioner produceret af Forecast.

Men hvis du ønsker, at din prædiktor skal trænes ud af de nye data, skal du oprette en ny prædiktor. Du skal muligvis overveje at genoptræne modellen, når datamønstre (sæsonbestemte, tendenser eller cyklusser) ændrer sig. Som nævnt i Overvåg konstant prædiktorens nøjagtighed med Amazon Forecast, vil en prædiktors præstation svinge over tid på grund af faktorer som ændringer i det økonomiske miljø eller i forbrugeradfærd. Derfor skal forudsigeren muligvis genoptrænes, eller der skal muligvis oprettes en ny forudsigelse for at sikre, at der fortsat bliver lavet meget nøjagtige forudsigelser. Med hjælp fra overvågning af prædiktorer, Forecast kan spore kvaliteten af ​​dine forudsigere, hvilket giver dig mulighed for at reducere den operationelle indsats, mens den hjælper dig med at træffe mere informerede beslutninger om at beholde, genoptræne eller genopbygge dine forudsigere.

Konklusion

Amazon Forecast er en tidsserieprognosetjeneste baseret på ML og bygget til analyse af forretningsmålinger. Vi kan integrere forudsigelse af efterspørgselsprognose med høj nøjagtighed ved at kombinere historisk salg og anden relevant information såsom lager, kampagner eller sæson. Inden for 8 uger hjalp vi en af ​​vores detailkunder med at opnå nøjagtige efterspørgselsprognoser - 10 % forbedring i forhold til den manuelle prognose. Dette fører til en direkte besparelse på 16 arbejdstimer om måneden og estimeret salg stiger med op til 11.8 %.

Dette indlæg delte fælles praksis for at bringe dit prognoseprojekt fra proof of concept til produktion. Kom i gang nu med Amazon prognose for at opnå meget nøjagtige prognoser for din virksomhed.


Om forfatterne

Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion af PlatoBlockchain Data Intelligence. Lodret søgning. Ai.Yanwei Cui, PhD, er Machine Learning Specialist Solutions Architect hos AWS. Han startede maskinlæringsforskning ved IRISA (Research Institute of Computer Science and Random Systems) og har flere års erfaring med at bygge kunstig intelligens-drevne industrielle applikationer inden for computersyn, naturlig sprogbehandling og online brugeradfærdsforudsigelse. Hos AWS deler han domæneekspertisen og hjælper kunderne med at frigøre forretningspotentialer og skabe handlingsrettede resultater med maskinlæring i stor skala. Uden for arbejdet holder han af at læse og rejse.

Implementering af Amazon Forecast i detailbranchen: En rejse fra POC til produktion af PlatoBlockchain Data Intelligence. Lodret søgning. Ai.Gordon Wang er Senior Data Scientist på Professional Services-teamet hos Amazon Web Services. Han støtter kunder i mange brancher, herunder medier, fremstilling, energi, detailhandel og sundhedspleje. Han brænder for computersyn, deep learning og MLOps. I sin fritid elsker han at løbe og vandre.

Tidsstempel:

Mere fra AWS maskinindlæring