6.2 Désambiguïsation contextuelle
6.2.2 Désambiguïsation d’un DAG
Suite à leur nettoyage, nos DAG demeurent ambigus et peuvent toujours conte- nir pour un même token plusieurs candidats de normalisation, qu’il s’agisse d’un token inconnu identifié comme une altération ou d’un token connu pour lequel les candidats homonymes ont été proposés. Prenons la phrase : « Le pri est élevé ! » illustrée figure 6.5. Nous savons que pri peut être normalisé par pris, prie, prix... Toutefois, sans informations supplémentaires, il est difficile de prédire quel candi- dat de normalisation est le plus adéquat. Nous avons donc besoin de connaître la probabilité d’avoir un candidat plutôt qu’un autre en fonction du contexte dans lequel il s’inscrit. 0 1 2 3 4 Le pri prix pris prie [...] est élevé
Figure 6.5 – Probabilité pour chaque candidat de normalisation d’apparaître dans le contexte ... « Le pri est élevé »
Pour cela, nous proposons de modéliser la langue de manière stochastique. Ce type de modélisation permet entre autres de calculer la probabilité qu’a un système de rencontrer une séquence donnée dans une langue donnée.
6.2.2.1 Outil choisi pour la génération du modèle de langue
Il existe d’ores et déjà plusieurs outils qui implémentent des modèles de langue et qui les utilisent de manière efficace afin de calculer la probabilité d’une séquence. Nous avons choisi d’utiliser l’un d’entre eux afin de ne pas avoir à implémenté un système qui serait possiblement moins performant que ceux déjà existant. Cet outil doit toutefois répondre à plusieurs critères. En effet, il doit tout d’abord être libre de droits et capable de traiter de gros volumes de données en peu de temps. En outre, nous avons besoin d’un système qui peut prendre des DAG en entrée. C’est notamment pour ces raisons que notre choix s’est porté sur l’outil KenLM8 (Heafield, 2011), un outil qui était état de l’art au moment où ce choix a été fait. KenLM permet notamment la construction d’un modèle de langue à partir d’un corpus donné et l’estimation d’une ou plusieurs phrases en fonction de ce modèle.
Bien que KenLM ait été initialement développé pour traiter du texte brut, cet outil est à présent apte à prendre des DAG en entrée. Cet ajout a été réalisé récemment afin de répondre à un besoin émis par le projet PACTE9. Ainsi une version de KenLM nommée Lazy est disponible sur le site de l’auteur10. Il prend donc un texte sous un format de DAG défini et renvoie les X chemins les plus probables. En outre, cet outil a l’avantage d’être paramétrable. Il nous permet entre autres de pondérer nos candidats de normalisation au sein du DAG. Cette option est d’autant plus intéressante que nous pouvons ainsi réutiliser les poids de nos candidats de normalisation et les prendre en compte lors de la désambi- guïsation11.
6.2.2.2 Modèles de langue construits
Les résultats qui seront obtenus par ce système de désambiguïsation dépendront principalement du modèle de langue appris via Lazy. Deux questions doivent es- sentiellement être posées lors de la construction d’un modèle de langue : (1) sur quel corpus doit-on l’entraîner ? et (2) comment doit-on l’entraîner ? Nous re- viendrons donc ci-dessous sur les choix que nous avons faits concernant ces deux critères.
6.2.2.2.1 Quel corpus d’entraînement ? Le corpus d’entraînement est censé représenter la langue de la manière la plus complète possible tout en prenant en compte l’utilité qu’il aura par la suite. Par exemple, si nous souhaitons traiter uniquement des textes portant sur l’automobile, utiliser un corpus d’entraînement spécialisé sur le sujet serait parfaitement pertinent. Dans notre cas, nous ne pou- vons pas prédire les sujets susceptibles d’être abordés dans nos messages. Le style d’écriture adopté dans ces derniers est variable ce qui fait que nous ne pouvons pas non plus cibler un type de corpus particulier.
9. Le projet PACTE (Projet d’Amélioration de la Capture TExtuelle) (2011-2015) avait pour objectif l’amélioration de la performance des processus de capture textuelle (OCR, reconnais- sance d’écriture manuscrite, saisie manuelle, rédaction) par l’utilisation du traitement de la langue, et plus spécifiquement des méthodes linguistiques statistiques et hybrides. Il concerne le domaine applicatif des projets de numérisation du patrimoine écrit, dans un contexte multi- lingue. Il réunissait trois entreprises (Numen, A2IA, Isako) et deux laboratoires (Alpage, LIUM).
10. https://github.com/kpu/lazy
11. Notons que cet outil peut présenter un défaut pour une application comme la nôtre. Le temps de chargement d’un modèle peut prendre un léger temps et doit être rechargé à chaque nouvel appel de l’outil. Pour une utilisation occasionnelle, cela n’est pas gênant, mais, à terme, cette solution ne peut pas être viable pour un système comme le nôtre qui risque d’être relancé à chaque nouvelle arrivée de texte. Pour pallier cela, notre modèle de langue sera chargé en arrière-plan afin que cela ne soit fait qu’à une reprise. Pour ce faire, nous utilisons un second outil, KendecServeur, développé par le projet Pacte.
La sélection de notre corpus d’entraînement est d’autant plus importante que ce dernier influencera les choix que fera notre module de filtrage. Il faut donc qu’on ait un corpus :
1. qui ressemble un minimum aux données qu’on veut traiter, 2. qui soit bien orthographié,
3. qui traite de sujets très différents afin qu’il soit le plus couvrant possible. Un corpus comme celui-ci n’existe pas à notre connaissance. Le second point est particulièrement primordial dans notre cas. En effet, nous avons absolument besoin d’un texte très peu bruité si nous souhaitons que notre modèle de langue soit pertinent pour une tâche de normalisation. Les textes écrits par les utilisateurs ne répondent malheureusement que très rarement à ce critère. Nous avons donc choisi, pour apprendre nos modèles de langue, le corpus Wikipédia qui couvre nos deux derniers points.
Notons que le choix de ce corpus a été effectué à défaut de mieux. Il serait possible de tenter de mélanger plusieurs types de corpus distincts afin d’obtenir un corpus d’apprentissage plus proche de nos données de tests par exemple. En effet, avoir par exemple plusieurs textes écrits à la première personne au sein de ce corpus d’entraînement optimiserait nos résultats. De même, nous pourrions envisager de mettre en place à terme plusieurs corpus d’entraînement en fonction des textes que nous voulons analyser afin que ces derniers soient plus performants en fonction du sujet traité.
Enfin, la qualité du modèle de langue va dépendre du corpus choisi, mais aussi de la quantité de texte contenu dans ce dernier. Plus la taille du corpus sera conséquente plus notre modèle de langue sera volumineux. Ne sachant pas quelle quantité serait adéquate, nous avons choisi d’apprendre et d’utiliser différents modèles de langue à partir de sous-corpus de la Wikipédia de tailles variés. Ces corpus sont illustrés dans la table 6.4.
Corpus nombre de tokens
100% Wiki 534 124 387
50% Wiki 257 574 283
25% Wiki 169 575 482
33% Wiki 134 004 732
17% Wiki 93 853 896
Table 6.4 – Tailles de corpus d’entraînement possibles
6.2.2.2.2 Quel contexte apprendre ? Une fois, un corpus d’apprentissage sélectionné, il est important de bien choisir la manière dont on veut le modèle de langue. Ne prendre en compte que le nombre de tokens qu’il contient reviendrait
à apprendre la fréquence d’un token dans une langue sans conserver son contexte. À notre stade, conserver des informations sur les voisinages possibles pour chaque token de la langue est essentiel. Il est donc nécessaire de définir plus précisément la taille du contexte que nous souhaitons prendre en compte. On s’interroge ainsi sur la taille des n-grammes que notre modèle de langue doit apprendre de notre corpus de référence. Plus la taille de n sera grande, plus les informations sto- ckées seront spécifiques. Au contraire, plus la taille des n-grammes conservés sera petite, plus les informations stockées seront générales (les caractéristiques de la langue risquent alors d’être mal représentées). Usuellement, on s’appuie sur des trigrammes, souvent considérés comme un juste milieu entre ces deux problèmes. Dans ce travail, toutefois nos évaluations seront effectuées en utilisant des modèles de langues contenant uniquement des bigrammes, uniquement des trigrammes ou encore des quadrigrammes. Ce ne sera que suite à ces expériences que la valeur des n-grammes conservés sera statuée.
Passer par un modèle de langue s’appuyant sur des tokens pour sélectionner à terme des candidats de normalisation pertinents peut sembler maladroit voir contradictoire. En effet, il aurait été préférable de travailler plutôt sur la notion de lemme puisque notre tâche est effective au lemme près. Toutefois, apprendre un modèle de langue lemmatisé supposerait de pouvoir ensuite le réappliquer sur un corpus de test lui aussi lemmatisé. La lemmatisation étant rarement concluante sur des textes bruités, procéder de la sorte risquerait de dégrader grandement nos résultats. Par ailleurs, au vu des différents résultats que nous avons obtenus jusqu’à présent, il est fort probable que le token qui était attendu pour une altéra- tion figure parmi les candidats de normalisation valides que nous aurons proposés. Cette hypothèse donc confortée par le faible différentiel constaté au chapitre pré- cédent entre les scores obtenus par notre système pour une tâche de correction et pour une tâche de normalisation.
6.2.2.3 Application du modèle de langue sur nos textes
L’application du modèle de langue sur nos données est ensuite assez simple à réaliser. En effet, cela consiste à récupérer notre DAG obtenu en sortie de chaîne de traitement et à le convertir au format accepté par Lazy. Lazy récupère ainsi nos données et nous renvoie, pour chaque DAG, les n phrases les plus probables. Ces dernières contiennent ainsi les candidats de normalisation les plus pertinents étant donné leur contexte. La valeur de n sera déterminée lors de notre évaluation. Afin de ne pas avoir à charger notre modèle de langue pour chaque nouvelle phrase traitée, rappelons que nous utilisons en parallèle KendecServeur. Ce second outil nous permet de lancer Lazy comme un processus et de stocker ainsi notre modèle en arrière-plan. Une fois que notre modèle de langue a extrait de notre DAG de sortie les n candidats de normalisation les plus pertinents, nous filtrons notre DAG initial afin de ne conserver que les candidats retenus par Lazy.
Ainsi, si nous prenons par exemple la phrase : « le syte et claire », sa normalisation se fera en trois temps :
1. analyse de la phrase par notre chaîne de traitement adaptée (cf. figure 6.6), 2. pondération des différents chemins possibles (cf. figure 6.7),
3. sélection de la meilleure analyse (cf. figure 6.8).
0 1 2 3 4 le site sy te et est claire
Figure 6.6 – Analyse de la phrase « le syte et claire » avant la désambiguïsation
0 1 2 3 4 le (-2,76) site(-5,87) sy te(-5,98) et(-2,66) est(-2,59) claire (-4,32)
Figure 6.7 – Pondération de l’analyse obtenue pour la phrase « le syte et claire » grâce au modèle de langue "k"-gramme entrainé sur "n"% de la Wikipédia
0 1 2 3 4
le (-2,76)
site(-5,87)
est(-2,59)
claire (-4,32)
Figure 6.8 – Sélection de la meilleure analyse de la phrase « le syte et claire » L’analyse ainsi obtenue est une normalisation correcte de la phrase de départ (la seule forme dont l’orthographe est incorrecte est « claire », mais la normalisation se faire à la flexion près).