Xavier Tannier [email protected] Indexation avancée Indexation et Recherche d'Information.

Xavier [email protected]

Indexationavancée

Indexation et Recherche d'Information

Rappels des épisodes précédents

Indexation et Recherche d'InformationXavier Tannier

Indexation Avancée

Recherche d'Information

3

Collections dynamiquesvs. statiques

Requête

Indexation(modèle de document)

Modèle derecherche Évaluation


Indexation Avancée

Construction de l’index : vue générale

4

TEXTERien ne sert de courir; il faut partir à point :Le lièvre et la tortue en sont un témoignage.

«Gageons, dit celle-ci, que vous n'atteindrez pointSitôt que moi ce but. - Sitôt? Êtes-vous sage ?

Repartit l'animal léger : Ma commère, il vous faut purger Avec quatre grains d'ellébore.) - Sage ou non, je parie encore."

Ainsi fut fait; et de tous deux On mit près du but les enjeux :

Savoir quoi, ce n'est pas l'affaire, Ni de quel juge l'on convint.

Notre lièvre n'avait que quatre pas à faire,J'entends de ceux qu'il fait lorsque, prêt d'être atteint,

Il s'éloigne des chiens, les renvoie aux calendes, Et leur fait arpenter les landes.

Ayant, dis-je, du temps de reste pour brouter, Pour dormir et pour écouter

D'où vient le vent, il laisse la tortue Aller son train de sénateur.

Elle part, elle s'évertue, Elle se hâte avec lenteur.

Lui cependant méprise une telle victoire, Tient la gageure à peu de gloire,

Croit qu'il y a de son honneur De partir tard. Il broute, il se repose,

Il s'amuse à toute autre chose Qu'à la gageure. A la fin, quand il vit

Que l'autre touchait presque au bout de la carrière,Il partit comme un trait; mais les élans qu'il fit

Furent vains : la tortue arriva la première."Eh bien! lui cria-t-elle, avais-je pas raison ?

De quoi vous sert votre vitesse ? Moi l'emporter! et que serait-ce Si vous portiez une maison ?"

TERMES

Rien ne sert de

courir il faut

partir à point

TERMES NORMALISÉS

rien sert

courir faut

partir point

DOCUMENTS INDEX


Indexation Avancée

Construction de l’index

5

Doc #1

I did enact julius

caesar I was

killed i’ the Capitol

Brutus killed me

Doc #2

So let it be

caesar The

with

hath

was

toldBrutus

ambitious

you

noble

caesar

Séquencede termes

Terme

Terme Id. Doc

Id. Doc


Indexation Avancée


6

Tri par termes(puis par documents)

Terme

Terme Id. Doc

Id. Doc

….. …..

Terme Id. Doc


Indexation Avancée


7

….. …..

Terme Id. DocTerme Fréquence Liste

Fichier inverse(dictionnaire)


Indexation Avancée


8

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 !


Indexation AvancéeXavier Tannier

Requête dans les index

• Les listes de documents sont ordonnées !

• On traverse les deux listes l1 et l2 simultanément

9

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 id1 = suivant(l1) sinon id2 = suivant(l2)

Brutus

Caesar

Fin !



Arbres binaires de recherche

10

jeu

je

jeudi

jeux

jard

jante

Recherche approximative dans l’index



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 ?

12



Permuterm

• Pour chaque terme, indexer de façon circulaire– bonjour$– onjour$b– njour$bo– jour$bon– our$bonj– ur$bonjo– r$bonjou– $bonjour

13

• 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 !

?



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

14




• 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

15




• Correction en contexte– cacher / cracher– foncer / forcer

• Techniques :– Fonction du nombre de documents retrouvés

– Bi-grammes les plus fréquents

16



Rappel des enjeux matériels

• L’espace disque est nécessaire pour stocker les index inversésCertains 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

18



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é

19


Indexation Avancée

Construction de l’index : tri par termes

20

Tri par termes(puis par documents)

Terme

Terme Id. Doc

Id. Doc

….. …..

Terme Id. Doc



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)

21

• 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 ?



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)

22

• Temps de transfert du disque (une fois la tête positionnée) : 0,02s par octet

• Un identifiant de terme : 4 octets• Temps d’une comparaison ou d’un échange

de chaîne de caractères : 0,01s

• Temps total pour accéder aux données d’un bloc, les trier et les réécrire sur le disque ?



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

23



Indexation par blocs

24

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)

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

26

Qu’est-ce qu’une tâche « parallélisable » ?(MapReduce)



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

27




• 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

28



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

29



MapReduce

• Principe :– 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 :

1. Une fonction map qui réalise un traitement (modification) des données2. 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

30



MapReduce : compter les mots

31

CORPUS

comptage

comptage

comptage

comptage

comptage

Compteglobal

chunks

MAP REDUCE

Fusion des comptes

Compression de l’index



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

33



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

34



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 !

35



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

36

rang des termes

fréquence des termes



Compression du dictionnaire

37

Termes Fréquence Pointeur vers les listes

a 650 865

abandon 1245

… … …

zoulou 63

20 octets 4 octets 4 octets

• Si on a environ 400 000 termes• 28 octets par termes 11,2 Mo

Problèmes de cette structure fixe ?• « a »• « anticonstitutionnellement »

le double en unicode !



Compression de la liste de termes

38


42

11

235

63


comacombatcombecombinaisoncomblercombustible

• Si un terme fait 8 lettres en moyenne (disons 8 octets)

• 19 octets par terme au lieu de 28

7,6 Mo




39


42

11

235

63


4coma6combat5combe11combinaison7combler11combustible

• 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

Pointeurs par blocs pointeur tous les k termes (ici, k=4)

Pourquoi ne pas augmenter k ?




40

jeu

je

jeudi

jeux

jard

jante jeun

job

jeu

je

jeudi

jeux

jante

jard jeun

job

Recherche sans les pointeurs par blocs…

… et avec les pointeurs par blocs

Combien de comparaisons en moyenne ?




41

8attabler7attache9attachant9attaquer

On descend à 5,9 Mo

Codage incrémental

8atta*bler3che5chant4quer

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 !



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 log2 1 000 000 = 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)

42

128564 128569 128580 128595 128601




• 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ù » !

43

128564 128569 128580 128595 128601

… 5 11 15 6

… 1 1 1 1

1452 152654




• 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.

44




Bilan :– Pour une collection initiale de :

• 800 000 documents • 16 M de termes• 400 000 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

45

Plusieurs index ?



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)

47

Xavier Tannier [email protected] Indexation avancée Indexation et Recherche d'Information.

Documents

Transcript of Xavier Tannier [email protected] Indexation avancée Indexation et Recherche d'Information.