Le système de recommandation

Notre approche de recommandation appartient à la classe des systèmes de recommandation hybride. Selon la classification de Burke (2002), c’est un hybride de type

commutation (voir la section 2.3.5), basculant d'un filtrage contextuel à un filtrage collaboratif (voir Figure 4.7).

La détermination de la technique appropriée dépend du contexte d’utilisation. Le système se doit alors de définir les critères de commutation, ou les cas où l’utilisation d’une autre technique est recommandée. La commutation entre le filtrage contextuel et le filtrage

collaboratif est faite dépendamment des besoins des utilisateurs. Si l’utilisateur demande

une liste de lecture pour une soirée romantique (pour une situation thématique en général : fête, voyage avec la famille, etc.) Mures va utiliser l’algorithme de filtrage contextuel. Si l’utilisateur veut découvrir de nouvelles chansons l’algorithme employé sera le filtrage

Figure 4.7 Le module de recommandation dans Mures

La première option est le filtrage contextuel. En général, un usager qui a besoin d'une liste de lecture peut fournir quelques informations caractéristiques de ce qu’il veut avoir. Ces informations initiales peuvent être classées en deux types : celles qui décrivent le contexte d'utilisation : soirée romantique, en allant vers son travail et celles qui décrivent les genres musicaux. Suivant le type de ces informations, nous distinguons plusieurs types de recommandation : la recommandation basée sur les tags, la recommandation basée sur les genres musicaux et un hybride de type cascade (voir la section 2.3.5).

Au moment de la création de la base de données Mures (voir la section 4.3), une étape particulière a été la création des tables qui contiennent les tags pour chacun des artistes et chacune des chansons. Ainsi nous avons créé deux tables : artiste_tag et

chanson_tag, ayant les structures suivantes : artiste_tag (artist_id, tag_id, source_id, fréquence), respectivement chanson_tag (chanson_id, tag_id, source_id, fréquence). « Source_id » représente d'où vient le tag en question et peut avoir une des valeurs

suivantes : Mures, Last.fm ou MusicBrainz. Après que ces tables soient créées, nous avons créé la table activity_tag (tag_id, activity_id, fréquence). Celle-ci a été créée manuellement, en choisissant les tags les plus fréquents à partir des deux tables et nous avons essayé

automobile, etc) le plus de tags possibles (voir Figure 4.8).

Figure 4.8 La table activity_tag dans Mures

Dans le cas de filtrage contextuel, nous parlons d’une simple recherche. L’usager spécifie le contexte d'utilisation et le système retourne une liste de tags prédéfinis (voir Figure 4.9). De plus, l'usager a l'option d'ajouter ses propres tags pour enrichir la recommandation. Le système envoie alors des requêtes vers la base de données de musique pour retrouver les chansons correspondantes.

Pour la classification des genres, de nombreuses approches ont été développées avec succès par la communauté MIR32. Certaines propositions intéressantes ont été comparées à la compétition MIREX33 faites en 2011 (URL, 17).

32 _{Music information retrieval (MIR).}

feuilles. Nous avons créé un graph de genres. Le graphe sert à représenter les distances entre les différents genres musicaux afin de pouvoir évaluer les chansons sélectionnés lors de la génération des listes de lecture (voir Figure 4.10).

Figure 4.9 La liste de tags pour un contexte d’utilisation dans Mures

le même principe que celui utilisé pour les tags) deux tables pour les évaluations des artistes et des chansons : votes_artistes et respectivement votes_chanson :

Votes_artistes (artist_id, vote_Mures, no_vote_Mures, vote_MB, no_vote_MB, vote_LF, no_vote_LF)

Votes_chanson (chanson_id, vote_Mures, no_vote_Mures, vote_MB, no_vote_MB, vote_LF, no_vote_LF).

Afin d’évaluer l'artiste ou de la chanson « X », Mures calculera l'évaluation moyenne selon la moyenne pondérée suivante :

Mures offre aussi la possibilité de sélectionner les artistes préférés (de l'usager),

selon les données comprises dans la table user_chanson_votes (user_id, artist_id,

chanson_id, vote, playcount) (voir Figure 4.11).

Figure 4.11 La table user_chanson_votes dans Mures

Vm : vote pour l’artiste ou chanson X

voteMures : moyenne des votes dans Mures (MusicBrainz ou Last.fm)

voir Figure 4.12) sont considérés les préférés et les chansons ayant les meilleures évaluations vont être considérées les meilleures chansons de cet artiste (voir Figure 4.13).

Figure 4.12 Les artistes préférés de l’usager testfoaf

Mures :

 Pseudo-code de l’algorithme de filtrage contextuel Début

1) L’usager choisit le contexte d’utilisation : Mures propose une liste de tags et laisse la possibilité de

valider ces tags et/ou des choisir d’autres tags ti ∈ T

2) L’usager choisit les genres musicaux gi ∈ G

3) Pour chaque tag ti sélectionné Mures va générer une

liste de 10 meilleures chansons

Si l’usager a spécifié des genres musicaux

o Garde seulement les chansons qui appartiennent aux

genres spécifiées

Fin si

4) Mures trouve les artistes pour chaque chanson

sélectionnée dans l’étape 3)

5) Mures :

o Trouve les 15 meilleures chansons des artistes connus

de l’usager

o Trouve les 15 meilleures chansons des artistes

inconnus de l’usager

o Recommande les 30 chansons trouvées de façon

aléatoire

Fin

Il a été largement reconnu que la popularité d'un article (et dans notre cas la popularité d’un artiste) peut diminuer la satisfaction des utilisateurs, en fournissant des recommandations évidentes (Herlocker et al., 2004; Konstan et al., 2006.). Pourtant, il n'y a pas de recette pour fournir des recommandations utiles aux utilisateurs. Mais d’après nous et en tenant compte de travaux de Lamere et al., (2007), nous pouvons prévoir au moins

sérendipité34, la familiarité et la pertinence.

La tâche difficile, pour les deux types de filtrage, a été de trouver le bon niveau de familiarité, de la nouveauté et de la pertinence pour chaque utilisateur. Nous avons voulu offrir à l’utilisateur la possibilité d’être familiarisé avec certaines chansons recommandées, pour améliorer sa confiance dans notre système. En tenant compte de la popularité des artistes et des informations de profil utilisateur, nous avons fourni des recommandations personnalisées, pertinentes qui sont également nouvelles pour l'utilisateur. En outre, certaines chansons devraient être inconnues pour l'utilisateur afin de découvrir les chansons cachées dans le catalogue.

La deuxième option de notre système de recommandation hybride est le filtrage

collaboratif. Le calcul de la similarité est une étape indispensable dans le filtrage

collaboratif. Pour notre système il est très important de trouver les usagers similaires ainsi que les artistes similaires.

Une des originalités de notre application c’est l’utilisation et la combinaison, des

plusieurs jeux de données et des services web disponibles gratuitement sur le Web, comme la base de données de musique de MusicBrainz et les habitudes d’écoute de Last.fm. Afin de trouver les artistes similaires, on utilise une table prédéfinie, calculée à partir du jeu de données de MusicBrainz. Nous avons sélectionné 13,323 artistes distincts et la table contient 262,859 relations. Pour chaque relation (artiste, artiste similaire, similarité) (Ex :

(Madonna, Celine Dion, 0.87)) nous avons testé la similarité correspondante dans Last.fm

et nous avons gardé la moyenne pondérée.

Pour trouver les usagers similaires, on utilise au début les données de Last.fm comme première étape. Ainsi, notre système n’aura aucun problème avec le démarrage à froid, ni du nouvel usager, ni du nouvel artiste qui est un des plus grands problèmes du filtrage collaboratif (voir la section 2.3).

34 _{La sérendipité est le fait de réaliser une découverte inattendue grâce au hasard et à l'intelligence, au cours}