Indexation et Recherche d'Information

Présentation au sujet: "Indexation et Recherche d'Information"— Transcription de la présentation:

1 Indexation et Recherche d'Information
Indexation avancée Indexation et Recherche d'Information

2 Rappels des épisodes précédents

3 Recherche d'Information
Indexation (modèle de document) Collections dynamiques vs. statiques Modèle de recherche Évaluation Requête

4 Construction de l’index : vue générale
DOCUMENTS TERMES Rien ne sert de courir il faut partir à point INDEX TEXTE Rien ne sert de courir; il faut partir à point : «Gageons, dit celle-ci, que vous n'atteindrez point Le lièvre et la tortue en sont un témoignage. Sitôt que moi ce but. - Sitôt? Êtes-vous sage ? Ma commère, il vous faut purger Repartit l'animal léger : Avec quatre grains d'ellébore.) - Sage ou non, je parie encore." On mit près du but les enjeux : Ainsi fut fait; et de tous deux Savoir quoi, ce n'est pas l'affaire, Ni de quel juge l'on convint. J'entends de ceux qu'il fait lorsque, prêt d'être atteint, Notre lièvre n'avait que quatre pas à faire, Il s'éloigne des chiens, les renvoie aux calendes, Ayant, dis-je, du temps de reste pour brouter, Et leur fait arpenter les landes. D'où vient le vent, il laisse la tortue Pour dormir et pour écouter Aller son train de sénateur. Elle part, elle s'évertue, Lui cependant méprise une telle victoire, Elle se hâte avec lenteur. Tient la gageure à peu de gloire, De partir tard. Il broute, il se repose, Croit qu'il y a de son honneur Qu'à la gageure. A la fin, quand il vit Il s'amuse à toute autre chose Que l'autre touchait presque au bout de la carrière, Il partit comme un trait; mais les élans qu'il fit "Eh bien! lui cria-t-elle, avais-je pas raison ? Furent vains : la tortue arriva la première. Moi l'emporter! et que serait-ce De quoi vous sert votre vitesse ? Si vous portiez une maison ?" TERMES normalisés rien sert courir faut partir point

5 Construction de l’index
Terme Id. Doc Doc #1 I did enact julius caesar I was killed i’ the Capitol Séquence de termes Brutus killed me Doc #2 So let it be with caesar The noble Brutus hath told you caesar was ambitious

6 Construction de l’index
….. Terme Id. Doc Terme Id. Doc Tri par termes (puis par documents)

7 Construction de l’index
Terme Fréquence Liste ….. Terme Id. Doc Fichier inverse (dictionnaire)

8 Construction de l’index
Terme Fréquence Liste Questions pour plus tard Comment construire cet index de façon efficace et économe ? Comment le conserver (mémoire, disque, quelle structure de données) ? C’est maintenant !

9 Requête dans les index Les listes de documents sont ordonnées !
fusion = <> id1 = l1[0], id2 = l2[0] Tant que les listes ne sont pas vides si id1 = id2 alors ajouter(fusion, id1) id1 = suivant(l1) id2 = suivant(e2) sinon si id1 < id2 alors id2 = suivant(l2) Les listes de documents sont ordonnées ! On traverse les deux listes l1 et l2 simultanément Brutus Fin ! Caesar

10 Arbres binaires de recherche
jeu jard jeudi jante je jeux

11 Recherche approximative dans l’index

12 Joker (« Wild Card ») * mon* : trouver tous les termes qui commencent par « mon ». Aucun problème avec les arbres binaires ou les B-Tree. *mon : trouver tous les termes qui finissent par « mon ». Maintenir un second B-Tree contenant les termes à l’envers ! tra*ant ?  S’arranger pour que le joker soit toujours à la fin ! Pourquoi ?

13 ? Permuterm Pour chaque terme, indexer de façon circulaire
bonjour$ onjour$b njour$bo jour$bon our$bonj ur$bonjo r$bonjou $bonjour Traitement des requêtes : permuter en conduisant le joker vers la droite X  X$ X*  $X* *X  X$* X*Y  *X*  X*Y*Z  Index environ 4 fois plus gros ! ?

14 Correction d’orthographe
Correction dans les documents Particulièrement utile pour les documents numérisés (OCR) Les pages Web ont beaucoup de fautes de frappe ou d’orthographe Le but : introduire moins de termes erronés dans le dictionnaire Correction dans les requêtes « comprendre » ce que demandait l’utilisateur

15 Correction d’orthographe
Correction d’un mot isolé : Distance d’édition (Levenshtein) Distance d’édition pondérée N-grammes de caractères Statistiques sur les logs de requêtes Soundex

16 Correction d’orthographe
Correction en contexte cacher / cracher foncer / forcer Techniques : Fonction du nombre de documents retrouvés Bi-grammes les plus fréquents

17 Construction de l’index

18 Rappel des enjeux matériels
L’espace disque est nécessaire pour stocker les index inversés Certains moteurs de recherche stockent presque tout en mémoire, c’est rapide mais très cher, et le changement d’échelle est plus compliqué. (mais Google et Bing le font) Le transfert de données via le disque dur est utilisé pour manipuler (au moins en partie) les listes inversées La mémoire vive stocke (si possible) le dictionnaire et accumule les documents de l’index La CPU est mise à contribution pour construire et ordonner les listes inversées

19 Rappel des enjeux matériel
Mémoire Accès rapide Accès aléatoire Contenance moyenne (Go) Chère Disque Accès lent Accès par blocs (de 8 à 256 Ko) Contenance élevée (To) Bon marché

20 Construction de l’index : tri par termes
….. Terme Id. Doc Terme Id. Doc Tri par termes (puis par documents)

21 Tri Le tri est généralement un travail pour la mémoire vive
Algorithmes efficaces, « lectures/écritures » fréquentes mais rapides OK jusqu’à quelques dizaines de millions de termes à trier. Impossible de tenir de grosses collections en mémoire pour la trier On analyse un document à la fois (compression très difficile) Les listes des index ne sont complètes qu’à la fin du processus Nécessité de prévoir des stockages intermédiaires sur le disque Algorithmes « classiques » de tri en mémoire impossible à reproduire sur le disque (accès trop lents) Chaque comparaison demande 2 accès au disque. On ordonne N éléments en N ln N comparaisons. Temps d’accès moyen :  5ms Combien de temps prendrait le tri de 100 M de termes ?

22 Tri par blocs Séparer la collection en n parties gérables en mémoire
Trier chacune de ses n parties séparément, et réécrire le résultat sur le disque (on trie par identifiants de termes et on conserve un dictionnaire) Fusionner les résultats 2 par 2. Fusion linéaire, vous commencez à connaître Inutile de mettre les deux blocs en mémoire Log2 n fusions Peut être fait avec plus de 2 blocs (plus efficace) Temps de transfert du disque (une fois la tête positionnée) :  0,02s par octet Un identifiant de terme : 4 octets Temps d’une comparaison ou d’un échange de chaîne de caractères :  0,01s Temps total pour accéder aux données d’un bloc, les trier et les réécrire sur le disque ?

23 Tri par blocs Condition du tri par blocs : le dictionnaire tient en mémoire Le dictionnaire permet de faire le lien entre les termes et leurs identifiants Il grandit dynamiquement On pourrait indexer par termes et non par identifiants, mais les fichiers deviendraient très gros Si le dictionnaire ne tient pas en mémoire ? Indexation complète par blocs On maintient un dictionnaire par bloc seulement On trie les dictionnaires, mais pas les listes

24 Indexation par blocs Tant que la mémoire n’est pas pleine
token = token suivant si token est dans le dictionnaire alors liste = liste existante pour ce token sinon liste = nouvelle liste ajouterToken(token, liste) Ordonner le dictionnaire Écrire le bloc sur le disque (dictionnaire + index) Recommencer avec un nouveau bloc si la liste est pleine alors doubler la taille de la liste Fusion des blocs (toujours pareil)

25 Indexation distribuée

26 Indexation distribuée
Pour de très larges collections (Web) Pour éviter de devoir utiliser des machines tolérantes aux fautes Un serveur principal dirige le tout (doit être très sûr) Il divise la tâche d’indexation en un ensemble de tâches parallèles Il assigne chaque tâche à une machine libre et fonctionnelle du réseau Qu’est-ce qu’une tâche « parallélisable » ? (MapReduce)

27 Indexation distribuée : contexte
Le problème : Compter le nombre de mots d'un corpus est trivial... Quand le corpus contient 100 documents... … mais pas quand il y en a 10 milliards ! Les deux aspects de la RI Modéliser la pertinence d'un document Construire l'architecture capable de mettre ce modèle en œuvre Stocker les données (efficacement !) Faciliter le traitement de masse de données

28 Indexation distribuée
Aujourd'hui tous les moteurs de recherche utilisent une architecture semblable un système de fichiers distribué un système de contrôle de tâches (job scheduler : quel programme est exécuté sur quelle machine à quel moment) Architecture initiale proposée par Google (Google File System & Map Reduce) Implémentation libre développée dans le projet Hadoop

29 Système de fichiers distribué
Pour le programmeur : Système de fichier standard (hiérarchie de répertoires + fichiers) En réalité : Les fichiers sont stockés découpés en morceaux (chunks) et stockés sur différentes machines Chaque chunk est stocké plusieurs fois (redondance)  possibilité de perdre des machines Système de fichiers : Vue abstraite : on ne sait pas où sont physiquement stockés les fichiers Gère la réplication : plus de copies des fichiers auxquels on accède le plus

30 MapReduce Principe : Interêt :
Cadre de développement permettant de paralléliser et de distribuer facilement les tâches Tous les algos sont écrits sous la forme de deux fonctions : Une fonction map qui réalise un traitement (modification) des données Une fonction reduce qui fusionne les résultats intermédiaires produits par map Interêt : Manière simple d‘écrire des programmes traitant plusieurs To de données Les tâches map sont exécutés sur les machines sur lesquelles sont stockées les données Les tâches map sont exécutées en parallèle

31 MapReduce : compter les mots
comptage Fusion des comptes comptage CORPUS comptage Compte global comptage comptage chunks MAP REDUCE

32 Compression de l’index

33 Pourquoi utiliser la compression ?
Utiliser moins d’espace disque (et faire des économies) Conserver plus d’informations en mémoire (et réfléchir plus vite) Conserver les dictionnaires Éventuellement, garder même les listes des mots fréquemment demandés en mémoire. Accélérer le transfert entre le disque et la mémoire À condition que le temps de compression/décompression soit inférieur au temps gagné au transfert Les algorithmes de compression doivent être rapides

34 Compression avec ou sans perte
Compression avec perte C’est le principe même de l’indexation : sac de mots mots vides lemmatisation, stemming, … Compression sans perte Rangement plus économe Compression de l’index une fois qu’on a décidé quelles informations on conserve

35 Rappel : Taille du vocabulaire
Le vocabulaire grandit quand la collection grandit. Loi de Heaps : M = kTb M : taille du vocabulaire T : nombre de tokens dans la collection b et k : constantes (typiquement, b = 0,5 et k = 30 à 100) Loi empirique Et c’est bien pire pour le Web !

36 Rappel : Fréquence des termes
Peu de mots fréquents, et beaucoup de mots rares Loi de Zipf : le nème mot le plus fréquent a une fréquence proportionnelle à 1/n fréquence des termes rang des termes

37 Compression du dictionnaire
Termes Fréquence Pointeur vers les listes a abandon 1245 … zoulou 63 le double en unicode ! 20 octets 4 octets 4 octets Problèmes de cette structure fixe ? « a » « anticonstitutionnellement » Si on a environ termes 28 octets par termes 11,2 Mo

38 Compression de la liste de termes
comacombatcombecombinaisoncomblercombustible Termes Fréquence Pointeur vers les listes 42 11 235 63 Si un terme fait 8 lettres en moyenne (disons 8 octets) 19 octets par terme au lieu de 28 7,6 Mo 3 octets 4 octets 4 octets

39 Compression de la liste de termes
Pointeurs par blocs pointeur tous les k termes (ici, k=4) 4coma6combat5combe11combinaison7combler11combustible Termes Fréquence Pointeur vers les listes 42 11 235 63 On économise 3 pointeurs (9 octets) tous les k termes. On dépense 1 octet de plus à chaque mot pour la taille 7,1 Mo 3 octets 4 octets 4 octets Pourquoi ne pas augmenter k ?

40 Compression de la liste de termes
jeu jeu jard jeudi jante jeudi jante je jeun jeux jard jeun job je jeux Recherche sans les pointeurs par blocs… job Combien de comparaisons en moyenne ? … et avec les pointeurs par blocs

41 Compression de la liste de termes
Codage incrémental Les mots ordonnés partagent souvent de longs préfixes en commun On ne code que les différences À l’intérieur d’un bloc uniquement ! 8attabler7attache9attachant9attaquer 8atta*bler3che5chant4quer On descend à 5,9 Mo

42 Compression des listes de documents
On trie les listes de documents par leurs identifiants (entiers) En général, un entier est codé sur 4 octets Au mieux, pour 1 M de documents, sur log = 20 bits Peu de termes fréquents, beaucoup de termes rares « allomorphie » apparaît peut-être une fois tous les millions de documents, donc pour notre collection d’un million de document, 20 bits devraient suffire « le » apparaît probablement dans chaque document, donc potentiellement 20 M de bits pour stocker la liste (c’est trop) 128564 128569 128580 128595 128601

43 Compression des listes de documents
Une idée : stocker les intervalles entre identifiants L’espoir est de pouvoir stocker les intervalles dans moins de 20 bits Mais… « le » « allomorphie » On a toujours besoin du maximum « au cas où » ! 128564 128569 128580 128595 128601 … 5 11 15 6 … 1 1452 152654

44 Compression des listes de documents
La solution ? Pour une valeur d’intervalle I, on veut utiliser aussi peu de bits que possible (l’entier au-dessus de log2 I). En pratique, on arrondit à l’octet supérieur. Comme pour les encodages de caractères, on consacre 7 bits d’un octet à représenter le nombre, et le dernier est le bit de continuation c. Si I  127, 7 bits suffisent, et c = 1. Sinon, c = 0 et on continue sur l’octet suivant. c = 1 signifie toujours que le nombre se termine à cet octet.

45 Compression des listes de documents
Bilan : Pour une collection initiale de : documents 16 M de termes termes uniques Taille du dictionnaire : Structure de taille fixe : 11,2 Mo Avec pointeurs vers les termes : 7,6 Mo Avec pointeurs par blocs : 7,1 Mo Avec pointeurs par blocs et codage incrémental : 5,9 Mo Taille de la liste de documents (sans les positions) : Matrice d’incidence : 40 Go Index inversé (4 octets) : 400 Mo Entiers de tailles variables : 116 Mo

46 Plusieurs index ?

47 Pourquoi plusieurs index ?
Les collections évoluent plus ou moins rapidement Documentation technique : de gros ajouts plutôt rares Des articles de journaux : quelques ajouts assez fréquents Le Web : beaucoup d’ajouts en permanence Plusieurs raisons d’utiliser plusieurs index : Pouvoir toujours utiliser un index si un autre est en reconstruction Maintenir un index des nouveaux documents en attendant de les fusionner à l’index principal Avoir un index pour chaque type de documents : Les pages rarement modifiées (exemple, le blog de votre grand-mère) Les pages modifiées régulièrement (exemple, le blog de votre petite sœur) Les pages modifiées en « temps réel » (exemple, la page d’accueil de liberation.fr)