System de recommandations Xavier Dupré Microsoft / ENSAE

Bio Parcours professionnel Enseignement 2000-2004 - thèse, reconnaissance de l’écriture 2004 – 2007 - reconnaissance de l’écriture 2007 – 2008 - finance 2008 - 2010 - Yahoo – réécriture 2010 – 2015 – Microsoft - Bing, local, réécriture, suggestions 2015 - Microsoft - Azure ML Enseignement 2001- ENSAE, programmation (1A) 2014- ENSAE, voie datascience (2A + 3A) 2015 – organisation de hackathon (Microsoft / ENSAE / Croix-Rouge)

Formalisation d’un système de recommandation Tenseur = matrice multidimensionnelle Utilisateur Produit Temps Localisation Contexte … Quelle valeur pour les paires non observées ? Chaque dimension multiplie les possibilités sans multiplier les données.

Système de recommandation, ranking Ranking similaire à un système de recommandation Requête  résultats conseillés Requête  requêtes associées (Related Searches) Recommandation pure Le système n’utilise pas d’information sur le contenu Uniquement basée sur l’évaluation implicite faite par l’utilisateur (le clic) Recommandation en pratique Système de recommandation pure uniquement une feature Features extraites à partir du contenu et du contexte Utilisation de classifieur intermédiaire (annotation manuelle, catégorisation) Apprendre le feedback des utilisateurs, généraliser là où il n’est pas Feature = itération longue, ranking final = itération courte

Offline / online Offline – cycle long – beaucoup de map reduce Utilisation de logs d’événements (achats, clic) Génération de candidats : requête  liste de résultats, système de recommandations Extraction de caractéristiques (requête, résultat, paire requête résultats Machine learning, à partir des clics, annotation Construction d’une liste de recommandations à utiliser online Online – cycle très court – C++ Ranking online doit être rapide Utilisation du contexte

Mise en production Dans la pratique Black list Contexte  online ou offline Croissance régulière des jeux de données Suggestions trop proches et trop éloignées ne fonctionnent pas Evénement rares : proposer des suggestions pas toujours pertinentes ou les cacher Offline  grande liste de recommandations Online  réduction de la liste online

Durée de vie d’une implémentation Le plus longtemps possible (3-6 ans) car Difficulté de changer de plateformes Documentation manquante ou orale (black list, seuils…) Perte de savoir liée au turn over (interne / externe) Intrication des système et architecture logicielle approximative (exemple de la normalisation) Mais Accroissement naturel des données Implémentation pas forcément conçue pour tout volume de données Accumulation de patchs, features difficile à maintenir Nouvelle technos et algorithmes

Changement de plateforme, d’algorithme Plateforme - durée 6 mois – 1 an Deux plateformes en parallèles pendant quelques mois Migration progressive (1 marché, puis 2, puis…) Parité impossible à obtenir (gain > perte mais jamais identiquement =) Algorithme - durée 3 mois – 6 mois Articles scientifiques – jeux de données plus propres que la réalité La vitesse n’est pas le souci premier (la performance oui) Testés sur des volumes petits Code chercheur = une seule utilisation

Agilité et test A/B Amélioration quotidienne testée via des test A/B Améliorations contraintes par l’agilité Logging d’information Plus on logge, moins on est limité en terme d’idées Coût en terme de calculs : plus on logge, plus ça rame

Quelques paris sur l’avenir Métrique Rôle d’une suggestion dans le parcours utilisateur ? Clic sur une suggestion : est-elle drôle ou pertinente ? Appauvrissement des données dû aux suggestions Personnalisation renforcée Un utilisateur voit différentes suggestions même s’il fait la même requête Apprentissage par renforcement Randomisation des algorithmes Utiliser l’utilisateur pour faire converger le système MWT - http://research.microsoft.com/en-us/projects/mwt/

Questions / Réponses