3. 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.
4. 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
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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/