Comment Amp sur Amazon a utilisé les données pour accroître l'engagement des clients, Partie 2 : Création d'une plateforme de recommandation d'émissions personnalisée à l'aide d'Amazon SageMaker

Ampli est une nouvelle application de radio en direct d'Amazon. Avec Amp, vous pouvez héberger votre propre émission de radio et écouter des chansons du catalogue Amazon Music, ou syntoniser et écouter les émissions que d'autres utilisateurs d'Amp hébergent. Dans un environnement où le contenu est abondant et diversifié, il est important d'adapter l'expérience utilisateur aux goûts individuels de chaque utilisateur, afin qu'il puisse facilement trouver les émissions qu'il aime et découvrir de nouveaux contenus qu'il aimerait.

Amp utilise l'apprentissage automatique (ML) pour fournir des recommandations personnalisées pour les émissions Amp en direct et à venir sur la page d'accueil de l'application. Les recommandations sont calculées à l'aide d'un modèle de forêt aléatoire utilisant des caractéristiques représentant la popularité d'une émission (comme le nombre d'écoutes et de likes), la popularité d'un créateur (comme le nombre total de fois où les émissions récentes ont été diffusées) et les affinités personnelles d'un utilisateur. au sujet et au créateur d'une émission. Les affinités sont calculées soit implicitement à partir des données comportementales de l'utilisateur, soit explicitement à partir de sujets d'intérêt (tels que la musique pop, le baseball ou la politique) tels que fournis dans leurs profils d'utilisateurs.

Il s'agit de la partie 2 d'une série sur l'utilisation de l'analyse de données et du ML pour Amp et la création d'une plate-forme personnalisée de liste de recommandations d'émissions. La plate-forme a montré une augmentation de 3 % des mesures d'engagement client suivies (aimer une émission, suivre un créateur, activer les notifications d'émissions à venir) depuis son lancement en mai 2022.

Reportez-vous à Partie 1 pour savoir comment les données comportementales ont été collectées et traitées à l'aide des systèmes de données et d'analyse.

Vue d'ensemble de la solution

Le programme de recommandation d'émissions basé sur ML pour Amp comporte cinq composants principaux, comme illustré dans le schéma d'architecture suivant :

1. L'application mobile Amp.
2. Services back-end qui rassemblent les données comportementales, telles que les likes et les suivis, ainsi que les informations de diffusion relatives aux émissions telles que les mises à jour de statut lorsque les émissions sont mises en ligne.
3. Ingestion en temps réel de données comportementales et d'émissions, et calcul et stockage de fonctionnalités en temps réel (en ligne).
4. Le traitement par lots (hors ligne) comprend le calcul et le stockage.
5. Un système de recommandation qui gère les demandes entrantes du backend de l'application pour obtenir une liste d'émissions. Cela inclut l'inférence en temps réel pour classer les émissions en fonction de caractéristiques personnalisées et non personnalisées.

Cet article se concentre sur les parties 3, 4 et 5 dans le but de détailler les éléments suivants :

Le schéma suivant montre l'architecture de haut niveau et ses composants.

Dans les sections suivantes, nous fournissons plus de détails sur le calcul des caractéristiques en temps réel, le calcul des caractéristiques par lots, l'inférence en temps réel, la santé opérationnelle et les résultats que nous avons observés.

Calcul des fonctionnalités en temps réel

Certaines fonctionnalités, telles que les likes et le nombre d'écoutes pour une émission, doivent être diffusées en continu et utilisées telles quelles, tandis que d'autres, telles que le nombre de sessions d'écoute de plus de 5 minutes, doivent également être transformées en temps réel sous forme de données brutes. pour les sessions est diffusé en continu. Ces types de caractéristiques où les valeurs doivent être calculées au moment de l'inférence sont appelés point dans le temps (PIT). Les données des fonctionnalités PIT doivent être mises à jour rapidement, et la dernière version doit être écrite et lue avec une faible latence (moins de 20 millisecondes par utilisateur pour 1,000 XNUMX émissions). Les données doivent également se trouver dans un stockage durable, car des données manquantes ou partielles peuvent entraîner une détérioration des recommandations et une mauvaise expérience client. En plus de la latence de lecture/écriture, les fonctionnalités PIT nécessitent également un faible temps de réflexion. Le temps de réflexion est le temps qu'il faut pour qu'une fonctionnalité soit disponible en lecture après l'émission des événements contributeurs, par exemple, le temps entre un auditeur qui aime une émission et la fonctionnalité PIT LikeCount mise à jour.

Les sources des données sont les services principaux desservant directement l'application. Certaines données sont transformées en métriques qui sont ensuite diffusées via Service de notification simple d'Amazon (Amazon SNS) aux écouteurs en aval tels que le pipeline de transformation de fonctionnalités ML. Une base de données en mémoire telle que MemoryDB est un service idéal pour un stockage durable et des performances ultra-rapides à des volumes élevés. Le composant de calcul qui transforme et écrit des fonctionnalités dans MemoryDB est Lambda. Le trafic des applications suit des schémas quotidiens et hebdomadaires de pics et de creux en fonction de l'heure et du jour. Lambda permet une mise à l'échelle automatique en fonction du volume d'événements entrants. La nature indépendante de chaque transformation de métrique individuelle fait également de Lambda, qui est un service sans état en soi, un bon choix pour ce problème. En mettant Service Amazon Simple Queue (Amazon SQS) entre Amazon SNS et Lambda empêche non seulement la perte de messages, mais agit également comme un tampon pour les pics de trafic inattendus que les limites de simultanéité préconfigurées de Lambda peuvent ne pas être suffisantes pour servir.

Calcul des caractéristiques par lots

Les fonctionnalités qui utilisent des données comportementales historiques pour représenter les goûts en constante évolution d'un utilisateur sont plus complexes à calculer et ne peuvent pas être calculées en temps réel. Ces caractéristiques sont calculées par un traitement par lots qui s'exécute de temps en temps, par exemple une fois par jour. Les données pour les fonctionnalités par lots doivent prendre en charge les requêtes rapides pour le filtrage et l'agrégation des données, et peuvent couvrir de longues périodes de temps, elles seront donc plus volumineuses. Étant donné que les entités par lots sont également récupérées et envoyées en tant qu'entrées pour l'inférence en temps réel, elles doivent toujours être lues avec une faible latence.

La collecte de données brutes pour le calcul d'entités par lots n'a pas le temps de réflexion inférieur à la minute requis par les fonctionnalités PIT, ce qui permet de mettre en mémoire tampon les événements plus longtemps et de transformer les métriques par lots. Cette solution utilisait Kinesis Data Firehose, un service géré pour ingérer rapidement des données de streaming vers plusieurs destinations, y compris Service de stockage simple Amazon (Amazon S3) pour conserver les métriques dans le lac de données S3 à utiliser dans les calculs hors ligne. Kinesis Data Firehose fournit un tampon d'événements et une intégration Lambda pour collecter, transformer par lots et conserver facilement ces métriques sur Amazon S3 afin qu'elles soient utilisées ultérieurement par le calcul des fonctionnalités par lots. Les calculs de fonctionnalités par lots n'ont pas les mêmes exigences de lecture/écriture à faible latence que les fonctionnalités PIT, ce qui fait d'Amazon S3 le meilleur choix car il fournit un stockage durable et peu coûteux pour stocker ces grands volumes de métriques commerciales.

Notre modèle ML initial utilise 21 fonctionnalités par lots calculées quotidiennement à l'aide de données capturées au cours des 2 derniers mois. Ces données incluent à la fois l'historique de lecture et d'engagement de l'application par utilisateur, et augmentent avec le nombre d'utilisateurs et la fréquence d'utilisation de l'application. L'ingénierie des fonctionnalités à cette échelle nécessite un processus automatisé pour extraire les données d'entrée requises, les traiter en parallèle et exporter le résultat vers un stockage persistant. L'infrastructure de traitement n'est nécessaire que pendant la durée des calculs. Traitement SageMaker fournit des images Docker prédéfinies qui incluent Apache Spark et d'autres dépendances nécessaires pour exécuter des tâches de traitement de données distribuées à grande échelle. L'infrastructure sous-jacente d'une tâche de traitement est entièrement gérée par SageMaker. Les ressources de cluster sont provisionnées pour la durée de votre tâche et nettoyées lorsqu'une tâche est terminée.

Chaque étape du processus par lots (collecte de données, ingénierie des fonctionnalités, persistance des fonctionnalités) fait partie d'un flux de travail qui nécessite une gestion des erreurs, des tentatives et des transitions d'état entre les deux. Avec Fonctions d'étape AWS, vous pouvez créer une machine d'état et diviser votre flux de travail en plusieurs étapes de prétraitement et de post-traitement, ainsi qu'une étape pour conserver les fonctionnalités dans SageMaker Feature Store ou les autres données dans Amazon S3. Une machine d'état dans Step Functions peut être déclenchée via Amazon Event Bridge pour automatiser le calcul par lots pour qu'il s'exécute selon un calendrier défini, par exemple une fois par jour à 10h00 UTC.

Une fois les caractéristiques calculées, elles doivent être versionnées et stockées pour être lues pendant l'inférence ainsi que le recyclage du modèle. Plutôt que de créer votre propre service de stockage et de gestion de fonctionnalités, vous pouvez utiliser SageMaker Feature Store. Feature Store est un référentiel entièrement géré et spécialement conçu pour stocker, partager et gérer les fonctionnalités des modèles ML. Il stocke l'historique des fonctionnalités ML dans le magasin hors ligne (Amazon S3) et fournit également des API à un magasin en ligne pour permettre des lectures à faible latence des fonctionnalités les plus récentes. La boutique hors ligne peut servir les données historiques pour une formation et une expérimentation supplémentaires du modèle, et la boutique en ligne peut être appelée par vos API orientées client pour obtenir des fonctionnalités d'inférence en temps réel. Au fur et à mesure que nous évoluons nos services pour fournir un contenu plus personnalisé, nous prévoyons de former des modèles ML supplémentaires et, avec l'aide de Feature Store, de rechercher, découvrir et réutiliser des fonctionnalités parmi ces modèles.

Inférence en temps réel

L'inférence en temps réel nécessite généralement l'hébergement de modèles ML derrière les points de terminaison. Vous pouvez le faire en utilisant des serveurs Web ou des conteneurs, mais cela nécessite des efforts d'ingénierie ML et une infrastructure à gérer et à entretenir. SageMaker facilite le déploiement de modèles ML sur des points de terminaison en temps réel. SageMaker vous permet de former et de télécharger des modèles ML et de les héberger en créant et en configurant des points de terminaison SageMaker. L'inférence en temps réel répond aux exigences de faible latence pour les émissions de classement lorsqu'elles sont parcourues sur la page d'accueil d'Amp.

En plus de l'hébergement géré, SageMaker fournit une mise à l'échelle des terminaux gérés. L'inférence SageMaker vous permet de définir une stratégie de mise à l'échelle automatique avec un nombre d'instances minimum et maximum et une utilisation cible pour déclencher la mise à l'échelle. De cette façon, vous pouvez facilement évoluer en fonction de l'évolution de la demande.

Santé opérationnelle

Le nombre d'événements que ce système gère pour le calcul des fonctionnalités en temps réel change en fonction du modèle naturel d'utilisation de l'application (trafic plus ou moins élevé en fonction de l'heure de la journée ou du jour de la semaine). De même, le nombre de demandes qu'il reçoit pour l'inférence en temps réel évolue avec le nombre d'utilisateurs simultanés de l'application. Ces services connaissent également des pics de trafic inattendus en raison des auto-promotions sur les réseaux sociaux par des créateurs populaires. Bien qu'il soit important de s'assurer que le système peut évoluer vers le haut et vers le bas pour servir le trafic entrant avec succès et avec parcimonie, il est également important de surveiller les métriques opérationnelles et d'alerter en cas de problème opérationnel inattendu pour éviter la perte de données et de service aux clients. La surveillance de la santé de ces services est simple à l'aide de Amazon Cloud Watch. Les métriques de santé vitales du service telles que les pannes et la latence des opérations ainsi que les métriques d'utilisation telles que l'utilisation de la mémoire, du disque et du processeur sont disponibles prêtes à l'emploi à l'aide de CloudWatch. Notre équipe de développement utilise des tableaux de bord de métriques et une surveillance automatisée pour nous assurer que nous pouvons servir nos clients avec une haute disponibilité (99.8 %) et une faible latence (moins de 200 millisecondes de bout en bout pour obtenir les émissions recommandées par utilisateur).

Mesurer le résultat

Avant le programme de recommandation d'émissions basé sur ML décrit dans cet article, un algorithme heuristique plus simple classait les émissions Amp en fonction des sujets d'intérêt personnels d'un utilisateur qui sont auto-déclarés sur son profil. Nous avons mis en place un test A/B pour mesurer l'impact du passage aux recommandations basées sur ML avec les données d'un utilisateur issues de ses interactions passées avec l'application. Nous avons identifié des améliorations dans des mesures telles que la durée d'écoute et le nombre d'actions d'engagement (aimer une émission, suivre un créateur d'émission, activer les notifications) comme indicateurs de succès. Les tests A/B avec 50 % des utilisateurs recevant des recommandations d'émissions classées pour eux via le système de recommandation basé sur ML ont montré une augmentation de 3 % des mesures d'engagement client et une amélioration de 0.5 % de la durée de lecture.

Conclusion

Grâce à des services spécialement conçus, l'équipe Amp a pu mettre en production l'API de recommandation d'émission personnalisée décrite dans cet article en moins de 3 mois. Le système s'adapte également bien aux charges imprévisibles créées par des animateurs d'émissions ou des campagnes marketing bien connus qui pourraient générer un afflux d'utilisateurs. La solution utilise des services gérés pour le traitement, la formation et l'hébergement, ce qui permet de réduire le temps consacré à la maintenance quotidienne du système. Nous sommes également en mesure de surveiller tous ces services gérés via CloudWatch pour garantir la santé continue des systèmes en production.

Le test A/B de la première version du système de recommandation basé sur ML d'Amp par rapport à une approche basée sur des règles (qui trie les émissions uniquement en fonction des sujets d'intérêt du client) a montré que le système de recommandation basé sur ML expose les clients à un contenu de meilleure qualité provenant de sujets plus divers. , ce qui se traduit par un nombre plus élevé de suivis et de notifications activées. L'équipe Amp travaille en permanence à l'amélioration des modèles pour fournir des recommandations très pertinentes.

Pour plus d'informations sur Feature Store, visitez Magasin de fonctionnalités Amazon SageMaker et découvrez d'autres cas d'utilisation client dans le Blog sur l'apprentissage automatique AWS.

---

À propos des auteurs

Tulipe Gupta est architecte de solutions chez Amazon Web Services. Elle travaille avec Amazon pour concevoir, créer et déployer des solutions technologiques sur AWS. Elle aide les clients à adopter les meilleures pratiques lors du déploiement de la solution dans AWS, et est une passionnée d'analyse et de ML. Dans ses temps libres, elle aime nager, faire de la randonnée et jouer à des jeux de société.

David Kuo est architecte de solutions chez Amazon Web Services. Il travaille avec les clients d'AWS pour concevoir, créer et déployer des solutions technologiques sur AWS. Il travaille avec des clients des médias et du divertissement et s'intéresse aux technologies d'apprentissage automatique. Dans ses temps libres, il se demande ce qu'il devrait faire de son temps libre.

Manolya McCormick est un ingénieur en développement logiciel senior pour Amp sur Amazon. Elle conçoit et construit des systèmes distribués à l'aide d'AWS pour servir les applications destinées aux clients. Elle aime lire et cuisiner de nouvelles recettes pendant son temps libre.

Jeff Christopherson est un ingénieur principal des données pour Amp sur Amazon. Il travaille à la conception, à la construction et au déploiement de solutions Big Data sur AWS qui génèrent des informations exploitables. Il accompagne les équipes internes dans l'adoption de solutions évolutives et automatisées, et est un passionné d'Analytics et de Big Data. Dans ses temps libres, lorsqu'il n'est pas sur une paire de skis, vous pouvez le trouver sur son VTT.