In che modo Amp on Amazon ha utilizzato i dati per aumentare il coinvolgimento dei clienti, parte 2: creazione di una piattaforma di consigli per spettacoli personalizzati utilizzando Amazon SageMaker

amplificatore è una nuova app radio in diretta di Amazon. Con Amp, puoi ospitare il tuo programma radiofonico e riprodurre brani dal catalogo Amazon Music, oppure sintonizzarti e ascoltare i programmi ospitati da altri utenti Amp. In un ambiente in cui i contenuti sono abbondanti e diversificati, è importante adattare l'esperienza dell'utente ai gusti individuali di ciascun utente, in modo che possano trovare facilmente i programmi che gli piacciono e scoprire nuovi contenuti che potrebbero apprezzare.

Amp utilizza l'apprendimento automatico (ML) per fornire consigli personalizzati per gli spettacoli Amp dal vivo e imminenti nella home page dell'app. I consigli vengono calcolati utilizzando un modello Random Forest utilizzando funzionalità che rappresentano la popolarità di uno spettacolo (come il conteggio di ascolto e Mi piace), la popolarità di un creatore (come il numero totale di volte in cui sono stati riprodotti gli spettacoli recenti) e le affinità personali di un utente all'argomento e al creatore di uno spettacolo. Le affinità sono calcolate in modo implicito dai dati comportamentali dell'utente o esplicitamente da argomenti di interesse (come musica pop, baseball o politica) come forniti nei loro profili utente.

Questa è la parte 2 di una serie sull'utilizzo dell'analisi dei dati e del machine learning per Amp e sulla creazione di una piattaforma personalizzata per l'elenco dei consigli per gli spettacoli. La piattaforma ha mostrato un aumento del 3% delle metriche di coinvolgimento dei clienti monitorate (apprezzare uno spettacolo, seguire un creatore, abilitare le notifiche di spettacoli imminenti) dal suo lancio nel maggio 2022.

Fare riferimento a Parte 1 per apprendere come i dati comportamentali sono stati raccolti ed elaborati utilizzando i dati e i sistemi di analisi.

Panoramica della soluzione

Il suggeritore di spettacoli basato su ML per Amp ha cinque componenti principali, come illustrato nel diagramma dell'architettura seguente:

1. L'app mobile Amp.
2. Servizi di back-end che raccolgono i dati comportamentali, come Mi piace e follower, nonché trasmettono informazioni relative allo spettacolo come aggiornamenti di stato quando gli spettacoli vanno in diretta.
3. Importazione in tempo reale di dati comportamentali e di spettacolo e funzionalità di elaborazione e archiviazione in tempo reale (online).
4. Funzionalità batch (offline) di elaborazione e archiviazione.
5. Un sistema di raccomandazione che gestisce le richieste in arrivo dal back-end dell'app per ottenere un elenco di spettacoli. Ciò include l'inferenza in tempo reale per classificare gli spettacoli in base a funzionalità personalizzate e non.

Questo post si concentra sulle parti 3, 4 e 5 nel tentativo di dettagliare quanto segue:

Il diagramma seguente mostra l'architettura di alto livello e i suoi componenti.

Nelle sezioni seguenti, forniamo maggiori dettagli sull'elaborazione delle funzionalità in tempo reale, sull'elaborazione delle funzionalità in batch, sull'inferenza in tempo reale, sull'integrità operativa e sui risultati che abbiamo osservato.

Calcolo delle funzionalità in tempo reale

Alcune funzioni, come il conteggio di Mi piace e ascolti per uno spettacolo, devono essere trasmesse in streaming continuamente e utilizzate così come sono, mentre altre, come il numero di sessioni di ascolto superiori a 5 minuti, devono anche essere trasformate in tempo reale come dati grezzi per le sessioni è in streaming. Questi tipi di funzionalità in cui i valori devono essere calcolati al momento dell'inferenza sono indicati come punto nel tempo (PIT). I dati per le funzionalità PIT devono essere aggiornati rapidamente e l'ultima versione deve essere scritta e letta con una bassa latenza (meno di 20 millisecondi per utente per 1,000 spettacoli). I dati devono inoltre trovarsi in uno spazio di archiviazione durevole perché dati mancanti o parziali possono causare consigli deteriorati e una scarsa esperienza del cliente. Oltre alla latenza di lettura/scrittura, le funzionalità PIT richiedono anche un tempo di riflessione ridotto. Il tempo di riflessione è il tempo necessario affinché una funzione sia disponibile per la lettura dopo che sono stati emessi gli eventi contribuenti, ad esempio il tempo che intercorre tra un ascoltatore che apprezza uno spettacolo e l'aggiornamento della funzione PIT LikeCount.

Le fonti dei dati sono i servizi di back-end che servono direttamente l'app. Alcuni dei dati vengono trasformati in metriche che vengono poi trasmesse tramite Servizio di notifica semplice Amazon (Amazon SNS) ai listener a valle, come la pipeline di trasformazione delle funzionalità di ML. Un database in memoria come MemoryDB è un servizio ideale per l'archiviazione duratura e prestazioni ultraveloci a volumi elevati. Il componente di calcolo che trasforma e scrive le funzionalità in MemoryDB è Lambda. Il traffico dell'app segue schemi giornalieri e settimanali di picchi e cali a seconda dell'ora e del giorno. Lambda consente il ridimensionamento automatico in base al volume di eventi in entrata. La natura indipendente di ogni singola trasformazione della metrica rende anche Lambda, che è di per sé un servizio stateless, una buona soluzione per questo problema. Mettendo Servizio Amazon Simple Queue (Amazon SQS) tra Amazon SNS e Lambda non solo previene la perdita di messaggi, ma funge anche da buffer per esplosioni di traffico impreviste che i limiti di concorrenza Lambda preconfigurati potrebbero non essere sufficienti per servire.

Calcolo delle funzionalità in batch

Le funzionalità che utilizzano dati comportamentali storici per rappresentare il gusto in continua evoluzione di un utente sono più complesse da calcolare e non possono essere calcolate in tempo reale. Queste funzionalità sono calcolate da un processo batch che viene eseguito ogni tanto, ad esempio una volta al giorno. I dati per le funzionalità batch dovrebbero supportare query rapide per il filtraggio e l'aggregazione dei dati e possono estendersi per lunghi periodi di tempo, quindi avranno un volume maggiore. Poiché le funzionalità batch vengono anche recuperate e inviate come input per l'inferenza in tempo reale, dovrebbero comunque essere lette con una bassa latenza.

La raccolta di dati grezzi per il calcolo delle funzionalità in batch non ha il requisito di tempo di riflessione inferiore al minuto delle funzionalità PIT, il che rende possibile il buffering degli eventi più a lungo e la trasformazione delle metriche in batch. Questa soluzione utilizzava Kinesis Data Firehose, un servizio gestito per acquisire rapidamente i dati in streaming in diverse destinazioni, tra cui Servizio di archiviazione semplice Amazon (Amazon S3) per la persistenza delle metriche nel data lake S3 da utilizzare nei calcoli offline. Kinesis Data Firehose fornisce un buffer di eventi e un'integrazione Lambda per raccogliere, trasformare in batch e mantenere facilmente questi parametri su Amazon S3 per essere utilizzati in seguito dal calcolo delle funzionalità batch. I calcoli delle funzionalità batch non hanno gli stessi requisiti di lettura/scrittura a bassa latenza delle funzionalità PIT, il che rende Amazon S3 la scelta migliore perché fornisce uno storage durevole e a basso costo per l'archiviazione di questi grandi volumi di parametri aziendali.

Il nostro modello ML iniziale utilizza 21 funzioni batch calcolate giornalmente utilizzando i dati acquisiti negli ultimi 2 mesi. Questi dati includono sia la cronologia di riproduzione che quella di coinvolgimento dell'app per utente e crescono con il numero di utenti e la frequenza di utilizzo dell'app. L'ingegneria delle funzionalità su questa scala richiede un processo automatizzato per estrarre i dati di input richiesti, elaborarli in parallelo ed esportare il risultato nell'archiviazione permanente. L'infrastruttura di elaborazione è necessaria solo per la durata dei calcoli. Elaborazione di SageMaker fornisce immagini Docker predefinite che includono Apache Spark e altre dipendenze necessarie per eseguire processi di elaborazione dati distribuiti su larga scala. L'infrastruttura sottostante per un lavoro di elaborazione è completamente gestita da SageMaker. Le risorse del cluster vengono fornite per la durata del processo e ripulite al termine del processo.

Ogni fase del processo batch (raccolta dati, progettazione delle funzionalità, persistenza delle funzionalità) fa parte di un flusso di lavoro che richiede la gestione degli errori, i tentativi e le transizioni di stato intermedie. Insieme a Funzioni AWS Step, puoi creare una macchina a stati e suddividere il flusso di lavoro in diversi passaggi di preelaborazione e postelaborazione, nonché un passaggio per mantenere le funzionalità in SageMaker Feature Store o gli altri dati in Amazon S3. Una macchina a stati in Step Functions può essere attivata tramite Amazon EventBridge per automatizzare l'elaborazione batch per l'esecuzione a una pianificazione prestabilita, ad esempio una volta al giorno alle 10:00 UTC.

Dopo che le funzionalità sono state calcolate, è necessario verificarne la versione e archiviarle per essere lette durante l'inferenza e il riaddestramento del modello. Invece di creare il tuo servizio di gestione e archiviazione delle funzionalità, puoi utilizzare SageMaker Feature Store. Feature Store è un repository completamente gestito e creato appositamente per archiviare, condividere e gestire le funzionalità per i modelli ML. Memorizza la cronologia delle funzionalità di ML nel negozio offline (Amazon S3) e fornisce anche API a un negozio online per consentire letture a bassa latenza delle funzionalità più recenti. Il negozio offline può fornire i dati storici per ulteriore addestramento e sperimentazione del modello e il negozio online può essere chiamato dalle API rivolte ai clienti per ottenere funzionalità per l'inferenza in tempo reale. Man mano che evolviamo i nostri servizi per fornire contenuti più personalizzati, prevediamo la formazione di modelli ML aggiuntivi e, con l'aiuto di Feature Store, ricerca, scopri e riutilizza le funzionalità tra questi modelli.

Inferenza in tempo reale

L'inferenza in tempo reale richiede solitamente l'hosting di modelli ML dietro gli endpoint. Puoi farlo utilizzando server Web o container, ma ciò richiede uno sforzo di progettazione e un'infrastruttura di ML per la gestione e la manutenzione. SageMaker semplifica la distribuzione di modelli ML su endpoint in tempo reale. SageMaker ti consente di addestrare e caricare modelli ML e ospitarli creando e configurando gli endpoint SageMaker. L'inferenza in tempo reale soddisfa i requisiti di bassa latenza per classificare gli spettacoli mentre vengono sfogliati nella home page di Amp.

Oltre all'hosting gestito, SageMaker fornisce il ridimensionamento degli endpoint gestito. L'inferenza di SageMaker consente di definire una policy di ridimensionamento automatico con un numero minimo e massimo di istanze e un utilizzo target per attivare il ridimensionamento. In questo modo, puoi facilmente aumentare o ridurre la domanda al variare della domanda.

Salute operativa

Il numero di eventi gestiti da questo sistema per il calcolo delle funzionalità in tempo reale cambia di conseguenza con il modello naturale di utilizzo dell'app (traffico maggiore o minore in base all'ora del giorno o al giorno della settimana). Allo stesso modo, il numero di richieste che riceve per l'inferenza in tempo reale scala con il numero di utenti simultanei dell'app. Questi servizi ottengono anche picchi di traffico inaspettati a causa delle autopromozioni sui social media da parte di creatori famosi. Sebbene sia importante garantire che il sistema possa aumentare e diminuire per servire il traffico in entrata con successo e in modo frugale, è anche importante monitorare le metriche operative e avvisare per eventuali problemi operativi imprevisti per prevenire la perdita di dati e servizi per i clienti. Il monitoraggio dello stato di salute di questi servizi è semplice da usare Amazon Cloud Watch. I parametri di integrità dei servizi vitali come errori e latenza delle operazioni, nonché i parametri di utilizzo come l'utilizzo di memoria, disco e CPU sono disponibili immediatamente utilizzando CloudWatch. Il nostro team di sviluppo utilizza dashboard delle metriche e monitoraggio automatizzato per garantire che possiamo servire i nostri clienti con alta disponibilità (99.8%) e bassa latenza (meno di 200 millisecondi end-to-end per ottenere spettacoli consigliati per utente).

Misurare il risultato

Prima del suggeritore di spettacoli basato su ML descritto in questo post, un algoritmo euristico più semplice classificava gli spettacoli Amp in base agli argomenti di interesse personali di un utente che sono stati riportati automaticamente sul suo profilo. Abbiamo impostato un test A/B per misurare l'impatto del passaggio a consigli basati su ML con i dati di un utente dalle sue precedenti interazioni con l'app. Abbiamo identificato i miglioramenti nelle metriche come la durata dell'ascolto e il numero di azioni di coinvolgimento (apprezzare uno spettacolo, seguire un creatore dello spettacolo, attivare le notifiche) come indicatori di successo. I test A/B con il 50% degli utenti che hanno ricevuto consigli sugli spettacoli classificati per loro tramite il suggeritore basato su ML hanno mostrato un aumento del 3% delle metriche di coinvolgimento dei clienti e un miglioramento dello 0.5% della durata della riproduzione.

Conclusione

Con servizi appositamente creati, il team Amp è stato in grado di rilasciare l'API di raccomandazione per lo spettacolo personalizzata come descritto in questo post per la produzione in meno di 3 mesi. Il sistema si adatta bene anche ai carichi imprevedibili creati da noti presentatori di spettacoli o campagne di marketing che potrebbero generare un afflusso di utenti. La soluzione utilizza servizi gestiti per l'elaborazione, la formazione e l'hosting, il che aiuta a ridurre il tempo dedicato alla manutenzione quotidiana del sistema. Siamo inoltre in grado di monitorare tutti questi servizi gestiti tramite CloudWatch per garantire la salute continua dei sistemi in produzione.

Il test A/B della prima versione del suggeritore basato su ML di Amp rispetto a un approccio basato su regole (che ordina solo per argomenti di interesse del cliente) ha dimostrato che il suggeritore basato su ML espone i clienti a contenuti di qualità superiore da argomenti più diversi , che si traduce in un numero maggiore di follower e notifiche abilitate. Il team Amp lavora continuamente per migliorare i modelli per fornire raccomandazioni altamente pertinenti.

Per ulteriori informazioni su Feature Store, visitare Negozio di funzionalità Amazon SageMaker e controlla altri casi d'uso dei clienti in Blog di apprendimento automatico AWS.

---

Circa gli autori

Tulipano Gupta è un Solutions Architect presso Amazon Web Services. Collabora con Amazon per progettare, creare e distribuire soluzioni tecnologiche su AWS. Assiste i clienti nell'adozione delle best practice durante la distribuzione della soluzione in AWS ed è un'appassionata di analisi e ML. Nel tempo libero le piace nuotare, fare escursioni e giocare a giochi da tavolo.

David Kuo è un Solutions Architect presso Amazon Web Services. Collabora con i clienti AWS per progettare, creare e distribuire soluzioni tecnologiche su AWS. Lavora con clienti Media e Entertainment e ha interessi nelle tecnologie di apprendimento automatico. Nel suo tempo libero, si chiede cosa dovrebbe fare del suo tempo libero.

Manolya McCormick è un Sr Software Development Engineer per Amp su Amazon. Progetta e costruisce sistemi distribuiti utilizzando AWS per servire applicazioni rivolte ai clienti. Le piace leggere e cucinare nuove ricette nel tempo libero.

Jeff Christophersen è un Sr. Data Engineer per Amp su Amazon. Lavora per progettare, creare e distribuire soluzioni Big Data su AWS che generano insight fruibili. Assiste i team interni nell'adozione di soluzioni scalabili e automatizzate ed è un appassionato di Analytics e Big Data. Nel tempo libero, quando non è con gli sci lo puoi trovare sulla sua mountain bike.