Généralisation de candidats de normalisation pour les er-

Nous avons ainsi choisi de traiter en priorité les erreurs les plus courantes trouvées dans nos corpus, à savoir les erreurs d’homophonie. Même si notre étude de corpus permet de constater que certaines fautes reviennent parfois plus que d’autres, elle montre surtout que ces dernières ne se produisent pas systématiquement sur les mêmes tokens. Par conséquent, nous ne pouvons pas établir une liste finie de to- kens pouvant être mal orthographiés et devons partir du principe qu’ils sont tous susceptibles de l’être. Pour mettre en place notre système, il est donc nécessaire d’obtenir simplement les homophones de chaque token. Une manière simple de réaliser cette opération est d’utiliser un lexique d’homophonie. Nous commence- rons ainsi par décrire la ressource que nous utiliserons pour rassembler les tokens partageant un même lien d’homophonie avant de nous concentrer sur le système de génération de candidats mis en place pour ce type de fautes.

6.1.3.1 Ressource lexicale utilisée

Afin de détecter et de normaliser les erreurs d’homophonie en rattachant un token à ses homophones, il est nécessaire de s’appuyer sur un dictionnaire phonétique. Nous utilisons, dans ce travail, le lexique phonétique Lexique 3, décrit en sec- tion 1.2.2.1. Ce dernier, doté d’environ 135 000 entrées, est principalement consti- tué de tokens usuels. Nous aurions certes pu nous appuyer sur un lexique plus fourni tel que le GLÀFF (Hathout et al., 2014) mais ce nombre restreint nous permettra notamment de nous focaliser sur les tokens les plus fréquents pour réa- liser notre génération de candidats sans nous attarder sur ceux, plus rares, qui font moins souvent l’objet de fautes. En effet, comme nous l’avons constaté en corpus, les erreurs d’homophonie sont majoritairement réalisées sur des tokens usuels. Un lexique plus large risquerait ainsi de nous induire en erreur.

Pondérer chacune des entrées de Lexique 3 en fonction de sa fréquence dans la langue peut, par ailleurs, nous aider à sélectionner plus précisément les tokens que nous souhaitons analyser. En outre, cela nous permet d’ordonner les candidats de corrections à conserver. Nous avons donc associé à chacune de ces entrées un poids situé entre 0 et 1. Ce poids a été calculé en normalisant de façon affine le logarithme de la fréquence de chaque token dans la Wikipédia3.

Ainsi, nous pouvons à présent nous appuyer sur une ressource lexicale qui associe chacune de ces entrées à sa retranscription phonétique (au format Lexique 3), à son lemme, à sa catégorie grammaticale et à sa fréquence normalisée ainsi qu’illustré à la table 6.2.

3. Réaliser ce calcul de fréquence sur un corpus à la première personne, plus proche de ceux que nous voulons traiter, serait préférable. Toutefois, il n’en existe pas à notre connaissance qui soit non bruité.

Phonétique4 Forme fléchie Lemme Cat. Gram. Fréq. norm.

§ on on NOM 0,812

§ on on PRO:per 0.812

§ ont avoir VER 0,799

§ ont avoir AUX 0,799

§ hon hon ONO 0,454

m@Z mange manger VER 0,522

m@Z manges manger VER 0,309

m@Z mangent manger VER 0,478

p2 peut pouvoir VER 0,777

p2 peu peu ADV 0,747

p2 peu peu NOM 0,747

p2 peuh peuh ONO 0,238

p2 peux pouvoir VER 0,524

Table 6.2 – Exemple d’entrées contenues dans Lexique 3 accompagnées de leurs fréquences extraites de la Wikipédia

6.1.3.2 Génération des candidats

Avant toute chose, rappelons que notre chaîne de traitement est construite de ma- nière à ce que toutes les ambiguïtés produites par chacun de nos modules puissent être résolues en nous appuyant sur leurs contextes. À ce stade, nous proposons donc de créer une ambiguïté supplémentaire en ajoutant des candidats de norma- lisation à tous les tokens dotés d’homophones que nous jugerons pertinents. Cette ambiguïté sera ainsi retirée à l’aide d’un système de désambiguïsation (comme nous l’expliquerons à la section 6.2). C’est cette dernière étape qui nous permet- tra de réaliser une sélection des candidats conservés parmi ceux créés par le module décrit dans cette section.

Si nous insérons une ambiguïté pour chaque homophonie détectée, le DAG représentant notre texte risque de devenir très, voire trop, ambigu. En effet, sans filtre, une phrase bien orthographiée comme « il est très cher » risquerait de devenir un DAG comme celui-

ci : « (il|ils|ile|île|îles|hile) (et|hé|ait|est|eh|ai|é) (trait|trais|traits|traie|très)

(cher|chair|chairs|chaire|chaires|cherres|chère|chères|chers) ». Tenter de désam-

biguïser une telle phrase risque d’augmenter la complexité de son analyse, son temps de traitement et d’impacter nos résultats. Nous avons ainsi choisi de procéder comme suit. Pour chaque token connu de notre lexique, nous cherchons

4. Le code phonétique employé dans ce tableau est propre à Lexique 3. Chaque phonème est ainsi représenté par un seul caractère. Ce code se rapproche notamment du code X-Sampa (eXtended Speech Assessment Methods Phonetic Alphabet). Ainsi § correspond [˜O], m@Z à /m˜AZ/ et p2 à /pø/. Bien que l’on désigne ce code comme phonétique, il s’agit plutôt d’un code phonologique.

ses homophones. S’il en possède, nous vérifions dans un premier temps les lemmes des homophones concernés puis, dans un second temps leurs fréquences. Ce qui nous permettra à terme de déterminer si nous souhaitons les conserver.

1. Tout d’abord, rappelons que nous ne nous intéressons qu’aux erreurs qui ne sont pas flexionnelles. Par exemple, le token mange ne partage sa phonétique [m˜AZ] qu’avec les tokens manges et mangent. Par conséquent, nous ne le suspecterons pas de nécessiter une normalisation puisqu’il ne s’agit ici que de flexions du lemme manger. Si nous prenons à présent le token peux, on constate qu’il peut correspondre à une faute flexionnelle (peux→peut ), mais aussi à une erreur d’homophonie. En effet, dans ce cas le token partage la phonétique [pø] aussi avec l’adverbe et le nom peu ainsi qu’avec l’onomatopée peuh. Ainsi la relation d’homophonie entre deux tokens sera pertinente que s’ils ne partagent pas le même lemme.

2. Ensuite, il est très rare qu’une erreur d’homophonie soit réalisée sur un to- ken peu fréquent ou que son candidat de normalisation soit lui-même peu fréquent. Si par exemple le token peux correspond dans un texte à une faute grammaticale, on ne s’attendra pas à ce qu’il soit normalisé par l’onoma- topée peuh qui est rarement employée. Nous proposons donc d’ajouter un seuil minimum de fréquence compris entre 0 et 1 afin d’autoriser ou non la normalisation d’un token et la validité d’un homophone donné. Plus ce seuil est élevé, plus la fréquence des tokens concernés sera importante. Ce seuil aura toutefois les défauts de ses qualités. En effet, imposer une limite parmi les tokens que nous souhaitons prendre en compte nous per- mettrait d’améliorer la précision de notre système puisqu’on ne conserverait que les tokens les plus fréquents et limiterait en plus de cela la complexité de notre système. Toutefois, cette limite diminuera automatiquement le rappel de notre système. En nous restreignant à un seuil donné, nous admettons que nous ne tenterons jamais de normaliser certains tokens qui auraient pu, malgré cela, être mal orthographiés. La valeur de ce seuil sera ainsi choisie en conséquence lors de l’évaluation de ce système.

Enfin, précisons qu’en fonction de sa provenance, la diction d’un locuteur peut varier. En effet, la phonétique d’un token dépendra souvent de l’accent de celui qui le prononce. Certaines personnes ne feront par exemple aucune distinction pho- nétique entre les tokens pomme /pOm/ et paume /pom/. L’aperture des voyelles notamment peut ne pas être perçue. C’est pourquoi, nous avons fait le choix de ne pas la prendre en compte en autorisant la libre substitution des phonèmes [o] et [O] et des phonèmes [e] et [E]. Les tokens été /ete/ et était /etE/, par exemple, seront ainsi considérés comme homophones.

Ainsi si on rencontre dans notre texte le token été, souvent confondu avec était, nous chercherons ses homophones. Ce dernier en possédant, il se verra attribuer le label /Homophone _{et obtiendra une sortie au format SxPipe telle que celle-ci :} ({été/Homophone} était|{été/Homophone} été|{été/Homophone} étaient)

6.1.4

Évaluation

À ce stade nous ne pouvons pas évaluer notre module sur la normalisation des fautes d’homophonie. Cette évaluation se fera dans la section suivante en le cou- plant au module de désambiguïsation. Ainsi afin de juger de la qualité de ce mo- dule de génération de candidats de normalisation seul, nous avons extrait toutes les fautes grammaticales et leur contexte contenus dans le corpus annoté utilisé pour l’évaluation de notre système de prétraitement (voir en section 4.2.9 la description de ce corpus). Ce corpus contient au total 105 fautes grammaticales.

La capacité de notre module à proposer des candidats de normalisation pertinents pour les tokens existants altérés dépend en grande partie de la valeur que nous aurons fixée pour le seuil minimum de fréquence normalisé. Nous avons ainsi choisi empiriquement d’observer les différents résultats obtenus lorsque ce seuil a les valeurs suivantes : 0,60, 0,65, 0,70, 0,75, 0,80, 0,90. La table 6.3 illustre ainsi la précision, le rappel et la f-mesure obtenus pour la tâche de génération de candidats de normalisation pour les fautes grammaticales.

Seuil homophonie

0,60 0,65 0,70 0,75 0,80 0,90 Précision 1,00 1,00 1,00 1,00 1,00 1,00 Rappel 0,78 0,68 0,62 0,55 0,52 0,01 F-Mesure 0,88 0,81 0,76 0,71 0,69 0,02

Table 6.3 – Résultats obtenus pour notre module de génération de candidats pour les fautes grammaticales

Les résultats obtenus par ce module sur notre corpus d’erreurs grammaticales en contexte sont satisfaisants. La précision montre que, lorsque ce dernier suggère des candidats de normalisation, le candidat attendu pour la faute grammaticale concernée est systématiquement proposé. Toutefois, obtenir une très bonne préci- sion n’est pas très complexe dès lors que notre module propose pour une altération tous ses homophones. C’est donc principalement le rappel obtenu par notre sys- tème qui nous intéressera pour cette tâche précise. En effet, ce dernier illustre bien l’importance du choix de notre seuil limite de fréquence. Si ce dernier est trop élevé, il ne tentera de normaliser que trop peu de fautes grammaticales. Ce constat se reflète d’ailleurs dans le rappel obtenu par notre système lorsque notre seuil minimum est fixé à 0,90. Toutefois, notons qu’un seuil dont la valeur serait trop petite permettrait certes de normaliser plus d’altérations, mais risquerait à terme de générer trop de bruit sur un corpus entier. Sélectionner la valeur la plus adéquate pour ce seuil est délicat. C’est pourquoi nous avons fait le choix de la déterminer non pas à la suite de cette évaluation, mais lors de l’évaluation générale de notre chaîne.

Notons enfin que l’on a tendance à se tromper sur certains types de tokens plus que sur d’autres. Ajouter, en plus d’un seuil de fréquence, un second score représentant la probabilité qu’une personne se trompe dans l’orthographe d’un token aurait donc pu être pertinent. Toutefois, pour rendre cela possible, un corpus annoté à grande échelle, fiable et proche de ceux que nous souhaitons normaliser aurait été nécessaire. Or, nous ne disposons pas de telles ressources5_.

Notre système suggère, malgré ce filtre de fréquence, de nombreux candidats de normalisation à la fois pour les tokens connus, comme expliqué ci-dessus, et pour les tokens inconnus, comme décrits dans les deux chapitres précédents. Il ne peut par conséquent être pertinent et efficace que s’il est suivi d’un bon système de désambiguïsation contextuelle. Ce système de désambiguïsation est décrit dans la section suivante.