Hvordan Amp på Amazon brugte data til at øge kundeengagementet, del 2: Opbygning af en personlig platform for showanbefaling ved hjælp af Amazon SageMaker

amp er en ny live radio-app fra Amazon. Med Amp kan du være vært for dit eget radioprogram og afspille sange fra Amazon Music-kataloget, eller tune ind og lytte til programmer, som andre Amp-brugere er vært for. I et miljø, hvor indholdet er rigeligt og mangfoldigt, er det vigtigt at skræddersy brugeroplevelsen til hver brugers individuelle smag, så de nemt kan finde udsendelser, de kan lide, og opdage nyt indhold, de ville nyde.

Amp bruger maskinlæring (ML) til at give personlige anbefalinger til live og kommende Amp-shows på appens startside. Anbefalingerne er beregnet ved hjælp af en Random Forest-model ved hjælp af funktioner, der repræsenterer populariteten af ​​et program (såsom lyt og like-antal), populariteten af ​​en skaber (såsom det samlede antal gange, de seneste shows blev spillet) og en brugers personlige tilhørsforhold til et shows emne og skaber. Affiniteter beregnes enten implicit ud fra brugerens adfærdsdata eller eksplicit fra emner af interesse (såsom popmusik, baseball eller politik), som angivet i deres brugerprofiler.

Dette er del 2 af en serie om brug af dataanalyse og ML til Amp og oprettelse af en personlig platform for showanbefalingslister. Platformen har vist et 3 % boost til målinger for kundeengagement, der er sporet (synes godt om et show, følge en skaber, hvilket muliggør kommende shownotifikationer) siden lanceringen i maj 2022.

Der henvises til del 1 at lære, hvordan adfærdsdata blev indsamlet og behandlet ved hjælp af data- og analysesystemerne.

Løsningsoversigt

Den ML-baserede show-anbefaler til Amp har fem hovedkomponenter, som illustreret i følgende arkitekturdiagram:

1. Amp-mobilappen.
2. Back-end-tjenester, der samler adfærdsdata, såsom likes og follows, samt udsender show-relateret information, såsom statusopdateringer, når shows går live.
3. Realtidsindtagelse af adfærds- og showdata og real-time (online) funktionsdatabehandling og lagring.
4. Batch (offline) funktion computing og lagring.
5. Et recommender-system, der håndterer indgående anmodninger fra app-backend for at få en liste over shows. Dette inkluderer realtidsslutning til rangering af shows baseret på personlige og ikke-personlige funktioner.

Dette indlæg fokuserer på del 3, 4 og 5 i et forsøg på at detaljere følgende:

Følgende diagram viser højniveauarkitekturen og dens komponenter.

I de følgende afsnit giver vi flere detaljer om real-time feature computing, batch feature computing, real-time inferens, operationel sundhed og de resultater vi observerede.

Funktionsberegning i realtid

Nogle funktioner, såsom like og lyttetæller for et show, skal streames kontinuerligt og bruges som de er, mens andre, såsom antallet af lyttesessioner længere end 5 minutter, også skal transformeres i realtid som rådata til sessioner streames. Disse typer funktioner, hvor værdier skal beregnes på inferenstidspunktet, kaldes tidspunkt (PIT) funktioner. Data til PIT-funktioner skal opdateres hurtigt, og den seneste version skal skrives og læses med lav latenstid (under 20 millisekunder pr. bruger for 1,000 shows). Dataene skal også være i et holdbart lager, fordi manglende eller delvise data kan forårsage forringede anbefalinger og dårlig kundeoplevelse. Ud over læse-/skriveforsinkelsen kræver PIT-funktioner også lav refleksionstid. Refleksionstid er den tid, det tager for et indslag at være tilgængeligt at læse, efter at de medvirkende begivenheder blev udsendt, for eksempel tiden mellem en lytter, der kan lide et program, og PIT LikeCount-funktionen bliver opdateret.

Kilderne til dataene er backend-tjenesterne, der direkte betjener appen. Nogle af dataene omdannes til metrics, som derefter udsendes via Amazon Simple Notification Service (Amazon SNS) til downstream-lyttere, såsom ML-funktionstransformationspipeline. En database i hukommelsen, såsom MemoryDB, er en ideel service til holdbar lagring og ultrahurtig ydeevne ved store mængder. Beregningskomponenten, der transformerer og skriver funktioner til MemoryDB, er Lambda. Apptrafik følger daglige og ugentlige mønstre af toppe og fald afhængigt af tidspunkt og dag. Lambda giver mulighed for automatisk skalering til indkommende mængde af hændelser. Den uafhængige karakter af hver enkelt metrisk transformation gør også Lambda, som er en statsløs tjeneste i sig selv, til en god pasform til dette problem. Putting Amazon Simple Queue Service (Amazon SQS) mellem Amazon SNS og Lambda forhindrer ikke kun tab af meddelelser, men fungerer også som en buffer for uventede udbrud af trafik, som forudkonfigurerede Lambdas samtidighedsgrænser muligvis ikke er tilstrækkelige til at betjene.

Batch feature computing

Funktioner, der bruger historiske adfærdsdata til at repræsentere en brugers stadigt udviklende smag, er mere komplekse at beregne og kan ikke beregnes i realtid. Disse funktioner beregnes af en batch-proces, der kører med jævne mellemrum, for eksempel én gang dagligt. Data til batchfunktioner bør understøtte hurtig forespørgsel til filtrering og aggregering af data og kan strække sig over lange perioder, så de vil være større i volumen. Fordi batchfunktioner også hentes og sendes som input til realtidsslutning, bør de stadig læses med lav latenstid.

Indsamling af rådata til batch feature computing har ikke det krav om refleksionstid på underminutter, som PIT-funktioner har, hvilket gør det muligt at buffere begivenhederne længere og transformere metrics i batch. Denne løsning brugte Kinesis Data Firehose, en administreret tjeneste til hurtigt at indtage streaming data til flere destinationer, bl.a. Amazon Simple Storage Service (Amazon S3) til vedvarende metrikker til S3-datasøen, der skal bruges i offline-beregninger. Kinesis Data Firehose leverer en hændelsesbuffer og Lambda-integration til nemt at indsamle, batchtransformere og fortsætte disse metrics til Amazon S3 for senere at blive brugt af batch-funktionsbehandlingen. Batch-funktionsberegninger har ikke de samme læse-/skrivekrav med lave latens som PIT-funktioner, hvilket gør Amazon S3 til det bedre valg, fordi det giver billig, holdbar lagring til lagring af disse store mængder af forretningsdata.

Vores første ML-model bruger 21 batch-funktioner, der beregnes dagligt ved hjælp af data, der er registreret i de seneste 2 måneder. Disse data inkluderer både afspilnings- og appengagementhistorik pr. bruger og vokser med antallet af brugere og frekvensen af ​​appbrug. Feature engineering i denne skala kræver en automatiseret proces til at trække de nødvendige inputdata, behandle dem parallelt og eksportere resultatet til vedvarende lagring. Behandlingsinfrastrukturen er kun nødvendig for varigheden af ​​beregningerne. SageMaker-behandling leverer forudbyggede Docker-billeder, der inkluderer Apache Spark og andre afhængigheder, der er nødvendige for at køre distribuerede databehandlingsjob i stor skala. Den underliggende infrastruktur for et Processing-job administreres fuldt ud af SageMaker. Klyngressourcer klargøres i løbet af dit job og ryddes op, når et job er fuldført.

Hvert trin i batchprocessen – dataindsamling, feature engineering, feature persistence – er en del af en arbejdsgang, der kræver fejlhåndtering, genforsøg og tilstandsovergange ind imellem. Med AWS-trinfunktioner, kan du oprette en tilstandsmaskine og opdele din arbejdsgang i flere trin af forbehandling og efterbehandling, samt et trin til at bevare funktionerne i SageMaker Feature Store eller de andre data til Amazon S3. En tilstandsmaskine i Trinfunktioner kan udløses via Amazon Eventbridge at automatisere batch computing til at køre efter en fastsat tidsplan, såsom én gang hver dag kl. 10:00 UTC.

Efter at funktionerne er beregnet, skal de versioneres og gemmes for at blive læst under inferens samt modeloplæring. I stedet for at bygge din egen funktionslagring og administrationstjeneste, kan du bruge SageMaker Feature Store. Feature Store er et fuldt administreret, specialbygget lager til at gemme, dele og administrere funktioner til ML-modeller. Den gemmer historikken for ML-funktioner i offlinebutikken (Amazon S3) og leverer også API'er til en onlinebutik for at tillade læsninger med lav latens af de seneste funktioner. Offline-butikken kan tjene de historiske data til yderligere modeltræning og -eksperimentering, og onlinebutikken kan kaldes af dine kundevendte API'er for at få funktioner til realtidsslutning. Efterhånden som vi udvikler vores tjenester til at levere mere personligt indhold, forventer vi at træne yderligere ML-modeller og ved hjælp af Feature Store søge, opdage og genbruge funktioner blandt disse modeller.

Realtidsslutning

Realtidsslutning kræver normalt hosting af ML-modeller bag endpoints. Du kan gøre dette ved at bruge webservere eller containere, men dette kræver ML-ingeniørindsats og infrastruktur til at administrere og vedligeholde. SageMaker gør det nemt at implementere ML-modeller til slutpunkter i realtid. SageMaker lader dig træne og uploade ML-modeller og hoste dem ved at oprette og konfigurere SageMaker-slutpunkter. Realtidsinferens opfylder kravene til lav latens for rangordningsprogrammer, når de gennemses på Amp-hjemmesiden.

Ud over administreret hosting tilbyder SageMaker administreret slutpunktsskalering. SageMaker-inferens giver dig mulighed for at definere en automatisk skaleringspolitik med minimum og maksimum antal forekomster og en måludnyttelse til at udløse skaleringen. På denne måde kan du nemt skalere ind eller ud, når efterspørgslen ændrer sig.

Operationel sundhed

Antallet af hændelser, som dette system håndterer til funktionsdatabehandling i realtid, ændres i overensstemmelse med det naturlige mønster for appbrug (højere eller lavere trafik baseret på tidspunktet på dagen eller ugedagen). På samme måde skalerer antallet af anmodninger, det modtager om realtidsslutning, med antallet af samtidige appbrugere. Disse tjenester får også uventede toppe i trafikken på grund af selvpromovering på sociale medier fra populære skabere. Selvom det er vigtigt at sikre, at systemet kan skalere op og ned for at betjene den indgående trafik med succes og sparsomt, er det også vigtigt at overvåge operationelle målinger og advare om eventuelle uventede driftsproblemer for at forhindre tab af data og service til kunderne. Overvågning af sundheden for disse tjenester er ligetil at bruge amazoncloudwatch. Vitale tjenestesundhedsmålinger såsom fejl og latens af operationer samt udnyttelsesmålinger såsom hukommelse, disk og CPU-brug er tilgængelige direkte ved hjælp af CloudWatch. Vores udviklingsteam bruger metric-dashboards og automatiseret overvågning for at sikre, at vi kan betjene vores kunder med høj tilgængelighed (99.8%) og lav latency (mindre end 200 millisekunder fra ende til anden for at få anbefalede shows pr. bruger).

Måling af resultatet

Forud for den ML-baserede show-anbefaler beskrevet i dette indlæg, rangerede en enklere heuristisk algoritme Amp-shows baseret på en brugers personlige emner af interesse, som er selvrapporteret på deres profil. Vi opretter en A/B-test for at måle effekten af ​​at skifte til ML-baserede anbefalere med en brugers data fra deres tidligere app-interaktioner. Vi identificerede forbedringer i metrics såsom lyttevarighed og antal engagementshandlinger (synes godt om et program, følge en programskaber, slå notifikationer til) som indikatorer for succes. A/B-test med 50 % af brugerne, der modtager showanbefalinger rangeret for dem via den ML-baserede anbefaling, har vist et 3 % boost til kundeengagement-metrics og en 0.5 % forbedring af afspilningsvarigheden.

Konklusion

Med specialbyggede tjenester var Amp-teamet i stand til at frigive den personlige show-anbefalings-API som beskrevet i dette indlæg til produktion på under 3 måneder. Systemet skalerer også godt til de uforudsigelige belastninger skabt af velkendte programværter eller marketingkampagner, der kan generere en tilstrømning af brugere. Løsningen bruger administrerede tjenester til behandling, træning og hosting, hvilket hjælper med at reducere den tid, der bruges på den daglige vedligeholdelse af systemet. Vi er også i stand til at overvåge alle disse administrerede tjenester via CloudWatch for at sikre den fortsatte sundhed af systemerne i produktionen.

A/B-testning af den første version af Amps ML-baserede anbefaling i forhold til en regelbaseret tilgang (som kun sorterer shows efter kundens emner af interesse) har vist, at den ML-baserede anbefaling udsætter kunder for indhold af højere kvalitet fra mere forskellige emner , hvilket resulterer i et højere antal følger og aktiverede meddelelser. Amp-teamet arbejder løbende på at forbedre modellerne for at give yderst relevante anbefalinger.

For mere information om Feature Store, besøg Amazon SageMaker Feature Store og tjek andre kundetilfælde i AWS Machine Learning Blog.

---

Om forfatterne

Tulip Gupta er Solutions Architect hos Amazon Web Services. Hun arbejder sammen med Amazon om at designe, bygge og implementere teknologiløsninger på AWS. Hun hjælper kunder med at indføre bedste praksis, mens hun implementerer løsning i AWS, og hun er Analytics- og ML-entusiast. I sin fritid nyder hun at svømme, vandre og spille brætspil.

David Kuo er Solutions Architect hos Amazon Web Services. Han arbejder med AWS-kunder for at designe, bygge og implementere teknologiløsninger på AWS. Han arbejder med medie- og underholdningskunder og har interesser i maskinlæringsteknologier. I sin fritid spekulerer han på, hvad han skal gøre med sin fritid.

Manolya McCormick er Sr Software Development Engineer for Amp på Amazon. Hun designer og bygger distribuerede systemer ved hjælp af AWS til at betjene kundevendte applikationer. Hun nyder at læse og lave nye opskrifter i sin fritid.

Jeff Christophersen er Sr. Data Engineer for Amp på Amazon. Han arbejder på at designe, bygge og implementere Big Data-løsninger på AWS, der driver handlingsorienteret indsigt. Han assisterer interne teams med at indføre skalerbare og automatiserede løsninger og er Analytics- og Big Data-entusiast. I fritiden, når han ikke er på et par ski, kan du finde ham på hans mountainbike.