Hoe Amp on Amazon gegevens gebruikte om de klantbetrokkenheid te vergroten, deel 2: een gepersonaliseerd platform voor showaanbevelingen bouwen met Amazon SageMaker

Amp Amp is een nieuwe live radio-app van Amazon. Met Amp kun je je eigen radioshow hosten en nummers uit de Amazon Music-catalogus afspelen, of afstemmen en luisteren naar shows die andere Amp-gebruikers hosten. In een omgeving waar inhoud overvloedig en divers is, is het belangrijk om de gebruikerservaring af te stemmen op de individuele smaak van elke gebruiker, zodat ze gemakkelijk programma's kunnen vinden die ze leuk vinden en nieuwe inhoud kunnen ontdekken die ze leuk zouden vinden.

Amp gebruikt machine learning (ML) om gepersonaliseerde aanbevelingen te doen voor live en aankomende Amp-shows op de startpagina van de app. De aanbevelingen worden berekend met behulp van een Random Forest-model met functies die de populariteit van een programma weergeven (zoals het aantal luister- en vind-ik-leuks), de populariteit van een maker (zoals het totale aantal keren dat de recente programma's zijn afgespeeld) en persoonlijke affiniteiten van een gebruiker naar het onderwerp en de maker van een show. Affiniteiten worden ofwel impliciet berekend op basis van de gedragsgegevens van de gebruiker of expliciet op basis van interessante onderwerpen (zoals popmuziek, honkbal of politiek) zoals vermeld in hun gebruikersprofielen.

Dit is deel 2 van een serie over het gebruik van data-analyse en ML voor Amp en het maken van een gepersonaliseerd platform voor showaanbevelingen. Het platform heeft sinds de lancering in mei 3 een toename van 2022% laten zien aan de bijgehouden klantbetrokkenheidsstatistieken (een show leuk vinden, een maker volgen, aankomende showmeldingen inschakelen).

Verwijzen naar Deel 1 om te leren hoe gedragsgegevens werden verzameld en verwerkt met behulp van de gegevens- en analysesystemen.

Overzicht oplossingen

De op ML gebaseerde showaanbeveler voor Amp heeft vijf hoofdcomponenten, zoals geïllustreerd in het volgende architectuurdiagram:

1. De mobiele Amp-app.
2. Back-endservices die de gedragsgegevens verzamelen, zoals vind-ik-leuks en volgt, en showgerelateerde informatie uitzenden, zoals statusupdates wanneer shows live gaan.
3. Realtime opname van gedrags- en showgegevens, en realtime (online) feature computing en opslag.
4. Batch (offline) functie computing en opslag.
5. Een aanbevelingssysteem dat inkomende verzoeken van de app-backend afhandelt om een ​​lijst met shows te krijgen. Dit omvat realtime gevolgtrekking om shows te rangschikken op basis van gepersonaliseerde en niet-gepersonaliseerde functies.

Dit bericht richt zich op de delen 3, 4 en 5 in een poging om het volgende in detail te beschrijven:

Het volgende diagram toont de architectuur op hoog niveau en de componenten ervan.

In de volgende secties geven we meer details over realtime feature computing, batch feature computing, realtime gevolgtrekking, operationele gezondheid en de resultaten die we hebben waargenomen.

Functieberekening in realtime

Sommige functies, zoals leuk vinden en luisteren tellen voor een show, moeten continu worden gestreamd en gebruikt zoals ze zijn, terwijl andere, zoals het aantal luistersessies langer dan 5 minuten, ook in realtime moeten worden omgezet als onbewerkte gegevens voor sessies wordt gestreamd. Dit soort functies waarbij waarden moeten worden berekend op het moment van inferentie, worden aangeduid als: punt in de tijd (PIT) functies. Gegevens voor PIT-functies moeten snel worden bijgewerkt en de nieuwste versie moet worden geschreven en gelezen met een lage latentie (minder dan 20 milliseconden per gebruiker voor 1,000 shows). De gegevens moeten ook in een duurzame opslag staan, omdat ontbrekende of gedeeltelijke gegevens kunnen leiden tot verslechterde aanbevelingen en een slechte klantervaring. Naast de lees-/schrijflatentie vereisen PIT-functies ook een lage reflectietijd. Reflectietijd is de tijd die nodig is voordat een functie beschikbaar is om te worden gelezen nadat de bijdragende gebeurtenissen zijn uitgezonden, bijvoorbeeld de tijd tussen een luisteraar die een programma leuk vindt en de PIT LikeCount-functie wordt bijgewerkt.

Bronnen van de gegevens zijn de backend-services die rechtstreeks de app bedienen. Sommige gegevens worden omgezet in statistieken die vervolgens worden uitgezonden via Amazon eenvoudige meldingsservice (Amazon SNS) naar downstream-luisteraars, zoals de ML-functietransformatiepijplijn. Een in-memory database zoals MemoryDB is een ideale service voor duurzame opslag en ultrasnelle prestaties bij hoge volumes. De rekencomponent die functies transformeert en schrijft naar MemoryDB is Lambda. App-verkeer volgt dagelijkse en wekelijkse patronen van pieken en dalen, afhankelijk van het tijdstip en de dag. Lambda zorgt voor automatische schaling naar inkomend volume van gebeurtenissen. Het onafhankelijke karakter van elke individuele metrische transformatie maakt Lambda, dat op zichzelf een staatloze service is, ook geschikt voor dit probleem. zetten Amazon Simple Queue-service (Amazon SQS) tussen Amazon SNS en Lambda voorkomt niet alleen berichtverlies, maar fungeert ook als een buffer voor onverwachte uitbarstingen van verkeer waarvoor vooraf geconfigureerde Lambda-gelijktijdigheidslimieten mogelijk niet voldoende zijn.

Batchfunctie-computing

Functies die historische gedragsgegevens gebruiken om de steeds veranderende smaak van een gebruiker weer te geven, zijn complexer om te berekenen en kunnen niet in realtime worden berekend. Deze functies worden berekend door een batchproces dat om de zoveel tijd wordt uitgevoerd, bijvoorbeeld eenmaal per dag. Gegevens voor batchfuncties moeten snelle query's ondersteunen voor het filteren en aggregeren van gegevens, en kunnen lange perioden beslaan, en zullen dus groter zijn in volume. Omdat batchfuncties ook worden opgehaald en verzonden als invoer voor realtime gevolgtrekking, moeten ze nog steeds met een lage latentie worden gelezen.

Het verzamelen van onbewerkte gegevens voor batchfunctieberekening heeft niet de sub-minuten reflectietijd die PIT-functies nodig hebben, waardoor het mogelijk is om de gebeurtenissen langer te bufferen en metrische gegevens in batch te transformeren. Deze oplossing maakte gebruik van Kinesis Data Firehose, een beheerde service om snel streaminggegevens op verschillende bestemmingen op te nemen, waaronder: Amazon eenvoudige opslagservice (Amazon S3) voor persistente statistieken voor het S3-datameer voor gebruik in offline berekeningen. Kinesis Data Firehose biedt een gebeurtenisbuffer en Lambda-integratie om deze statistieken eenvoudig te verzamelen, batchgewijs te transformeren en te bewaren voor Amazon S3 om later te worden gebruikt door de batchfunctie-computing. Batch-functieberekeningen hebben niet dezelfde lees-/schrijfvereisten met lage latentie als PIT-functies, waardoor Amazon S3 de betere keuze is omdat het goedkope, duurzame opslag biedt voor het opslaan van deze grote hoeveelheden zakelijke statistieken.

Ons eerste ML-model gebruikt 21 batchfuncties die dagelijks worden berekend op basis van gegevens die in de afgelopen 2 maanden zijn vastgelegd. Deze gegevens omvatten zowel afspeel- als app-betrokkenheidsgeschiedenis per gebruiker en groeien met het aantal gebruikers en de frequentie van app-gebruik. Feature-engineering op deze schaal vereist een geautomatiseerd proces om de vereiste invoergegevens op te halen, deze parallel te verwerken en het resultaat naar permanente opslag te exporteren. De verwerkingsinfrastructuur is alleen nodig voor de duur van de berekeningen. SageMaker-verwerking biedt vooraf gebouwde Docker-images die Apache Spark en andere afhankelijkheden bevatten die nodig zijn om op grote schaal gedistribueerde gegevensverwerkingstaken uit te voeren. De onderliggende infrastructuur voor een Processing-taak wordt volledig beheerd door SageMaker. Clusterresources worden ingericht voor de duur van uw taak en opgeschoond wanneer een taak is voltooid.

Elke stap in het batchproces - gegevensverzameling, feature-engineering, feature-persistentie - maakt deel uit van een workflow die foutafhandeling, nieuwe pogingen en statusovergangen daartussen vereist. Met AWS Stap Functies, kunt u een statusmachine maken en uw workflow opsplitsen in verschillende stappen van voorverwerking en naverwerking, evenals een stap om de functies in SageMaker Feature Store of de andere gegevens naar Amazon S3 te bewaren. Een statusmachine in Step Functions kan worden geactiveerd via Amazon EventBridge om batchcomputing te automatiseren zodat deze volgens een vast schema wordt uitgevoerd, zoals eenmaal per dag om 10:00 uur UTC.

Nadat de functies zijn berekend, moeten ze worden geversied en opgeslagen om te kunnen worden gelezen tijdens inferentie en bij het opnieuw trainen van modellen. In plaats van uw eigen opslag- en beheerservice voor functies te bouwen, kunt u SageMaker Feature Store gebruiken. Feature Store is een volledig beheerde, speciaal gebouwde opslagplaats voor het opslaan, delen en beheren van functies voor ML-modellen. Het slaat de geschiedenis van ML-functies op in de offline winkel (Amazon S3) en biedt ook API's aan een online winkel om het lezen van de meest recente functies met lage latentie mogelijk te maken. De offline winkel kan de historische gegevens dienen voor verdere modeltraining en experimenten, en de online winkel kan worden aangeroepen door uw klantgerichte API's om functies voor realtime gevolgtrekking te krijgen. Naarmate we onze services verder ontwikkelen om meer gepersonaliseerde inhoud te bieden, verwachten we extra ML-modellen te trainen en met behulp van Feature Store functies tussen deze modellen te zoeken, ontdekken en hergebruiken.

Real-time gevolgtrekking

Realtime gevolgtrekking vereist meestal het hosten van ML-modellen achter eindpunten. U zou dit kunnen doen met behulp van webservers of containers, maar dit vereist ML-engineering en infrastructuur om te beheren en te onderhouden. SageMaker maakt het eenvoudig om ML-modellen te implementeren op realtime eindpunten. Met SageMaker kunt u ML-modellen trainen, uploaden en hosten door SageMaker-eindpunten te maken en te configureren. Realtime gevolgtrekking voldoet aan de lage latentievereisten voor het rangschikken van shows zoals ze worden bekeken op de Amp-startpagina.

Naast managed hosting biedt SageMaker managed endpoint scaling. Met SageMaker-inferentie kunt u een beleid voor automatisch schalen definiëren met minimale en maximale aantallen exemplaren en een doelgebruik om de schaling te activeren. Op deze manier kunt u eenvoudig in- of uitschalen als de vraag verandert.

operationele gezondheid

Het aantal gebeurtenissen dat dit systeem verwerkt voor realtime feature computing verandert overeenkomstig met het natuurlijke patroon van app-gebruik (meer of minder verkeer op basis van het tijdstip van de dag of de dag van de week). Evenzo wordt het aantal verzoeken dat het ontvangt voor realtime gevolgtrekkingen geschaald met het aantal gelijktijdige app-gebruikers. Deze diensten krijgen ook onverwachte pieken in het verkeer als gevolg van zelfpromoties in sociale media door populaire makers. Hoewel het belangrijk is om ervoor te zorgen dat het systeem op en neer kan schalen om het inkomende verkeer met succes en zuinig te bedienen, is het ook belangrijk om operationele statistieken te bewaken en te waarschuwen voor onverwachte operationele problemen om verlies van gegevens en service aan klanten te voorkomen. Het bewaken van de status van deze services is eenvoudig met behulp van Amazon Cloud Watch. Vitale service-gezondheidsstatistieken zoals fouten en latentie van bewerkingen, evenals gebruiksstatistieken zoals geheugen-, schijf- en CPU-gebruik zijn kant-en-klaar beschikbaar met CloudWatch. Ons ontwikkelingsteam gebruikt metrische dashboards en geautomatiseerde monitoring om ervoor te zorgen dat we onze klanten kunnen bedienen met hoge beschikbaarheid (99.8%) en lage latentie (minder dan 200 milliseconden end-to-end om aanbevolen shows per gebruiker te krijgen).

Het resultaat meten

Voorafgaand aan de op ML gebaseerde showaanbeveler die in dit bericht wordt beschreven, rangschikte een eenvoudiger heuristisch algoritme Amp-shows op basis van de persoonlijke interesseonderwerpen van een gebruiker die zelf op hun profiel zijn gerapporteerd. We hebben een A/B-test opgezet om de impact te meten van het overschakelen naar op ML gebaseerde aanbevelingen met de gegevens van een gebruiker uit eerdere app-interacties. We identificeerden verbeteringen in statistieken zoals luisterduur en aantal betrokkenheidsacties (een show leuk vinden, een maker van een show volgen, meldingen inschakelen) als indicatoren voor succes. A/B-tests waarbij 50% van de gebruikers show-aanbevelingen ontvingen die voor hen werden gerangschikt via de op ML gebaseerde aanbeveling, hebben een toename van 3% laten zien in de statistieken voor klantbetrokkenheid en een verbetering van 0.5% in de afspeelduur.

Conclusie

Met speciaal gebouwde services kon het Amp-team de gepersonaliseerde API voor showaanbevelingen, zoals beschreven in dit bericht, in minder dan 3 maanden in productie nemen. Het systeem schaalt ook goed voor de onvoorspelbare belastingen die worden gecreëerd door bekende showhosts of marketingcampagnes die een toestroom van gebruikers kunnen genereren. De oplossing maakt gebruik van beheerde services voor verwerking, training en hosting, waardoor de tijd die wordt besteed aan het dagelijkse onderhoud van het systeem wordt verminderd. We zijn ook in staat om al deze beheerde services via CloudWatch te bewaken om de voortdurende gezondheid van de systemen in productie te garanderen.

A/B-testen van de eerste versie van de op ML gebaseerde aanbeveling van de Amp tegen een op regels gebaseerde benadering (die alleen sorteert op de onderwerpen van de klant die van belang zijn) heeft aangetoond dat de op ML gebaseerde aanbeveling klanten blootstelt aan inhoud van hogere kwaliteit uit meer diverse onderwerpen , wat resulteert in een hoger aantal volgers en ingeschakelde meldingen. Het Amp-team werkt continu aan het verbeteren van de modellen om zeer relevante aanbevelingen te kunnen doen.

Ga voor meer informatie over Feature Store naar: Amazon SageMaker Feature Store en bekijk andere gebruiksvoorbeelden van klanten in de AWS Blog over machine learning.

---

Over de auteurs

Tulp Gupta is Solutions Architect bij Amazon Web Services. Ze werkt samen met Amazon om technologische oplossingen op AWS te ontwerpen, bouwen en implementeren. Ze helpt klanten bij het toepassen van best practices bij het implementeren van oplossingen in AWS, en is een enthousiaste Analytics- en ML-fan. In haar vrije tijd houdt ze van zwemmen, wandelen en bordspellen spelen.

David Koe is Solutions Architect bij Amazon Web Services. Hij werkt samen met AWS-klanten om technologische oplossingen op AWS te ontwerpen, bouwen en implementeren. Hij werkt met media- en entertainmentklanten en heeft interesse in machine learning-technologieën. In zijn vrije tijd vraagt ​​hij zich af wat hij met zijn vrije tijd moet doen.

Manolya McCormick is een Senior Software Development Engineer voor Amp op Amazon. Ze ontwerpt en bouwt gedistribueerde systemen met behulp van AWS om klantgerichte applicaties te bedienen. In haar vrije tijd leest ze graag en kookt ze graag nieuwe recepten.

Jef Christophersen is een Sr. Data Engineer voor Amp op Amazon. Hij werkt aan het ontwerpen, bouwen en implementeren van Big Data-oplossingen op AWS die bruikbare inzichten opleveren. Hij assisteert interne teams bij het adopteren van schaalbare en geautomatiseerde oplossingen en is een liefhebber van Analytics en Big Data. In zijn vrije tijd, als hij niet op een paar ski's staat, vind je hem op zijn mountainbike.