La recommandation de A à Z [3/3]: créer et exposer un modèle AWS Personalize
Vous l’avez sûrement deviné, ce dernier article va couvrir l’ingestion des données précédemment préparées dans AWS Personalize ainsi que de l’entraînement d’une solution personnalisée de recommandation. Pour illustrer nos propos nous allons utiliser les interactions entre nos utilisateurs et des vidéos YouTube, directement extraites de notre application d’exemple.
Comment fonctionne la recommandation ?
La recommandation, et plus précisément un système de recommandation, à pour objectif de recommander à des utilisateurs des choses qu’il sont suceptibles d’acheter, d’aimer, …
Pour y parvenir, un système de recommandation nécessite beaucoup de données, qui se composent de profils utilisateurs, d’informations sur le contenu et surtout d’interactions entre ces deux entités. Pour en savoir plus sur le sujet, c’est par ici.
Dans notre cas, nous allons nous concentrer sur le fonctionnement de la recommandation avec AWS Personalize.
AWS Personalize permet d’entraîner des solutions de recommandation sur vos propres données. Pour ce faire, vous pouvez choisir entre différentes recipes, qui sont tout simplement des algorithmes répondant à des cas d’utilisation spécifiques de ces 3 catégories :
- Items similaires : trouver les livres les plus similaires à celui choisi ;
- Classement personnalisé : personnaliser l’ordre des résultats d’une recherche ;
- Personnalisation utilisateur : recommander le prochain article que l’utilisateur est le plus suceptible d’acheter par exemple.
Par exemple, votre service a peut-être besoin d’une fonctionnalité permettant de connaître le prochain article qu’un utilisateur est susceptible d’acheter. Et pour une autre fonctionnalité, vous voulez montrer à l’utilisateur des objets similaires à celui qu’il a consulté récemment. Les recipes de AWS Personalize sont là pour optimiser vos recommandations selon ces cas d’utilisation.
Créer un groupe jeux de données
Un groupe de jeux de données (dataset group) est l’entité AWS qui contient vos jeux de données d’interactions entre vos utilisateurs et vos contenus. Il s’agit de la première étape pour construire et entraîner une solution avec AWS Personalize.
Seul un nom est requis pour la création d’un dataset group, le vrai travail vient juste après. Pour l’exemple, ici nous voulons entraîner AWS Personalize à faire des recommandations basées sur les interactions de nos utilisateurs avec des vidéos YouTube. On crée donc un dataset group comme ci-dessous :
De retour sur l’interface principale des dataset groups, on observe que la création a bien fonctionné.
Pour continuer, regardons ce qu’il faut faire ensuite en cliquant sur notre dataset group faîchement créé, appelé user-videos.
Ce tableau de bord montre les différentes étapes à suivre. Dans notre cas, nous venons tout juste de créer un dataset group vide, commençons donc par importer nos jeux de données.
Chargement de vos jeux de données
Comme illustré ci-dessus, 3 jeux de données (datasets) sont requis par AWS Personalize pour créer une solution. Chaque dataset correspond à une des 3 entités impliquées dans une interaction utilisateur-contenu, qui sont :
- Utilisateur
- Contenu
- L’interaction elle-même
Pour chacun d’entre eux, il vous faut un seul fichier CSV dans un bucket S3, qui peut par exemple être la sortie de vos tâches d’ETL dans AWS Glue.
La première étape pour importer un dataset est de créer un Schéma. Il s’agit simplement de la représentation en JSON de vos données sous forme d’une liste de champs qui doit exactement correspondre au noms et types de donnée des colonnes de votre fichier CSV. AWS Personalize utilise ce schémapour connaître la structure de vos données et ainsi les lire.
Vos 3 schémas(pour vos 3 datasets) doivent suivre quelques règles supplémentaires, en plus de correspondre à la structure de vos CSV.
L’exemple ci-dessus est un schéma utilisateur très simple donné par AWS.
Un schéma utilisateur requière un champ USER_ID, avec ce nom exact. Si vous construiseez vos jeux de données avec Glue, il vous suffit de renommer ainsi la colonne qui identifie vos utilisateurs.
AWS Personalize requière également un champ de métadonnée pour un schéma utilisateur, ce qui se résume à une valeur numérique ou un champ catégorique sous forme de chaîne de caractère. Dans l’exemple ci-dessus, cela correspond à l’âge et au genre. Il est possible d’utiliser entre 1 et 5 cahmps de métadonnées pour votre schéma utilisateur. Ces champs sont requis principalement parce qu’ils permettent aux algorithmes de recommandation de calculer la similarité (distance) entre deux profils utilisateurs. En effet, il est impossible, ou du moins cela n’a pas de sens, de comparer 2 utilisateurs uniquement en se bassant sur leurs identifiants uniques…
De manière similaire au schéma utilisateur, le schéma d’item requière un identifiant unique, appelé ITEM_ID cette fois-ci. Un champ de métadonnée est également requis, mais pour les items il est possible d’utiliser jusqu’à 50 champs de métadonnée. De même que pour les utilisateurs, certaines solutions de recommandations se basent sur les similarités entre items.
Comme vous pouvez le voir dans l’exemple ci-dessus, il est possible de spécifier la nullité d’un champ en utilisant une liste pour le type d’un champ.
Les datasets d’interactions stockent les interactions entre les utilisateurs et les items. C’est pourquoi le schéma d’interactions requière les champs USER_ID et ITEM_ID. De plus, un champ TIMESTAMP de type “long” est également requis pour une interaction. Ce champ est indispensable aux algorithmes de AWS Personalize qui basent leurs recommandations sur l’historique des interactions d’un utilisateur.
C’est dans ce schéma (et dnas le dataset correspondant) qu’il vous faut stocker les informations qui concernent l’appareil de l’utilisateur (type, OS, …) ainsi que le type d’évènement (un clic, une vue ou un like par exemple).
Pour en savoir plus sur les schémas de AWS Personalize, c’est par ici.
Remarque : Gardez en tête qu’une fois qu’un schéma est créé, la console AWS n’offre ni la possibilité de le modifier, ni celle de le supprimer. Supprimer un dataset ne supprimera pas le schéma associé étant donné que les schémas sont réutilisables à l’infini pour d’autres datasets.Typiquement, vous allez avoir besoin d’un dataset d’utilisateurs pour chacun de vos dataset groups, mais souvent le schéma utilisateur sera le même.
Une fois que vous avez créé votre schéma, cliquez sur le bouton “Suivant”. Cela va lancer une vérification qui s’assure que votre schéma suit bien les prérequis expliqués ci-dessus. Ensuite vous devriez arriver sur la page suivante :
Vous pouvez tout d’abord choisir un nom pour la tâche que AWS Personalize va créer pour importer vos données. Juste après, il vous faut choisir un rôle IAM qui autorise le service à accéder à vos données, c’est-à-dire le bucket contenant vos fichiers CSV.
Ensuite, il faut donner certaines permissions à AWS Personalize pour qu’il puisse faire ce dont il a besoin de vos données stockées dans S3. Cela se résume à créer un role d’accès, par exemple AmazonPersonalizeAccessRole, avec la policy suivante y étant attachée :
Il faut également attacher la policy suivante à votre bucket S3 :
De cette manière, AWS Personalize devrait être capable d’accéder sans problème à vos données lors de l’import de votre dataset. Vous pouvez trouver la documentation détaillée ici.
Pour finir, vous pouvez spécifier le chemin vers votre fichier CSV. Cliquer sur le bouton “Terminer” va lancer une vérification qui s’assure que votre schéma correspond bien à la structure de votre fichier CSV. Si vous en êtes à vos débuts avec AWS Personalize, cette étape peut vous demander plusieurs essais avant d’importer vos données avec succès. Soyez très attentifs aux noms de vos champs ainsi qu’à leur type. Cette étape peut se révéler un peu fastidieuse à cause de l’impossibilité de modifier un schéma. De plus, vous ne plus changer le schéma d’un dataset une fois que vous avez atteint la seconde page des étapes d’import. Cela signifie qu’à chaque échec d’import de vos données dû à une erreur dans le schéma il vous faudra supprimer le dataset correspondant dans votre dataset group (ce qui prend d’ailleurs quelques secondes à être pris en compte) et en créer un nouveau.
Losque vos datasets sont en cours d’import dans votre dataset group, vous pouvez prendre une pause café, c’est en général un peu long.
Vous pouvez lancer au maximum 5 imports de dataset en parallèle, mais cela prend quand même au moins 10 minutes à un dataset pour être importé avec succès.
Vous devriez finalement voir quelque chose d’identique pour vos 3 datasets de votre dataset group :
Vous êtes maintenant prêts à entraîner une solution de recommandation avec AWS Personalize !
Créer une solution
Notre dataset étant prêt, nous sommes maintenant capable d’entraîner un modèle personnalisé pour faire des recommandations.
Noter que vous pouvez commencer à créer des solutions sans avoir vos 3 datasets prêts (c’est une alternative à votre pause café précédente).
Pour créer une solution, il vous faut tout d’abord choisir un nom pour celle-ci, puis choisir une recipe. AWS Personalize offre une liste de recipes, qui sont simplement des algorithmes conçus pour des cas d’utilisations spécifiques.
Par exemple, vous pouvez être intéressés par la recommandation d’articles à des utilisateurs basée sur leurs goûts, mais aussi par la recommandation d’articles similaires à un article donné (comme lors d’un achat sur Amazon.com).
En conséquence, chaque recipe requière des choses différentes en entrée pour vous donner des recommandations. Vous trouverez la documentation des recipes ici.Dans notre cas, nous voulons recommander à un utilisateur des vidéos YouTube qui pourraient l’intéresser, suite à ses interactions (vues, likes, dislikes, …) dans notre application avec d’autres vidéos. Notre cas d’utilisation s’inscrit dans la categorie ‘User Personalization’ des recipes. Pour cet exemple, nous avons donc choisi la recipe ‘aws-user-personalization’, qui requiert un identifiant d’utilisateur et qui donne en sortie une liste d’identifiants de contenus recommandés (ici des identifiants de vidéos YouTube).
Pour améliorer votre solution, AWS Personalize peut optimiser les hyperparamètres de l’algorithme qui va être entraîné. Pour utiliser cette fonctionnalité, assurez vous juste d’activer le switch pour “Perform HPO” comme dans la figure ci-dessous.
Vous pouvez ensuite changer les vlaeurs par défaut choisies par AWS Personalize, comme le nombre de tâches d’entraînement pendant l’optimisation ou la taille de la dimension cachée (en fonction de la complexité de vos données). Pour cet exemple, nous allons juste utiliser l’optimisation avec les vlaeurs par défaut.
Une fois cette étape terminée, vous devriez voir ceci dans le tableau de bord de votre dataset group :
Votre solution va maintenant être entraînée sur vos données importées dnas AWS Personalize. Cette étape peut prendre du temps, cela dépend surtout de la taille de votre jeu de données. Pour passer à l’étape suivante vous devrez attendre que l’entraînement se termine.
Créer une campagne pour une solution entraînée
Pour obtenir des recommandations à partir de votre solution entraînée, vous devez créer une Campagne. Il s’agit de l’entité avec laquelle vous allez communiquer (à l’aide du SDK AWS par exemple) pour obtenir les resultats claculés par votre solution.
Comme d’habitude il faut choisir un nom, ici pour votre campagne. Ensuite vous pouvez choisir la solution de votre choix parmi celles que vous avez entraîné. Et c’est tout !
Remarque : vous pouvez choisir le nombre minimum de transactions par seconde pour votre campagne, nous le laissons à la valeur par défaut de 1 pour notre exemple.
Rendre les prédictions disponibles
La dernière étape pour obtenir des recommandations d’un algorithme entraîné est d’utiliser le SDK AWS pour communiquer avec votre campagne.
Pour ce faire, nous avons choisi d’utiliser AWS Lambda et AWS API Gateway. Nous ne rentrerons pas dans les détails sur ce sujet étant donné que le sujet de cet article est AWS Personalize. Pour résumer, vous devez configurer une Lambda déclenchée par une route de votre API. Dnas notre exemple, nous souhaitons obtenir des recommandations pour un utilisateur donné, donc la route nécessite l’identifiant de l’utilisateur en path parameter par exemple. Ensuite, il est possible d’obtenir des recommandations pour cet utilisateur à l’aide de l’extrait de code suivant :
Le SDK requiert simplement l’ARN de votre campagne, l’identifiant de l’utilisateur et peut aussi prendre en compte un nombre maximum de résultats.
Cela va vous donner une liste d’items recommandés, plus précisément une liste d’identifiant d’items. Daas notre cas, on obtient une liste d’identifiants de vidéos YouTube :
Bonus: Configurer le tracking Personalize
Jusqu’à maintenant, nous avons entraîné avec succès un algorithme qui donne des recommandations personnalisées pour notre application de recommandation de contenu YouTube. Cependant, cet algorithme a été entraîné à un moment fixe donné sur un jeu de donné fixe d’interactions entre utilisateurs et vidéos. Il en sera de même pour votre solution.
Heureusement, pour l’adapter aux nouvelles interactions de vos utilisateurs avec votre contenu, AWS Personalize permet d’ajouter de nouvelles données en temps réel à vos solutions de recommandation (à vos datasets). Ceci est fait avec les Event Trackers, fonctionnalité qui permet à vos solutions d’apprendre à partir des interactions les plus récentes sans entraînement.
Les Event Trackers vous permettent de traquer les nouvelles interactions de vos utilisateurs et de les intégrer dans vos datasets. Grâce à cette fonctionnalité, AWS Personalize peut adapter les recommandations qu’il fait aux nouveaux évènements traqués en temps réel.
Nous avons mis cette fonctionnalité en bonus de cet article car elle est la cerise sur le gâteau pour votre propre moteur de recommandation créé à l’aide de AWS Personalize. Pour en savoir plus voici la documentation sur le sujet.
Pour créer un tracker, il suffit de lui donner un nom comme dans l’exemple suivant :
Ensuite, le Tracking ID va vous permettre de tracker des évènements avec votre nouveau tracker en utilisant le SDK AWS.
Pour notre application de recommandation de contenu YouTube, nous avons également choisi de travailler avec AWS Lambda pour traquer de nouveaux évènements. Dans le code de la Lambda, traquer un nouvel évènement ressemble à cela :
Il est évidemment obligatoire d’avoir les identifiants de l’utilisateur et l’item impliqués dans l’interaction, ainsi que le moment (timestamp) auquel l’évènement à eu lieu. Ces informations correspondent aux champs de votre schéma d’interaction (USER_ID, ITEM_ID, TIMESTAMP).
Le tracking ID est celui mentionné plus haut, que vous obtenez en créant un tracker. L’identifiant de session (sessionId) peut se révéler utile quand vous voulez garder la trace d’évènements qui ont eu lieu avant que l’utilisateur se connecte à votre service (quand vous ne possédez pas encore l’identifiant utilisateur).
Comment fonctionne la tarification d’AWS Personalize ?
Pour finir cet article et le rendre le plus complet possible, il est temps de parler de ce que vous allez payer pour utiliser AWS Personalize.
La première chose que vous allez payer est l’ingestion de données, qui va vous coûter 0.05$ par GB de données. Cela inclus les données que vous importez depuis S3 comme expliqué plus tôt, mais aussi toutes les données d’interactions ingérées en temps réel par vos trackers. Notez que les 20 premiers GB mensuels sont gratuits ! Ce n’est donc pas ce qui va vous coûter le plus d’argent.
La seconde chose qui vous sera facturée est l’entraînement de vos solutions. La mesure utilisée pour calculer le prix à payer est l’heure de formation.
Une heure de formation représente une heure de capacité de calcul en utilisant des 4 vCPU et 8 Gio de mémoire.
Parfois, vous serez amenés à payer plus que le prix qui correspond au temps écoulé lors d’un entraînement :
Amazon Personalize choisit automatiquement les types d’instance les plus efficaces pour former vos données. Il peut s’agir d’une instance dépassant les spécifications de base afin de terminer votre travail plus rapidement.
De même que pour l’ingestion de données, il y a un palier gratuit de 100 heures de formations mensuelles. Une heure de formation cooûte 0.24$.
Finally, the last (but not least) feature of the service that you will pay is Inference. We will speak here only about real-time inference. To make it simple, you will pay real-time inference as if you were renting a remote machine.
Pour finir, la dernière chose qui vous sera facturée en utilisant AWS Personalize est l’inférence. Nous parlerons ici uniquement d’inférence en temps réel. Pour faire simple, payer de l’inférence en temps réel est similaire à louer une machine à distance.
Le service prend en charge les recommandations en temps réel, qui sont mesurées en transactions par seconde (TPS).
Vous devez spécifier le nombre minimum de TPS que vous souhaitez, selon vos besoins. Ensuite, le montant à payer est calculé sur la base du TPS-heure qui est calculé avec la formule suivante :
Le TPS provisionned correspond au montant minimal de TPS choisi lors de la création de votre campagne, et le TPS actual est le nombre réel de TPS que vous consommez. Vous pouvez trouver plus de détails sur cette tarification ici. Pour l’inférence, cela fonctionne sous la forme de remise sur la quantité. Les 20K premiers TPS-heure mensuels sont facturés 0.20$ l’unité, les 180K suivants coûtent 0.10$ l’unité et enfin au-delà de 200K TPS-heure vous paierez 0.05$ l’unité. Le plus vous l’utilisez le moins vous payez ! (Il y a aussi une tranche gratuite de 50 TPS-heure mensuels.)
Comme nous sommes de gentilles personnes, voici une conversion de ces paliers en termes de TPS (et non de TPS-heure) pour vous aider à choisir le montant de TPS à provisionner :
- 20K TPS-heure mensuels correspondent à ~28 TPS provisionnés
- 200K TPS-heure mensuels représentent ~278 TPS provisionnés
Pour résumer pour la tarification, la chose importante à retenir est que l’inférence est ce qui vous coûtera le plus cher, et vous commencerez à la payer dès la création d’une campagne.
Conclusion
En conclusion, je dirai simplement : ça fonctionne.
Afin de vous faire gagner du temps, nous vous conseillons dans un premier temps de bien réfléchir à la structure de vos données avant d’essayer quelque chose avec AWS Personalize. De cette manière, vous éviterez des pertes de temps à l’ingestion de vos données dnas le service.
Soyez également attentifs à la tarification, ne laisser pas tourner des campagnes que vous n’utilisez plus, cela peut vite vous coûter un bras sans l’utiliser.
Pour finir, il n’est pas possible (pour l’instant du moins) de récupérer des recommandations directement côté client. Vous aurez soit besoin d’utiliser une approche serverless (comme nous l’avons fait avec Lambda) ou un backend dédié.
Vous êtes finalement arrivés au bout de cette série d’articles ! Nous espérons que vous avez appris des choses intéressantes et utiles au cours de ces 3 articles.
