Passage ` a l’´ echelle

a des attaques [SMB07]. Une attaque d´esigne l’injection d’informations frauduleuses visant `a

promouvoir ou rabaisser certains items. La robustesse du syst`eme est mesur´ee par la quantit´e de donn´ees frauduleuses n´ecessaires avant que les changements ne soient effectifs. Il est par-fois possible de mesurer la robustesse th´eoriquement, autrement, il est possible de simuler des attaques afin d’effectuer la mesure.

4.2.12 Adaptation

Il s’agit ici de mesurer la vitesse d’adaptation du syst`eme aux nouvelles donn´ees. Les

nou-velles donn´ees concernent soit les items (les nouveaux items peuvent par exemple prendre la

place de leurs pr´ed´ecesseurs qui deviennent obsol`etes) soit les nouvelles donn´ees fournies par l’utilisateur cible. L’adaptation peut ˆetre mesur´ee en comparant les recommandations avant et apr`es l’application des changements.

4.2.13 Passage `a l’´echelle

Le passage `a l’´echelle est un point crucial dans les syst`emes de recommandation. En effet, les syst`emes de recommandation traitent d’importantes quantit´es de donn´ees, il est donc important de rester r´eactif face `a elles. Les recommandations ´etant cens´ees ˆetre propos´ees en temps r´eel, la mesure du passage `a l’´echelle repose sur le calcul du temps de construction du mod`ele

hors-ligne, du temps de r´eponse entre l’envoi d’une requˆete et la r´eception des recommandations

et du nombre de recommandations g´en´er´ees par unit´e de temps (par exemple le nombre de

recommandations par seconde).

Nous avons recens´e dans ce chapitre les diverses fa¸cons d’´evaluer les performances d’un sys-t`eme de recommandation. L’id´eal, si l’on dispose d’une quantit´e suffisante de donn´ees concer-nant les interactions des utilisateurs avec le syst`eme (des notes d’items, etc.), est d’effectuer une ´evaluation hors-ligne. Une ´evaluation hors-ligne va permettre d’avoir une id´ee globale du

comportement du syst`eme et de l’am´eliorer avant de le diffuser au grand public. Quant aux

´

evaluations en ligne, il en existe deux types : les tests en ligne et les ´etudes utilisateurs. Le test en ligne est une ´evaluation `a risque. En effet, il s’agit d’´evaluer toute l’application sur de vrais utilisateurs. Si le syst`eme de recommandation n’est pas au point, il y a un risque que l’utilisateur soit dissuad´e de r´eutiliser l’application dans le futur.

Il vaudrait donc mieux, dans le meilleur des sc´enarios, effectuer une ´evaluation hors-ligne, suivie d’une ´etude utilisateur, qui permet une interaction directe avec les utilisateurs, pour enfin proc´eder `a la mise en ligne et donc au test `a grande ´echelle.

Ces trois types d’´evaluations permettent uniquement de r´ecolter des donn´ees. Ces derni`eres doivent ˆetre ensuite analys´ees pour pouvoir ˆetre interpr´et´ees. Pour ce faire, plusieurs dimensions `

a ´evaluer ont ´et´e identifi´ees. Le choix de ces dimensions se fait en fonction des objectifs du syst`eme de recommandation. Par exemple, si l’objectif du syst`eme est de fid´eliser l’utilisateur, la mesure de la confiance de l’utilisateur sera plus appropri´ee (voir section 4.2.6), si l’on doit travailler avec une tr`es grande quantit´e de donn´ees, il faut mesurer la capacit´e du syst`eme `a passer `a l’´echelle (section 4.2.13), etc.

Chapitre 5

Conclusion

Dans cette partie consacr´ee `a l’´etat de l’art, nous avons ´etudi´e les diff´erentes ´etapes de la cr´eation d’un syst`eme de recommandation. Premi`erement, il est n´ecessaire de d´efinir le mod`ele utilisateur. Ensuite, vient le choix et l’impl´ementation de l’approche de recommandation. Enfin, la validation de l’approche de recommandation est effectu´ee.

La mod´elisation utilisateur souligne que les donn´ees fournies explicitement par l’utilisateur ne sont pas les seules donn´ees utilisables afin de construire son profil. En effet, des donn´ees implicites provenant des actions de l’utilisateur sur le syst`eme peuvent ´egalement ˆetre analys´ees et interpr´et´ees. De ce fait, [Koc01] classe les mod`eles utilisateurs selon leur utilisation de donn´ees explicites ou implicites entre autres. Nous utilisons cette caract´erisation non pas pour classer les mod`eles utilisateurs, mais pour classer les utilisateurs eux-mˆemes. En effet, nous distinguons entre les utilisateurs explicites et implicites afin de mieux exploiter les donn´ees disponibles `a leur propos.

Dans le chapitre 3, nous avons pr´esent´e les diff´erentes approches de recommandation

exis-tantes et les diff´erentes techniques d’hybridation possibles. Les syst`emes de recommandation

hybrides pr´esentent de meilleures performances que les syst`emes de recommandation simples.

C’est pourquoi l’hybridation repr´esente un objectif majeur dans l’´elaboration de notre

sys-t`eme. Pour ce faire, nous utilisons un module de recommandation collaboratif et un module

de recommandation bas´e sur le contenu. Les approches collaboratives ont l’avantage de ne pas

n´ecessiter de connaissances sur les items et donc sur le domaine. Ces approches sont donc

fa-cilement r´eutilisables dans d’autres domaines. Les approches bas´ees sur le contenu (ainsi que les approches bas´ees sur la connaissance ou sur l’utilit´e) sont quant `a elles fortement li´ees au domaine auquel elles sont destin´ees. Par cons´equent, ce type d’approches est d´ependant du do-maine et n´ecessite d’y apporter des modifications majeures afin de pouvoir ˆetre r´eutilis´e dans

d’autres domaines. Nous nous sommes donc fix´e comme objectif la d´efinition d’une approche

de recommandation totalement ind´ependante du domaine. En effet, les donn´ees du

syst`eme ´etant d´ecrites dans une ontologie, nous nous basons uniquement sur la structure de

l’ontologie afin de raisonner sur les items.

modules de recommandation ainsi que deux mesures s´emantiques pouvant ˆetre incluses dans le

processus de recommandation. Ces modules et mesures ne sont pas syst´ematiquement appliqu´es

de la mˆeme mani`ere pour tous les utilisateurs. En effet, nous pr´econisons l’adaptation du

processus de recommandation `a l’utilisateur [MA00, IH07]. Pour ce faire, le profil de

l’utilisateur est analys´e afin de le classer dans une cat´egorie et cette derni`ere d´etermine le

processus de recommandation `a utiliser. Par ailleurs, les modules de recommandation et les

mesures s´emantiques d´efinis permettent d’expliquer les recommandations aux utilisateurs

afin de gagner en transparence et de permettre aux utilisateurs de corriger les raisonnements expliqu´es qui ne leur sont pas adapt´es.

Le chapitre 4 r´esume, quant `a lui, les diff´erentes techniques d’´evaluation possibles ainsi

que les dimensions `a mesurer lors de ces ´evaluations. Nous retenons dans notre approche deux

techniques d’´evaluation qui sont applicables `a notre syst`eme : l’´evaluation hors-ligne qui permet

dans un premier temps de tester l’approche sur un ensemble de donn´ees et d’affiner les

para-m`etres utilis´es ; puis l’´etude utilisateur o`u de vrais utilisateurs testent et interagissent avec le syst`eme d´efini. Le test en ligne n’est, quant `a lui, pas applicable `a notre syst`eme car il concerne les syst`emes existant et accueillant fr´equemment de vrais utilisateurs.

Deuxi`eme partie

DOMINOS : DOMain INdependent

recOmmender System

Chapitre 1

Introduction

Durant ces derni`eres ann´ees, le probl`eme de la recommandation s’est de plus en plus focalis´e sur l’utilisateur en mettant en ´evidence le caract`ere unique de celui-ci. De ce fait, de nouvelles

di-mensions `a prendre en compte sont apparues. L’explication de la recommandation en fait partie

[TM08]. En effet, expliquer `a l’utilisateur pourquoi un item lui a ´et´e recommand´e rend la recom-mandation plus personnelle. Il ne s’agit plus, dans ce cas de figure, de noyer l’utilisateur devant

un ensemble d’items recommand´es mais de lui proposer des items tout en expliquant pourquoi

ils pourraient l’int´eresser. Les explications permettent, entre autres, de s’adresser directement `

a l’utilisateur, de susciter sa curiosit´e et de gagner sa confiance.

Les utilisateurs ´etant diff´erents les uns des autres, les satisfaire `a l’aide d’un processus de

recommandation identique pour tout le monde est une tˆache d´elicate. Il est donc important

de prendre en compte les diff´erences entre utilisateurs et de mettre en place un syst`eme de

recommandation qui s’adapte pour pouvoir r´epondre aux besoins sp´ecifiques de chacun [MA00,

IH07, DPH⁺09].

Dans cette partie, nous pr´esentons DOMINOS (DOMain INdependent recOmmendation

System), un syst`eme de recommandation hybride, adaptatif, ind´ependant du domaine et

expli-quant les recommandations. DOMINOS propose une approche de recommandation adaptative

telle que le processus de recommandation s’adapte `a chaque utilisateur. Les utilisateurs sont

class´es par cat´egories suite `a l’analyse de leurs profils et chaque cat´egorie se voit appliquer un

processus de recommandation diff´erent. Celui-ci peut-ˆetre hybride ou simple. Les

recomman-dations r´esultantes sont ´egalement expliqu´ees dans un effort de transparence et d’interactivit´e

avec l’utilisateur. Par ailleurs, DOMINOS se veut ind´ependant du domaine, dans la mesure o`u

la m´ethodologie appliqu´ee est g´en´erique et applicable `a des domaines diff´erents. Pour ce faire,

la connaissance du domaine est contenue dans une ontologie donn´ee en entr´ee au syst`eme et

la recommandation se fait `a l’aide de raisonnements bas´es sur la structure de l’ontologie. De ce fait, le domaine est d´etermin´e par l’ontologie donn´ee en entr´ee du syst`eme et le changement de domaine n´ecessite seulement le changement de l’ontologie `a condition que celle-ci respecte le

langage d’expression utilis´e qui est OWL-DL.

de deux parties : (i) l’apprentissage de la cat´egorie de l’utilisateur, (ii) le moteur de recomman-dation.

L’apprentissage des cat´egories d’utilisateurs est d´efini dans le chapitre 3. Cet apprentissage est une ´etape tr`es importante dans l’approche que nous pr´esentons. En effet, l’adaptation du processus de recommandation repose enti`erement sur le r´esultat de cette cat´egorisation. Les donn´ees r´ecolt´ees sur les utilisateurs sont dans un premier temps analys´ees, ce qui permet de d´etecter le caract`ere implicite et/ou explicite de l’utilisateur. Les donn´ees `a utiliser sont ensuite s´electionn´ees et analys´ees une seconde fois afin d’attribuer une cat´egorie `a l’utilisateur.

Une fois la cat´egorie de l’utilisateur d´etect´ee, le processus de recommandation ad´equat est s´electionn´e. Les diff´erents processus sont d´ecrits dans le chapitre 6. Ces processus utilisent les mesures s´emantiques d´efinies dans le chapitre 4 et les modules de recommandation d´efinis dans le chapitre 5.

Chapitre 2

L’architecture du syst`eme

L’architecture du syst`eme de recommandation est illustr´ee sur la Figure 2.2.1. Cette

ar-chitecture permet `a la fois d’avoir un syst`eme hybride, adaptatif, ind´ependant du domaine et pouvant expliquer la recommandation.

Figure 2.2.1 – L’architecture du syst`eme de recommandation

Nous allons dans un premier temps d´ecrire les donn´ees sur lesquelles nous travaillons,

2.1 Description des donn´ees

Les items du syst`eme sont d´ecrits dans une ontologie (voir chapitre 2, d´efinition 3). Dans la suite, une ontologie sera not´ee O(C, R, X , A) o`u C est l’ensemble des concepts, R l’ensemble

des propri´et´es (relations), X l’ensemble des axiomes (subclassOf, domain, range, etc.) et A

l’ensemble des axiomes sur les instances et leurs relations (typage et relations). Nous notons I l’ensemble des instances de concepts de C.

Ainsi, les items qui sont concern´es par la recommandation sont des instances. Notons Item ∈ C le concept repr´esentant les items et It ⊆ I l’ensemble des instances de type Item du syst`eme : i ∈ It ⇒ Item(i).

De plus, le syst`eme prend en entr´ee l’ensemble des profils des utilisateurs U , parmi lesquels le profil de l’utilisateur cible not´e u. Un profil contiendra notamment des informations pouvant ˆ

etre exploit´ees afin de d´eterminer les pr´ef´erences des utilisateurs en termes d’items. Parmi ces informations, l’historique de l’utilisateur qui est constitu´e d’items pour lesquels nous disposons de notes explicites ou implicites de l’utilisateur. L’historique de l’utilisateur u est d´efini par :

u ∈ U historique(u) ⊆ It (2.1)

Les notes des items de l’historique seront repr´esent´ees par une fonction note telle que :

u ∈ U , i ∈ historique(u) note(u, i) ∈ [bmin, bmax] (2.2)

o`u bmin et bmax sont respectivement les bornes inf´erieure et sup´erieure de l’´echelle de notation.

Le traitement de ces informations m`ene `a la recommandation et est d´ecrit dans le moteur de recommandation.