Évaluation

4.2.9.1 Données d’évaluation

Afin d’évaluer nos différents modules, nous avons mis en place deux corpus de test constitués chacun de messages provenant des divers canaux traités par l’entreprise viavoo. Ils regroupent ainsi des messages provenant d’e-mails, de tchats, de for- mulaires, de sites d’avis, de forums et d’enquêtes de satisfaction. Pour chacun de ces canaux, nous avons veillé à extraire des messages provenant d’organisations différentes afin de couvrir une grande partie des sujets que l’on sera amenée à rencontrer et à traiter. Le premier est un corpus relativement restreint contenant 10 123 tokens. Ce dernier ayant été annoté manuellement, il nous permettra d’éva- luer de manière plus complète notre système. Sa composition est détaillée dans la table 4.11.

Canal Nb tokens Répartition

E-mails 2170 21,4% Tchat 1914 18,9% Sites d’avis 2016 19,9% Forums 2013 19,9% Enquêtes satisfaction 2010 19,9% Total 10123 100%

Table 4.11 – Composition du corpus d’évaluation annoté

Le second est de plus grande taille (100 295 tokens), mais n’est pas annoté. La table 4.12 illustre ainsi la taille couverte par chaque canal distinct dans ce dernier corpus.

4.2.9.2 Résultats

Afin d’évaluer les modules présentés ci-dessus, nous avons passé nos deux corpus d’évaluation dans notre chaîne de traitement SxPipe adaptée. En cas d’ambiguïté

Canal Nb tokens Répartition E-mails 20053 20% Tchat 20097 20% Sites d’avis 20011 20% Forums 20063 20% Enquêtes satisfaction 20071 20% Total 100295 100%

Table 4.12 – Composition du corpus d’évaluation non annoté

dans nos sorties, nous considérons qu’une altération est correctement normalisée dès lors qu’au moins un des candidats proposés correspond à une des formes flé- chies du lemme auxquelles notre token altéré aurait dû être rattaché. Certains de nos modules, que nous considérons comme potentiellement bruyants, peuvent conserver le token altéré d’origine dans leur sortie. Ce procédé a pour avantage de permettre aux modules le suivant de tenter de suggérer d’autres analyses plus pertinentes et de ne pas considérer celles proposées précédemment comme com- plètement fiables13. Dans ce cas, on considéra cette analyse comme non erronée dans la mesure où elle permet aux autres modules d’analyser autrement ce token inconnu.

Pour la suite de cette évaluation, nous utilisons les notions habituelles de précision, rappel et f-mesure. La précision P correspond au rapport entre le nombre de tokens bien normalisés et ceux pour lesquels nous avons proposé au moins un candidat de normalisation. Le rappel R sera calculé comme le rapport entre le nombre de tokens bien normalisés et le nombre de tokens donnés en entrée nécessitant une transformation. La f-mesure F, quant à elle, sera calculée comme habituellement : F = 2P R/(P + R).

Le premier corpus annoté se verra ainsi évalué à l’aide de ces trois mesures. Le second étant non annoté ne pourra, quant à lui, être utilisé que pour confirmer sur une masse de données plus importante la précision calculée avec notre premier corpus. Il est par ailleurs à préciser que nous n’avons volontairement pas évalué le module de correction par substitution. Ce choix est dû au fait qu’il a été im- plémenté afin de donner la possibilité aux utilisateurs d’ajouter à leur guise les paires (altération-normalisation) de leur choix. La qualité de ce module dépendra par conséquent des ressources fournies par l’utilisateur.

Bien que notre premier corpus d’évaluation ait l’avantage d’être annoté, il ne contient que relativement peu d’altérations. Les résultats obtenus sont par consé- quent à prendre avec précaution. En effet, ils sont empreints d’une marge d’erreur importante causée par le faible nombre d’altérations analysées. Ces résultats sont

13. Un système de désambiguïsation est ensuite appliqué en fin de chaîne (cf. chapitre 6) afin choisir quelle analyse nous souhaitons conserver.

présentés dans la table 4.13 accompagnés du nombre d’occurrences trouvé par cha- cun de nos modules afin de donner un ordre de grandeur du nombre d’éléments concernés par ces résultats.

Altération Nb Occ Précision Rappel F-mesure

Apostrophe 74 99% 87% 93% Accentuation 19 89% 100% 94% Autocensure 2 100% 100% 100% Décomposition 16 100% 100% 100% Agglutination 45 100% 100% 100% Étirement 0 — — —

Table 4.13 – Évaluation du système sur le corpus annoté

Il est à noter que, parmi les modules évalués, seul le module de détection des tokens agglutinés conserve systématiquement la forme initiale du token normalisé. Les autres proposent soit de conserver cette forme s’ils jugent son analyse peu fiable, soit de la supprimer imposant ainsi leur analyse.

• On constate que le nombre d’étirements présents dans ce corpus d’évaluation est nul, ce qui est peu surprenant si l’on se réfère à l’étude de corpus que nous avions réalisé (cf. la table 3.2 p. 68 récapitulant le nombre d’étirements trouvés au cours de cette précédente étude). Ce constat est le même en ce qui concerne le faible nombre de tokens correspondant à des cas d’autocensure. • Notre module de réaccentuation suggère une normalisation valide à tous les tokens altérés contenant une erreur d’accentuation ce qui explique son rappel. Il propose toutefois deux normalisations erronées sur 19 (sur un emprunt non adapté et sur un cas d’incomplétude lexicale) ce qui justifie notre précision de 89%.

• Le module de détection des erreurs d’apostrophe se révèle très peu bruyant. Il ne produit en effet qu’une seule normalisation erronée dans laquelle il ajoute une apostrophe entre deux tokens (l et ors) alors que ces deux derniers auraient dû être concaténés ensemble. Le rappel de ce module atteint 87%. Ce nombre peut paraître peu satisfaisant, mais il s’explique par le fait que ce module fonctionne à l’aide d’expressions régulières assez précises. Ces dernières assurent la fiabilité des normalisations suggérées, privilégiant ainsi la précision au rappel.

• Notre système de détection des tokens décomposés parvient à détecter tous les cas qui étaient annotés dans notre corpus et ne génère aucune mauvaise normalisation.

• Enfin, le module de détection des tokens agglutinés ne génère lui non plus aucune mauvaise normalisation. En effet, bien que ce dernier tente, à de nombreuses reprises, de normaliser des inconnus ne correspondant pas à

des agglutinations, il conserve systématiquement leur forme initiale, ce qui empêche à ce module de produire du bruit ou d’affecter la suite de la chaîne de traitement avec ses analyses. On peut toutefois noter qu’en conservant systématiquement ce token en plus de son analyse, ce module génère de l’ambiguïté. On constate qu’il ajoute ainsi en moyenne 1,3 candidats de normalisation en moyenne sur ce corpus en plus du token inconnu. Il a notamment tendance à se tromper sur des noms de produits (ex. : livebox ) et sur certaines fautes d’orthographe (damenager ou sechoir ).

Ainsi qu’expliqué ci-dessus, nous avons réalisé une seconde évaluation de notre chaîne sur un corpus qui a l’avantage d’être plus volumineux. Nous n’avons pour ce dernier évalué que la précision puisqu’il n’est pas annoté. La table 4.14 illustre ainsi les résultats obtenus par chaque module sur ce corpus.

Altération Nb Occ Précision

Apostrophe 848 99,6% Accent 222 90,1% Autocensure 0 — Décomposition 137 98,8% Agglutination 513 100% Étirement 14 100%

Table 4.14 – Éval du système sur le corpus non annoté

On peut ainsi constater que nos modules conservent de très bonnes précisions, presque identiques à celles obtenues avec le corpus précédent. Seule celle obtenue par notre système de détection de décomposition décroit légèrement de 100% à 98,8%. Cela est dû à deux erreurs d’analyses. La première concerne la forme sous- traite (forme fléchie du verbe sous-traiter ), absente du Lefff , que notre module propose de normaliser en soustraite (forme fléchie du verbe soustraire). La seconde est réalisée sur la chaîne « c’est plus cher-chez XXX ». Notre système est induit en erreur par l’absence d’espace avant et après le tiret et propose de normaliser cher-chez en cherchez.