Un moteur de recherche juridique

Les données traitées par Luxia

Luxia offre deux services dans le domaine juridique, Regmind et Alinéa by Luxia.
Ces deux services, qui utilisent le même moteur de recherche, ont comme mission de faciliter l’accès aux ressources juridiques grâces à différentes fonctionnalités mises à disposition de leurs publics, notamment la visualisation des actual ités juridiques, la création de veilles ou d’alertes pour être à jour par rapport à toute évolution judiciaire avec un outil de comparaison entre les versions des documents.
Les donnés traitées par ces deux services diffèrent en fonction du public ciblé, Regmind se spécialise dans les documents bancaires et financiers, alors que Alinéa by Luxia pointe vers des textes de droits généralistes.

Indexation de ressources

L’indexation désigne l’action du robot (c’est-à-dire d’un programme) d’un moteur de recherche qui passe sur un site, le parcourt et indexe son contenu. Lorsque l’on dit que le robot (le spider) indexe un site, cela signifie qu’il visite le site, en copie le contenu et le stocke dans les serveurs du moteur de recherche.[5] Pour indexer ses données juridiques, Luxia applique un processus de traitement et d’analyses sur les documents extraites depuis sa base de données.
Le processus de préparation des documents pour l’indexation à pour objectif de définir le langage documentaire de tel document. Cette phase permet de choisir les bons éléments à indexer. Il s’agit de définir des champs spécifiques qui contiennent des parties déterminées pour chaque article, notamment le titre par exemple et son contenu, ainsi identifier pour chaque document sa langue en ajoutant cette valeur dans un champs ‘’langue’’.
A partir de cette forme, les documents sont indexés dans un seul et unique index qui applique un analyseur français sur tous les champs des documents.

Mission et problématique

Mission principale

La création d’un seul index pour des documents de langues différentes influence la recherche. Comme certains mots s’écrivent de la même manière dans différentes langues, le taux de correspondance va être de plus au moins élevé au niveau de la recherche, ce qui préserve le rappel. Mais dans certains cas, cela produit un taux de bruit important puisque certains termes pourront se trouver dans une autre langue, exemple :
Une recherche de ‘’commercial commission ‘’ va renvoyer directement sur des documents en français sur la tête de la liste, pourtant l’utilisateur voulait une recherche en anglais.
Donc, une recherche dans des documents qui ne peuvent pas convenir influence sur le temps du traitement de la requête, ce qui produit une autre insuffisance.

Problématique

En vue de l’internationalisation de la solution, Luxia a besoin de rendre le moteur de recherche plus robuste en anglais, pour commercialiser la solution sur les pays européens et avoir de meilleurs résultats sur les documents européens et nouveaux clients anglophones.
Le premier objectif est de trouver une stratégie qui aide à montrer les différents documents possibles en fonction de la langue souhaitée par l’utilisateur, pour ensuite avoir de meilleurs résultats sur les documents européens. C’est aussi en vue de grandir nos donnés en fonctions du pays où on va commercialiser la solution.

Missions annexes

Etude technique

Cette internationalisation permet également une étude technique pour l’étude de faisabilité du passage de Solr à Elasticsearch.
Actuellement le moteur de recherche utilise l’apache Solr pour l’indexation des documents. Cette approche qui est basée sur la Bibliothèque Lucene, est considérée comme une base de données spécialisée dans la recherche d’information. Cette migration technologique à pour but de tester les apports d’un nouvel outil qui est appliqué dans plusieurs domaines d’indexation de l’information.
Le développement en Elasticsearch offres des nombreuses avantages tel que une recherche large (recherche sur un grand ensemble de données) sur toutes sortes de documents quelle que soit sa configuration ou sa définition. Ainsi grâce à son architecture, il offre une capacité d’analyse et de synthèse importante surtout au niveau de partage de l’indexation entre les différents utilisateurs ce qui confirme la rapidité.

Les différentes étapes du travail

Le travail comprend deux phases 

Analyse des besoins : afin de proposer une solution adéquate, il me faut tout d’abord étudier les besoins du client et ceci en recensant aussi bien ses besoins fonctionnels et que non fonctionnels. Cette phase était réalisée durant les premiers sprints de 3 mars 2020 à 5 mai 2020.
Conception et développement : C’est une étape dans laquelle, je mets en œuvre les besoins fonctionnels et leurs contraintes et je modélise le système à réaliser pour clarifier les tâches à accomplir dans la partie développement. Cette phase se termine par une partie qui comprend la programmation et les tests de validations. Elle e été accompli pendant les derniers sprints de juin et jusqu’au juillet 2020.

Analyse et spécifications

Introduction

Cette phase de mon étude est la plus importante, puisque c’est la première étape du développement de mon projet, au cours de laquelle les fonctionnalités que la solution devrait satisfaire seront déterminées.
Afin de proposer une solution adéquate, je présente dans un premier temps les attentes du public. Ensuite je vais dégager dans la deuxième partie les différents besoins fonctionnels et non fonctionnels à savoir les fonctionnalités requises par les utilisateurs.

Les types de recherches 

Recherche par mot

La recherche par mot va rechercher dans les documents l’existence de ce mot, et renvoyer les résultats classés par pertinences (du document le plus pertinent au moins pertinent) et en deuxième critère le plus récent au plus ancien.
Ce type de recherche s’applique sur le titre ou/et contenu.

Recherche par phrase

La recherche plein texte par phrase permet de recherche plusieurs mots consécutifs devant apparaitre dans le titre, dans le contenu ou dans ses mots-clefs associés. Cette recherche sur les titres&contenus est considérée comme une recherche exacte, où elle permet de rechercher dans les documents dont les titres&contenus sont les plus proches de la valeur saisie, plus la requête est proche du document, plus le score de ce document est élevé et sera afficher le premier. Ainsi, la recherche des mots de la phrase va rechercher dans les documents l’existence de ces mots, et renvoyer les résultats classés par pertinences et par ordre chronologique.
Ce type de recherche est utilisé éventuellement pour la recherche par numéro, où elle s’applique généralement sur un champs défini (numéro). Mais aussi dans certains cas quand le numéro figure dans le titre ou dans le contenu, on a besoin de faire la recherche sur d’autres champs, notamment le titre ou le contenu, afin d’augmenter la précision
La recherche par numéro permet de retrouver un document juridique faisant référence à un numéro connu, en renvoyant les documents dans l’ordre le plus pertinent et en deuxième critère du document le plus récent au plus ancien. Exemple des formes des numéros que le moteur de recherche est capable de reconnaître et pour lesquelles il va lancer une recherche précise par n°.

Conception

Introduction

Ce chapitre est consacré à la phase de conception, une phase cruciale dans le cycle de développement d’un projet. Je présente d’abord le mécanisme général du système d’indexation avec Elastic search. Je détaille ensuite les différents éléments de la conception de la solution proposée.

L’indexation dans Elasticsearch

Elasticsearch offre un mécanisme pour bien configurer l’index avant sa création, la figure cidessous présente les deux étapes que je les ai appliqué pour définir la structure de l’index utilisé.

Traitement des requêtes

Après avoir créé et rempli l’index de différents documents, il ne reste que traiter les requêtes des utilisateurs.
Avant de commencer cette partie, je définis l’indexation et ses avantages. Indexer des documents consiste à créer un index contenant ces documents. Il s’agit aussi d’affecter aux documents des indices et des analyses sur leurs contenus. En plus, l’indexation possède le pouvoir d’analyser par le même procédé les textes et les requêtes de l’utilisateur.
Pour un traitement efficace sur les requêtes, il faut savoir auparavant la cible de l’utilisateur.
Le traitement diffère d’une requête à l’autre, en fonction de son contenu, le processus de recherche exécute les meilleures fonctions.
Pour cela, j’ai réalisé beaucoup des tests sur plusieurs types des requêtes fournis par elasticsearch, notamment :
La Multi-match-query, ayant pour but de lancer une recherche dans plusieurs champs à la fois. La façon d’exécuter cette fonction dépend du paramètre type de la fonction.

Test et Réalisation

Pour intégrer les requêtes multi-match-query, j’ai utilisé la bibliothèque elasticsearch-dsl. Cette bibliothèque permet de créer des requêtes elasticsearch de façon claire et simple. Requêtes développées.

Synthèse

D’après les résultats de la requête 1, le moteur de recherche à réussi à matcher exactement la requête avec les deux titres de deux documents, donc cette fois -ci le système a fait une recherche exacte sur les termes.
Egalement, on remarque aussi une correspondance dans les titres proches et la requête, c’est tout à fait normal puisque le terme proche est inclut dans le terme exact. Pour le deuxième cas de recherche, la similarité par champs exacte est apparue seulement dans le premier résultat, le premier document possède un score de 36.64 de similarité où la phrase passée par la requête est inclues exactement dans son contenu. Tant que le deuxième document qui arrive avec un score de 18.25 c’est presque la moitié contient seulement quelques termes de la requête, ce qui explique la chute du score.
Depuis ces résultats, on peut conclure que le moteur de recherche réussit toujours à donner des bons résultats à l’utilisateur, quelque soit la valeur passée dans la requête, il y aura dans tous les cas un retour positif.

Requêtes sur les numéros

C’est le même principe, cette requête s’exécute toujours avec les deux requêtes précédentes. Son objectif est de renvoyer les documents dont le numéro figure dans la recherche. La seule différence c’est que les champs numéros utilisent toujours un seul analyseur, l’analyzer_exact_search. L’application de cet analyseur dans ce type de recherche est nécessaire, son objectif est de matcher exactement la requête comme elle est.
Une recherche proche sur les numéros peut provoquer une perte de précision, dans le cas où l’utilisateur tape par exemple une recherche du numéro ‘’r125-3’’, cette dernière va renvoyer sur les documents où ‘’r125’’ et/ou ‘’3’’ existent dans leurs contenus, titres ou numéros.

Requête multilingue

Le but de réaliser ce type de requête, est de montrer les différents documents possibles en fonction de la langue souhaitée par l’utilisateur. Pour cela j’ai travaillé sur deux possibilités :

Option 1 : Deux indexes séparés par langue :

Avant l’indexation, il s’agit de créer deux indexes, un index anglais et un index français dont chacun utilise respectivement un analyseur anglais et un analyseur français. L’indexation des documents dans deux indexes séparés se fait en fonction de chaque langue du document.
Lors d’une recherche, le système va déclencher d’abord l’algorithme de détection de langue, puis en fonction de la langue détectée, le moteur de recherche va changer d’index.
Ce traitment que je l’ai développé utilise un processus d’inférence d’un pipeline d’ingestion qui fait référence à un modèle d’identification de langue.
Pour ce traitement il a fallu utiliser le model lang_ident_model_1 qui prend la valeur de la requête, puis à l’aide d’un pipeline elasticsearch il exécute le processeur de détection sur cette valeur puis il renvoi la langue qui possède le score le plus élevé.
Le processeur de détection de la langue proposé par elasticsearch est composé d’une phase de modélisation et une phase de classification.
La création du modèle (modélisation) sert à identifier et stoker les mots ou les N-grammes les plus fréquents.
La deuxième étape, celle de la classification s’agit de comparer le document d’entrés aux différents modèles de langue de référence

Point fort

Avec cette idée, la précision sur les résultats sera élevée, puisque le moteur de recherche va changer automatiquement d’index en fonction de la langue, il aura donc uniquement les documents de la langue détectée.
Prenons l’exemple cité dans la problématique, la recherche de ’’commercial commission’’ au début avec un seul index a renvoyé sur des documents en français et en anglais à la fois, sans prendre compte de la langue.
Par contre, dans le cas d’une recherche sur deux indexes différents, le moteur de recherche a réussi (après un test effectué sur cette phrase) à montrer des résultats qui correspondent à la langue de la requête en changeant d’index (index anglais).

Point faible 

Malgré son efficacité niveau précision, cette solution possède une insuffisance non négligeable, c’est le cas d’une recherche par numéro.
En effet le processeur de détection de langue ne va pas reconnaître la bonne langue de la requête si elle contient seulement un numéro, il va renvoyer un résultat quelconque qui peut être français, anglais, ou n’importe quelle autre langue. Dans ce cas, le moteur de recherche va changer son index en fonction d’une langue non fiable, ce qui va entraîner une recherche dans un autre index où le numéro demandé ne figure jamais.
Exemple : le numéro ‘’r125-3’’ existe seulement dans l’index français, et le processeur de détection de la langue a demandé un changement d’index vers l’anglais.

Option 2 : un seul index avec deux différents analyseurs de langue 

Cette solution consiste à définir un analyseur par langue. L’idée est comme suit :
Pour chaque champs qui peut être en deux langues différentes (contenu ou titre), création de :
 Un sous champs français qui pointe sur le champs père avec un analyseur français.
 Un sous champs anglais qui pointe sur le même champs père mais avec un analyseur anglais.
Au moment de l’indexation, un seul index va contenir tous l’ensemble des documents de différentes langues.
Ensuite pendant la recherche, le changement sera au niveau des analyseurs. L’échange des analyseurs se fait en fonction de la langue de la requête. Si l’utilisateur tape une requête en français, le moteur de recherche exécute l’analyseur français, si la requête est en anglais, l’analyseur anglais sera exécuté. Comme il est bien indiqué dans la partie annexe Mapping_2, chaque sous-champs possède un seul analyseur, donc pour changer d’un analyseur à l’autre, il suffit de changer l’ensemble des champs à interroger.

Point fort

Cette solution garantit toujours un score de correspondance élevé. Les sous-champs seront dans tous les cas interrogés ensembles par la requête, donc le moteur de recherche quelle que soit la requête de l’utilisateur il trouvera toujours une similarité soit en français ou en anglais.
Grace à cette idée, la précision sur les documents sortants sera élevée, également pour le rappel où le moteur de recherche renvoi toujours les articles proches de la requête.

Points à améliorer

Afin de rendre cette solution efficace à 99.99%, il faut réaliser plusieurs tests avec des documents de langues différentes. Pour l’instant j’ai testé cette solution sur un ensemble de documents réduit (environs 720 articles)

Conclusion et perspective

Mon travail consiste à internationaliser le moteur de recherche de Luxia qui m’a donné l’opportunité de travailler sur un sujet complet depuis la phase de conception jusqu’au la phase de réalisation de la solution.
Pour réaliser ce projet, il a fallu étudier différentes solutions et les comparer pour aboutir au choix de la solution appropriée « indexation et recherche multilingues ».
Ce choix se justifie par l’avantage de deux options possibles : une garantie d’un taux de correspondance élevé.
Ce projet m’a permis d’améliorer mes connaissances théoriques acquises durant mes deux ans d’études universitaires à l’université Grenoble Alpes, ainsi que la maitrise de nouveaux outils d’indexation et de programmation. Il a été une expérience bénéfique pour moi, car il m’a initié à la vie professionnelle.
On peut conclure que le travail effectué, dans le cadre de ce projet de fin d’études m’a été bénéfique sur plusieurs niveaux :
En premier lieu, cette étude m’a permis d’enrichir mes connaissances dans le domaine d’indexation, et de découvrir ces nouvelles notions.
En deuxième lieu, ce projet m’a permis d’acquérir une expérience théorique et pratique de grande valeur, vu qu’il se présente comme une occasion de prendre la responsabilité de l’étude et du développement d’un outil d’indexation.
En troisième lieu, il m’a permis de savoir l’importance de la phase d’analyse d’un tel projet informatique et surtout l’importance de la phase de conception.
Comme tout travail, ce travail n’est pas exhaustif, il manque certaines fonctionnalités à améliorer à l’avenir.
L’utilisation d’Elasticsearch pour cette solution est encore étendue, il existe des points à améliorer, notamment :
 Le détecteur de la langue, dans certaines langues, le modèle de détection est assez précis sur des textes courts, mais il est plus difficile à identifier la langue sur des courts flux pour les langues similaires.
 Le stemmer utilisé au niveau d’analyseur par terme proche, il possède certaines insuffisances dans certains cas, même elles sont négligeables dans notre cas, mais ça reste toujours un point à améliorer.
 Chercher une troisième possibilité de recherche multilingue, penser à interroger simultanément deux indexes à la fois.
Ce projet a été une expérience bénéfique du point de vue des relations humaines car j’ai appris à travailler dans une équipe disciplinée et dans un environnement de travail réel et efficace.

Table des matières
Introduction 
Partie 1 
Présentation générale du projet 
I. Chapitre 1. Présentation générale du projet
1. Présentation du projet
2. Présentation du stage
1. Luxia
2. Stage
1. Le secteur d’activité
2. Les données traitées par Luxia
3. Indexation de ressources
4. Mission et problématique
5. Méthodologie de travail
Partie 2 
Analyse et spécifications 
II. Chapitre 2. Analyse et spécifications
Introduction
1. Les attentes du client
2. Analyses des besoins
i. Besoins non fonctionnels
ii. Besoins fonctionnels
Conclusion
Partie 3 
Conception 
III. Chapitre 3
Introduction
1. L’indexation dans Elasticsearch
2. Processus d’indexation
I. Settings
II. Mapping
3. Traitement des requêtes
Partie 4 
Conclusion générale et perspectives 
IV. Chapitre 4
Bibliographie
Table des annexes 

Télécharger le rapport complet