Commit b56fccaa authored by Dos Santos David's avatar Dos Santos David

rapport

parent 1258677d
## Projet recherche d'informations web
# Projet recherche d'informations web
### Traitements linguistiques
## Implémentation
#### Collection CACM
### Parser
Code source : [Parser CACM](/parser/cacm_parser.py), [Parser Stanford](/parser/stanford_parser.py)
Le `Parser` est responsable de fournir une collection, sous la forme d'un ensemble de documents.
Pour cela, il implémente un générateur `find_documents` qui génère à la volée un Document (un `CACMDocument` ou `StanfordDocument`).
La structure en générateur permet un traitement à la volée de la collection brute sans tout charger en mémoire.
### Tokenizer
Code source : [SimpleTokenizer](/tokenizer/simple_tokenizer.py), [NoTokenizer](/tokenizer/no_tokenizer.py)
Le `Tokenizer` s'occupe de transformer un document en un ensemble de tokens. Sa principale méthode est `get_counted_tokens` et permet d'obtenir un [Counter](https://docs.python.org/3/library/collections.html#collections.Counter) des tokens du document.
Le `SimpleTokenizer` s'occupe de découper la chaine de caractère en une liste de mots, puis les met tous en minuscule et enfin filtre les mots présents dans les stop words.
### Indexer
Code source : [BSBIIndexer](/indexer/bsbi_indexer.py)
Cette classe est responsable de plusieurs choses :
- construire un dictionnaire token -> token_id
- construire un index inversé token_id -> postings
- construire un dictionnaire doc_id -> document metadata. Dans ces metadata on a toutes les informations qui permettent d'ordonner les résultats d'une requête suivant plusieurs pondérations
- enregistrer toutes ces données sur disque
- récupérer ces données depuis le disque si elles sont déjà disponibles
- trouver la liste des doc_ids qui contiennent un terme donné
- donner les metadata d'un doc_id
Pour l'implémentation, l'index inversé est construit à l'aide de la technique du Blocked Sort-Based Indexing (BSBI) : la mémoire allouée à la construction de l'index peut-être très facilement bornée. L'index contient alors une série de tuples (sous forme binaire) de taille fixe de 12 octets :
- 4 octets pour le token_id
- 4 octets pour le doc_id
- 4 octets pour la frequence du token dans le document
La recherche dans l'index se fait avec par dichotomie dans le fichier : on ouvre un file descriptor sur le fichier et on le déplace à la moitié du fichier. On regarde si le token_id que l'on recherche est avant ou après le token_id à la moitié du fichier puis on recherche récursivement sur la moitié du fichier.
La recherche se fait donc sans charger tout l'index en mémoire.
Par contre, pour simplifier, les dictionnaires token -> token_id et les doc_id -> metadata sont construits en ram, et stocker sur le disque sous forme de pickle.
### Query
Nous supportons les recherches sur le modèle booléen et vectoriel.
Pour le modèle booléen, on impose que la requête soit sous forme normale conjonctive.
Pour le modèle vectoriel, une fois les documents récupérés, nous les ordonnons grâce à une mesure cosinus. Les normes des vecteurs des documents sont pré-calculés lors de la construction de l'index. Ses composantes intéressantes (celles qui correspondent à des tokens dans la requête) sont re-calculés ici.
## Traitements linguistiques
### Collection CACM
Voici l'analyse obtenue pour la collection CACM:
......@@ -32,7 +80,7 @@ Graphes pour la loi de Zipf :
![zipf_law](/graphs/cacm_zipf_law.png)
![zipf_law_logs](/graphs/cacm_zipf_law_logs.png)
#### Collection CS276
### Collection CS276
Voici l'analyse obtenue pour la collection CS276
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment