Just Dance : comment sont faits les systèmes de recommandation ?

Pierre, quel est ton parcours ? 

Je suis chez Ubisoft depuis un peu plus de trois ans et je travaille sur les systèmes de recommandation. De base, j'ai une formation hybride entre l'économie, la science politique et les mathématiques appliquées dans l’informatique. Ensuite, j'ai fait un stage de recherche en NLP et j'ai été recruté par Ubisoft, et je travaille désormais sur des problématiques de mise en production, de maintenance. Il y a une partie de R&D, mais il va y avoir aussi une partie très engineering, très back end.

‍

La Data dans Just Dance

Just dance est un gameplay assez sympa, qui consiste à reproduire les mouvements d'un coach que vous pouvez voir sur un écran avec une musique qui passe. C'est un jeu qui correspond à beaucoup de cibles de joueurs différentes : on peut jouer avec sa famille ou prendre le jeu au sérieux. Il y a un catalogue très riche et diversifié : c’est le setting parfait pour faire de la personnalisation et de la recommandation de musiques sur le jeu.

La recommandation

Pour recommander du contenu personnalisé à nos joueurs, on utilise ce que l'on appelle des feedbacks implicites.

Sur YouTube ou Spotify il y a des systèmes de rating : on peut liker une vidéo ou une chanson. Ce genre de rating est explicite. Sur Just Dance, nous n'avons pas ça. Ce dont on dispose, c’est des feedbacks implicites : quand un utilisateur a terminé une chanson, s’il l'a ajouté à sa playlist favorite, c'est un feedback positif. S’il a quitté la chanson pendant qu'il était en train de jouer, c'est un feedback plutôt négatif.

Donc on combine tous ces différents feedbacks implicites pour créer des ratings, des notes d'appréciation qui sont données en fonction de ce que l'on peut déduire du comportement de jeu.

‍

Un processus difficile 

La recommandation est un processus complexe. Toute la problématique des systèmes de recommandation est qu’il faut deviner la note que donnera un utilisateur à un item qu'il n'a pas encore vu. On essaye d’imaginer une matrice avec dans les colonnes des items (des chansons) et dans les lignes, des utilisateurs. 

L'idée va être de se demander quelle serait la note que pourrait mettre l’utilisateur. Et on se rend compte, que l'algorithme va dire : un joueur X a adoré Baby Shark et a adoré Frozen (la Reine des neiges). Cela signifie que, si le joueur Y n'a pas aimé Baby Shark, il ne va pas aimer Frozen. Ça, c'est le premier algorithme : la recommandation au niveau du profil, généralement triée par pertinence, c'est à dire par relenvency pour le joueur. C’est l’approche User Based.

Il y a un deuxième type d'algorithme auquel vous avez sûrement été confronté, sur Amazon par exemple. Ce sont les algorithmes qui sont Item Based. On ne va pas proposer des items qui sont similaires au profil de l'utilisateur, mais qui sont plutôt similaires aux profils de l'item.

Par exemple, quand le joueur danse sur une musique, la recommandation va proposer des musiques avec des similarités importantes (les coachs, le type de musique).

Amazon fait les deux : ils recommandent des items qui vous correspondent, c'est à dire qu'ils sont vraiment personnalisés, mais lorsque vous allez cliquer sur un item en particulier, si vous descendez en bas de la page, vous allez voir des items qui sont similaires à celui que vous êtes en train de regarder. Il faut arriver à équilibrer les deux types de recommandation dans votre produit. 

‍

Est-ce qu'une chanson peut être recommandée de manière différente avec des critères extérieurs, comme le jour de la semaine, l’heure de la journée ?

Je ne pourrai pas rentrer en détail dans ce que nous prenons en compte dans notre algorithme car c’est confidentiel. Mais en effet, ce sont des critères qui peuvent très bien être pris en compte quand on fait de la recommandation en général. Les inputs choisis pour l’algorithme de recommandations ont une influence sur l'algorithme que l’on peut utiliser. Il y a des algorithmes qui sont rule based, comme le NLP. Donc l’algorithme va déduire : le joueur joue un samedi - le samedi, il aime jouer telle chanson - donc, je vais recommander cette chanson-là. Mais ça va être un peu limité : certes, on va pouvoir utiliser ces inputs custom mais ça va être très compliqué de reproduire cela à la main alors qu’il y a d'autres algorithmes beaucoup plus flexibles, notamment ceux qui utilisent le deep learning, dans lequel on peut mélanger plusieurs features différentes et faire des recommandations pour le joueur.

L’évaluation de la performance d’un algorithme 

Il y a deux métriques pour évaluer un algorithme :

• Les métriques que l’on peut calculer de manière offline juste après avoir entraîné l’algorithme. Si par exemple on entraîne un algorithme de classification, il est possible d’évaluer s’il ne fait pas trop de faux positifs ou négatifs. A ce moment-là, on peut en offline (sans exposer l'algorithme aux utilisateurs), évaluer si un algorithme réalise des performances satisfaisantes dans le cadre de la recommandation.
• Les métriques online c’est lorsque l’on va évaluer les performances de notre algorithme quand il est utilisé par les joueurs. On va regarder à quel point les utilisateurs cliquent sur le contenu que l'on leur recommande, par exemple. Ce sont des métriques que l'on ne peut pas avoir juste après notre entraînement et que l’on doit tracker  ensuite.

Les outils pour créer de faux user

 Pour évaluer les algorithmes, nous pouvons créer de faux utilisateurs. Nous en avons développé chez Ubisoft avec des outils en interne. Si on parle de tests utilisateurs pour lesquels on va mettre le joueur devant des recommandations comme Just dance, on va développer notre propre UI, avec un framework qui s'appelle Dash, par exemple. Si on parle de test de scalabilité, on va plutôt utiliser des outils qui sont développés en interne par Ubisoft.

Les limites de ces systèmes de recommandations 

1. Ces systèmes sont durs à intégrer :

Les programmeurs gameplay ne savent pas comment interpréter les résultats de l’algorithme. D’un autre côté, les user interface designers doivent  l’exposer dans le jeu, c’est-à-dire où placer ces recommandations (problème d’équilibre évoqué précédemment).

Il faut bien comprendre que les personnes avec lesquelles on travaille ne sont parfois pas sensibilisées à ces problématiques techniques. Par conséquent, il va y avoir tout un travail d'évangélisation auprès des équipes.

Par exemple, lorsque l’on va vouloir intégrer notre algorithme de machine learning pour le passer à échelle, il nous faudra être capable de prouver que l'algorithme proposé est capable d'avoir une charge de requêtes conséquente. Cette partie est compliquée parce qu'il faut, non pas seulement optimiser notre modèle d'un point de vue performance algorithmique, mais l'optimiser d'un point de vue performance technique.

Nous pouvons avoir trois recommandations : 

• Commencer très simplement au début, pour faciliter l’étape d'évangélisation avec les autres équipes
• Mettre en place un process facile pour vous permettre d'évaluer la scalabilité de l'algorithme
• Rester le plus proche possible des équipes produits dans le cadre d'un jeu vidéo : les game designers et les user interface designers et des équipes marketing notamment.  Elles ont une meilleure connaissance du produit.

2. Ces systèmes sont compliqués à évaluer :

À chaque entraînement, il y a un aspect stochastique : à la fin de chaque entraînement, il est possible de terminer avec un résultat qui est différent. Lors du déploiement de l’algorithme sur le produit, les testeurs ne vont pas être capables de comprendre l'output qui est effectué par votre algorithme car leur expertise est de s'assurer que le produit fonctionne bien. Elle n'est pas de s'assurer que l'algorithme fonctionne bien.

Je recommande deux choses : 

• Développer assez tôt dans votre pipeline des outils pour tester facilement votre algorithme, qui a priori devrait être simple. Plus il est simple, plus ça va être facile de développer des outils pour l’évaluer. 
• Créer des profils stéréotypés : les faux users, c'est à dire faire de faux profils de joueurs qui ont des patterns de jeu extrêmement stéréotypés pour s'assurer que l’algorithme apprend bien quelque chose concernant les patterns de consommation des joueurs.

3. Ces systèmes sont complexes à maintenir :

Il y a un souci de scalabilité : si le produit est personnalisé pour chacun des utilisateurs, il faut s’assurer que l’algorithme peut effectivement proposer des recommandations pour chacun des utilisateurs le nombre d'utilisateurs augmente, il va également falloir que l’algorithme soit capable de faire des recommandations pour chacun d’entre eux. S'il commence à casser, il est nécessaire d’avoir des alertes mises en place pour prévenir que l’algorithme ne fonctionne plus, il faut assurer au niveau de la maintenance. Que ce soit d'un point de vue technique, par exemple, si le serveur a cassé parce que l’algorithme ne peut plus faire de recommandations ou d'un point de vue algorithmique, c'est-à-dire qu'il y a trop d'utilisateurs.

Je recommande donc de rester simple concernant l’algorithme parce que ça facilite la maintenance. Si l’algorithme casse, assurez-vous d'avoir une solution qui vous permettra de facilement retourner à un modèle qui a fonctionné auparavant.

Pour conclure, la personnalisation, c'est puissant.

C'est important de mesurer le fait que vous êtes pris dans un tout et que l'algorithme interagit avec de nombreuses parties de votre produit et donc vous serez aussi en partie responsable de ces aspects du produit.

La phase d’évangélisation

Pour revenir sur la phase d’évangélisation, il faut de la coordination avec les équipes, suivre les sujets avec elles, essayer de se tenir au courant de tout ce qui est en train de se faire au niveau du produit. Par exemple, lorsque les équipes de production se tournent vers nous avec de nouvelles idées autour d’un produit, nous essayons de parler et de réfléchir conjointement à ce qui peut être fait en termes d'analytics d'abord, avant de penser en termes d'algorithme. C’est indispensable de garder l'esprit ouvert et d'être conscient du fait que le machine learning ne va pas forcément répondre à la problématique.