3.2 Les approches d’évaluation des SRI orientées-laboratoire
3.2.1 Le paradigme de Cranfield
L’évaluation des SRI débutait dans les années 1950 où des petites collections de documents (références bibliographiques) ont été utilisées à petite échelle. Dans les années 1960 et 1970, un nouveau paradigme d’évaluation des systèmes de type laboratoire (laboratory-based model), appelé paradigme de Cranfield, est initié par Cleverdon [45] dans le cadre du projet Cranfield project II. Le premier
but des expérimentations dans le projet Cranfield II est la comparaison entre langages d’indexation basés sur l’utilisation du même ensemble de documents, des besoins/requêtes formalisés pour chaque langage en utilisant les mêmes mesures basées essentiellement sur le rappel et la précision. Ce modèle est défini comme suit [46] : "‘a laboratory type situation where, freed as far as possible from the contamination of operational variables, the performance of index languages could be considered in isolation"’.
Généralement, ce modèle et fondé sur la construction des des collections de test volumineuses (e.g. cranfield, CACM) servant de base à l’évaluation des systèmes différents et leurs impacts en pratique et la comparaison des différentes techniques. Le principe de construction des collections de test dans le modèle de Cranfield est basé sur trois hypothèses majeures :
– hypothèse 1 : la pertinence est estimée par la similarité basée sur le cri- tère de sujet, d’où la pertinence thématique. Cette hypothèse présente les implications suivantes : tous les documents pertinents ont le même degré de préférence du point de vue de l’utilisateur ; la pertinence d’un document est indépendante de la pertinence des autres documents : le besoin en information de l’utilisateur est statique.
– hypothèse 2 : un ensemble unique de jugements de pertinence pour une requête est représentatif d’une population d’utilisateurs, ce qui traduit une notion de pertinence commune.
– hypothèse 3 : la liste des documents pertinents pour chaque requête est complète (tous les documents pertinents sont connus).
3.2.2 Collection de test
La collection de test servant à l’évaluation orientée-laboratoire des SRI com- prend un ensemble de requêtes, une collection de documents et des jugements de pertinence associant un sous-ensemble de documents, dits pertinents pour chaque requête. Nous présentons dans cette section les propriétés de chacun de ces éléments, en mettant l’accent sur la campagne d’évaluation TREC comme exemple illustratif, et terminons avec les avantages et les limites de ce modèle d’évaluation.
3.2.2.1 Collection de documents
La collection de documents doit contenir des échantillons des types de textes qui sont considérés intéressants dans un contexte de recherche opérationnel. D’après le modèle de Cranfield, les documents de la collection doivent être
représentatifs d’une tâche de recherche réelle satisfaisant les critères suivants : – Diversité de la collection de test : Il est important que la collection de do- cuments soit représentative dans une tâche de recherche réelle et dispose d’une diversité des sujets, choix des termes, styles de littérature, formats de document, genre, quantité, texte intégral ou résumé du texte, etc. A titre d’exemple, les collections de TREC ad hoc contiennent des articles des journaux (newspaper or newswire articles), et des documents gouver- nementaux (the Federal Register) dans le but d’intégrer la diversité dans la collection de test.
– Volume de la collection : pour qu’une collection de test soit significative, il faut qu’elle comprend un nombre de documents assez élevé. Les premières collections de test développées dans les années 1970 renferment quelques milliers de documents. Les corpus de test plus récentes (par exemple, ceux de TREC) contiennent en général plus 100 000 documents (considérés maintenant comme une collection de taille moyenne), voir des millions de documents (collection de grande taille).
La spécification du volume des collections de documents utilisés dans l’éva- luation orientée-laboratoire est relativement dépendante de la tâche de re- cherche impliquée dans le SRI à évaluer. Classiquement dans les sciences cog- nitives, une tâche est définie comme étant un but à atteindre dans un environ- nement donné au moyen d’actions ou d’opérations [113]. La notion de tâche a été introduite dans plusieurs campagnes d’évaluation telles que TREC, INEX, etc. Dans le cadre de la recherche textuelle simple, la tâche ad hoc est la tâche principale dans TREC qui vise à évaluer les performances des systèmes de recherche d’information, sur des ensembles statiques de documents où seules les requêtes changent. Des tâches spécifiques ont été introduites progressive- ment dans TREC (depuis TREC4 en 1996) afin de permettre l’évaluation de problèmes spécifiques en recherche d’information telles que le filtrage, le croi- sement de langues, la recherche dans de très larges collections (25 giga-octets et plus), les modèles d’interaction, etc.
Généralement, les collections TREC contiennent environ 2 gigabytes de textes (entre 500,000 et 1,000,000 documents). Les collections de documents utilisées dans différentes tâches étaient plus petites ou plus grandes dépendant des besoins des tâches et la disponibilité des données. Une nouvelle tâche ad- hoc dans laquelle la collection de documents est un ensemble représentatif de documents issus du world wide web est proposée dans le cadre de la collection TREC. Une première tâche permet d’étudier l’impact de l’utilisation des liens hypertextes sur les performances de la recherche d’informations sur approxi- mativement 2 GO de pages Web. Une base de 100 GO de documents Web est également mise à disposition des utilisateurs pour l’évaluation des tâches de recherche sur le Web.
3.2.2.2 Collection de requêtes
La requête traduit le besoin en information de l’utilisateur et est formulée souvent par un ensemble de mots clés ciblant les documents recherchés. L’éva- luation d’un système ne doit pas reposer seulement sur une requête. Pour avoir une évaluation assez objective, un ensemble de quelques dizaines de requêtes, traitant des sujets variés, est nécessaire. Vu que l’efficacité d’un système varie considérablement entre les requêtes, plus le nombre de requêtes utilisées dans les expérimentations est élevé, plus les conclusions tirées des expérimentations seront fiables [34].
Dans le cadre des campagnes d’évaluation (TREC, INEX, etc.), le terme to- pic désigne un besoin en information de l’utilisateur dans lequel sont spécifiées des métadonnées supplémentaires concernant une description courte et longue du besoin en information et un ensemble de critères de pertinence des docu- ments répondant au topic. Généralement un topic comprend 4 sections : un identifiant, un titre, une description et un champ narratif. La requête désigne quant à elle la structure du besoin en information soumise au SRI et peut corres- pondre au titre du topic ou sa description. Un exemple typique d’un topic dans TREC est illustré dans la figure 3.1. Le champ Title contient une description courte du topic et le champ Description contient une description riche et plus longue du topic concernant les critères de pertinence des documents associés au topic. Finalement, le champ Narrative décrit des informations additionnelles qui recouvrent les critères de pertinence des documents pertinents associés au topic dans un paragraphe. TREC utilise de 25 à 50 topics comme une norme
<top>
<num> Number: 705
<title> Iraq foreign debt reduction <desc> Description:
Identify any efforts, proposed or undertaken, by world governments to seek reduction of Iraq's foreign debt. <narr> Narrative:
Documents noting this subject as a topic for
discussion (e.g. at U.N. and G7) are relevant. Money pledged for
reconstruction is irrelevant. </top>
Fig. 3.1 – Topic 705 de la tâche Terabyte de TREC
du nombre de requêtes de test. Les topics dans TREC sont crées par le même groupe de personnes qui associent à chaque requête l’ensemble de ses documents pertinents. Souvent, chaque assesseur dans TREC participe en définissant des topics selon ses propres intérêts et recherche dans la collection de documents
via le système de recherche PRISE de NIST pour estimer le nombre de docu- ments pertinents pour chaque topic. Finalement, la liste des topics est choisie par l’équipe de TREC en se basant sur le nombre de documents pertinents associés à chacun et en balançant les choix entre les assesseurs. Dans le cadre de la recherche informationnelle sur le Web, la tâche Terabyte dans TREC, créent les champs Title des topics pour définir des requêtes stéréo-typiquement soumises par des utilisateurs du Web.
3.2.2.3 Jugements de pertinence
Dans le but de comparer les documents résultats fournis par le système et les documents que souhaite recevoir l’utilisateur, il faut spécifier pour chaque requête l’ensemble de réponses idéales du point de vue de l’utilisateur. La spé- cification des jugements de pertinence des documents associés à la requête constituent la tâche la plus difficile dans la construction d’une collection de test. A la différence de l’évaluation à la Cranfield où les documents pertinents doivent être connus et complets pour chaque requête, la technique adoptée dans la plupart des campagnes d’évaluation pour la création des jugements de pertinence ne respectent pas cette hypothèse.
La création des jugements de pertinence dans l’évaluation orientée- laboratoire est basée sur une technique appelée, Pooling. Vu que la notion de pertinence est variable entre les utilisateurs, la technique de Pooling consiste à trouver une pertinence commune sur une partie de documents en se ba- sant uniquement sur le critère de sujet ou la notion de pertinence thématique. Dans cette technique, les jugements de pertinence sont souvent spécifiés par un groupe de personnes (assesseurs) experts dans le domaine des sujets trai- tés par les requêtes. Dans le but d’établir les listes de documents pertinents pour chaque requête, les utilisateurs (ou des assesseurs simulant des utilisa- teurs) doivent examiner chaque document du pool de la collection, et juger s’il est pertinent indépendamment des autres documents pertinents contenant la même information.
La figure 3.2 montre les étapes de la technique de Pooling pour la création des jugements de pertinence, détaillée comme suit :
– Création des topics : les assesseurs créent les topics de test servant à l’évaluation des systèmes,
– Collecte des documents pour un topic : cette étape consiste à collecter les 1000 premiers documents retournés par une variété des systèmes pour un même topic. Dans le cadre de TREC, le NIST (National Institute of Standards and Technology) fournit une collection de documents et un ensemble de requêtes définies. Les participants exploitent leurs propres systèmes de récupération des résultats pour chaque topic, et renvoient au
NIST la liste des documents associée,
– Création des ensembles pools des documents uniques : Il s’agit de créer un ensemble de documents uniques à partir de toutes les listes des do- cuments retournés par les systèmes utilisés puisqu’un même document peut figurer dans plusieurs listes de résultats. Dans TREC, le NIST juge en commun les documents recherchés pour l’exactitude, et évalue les ré- sultats en prenant les k-documents les mieux classés des différents SRI participant à la campagne d’évaluation.
– Création des jugements de pertinence : la dernière étape de la technique de Pooling consiste à juger chaque document dans les pools de documents associés à chaque topic. Chaque document est montré à des assesseurs qui décident finalement de sa pertinence.
Assesseurs créent les topics
Les systèmes sont évalués sur la base des jugements de pertinence créés
Former des pools des documents uniques à partir de tous les systèmes testés et devant être jugés par les assesseurs
Une variété des systèmes différents restituent les premiers 1000 documents pour chaque topic
Fig. 3.2 – Technique de Pooling pour la création des collections de test larges Notons que les jugements de pertinence peuvent être binaires (pertinent, non pertinent) ou graduels correspondants à des degrés de pertinence (utilisés dans Cranfield) allant de très pertinent (high relevant), moyennement pertinent (soft relevant) ou non pertinent (non relevant).
3.2.3 Mesures d’évaluation
L’évaluation des systèmes peut être abordée sous deux angles : l’efficience et l’efficacité. L’efficience regroupe le temps et l’espace [30, 189]. En effet, un système est considéré meilleur lorsque le temps entre la formulation de la re- quête et la réponse du système est court et l’espace occupé par le système est faible. L’efficacité d’un système peut être mesurée par plusieurs critères :
– L’effort intellectuel ou physique, nécessaire aux utilisateurs pour formuler les requêtes, conduire leur recherche, voir les documents résultats, etc. – La présentation du résultat peut être mesurée par la capacité de l’utili-
sateur à utiliser les documents retrouvés,
– La qualité de la collection de documents vis à vis du besoin de l’utilisateur. Ce critère dépend de la disponibilité de l’nformation pertinente dans la
requêtes et |Q| est le nombre de requêtes. Cette mesure peut être qualifiée de globale puisqu’elle combine différents points de mesure. Elle est moins sensible au nombre de documents pertinents que les Pn.
– précision moyenne interpolée : Cette précision est calculée à différents ni- veaux de rappel (0%, 10%, 20%, ...,100%). Pour chaque niveau de rappel, les valeurs calculées sont moyennées sur tout l’ensemble des requêtes. C. Mesures orientées-rang
– Mean Reciprocal Rank (MRR) : correspond à une mesure alternative de calcul de la précision. Si l’utilisateur analyse la liste des documents, cette mesure permet d’évaluer le nombre de documents qu’il faut consi- dérer avant de retrouver le premier document pertinent. Elle est égale à la moyenne (calculée sur l’ensemble de requêtes) du rang du premier document pertinent. MRR = 1 |Q| Q X i=1 1 ranki
MRR est nulle pour une requête si aucun document pertinent n’est re- tourné par le système. Cependant, MRR donne un score élevé pour un système qui retourne des documents pertinents en haut de la liste pré- sentée à l’utilisateur. Cette mesure est souvent utilisée dans les systèmes Questions-réponses où l’utilisateur s’intéresse à recevoir la bonne réponse en premier rang.
Une grande variété des mesures d’évaluation (CG (cumulative gain), DCG (discounted cumulative gain) [90, 89], etc.) ont été développées où certaines sont moins stables que d’autres. Par exemple, les mesures basées sur un peu de données comme la précision au premier document pertinent retrouvé intro- duisent du bruit, et la moyenne des précisions moyennes (MAP), qui mesure la précision globale du système recouvrant tous les points de rappel, est beaucoup plus stable [189].
3.2.4 Protocole d’évaluation
Le protocole d’évaluation dans le modèle d’évaluation orienté-laboratoire consiste à comparer plusieurs systèmes, stratégies de recherche ou algorithmes entre eux en spécifiant trois composantes non indépendantes qui sont le nombre de topics utilisés, les mesures d’évaluation utilisés et la différence de per- formance requise pour considérer qu’une stratégie de recherche est meilleure qu’une autre [34].
L’évaluation de l’efficacité de chaque stratégie de recherche consiste à évaluer la liste de résultats obtenus pour chaque requête de test. Cette évaluation est à la base de la correspondance entre la pertinence algorithmique calculée par le système et la pertinence donnée par les assesseurs. L’efficacité globale d’une
stratégie de recherche est calculée comme étant la moyenne des précisions cal- culées selon une mesure donnée sur l’ensemble des requêtes dans la collection de test.