Nicolas Noullet IUP ISI L3 1 er avril 1 er 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 10 3.1 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é 15 5.1 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.3.1 Parseurs XML et expressions régulières.................. 17 5.3.2 Parseur dédié au HTML.......................... 17 5.4 Développement de l API storage.......................... 18 5.4.1 Berkeley DB................................. 18 5.4.2 Fichiers binaires adhoc........................... 19 5.5 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 24 6.1 Apport du travail réalisé.............................. 24 6.1.1 Évaluation du travail réalisé........................ 24 6.1.2 Analyse des résultats............................ 25 6.2 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 Concepts nécessaires à la compréhension du sujet 3.1.1 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 juin : Interrogation - État de l art de la recherche d information - Implémentation de la lecture de l index - Programmation de modules simples - Implémentation du module d interrogation - Conception de l architecture générale - Interrogation à partir de topics TREC mai : Indexation juillet : Evaluation - Implémentation du module d indexation - Évaluation à partir de collections TREC - Implémentation de l écriture de l index - Optimisation et correction de bogues - Indexation de corpus TREC - 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. http://staruml.sourceforge.net/ 8. http://www.eclipse.org/ 9. http://www.cygwin.com/ 10. http://subversion.tigris.org/ page 14 sur 34
Chapitre 5 Travail réalisé 5.1 Analyse préalable 5.1.1 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(log 2 (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 t 1 qui se trouve dans de nombreux documents et un autre terme t 2 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(t 1, d) et nbocc(t 2, d) alors que la présence de t 2 dans un document est beaucoup plus significative de son adéquation à la requête que la présence de t 1. 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 : où ( ) D idf(t) = log 2 {d D t d} 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. (5.1) 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. n tf(q i, d) (k 1 + 1) score(d, Q) = idf(q i ) i=1 tf(q i, d) + k 1 (1 ) (5.2) d b + b avgdl où d est un document du corpus comprenant d termes, Q est une requête de n termes {q 1, q 2,..., q n }, avgdl est nombre moyen de termes des documents du corpus, k 1 et b sont des paramètres libres. Figure 5.1 Formule du modèle de pondération Okapi BM25 5.7 Activités annexes 5.7.1 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 TREC- BLOG 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