Collecte des préférences
Les systèmes de filtrage présupposent l’existence d’un système de collecte du degré d’appréciation des utilisateurs pour une ressource donnée. En effet, pour caractériser un profil d’utilisateur, la première chose à collecter est l’évaluation d’une ressource donnée faite par un utilisateur : si cette dernière lui a plu, moins plu, ou pas du tout plus. À cet effet, il existe deux approches: demander à l’utilisateur explicitement d’évaluer lui-même les ressources à partir d’une échelle de notes préalablement définie, ou bien inférer automatiquement cette évaluation, grâce aux informations que l’on peut récolter à partir des données du protocole de communication [1].
Évaluations explicites. Les utilisateurs sont obligés de spécifier explicitement leurs préférences pour toutes les ressources. Généralement, les utilisateurs doivent indiquer leur degré d’appréciation sur une échelle de 1 à 5 ou 1 à 7. De récentes études ont mis en évidence l’impact du choix de l’échelle d’évaluation sur la qualité des recommandations [2].
Évaluations implicites. Les évaluations explicites imposent aux utilisateurs des efforts supplémentaires. En conséquence, les utilisateurs tendent souvent à éviter ce fardeau en quittant définitivement le système ou en fournissant des évaluations erronées [2]. À l’opposé, la déduction de ces évaluations par la seule observation du comportement des utilisateurs est beaucoup moins intrusive. Parmi les exemples typiques de ces observations pour des évaluations implicites, on peut citer l’historique d’achat pour Amazon, le temps de lecture pour Usenet News [2], et l’analyse des comportements de navigation sur Internet pour Quickstep [3, 4].
Un exemple réel de l’inférence des évaluations implicite est la formule, proposée par Chan [5], pour prédire si une page web a été appréciée ou pas. Cette formule se base, en grande partie, sur les informations que l’on peut récolter à partir des données du protocole de communication. En effet, elle est calculée en fonction de l’historique, le marque-page (bookmark), le contenu des pages et le journal des accès (« access log »).
Plus précisément, l’historique d’un navigateur web maintient une trace du dernier moment qu’une page a été visitée. On peut donc utiliser cette donnée pour calculer combien de fois un utilisateur passe sur une page et depuis quand il n’est pas retourné la visiter. De plus, on peut également supposer qu’une URL présente dans le marque-page d’un utilisateur est considérée comme intéressante pour celui-ci. En outre, chaque page contient des liens vers d’autres pages. On suppose que si un utilisateur est intéressé par une page, il va probablement visiter les liens référencés par celle-ci. Ainsi, on conjecture qu’un fort pourcentage de liens visités à partir d’une page dénote un intérêt particulier pour cette page. Enfin, chaque entrée dans un journal des accès correspond à une requête HTTP, qui contient typiquement l’adresse IP du client, une marque du moment de connexion, des méthodes d’accès, une URL, un protocole, un statut, et une taille de fichier. Typiquement, une ligne de fichier de log se présente comme suit:
« 216.22.34.11 – – [10/Jul/2008:04:04:54 +0200] « GET /uqam.ca/index.html HTTP/1.1 » 200 2856 »
Où
- 216.22.34.11 correspond à l’adresse IP du client,
- 10/Jul/2008:04:04:54 correspond au moment de connexion,
- GET correspond à la méthode d’accès,
- /uqam.ca/index.html est l’URL de la page qui a été visitée,
- HTTP/1.1 correspond au protocole de communication,
- 200 est la valeur de retour (ici, tout s’est bien passé),
- 2856 correspond à la quantité d’informations transférées (généralement la taille du fichier).
Grâce à ces informations, le temps passé sur chaque page peut être calculé. Cependant, le temps passé sur une page dépendant également de la longueur de cette page, l’intérêt d’un utilisateur pour une page sera calculé par le temps passé sur la page, normalisé par la taille de la page.
Finalement, Chan [5] définit le degré d’intérêt d’une page par:
Un autre exemple concret pour l’évaluation non intrusive est la collecte des préférences des utilisateurs sur la musique écoutée. Les lecteurs multimédias, comme iTunes et Windows Media Player, ont la possibilité d’observer le nombre de fois que vous écoutez une chanson. Ces logiciels peuvent aussi se rappeler la dernière fois que vous avez écouté chaque chanson. Ces informations peuvent être utilisées pour dégager les évaluations implicites des utilisateurs [6]. La figure 1 illustre les différents aspects de notre vie quotidienne qui peuvent être utilisés par les systèmes de recommandations.
Figure 1 Aspects de vie quotidienne pouvant être utilisés par les systèmes de recommandation [6]
Pour conclure, malgré la facilité qu’elle peut apporter dans la collecte des préférences des utilisateurs, l’évaluation implicite comporte quelques limites. Par exemple, les achats faits pour offrir à une autre personne (achats de cadeaux) ou pour le compte de quelqu’un d’autre (achats pour son entreprise) ne reflètent pas les intérêts de l’utilisateur. Ainsi, les évaluations implicites ne représentent pas toujours les préférences réelles de l’utilisateur. De plus, il est difficile d’obtenir des évaluations explicites des utilisateurs. Pour ces raisons, un certain nombre de systèmes de recommandation adoptent des approches hybrides. Amazon.com calcule ses recommandations en se basant, autant que possible, sur des évaluations explicites. En cas d’indisponibilité de ces dernières, des évaluations implicites, inférées des observations des comportements de l’utilisateur, sont utilisées à la place [2].
Références
[1] M. Claypool, M. Claypool, D. Brown, P. Le, and M. A. W. M. Waseda, « Inferring user interest
Inferring user interest, » Internet Computing, IEEE, vol. 5, pp. 32-39, 2001.
[2] C.-N. Ziegler, « Towards Decentralized Recommender Systems, » Albert-Ludwigs-Universitat Freiburg – Fakultat fur Angewandte Wissenschaften, Institut fur Informatik, 2005.
[3] S. E. Middleton, N. R. Shadbolt, and D. C. De Roure, « Ontological user profiling in recommender systems, » ACM Trans. Inf. Syst., vol. 22, pp. 54-88, 2004.
[4] W. Gaul and L. Schmidt-Thieme, « Recommender Systems Based On User Navigation Behaviour In The Internet, » Behaviormetrika, vol. 29, pp. 1-22, 2002.
[5] P. K. Chan, « A non-invasive learning approach to building web user profiles, » Workshop on Web usage analysis and user profiling, Fifth International Conference on Knowledge Discovery and Data Mining, August 1999.
[6] N. B. Miller, « Toward a personal recommender system, » University of Minnesota, 2003, p. 185.
Corpus pour l’évaluation des systèmes de recommandation
Les chercheurs qui travaillent dans le domaine du filtrage collaboratif de l’information utilisent différents corpus de plusieurs domaines d’application pour évaluer la performance des algorithmes de recommandation [1]. On trouvera une revue de la littérature sur les corpus d’évaluation pour les systèmes de recommandation dans Zaier et al. [2].
Corpus MovieLens. Ces derniers sont les plus populaires dans l’évaluation des systèmes de recommandation. En effet, les corpus MovieLens ont déjà fait l’objet de plusieurs travaux de recherche [3-5]. Publiquement disponibles, ils contiennent des évaluations explicites au sujet de films, des informations démographiques sur les utilisateurs (âge, genre, métier, code postal) et une courte description des films (titre, année de production, genres). Ainsi, ces corpus, à très forte densité, sont constitués d’évaluations de films, sur une échelle de 1 à 5, faites par 943 utilisateurs anonymes sur 1682 films. De plus, cette collection est subdivisée en plusieurs corpus d’évaluation.
Corpus Jester. Ces corpus, proposés par Ken Goldberg du site Web de recommandation de blagues Jester, contiennent des évaluations, de 100 blagues, faites par 73.496 utilisateurs anonymes. Les notes sont des valeurs réelles qui varient entre -10.00 et +10.00 [6]. Ces corpus, comme pour les corpus MovieLens, ont une très forte densité. En effet, un grand nombre d’utilisateurs ont évalué, à peu près, toutes les blagues.
Cette collection est divisée en trois corpus différents :
- Jester-data-1 : Contient les évaluations de 24.983 utilisateurs qui ont évalué 36 blagues ou plus.
- Jester-data-2 : Contient les notes de 23.500 utilisateurs qui ont évalué 36 blagues ou plus.
- Jester-data-3 : Contient les données de 24.938 utilisateurs qui ont évalué entre 15 et 35 blagues.
Corpus Netflix. Le corpus Netflix est actuellement l’objet d’un nombre considérable d’études. En 2006, le spécialiste de la location de films en ligne lance le Netflix Prize, avec un million de dollars pour qui augmentera de dix pour cent la qualité de leur système de recommandation Cinematch™. Ce dernier prédit si un spectateur va aimer ou non un film en fonction des films qu’il a appréciés (ou pas) par le passé. À cet effet, Netflix a proposé un gros corpus comprenant plus de 100 millions d’évaluations de 17.770 films, sur une échelle de 1 à 5, fournies par 480.189 utilisateurs anonymes. De plus, ce corpus comporte une courte description des films (titre et année de production) [7-12].
Corpus BookCrossing. Le corpus BookCrossing a été recueilli en 2004 par Cao-Nicolas Ziegler, à partir de la communauté Book-Crossing. Il est composé de 278.858 utilisateurs anonymes qui ont fourni 1.149.780 évaluations sur 271.379 livres, notées sur une échelle de 1 à 10. Ce corpus, comme pour le corpus de MovieLens, contient des informations démographiques sur les utilisateurs (âge et ville) et une courte description des livres (titre du livre, auteur du livre, année de publication, éditeur) [13, 14].
Une attention particulière doit être portée quant au choix des corpus. Une des préoccupations est de choisir des corpus facilement accessibles et disponibles, ayant déjà été utilisés dans le passé et étant susceptibles de l’être encore dans le futur. Un autre aspect assez important est la taille de ces corpus. Pour que les résultats soient significatifs, les bases de travail devaient contenir un nombre suffisant d’utilisateurs, d’article à évaluer, et d’évaluations. Une récente étude, sur la distribution des corpus d’évaluation des systèmes de recommandation, montre que cette dernière pouvait influencer la performance des algorithmes [2]. Il est donc préférable de choisir un corpus qui suit une distribution réelle et ainsi, obtenir des performances qui reflètent la réalité [15-17].
Références
[1] L. J. Herlocker, A. J. Konstan, G. L. Terveen, and T. J. Riedl, « Evaluating collaborative filtering recommender systems, » ACM Trans. Inf. Syst., vol. 22, pp. 5-53, 2004.
[2] Z. Zaier, R. Godin, and L. Faucher, « Evaluating Recommender Systems, » in Fourth International Conference on Automated Production of Cross Media Content for Multi-Channel Distribution. AXMEDIS ’08 Florence, Italy, 2008, pp. 211-217.
[3] Z. Zaier, R. Godin, and L. Faucher, « Recommendation Quality Evolution Based on Neighborhood Size, » in Third International Conference on Automated Production of Cross Media Content for Multi-Channel Distribution. AXMEDIS ’07 Barcelona, Spain, 2007, pp. 33-36.
[4] Z. Zaier, R. Godin, and L. Faucher, « Recommendation Quality Evolution Based on Neighbors Discrimination, » in MCETECH Conference on e-Technologies Montreal, 2008, pp. 148-153.
[5] B. N. Miller, J. A. Konstan, and J. T. Riedl, « PocketLens: Toward a personal recommender system, » ACM Trans. Inf. Syst., vol. 22, pp. 437-476, 2004.
[6] J. Canny, « Collaborative filtering with privacy via factor analysis, » in Proceedings of the 25th annual international ACM SIGIR conference on Research and development in information retrieval Tampere, Finland: ACM, 2002.
[7] R. Bell and Y. Koren, « Lessons from the Netflix prize challenge, » SIGKDD Explor. Newsl., vol. 9, pp. 75-79, 2007.
[8] R. Bell and Y. Koren, « Improved Neighborhood-based Collaborative Filtering, » 2007.
[9] R. Bell and Y. Koren, « Scalable Collaborative Filtering with Jointly Derived Neighborhood Interpolation Weights, » in Data Mining, 2007. ICDM 2007. Seventh IEEE International Conference on, 2007, pp. 43-52.
[10] R. Bell, Y. Koren, and C. Volinsky, « Modeling relationships at multiple scales to improve accuracy of large recommender systems, » in Proceedings of the 13th ACM SIGKDD international conference on Knowledge discovery and data mining San Jose, California, USA: ACM, 2007.
[11] R. Bell, Y. Koren, and C. Volinsky, « The BellKor solution to the Netflix Prize, » 2007.
[12] R. Bell, Y. Koren, and C. Volinsky, « Chasing $1,000,000: How We Won The Netflix Progress Prize » Statistical Computing and Statistical Graphics Newsletter, vol. 18, pp. 4-12, 2007.
[13] C.-N. Ziegler, S. M. McNee, J. A. Konstan, and G. Lausen, « Improving recommendation lists through topic diversification, » in Proceedings of the 14th international conference on World Wide Web Chiba, Japan: ACM, 2005.
[14] C.-N. Ziegler, « Towards Decentralized Recommender Systems, » Albert-Ludwigs-Universitat Freiburg – Fakultat fur Angewandte Wissenschaften, Institut fur Informatik, 2005.
[15] C. Anderson, The Long Tail: Why the Future of Business Is Selling Less of More: Hyperion, 2006.
[16] C. Anderson, « The Long Tail, » Wired Magazine, vol. 12, 2004.
[17] A. Elberse, « Should You Invest in the Long Tail?, » in Harvard Business Review, 2008.