Bouclage de Pertinence Collaborative

Le mécanisme de bouclage de pertinence suppose que la requête qu de l’utilisateur u

fournit un ensemble de documents que l’utilisateur évalue Rqu. De nouvelles requêtes sont ensuite générées à partir de ces jugements en ajoutant aux termes de la requête initiale des termes extraits de documents sélectionnés Rjugé-peru, on appelle cela l’expansion de requête en fonction du contexte, dans laquelle on prend en compte le jugement de l’utilisateur.

Ce mécanisme est une approche « individuelle » de la fonction de bouclage de pertinence

où la requête qu et l’ensemble Rjugé-peru des documents jugés pertinents par un seul utilisateur u sont pris en compte. On peut également remarquer que cette fonction ne prend en

compte les documents que selon un seul aspect, celui de leur jugement de pertinence. Cependant, nous pensons que le fait de prendre en compte les documents sélectionnés selon d’autres aspects que la pertinence peut aussi être intéressante.

Il y a trois manières d’introduire notre approche collaborative dans le bouclage de

pertinence :

1. Introduire l’ensemble de requêtes QELtc : la fusion de requêtes que nous avons proposée dans la section précédente prend en compte la collaboration et la personnalisation. Au lieu de prendre en compte la requête de l’utilisateur, on prend en compte et on fusionne les requêtes de l’ensemble QELtc pour obtenir une nouvelle requête. On peut utiliser la formule [5.3] ou [5.4] (fusion de requêtes) pour proposer une nouvelle requête en tenant compte des requêtes ayant obtenu une meilleure évaluation EvalEtapej, donc plus efficaces.

2. Introduire l’ensemble de documents RELtc : qui remplace l’ensemble Rjugé-peru du mécanisme de bouclage de pertinence « individuelle » et le personnalise.

3. Introduire les ensembles de requêtes RELtc et des documents RELtc : la reformulation de la requête pour l’utilisateur u prend en compte à la fois des requêtes et des documents des

autres utilisateurs selon plusieurs aspects. Où les ensembles QELtc et RELtc sont pris en compte dans l’ensemble des requêtes et des documents que la fonction de bouclage de pertinence utilise.

La mise en oeuvre du mécanisme de bouclage de pertinence dans les modèles vectoriel et booléen ne présente pas le même degré de difficulté. Puisque ce mécanisme prend essentiellement en compte les documents et leurs jugements. Alors, notre considération au début de ce chapitre que les documents sont des ensembles de termes de leur titre, interviennent dans la mise en ouvre du bouclage de pertinence pour chacun des modèles. Ainsi, notre approche collaborative du bouclage de pertinence est présentée pour le modèle vectoriel (paragraphe 5.4.3.1) pour le modèle booléen (paragraphe 5.4.3.2). En ce qui concerne le bouclage de pertinence collaborative pour des requêtes vectorielles et booléennes, nous précédons de la même manière que pour la fusion des requêtes de modèles différents en transformant le tout à une seule représentation puis nous appliquons le bouclage de pertinence collaborative selon la représentation unique.

5.4.3.1. Bouclage de Pertinence Collaborative pour le Modèle Vectoriel

Nous présentons tout d’abord une méthode de bouclage de pertinence habituelle (paragraphe 5.4.3.1.1), puis l’introduction de notre approche collaborative à cette méthode

(paragraphe 5.4.3.1.2), ensuite, nous présentons et discutons d’une autre approche collaborative déjà étudiée au sein de ce modèle (paragraphe 5.4.3.1.3).

5.4.3.1.1. Bouclage de Pertinence dans le modèle Vectoriel

Plusieurs méthodes de reformulation ont été proposées dans le cadre de ce modèle. La formule suivante de Roccchio [Rocchio 1971] est la définition d’une fonction de reformulation d’un vecteur de requête qu par un vecteur de requête qreformulée :

qreformulée = αqu + β

Dp

1 ∑Doci∈DpDoci - γ

Dnp

1 ∑Doci∈DnpDoci

où Dp est l’ensemble des vecteurs-documents proposés pour qu et jugés pertinents par l’utilisateur. Dnp est l’ensemble des vecteurs-documents proposés pour qu et jugés non pertinents. α,β, γ ∈ [0-1] des facteurs qui permettent d’exprimer les différentes probabilités de fonction de reformulation. ∑ représente la somme des vecteurs.

Dans le cas où l’ensemble de document non pertinents Dnp n’est pas pris en compte (γ = 0), la requête qu et l’ensemble de documents pertinents Dp (l’ensemble Dp est l’ensemble Rjugé-peru selon notre convention) ont la même importance (α = β = 1). La formule précédente de

fonction de bouclage de pertinence peut être exprimée ainsi :

qreformulée = qu +

per

Rjuge¹− _u ∑Doci∈Rjugé-peruDoci

Nous expliquons dans la suite comment l’approche collaborative intervint dans l’ensemble

Rjugé-peru de documents Doci , et puis dans la requête qu.

5.4.3.1.2. Approche Collaborative Proposée

La première approche reformule la requête qu en utilisant l’ensemble des termes TDoci qui apparaisse dans les titres de tous les documents Doci extraits dans RELtc. Puisque la requête qu est un vecteur, alors nous présentons cet ensemble de termes des documents sous la forme d’un vecteur dans l’espace des termes où ont un poids non nul les mots qui apparaissent dans les titres des documents :

(w11 , w12 , …, wij, … ) wij = 1 si tij ∈ ∪Doci∈RELtcTDoci

wij = 0 si tij ∉ ∪Doci∈RELtcTDoci

La requête qreformulée contient tous les termes qui apparaissent dans la requête Tqu et dans les titres de document extraits TDoci :

qreformulée = qu + ( w11 , w12 , … wij, …) où wij≠ 0 si tij ∈ ∪Doci∈RELtcTDoci [5.5]

Tqreformulée = Tqu ∪ (∪Doci∈RELtcTDoci) est l’ensemble des termes de la requête reformulée. La seconde approche reformule la requête en utilisant non seulement l’ensemble des documents Doci extraits dans RELtc. Mais l’ensemble de requêtes extraites dans QELtc Où la

requête qfusion calculée par la formule [5.3] remplace la requête qu de la formule [5.5] précédente ainsi :

qreformulée = qfusion + ( w11 , w12 , … wij, …) où wij≠ 0 si tij ∈ ∪Doci∈RELtcTDoci [5.6] Les termes de la requête sont choisis dans l’ensemble suivant :

Tqreformulée = (∪qi∈QELtcTqi) ∪ (∪Doci∈RELtcTDoci) 5.4.3.1.3. Autre Approche

Une approche semblable s’est intéressée à la collaboration pour l’expansion de requête [Hust 2002a] et [Hust 2002b], dans le cadre du modèle vectoriel, cette approche est un cas particulier de la nôtre dans laquelle les auteurs utilisent dans bouclage de pertinence les documents dont les requêtes sont similaires du point de vue de système c’est-à-dire RELtc =

RSimReq (qu) où :

QSimReq (qu) = {qj : SimReq (qu, qj) ≥ αsimreq }

RSimReq (qu) = { Rqj : qj ∈ QSimReq (qu) }

Nous utilisons nos conventions pour présenter cette méthode, comme la suite :

qreformulée = qu + ∑qj∈QSimReqλqj

∑^∑

Doc

Doc

où || . || est la norme Euclidienne d’un vecteur. QSimReq(qu) l’ensemble des requêtes similaires à la requête qu, et Rqj le résultat de qj. λqj est un paramètre permettant de faire varier le poids donné aux différents termes d’expansion. Pour déterminer les coefficients λqj, les auteurs proposent différentes méthodes :

• QSD (Query Similarity and relevant Documents) :

λqj = SimQ(qu, qj)

où leur fonction de similarité de deux vecteurs de requête est : SimQ(qu, qj) = cos(qu, qj) • QLD (Query Linear combination and relevant Documents) : cette méthode consiste à :

a. utiliser les requêtes qj similaires à la requête qu pour construire la requête qu, comme

une combinaison linaire des requêtes qj avec les coefficients σqj, c’est-à-dire : qu = ∑qi∈QSimReq(qu)σqj∗ qj ⇔ qu = Q ∗ σ

où Q est une matrice de M lignes (dimension de requête) et de |QSimReq(qu)| (le

nombre de requêtes similaires) colonnes. σ est un vecteur d’une colonne de

|QSimReq(qu)| éléments.

b. trouver le vecteur σ^ qui ajuste au mieux l’équation précédente, leur approche étant de minimiser la norme euclidienne du vecteur Q ∗σ - qu :

c. prendre le coefficient λqj égale à σ^

qj si ce dernier est plus grand ou égal à un seuil donné β : λqj = σ^ qj si | σ^ qj | ≥ β λqj = 0 si | σ^ qj | < β

Nous remarquons que dans cette approche le problème est de trouver la valeur des coefficients λqj. Alors dans notre approche, nous n’avons pas ce problème car les valeurs de ces coefficients sont les valeurs des autres critères de soutien. Par exemples λqj peut être le degré de préférence de l’utilisateur uj qui a posé la requête qj (λqj = Pref(uj)), où l’efficacité de requête qj (λqj = Eval-Etapej), …et la formule [5.7] devient :

qreformulée = qu + ∑qj∈QSimReqPref(uj) ∑ ∑ ∈ ∈ j q i j q i R Doc i R Doc i Doc Doc ou

qreformulée = qu + ∑qj∈QSimReqEval-Etapej ∑ ∑ ∈ ∈ j q i j q i R Doc i R Doc i Doc Doc

5.4.3.2. Bouclage de Pertinence Collaborative pour le Modèle Booléen

La première approche introduit la collaboration et les critères de personnalisation dans l’ensemble de documents. La requête reformulée contient en plus de l’expression de la requête de l’utilisateur qu, tous les termes qui apparaissent dans les titres des documents de

RELtc liés par OU. Pour les termes qui apparaissent à la fois dans les titres des documents et dans la requête qu, ils sont liés comme dans la requête qu. Alors la nouvelle requête qrefourmulée :

qreformulée = qu OU t11 OU … OU tij OU … tij ∈ [(∪Doci∈RELtcTDoci)| Tqu] [5.7]

Tqreformulée = Tqu ∪ (∪Doci∈RELtcTDoci)

La seconde approche, ressemble à la première, mais l’expression de la requête fusionnée

qfusion calculée dans la formule [5.4] (fusion des requêtes booléennes) remplace celle de la requête qu ainsi :

qreformulée = qfusion OU t11 OU … OU tij OU … tij ∈ [(∪Doci∈RELtcTDoci)| Tqfusion] [5.8]

Tqreformulée = Tqfusion ∪ (∪Doci∈RELtcTDoci)

Donc, la reformulation de la requête est personnalisée selon plusieurs aspects et elle prend en compte la recherche collaborative.

5.5. Conclusion

Nous avons construit un soutien adapté à trois niveaux : selon le degré de collaboration du groupe, selon le contexte de l’utilisateur ces deux niveaux ont été expliqués à travers le CHAPITRE.4 et dans ce chapitre nous avons proposé une procédure afin de construire un soutien personnalisé et adapté aux désirs et souhaits de l’utilisateurs qu’il les exprime à travers des critères de soutien.

Le chapitre suivant est consacré à la description du prototype réalisé sur la base des idées exposées dans ce chapitre et le chapitre précédent.

CHAPITRE.6. Réalisation du Système

Ce chapitre présente la réalisation de notre proposition, où dans le paragraphe 6.1 nous proposons l’architecture de notre système, dans le paragraphe 6.2 l’implantation de cette architecture. Un exemple clarifiant notre approche est présenté dans le paragraphe 6.3, et dans le paragraphe 6.4 nous présentons un résumé de l’évaluation des systèmes de groupware en général et l’évaluation de notre prototype en particulier, nous conclurons ce chapitre par une discussion sur cette évaluation du prototype et quelques pistes d’amélioration et de développement (paragraphe 6.5).