Wie Amp auf Amazon Daten nutzte, um die Kundenbindung zu steigern, Teil 2: Aufbau einer Plattform für personalisierte Show-Empfehlungen mit Amazon SageMaker

Ampere ist eine neue Live-Radio-App von Amazon. Mit Amp können Sie Ihre eigene Radiosendung hosten und Songs aus dem Amazon Music-Katalog abspielen oder Sendungen einschalten und anhören, die andere Amp-Benutzer hosten. In einer Umgebung, in der Inhalte reichlich und vielfältig sind, ist es wichtig, die Benutzererfahrung an den individuellen Geschmack jedes Benutzers anzupassen, damit er leicht Sendungen finden kann, die ihm gefallen, und neue Inhalte entdecken kann, die ihm gefallen würden.

Amp verwendet maschinelles Lernen (ML), um personalisierte Empfehlungen für Live- und kommende Amp-Shows auf der Homepage der App bereitzustellen. Die Empfehlungen werden unter Verwendung eines Random-Forest-Modells unter Verwendung von Merkmalen berechnet, die die Popularität einer Sendung (z. B. die Anzahl der angehörten und ähnlichen Sendungen), die Popularität eines Erstellers (z. B. die Gesamtzahl der Wiedergaben der letzten Sendungen) und die persönlichen Affinitäten eines Benutzers darstellen zum Thema und Schöpfer einer Show. Affinitäten werden entweder implizit aus den Verhaltensdaten des Benutzers oder explizit aus Interessensthemen (wie Popmusik, Baseball oder Politik) berechnet, die in seinen Benutzerprofilen angegeben sind.

Dies ist Teil 2 einer Reihe über die Verwendung von Datenanalysen und ML für Amp und die Erstellung einer Plattform für personalisierte Show-Empfehlungslisten. Die Plattform hat seit ihrer Einführung im Mai 3 einen Anstieg der erfassten Kundenbindungsmetriken (Gefällt mir auf eine Sendung, Folgen eines Erstellers, Aktivieren von Benachrichtigungen über bevorstehende Sendungen) um 2022 % verzeichnet.

Beziehen auf Teil 1 um zu erfahren, wie Verhaltensdaten mithilfe der Daten- und Analysesysteme erfasst und verarbeitet wurden.

Lösungsüberblick

Der ML-basierte Show Recommender für Amp besteht aus fünf Hauptkomponenten, wie im folgenden Architekturdiagramm dargestellt:

1. Die mobile Amp-App.
2. Back-End-Dienste, die die Verhaltensdaten wie Likes und Follows sowie sendungsbezogene Informationen wie Statusaktualisierungen sammeln, wenn Sendungen live gehen.
3. Aufnahme von Verhaltens- und Showdaten in Echtzeit sowie Berechnung und Speicherung von Funktionen in Echtzeit (online).
4. Batch (offline)-Feature-Berechnung und -Speicherung.
5. Ein Recommender-System, das eingehende Anfragen vom App-Backend verarbeitet, um eine Liste von Shows zu erhalten. Dazu gehören Echtzeit-Rückschlüsse auf Ranglistenshows basierend auf personalisierten und nicht personalisierten Merkmalen.

Dieser Beitrag konzentriert sich auf die Teile 3, 4 und 5, um Folgendes zu erläutern:

Das folgende Diagramm zeigt die High-Level-Architektur und ihre Komponenten.

In den folgenden Abschnitten stellen wir weitere Details zu Echtzeit-Feature-Computing, Batch-Feature-Computing, Echtzeit-Inferenz, Betriebszustand und den von uns beobachteten Ergebnissen bereit.

Feature-Computing in Echtzeit

Einige Features, wie Like und Listen Count für eine Show, müssen kontinuierlich gestreamt und unverändert verwendet werden, während andere, wie die Anzahl der Hörsitzungen länger als 5 Minuten, ebenfalls in Echtzeit als Rohdaten umgewandelt werden müssen für Sitzungen wird gestreamt. Diese Arten von Merkmalen, bei denen Werte zur Inferenzzeit berechnet werden müssen, werden als bezeichnet Zeitpunkt (PIT)-Funktionen. Daten für PIT-Funktionen müssen schnell aktualisiert werden, und die neueste Version sollte mit geringer Latenz geschrieben und gelesen werden (unter 20 Millisekunden pro Benutzer für 1,000 Shows). Die Daten müssen auch dauerhaft gespeichert werden, da fehlende oder unvollständige Daten zu verschlechterten Empfehlungen und einem schlechten Kundenerlebnis führen können. Neben der Lese-/Schreiblatenz erfordern PIT-Funktionen auch eine geringe Reflexionszeit. Die Reflexionszeit ist die Zeit, die benötigt wird, damit ein Feature zum Lesen verfügbar ist, nachdem die beitragenden Ereignisse ausgegeben wurden, beispielsweise die Zeit zwischen einem Zuhörer, der eine Show mag, und dem PIT-LikeCount-Feature, das aktualisiert wird.

Quellen der Daten sind die Backend-Dienste, die die App direkt bedienen. Einige der Daten werden in Metriken umgewandelt, die dann über gesendet werden Amazon Simple Notification Service (Amazon SNS) an nachgelagerte Listener wie die ML-Funktionstransformationspipeline. Eine In-Memory-Datenbank wie MemoryDB ist ein idealer Dienst für dauerhafte Speicherung und ultraschnelle Leistung bei hohen Volumen. Lambda ist die Compute-Komponente, die Features transformiert und in MemoryDB schreibt. Der App-Traffic folgt je nach Uhrzeit und Tag täglichen und wöchentlichen Mustern von Spitzen und Einbrüchen. Lambda ermöglicht die automatische Skalierung auf das eingehende Ereignisvolumen. Aufgrund der Unabhängigkeit jeder einzelnen Metriktransformation eignet sich Lambda, das selbst ein zustandsloser Dienst ist, gut für dieses Problem. Putten Amazon Simple Queue-Dienst (Amazon SQS) zwischen Amazon SNS und Lambda verhindert nicht nur den Verlust von Nachrichten, sondern fungiert auch als Puffer für unerwartete Datenverkehrsspitzen, für die vorkonfigurierte Lambda-Parallelitätslimits möglicherweise nicht ausreichen.

Batch-Feature-Computing

Funktionen, die historische Verhaltensdaten verwenden, um den sich ständig weiterentwickelnden Geschmack eines Benutzers darzustellen, sind komplexer zu berechnen und können nicht in Echtzeit berechnet werden. Diese Merkmale werden von einem Batch-Prozess berechnet, der von Zeit zu Zeit ausgeführt wird, beispielsweise einmal täglich. Daten für Batch-Features sollten schnelle Abfragen zum Filtern und Sammeln von Daten unterstützen und können sich über lange Zeiträume erstrecken, sodass sie ein größeres Volumen haben. Da Batch-Features auch abgerufen und als Eingaben für Echtzeit-Inferenz gesendet werden, sollten sie dennoch mit geringer Latenz gelesen werden.

Das Sammeln von Rohdaten für die Batch-Feature-Berechnung hat nicht die Bedingungszeit von weniger als einer Minute, die PIT-Features haben, was es möglich macht, die Ereignisse länger zu puffern und Metriken im Batch umzuwandeln. Diese Lösung nutzte Kinesis Data Firehose, einen verwalteten Dienst zum schnellen Einlesen von Streaming-Daten in mehrere Ziele, darunter Amazon Simple Storage-Service (Amazon S3) für persistente Metriken im S3 Data Lake, die in Offline-Berechnungen verwendet werden sollen. Kinesis Data Firehose bietet einen Ereignispuffer und eine Lambda-Integration, um diese Metriken einfach zu sammeln, in Stapeln umzuwandeln und in Amazon S3 zu speichern, damit sie später von der Batch-Feature-Berechnung verwendet werden können. Batch-Feature-Berechnungen haben nicht die gleichen Lese-/Schreibanforderungen mit geringer Latenz wie PIT-Features, was Amazon S3 zur besseren Wahl macht, da es einen kostengünstigen, dauerhaften Speicher zum Speichern dieser großen Mengen an Geschäftsmetriken bietet.

Unser anfängliches ML-Modell verwendet 21 Stapelfunktionen, die täglich anhand von Daten berechnet werden, die in den letzten 2 Monaten erfasst wurden. Diese Daten umfassen sowohl den Wiedergabe- als auch den App-Interaktionsverlauf pro Benutzer und wachsen mit der Anzahl der Benutzer und der Häufigkeit der App-Nutzung. Feature-Engineering in dieser Größenordnung erfordert einen automatisierten Prozess, um die erforderlichen Eingabedaten abzurufen, sie parallel zu verarbeiten und das Ergebnis in einen persistenten Speicher zu exportieren. Die Verarbeitungsinfrastruktur wird nur für die Dauer der Berechnungen benötigt. SageMaker-Verarbeitung bietet vorgefertigte Docker-Images, die Apache Spark und andere Abhängigkeiten enthalten, die für die Ausführung verteilter Datenverarbeitungsaufträge in großem Umfang erforderlich sind. Die zugrunde liegende Infrastruktur für einen Verarbeitungsauftrag wird vollständig von SageMaker verwaltet. Clusterressourcen werden für die Dauer Ihres Auftrags bereitgestellt und nach Abschluss eines Auftrags bereinigt.

Jeder Schritt im Batch-Prozess – Datenerfassung, Feature-Engineering, Feature-Persistenz – ist Teil eines Workflows, der Fehlerbehandlung, Wiederholungen und Zustandsübergänge dazwischen erfordert. Mit AWS Step-Funktionen, können Sie eine Zustandsmaschine erstellen und Ihren Workflow in mehrere Schritte der Vor- und Nachverarbeitung sowie einen Schritt zum Persistieren der Funktionen im SageMaker Feature Store oder der anderen Daten in Amazon S3 aufteilen. Eine Zustandsmaschine in Step Functions kann über getriggert werden Amazon EventBridge um Batch-Computing zu automatisieren, sodass es nach einem festgelegten Zeitplan ausgeführt wird, z. B. einmal täglich um 10:00 Uhr UTC.

Nachdem die Features berechnet wurden, müssen sie versioniert und gespeichert werden, damit sie während der Inferenz sowie beim Neutraining des Modells gelesen werden können. Anstatt Ihren eigenen Funktionsspeicher- und Verwaltungsdienst zu erstellen, können Sie SageMaker Feature Store verwenden. Feature Store ist ein vollständig verwaltetes, speziell entwickeltes Repository zum Speichern, Freigeben und Verwalten von Funktionen für ML-Modelle. Es speichert den Verlauf von ML-Funktionen im Offline-Shop (Amazon S3) und stellt auch APIs für einen Online-Shop bereit, um das Lesen der neuesten Funktionen mit geringer Latenz zu ermöglichen. Der Offline-Shop kann die historischen Daten für weiteres Modelltraining und Experimente bereitstellen, und der Online-Shop kann von Ihren kundenorientierten APIs aufgerufen werden, um Funktionen für Echtzeit-Inferenzen zu erhalten. Während wir unsere Dienste weiterentwickeln, um personalisiertere Inhalte bereitzustellen, planen wir, zusätzliche ML-Modelle zu trainieren und mithilfe des Feature Store Funktionen zwischen diesen Modellen zu suchen, zu entdecken und wiederzuverwenden.

Echtzeit-Inferenz

Echtzeit-Inferenz erfordert normalerweise das Hosten von ML-Modellen hinter Endpunkten. Sie könnten dies mithilfe von Webservern oder Containern tun, aber dies erfordert ML-Engineering-Aufwand und eine zu verwaltende und zu wartende Infrastruktur. SageMaker vereinfacht die Bereitstellung von ML-Modellen auf Echtzeit-Endpunkten. Mit SageMaker können Sie ML-Modelle trainieren, hochladen und hosten, indem Sie SageMaker-Endpunkte erstellen und konfigurieren. Echtzeit-Inferenz erfüllt die Anforderungen an niedrige Latenzzeiten für das Ranking von Shows, während sie auf der Amp-Homepage durchsucht werden.

Zusätzlich zum verwalteten Hosting bietet SageMaker verwaltete Endpunktskalierung. Mit der SageMaker-Inferenz können Sie eine Auto Scaling-Richtlinie mit minimaler und maximaler Instanzanzahl und einer Zielauslastung definieren, um die Skalierung auszulösen. Auf diese Weise können Sie bei sich ändernder Nachfrage einfach ein- oder ausskalieren.

Betriebsgesundheit

Die Anzahl der Ereignisse, die dieses System für die Echtzeit-Feature-Berechnung verarbeitet, ändert sich entsprechend dem natürlichen Muster der App-Nutzung (höherer oder niedrigerer Datenverkehr je nach Tageszeit oder Wochentag). Ebenso skaliert die Anzahl der Anfragen, die es für Echtzeit-Inferenz erhält, mit der Anzahl der gleichzeitigen App-Benutzer. Diese Dienste erhalten auch unerwartete Traffic-Spitzen aufgrund von Eigenwerbung in sozialen Medien durch beliebte Ersteller. Obwohl es wichtig ist sicherzustellen, dass das System nach oben und unten skaliert werden kann, um den eingehenden Datenverkehr erfolgreich und sparsam zu bedienen, ist es auch wichtig, Betriebsmetriken zu überwachen und bei unerwarteten Betriebsproblemen zu warnen, um Daten- und Serviceverluste für Kunden zu verhindern. Die Überwachung des Zustands dieser Dienste ist unkompliziert Amazon CloudWatch. Wichtige Dienstzustandsmetriken wie Fehler und Latenz von Vorgängen sowie Nutzungsmetriken wie Speicher-, Festplatten- und CPU-Nutzung sind mit CloudWatch sofort einsatzbereit. Unser Entwicklungsteam verwendet Metrik-Dashboards und automatisierte Überwachung, um sicherzustellen, dass wir unsere Kunden mit hoher Verfügbarkeit (99.8 %) und geringer Latenz (weniger als 200 Millisekunden durchgehend, um empfohlene Shows pro Benutzer zu erhalten) bedienen können.

Ergebnis messen

Vor dem in diesem Beitrag beschriebenen ML-basierten Show-Recommender hat ein einfacherer heuristischer Algorithmus Amp-Shows basierend auf den persönlichen Interessensthemen eines Benutzers eingestuft, die in seinem Profil selbst gemeldet wurden. Wir haben einen A/B-Test eingerichtet, um die Auswirkungen des Wechsels zu ML-basierten Empfehlungsdiensten mit den Daten eines Benutzers aus seinen früheren App-Interaktionen zu messen. Wir haben Verbesserungen bei Metriken wie Hördauer und Anzahl der Interaktionsaktionen (eine Sendung mit „Gefällt mir“ markieren, einem Ersteller einer Sendung folgen, Benachrichtigungen aktivieren) als Erfolgsindikatoren identifiziert. A/B-Tests mit 50 % der Benutzer, die über den ML-basierten Recommender für sie eingestufte Showempfehlungen erhielten, haben eine Steigerung der Kundenbindungsmetriken um 3 % und eine Verbesserung der Wiedergabedauer um 0.5 % gezeigt.

Zusammenfassung

Mit speziell entwickelten Diensten war das Amp-Team in der Lage, die in diesem Beitrag beschriebene personalisierte Sendungsempfehlungs-API in weniger als 3 Monaten für die Produktion freizugeben. Das System skaliert auch gut für die unvorhersehbaren Lasten bekannter Show-Moderatoren oder Marketingkampagnen, die einen Zustrom von Benutzern generieren könnten. Die Lösung verwendet Managed Services für die Verarbeitung, Schulung und das Hosting, was dazu beiträgt, den Zeitaufwand für die tägliche Wartung des Systems zu reduzieren. Wir sind auch in der Lage, alle diese Managed Services über CloudWatch zu überwachen, um den kontinuierlichen Zustand der Systeme in der Produktion sicherzustellen.

A/B-Tests der ersten Version des ML-basierten Recommenders von Amp im Vergleich zu einem regelbasierten Ansatz (der Shows nur nach Kundeninteressen sortiert) haben gezeigt, dass der ML-basierte Recommender Kunden höherwertigen Inhalten aus vielfältigeren Themenbereichen aussetzt , was zu einer höheren Anzahl von Followern und aktivierten Benachrichtigungen führt. Das Amp-Team arbeitet kontinuierlich an der Verbesserung der Modelle, um hochrelevante Empfehlungen zu geben.

Weitere Informationen zum Feature Store finden Sie unter Amazon SageMaker Feature Store und sehen Sie sich andere Kundenanwendungsfälle in der an AWS-Blog für maschinelles Lernen.

---

Über die Autoren

Tulpe Gupta ist Lösungsarchitekt bei Amazon Web Services. Sie arbeitet mit Amazon zusammen, um Technologielösungen auf AWS zu entwerfen, zu erstellen und bereitzustellen. Sie unterstützt Kunden bei der Übernahme von Best Practices bei der Bereitstellung von Lösungen in AWS und ist eine begeisterte Analytikerin und ML-Expertin. In ihrer Freizeit geht sie gerne schwimmen, wandert und spielt Gesellschaftsspiele.

David Kuo ist Lösungsarchitekt bei Amazon Web Services. Er arbeitet mit AWS-Kunden zusammen, um Technologielösungen auf AWS zu entwerfen, zu erstellen und bereitzustellen. Er arbeitet mit Kunden aus der Medien- und Unterhaltungsbranche zusammen und interessiert sich für maschinelle Lerntechnologien. In seiner Freizeit fragt er sich, was er mit seiner Freizeit anfangen soll.

Manolya McCormick ist Senior Software Development Engineer für Amp bei Amazon. Sie entwirft und baut verteilte Systeme mit AWS, um kundenorientierte Anwendungen zu bedienen. In ihrer Freizeit liest und kocht sie gerne neue Rezepte.

Jeff Christophersen ist Senior Data Engineer für Amp bei Amazon. Er arbeitet an der Entwicklung, Erstellung und Bereitstellung von Big-Data-Lösungen auf AWS, die umsetzbare Erkenntnisse liefern. Er unterstützt interne Teams bei der Einführung skalierbarer und automatisierter Lösungen und ist ein begeisterter Analytiker und Big Data-Enthusiast. In seiner Freizeit, wenn er nicht auf den Skiern steht, findet man ihn auf seinem Mountainbike.