Hvordan Amp på Amazon brukte data for å øke kundeengasjementet, del 2: Bygge en personlig plattform for showanbefaling ved å bruke Amazon SageMaker

Forsterker er en ny direkteradioapp fra Amazon. Med Amp kan du være vert for ditt eget radioprogram og spille av sanger fra Amazon Music-katalogen, eller stille inn og lytte til programmer som andre Amp-brukere er vertskap for. I et miljø der innholdet er rikelig og mangfoldig, er det viktig å skreddersy brukeropplevelsen til hver brukers individuelle smak, slik at de enkelt kan finne programmer de liker og oppdage nytt innhold de vil like.

Amp bruker maskinlæring (ML) for å gi personlige anbefalinger for live og kommende Amp-show på appens hjemmeside. Anbefalingene er beregnet ved å bruke en Random Forest-modell ved å bruke funksjoner som representerer populariteten til et program (som lytt og like-telling), populariteten til en skaper (som totalt antall ganger de siste programmene ble spilt), og personlige tilhørigheter til en bruker til et programs tema og skaper. Tilhørighet beregnes enten implisitt fra brukerens atferdsdata eller eksplisitt fra emner av interesse (som popmusikk, baseball eller politikk) som angitt i brukerprofilene deres.

Dette er del 2 av en serie om bruk av dataanalyse og ML for Amp og å lage en personlig plattform for showanbefalingslister. Plattformen har vist en økning på 3 % av kundeengasjementmålinger som er sporet (liker et show, følger en skaper, muliggjør kommende showvarsler) siden lanseringen i mai 2022.

Referere til Del 1 for å lære hvordan atferdsdata ble samlet inn og behandlet ved hjelp av data- og analysesystemene.

Løsningsoversikt

Den ML-baserte show-anbefaleren for Amp har fem hovedkomponenter, som illustrert i følgende arkitekturdiagram:

1. Amp-mobilappen.
2. Back-end-tjenester som samler atferdsdata, for eksempel liker og følger, samt kringkaster showrelatert informasjon som statusoppdateringer når show går live.
3. Sanntidsinntak av atferdsdata og showdata, og sanntids (online) funksjonsdatabehandling og lagring.
4. Batch (offline) funksjoner databehandling og lagring.
5. Et anbefalingssystem som håndterer innkommende forespørsler fra appens backend for å få en liste over programmer. Dette inkluderer sanntidsslutning til rangering av show basert på personlige og ikke-personlige funksjoner.

Dette innlegget fokuserer på del 3, 4 og 5 i et forsøk på å detaljere følgende:

Følgende diagram viser høynivåarkitekturen og dens komponenter.

I de følgende delene gir vi flere detaljer om sanntidsfunksjonsdatabehandling, batchfunksjonsdatabehandling, sanntidsslutninger, operasjonell helse og resultatene vi observerte.

Funksjonsdatabehandling i sanntid

Noen funksjoner, som liker og lyttetall for et program, må strømmes inn kontinuerlig og brukes som de er, mens andre, for eksempel antall lytteøkter som er lengre enn 5 minutter, også må transformeres i sanntid som rådata for økter streames. Disse typene funksjoner der verdier må beregnes på slutningstidspunktet, kalles tidspunkt (PIT) funksjoner. Data for PIT-funksjoner må oppdateres raskt, og den nyeste versjonen bør skrives og leses med lav ventetid (under 20 millisekunder per bruker for 1,000 show). Dataene må også være i en varig lagring fordi manglende eller deler av data kan føre til forringede anbefalinger og dårlig kundeopplevelse. I tillegg til lese-/skriveforsinkelsen, krever PIT-funksjoner også lav refleksjonstid. Refleksjonstid er tiden det tar før en funksjon er tilgjengelig for å lese etter at de medvirkende hendelsene ble sendt ut, for eksempel tiden mellom en lytter liker et program og PIT LikeCount-funksjonen blir oppdatert.

Kilder til dataene er backend-tjenestene som betjener appen direkte. Noen av dataene omdannes til beregninger som deretter kringkastes via Amazon enkel varslingstjeneste (Amazon SNS) til nedstrøms lyttere som ML-funksjonstransformasjonspipeline. En minnedatabase som MemoryDB er en ideell tjeneste for holdbar lagring og ultrarask ytelse ved høye volumer. Beregningskomponenten som transformerer og skriver funksjoner til MemoryDB er Lambda. Apptrafikken følger daglige og ukentlige mønstre av topper og fall avhengig av tid og dag. Lambda muliggjør automatisk skalering til innkommende volum av hendelser. Den uavhengige karakteren til hver enkelt metrisk transformasjon gjør også at Lambda, som er en statsløs tjeneste i seg selv, passer godt for dette problemet. Sette Amazon enkel køtjeneste (Amazon SQS) mellom Amazon SNS og Lambda forhindrer ikke bare meldingstap, men fungerer også som en buffer for uventede utbrudd av trafikk som forhåndskonfigurerte Lambda-samtidighetsgrenser kanskje ikke er tilstrekkelige til å betjene.

Batch funksjon databehandling

Funksjoner som bruker historiske atferdsdata for å representere en brukers stadig utviklende smak er mer komplekse å beregne og kan ikke beregnes i sanntid. Disse funksjonene beregnes ved hjelp av en batchprosess som kjøres med jevne mellomrom, for eksempel én gang daglig. Data for batchfunksjoner bør støtte rask spørring for filtrering og aggregering av data, og kan strekke seg over lange tidsperioder, og vil derfor være større i volum. Fordi batchfunksjoner også hentes og sendes som innganger for sanntidsslutning, bør de fortsatt leses med lav ventetid.

Innsamling av rådata for batchfunksjonsdatabehandling har ikke kravet til refleksjonstid under minuttene PIT-funksjoner har, noe som gjør det mulig å bufre hendelsene lenger og transformere beregninger i batch. Denne løsningen benyttet Kinesis Data Firehose, en administrert tjeneste for raskt å innta strømmedata til flere destinasjoner, inkludert Amazon enkel lagringstjeneste (Amazon S3) for vedvarende beregninger til S3-datasjøen som skal brukes i offline-beregninger. Kinesis Data Firehose gir en hendelsesbuffer og Lambda-integrasjon for enkelt å samle inn, batchtransformere og vedvare disse beregningene til Amazon S3 for senere å bli brukt av batchfunksjonsdatabehandlingen. Batch-funksjonsberegninger har ikke de samme lave lese-/skrive-kravene som PIT-funksjoner, noe som gjør Amazon S3 til det bedre valget fordi det gir rimelig, holdbar lagring for lagring av disse store volumene av forretningsverdier.

Vår første ML-modell bruker 21 batchfunksjoner beregnet daglig ved hjelp av data som er fanget de siste 2 månedene. Disse dataene inkluderer både avspillings- og appengasjementshistorikk per bruker, og vokser med antall brukere og frekvensen av appbruk. Funksjonsteknikk i denne skalaen krever en automatisert prosess for å hente de nødvendige inndataene, behandle dem parallelt og eksportere resultatet til vedvarende lagring. Behandlingsinfrastrukturen er kun nødvendig under varigheten av beregningene. SageMaker-behandling gir forhåndsbygde Docker-bilder som inkluderer Apache Spark og andre avhengigheter som trengs for å kjøre distribuerte databehandlingsjobber i stor skala. Den underliggende infrastrukturen for en prosesseringsjobb administreres fullt ut av SageMaker. Klyngressursene tilrettelegges for varigheten av jobben din, og ryddes opp når en jobb er fullført.

Hvert trinn i batchprosessen – datainnsamling, funksjonsutvikling, funksjonsfasthet – er en del av en arbeidsflyt som krever feilhåndtering, gjenforsøk og tilstandsoverganger i mellom. Med AWS trinnfunksjoner, kan du opprette en tilstandsmaskin og dele opp arbeidsflyten din i flere trinn med forhåndsbehandling og etterbehandling, samt et trinn for å opprettholde funksjonene i SageMaker Feature Store eller andre data til Amazon S3. En tilstandsmaskin i Step Functions kan utløses via Amazon EventBridge for å automatisere batchdatabehandling for å kjøre på en fastsatt tidsplan, for eksempel én gang hver dag kl. 10:00 UTC.

Etter at funksjonene er beregnet, må de versjoneres og lagres for å kunne leses under inferens samt modellomskolering. I stedet for å bygge din egen funksjonslagrings- og administrasjonstjeneste, kan du bruke SageMaker Feature Store. Feature Store er et fullt administrert, spesialbygd depot for å lagre, dele og administrere funksjoner for ML-modeller. Den lagrer historikk for ML-funksjoner i offline-butikken (Amazon S3) og gir også API-er til en nettbutikk for å tillate lesing med lav latens av de nyeste funksjonene. Den frakoblede butikken kan tjene de historiske dataene for videre modellopplæring og eksperimentering, og nettbutikken kan kalles opp av dine kundevendte API-er for å få funksjoner for sanntidsslutning. Etter hvert som vi utvikler tjenestene våre for å tilby mer personlig innhold, forventer vi opplæring av flere ML-modeller og ved hjelp av Feature Store kan du søke, oppdage og gjenbruke funksjoner blant disse modellene.

Slutning i sanntid

Sanntidsslutning krever vanligvis hosting av ML-modeller bak endepunkter. Du kan gjøre dette ved å bruke webservere eller containere, men dette krever ML-ingeniørarbeid og infrastruktur for å administrere og vedlikeholde. SageMaker gjør det enkelt å distribuere ML-modeller til endepunkter i sanntid. SageMaker lar deg trene og laste opp ML-modeller og være vert for dem ved å opprette og konfigurere SageMaker-endepunkter. Sanntidsslutninger tilfredsstiller kravene til lav latens for rangeringsprogrammer når de surfes på Amp-hjemmesiden.

I tillegg til administrert hosting, tilbyr SageMaker administrert endepunktskalering. SageMaker-inferens lar deg definere en automatisk skaleringspolicy med minimum og maksimum antall forekomster og en målutnyttelse for å utløse skaleringen. På denne måten kan du enkelt skalere inn eller ut når etterspørselen endres.

Operativ helse

Antall hendelser dette systemet håndterer for sanntidsfunksjonsdatabehandling endres tilsvarende med det naturlige mønsteret for appbruk (høyere eller lavere trafikk basert på tid på dagen eller ukedagen). På samme måte skalerer antall forespørsler den mottar for sanntidsslutning med antall samtidige appbrukere. Disse tjenestene får også uventede topper i trafikken på grunn av selvkampanjer i sosiale medier av populære skapere. Selv om det er viktig å sikre at systemet kan skalere opp og ned for å betjene den innkommende trafikken på en vellykket og nøysom måte, er det også viktig å overvåke driftsmålinger og varsle om eventuelle uventede driftsproblemer for å forhindre tap av data og tjenester til kundene. Det er enkelt å overvåke helsen til disse tjenestene Amazon CloudWatch. Vitale tjenestehelseberegninger som feil og ventetid for operasjoner, samt utnyttelsesberegninger som minne, disk og CPU-bruk er tilgjengelig direkte ved bruk av CloudWatch. Utviklingsteamet vårt bruker målepaneler og automatisert overvåking for å sikre at vi kan betjene kundene våre med høy tilgjengelighet (99.8 %) og lav ventetid (mindre enn 200 millisekunder fra ende til annen for å få anbefalte show per bruker).

Måler resultatet

Før den ML-baserte show-anbefaleren beskrevet i dette innlegget, rangerte en enklere heuristisk algoritme Amp-show basert på en brukers personlige emner av interesse som er selvrapportert på profilen deres. Vi satte opp en A/B-test for å måle effekten av å bytte til ML-baserte anbefalere med en brukers data fra tidligere appinteraksjoner. Vi identifiserte forbedringer i beregninger som lyttevarighet og antall engasjementshandlinger (liker et program, følger en programskaper, slår på varsler) som indikatorer på suksess. A/B-testing med 50 % av brukerne som har mottatt programanbefalinger rangert for dem via den ML-baserte anbefalingen, har vist en økning på 3 % i kundeengasjementmålinger og en forbedring på 0.5 % i avspillingsvarigheten.

konklusjonen

Med spesialbygde tjenester var Amp-teamet i stand til å gi ut den personlige programanbefalings-API-en som beskrevet i dette innlegget til produksjon på under 3 måneder. Systemet skalerer også godt for de uforutsigbare belastningene som skapes av kjente programverter eller markedsføringskampanjer som kan generere en tilstrømning av brukere. Løsningen bruker administrerte tjenester for behandling, opplæring og hosting, noe som bidrar til å redusere tiden brukt på daglig vedlikehold av systemet. Vi er også i stand til å overvåke alle disse administrerte tjenestene via CloudWatch for å sikre den fortsatte helsen til systemene i produksjon.

A/B-testing av den første versjonen av Amps ML-baserte anbefaling mot en regelbasert tilnærming (som kun sorterer show etter kundens emner av interesse) har vist at den ML-baserte anbefaleren utsetter kunder for innhold av høyere kvalitet fra mer forskjellige emner , noe som resulterer i et høyere antall følgere og aktiverte varsler. Amp-teamet jobber kontinuerlig med å forbedre modellene for å gi svært relevante anbefalinger.

For mer informasjon om Feature Store, besøk Amazon SageMaker Feature Store og sjekk ut andre kundebrukstilfeller i AWS maskinlæringsblogg.

---

Om forfatterne

Tulip Gupta er løsningsarkitekt hos Amazon Web Services. Hun jobber med Amazon for å designe, bygge og distribuere teknologiløsninger på AWS. Hun hjelper kunder med å ta i bruk beste praksis mens hun implementerer løsning i AWS, og er en Analytics- og ML-entusiast. På fritiden liker hun å svømme, gå tur og spille brettspill.

David Kuo er løsningsarkitekt hos Amazon Web Services. Han jobber med AWS-kunder for å designe, bygge og distribuere teknologiløsninger på AWS. Han jobber med medie- og underholdningskunder og har interesser i maskinlæringsteknologier. På fritiden lurer han på hva han skal gjøre med fritiden.

Manolya McCormick er en Sr Software Development Engineer for Amp på Amazon. Hun designer og bygger distribuerte systemer ved hjelp av AWS for å betjene kundevendte applikasjoner. Hun liker å lese og lage nye oppskrifter på fritiden.

Jeff Christophersen er Sr. Data Engineer for Amp på Amazon. Han jobber med å designe, bygge og distribuere Big Data-løsninger på AWS som gir handlingskraftig innsikt. Han bistår interne team med å ta i bruk skalerbare og automatiserte løsninger, og er en Analytics- og Big Data-entusiast. På fritiden, når han ikke er på et par ski, kan du finne ham på terrengsykkelen hans.