Hur Amp på Amazon använde data för att öka kundernas engagemang, del 2: Bygga en personlig showrekommendationsplattform med Amazon SageMaker

Förstärkare är en ny liveradioapp från Amazon. Med Amp kan du vara värd för ditt eget radioprogram och spela låtar från Amazon Music-katalogen, eller ställa in och lyssna på program som andra Amp-användare är värd för. I en miljö där innehållet är rikligt och mångsidigt är det viktigt att skräddarsy användarupplevelsen efter varje användares individuella smak, så att de enkelt kan hitta program som de gillar och upptäcka nytt innehåll de skulle uppskatta.

Amp använder maskininlärning (ML) för att ge personliga rekommendationer för live och kommande Amp-shower på appens hemsida. Rekommendationerna beräknas med hjälp av en Random Forest-modell med funktioner som representerar populariteten för en serie (som t.ex. lyssna och gilla antal), populariteten för en kreatör (som totalt antal gånger de senaste programmen spelades) och en användares personliga tillhörighet till en series ämne och skapare. Affiniteter beräknas antingen implicit från användarens beteendedata eller explicit från ämnen av intresse (som popmusik, baseboll eller politik) som anges i användarprofilerna.

Det här är del 2 i en serie om att använda dataanalys och ML för Amp och skapa en personlig plattform för programrekommendationer. Plattformen har visat en ökning på 3 % av mätvärden för kundernas engagemang (att gilla en serie, följa en kreatör, vilket möjliggör kommande programaviseringar) sedan lanseringen i maj 2022.

Hänvisa till del 1 att lära sig hur beteendedata samlades in och bearbetades med hjälp av data- och analyssystemen.

Lösningsöversikt

Den ML-baserade showrekommendatorn för Amp har fem huvudkomponenter, som illustreras i följande arkitekturdiagram:

1. Amp mobilappen.
2. Back-end-tjänster som samlar in beteendedata, som gilla-markeringar och följer, samt sänder programrelaterad information som statusuppdateringar när program går live.
3. Realtidsintag av beteende- och showdata, och realtidsfunktion (online) med beräkning och lagring.
4. Batch-funktion (offline) för datoranvändning och lagring.
5. Ett rekommendationssystem som hanterar inkommande förfrågningar från appens backend för att få en lista över shower. Detta inkluderar slutledning i realtid för att rangordna program baserat på personliga och icke-personliga funktioner.

Det här inlägget fokuserar på delarna 3, 4 och 5 i ett försök att detaljera följande:

Följande diagram visar högnivåarkitekturen och dess komponenter.

I följande avsnitt ger vi mer information om realtidsfunktionsberäkning, batchfunktionsberäkning, realtidsinferens, operativ hälsa och de resultat vi observerade.

Funktionsberäkning i realtid

Vissa funktioner, som gilla- och lyssningsantal för ett program, måste strömmas in kontinuerligt och användas som de är, medan andra, som antalet lyssningssessioner längre än 5 minuter, också måste omvandlas i realtid som rådata för sessioner streamas. Dessa typer av funktioner där värden måste beräknas vid slutledningstidpunkten kallas tidpunkt (PIT) funktioner. Data för PIT-funktioner måste uppdateras snabbt, och den senaste versionen bör skrivas och läsas med låg latens (under 20 millisekunder per användare för 1,000 XNUMX shower). Data måste också finnas i en hållbar lagring eftersom saknade eller delar av data kan orsaka försämrade rekommendationer och dålig kundupplevelse. Förutom läs-/skrivfördröjningen kräver PIT-funktioner också låg reflektionstid. Reflektionstid är den tid det tar för en funktion att vara tillgänglig att läsa efter att de bidragande händelserna sänts ut, till exempel tiden mellan att en lyssnare gillar en show och att PIT LikeCount-funktionen uppdateras.

Datakällorna är backend-tjänsterna som direkt betjänar appen. En del av datan omvandlas till mätvärden som sedan sänds via Amazon enkel meddelandetjänst (Amazon SNS) till nedströmslyssnare som ML-funktionstransformeringspipeline. En minnesdatabas som MemoryDB är en idealisk tjänst för hållbar lagring och ultrasnabb prestanda vid höga volymer. Beräkningskomponenten som transformerar och skriver funktioner till MemoryDB är Lambda. Apptrafiken följer dagliga och veckovisa mönster av toppar och fall beroende på tid och dag. Lambda möjliggör automatisk skalning till inkommande volym av händelser. Den oberoende karaktären hos varje enskild metrisk transformation gör också att Lambda, som är en statslös tjänst i sig, passar bra för detta problem. Att sätta Amazon enkel kötjänst (Amazon SQS) mellan Amazon SNS och Lambda förhindrar inte bara meddelandeförlust utan fungerar också som en buffert för oväntade trafikskurar som förkonfigurerade Lambdas samtidighetsgränser kanske inte är tillräckliga för att betjäna.

Batchfunktionsberäkning

Funktioner som använder historiska beteendedata för att representera en användares ständigt föränderliga smak är mer komplexa att beräkna och kan inte beräknas i realtid. Dessa funktioner beräknas av en batchprocess som körs då och då, till exempel en gång dagligen. Data för batchfunktioner bör stödja snabb sökning för filtrering och aggregering av data, och kan sträcka sig över långa tidsperioder, så den kommer att vara större i volym. Eftersom batchfunktioner också hämtas och skickas som indata för realtidsinferens, bör de fortfarande läsas med låg latens.

Att samla in rådata för batchfunktionsberäkning har inte det krav på underminutsreflektionstid som PIT-funktioner har, vilket gör det möjligt att buffra händelserna längre och transformera mätvärden i batch. Denna lösning använde Kinesis Data Firehose, en hanterad tjänst för att snabbt få in strömmande data till flera destinationer, inklusive Amazon enkel lagringstjänst (Amazon S3) för beständiga mätvärden till S3-datasjön som ska användas i offlineberäkningar. Kinesis Data Firehose tillhandahåller en händelsebuffert och Lambda-integration för att enkelt samla in, batchtransformera och bevara dessa mätvärden till Amazon S3 för att senare användas av batchfunktionsdatorn. Batch-funktionsberäkningar har inte samma låga latens läs/skrivkrav som PIT-funktioner, vilket gör Amazon S3 till det bättre valet eftersom det ger låg kostnad, hållbar lagring för att lagra dessa stora volymer av affärsmått.

Vår första ML-modell använder 21 batchfunktioner som beräknas dagligen med hjälp av data som samlats in under de senaste 2 månaderna. Denna data inkluderar både uppspelnings- och appengagemangshistorik per användare och växer med antalet användare och frekvensen av appanvändning. Funktionsteknik i denna skala kräver en automatiserad process för att hämta nödvändiga indata, bearbeta dem parallellt och exportera resultatet till beständig lagring. Behandlingsinfrastrukturen behövs endast under beräkningarnas varaktighet. SageMaker-bearbetning tillhandahåller förbyggda Docker-bilder som inkluderar Apache Spark och andra beroenden som behövs för att köra distribuerade databearbetningsjobb i stor skala. Den underliggande infrastrukturen för ett bearbetningsjobb hanteras helt av SageMaker. Klusterresurser tillhandahålls under ditt jobb och rensas upp när ett jobb är klart.

Varje steg i batchprocessen – datainsamling, funktionsutveckling, funktionsbeständighet – är en del av ett arbetsflöde som kräver felhantering, omförsök och tillståndsövergångar däremellan. Med AWS stegfunktioner, kan du skapa en tillståndsmaskin och dela upp ditt arbetsflöde i flera steg av förbearbetning och efterbearbetning, samt ett steg för att bevara funktionerna i SageMaker Feature Store eller andra data till Amazon S3. En tillståndsmaskin i Step Functions kan triggas via Amazon EventBridge för att automatisera batchberäkning för att köras enligt ett fastställt schema, till exempel en gång varje dag kl. 10:00 UTC.

Efter att funktionerna har beräknats måste de versioneras och lagras för att kunna läsas under slutledning samt modellomskolning. Istället för att bygga din egen funktionslagring och hanteringstjänst kan du använda SageMaker Feature Store. Feature Store är ett fullt hanterat, specialbyggt arkiv för att lagra, dela och hantera funktioner för ML-modeller. Den lagrar historik över ML-funktioner i offlinebutiken (Amazon S3) och tillhandahåller även API:er till en onlinebutik för att tillåta läsningar med låg latens av de senaste funktionerna. Offlinebutiken kan servera historiska data för ytterligare modellträning och experiment, och onlinebutiken kan anropas av dina kundinriktade API:er för att få funktioner för realtidsslutning. När vi utvecklar våra tjänster för att tillhandahålla mer personligt innehåll, förväntar vi oss att utbilda ytterligare ML-modeller och med hjälp av Feature Store, söka, upptäcka och återanvända funktioner bland dessa modeller.

Inferens i realtid

Realtidsinferens kräver vanligtvis värd för ML-modeller bakom endpoints. Du kan göra detta med hjälp av webbservrar eller behållare, men detta kräver ML ingenjörsarbete och infrastruktur för att hantera och underhålla. SageMaker gör det enkelt att distribuera ML-modeller till slutpunkter i realtid. SageMaker låter dig träna och ladda upp ML-modeller och vara värd för dem genom att skapa och konfigurera SageMaker-slutpunkter. Realtidsinferens uppfyller kraven på låg latens för rankingprogram när de bläddras på Amp-hemsidan.

Förutom hanterad värd tillhandahåller SageMaker hanterad slutpunktsskalning. SageMaker-inferens låter dig definiera en automatisk skalningspolicy med minsta och maximala antal instanser och ett målanvändning för att utlösa skalningen. På så sätt kan du enkelt skala in eller ut när efterfrågan förändras.

Operativ hälsa

Antalet händelser som detta system hanterar för funktionsberäkning i realtid ändras i enlighet med det naturliga mönstret för appanvändning (högre eller lägre trafik baserat på tid på dygnet eller veckodag). På samma sätt skalar antalet förfrågningar den tar emot för realtidsinferens med antalet samtidiga appanvändare. Dessa tjänster får också oväntade toppar i trafiken på grund av självreklam i sociala medier av populära kreatörer. Även om det är viktigt att säkerställa att systemet kan skalas upp och ned för att betjäna den inkommande trafiken framgångsrikt och sparsamt, är det också viktigt att övervaka driftsstatistik och varna för eventuella oväntade driftsproblem för att förhindra förlust av data och service till kunder. Att övervaka hälsan hos dessa tjänster är enkel att använda amazoncloudwatch. Vital hälsostatistik för tjänster som fel och driftfördröjning samt användningsstatistik som minne, disk och CPU-användning är tillgängliga direkt med CloudWatch. Vårt utvecklingsteam använder mätinstrumentpaneler och automatiserad övervakning för att säkerställa att vi kan betjäna våra kunder med hög tillgänglighet (99.8%) och låg latens (mindre än 200 millisekunder från början till slut för att få rekommenderade shower per användare).

Att mäta resultatet

Före den ML-baserade showrekommendatorn som beskrivs i det här inlägget, rankade en enklare heuristisk algoritm Amp-shower baserat på en användares personliga ämnen av intresse som är självrapporterade på deras profil. Vi satte upp ett A/B-test för att mäta effekten av att byta till ML-baserade rekommendationer med en användares data från deras tidigare appinteraktioner. Vi identifierade förbättringar i mätvärden som lyssnarlängd och antal engagemangsåtgärder (gilla en serie, följa en programskapare, aktivera aviseringar) som indikatorer på framgång. A/B-tester med 50 % av användarna som fått programrekommendationer rankade för dem via den ML-baserade rekommendationen har visat en ökning på 3 % av mätvärden för kundernas engagemang och en 0.5 % förbättring av uppspelningslängden.

Slutsats

Med specialbyggda tjänster kunde Amp-teamet släppa det personliga programrekommendations-API:et som beskrivs i det här inlägget till produktion på mindre än 3 månader. Systemet skalar också bra för de oförutsägbara belastningar som skapas av välkända programvärdar eller marknadsföringskampanjer som kan generera en tillströmning av användare. Lösningen använder hanterade tjänster för bearbetning, utbildning och hosting, vilket hjälper till att minska tiden som ägnas åt det dagliga underhållet av systemet. Vi har också möjlighet att övervaka alla dessa hanterade tjänster via CloudWatch för att säkerställa den fortsatta hälsan hos systemen i produktionen.

A/B-testning av den första versionen av Amps ML-baserade rekommendator mot ett regelbaserat tillvägagångssätt (som endast sorterar program efter kundens ämnen av intresse) har visat att den ML-baserade rekommendatorn exponerar kunder för innehåll av högre kvalitet från mer olika ämnen , vilket resulterar i ett högre antal följder och aktiverade aviseringar. Amp-teamet arbetar kontinuerligt med att förbättra modellerna för att ge mycket relevanta rekommendationer.

För mer information om Feature Store, besök Amazon SageMaker Feature Store och kolla in andra kundanvändningsfall i AWS-maskininlärningsblogg.

---

Om författarna

Tulpan Gupta är en lösningsarkitekt på Amazon Web Services. Hon arbetar med Amazon för att designa, bygga och distribuera tekniska lösningar på AWS. Hon hjälper kunderna att ta till sig bästa praxis när hon implementerar lösningar i AWS och är en Analytics- och ML-entusiast. På fritiden tycker hon om att simma, vandra och spela brädspel.

David Kuo är en lösningsarkitekt på Amazon Web Services. Han arbetar med AWS-kunder för att designa, bygga och distribuera tekniska lösningar på AWS. Han arbetar med media- och underhållningskunder och har intressen för maskininlärningsteknik. På fritiden undrar han vad han ska göra med sin fritid.

Manolya McCormick är en Sr Software Development Engineer för Amp på Amazon. Hon designar och bygger distribuerade system med hjälp av AWS för att betjäna kundinriktade applikationer. Hon tycker om att läsa och laga nya recept på fritiden.

Jeff Christophersen är Sr. Data Engineer för Amp på Amazon. Han arbetar med att designa, bygga och distribuera Big Data-lösningar på AWS som driver handlingskraftiga insikter. Han hjälper interna team att ta till sig skalbara och automatiserade lösningar och är en Analytics- och Big Data-entusiast. På fritiden, när han inte är på ett par skidor kan du hitta honom på sin mountainbike.