Évaluation de l’ensemble des candidats

Cette première évaluation, effectuée à l’aide des données d’évaluation décrites ci-dessus, ne s’appuie sur aucun scores. Son but est principalement d’évaluer la qualité des candidats pour une tâche de correction et pour une tâche de norma- lisation. Elle permet ainsi de vérifier dans quelle mesure ce système est bruyant lorsqu’il propose des candidats. Pour ce faire, nous nous sommes intéressée à la quantité de candidats conçus pour chaque altération, puis à la couverture de ce

système. Nous nous sommes, par la suite, penchée sur la qualité des propositions réalisées pour des tâches de correction et de normalisation en calculant les scores optimaux que nous pouvons obtenir et en proposant une baseline pour notre sys- tème.

5.3.2.1.1 Nombre de candidats proposés Il est important de vérifier dans un premier temps que notre système ne propose pas trop de candidats, notam- ment au niveau du module de correction générique. Nous avons donc compté les candidats obtenus avec et sans ce dernier. Le nombre de candidats proposés reste raisonnable, même avec le module de correction générique. En effet, comme le montre la figure 5.2, seule une altération sur quatre se voit attribuer plus de 4 candidats. Le nombre de ces derniers décroît par ailleurs assez rapidement puisque même avec le module de correction générique, près de 45% des tokens altérés de notre corpus de test ne se voient attribuer qu’une seule proposition de correction.

0 1 2 3 ≥4 0 200 400 600 800 1 000 1 200 136 1 132 432 220 636 93 1 164 438 222 639

Nombre de candidats proposés

Nom bre de d’ a ltérations

sans correction générique avec correction générique

Figure 5.2 – Nombre de candidats proposés avec et sans correction générique

5.3.2.1.2 Couverture Cette figure nous montre aussi l’utilité de la correction générique. En se limitant aux seuls jeux de règles, 5,3% des tokens ne reçoivent aucun candidat. La correction générique permet de réduire ce taux à 3,6%. Les 93 tokens qui demeurent non traités ont été étudiés manuellement : 85% d’entre eux correspondent à des altérations trop complexes ou trop nombreuses (ex. : arondi- semernts, aérdorme) et 15% à des séquences de caractères difficilement interpré- tables, et ce même pour un humain (ex. : klàkoes, piwut).

Nous avons cherché, par ailleurs, à estimer la qualité des candidats proposés. Pour ce faire, étant donné un inventaire de candidats pour chaque altération, nous pouvons calculer une borne inférieure et une borne supérieure pour le système dans son ensemble. Ces bornes encadrent les performances que nous pourrons obtenir lorsque nous attribuerons des valeurs aux coefficients λs et λl, c’est-à-dire lorsque nous évaluerons la qualité de notre système de pondération à la section 5.3.2.2. Ces bornes ne prennent pas en compte les scores de correction de chaque candidat, et sont définies comme suit.

5.3.2.1.3 Borne supérieure pour le système complet Afin de déterminer le score maximum que notre système pourrait atteindre étant donné les candidats obtenus, nous utilisons un oracle. Pour chaque altération, dès lors qu’une bonne correction est trouvée, l’oracle le choisit. À défaut, si au moins une bonne nor- malisation est proposée, l’une d’entre elles est choisie au hasard par l’oracle. Si aucune normalisation valable ne se trouve parmi les candidats obtenus, le choix de l’oracle importera peu. Un tel oracle a été évalué pour les deux tâches de cor- rection et de normalisation. Ses résultats obtenus figurent respectivement dans les tableaux 5.4 et 5.5. Ils sont nécessairement meilleurs que ceux que nous obtien- drons avec notre système de storage, et ce quel que soit le nombre de candidats conservés en définitive.

Altérations Précision rappel F-mesure

sans correction générique (2 556 tokens) 94,1 89,1 91,6 avec correction générique (2 556 tokens) 93,7 90,3 92,0 uniquement concernées par corr. générique 69,8 22,1 33,5 (sur 93 tokens)

Table 5.4 – Évaluation des candidats après sélection par l’oracle pour la tâche de correction

Altérations Précision rappel F-mesure

sans correction générique (2 556 tokens) 95,6 90,4 92,9 avec correction générique (2 556 tokens) 95,1 91,6 93,3 uniquement concernées par corr. générique 69,8 22,1 33,5 (93 tokens)

Table 5.5 – Évaluation des candidats après sélection par l’oracle pour la tâche de normalisation

Nous avons calculé la précision, le rappel et la f-mesure que notre système obtient sur notre corpus d’évaluation complet de 2 556 tokens avec et sans la correction gé- nérique. Nous nous sommes aussi intéressée aux résultats acquis par la correction générique seule, en évaluant ce système sur les 93 altérations n’obtenant pas de

candidats avec nos jeux de règles larges et spécifiques. Cela a pour principal objec- tif de mesurer l’impact de ce dernier type de correction. Cette évaluation a été faite de manière systématique pour la tâche de correction automatique, en vérifiant que le token attendu fasse partie des candidats proposés pour la tâche de correction (cf. table 5.4), et pour la tâche de normalisation, en vérifiant qu’au moins un des candidats appartienne au même lemme que le token attendu (cf. table 5.5). Bien que l’écart entre nos scores avec et sans la correction générique ne soit pas très élevé, cette dernière nous permet de traiter plus de tokens (cf. les tables 5.4 et 5.5), sans faire diminuer de beaucoup notre précision. Par ailleurs, on constate que le rappel obtenu par la correction générique seule est très faible (pour les raisons citées en section 5.3.2.1) mais sa précision reste acceptable (70% environ). Nous l’avons donc conservée dans la suite de nos expériences.

Les scores obtenus pour les tâches de correction et de normalisation diffèrent peu. Cela montre que notre système de correction se trompe rarement dans la flexion du token qu’il tente de corriger, dès lors qu’il a correctement identifié le bon lemme. On note que les scores du module de correction générique sont identiques en correction et en normalisation. Cela s’explique par le fait que la correction générique, n’effectuant que des opérations non pondérées sur un caractère, a peu de chances de proposer une correction fautive qui soit une forme fléchie du bon lemme. En effet, supposons par exemple que l’on demande au module de correction générique de proposer un candidat pour l’altération prèt. Il pourra par exemple proposer, grâce à une unique substitution, les candidats suivants : prêt, prit, près. Cet exemple illustre le fait que, de façon générale, les tokens les plus proches (au sens de la distance de Levenshtein) d’une même altération ne sont pas tous, loin de là, des formes fléchies d’un même lemme. C’est d’autant plus vrai que le module de correction générique n’est appliqué qu’aux altérations suffisamment complexes ou inattendues pour que nos règles de correction, qui traitent plus de 96% des altérations, soient inefficaces.

5.3.2.1.4 Baseline pour le système complet Notre système de pondéra- tion doit être plus performant qu’un système de sélection aléatoire parmi les can- didats proposés. Afin de pouvoir l’évaluer, nous avons choisi de mettre en place une baseline qui sélectionnerait aléatoirement, pour chaque altération, un ou plu- sieurs candidats de normalisation. À ce stade nous ne savons pas encore si nous conserverons un ou plusieurs candidats. Les trois quarts de nos propositions de candidats n’étant pas supérieures à trois candidats (cf section 5.3.2.1.1), nous nous limiterons aux résultats pouvant être obtenus par cette baseline dans le cas où elle conserve 1, 2 et 3 candidats. Nos candidats étant produits dans un ordre immotivé, nous conservons donc à chaque fois les premiers proposés sans prendre en compte leur poids.

Nous pouvons tout d’abord constater que la tâche de normalisation (table 5.7) obtient de meilleurs résultats que celle de correction (table 5.6). Ce constat était

Nb candidats conservés Précision rappel F-mesure

1 candidat 50,7 48,9 49,8

2 candidats 64,6 62,2 63,4

3 candidats 70,6 68,0 69,3

Table 5.6 – Évaluation des candidats après sélection de manière aléatoire pour la tâche de correction

Nb candidats conservés Précision rappel F-mesure

1 candidat 69,3 66,7 68,0

2 candidats 78,9 76,0 77,5

3 candidats 85,3 82,2 83,7

Table 5.7 – Évaluation des candidats après sélection de manière aléatoire pour la tâche de normalisation

attendu dans la mesure où cette tâche a des attentes moins strictes. Toutefois, on peut noter de manière plus générale que, pour un système effectuant un choix aléatoire, les scores obtenus sont assez élevés. De plus, les taux de précision, rappel et f-mesure croissent rapidement à mesure qu’on augmente le nombre de candidats conservés. Cela met ainsi en évidence la pertinence des candidats proposés par notre système.