Nicolas Noullet IUP ISI L3 1er avril – 1er août 2009/2010

Maître de stage : Guillaume Cabanac Tuteur : Bernard Cherbonneau

Rapport de stage Développement d’un moteur de recherche d’information textuelle

Institut de Recherche en Informatique de Toulouse 118 route de Narbonne 31062 Toulouse Cedex 9

Remerciements

Je tiens à remercier Monsieur Claude Chrisment de m’avoir accueilli au sein de l’équipe SIG. Je remercie également mon maître de stage, Monsieur Guillaume Cabanac, de m’avoir permis d’effectuer un stage à l’IRIT, de son encadrement efficace et enthousiaste et des précieux conseils qu’il m’a donnés tout au long de ce stage. De plus, je remercie Monsieur Mohand Boughanem pour ses explications précises qui ont orienté mes décisions et m’ont permis d’obtenir des résultats concluants. Enfin, je souhaite remercier mon tuteur de stage, Monsieur Bernard Cherbonneau.

Table des matières 1 Introduction

6

2 Contexte du stage

7

2.1

L’IRIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

L’équipe SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

Moyens mis à disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3 Présentation du sujet 3.1

10

Concepts nécessaires à la compréhension du sujet . . . . . . . . . . . . . . . . 10 3.1.1

Principe général d’un moteur de recherche . . . . . . . . . . . . . . . . 10

3.1.2

Campagnes d’évaluation de moteurs de recherche . . . . . . . . . . . . 11

3.2

Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3

Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Démarche mise en œuvre

13

4.1

Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2

Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3

Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4

Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Travail réalisé 5.1

15

Analyse préalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1

Cadre d’évaluation TREC . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1.2

Utilisation du moteur de référence Terrier sur une collection TREC . . 16

5.2

Architecture prévue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3

Développement de l’API term . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.4

5.5

5.3.1

Parseurs XML et expressions régulières . . . . . . . . . . . . . . . . . . 17

5.3.2

Parseur dédié au HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Développement de l’API storage . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4.1

Berkeley DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4.2

Fichiers binaires adhoc . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4

5.6

Interrogation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.7

Activités annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.7.1

Collaboration avec un doctorant . . . . . . . . . . . . . . . . . . . . . . 22

5.7.2

Participation à PIVasse . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7.3

Utilisation de LaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7.4

Réalisation d’un tutoriel . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Résultats obtenus 6.1

6.2

24

Apport du travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1

Évaluation du travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1.2

Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Perspectives d’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Bilan personnel

27

7.1

Lien avec les enseignements ISI . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.2

Différences avec le stage précédent . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.3

Choix du stage et implication dans le projet professionnel . . . . . . . . . . . . 28

8 Conclusion

29

Table des figures

30

Liste des tableaux

31

Bibliographie

32

page 5 sur 34

Chapitre 1

Introduction Ce document présente mon rapport pour le stage de quatre mois de licence 3 de l’IUP ISI. J’ai effectué ce stage dans un laboratoire d’informatique du campus de l’université Paul Sabatier : l’Institut de Recherche en Informatique de Toulouse (IRIT). Ce laboratoire aborde l’ensemble des thématiques de l’informatique actuelle, réparties dans plusieurs équipes. C’est dans l’équipe « Systèmes d’Informations Généralisés » (SIG) que j’ai réalisé mon stage, sous l’encadrement d’un enseignant-chercheur : Guillaume Cabanac. Le sujet de mon stage est le développement d’un moteur de recherche d’information textuelle. Plus précisément, il s’agissait de développer une nouvelle version d’un moteur de recherche développé dans les années 1990 : Mercure. L’intérêt de ce moteur de recherche est de servir de support pour la validation des propositions des chercheurs de l’équipe SIG. Le développement de cette nouvelle version, Mercure2, se justifie par l’évolution rapide des systèmes d’informations, en taille et en complexité, qui ont rendu peu à peu Mercure1 obsolète. En effet, les maintenances et extensions successives de ce programme développé en C ont provoqué des sources de bogues nuisant fortement à son efficacité, dues aux tentatives de mise à l’échelle pour suivre les évolutions du domaine de la recherche d’information et à des erreurs de programmation. L’objectif de mon stage a donc été de développer Mercure2 en Java de manière à ce qu’il comble les lacunes de son prédécesseur : produire un moteur de recherche efficace qui permette d’intégrer les recherches de l’équipe et s’adapter aux évolutions de la recherche d’information. Pour parvenir à ce résultat, mon maître de stage ainsi que le créateur de Mercure, Mohand Boughanem, m’ont indiqué de ne pas m’attarder à l’analyse de Mercure1 et plutôt de baser la conception de Mercure2 sur l’état de l’art de la recherche d’information. Enfin, il m’a été demandé d’évaluer le moteur de recherche réalisé afin de démontrer son efficacité. Ce rapport présente donc une synthèse du sujet de mon stage et de sa mise en œuvre durant ces quatre mois. Dans un premier temps, je décrirai le contexte du stage au sein de l’IRIT. Dans un second temps, je présenterai le sujet, la problématique qu’il soulève et les objectifs à remplir. J’expliquerai ensuite la démarche mise en œuvre pour traiter ce sujet. Le chapitre suivant traitera du travail que j’ai réalisé, depuis les phases d’analyse jusqu’à la résolution de la problématique. Afin de valider ce travail, je présenterai alors les résultats obtenus et les perspectives d’évolution. Avant de conclure, j’achèverai ce rapport par le bilan personnel que je retire de ce stage.

6

Chapitre 2

Contexte du stage 2.1

L’IRIT

L’Institut de Recherche en Informatique de Toulouse (IRIT) est un établissement mixte de recherche. Fondé en 1990, ce laboratoire résulte du partenariat de plusieurs organismes : – le Centre National de la Recherche Scientifique (CNRS), – l’Institut National Polytechnique de Toulouse (INPT), – l’Université Toulouse 1 Capitole (UT1), – l’Université de Toulouse Le Mirail (UTM), – l’Université Paul Sabatier de Toulouse (UT3). Son personnel comporte plus de 600 membres (figure 2.1).

Figure 2.1 – Répartition du personnel de l’IRIT (source : http://www.irit.fr/, août 2010) Le personnel est reparti dans 18 équipes de recherche, structurées en sept thèmes : – analyse et synthèse de l’information, – architecture, systèmes et réseaux, – indexation et recherche d’informations, – interaction, autonomie, dialogue et coopération, – modélisation, algorithmes et calcul haute performance, – raisonnement et décision, – sûreté de développement du logiciel. 7

2.2

L’équipe SIG

J’ai intégré l’équipe « Systèmes d’Informations Généralisés » (SIG) qui s’inscrit dans la thématique « indexation et recherche d’informations » et dont le responsable est le professeur Claude Chrisment. Les recherches menées au sein cette équipe s’articulent autour du concept de base d’informations. Les travaux se focalisent sur : – les modèles de représentation abstraite de collections d’informations complexes, – les modèles d’interrogation de collections, – et ceux destinés à la manipulation et à l’exploration visuelle de grandes collections. L’équipe est composée de 24 membres titulaires, maîtres de conférences et professeurs, ainsi que de 51 membres non titulaires, master, doctorants, post-doctorants, invités et contractuels (ces chiffres ont été recueillis au début du mois d’août 2010). De nombreux chercheurs de l’IRIT axent leur recherches sur le vaste domaine des systèmes d’informations. Aussi, les recherches de l’équipe sont divisées en quatre composantes : – DDSS : Documents, Données Semi-Structurées et usages, – ED : Conception de systèmes d’informations décisionnels, – EVI : Exploration et Visualisation d’Information, – RFI : Modèles adaptatifs pour la recherche d’information. Mon stage s’est inscrit plus particulièrement dans la composante RFI qui a pour responsable le professeur Mohand Boughanem. Les travaux de recherche centrés sur cette thématique ont pour objectif la mise en œuvre de systèmes de recherche d’information qui reposent sur des modèles théoriques éprouvés. Ils s’appuient sur des approches théoriques et expérimentales qui prennent en considération différents facteurs. Ceux-ci sont principalement liés à l’information manipulée et à son contexte. C’est un maître de conférences effectuant des travaux de recherche dans cette thématique, Guillaume Cabanac 1 , qui m’a donné l’opportunité de réaliser ce stage et qui a encadré mon travail en tant que maître de stage. J’ai disposé d’un certains nombre de moyens fournis par l’IRIT à ses personnels. Ceux-ci font l’objet de la section suivante.

1. http://www.irit.fr/~Guillaume.Cabanac/

page 8 sur 34

2.3

Moyens mis à disposition

Les personnels de l’IRIT, titulaires ou non titulaires (comme c’était mon cas), disposent d’un compte pour se connecter aux ordinateurs du parc informatique. De plus, ils ont accès à un intranet offrant un service de messagerie et d’un accès au réseau Wi-Fi pour les ordinateurs individuels. L’équipe SIG dispose de deux salles informatiques dédiées (figure 2.2), équipées d’ordinateurs Linux et Windows ainsi que de deux imprimantes laser. Il est par ailleurs possible d’accéder aux comptes Linux depuis l’extérieur du réseau à l’aide des protocoles SSH et FTP.

Figure 2.2 – Étudiants travaillant dans une salle machine de l’équipe SIG L’IRIT comprend un service de documentation qui propose la consultation de publications liées aux recherches qui y sont effectuées (articles, thèses) ainsi que de nombreux ouvrages traitant des aspects théoriques et pratiques de l’informatique. De plus, l’université Paul Sabatier, dont dépend l’IRIT, est abonnée à des bibliothèques de publications en ligne telles que IEEE 2 et Springer 3 . La consultation des contenus proposés par ces sites est donc possible à partir des réseaux Ethernet et Wi-Fi de l’IRIT. En outre, les membres de la composante RFI ont accès à une plate-forme destinée à la recherche d’information et à l’indexation multimédia : Osirim 4 . C’est un groupe de serveurs (ou cluster) qui propose à la fois des fonctionnalités de stockage et de calcul. Le stockage est assuré par une baie de disques pour une capacité totale de 400 téra-octets. La fonctionnalité de calcul est, quant à elle, permise par 8 serveurs disposant de deux processeurs bi-cœur chacun, pour un total de 32 cœurs de processeur. Osirim offre un ordonnanceur afin d’assurer la gestion des tâches soumises par les utilisateurs.

2. http://ieeexplore.ieee.org 3. http://www.springerlink.com/ 4. https://osirim.irit.fr/

page 9 sur 34

Chapitre 3

Présentation du sujet 3.1 3.1.1

Concepts nécessaires à la compréhension du sujet Principe général d’un moteur de recherche

Mon stage implique le développement d’un moteur de recherche, aussi apparaît-il pertinent d’en présenter ici certains concepts fondamentaux [CMS09]. Le développement de l’informatique a conduit à la création de nombreux supports pour l’information. On admettra qu’il est impossible pour un individu d’organiser l’information et donc de chercher manuellement une information particulière lorsque la quantité d’information disponible dépasse un certain seuil. Pour répondre à ce problème, des outils informatiques qui automatisent cette tâche, appelés moteurs de recherche, ont été développés. Leur utilisation s’illustre par exemple sur internet, où des pages web sont créées continuellement et forment une masse d’information. Les individus qui cherchent une information spécifique sur internet sans connaître son emplacement font appel à un moteur de recherche tel que Google 5 . Internet est donné ici à titre d’exemple mais il existe de nombreux autres supports d’information, textuels ou multimédia, qui font l’objet de développement de moteurs de recherche qui leur sont propres. Une première problématique est soulevée pour le développement d’un moteur de recherche : « Comment le programme connaît-il la nature et l’emplacement de l’information ? ». Afin de répondre à ce problème, le moteur de recherche doit traiter l’ensemble de l’information disponible dans un processus appelé indexation. Ce processus recense l’information et sa localisation sous la forme d’un index dont le principe est semblable à celui de l’index d’un livre : pour un mot donné, l’index permet d’accéder à la liste des documents qui le contiennent. Une fois l’information indexée, le moteur de recherche permet d’interroger l’index lorsqu’un utilisateur formule un besoin en information, sous la forme d’une requête, afin de restituer l’information pertinente pour cette requête. De manière naturelle, un individu sait, en lisant un document textuel par exemple, s’il correspond (et dans quelle mesure) à la requête qu’il a formulée. Le moteur de recherche doit fournir des résultats qui se rapprochent le plus possible de cette perception. La seconde problématique soulevée lors du développement d’un moteur de recherche est donc d’assurer que l’information restituée par un moteur de recherche soit pertinente du point de vue de la perception humaine.

5. http://www.google.fr/

10

3.1.2

Campagnes d’évaluation de moteurs de recherche

La recherche d’information, domaine majeur de l’informatique des systèmes d’information, fait l’objet de recherches dans les universités du monde entier. Ce domaine offre en effet de nombreuses possibilités d’avancées et d’améliorations, compte tenu notamment de l’augmentation de la masse et de la multiplication des supports de l’information (étiquettes, vidéo). De plus, les résultats des moteurs de recherches doivent être le plus pertinent possible du point de vue de la perception humaine, le processus de création de ces résultats à partir de l’index est donc sujet à de nombreuses recherches. Pour proposer des résultats, un chercheur doit franchir plusieurs étapes dans son travail de recherche : notamment l’état de l’art, le développement d’une problématique et une proposition de résolution. Cependant, pour valider les hypothèses formulées, il est nécessaire qu’elles soient vérifiées de manière expérimentale. Les débuts de la recherche dans le domaine de la recherche d’information ont donc été caractérisés par des protocoles expérimentaux issus d’initiatives non coordonnées. Ceux-ci ont cependant montré deux limites. En effet, le fait qu’ils soient développés de manière indépendante et ponctuelle ne permettait pas d’établir des comparaisons pertinentes entre les différents travaux réalisés. De plus, la quantité d’information à traiter a augmenté de manière très significative avec notamment le développement d’internet ces dernières années : pour qu’un protocole de test soit réaliste il doit se baser sur une collection de test conséquente et donc coûteuse. Il est donc apparu nécessaire de s’allier pour diminuer les efforts et les coûts de constitution des collections de test et fournir les outils et mesures permettant le classement et la comparaison des moteurs de recherche. C’est dans cet objectif qu’a été crée le cadre d’évaluation « Text REtrieval Conference» (TREC) 6 [VH05] en 1992. Depuis sa création, TREC fait l’objet de conférences annuelles où sont proposées de grandes collections de documents ainsi que le moyen d’évaluer les résultats des différents moteurs de recherche appliqués à ces collections. D’autres cadres d’évaluation ont vu le jour mais ne seront pas étudiés ici.

3.2

Problématique

Dans les années 1990, l’équipe SIG de l’IRIT a développé un moteur de recherche d’information textuelle : Mercure. L’objectif de ce programme est de servir de support d’expérimentation des recherches effectuées au sein de l’équipe et plus précisément dans le cadre de la composante RFI. De plus, au travers de Mercure, ces recherches peuvent être soumises aux collections proposées dans le cadre des campagnes d’évaluations de TREC afin de démontrer leur pertinence. Mercure a été écrit en langage C et a subi de nombreuses modifications par diverses personnes afin de s’adapter à l’évolution rapide de la RI. Cependant, ce programme n’a pas été conçu initialement pour supporter une telle évolution et la version actuelle souffre de nombreuses limites : son efficacité s’est dégradée à cause de bogues apparus lors des maintenances successives et il ne supporte pas la mise à l’échelle nécessaire pour s’adapter à l’augmentation de la quantité d’information à traiter. La problématique est donc la suivante : spécifier, concevoir et développer une nouvelle version de Mercure adaptée à l’évolution rapide du domaine de la recherche d’information.

6. http://trec.nist.gov/

page 11 sur 34

3.3

Objectifs

Le sujet de mon stage est donc de développer une nouvelle version de Mercure : Mercure2. Les besoins fonctionnels correspondent aux fonctionnalités principales de nombreux moteurs de recherches : l’indexation d’un corpus documentaire d’une part, l’interrogation des index ainsi produits d’autre part. Il est à noter que Mercure2 ne disposera pas d’une interface graphique. En effet, son utilisation devait pouvoir être automatisée par le biais de scripts. Aussi, sa configuration se fera par l’intermédiaire d’un fichier et son exécution sera effectuée en ligne de commande. De plus, certaines contraintes fortes ont été exprimées par mon maître de stage, Guillaume Cabanac, et par Mohand Boughanem qui est à l’origine de Mercure. En effet, le développement devra être effectué en Java. De plus, cette nouvelle version de Mercure devra combler les manques de la version actuelle. Dans ce but, je devrai proposer une architecture qui offre la possibilité d’ajouter ou d’ôter des composants en limitant les modifications du code original. L’utilisation d’un langage orienté objet favorise une telle flexibilité, notamment par l’application de patrons de conception. En outre, Mercure2 devra supporter la taille croissante des collections d’évaluation des moteurs de recherche : plusieurs dizaines de téra-octets pour certaines. Cet aspect implique une contrainte physique car les données issues de telles collections ne peuvent être stockées en mémoire vive, ainsi qu’une contrainte de performance : le temps d’exécution doit être minimal. Enfin, si Mercure2 est développé pour intégrer des concepts innovants, il faudra d’abord s’assurer qu’il constitue une base robuste. C’est pourquoi il est important de s’assurer de la qualité des processus d’indexation et d’interrogation dans une configuration conventionnelle. Des moteurs de recherches développés par d’autres universités ont été évalués à l’aide de collections issues de TREC. Configuré de la même manière que ces moteurs de recherche de référence, Mercure2 devra donc offrir des résultats similaires.

page 12 sur 34

Chapitre 4

Démarche mise en œuvre 4.1

Méthodologie

Guillaume Cabanac, mon maître de stage, m’a confié comme première tâche d’étudier l’état de l’art de la recherche d’information. Cette phase préalable m’a permis d’acquérir une vue d’ensemble de ce domaine, et plus particulièrement une connaissance générale du fonctionnement des moteurs de recherche. Il est apparu qu’un moteur de recherche comprend plusieurs composants distincts et peu couplés. Ces composants font l’objet d’études spécifiques dans l’état de l’art de la recherche d’information. De plus, mon maître de stage et Mohand Boughanem, le créateur de Mercure désiraient avoir une visibilité précise sur l’avancement de mon travail. Ces raisons m’ont conduit à décider, avec l’accord de mon maître de stage, d’un cycle de développement itératif où chaque itération correspondrait à un composant de Mercure2. De nombreux articles et ouvrages détaillent la structure et les caractéristiques des moteurs de recherches, c’est pourquoi il est apparu judicieux de précéder chaque itération d’un état de l’art concernant le composant que j’allais développer. Cette phase de recherche s’est avérée proche de l’état de l’art que réalisent les chercheurs lorsqu’ils débutent leurs recherches dans un nouveau domaine. Une telle documentation m’a permis de bénéficier du travail effectué par d’autres chercheurs, travail documenté et validé par des expérimentations. Les informations ainsi recueillies ont guidé mes décisions et m’ont ainsi fait gagner du temps.

4.2

Organisation du travail

Lors de mon premier jour de stage, Guillaume Cabanac m’a proposé de choisir moi-même mes horaires, tout en respectant le temps de travail hebdomadaire prévu dans la convention. Afin de pouvoir m’entretenir facilement avec lui ainsi qu’avec Mohand Boughanem, j’ai choisi des horaires traditionnels : 9h–17h30 avec une pause pour le déjeuner. Au début du stage, mon maître de stage m’a indiqué que je pouvais avoir un entretien avec lui lorsque je jugerais cela nécessaire, pour discuter d’un problème rencontré, d’une décision à prendre ou pour présenter l’état d’avancement de mes travaux. Certains entretiens plus formels ont été organisés afin que de présenter et de discuter de mon travail avec Mohand Boughanem. De plus, afin d’avoir un suivi écrit de l’avancement de mon travail, Guillaume Cabanac m’a demandé de lui fournir un rapport hebdomadaire. Le but de ces rapports était de présenter le travail effectué, les problèmes rencontrés, les résultats obtenus ainsi que les perspectives pour la semaine suivante.

13

4.3

Planification

Après avoir réalisé l’état de l’art de la recherche d’information, j’ai pu établir une planification prévisionnelle lors du premier mois de mon stage. J’ai communiqué celle-ci à Bernard Cherbonneau, mon tuteur, dans le cadre du document de présentation du stage. À ce stade, je n’avais codé que des modules simples afin de me familiariser avec l’environnement de travail. Il s’est avéré par la suite, au commencement du second mois de stage où j’ai abordé la conception et la programmation de composants plus complexes, que certains aspects du développement de Mercure2 seraient prépondérants alors que je les avais sous-estimés et qu’à l’inverse j’en avais surestimé d’autres. De plus, des entretiens avec mon maître de stage et Mohand Boughanem m’ont permis de préciser leurs besoins. Ces raisons expliquent la création au cours du deuxième mois du stage d’une seconde planification 4.1, plus fidèle aux contraintes de développement de Mercure2. avril : Analyse préalable - État de l’art de la recherche d’information - Programmation de modules simples - Conception de l’architecture générale

juin : Interrogation - Implémentation de la lecture de l’index - Implémentation du module d’interrogation - Interrogation à partir de topics TREC

mai : Indexation - Implémentation du module d’indexation - Implémentation de l’écriture de l’index - Indexation de corpus TREC

juillet : Evaluation - Évaluation à partir de collections TREC - Optimisation et correction de bogues - Réalisation d’un tutoriel

Figure 4.1 – Planification du stage (corrigée au deuxième mois)

4.4

Outils utilisés

En ce qui concerne les techniques employées, j’ai utilisé StarUML 7 pour la conception orientée objet reposant sur les modèles UML. Pour le développement, j’ai retenu l’environnement Eclipse 8 qui est utilisé par l’équipe d’accueil et qui se révèle particulièrement adapté à la programmation Java. Mon maître de stage m’a indiqué que l’utilisation de commandes et de scripts du shell Linux me seraient utiles. Mon poste de travail possédant un système d’exploitation Windows, j’ai donc utilisé l’émulateur Cygwin 9 qui permet de bénéficier d’un environnement Linux sous Windows. De plus, mon maître de stage a mis à ma disposition un serveur de gestion de version Subversion (SVN) 10 . Ainsi, le travail effectué (notamment les programmes que j’ai développés) a été stocké sur un serveur de l’IRIT et non plus sur ma seule machine. Les gains offerts par ce service sont multiples. Dans un premier temps, il assure une sauvegarde distante des données qui permet d’éviter les pertes qu’une panne pourrait causer. De plus, un tel serveur conserve les versions successives des fichiers qui y sont stockés. Cette caractéristique permet de conserver un historique du travail effectué et d’accéder à tous les fichiers des versions antérieures. 7. 8. 9. 10.

http://staruml.sourceforge.net/ http://www.eclipse.org/ http://www.cygwin.com/ http://subversion.tigris.org/

page 14 sur 34

Chapitre 5

Travail réalisé 5.1 5.1.1

Analyse préalable Cadre d’évaluation TREC

La première partie de l’analyse préalable à la conception et à la programmation des composants de Mercure2 a concerné le cadre d’évaluation TREC. En effet, l’objectif de ce moteur de recherche et de servir de support pour l’évaluation des recherches effectuées au sein de l’équipe SIG. Il convenait donc de connaître la structure des fichiers fournis aux participants des campagnes TREC ainsi que le fonctionnement de la phase d’évaluation des moteurs de recherche. Chaque année depuis sa création, les organisateurs de la conférence TREC proposent des collections à ses participants. Une collection est composée de trois types de fichiers : – le corpus, composé de documents à indexer, – les topics, requêtes à soumettre au moteur de recherche, – les qrels, les documents jugés pertinents (par des des experts) pour les topics donnés. Les participants qui souhaitent évaluer leur moteur de recherche doivent, pour une collection donnée : 1. indexer le corpus (celui-ci est généralement découpé en plusieurs fichiers compressés), 2. soumettre au moteur de recherche l’ensemble des topics (généralement 50) fournis pour la collection, 3. comparer les résultats obtenus avec les jugements de pertinence fournis sous forme de qrels. Les deux premières étapes sont réalisées par le participant avec son moteur de recherche. Celui-ci doit fourni les résultats obtenus pour les topics donnés sous un format particulier. C’est un programme fourni par TREC, trec_eval 11 , qui effectue la comparaison des résultats du moteur de recherche avec les qrels et qui calcule une valeur reflétant la performance du moteur de recherche. Il est à noter que pour des collections possédant un corpus de plusieurs milliers ou millions de documents, il est impossible pour des assesseurs humains d’évaluer la pertinence de tous les documents pour les topics donnés et donc de créer les qrels. Aussi, TREC utilise un technique de pooling : un premier sous-ensemble de documents est créé à partir de l’union des documents ayant obtenu les meilleurs résultats avec les moteurs de recherches reconnus. Ce sous-ensemble est ensuite évalué manuellement par des assesseurs. 11. http://trec.nist.gov/trec_eval/

15

Le programme trec_eval propose des mesures qui permettent de connaître la pertinence des résultats d’un moteur de recherche. Nous ne nous intéresserons ici qu’à une seule de ces mesures, la précision moyenne : « Mean Average Precision » (MAP) car celle-ci est la plus couramment utilisée pour mesurer la pertinence des moteurs de recherche. 5.1.2

Utilisation du moteur de référence Terrier sur une collection TREC

Afin de comprendre comment devrait fonctionner Mercure2, mon maître de stage m’a conseillé d’étudier un moteur de recherche développé par l’université de Glasgow : Terrier [OLMP07]. Afin de valider les connaissances acquises précédemment, il est apparu logique de tester ce moteur de recherche à l’aide d’une collection TREC. J’ai pour cela récupéré une collection de taille moyenne, stockée sur la plateforme Osirim. J’ai pu réaliser avec succès la première étape de l’utilisation d’un moteur de recherche : l’indexation des documents du corpus. J’ai cependant eu des difficultés à effectuer la deuxième étape : l’interrogation de cet index avec une requête donnée. En effet, il semble que Terrier ait nommé les fichiers d’index de manière incorrecte. Après modification du nom de ces fichiers, l’interrogation a fonctionné correctement et le moteur de recherche a produit des fichiers de résultats. J’ai pu ensuite soumettre ces fichiers à trec_eval afin de les comparer avec les qrels de la collection et obtenir la mesure de précision moyenne. L’utilisation de Terrier s’étant révélé être un succès, j’ai ensuite entrepris de comprendre la structure interne de ce programme. J’ai donc consulté la documentation en ligne 12 fournie par l’université de Glasgow, notamment la javadoc.

5.2

Architecture prévue

Au début de mon stage, Guillaume Cabanac m’a fourni plusieurs documents de l’état de l’art de la recherche d’information [CMS09, MRS08]. La lecture de ces documents m’a permis d’entrevoir les principes généraux de la recherche d’information. En outre, j’ai pu aborder plus précisément certains aspects de l’implémentation des moteurs de recherche. Cet état de l’art auquel s’ajoute l’utilisation de Terrier m’ont permis de définir la structure de Mercure2. J’ai identifié deux étapes principales : 1. l’indexation du corpus qui conduit à la création de l’index, 2. l’interrogation de l’index avec des requêtes, fournissant à l’utilisateur les résultats correspondants. À première vue, ces deux étapes n’interviennent pas au même moment ni à la même fréquence. Afin de simplifier l’architecture du programme, j’ai décidé de séparer Mercure2 en deux programmes dont les fonctionnalités correspondent à ces deux étapes : index et retriever. J’ai cependant identifié un couplage inévitable entre ces deux programmes : – l’écriture de l’index par indexer et sa lecture par retriever dépendent tous deux du format des fichiers d’index, – l’extraction des mots des documents par index et l’extraction des termes de la requête par retriever doivent être identiques pour permettre la comparaison des termes. Dans l’architecture proposée, j’ai donc extrait des deux programmes les fonctionnalités correspondant à la lecture/écriture de l’index et celles correspondant à l’extraction des termes. Ces fonctionnalités ont donc été réunies pour former deux API : storage et term. 12. http://terrier.org/docs/v3.0/

page 16 sur 34

5.3

Développement de l’API term

Comme j’ai pu le constater lors des phases d’analyses préalables, les collections TREC que Mercure2 allait devoir indexer comportent des documents issus du web. Il est donc apparu nécessaire, en vue du développement de l’API term, d’étudier les différentes possibilités qui permettent d’interpréter les documents HTML afin d’en extraire le contenu textuel. 5.3.1

Parseurs XML et expressions régulières

Dans un premier temps, j’ai voulu tirer profit des nombreuses API Java dédiées à la lecture de documents XML [ABC05]. Je me suis orienté vers ces API car il existe de nombreuses similitude entre HTML et XML. De plus, les normes du W3C 13 préconisent, pour le développement de sites web, l’utilisation du format XHTML qui est un sous ensemble de XML. J’ai donc entrepris d’utiliser l’API DOM [CPS10]. Celle-ci propose un accès hiérarchique à l’information contenu dans un fichier XML. Mon maître de stage m’a découragé d’utiliser DOM car celui-ci nécessite le chargement du document en entier avant de pouvoir en lire le contenu, ce qui est coûteux en mémoire. Il m’a orienté vers une autre API nommée SAX. SAX propose un traitement des documents XML de manière événementielle : à chaque objet du fichier XML (balises, attributs, entités, contenu textuel) lu, un événement correspondant est notifié. L’utilisateur peut ensuite définir l’action effectuée lors de l’apparition de cet évènement. Cette API ne conserve donc pas en mémoire les documents XML, elle ne fait que le parcourir. J’ai donc entrepris de développer la fonction d’extraction du contenu textuel des documents issus de TREC. Cependant, ces documents HTML issus de la «vie réelle» ne sont pas toujours bien formés. Or, les API de lecture de documents XML sont très strictes et interrompent le traitement dès qu’un élément mal formé est rencontré. Pour contourner ce problème, j’ai trouvé des programmes qui reformatent le XML mal formé. Si cette démarche a fonctionné, elle s’est révélée toutefois peu viable : le temps nécessaire pour extraire le contenu des documents TREC était multiplié par trois, pour la lecture de millions de documents, un tel ralentissement n’est pas acceptable. Face à l’échec de l’utilisation des parseurs XML, j’ai envisagé un tout autre outil afin d’interpréter les documents HTML issus de TREC : les expressions régulières [Des01]. Issues de la théorie des langages formels, les expressions régulières sont des chaînes de caractères qui décrivent un motif, un enchaînement de caractères. Un tel motif permet de reconnaître par exemple les balises ouvrantes et fermantes dans un document HTML. J’ai donc conçu des motifs reconnaissant les balises HTML afin de n’en conserver que le contenu textuel. Cependant, l’implémentation Java des expressions régulières a semblé ne pas supporter des documents de taille importante. Après plusieurs tentatives infructueuses lors de la lecture de documents HTML volumineux, j’ai abandonné l’utilisation des expressions régulières. 5.3.2

Parseur dédié au HTML

C’est finalement grâce à mon maître de stage que j’ai résolu ce problème. En effet, il m’a donné un prototype qu’il avait développé dans le cadre de recherches nécessitant l’indexation à la volée de pages web dans un navigateur internet. Afin d’extraire le contenu textuel des pages XHTML consultées, c’est un parseur dédié au XHTML qui avait été utilisé, provenant du paquetage HTMLEditorKit de la librairie Swing de Java. L’avantage d’un tel analyseur syntaxique, reposant sur un modèle événementiel comme SAX, c’est qu’il est adapté au traitement spécifique des fichiers HTML et supporte les éléments mal formés. 13. http://www.w3.org/

page 17 sur 34

5.4

Développement de l’API storage

Une fois l’API term développée, il était nécessaire de développer l’API storage pour envisager l’indexation d’un corpus. 5.4.1

Berkeley DB

Si le moteur de recherche Terrier utilise des fichiers binaires adhoc pour le stockage de son index, un tel procédé nécessite l’implémentation des mécanismes d’accès direct permettant une lecture efficace des fichiers. En effet, un accès séquentiel provoquerait une quantité trop importante de lectures disques qui sont très coûteuses en temps d’exécution car beaucoup plus lentes que les calculs du processeur. Après la présentation de ces informations à mon maître de stage, nous avons conclu qu’il était raisonnable de rechercher des supports de stockage qui permettraient la création d’un index plus aisée et flexible qu’avec les fichiers binaires. Parallèlement au développement de l’API term, j’ai commencé à développer indexer. Dans ce programme, j’ai employé les Map Java pour le stockage temporaire en mémoire des index lors de leur construction, c’est donc logiquement une API permettant le stockage de Map Java sur le disque que j’ai recherchée. C’est finalement un base de données bas niveau qui a retenu mon attention : Berkeley DB 14 . Proposée par l’éditeur de logiciels Oracle, Berkeley DB a comme caractéristique principale de ne pas proposer un langage d’interrogation tel que le SQL : les données sont traitées sous la forme de couples (clé,valeur) de la même manière que les sont les Map Java. Si la version originale de Berkeley DB est destinée au langage C, il existe une API appelée Berkeley DB JE 15 qui est dédiée au Java. Celle-ci ne nécessite aucune gestion de base de donnée extérieure : les processus qui y sont liés sont exécutés conjointement au programme. De plus, Berkeley DB JE propose une API nommée Collections qui propose des structures stockées sur le disque et implémentant l’interface Map de Java, satisfaisant donc pleinement les critères retenus pour la recherche d’un nouveau format de stockage. Enfin, Berkeley DB JE permet la création automatique d’index secondaires, assurant ainsi la création de l’index inverse de Mercure2. J’ai suivi les tutoriels proposés afin de comprendre le fonctionnement de l’API Collections. Une fois les bases acquises, j’ai entrepris la création des structures de données permettant le stockage des fichiers d’index de Mercure2 avec cette API. Enfin, j’ai procédé à l’intégration de ces structures au programme existant, facilitée par le fait que le comportement des Map de Berkeley DB JE est identique à celui des Map Java que j’utilisais jusque là. Les premiers tests ont été concluants : j’ai pu construire les index correspondant à un petit nombre de documents et les interroger avec succès. J’ai logiquement procédé à un test à plus grande échelle sur 10 000 fichiers d’une collection Quaero. Deux problèmes critiques sont apparus : l’indexation est lente (plus de 20 minutes dans ce test) et les fichiers produits par Berkeley DB JE sont très volumineux (15 fois la taille du corpus indexé). L’objectif de Mercure2 étant d’indexer des collections comprenant des millions de fichiers, les problèmes identifiés sont bloquants. Cependant, la flexibilité permise par Berkeley DB JE est un réel atout, j’ai donc cherché comment améliorer ses performances afin de ne pas abandonner son utilisation. J’ai consulté en détail la Javadoc fournie avec l’API Collections et, en modifiant des éléments de configuration, je suis parvenu à une légère amélioration, toutefois insuffisante. Après de nombreuses tentatives peu fructueuses, je me suis résolu à 14. http://www.oracle.com/technology/products/berkeley-db/index.html 15. http://www.oracle.com/database/berkeley-db/je/index.html

page 18 sur 34

contacter la communauté internationale des utilisateurs de Berkeley DB JE. J’ai ainsi obtenu l’aide d’utilisateurs expérimentés qui m’ont donné des indications pour mieux configurer cette base de données. J’ai appliqué ces conseils et j’ai finalement réduit par deux le temps d’exécution et par trois la taille des fichiers produits. Malgré ces améliorations, les fichiers produits demeurent très volumineux et le temps d’indexation élevé. Afin d’analyser pertinemment cette tendance, j’ai étudié l’état de l’art des moteurs de recherches concurrents. Pour cela, je me suis appuyé entre autres sur les chiffres annoncés sur le site internet de Terrier 16 [OLMP07] et sur un article de recherche consacré à la comparaison des moteurs de recherches open-source [MBY07]. Il est apparu que l’index produit par un moteur de recherche a une taille moyenne comprise entre 50 % et 150 % de la taille des documents indexés contre 500% pour les index obtenus avec Berkeley DB JE. Quant à la vitesse d’indexation, elle est de 10 à 20 min par Go indexé pour les moteurs de l’état de l’art contre 1h30 par Go pour Mercure2. Cette analyse a donc confirmé les mauvaises performances de Berkeley DB JE en termes de taille des index et temps d’indexation. Suite à la présentation de ces résultats à mon maître de stage, il est apparu que ces facteurs sont secondaires dans les performance de Mercure2. En effet, L’IRIT dispose de supports de stockage importants qui pourraient contenir des index volumineux. De plus, la majorité des recherches portent sur l’interrogation des données des index et non sur leur création. Ceci implique que l’indexation sera effectuée rarement et qu’un temps d’indexation élevé pourrait ne pas être bloquant. En revanche, la vitesse d’interrogation est elle un facteur significatif et semblait satisfaisante avec Berkeley DB JE. Si les mauvaises performances portent sur des facteurs peu significatifs, les expérimentations effectuées ainsi que les témoignages recueillis, notamment auprès de Mohand Boughanem, convergent et semblent indiquer que les bases de données ne sont pas adaptées au stockage des index d’un moteur de recherche. Avec l’accord de mon maître de stage, j’ai donc abandonné l’utilisation de Berkeley DB JE. Afin de remplacer cette technologie, nous avons convenu que les fichiers binaires ad hoc, largement utilisés et documentés dans l’état de l’art, semblaient être adaptés au stockage des fichiers d’index de Mercure2. 5.4.2

Fichiers binaires adhoc

Après avoir fait l’état de l’art de l’indexation sous la forme de fichier binaires, j’ai défini la structure des index de Mercure2. Un index est composé de quatre fichiers distincts : – le fichier dictionnaire, comportant tous les termes apparaissant au moins une fois dans le corpus, trié par ordre alphabétique des termes, – le fichier index inversé, comportant pour chaque terme la liste identifiants des documents où il apparaît et le nombre de fois qu’il y apparaît, – le fichier documents qui associe à chaque identifiant de document le nom du document, – le fichier propriétés qui recense des statistiques générales sur l’index, notamment le nombre d’entrées des fichiers précédents. Afin de me familiariser avec l’utilisation de fichiers binaires, j’ai tout d’abord implémenté l’accès direct au fichier documents qui indexe, pour chaque identifiant de document généré dans Mercure2, le nom du fichier associé. Les idDoc sont générés séquentiellement et les couples (idDoc, nomDoc) sont triés selon les idDoc. Une fonction de hachage qui associe à chaque idDoc une adresse dans le fichier permet d’accéder directement au nom d’un document à partir de son identifiant. J’ai implémenté avec succès cette fonction de hachage et l’accès 16. http://terrier.org/docs/v3.0/trec_examples.html

page 19 sur 34

au fichier à l’aide de la classe RandomAccessFile. Le second, l’index inversé, mémorise les postings pour chaque terme : les couples (idDoc,nbOcc) où idDoc est l’identifiant d’un document et nbOcc le nombre d’occurrences d’un terme dans ce document. Le fichier dictionnaire ou lexicon associe à chaque terme indexé le décalage nécessaire pour obtenir les postings correspondants dans l’index inversé. Ces accès directs permettent, pour un terme du dictionnaire donné, la lecture de l’identifiant du document, du nombre d’occurrences du terme dans ce document puis du nom du fichier correspondant au document avec un nombre minimum d’accès disque. Néanmoins, la lecture du dictionnaire était jusque là séquentielle et donc, elle, couteuse en accès disques. J’ai donc entrepris d’étudier les moyens pour accéder, pour un terme donné, à l’entrée correspondante dans le fichier dictionnaire avec un minimum d’accès disques. Dans un premier temps, j’ai envisagé l’implémentation du dictionnaire sous forme de fichier haché. Ceci aurait impliqué d’utiliser une fonction de hachage qui aurait associé à chacun des T termes un nombre unique compris entre 0 et T − 1. Muni de cette fonction et connaissant la taille d’une entrée du dictionnaire, on aurait pu ainsi obtenir l’adresse où lire l’entrée correspondant à un terme. Cependant, une telle fonction de hachage, dite «parfaite» n’est possible que si le jeu de valeurs est connu à l’avance. Sinon, il faut mettre en place une stratégie visant à gérer les collisions : les cas où la fonction peut fournir, pour deux valeurs distinctes en entrée, la même valeur de sortie. Cette solution aurait nécessité une organisation complexe du fichier dictionnaire, j’ai donc cherché une approche plus simple. C’est finalement la recherche dichotomique qui a attiré mon attention car elle porte sur des données triées, or le dictionnaire est trié selon l’ordre alphabétique des termes. Le principe de cette recherche est récursif. Elle est effectuée tant que la valeur n’est pas trouvée et que la liste des valeurs examinée n’est pas vide. La liste des valeurs triées est séparée en deux listes par le milieu. L’algorithme détermine si la valeur cherchée est dans la première ou la seconde moitié par une comparaison avec l’élément médian. La sous-liste ainsi déterminée est à son tour divisée selon le même principe. Une telle recherche offre une complexité logarithmique O(log2 (n)), ce qui signifie que le nombre d’opérations nécessaires pour accéder à une valeur parmi un jeu de valeur grandit d’autant plus faiblement que le nombre de ces valeurs augmente. Cette méthode de recherche nécessite donc beaucoup moins d’accès disques que la recherche séquentielle dont la complexité est linéaire : O(n). J’ai implémenté et testé avec succès l’accès au dictionnaire à l’aide de la recherche dichotomique. Enfin, afin d’améliorer encore les performances en écriture et lecture de fichiers, j’ai maximisé l’utilisation de tampons d’octets en mémoire (classe ByteBuffer du paquetage nio de Java).

5.5

Indexation

Une fois les API term et storage développées, j’avais en main les outils nécessaires à l’indexation d’un corpus documentaire. Cependant, l’indexation repose sur une étape clé : le stockage en mémoire du dictionnaire et de l’index au fur et à mesure de leur création. Lors de la phase de teste, si indexer est parvenu à indexer correctement un corpus de quelques centaines de documents TREC, au delà d’un certain seuil la mémoire est saturée et l’indexation échoue. J’avais identifié ce problème avant qu’il ne survienne grâce à l’état de l’art qui met l’accent sur les différentes manières d’indexer une collection, et plus particulièrement sur leur limites. À partir de ces informations, j’ai décidé d’ajouter un programme à l’architecture de Mercure2 : merger. Celui-ci a pour fonction de fusionner deux index (composés chacun des quatre fichiers précédemment décrits) pour en former un seul qui réunisse de manière cohérente les page 20 sur 34

informations des deux autres. J’ai donc entamé le développement de ce programme, en me reposant notamment sur l’API storage pour la lecture des deux index en entrée et l’écriture de l’index en sortie. J’ai ainsi pu résoudre le problème de la mise à l’échelle de l’indexation. L’indexation d’une grande collection est donc possible par l’utilisation répétée du programme indexer puis par l’utilisation de la fusion binaire de merger jusqu’à obtenir un seul fichier d’index. De plus, une telle approche présente un avantage de taille : le corpus est indexé par morceaux de manière indépendante. Ainsi, il est possible de lancer en parallèle plusieurs instances d’indexer qui indexent chacune une partie du corpus, permettant un gain de temps considérable. J’ai pu tester une telle parallélisation sur le cluster Osirim, en lançant une instance d’indexer sur chaque nœud du cluster.

5.6

Interrogation

Une fois l’index créé, j’ai pris en charge la seconde fonctionnalité de Mercure2 : l’interrogation de l’index. La première partie de l’interrogation consiste à lire les topics, ou requêtes, données en entrée du programme retriever. Les requêtes sont ensuite décomposées en termes grâce à l’API term. La lecture de l’index à l’aide de l’API storage permet d’obtenir, pour un terme donné de la requête, la liste des noms des documents qui le contiennent et le nombre de fois où il apparaît dans chacun d’eux. Un tri selon le nombre d’occurrences permet d’obtenir les documents où le terme apparaît le plus. Pour traiter une requête comportant plusieurs termes, on pourrait de même fournir à l’utilisateur les documents qui ont le nombre maximum d’occurrences de ces termes. Cependant, une telle approche est limitée. En effet, supposons qu’une requête comporte un terme t1 qui se trouve dans de nombreux documents et un autre terme t2 qui est au contraire très rare. Dans ce cas, pour un document d, le même poids sera donné au nombre d’occurrences nbOcc(t1 , d) et nbOcc(t2 , d) alors que la présence de t2 dans un document est beaucoup plus significative de son adéquation à la requête que la présence de t1 . Afin de pondérer le nombre d’occurrences d’un terme en fonction de sa rareté, on peut calculer le tf ·idf [MRS08]. Ce score résulte de la multiplication de la fréquence du terme tf (t, d) par l’inverse de sa fréquence d’apparition dans les documents idf (t). La fréquence du terme tf (t, d) correspond au nombre d’occurrences de ce terme dans un document : nbOcc(t, d). La fonction logarithme est utilisée afin de modérer l’idf (t) afin que la fréquence d’apparition du terme dans un document ait plus d’influence sur le score obtenu que la rareté de ce terme. L’idf (t) est calculé ainsi : idf (t) = log2

|D| |{d ∈ D|t ∈ d}|

!

(5.1)

où – |D| est le nombre total de documents dans le corpus D, – |{d ∈ D|t ∈ d}| est le nombre de documents de D où le terme t apparaît. Le nombre de documents où chaque terme apparaît est renseigné dans le dictionnaire, le nombre total de documents est enregistré dans un fichier de propriétés et le nombre d’occurrences des termes dans les documents est inscrit dans les postings de l’index inversé. J’ai ainsi pu implémenter le calcul du tf · idf qui permet d’établir un score plus pertinent que le page 21 sur 34

nombre d’occurrences et donc un classement des résultats plus pertinent. Un tel calcul est suffisant pour répondre à une requête qui comprend un seul terme. Une requête qui contient plusieurs termes requiert, elle, un modèle qui traite les résultats obtenus pour chacun des termes afin de fournir à l’utilisateur les documents les plus pertinents pour l’ensemble de la requête. L’état de l’art présente des modèles qui ont démontré leur efficacité lors des campagnes d’évaluation TREC. Aussi, j’ai implémenté un modèle, reposant sur la théorie mathématique des probabilités, qui est largement utilisé par les moteurs de recherche : Okapi BM25 5.1 [VH05]. J’ai ainsi achevé le développement du programme merger, dernier maillon de la chaîne du moteur de recherche Mercure2. score(d, Q) =

n X i=1

 idf (qi ) ·



tf (qi , d) · (k1 + 1) 

tf (qi , d) + k1 · 1 − b + b ·

|d| avgdl



(5.2)

où – d est un document du corpus comprenant |d| termes, – Q est une requête de n termes {q1 , q2 , ..., qn }, – avgdl est nombre moyen de termes des documents du corpus, – k1 et b sont des paramètres libres. Figure 5.1 – Formule du modèle de pondération Okapi BM25

5.7 5.7.1

Activités annexes Collaboration avec un doctorant

En marge du développement de Mercure, mon maître de stage m’a chargé de développer des programmes de traitement de fichiers HTML pour Malik Missen, doctorant de l’équipe SIG. J’ai dans un premier temps développé deux programmes, l’un permettant de supprimer certaines balises HTML et du contenu indésirable tout en conservant d’autres contenus, l’autre assurant l’identification et le formatage de documents en phrases. J’ai pour cela abordé et mis en œuvre de nombreux aspects du traitement de fichiers textuels et XML, notamment les expressions régulières, DOM et SAX. Dans un second temps, Malik m’a demandé de réunir ces programmes dans un programme de traitement par lot. Celui-ci doit traiter des documents issus des collections TRECBLOG 17 , version de TREC dont le corpus est constitué de pages web issues de blogs. Dans cette collection TREC, les documents sont réunis, par groupe de 1000, dans des fichiers appelés permalink, archivés à l’aide de gzip 18 . Le programme prend en paramètre une liste de documents à extraire, décompresse les permalink correspondants à la volée et traite les documents voulus. J’ai testé le programme développé, documenté à l’aide de Javadoc et j’ai procédé à sa démonstration et recette auprès de Malik Missen. Celui-ci m’a aussi chargé de réaliser une étude comparative de programmes d’identification de langue pour les documents textuels. Il est à noter que Malik Missen est d’origine pakistanaise, aussi, il m’a demandé de m’entretenir avec lui en anglais, langue qu’il comprend mieux que le français. J’ai donc communiqué 17. http://ir.dcs.gla.ac.uk/wiki/TREC-BLOG/ 18. http://www.gzip.org/

page 22 sur 34

avec lui et produit de la documentation exclusivement en langue anglaise lors des tâches précédemment décrites. 5.7.2

Participation à PIVasse

Mon maître de stage m’a soumis un article [PCSH10] portant sur un sujet de recherche qui l’accapare actuellement : la recherche d’information géographique et son évaluation. La recherche d’information géographique mêle les dimensions spatiale, temporelle et thématique, contrairement à la recherche d’information généraliste qui ne porte que sur la dimension thématique des documents. Dans le contexte de la création d’un cadre d’évaluation pour les moteurs de recherche d’information géographique et dans le cadre du projet PIV « Pyrénées Itinéraires Virtuels » [LL06], j’ai été mis à contribution en tant qu’assesseur. J’ai donc évalué, à deux reprises, la pertinence de 300 documents du corpus du cadre d’évaluation sur un topic donné. Afin de l’évaluer, la pertinence est décomposée en pertinence spatiale, temporelle, thématique et globale. Une telle évaluation manuelle des documents permet la création de fichiers qrels qui serviront de base pour évaluer les runs 19 des moteurs de recherche. Les résultats obtenus à partir de ce cadre d’évaluation ont été présentés avec succès lors du congrès INFORSID 2010 20 . 5.7.3

Utilisation de LaTeX

Au début du stage, Guillaume Cabanac m’a proposé d’écrire mes rapports hebdomadaires sous la forme de documents LaTeX, largement utilisés dans le domaine de la recherche scientifique. LaTeX est un logiciel de composition de documents qui sépare la structure logique du document de son contenu. Mon maître de stage m’a conseillé la suite logicielle MikTeX 21 qui comprend un éditeur de texte, un compilateur LaTeX ainsi qu’un gestionnaire de téléchargement de paquets. L’utilisation d’un tel logiciel et du langage de programmation nécessite un apprentissage, notamment des mots du langages qui permettent de structurer les documents. Après quelques difficultés, j’ai finalement pris en main l’écriture de documents LaTeX c’est pourquoi le présent rapport a été écrit grâce à ce langage. 5.7.4

Réalisation d’un tutoriel

Mohand Boughanem m’a demandé de réaliser un tutoriel explicatif permettant aux futurs utilisateurs de Mercure2 de prendre en main rapidement ce programme afin d’y intégrer leurs travaux et de procéder à des expérimentations. J’ai choisi le format HTML pour créer ce tutoriel, ce qui m’a permis d’intégrer des hyperliens vers la javadoc générée à partir du code source de Mercure2. Ce tutoriel présente l’architecture générale de Mercure2, la structure des fichiers que ce moteur de recherche utilise ainsi que le détail de l’utilisation des sous-programmes et API qui le composent. De plus, j’y ai présenté un inventaire de bogues non bloquants que j’ai identifiés à la fin du stage, ainsi que d’améliorations auxquelles je n’ai pas pu procéder par manque de temps.

19. Liste des documents restitués pour chaque topic et classés par pertinence 20. http://www.lsis.org/inforsid/ 21. http://miktex.org/

page 23 sur 34

Chapitre 6

Résultats obtenus 6.1

Apport du travail réalisé

6.1.1

Évaluation du travail réalisé

Afin de mesurer l’apport de cette nouvelle version de Mercure, la suite logique au développement de Mercure2 est l’indexation des collections issues de TREC. J’ai donc demandé à Mohand Boughanem de m’indiquer les collections qu’il avait utilisées pour évaluer Mercure1, afin d’avoir une base de comparaison pour Mercure2. Celui-ci m’a communiqué trois collections : WT10G, GOV et TERABYTE (tableau 6.1). Celles-ci sont toutes les trois composées d’un corpus de pages web extraites d’internet, cependant la taille de ces corpus est significativement différente ce qui m’a permis de tester progressivement la capacité de Mercure2 à fonctionner avec une grande collection. Collections

Taille (Go) Nombre de documents Conférences TREC (année)

WT10G

GOV

TERABYTE

10 1 692 096 2000–2001

18 1 247 753 2002–2003

426 25 205 179 2004 – 2006

Table 6.1 – Caractéristiques des collections TREC utilisées La première étape pour l’évaluation de Mercure2 était de le configurer de manière pertinente. S’il était intéressant de comparer Mercure2 à son prédécesseur, il était aussi pertinent de le comparer avec un moteur de recherche de référence : Terrier. Le site internet de ce moteur de recherche présente des statistiques recueillies lors de l’indexation de collections TREC 22 , notamment les trois que m’a indiqué Mohand Boughanem. J’ai donc configuré Mercure2 de la même manière que l’était Mercure2 pour ces évaluations, en utilisant notamment le même modèle de pondération : Okapi BM25. J’ai ensuite pu entamé l’indexation de la plus petite des trois collections : WT10G. Afin de minimiser le temps d’exécution, j’ai généré des scripts lançant des instances du programme indexer en parallèle. L’indexation s’est déroulée sans erreur, cependant le seul moyen de s’assurer que l’index généré était de bonne qualité était d’interroger cet index avec des requêtes TREC : les topics, à l’aide du programme retriever de Mercure2. Ce phase s’est elle aussi déroulée sans accroc. J’ai finalement utilisé le programme fourni par TREC pour l’évaluation des moteurs de recherche : trec_eval. Celui-ci m’a permis de comparer les résultats obtenus 22. http://terrier.org/docs/v3.0/trec_examples.html

24

avec Mercure2 avec les résultats types représentés par les qrels TREC. J’ai procédé au même protocole d’évaluation pour les collections GOV puis TERABYTE. 6.1.2

Analyse des résultats

L’objectif de la phase d’évaluation de Mercure2 était double : démontrer l’apport qu’il présente par rapport à son prédécesseur d’une part, comparer ses performances avec celles d’un moteur de recherche de référence d’autre part. Avant d’entamer une analyse plus poussée, il convient de remarquer qu’il n’a jamais été possible d’indexer la collection TERABYTE avec Mercure1. En effet, la taille très importante de celle-ci (23 fois plus grande que GOV) avait montré les limites de la mise à l’échelle de ce moteur de recherche par l’apparition de nombreux bogues bloquants. Sur ce premier aspect, Mercure2 s’est comporté correctement malgré la taille des fichiers traités (l’index correspondant à TERABYTE pèse 45 Go) et a donc surpassé son prédécesseur. J’ai recueilli des statistiques lors de l’indexation des trois collections TREC afin d’analyser les performances de Mercure2 (tableau 6.2). Le temps d’indexation a été satisfaisant : du même ordre de grandeur que les chiffres annoncés sur le site de Terrier. Sur cet aspect encore, Mercure2 dépasse Mercure1 qui présentait des temps d’indexation 10 fois supérieurs. Enfin, la taille de l’index est de l’ordre de 15% de la taille de la collection, ce qui correspond aux informations que j’avais recueillies dans l’état de l’art des moteurs de recherche. Collections

Temps d’indexation Taille de l’index (Go) Taille de l’index (entrées) Taille moyenne des docs (termes)

WT10G

GOV

TERABYTE

1h10 2,8 273 136 465 372

0h40 2,9 279 081 501 679

20h 45 4 589 822 062 589

Table 6.2 – Statistiques d’indexation des collections C’est finalement l’évaluation des résultats de Mercure2 avec trec_eval qui a donné le plus d’indications sur la qualité de ce moteur de recherche. J’ai utilisé la mesure MAP, moyenne des précisions obtenues, qui est réputée dans l’état de l’art pour sa représentation efficace de la pertinence des résultats du moteur de recherche. C’est aussi la mesure qui est présentée sur le site internet de Terrier, me permettant une comparaison. Le tableau 6.3 présente donc la comparaison de l’évaluation de Mercure2 avec celles de Mercure1 et Terrier. Ces résultats nous renseignent sur deux points. D’une part, Mercure2 présente des résultats significativement meilleurs que ceux de Mercure1. En effet, plus la MAP est importante, plus le moteur de recherche est pertinent, or les MAP obtenues par la version que j’ai développé est de 15 à 30% plus importante que celle de son prédécesseur. En outre, les MAP de Mercure2 se rapprochent de celles présentées pour Terrier, de 3% moins importante pour WT10G, à 0,7% plus grande pour GOV, différences peu significatives. L’analyse des résultats a donc démontré les apports présentés par Mercure2 en comparaison avec son prédécesseur, et nous a de plus informé que ce programme présente des qualités comparables à celles des moteurs de recherche de référence.

page 25 sur 34

Moteurs de recherche Collection

Mercure1

Mercure2

Terrier

0,1438 0,1645 N/A

0,2043 0,1923 0,3024

0,2104 0,1910 0,3046

WT10G GOV TERABYTE

Table 6.3 – Comparaisons des résultats de l’évaluation des moteurs de recherches

6.2

Perspectives d’évolution

La raison d’être de Mercure2 est qu’il évolue par l’intégration du travail d’étudiants, doctorants et chercheurs de l’équipe SIG. Les résultats obtenus par Mercure2 dans une configuration donne une base forte qui permettra de mesurer précisément les apports du travail de ses futurs utilisateurs. L’état de l’art de la recherche d’information présente de très nombreuses perspectives qui permettent d’améliorer la qualité des résultats fournis par les moteurs de recherche. La collecte de données supplémentaires, de la balise HTML qui encadre un mot par exemple, permettrait de lui donner un poids plus fort s’il est compris dans une balise de titre. D’autres données permettraient de nouvelles fonctionnalités : la mémorisation de la position des mots dans les documents autoriserait des requêtes sous forme de phrase, alors que l’ordre des mots de la requête n’est pas prise en compte dans la version actuelle de Mercure2. D’autres améliorations reposent sur la manipulation de l’index. Par exemple, la reformulation de requête consiste à consulter les mots les plus fréquents dans les documents contenant les mots de la requête pour les ajouter à la requête et renforcer son poids sémantique.

page 26 sur 34

Chapitre 7

Bilan personnel 7.1

Lien avec les enseignements ISI

Le déroulement de mon stage m’a permis de réinvestir des connaissances et des compétences acquises lors de ma formation, notamment lors de ma licence 3 ISI. En premier lieu, le langage qui m’a été imposé d’utiliser pour la programmation, le Java, constitue un enseignement majeur du semestre 5 de l’IUP. J’ai ainsi mis en œuvre les mécanismes propres à ce langage objet tels que l’héritage, la redéfinition, la surcharge et l’introspection. Il est à noter que j’ai eu l’occasion d’utiliser le même environnement de développement que celui utilisé lors des cours à l’IUP : l’IDE Eclipse. De plus, une programmation orientée objet implique une conception orientée objet, aussi, j’ai utilisé la notation UML qui constitue un enseignement du semestre 6. Là aussi, j’ai utilisé le logiciel qui nous était proposé lors des travaux pratiques de ce cours : StarUML. Je n’ai cependant pas appliqué la démarche qui nous a été présentée en cours. En effet, la conception s’est appuyée sur les besoins non fonctionnels tels que la vitesse d’exécution et l’utilisation de la mémoire et du disque plutôt que sur les cas d’utilisations qui se révèlent simples dans le cadre de l’utilisation d’un moteur de recherche. Les connaissances acquises en base de données m’ont permis dans un premier temps d’utiliser Berkeley DB qui en illustre quelques principes fondamentaux. Cependant, c’est la partie du cours d’optimisation des bases de données du semestre 5 portant sur les systèmes de gestion de fichiers et sur les arbres balancés et index hachés qui m’a le plus servi. En effet, ayant abandonné l’utilisation de Berkeley DB pour ses mauvaises performances, j’ai dû mettre en œuvre un index adhoc reposant sur des fichiers binaires dont j’ai défini moi même les structures et les accès directs. Pour le traitement des fichiers XML, j’ai envisagé l’utilisation d’expressions régulières dont le principe a été abordé en cours de langages et automates du semestre 6. Cependant, si les cours présentaient la théorie des expressions régulières, j’ai dû en apprendre la syntaxe avancée dans son implémentation en Java, ce qui a nécessité un apprentissage supplémentaire. Mon maître de stage avait mis à ma disposition un serveur Subversion pour stocker mon travail. Ce système de gestion de versions nous a été présenté lors d’un cours du semestre 5, cependant c’est son utilisation lors des deux bureaux d’études qui m’a permis de m’en servir sans difficulté lors du stage. Enfin, j’ai dû acquérir de nombreuses connaissances qui n’étaient pas comprises dans l’enseignement de licence à l’IUP. En effet, le développement d’un moteur de recherche m’a conduit à étudier de manière approfondie des techniques propres à la recherche d’information. De plus, j’ai utilisé des API XML dont l’usage nous sera enseigné en master ISI. 27

7.2

Différences avec le stage précédent

J’ai réalisé mon stage précédent à l’occasion de ma deuxième année d’IUT informatique à Rangueil. J’avais décidé d’effectuer ce premier stage à l’étranger pour enrichir mes expériences et améliorer mon niveau en anglais, c’est donc logiquement l’Angleterre qui avait retenu mon intérêt. J’ai développé un site web collaboratif en PHP objet, permettant la création, la modification et la suppression d’utilisateurs et de contenu. J’ai réalisé ce stage dans le cadre du laboratoire de recherche en accessibilité de l’université de Teesside 23 dans une ville du nord-est de l’Angleterre : Middlesbrough. Il y a de nombreuses différences entre ce stage d’IUT et le stage qui fait l’objet de ce présent rapport. Premièrement, la durée de mon premier stage était de 3 mois alors que celle de celui-ci est de 4 mois. Mon premier stage s’est déroulé dans un pays étranger, j’ai donc dû m’adapter à un contexte inconnu ce qui a nécessité un certain temps. À l’opposé, le stage à l’IRIT s’est déroulé sur le campus de l’université Paul Sabatier où se situe aussi l’IUP où se déroule ma formation, ce qui m’a permis d’entrer rapidement dans le vif du sujet en limitant le temps d’adaptation. J’ai choisi mon stage d’IUP en ne prenant en compte que l’intérêt que je portais pour le sujet, j’ai donc choisi un sujet qui me plaisait vraiment. Au contraire, j’avais dû me résoudre au développement d’un site web pour mon stage d’IUT car j’avais donné priorité au fait que le stage soit à l’étranger. Aussi, mon stage en Angleterre s’est déroulé dans un laboratoire de recherche d’une université, comme mon stage d’IUP, cependant la similitude s’arrête à la terminologie. En effet, dans les faits, une université anglaise fonctionne de manière très différente d’une université française, ces dernières sont publiques alors que les premières sont des entreprises qui existent pour réaliser des bénéfices. Enfin, lors de mon stage d’IUT, j’étais dans un milieu de chercheurs ayant de faibles compétences en informatique alors que pour ce présent stage, la majorité des gens que j’ai côtoyés avaient un niveau supérieur au mien. Ce dernier point m’a permis d’engranger de nombreuses nouvelles connaissances en informatique. Il existe toutefois des similitudes entre ces deux stages, notamment le fait que j’ai dû acquérir de nombreuses compétences pour mener à bien le sujet qui m’a été proposé : lors de mon stage d’IUT j’ai dû apprendre la programmation en PHP objet par l’intermédiaire d’un framework au fonctionnement complexe (Zend) alors que lors du stage faisant l’objet de ce rapport j’ai dû intégrer de nombreux principes du domaine de la recherche d’information.

7.3

Choix du stage et implication dans le projet professionnel

La formation des IUP, et notamment celle de l’IUP ISI, a vocation de former les étudiants afin qu’ils s’adaptent au mieux à une intégration dans le monde professionnel. Aussi, la décision d’effectuer mon stage à l’IRIT peut paraître surprenante. Cette décision a pourtant résulté de nombreux facteurs. En effet, j’ignorais le fonctionnement d’un laboratoire de recherche en informatique, et donc une grande partie du métier d’enseignant chercheur. Si je me destine, et c’est cohérent avec ma formation, à un avenir professionnel dans le monde de l’entreprise, c’est un atout incontestable que de connaître les codes du monde de la recherche et notamment d’avoir appris les démarches qu’effectue un chercheur entre une idée et sa concrétisation. De plus, les systèmes d’information et notamment la recherche d’information ont toujours suscité ma curiosité, ce sujet était une très bonne occasion d’acquérir des connaissances dans ce domaine. Enfin, mon intérêt s’est porté sur ce stage car il représentait une occasion de collaborer avec des enseignants que j’ai connus lors de mes formations. 23. http://www.tees.ac.uk/

page 28 sur 34

Chapitre 8

Conclusion Ce stage a été très enrichissant, et cela dans de nombreux domaines. Tout d’abord, les résultats que j’ai obtenus, comparables à ceux produits par des moteurs de recherche de renommée internationale, ne peut que susciter mon enthousiasme et la satisfaction d’avoir accompli le travail qui m’avait été demandé. Ces résultats mis à part, le domaine de la recherche d’information suscitait fortement ma curiosité car il est au centre de l’utilisation quotidienne que je fais de mon ordinateur : internet. Aussi, j’ai pu acquérir au cours de ces quatre mois, par le développement d’un moteur de recherche complet, de nombreuses connaissances qui confirment cet intérêt pour ce domaine. Mener seul le développement d’un programme pendant quatre mois est une expérience compliquée lorsqu’on est habitué au travail de groupe dans le cadre des études. J’ai eu le sentiment de progresser de manière significative en organisation et en compétences techniques grâce à cette autonomie qui oblige à trouver seul des solutions aux problèmes rencontrés. De manière plus générale, un stage dans un laboratoire de recherche en informatique m’a permis de me confronter à la réalité du métier de chercheur. J’ai ainsi pu approcher des tâches inhérentes à la recherche telles que l’état de l’art ou la comparaison de solutions afin de trouver la plus appropriée. De plus, Guillaume Cabanac m’a fait partagé son enthousiasme pour la recherche en m’impliquant tant que possible dans les activités de l’IRIT : assister à une soutenance de thèse, discuter avec des étudiants de master de leur travail ou relire et échanger au sujet des articles avant qu’ils soient publiés dans des conférences. Pour conclure, ce stage m’a ouvert de nouveaux horizons techniques, professionnels et humains, et j’en retire donc un bilan très positif.

29

Table des figures 2.1

Répartition du personnel de l’IRIT (source : http://www.irit.fr/, août 2010)

7

2.2

Étudiants travaillant dans une salle machine de l’équipe SIG . . . . . . . . . .

9

4.1

Planification du stage (corrigée au deuxième mois) . . . . . . . . . . . . . . . . 14

5.1

Formule du modèle de pondération Okapi BM25 . . . . . . . . . . . . . . . . . 22

30

Liste des tableaux 6.1

Caractéristiques des collections TREC utilisées . . . . . . . . . . . . . . . . . . 24

6.2

Statistiques d’indexation des collections . . . . . . . . . . . . . . . . . . . . . . 25

6.3

Comparaisons des résultats de l’évaluation des moteurs de recherches . . . . . 26

31

Bibliographie [ABC05]

Accary-Barbier T. et Calabretto S. : XML : syntaxe. Dans Techniques de l’Ingenieur, chapitre H 3500, p. 1–15. août 2005. Ce document présente dans un premier temps le contexte historique qui a mené à la création du langage XML. Il détaille ensuite la syntaxe et la structure propres à XML puis celle des DTD, modèles des documents XML. Le parcours de fichiers XML via la spécification XPath, sa syntaxe et ses fonctions de base sont ensuite introduits. Enfin, les auteurs proposent une présentation de XSL-T, langage de feuille de style qui permet la transformation l’arbre XML pour produire un résultat en fonction de règles données.

[CMS09]

Croft B., Metzler D. et Strohman T. : Search Engines : Information Retrieval in Practice. Addison-Wesley Publishing Company, USA, 2009. Cet ouvrage présente un état de l’art détaillé des moteurs de recherche. Les auteurs présentent les principes théoriques et pratiques des différents processus impliqués dans l’utilisation d’un moteur de recherche. Les explications vont des principes fondamentaux de la recherche d’information aux détails des problèmes rencontrés lors de l’implémentation de composants spécifiques. Aussi, cet ouvrage détaille les étapes qui, depuis l’indexation d’un corpus documentaire, permettent à la production des résultats pour une requête donnée. Les explications fournies par les auteurs sont accompagnées d’exemples simples qui les illustrent.

[CPS10]

Chevalier M. et Pinel-Sauvagnat K. : XML et interopérabilité des systèmes : Applications en Java 1.5 et PHP 5.0. Dans Techniques de l’Ingenieur, chapitre H 6008, p. 1–18. fev 2010. Ce document présente différentes approches dans l’accès aux données issues de documents XML, selon les traitements voulus. Ces approches sont : parcours de document via SAX ou DOM, transformation des documents via XSL-T, requêtes XQuery et approche mixte avec SGBD relationnel. De plus, les auteurs proposent un exemple unique sur lequel est appliquée chaque approche. Ces applications sont illustrées par une implantation dans deux langages de programmation : Java et PHP.

[Des01]

Desgraupes B. : Introduction aux expressions régulières. Vuibert, 2001. Cet ouvrage propose dans un premier temps un exposé des différents types d’expressions régulières et de leur syntaxe ainsi que des exemples d’application qui permettent d’en comprendre les subtilités. Dans un second temps, il illustre les différences de fonctionnement des expressions régulières dans les langages de programmation TCL, Perl, Python, JavaScript, Awk ainsi qu’avec les outils de recherche de la famille grep

[LL06]

Lesbegueries J. et Loustau P. : Extraction et interprétation d’information géographique dans des données non structurées. Dans COnférence en Recherche d’Infomations et Applications - CORIA 2006, 3rd French Information Retrieval Conference, Lyon, France, March 15-17, 2006., p. 347–352. Université de Lyon, 2006. Cet article présente le projet «Pyrénées Itinéraires Virtuels» (PIV). Ce projet consiste à valoriser un fonds documentaire patrimonial localisé dans le territoire pyrénéen. L’article propose

32

d’étendre les fonctionnalités de systèmes de gestion de base documentaire classiques afin d’améliorer la prise en compte des aspects spatiaux formulés dans une requête. De plus, les auteurs présentent la description d’un prototype qui étaye cette proposition.

[MBY07]

Middleton C. et Baeza-Yates R. : A comparison of open source search engines. Rapport technique, octobre 2007. Cet article présente une comparaison des moteurs de recherches reposant sur plusieurs facteurs jugés pertinents. Cette comparaison est précédée d’une présentation du protocole expérimental (reposant sur des collections TREC) une ainsi que d’une description détaillée des caractéristiques des différents moteurs de recherches évalués. Les moteurs de recherche sont comparés selon le temps d’indexation, la taille des index produits, le temps d’interrogation et les résultats produits (avec des mesures de trec_eval).

[MRS08]

Manning C. D., Raghavan P. et Schütze H. : Introduction to Information Retrieval. Cambridge University Press, 2008. Cet ouvrage présente de manière détaillée les principes mis en œuvre dans le domaine de la recherche d’information. Accompagné de courts exemples, il décrit les écueils à éviter et les techniques pour optimiser les différentes étapes de fonctionnement d’un moteur de recherche : création de fichiers d’index binaires, compression d’index, calcul des scores, évaluation des résultats, modèles de langues et probabilistes ainsi que la reformulation de requête.

[OLMP07] Ounis I., Lioma C., Macdonald C. et Plachouras V. : Research Directions in Terrier. Novatica/UPGRADE Special Issue on Web Information Access, Ricardo Baeza-Yates et al. (Eds), Invited Paper, 2007. Ce document présente une vue d’ensemble du moteur de recherche Terrier. Il décrit l’architecture générale du programme, la structure des fichiers qu’il utilise ainsi que les principaux modules qu’il propose : indexation, interrogation, web crawling, langage de requête et reformulation de requêtes. Enfin, les auteurs détaillent l’utilisation de Terrier dans le cadre d’une recherche sur un corpus web.

[PCSH10] Palacio D., Cabanac G., Sallaberry C. et Hubert G. : Cadre d’évaluation de systèmes de recherche d’information géographique : apport de la combinaison des dimensions spatiale, temporelle et thématique. Dans Congrès Informatique des Organisations et Systèmes d’Information et de Décision (INFORSID), Marseille, France. INFORSID, mai 2010. Cet article s’inscrit dans le contexte de la valorisation des fonds documentaires patrimoniaux et plus précisément dans le projet PIV « Pyrénées Itinéraires Virtuels » qui gère un fonds documentaire consacré aux Pyrénées. Afin de favoriser l’accès à ces ressources, il est souhaitable d’y associer un moteur de recherche. Ce moteur de recherche doit prendre en considération la dimension thématique des documents mais aussi les dimensions spatiales et temporelles, il s’agirait donc d’un système de recherche d’information géographique (les moteurs de recherche généralistes ne traitent généralement que la dimension thématique). Il existe des cadres d’évaluation pour de tels SRI mais ils ne proposent des évaluations qui ne concernent que les performances (taille des index, temps de réponse). Cet article propose donc un cadre d’évaluation comblant les lacunes de ceux qui existent en proposant une évaluation de la pertinence des résultats des moteurs de recherche géographiques. Ce cadre d’évaluation est décrit suivant deux axes principaux : la collection de test comprenant les topics, les qrels et le corpus documentaire d’une part, un protocole d’évaluation des résultats obtenus par les SRI d’autre part. Cette proposition est appuyée par une étude de cas : l’évaluation du SRI développé pour PIV. Cette évaluation montre que les résultats obtenus par un SRI combinant les trois dimensions offre un gain d’efficacité de 56,5% face à un SRI ne comportant que la dimension thématique. La mise en œuvre du cadre d’évaluation est donc un succès et l’efficacité de la combinaison des trois dimensions pour la RI géographique est démontrée.

page 33 sur 34

[VH05]

Voorhees E. et Harman D. : Trec experiment and evaluation in information retrieval. MIT Press, MA, USA, 2005. Cet ouvrage traite du cadre d’évaluations de moteurs de recherche TREC. Une caractéristique importante de cet ouvrage est qu’il fait intervenir dans ses chapitres différents auteurs, intervenants majeurs du monde de la recherche d’information. En premier lieu, les auteurs relatent l’histoire des campagnes TREC depuis leur création. Dans un second temps, ceux-ci présentent la contribution de TREC au domaine de la recherche d’information en décrivant les collections proposées ainsi que les principes du protocole d’évaluation des moteurs de recherche. L’ouvrage comprend ensuite la description de différentes tâches de TREC. Enfin, les principaux participants aux campagnes de TREC présentent leurs travaux, tels que le modèle Okapi présenté par S. Robertson ou les modèles de langues expliqués par D. Hiemstra et W. Kraaij.

page 34 sur 34