UNIVERSITÉ PARIS 13 INSTITUT GALILÉE N˚attribué par la

Transcription

UNIVERSITÉ PARIS 13
INSTITUT GALILÉE
N˚ attribué par la bibliothèque
THÈSE
pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ PARIS 13
Discipline : informatique
présentée et soutenue publiquement
par
Olivier HAMON
le 6 décembre 2010
Titre :
Vers une architecture générique et pérenne pour l’évaluation en traitement
automatique des langues : spécifications, méthodologies et mesures
Directrice de thèse :
Adeline Nazarenko
JURY
M.
M.
M.
M.
M.
Mme
M.
Mohand
Khalid
Anthony
Daniel
Joseph
Adeline
François
BOUGHANEM
CHOUKRI
HARTLEY
KAYSER
MARIANI
NAZARENKO
YVON
Rapporteur
Examinateur
Examinateur
Examinateur
Président
Directrice
Rapporteur
« – Ma machine fait ce qu’elle sait faire, dit-il. Ce n’est pas de techniciens qu’elle aurait
besoin. Elle en a assez. Il lui faudrait des cerveaux...
– Des cerveaux ? Il n’y a pas un endroit au monde où vous en trouverez réunis de
meilleurs qu’ici ! Je vais demander une réunion immédiate du Conseil. Vous exposerez
vos problèmes...
– Ce sont de petits cerveaux, monsieur le docteur, de tout petits cerveaux d’hommes. Il
leur faudrait des siècles de discussion avant de se mettre d’accord sur le sens d’une
virgule... Quand je dis cerveau, c’est au sien que je pense.
Il caressa de nouveau le bord de la console, et ajouta :
– Et à ses semblables. »
La Nuit des temps, René Barjavel, éd. Presses de la cité, 1968, p.128.
Remerciements
Il est difficile d’évaluer l’apport de chacun sur une thèse... certains ont un fort rappel,
d’autres une forte précision, et d’autres encore cumulent et obtiennent une forte f-mesure.
Ces remerciements ne sont pas une évaluation, mais plutôt une sorte de "validation",
tous ayant largement dépassé un seuil qui était fixé bien haut. Cette validation m’est
plus simple à faire et chaque personne citée ci-dessous a apporté une brique nécessaire à
construire ma petite maison qui sera, j’en ai bien l’impression, en perpétuels travaux.
Mes premiers remerciements vont bien entendu à Adeline Nazarenko, qui a accepté
d’être la directrice de cette thèse. Chaque discussion que nous avons eue a été une source
de (re)motivation et un très bon exercice pour se creuser les méninges. Sa présence lors des
moments difficiles, 24 heures sur 24 et 7 jours sur 7, a été d’un support plus qu’apprécié.
Merci également à Khalid Choukri pour m’avoir accueilli au sein de la société ELDA
afin de réaliser cette thèse dans le cadre d’une convention CIFRE. Le contexte de mon
travail à ELDA m’a permis de découvrir de nombreux aspects du domaine du TAL et de
réaliser des expérimentations autour de multiples et diverses campagnes d’évaluation.
J’adresse mes remerciements à Mohand Boughanem et François Yvon, rapporteurs de
ce manuscrit, de même qu’à Anthony Hartley, Daniel Kayser et Joseph Mariani qui ont
accepté d’en être les examinateurs. Merci à eux pour leurs remarques constructives et les
discussions lors de ma soutenance. Ils m’ont apporté de nombreux points de réflexion pour
le futur. Merci à ceux qui sont venus de loin, voire de très loin, assister à ma soutenance.
Chronologiquement parlant, je ne peux que remercier Sylvain Surcin, qui ma lancé dans
cette galère. L’odyssée s’est poursuivi sans lui, mais il est à l’origine de ma motivation
pour démarrer ce beau voyage.
Un énorme merci à Louis-Gabriel Pouillot et Victoria Arranz pour leurs relectures
attentives. Ma thèse n’en est que plus aboutie par leur aide précieuse, quand bien même
cela m’a donné plus de travail que prévu.
Les travaux présentés dans cette thèse reposent sur plusieurs évaluations de systèmes
de traitement automatique des langues. Ils n’auraient pas pu être réalisés sans l’apport
et le soutien de nombreuses personnes avec qui j’ai eu le plaisir, autant professionnel
que personnel, de collaborer. Parmi elles, je tiens particulièrement à remercier Andrei
Popescu-Belis, Patrick Paroubek, Paula Estrella, Haïfa Zargayouna et Martin Rajman
qui ont alimenté mes réflexions autour du sujet "évaluation" et certainement bien plus.
Merci aussi aux collaborateurs avec qui j’ai eu l’occasion de collaborer dans différents
projects et qui m’ont beaucoup appris dans un contexte hors évaluation.
Je tiens à remercier l’ensemble de l’équipe d’ELDA, passée et présente. Certains ont
déjà été cités, je remercie aussi plus particulièrement Chiao Yun-Chuang, Marie-Neige
Garcia, Hélène Mazo et Mathieu Robin-Vinet. Leur écoute de mes râleries constantes a
été source de relaxation...
Enfin je remercie ma famille et mes amis pour leur patience et m’avoir supporté durant
tout ce temps... ou d’avoir supporté mes absences répétées. Ce n’est malheureusement
qu’un aperçu de ce qui les attends par la suite ! Un grand merci en particulier à mes parents
pour avoir tenu le coup lors de ma soutenance, et réussi à me réconforter durant toutes
ces années. Merci aussi à J.P., J.D. et Odile pour leurs encouragements inextinguibles.
Pour les oubliés, mille pardons...
Le meilleur pour la fin, un énorme merci à la petite pitufa pour son soutien infaillible.
Résumé
Le développement de systèmes en traitement automatique des langues (TAL) nécessite de déterminer la qualité de ce qui est produit. Que ce soit pour comparer plusieurs
systèmes entre eux ou identifier les points forts et faibles d’un système isolé, l’évaluation
suppose de définir avec précision et pour chaque contexte particulier une méthodologie, un
protocole, des ressources linguistiques (les données nécessaires à l’apprentissage et au test
des systèmes) ou encore des mesures et métriques d’évaluation. C’est à cette condition
que l’amélioration des systèmes est possible afin d’obtenir des résultats plus fiables et plus
exploitables à l’usage. L’apport de l’évaluation en TAL est important avec la création de
nouvelles ressources linguistiques, l’homogénéisation des formats des données utilisées ou
la promotion d’une technologie ou d’un système.
Toutefois, l’évaluation nécessite un important travail manuel, que ce soit pour l’expression des jugements humains ou pour la gestion du déroulement même de l’évaluation, ce
qui compromet l’efficacité des évaluations, augmente leur coût et les rend difficilement reproductibles. Nous avons cherché à réduire et à encadrer ces interventions manuelles. Pour
ce faire, nous appuyons nos travaux sur la conduite ou la participation à des campagnes
d’évaluation comparant des systèmes entre eux, ou l’évaluation de systèmes isolés.
Nous avons formalisé la gestion du déroulement de l’évaluation et listé ses différentes
phases pour définir un cadre d’évaluation commun, compréhensible par tous. Le point
phare de ces phases d’évaluation concerne la mesure de la qualité via l’utilisation de
métriques. Cela a imposé trois études successives sur les mesures humaines, les mesures
automatiques et les moyens d’automatiser le calcul de la qualité et enfin la méta-évaluation
des mesures qui permet d’en évaluer la fiabilité. En parallèle, les mesures d’évaluation
utilisent des ressources linguistiques dont les aspects pratiques et administratifs à travers
les opérations de création, standardisation, validation, impact sur les résultats, coût de
production et d’utilisation, identification et négociation des droits doivent être prises
en compte. Dans ce contexte, l’étude des similarités entre les technologies et entre leurs
évaluations nous a permis d’observer les points communs et de les hiérarchiser. Nous avons
montré qu’un petit ensemble de mesures permet de couvrir une large palette d’applications
à des technologies distinctes.
Notre objectif final était de définir une architecture d’évaluation générique, c’est-àdire adaptable à tout type de technologie du TAL, et pérenne, c’est-à-dire permettant la
réutilisation de ressources linguistiques, mesures ou méthodes au cours du temps. Notre
proposition se fait à partir des conclusions des étapes précédentes afin d’intégrer les phases
d’évaluation à notre architecture et d’y incorporer les mesures d’évaluation, sans oublier
la place relative à l’utilisation de ressources linguistiques. La définition de cette architecture s’est effectuée en vue d’automatiser entièrement la gestion des évaluations, que
ce soit pour une campagne d’évaluation ou l’évaluation d’un système isolé. À partir de
premières expérimentations, nous avons modélisé une architecture d’évaluation prenant
en compte l’ensemble de ces contraintes et utilisant les services Web afin d’interconnecter
les composants de l’architecture entre eux et d’y accéder via le réseau Internet.
Abstract
The development of Natural Language Processing (NLP) systems needs to determine
the quality of their results. Whether aiming to compare several systems to each other or to
identify both the strong and weak points of an isolated system, evaluation implies defining
precisely and for each particular context a methodology, a protocol, language resources
(data needed for both system training and testing) and even evaluation measures and
metrics. It is following these conditions that system improvement is possible so as to
obtain more reliable and easy-to-exploit results. The contribution of evaluation to NLP is
important due to the creation of new language resources, the homogenisation of formats
for those data used or the promotion of a technology or a system.
However, evaluation requires considerable manual work, whether to formulate human
judgments or to manage the evaluation procedure. This compromises the evaluation’s
reliability, increases costs and makes it harder to reproduce. We have tried to reduce
and delimit those manual interventions. To do so, we have supported our work by either
conducting or participating in evaluation campaigns where systems are compared to each
other or where isolated systems are evaluated.
The management of the evaluation procedure has been formalised in this work and
its different phases have been listed so as to define a common evaluation framework,
understandable by all. The main point of those evaluation phases regards quality measurement through the usage of metrics. Three consecutive studies have been carried out on
human measures, automatic measures and the automation of quality computation, and
the meta-evaluation of the mesures so as to evaluate their reliability. Moreover, evaluation measures use language resources whose practical and administrative aspects must
be taken into account. Among these, we have their creation, standarisation, validation,
impact on the results, costs of production and usage, identification and legal issues. In
that context, the study of the similarities between the technologies and between their
evaluations has allowed us to highlight their common features and class them. This has
helped us to show that a small set of measures allows to cover a wide range of applications
for different technologies.
Our final goal has been to define a generic evaluation architecture, which is adaptable to different NLP technologies, and sustainable, namely allowing to reuse language
resources, measures or methods over time. Our proposal has been built on the conclusions
drawn from previous steps, with the objective of integrating the evaluation phases to
our architecture and incorporating the evaluation measures, all of which bearing in mind
the place of language resource usage. The definition of this architecture has been done
with the aim of fully automating the evaluation management work, regardless of whether
this concerns an evaluation campaign or the evaluation of an isolated system. Following
initial experiments, we have designed an evaluation architecture taking into account all
the constraints found as well as using Web services. These latter provide the means to
interconnect architecture components and grant them accessible through the Internet.
Table des matières
1 Introduction
1.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Contexte de travail . . . . . . . . . . . . . . . . . . . .
1.2.1 ELDA et le LIPN : des organismes demandeurs
1.2.2 Des projets divers et variés . . . . . . . . . . . .
1.3 Conclusion et plan de thèse . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 L’évaluation en traitement automatique des langues
2.1 Le traitement automatique des langues . . . . . . . . . . . . . . . . .
2.1.1 Vision historique . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Applications et enjeux . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Niveaux de traitement . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Difficultés . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Domaines d’application . . . . . . . . . . . . . . . . . . . . . .
2.2 Évaluation en traitement automatique des langues . . . . . . . . . . .
2.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Trois questions fondamentales . . . . . . . . . . . . . . . . . .
2.2.4 Paradigme et méthodologies . . . . . . . . . . . . . . . . . . .
2.2.5 Difficultés . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6 De la théorie à la pratique . . . . . . . . . . . . . . . . . . . .
2.3 Architectures en traitement automatique des langues . . . . . . . . .
2.3.1 Infrastructure, architecture ou plate-forme ? . . . . . . . . . .
2.3.2 GATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 UIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Architectures en évaluation . . . . . . . . . . . . . . . . . . .
2.4 Vers une automatisation de l’évaluation en traitement automatique
langues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Aspects méthodologiques et organisation d’évaluations . . . .
2.4.2 Utilité des ressources linguistiques . . . . . . . . . . . . . . . .
2.4.3 Un point de départ : les jugements . . . . . . . . . . . . . . .
2.4.4 Automatisation et substitution aux jugements humains . . . .
2.4.5 Évaluation des mesures . . . . . . . . . . . . . . . . . . . . . .
2.4.6 Automatisation des protocoles : un vaste avenir . . . . . . . .
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
des
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
1
1
3
3
5
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
14
15
16
17
19
19
19
25
28
37
39
42
44
44
44
45
.
.
.
.
.
.
.
.
47
47
47
48
48
49
50
51
TABLE DES MATIÈRES
3 Le déroulement d’une évaluation
3.1 Phases préliminaires . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Planifier l’évaluation . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Définir la tâche de contrôle et ses objectifs . . . . . . . . . .
3.1.3 Cibler les participants et les acteurs . . . . . . . . . . . . . .
3.1.4 Établir des critères de qualité . . . . . . . . . . . . . . . . .
3.1.5 Définir les mesures de la qualité . . . . . . . . . . . . . . . .
3.1.6 Constituer les ressources linguistiques . . . . . . . . . . . . .
3.1.7 Spécifier et organiser les interactions entre acteurs . . . . . .
3.1.8 Préparer l’évaluation . . . . . . . . . . . . . . . . . . . . . .
3.2 Phases d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Phase d’apprentissage . . . . . . . . . . . . . . . . . . . . .
3.2.2 Phase de réglage . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Phase de test à blanc . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Phase de test . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Phase d’analyse des résultats . . . . . . . . . . . . . . . . .
3.2.6 Phase de retour d’expériences et d’adjudication des résultats
3.2.7 Phase de diffusion . . . . . . . . . . . . . . . . . . . . . . . .
3.2.8 Niveau supérieur : pérennisation et recherche de synergie . .
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
54
56
58
59
60
62
68
70
70
71
72
73
75
77
77
78
80
80
4 Les ressources linguistiques pour l’évaluation
4.1 Définition . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Le développement de systèmes . . . . . . . .
4.1.2 Évaluation de systèmes . . . . . . . . . . . .
4.2 Identification, production et négociation . . . . . .
4.2.1 Identification . . . . . . . . . . . . . . . . .
4.2.2 Production . . . . . . . . . . . . . . . . . .
4.2.3 Négociation . . . . . . . . . . . . . . . . . .
4.3 Validation . . . . . . . . . . . . . . . . . . . . . . .
4.4 Coût des ressources . . . . . . . . . . . . . . . . . .
4.5 Standardisation . . . . . . . . . . . . . . . . . . . .
4.6 Impact des ressources sur l’évaluation . . . . . . . .
4.6.1 Impact méthodologique . . . . . . . . . . . .
4.6.2 Impact de la qualité . . . . . . . . . . . . .
4.6.3 (Contre)-exemple en traduction automatique
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
84
85
85
86
90
91
92
92
93
93
93
93
102
5 L’étude des mesures d’évaluation
5.1 Description . . . . . . . . . . . .
5.1.1 Généralités et définitions .
5.1.2 Identification des mesures
5.1.3 Modélisation . . . . . . . .
5.1.4 Métriques de base . . . . .
5.1.5 Applications . . . . . . . .
5.2 Évaluation humaine . . . . . . . .
5.2.1 Caractéristiques . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
105
105
105
107
108
110
111
112
114
.
.
.
.
.
.
.
.
xii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
5.2.2 Déroulement . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Validation des jugements humains . . . . . . . . . . . . . .
5.2.4 Identification de juges « problématiques » . . . . . . . . .
5.2.5 Calcul et analyse des résultats de l’évaluation humaine . .
5.3 Évaluation automatique . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Formalisme et approches . . . . . . . . . . . . . . . . . . .
5.3.3 Déroulement . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 Calcul et analyse des résultats de l’évaluation automatique
5.3.5 Expérimentations en traduction automatique . . . . . . . .
5.3.6 Expérimentations en extraction terminologique . . . . . .
5.4 Méta-évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2 Procédure et méthodes . . . . . . . . . . . . . . . . . . . .
5.4.3 Méta-évaluation de l’évaluation manuelle . . . . . . . . . .
5.4.4 Méta-évaluation de l’évaluation automatique . . . . . . . .
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Les similarités entre évaluations de technologies
naisons de technologies
6.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . .
6.2 Similarités entre technologies . . . . . . . . . . . .
6.3 Similarités entre mesures ou métriques . . . . . .
6.3.1 Mesure humaine vs mesures automatiques
6.3.2 Catégories . . . . . . . . . . . . . . . . . .
6.3.3 Métriques humaines . . . . . . . . . . . . .
6.3.4 Métriques automatiques . . . . . . . . . .
6.3.5 Synergies . . . . . . . . . . . . . . . . . .
6.4 Formalisme . . . . . . . . . . . . . . . . . . . . .
6.5 Difficultés et « hiérarchie » des technologies . . .
6.5.1 Subjectivité . . . . . . . . . . . . . . . . .
6.5.2 Diversité des réponses possibles . . . . . .
6.5.3 Non comparabilité . . . . . . . . . . . . .
6.5.4 Complexité . . . . . . . . . . . . . . . . .
6.5.5 Synthèse et hiérarchisation . . . . . . . . .
6.6 Combinaison de technologies . . . . . . . . . . . .
6.6.1 Généralités . . . . . . . . . . . . . . . . .
6.6.2 Expérimentation . . . . . . . . . . . . . .
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
118
129
136
141
141
143
145
146
148
156
162
162
164
165
166
169
du TAL et les combi171
. . . . . . . . . . . . . . 171
. . . . . . . . . . . . . . 172
. . . . . . . . . . . . . . 174
. . . . . . . . . . . . . . 174
. . . . . . . . . . . . . . 174
. . . . . . . . . . . . . . 174
. . . . . . . . . . . . . . 175
. . . . . . . . . . . . . . 176
. . . . . . . . . . . . . . 177
. . . . . . . . . . . . . . 179
. . . . . . . . . . . . . . 179
. . . . . . . . . . . . . . 179
. . . . . . . . . . . . . . 180
. . . . . . . . . . . . . . 180
. . . . . . . . . . . . . . 181
. . . . . . . . . . . . . . 183
. . . . . . . . . . . . . . 183
. . . . . . . . . . . . . . 185
. . . . . . . . . . . . . . 195
7 Vers une architecture d’évaluation générique et pérenne
7.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Premières expériences . . . . . . . . . . . . . . . . . . . . .
7.2.1 Architectures pour l’évaluation automatique . . . .
7.2.2 Architectures pour l’évaluation humaine . . . . . .
7.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . .
7.3 Proposition d’une architecture d’évaluation . . . . . . . . .
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
en
. .
. .
. .
. .
. .
. .
TAL
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
197
198
201
201
207
215
216
TABLE DES MATIÈRES
7.3.1 Spécifications fonctionnelles . . .
7.3.2 Spécifications techniques . . . . .
7.3.3 Modélisation . . . . . . . . . . . .
7.3.4 Environnement de développement
7.4 Discussion et conclusion . . . . . . . . .
8 Conclusions et travaux futurs
8.1 Résumé . . . . . . . . . . .
8.1.1 Méthodologie . . . .
8.1.2 Généralisation . . . .
8.1.3 Automatisation . . .
8.2 Principaux développements
8.3 Perspectives . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
231
. 231
. 231
. 232
. 232
. 233
. 233
Bibliographie
235
A Résultats succincts de projets abordés
A.1 TC-STAR . . . . . . . . . . . . . . . .
A.2 CESTA . . . . . . . . . . . . . . . . .
A.3 CESART . . . . . . . . . . . . . . . . .
A.4 PASSAGE . . . . . . . . . . . . . . . .
A.5 EQueR . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Chronologie sur l’évaluation en TAL
sur les corpus
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
249
. 249
. 249
. 250
. 251
. 251
253
C Exemples de métriques utilisées en TAL
C.1 Traduction automatique . . . . . . . . . . . . . . .
C.1.1 BLEU . . . . . . . . . . . . . . . . . . . . .
C.1.2 mWER . . . . . . . . . . . . . . . . . . . . .
C.1.3 WNM . . . . . . . . . . . . . . . . . . . . .
C.2 Recherche d’information . . . . . . . . . . . . . . .
C.2.1 Précision moyenne non interpolée ou UAP .
C.2.2 Moyenne des Réciproques du Rang ou MRR
D Exemple de standardisation
D.1 Contexte et historique . .
D.2 Formats de codage . . . .
D.3 Formats de stockage . . .
217
221
224
228
230
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
255
. 255
. 255
. 256
. 256
. 258
. 258
. 258
textuels
261
. . . . . . . . . . . . . . . . . . 261
. . . . . . . . . . . . . . . . . . 264
. . . . . . . . . . . . . . . . . . 265
E Liste des acronymes
267
E.1 Liste des acronymes de projets et de campagnes . . . . . . . . . . . . . . . 267
E.2 Liste des acronymes d’institutions . . . . . . . . . . . . . . . . . . . . . . . 268
E.3 Liste des acronymes du traitement automatique des langues et de l’évaluation269
E.4 Liste des acronymes de l’informatique . . . . . . . . . . . . . . . . . . . . . 269
Glossaire
271
xiv
Liste des tableaux
2.1 Distinction entre compétition, validation et évaluation. . . . . . . . . . . . 29
2.2 Exemples de différents types, niveaux, critères, méthodes et mesures d’évaluation pour l’évaluation d’un système de traduction automatique de l’oral
vers l’oral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
Les phases préliminaires de l’organisation d’une évaluation. . . . .
Les étapes de la planification d’une évaluation. . . . . . . . . . . .
Les étapes de la définition de la tâche de contrôle. . . . . . . . . .
Les étapes pour cibler les acteurs de l’évaluation. . . . . . . . . .
Les étapes pour établir les critères de qualité. . . . . . . . . . . .
Caractéristiques des systèmes et critères de qualité dans CESART.
Caractéristiques des systèmes et critères de qualité dans CESTA.
Les étapes pour définir les mesures de la qualité. . . . . . . . . . .
Les étapes pour constituer les ressources. . . . . . . . . . . . . . .
Les étapes d’organisation des interactions entre acteurs. . . . . . .
Les phases d’une évaluation. . . . . . . . . . . . . . . . . . . . . .
Recommandations faisant suite au test à blanc CESTA. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1
4.2
4.3
4.4
Aperçu des ressources utilisées en fonction des technologies. . . . . . . . .
Directions de traduction et types de données du projet TC-STAR. . . . .
Pénalités pour les erreurs de traduction. . . . . . . . . . . . . . . . . . .
Scores de validation des traductions de référence et WER entre les traductions intermédiaires et la traduction finale pour la première traduction de
référence et la seconde de chaque ensemble. . . . . . . . . . . . . . . . . .
4.5 Corrélations sur les scores BLEU [%] et sur les classements des systèmes.
5.1 Caractéristiques de définition d’une mesure humaine, valeurs possibles et
exemples en traduction automatique. . . . . . . . . . . . . . . . . . . . .
5.2 Concordance des jugements de pertinence sur les mêmes documents, pour
608 documents portant sur le français lors du projet Infile. . . . . . . . .
5.3 Interprétation des valeurs du coefficient Kappa. . . . . . . . . . . . . . .
5.4 Exemple de résultats avec des désaccords équilibrés. . . . . . . . . . . . .
5.5 Exemple de résultats avec des désaccords déséquilibrés. . . . . . . . . . .
5.6 Coefficients Kappa global κg [0-1] pour les évaluations en fluidité et adéquation des deux campagnes d’évaluation CESTA. . . . . . . . . . . . . .
5.7 n-agreement [0-1] pour les deux campagnes d’évaluation CESTA. . . . . .
xv
.
.
.
.
.
.
.
.
.
.
.
.
54
55
57
58
59
60
60
61
63
69
71
75
. 84
. 94
. 95
. 98
. 101
. 116
.
.
.
.
120
121
122
122
. 123
. 124
LISTE DES TABLEAUX
5.8 Accord intra-juge [0-1] pour les deux campagnes, mesuré à partir du score
des systèmes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.9 Accord intra-juge [0-1] pour les deux campagnes, mesuré en fonction du
rang des systèmes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.10 Accord relatif intra-juge [0-1] pour la seconde campagne d’évaluation. . . . 127
5.11 Nombre de juges divergents identifiés pour chacune des méthodes de validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.12 Corrélations de Pearson entre les scores originaux et les scores après suppression des juges problématiques. . . . . . . . . . . . . . . . . . . . . . . . 135
5.13 Résultats des jugements humains pour la première campagne : scores sur
une échelle de 1 à 5 (5 étant la meilleure note et 1 la moins bonne) avec
leurs intervalles de confiance, et classements avec leurs probabilités. . . . . 137
5.14 Rang moyen des systèmes en fonction des classements par juge pour la
mesure de fluidité de la première campagne. . . . . . . . . . . . . . . . . . 137
5.15 Rang moyen des systèmes en fonction des classements par juge pour la
mesure d’adéquation de la première campagne. . . . . . . . . . . . . . . . . 138
5.16 Résultats des jugements humains pour la seconde campagne après adaptation des systèmes au domaine : scores sur une échelle de 1 à 5 avec leurs
intervalles de confiance, et classements avec leurs probabilités. . . . . . . . 138
5.17 Statistiques des candidats termes renvoyés par les systèmes pour la tâche
T1 de CESART et par corpus d’évaluation. . . . . . . . . . . . . . . . . . . 139
5.18 Précision des extracteurs sur le corpus de la santé d’après l’appariement
automatique aidant les experts, sur les N premiers candidats termes renvoyés.140
5.19 Précision cumulée [%] des extracteurs sur le corpus de la santé. . . . . . . . 141
5.20 Scores des métriques automatiques pour les traductions de la première campagne d’évaluation CESTA. . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.21 Scores des métriques automatiques pour les résultats de la seconde campagne avant adaptation au domaine. . . . . . . . . . . . . . . . . . . . . . 147
5.22 Scores des métriques automatiques pour les résultats de la seconde campagne CESTA après adaptation au domaine. . . . . . . . . . . . . . . . . . 147
5.23 Comparaison des scores des métriques automatiques pour les résultats de
la seconde campagne CESTA avant et après adaptation au domaine. . . . . 147
5.24 Poids des catégories morphosyntaxiques pour le calcul du X-Score. . . . . . 152
5.25 Scores et classement X-Score et fluidité des systèmes de la première campagne CESTA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.26 Scores et classement X-Score et fluidité des systèmes de la seconde campagne CESTA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.27 Exemple de résultats du X-Score. . . . . . . . . . . . . . . . . . . . . . . . 154
5.28 Scores et classement X-Score des systèmes des deux campagnes CESTA en
considérant les ratios d’unigrammes. . . . . . . . . . . . . . . . . . . . . . 156
5.29 Résultats de l’évaluation automatique sur CESART. . . . . . . . . . . . . . 160
5.30 Résultats de l’évaluation automatique sur CESART. . . . . . . . . . . . . . 160
5.31 Corrélations de Pearson pour chaque système entre les évaluations automatique et humaine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
xvi
LISTE DES TABLEAUX
5.32 Résultats de l’échantillonnage des jugements humains pour la première
campagne d’évaluation CESTA : scores sur une échelle de 1 à 5 avec leurs
intervalles de confiance, et classements avec leurs probabilités. . . . . . . . 167
5.33 Résultats de l’échantillonnage sur les scores moyens pour la métrique BLEU
(cumul. 4-gram avec casse) pour la première campagne CESTA. . . . . . . 168
5.34 Corrélation de Pearson entre les métriques automatiques et les juges humains de la première campagne CESTA. . . . . . . . . . . . . . . . . . . . 168
6.1 Technologies classifiées selon le traitement effectué et le format des résultats.173
6.2 Classification de mesures pour l’évaluation de technologies du traitement
automatique des langues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.3 Types de mesures selon les types de traitement et formats de données en
sortie des technologies du TAL. . . . . . . . . . . . . . . . . . . . . . . . . 177
6.4 Difficulté d’évaluations de différentes technologies, d’après les indices de
subjectivité, de diversité des réponses possibles et de non comparabilité. . . 181
6.5 Résultats des mesures automatiques de la seconde campagne TC-STAR
pour les composants de reconnaissance automatique de la parole avec le
WER et de traduction automatique de la parole avec BLEU. Les résultats
du meilleur système et du système sont présentés. . . . . . . . . . . . . . . 186
6.6 Résultat des mesures humaines de la seconde campagne TC-STAR pour le
composant de traduction automatique de la parole avec les scores de fluidité
et d’adéquation ; les résultats du meilleur système, de la combinaison de
systèmes et d’une référence humaine sont présentés. . . . . . . . . . . . . . 186
6.7 Résultat des mesures humaines de la seconde campagne TC-STAR pour
le composant de synthèse vocale avec la qualité globale ; les résultats du
meilleur système et d’une voix humaine sont présentés. . . . . . . . . . . . 186
6.8 Questionnaire de qualité pour l’évaluation en cascade de TC-STAR. . . . . 190
6.9 1-agreement [%] du questionnaire de qualité pour l’évaluation en cascade
de TC-STAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.10 Résultats des tests d’adéquation [%] pour l’évaluation en cascade de TCSTAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.11 Résultats des tests de compréhension [%] pour l’évaluation en cascade de
TC-STAR, restreints au sous-ensemble des questions pour lesquelles les
réponses sont trouvées dans les sorties des interprètes. . . . . . . . . . . . . 192
6.12 Résultats des tests de fluidité [1-5] pour l’évaluation en cascade de TC-STAR.193
6.13 Résultats des tests de qualité pour chaque composant de l’évaluation en
cascade de TC-STAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
C.1 Exemple de précisions calculées pour chaque document pertinent. . . . . . 258
xvii
LISTE DES TABLEAUX
xviii
Table des figures
1.1 Hiérarchie entre les concepts d’outil, de technologie, de système et d’application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Les niveaux d’analyse du traitement automatique des langues.
L’évaluation dans le cycle de vie d’un logiciel. . . . . . . . . .
Les types et niveaux d’évaluation d’après les travaux de ELSE.
Processus d’évaluation automatique et humaine. . . . . . . . .
Les types, niveaux et mesures d’évaluation. . . . . . . . . . . .
Schéma de l’architecture UIMA dans TC-STAR. . . . . . . . .
Méta-évaluation des mesures automatiques et humaines. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
DTD du corpus original. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DTD de la liste de termes amorces. . . . . . . . . . . . . . . . . . . . . . .
Format SGML des documents sources des campagnes d’évaluation CESTA.
Format SGML des documents références des campagnes d’évaluation CESTA.
Format SGML des documents tests des campagnes d’évaluation CESTA. .
DTD du corpus de la liste ordonnée de termes. . . . . . . . . . . . . . . . .
DTD des relations renvoyées. . . . . . . . . . . . . . . . . . . . . . . . . .
Phases préliminaires et phases d’évaluation. . . . . . . . . . . . . . . . . .
4.1 Comparaison des différences de score de validation et les WER entre les
traductions non validées et leurs corrections. . . . . . . . . . . . . . . . .
4.2 Résultats BLEU [%] pour l’ensemble Cortes-Verbatim de la direction de
l’espagnol vers l’anglais de la troisième année . . . . . . . . . . . . . . . .
4.3 Résultats BLEU [%] pour l’ensemble Cortes-FTE de la direction de l’espagnol vers l’anglais de la seconde année . . . . . . . . . . . . . . . . . . .
4.4 Cycle de vie d’une ressource linguistique. . . . . . . . . . . . . . . . . . .
5.1
5.2
5.3
5.4
Différents aspects d’une mesure. . . . . . . . . . . . . . . . . . . . . . . .
Modélisation d’une métrique d’évaluation. . . . . . . . . . . . . . . . . .
Déroulement d’une évaluation humaine. . . . . . . . . . . . . . . . . . . .
Score moyen par juge pour les jugements de fluidité et score moyen pour
les jugements correspondants provenant des autres juges. . . . . . . . . .
5.5 Score moyen par juge pour les jugements d’adéquation et score moyen pour
les jugements correspondants provenant des autres juges. . . . . . . . . .
5.6 Accord moyen par juge pour les jugements de fluidité. . . . . . . . . . . .
5.7 Accord moyen par juge pour les jugements d’adéquation. . . . . . . . . .
xix
.
.
.
.
.
.
.
2
16
29
31
35
35
43
50
64
64
66
66
67
69
70
82
. 99
. 100
. 100
. 103
. 107
. 109
. 118
. 131
. 131
. 132
. 133
TABLE DES FIGURES
5.8 Résultats officiels des systèmes comparés aux résultats après suppression
des juges problématiques. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9 Déroulement de la métrique X-Score. . . . . . . . . . . . . . . . . . . . . .
5.10 Poids catégories morphosyntaxiques rapporté au nombre total des fréquences
du X-Score. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11 Évaluation automatique sur les terminologies complète et réduite. . . . . .
5.12 Échantillonnage des jugements pour tester la robustesse de l’évaluation
humaine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Schématisation de la difficulté cognitive d’évaluer en fonction du nombre
des réponses possibles et de son caractère fini. . . . . . . . . . . . . . . .
6.2 Hiérarchisation des évaluations de technologies du traitement automatique
des langues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Calcul de l’impact de la sortie d’un composant sur un autre pour une
évaluation en cascade. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Le processus de traduction de l’oral vers l’oral. . . . . . . . . . . . . . . .
6.5 L’évaluation de la traduction de l’oral vers l’oral. . . . . . . . . . . . . .
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
Schéma d’utilisation du serveur de données dans TC-STAR. . . . . . . .
Architecture de la plate-forme d’évaluation. . . . . . . . . . . . . . . . .
Interface d’évaluation humaine CESTA - jugement de fluidité. . . . . . .
Interface d’évaluation humaine CESTA - jugement d’adéquation. . . . . .
Interface d’évaluation humaine CESTA - partie administration. . . . . . .
Interface de réponse aux questionnaires TC-STAR pour l’évaluation de la
traduction de l’oral vers l’oral (en espagnol). . . . . . . . . . . . . . . . .
Interface d’évaluation QASTLE pour les systèmes de question-réponse. .
Schéma fonctionnel de l’architecture. en gris la version étendue de l’architecture intégrant les systèmes de TAL. . . . . . . . . . . . . . . . . . . .
Alternatives d’architectures d’évaluation. . . . . . . . . . . . . . . . . . .
Combinaison d’une architecture d’évaluation et d’une architecture de production de ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Une occurrence d’évaluation au sein de l’architecture. . . . . . . . . . . .
xx
136
149
153
159
166
. 180
. 182
. 184
. 188
. 189
.
.
.
.
.
202
206
208
209
210
. 211
. 213
. 218
. 225
. 226
. 227
Chapitre 1
Introduction
1.1
Généralités
Le Traitement Automatique des Langues (TAL) s’appuie sur plusieurs disciplines à
l’intersection de la linguistique et des mathématiques, le liant étant l’informatique et la
couche supérieure relevant de l’intelligence artificielle et des sciences cognitives. Chacune
de ces disciplines apporte ses propres contributions au TAL, qui se préoccupe de l’interaction entre un ordinateur et un humain en langue naturelle.
De manière simple, l’ordinateur analyse une entrée, la convertit en une représentation formelle compréhensible par un programme, pour générer une sortie en faisant la
conversion inverse vers une langue compréhensible par un humain. Il arrive aussi que
cette analyse ait pour finalité de rester à un niveau intermédiaire dans un format non
naturel.
L’intérêt du traitement automatique des langues réside dans sa capacité à traiter en
quantité des informations produites en langue naturelle. L’ambition d’automatiser ces
traitements, notamment pour un accès à l’information plus rapide, est au centre de la
problématique du TAL. Les raisons se situent aux origines du TAL dès les années 50, avec
les besoins en compréhension mutlilingue et en communication.
L’expression « TAL » regroupe de nombreuses technologies comme la traduction automatique, la reconnaissance de la parole, la recherche d’information, l’analyse syntaxique,
la synthèse de la parole, le dialogue homme-machine, etc. Ce qui est une ambition de la
recherche scientifique est aussi au cœur de la réalité industrielle de par les applications qui
sont proposées. Le TAL regroupe de nombreux sous-domaines utilisant plusieurs types de
données issus de l’écrit (textes écrits, lexiques, etc.), de l’oral (signaux sonores, dialogues
oraux, etc.) ou du multimodal (images et sons).
Chaque technologie se retrouve intégrée dans des systèmes, ensemble de programmes
informatiques permettant d’automatiser une tâche. Une application est, elle, plutôt destinée à un utilisateur final qui n’a besoin d’aucune connaissance spécifique pour la faire
fonctionner. À un niveau plus basique, les outils sont des programmes qui effectuent des
tâches simples. La figure 1.1 présente la hiérarchie entre ces différents concepts.
Dans notre thèse, nous préférons parler d’évaluation de systèmes que d’évaluation
d’applications. D’autre part, nous considérons que les systèmes sont composés de mo1
Chapitre 1 : Introduction
Figure 1.1 – Hiérarchie entre les concepts d’outil, de technologie, de système et d’application.
dules, éléments de base d’un programme, et qu’une combinaison de systèmes regroupe des
composants technologiques 1 .
Au delà du développement de systèmes de traitement automatique, il existe un besoin de déterminer la qualité de ce qui est produit. L’automatisation des processus de
traitement de la langue est une tâche ni accomplie, ni stabilisée : la difficulté de traiter
le langage naturel conduit à vouloir estimer les performances des systèmes. De plus, le
traitement automatique des langues est un domaine qui n’est pas encore entré dans les
mœurs et la connaissance du grand public reste limitée. Il faut alors trouver les moyens
pour prouver que les systèmes fonctionnent et qu’ils sont utilisables, via l’évaluation.
D’après le Trésor de la Langue Française 2 , l’évaluation se définie comme l’action d’évaluer, d’apprécier la valeur (d’une chose) ; technique, méthode d’estimation. Ainsi, l’évaluation en traitement automatique des langues a pour but d’apprécier la qualité des sorties
d’un ou de plusieurs systèmes traitant le langage naturel. Cette évaluation s’accomplit
dans le contexte d’une tâche précise et à l’aide de méthodes spécifiques.
En TAL, le besoin d’évaluer est bien réel car il est inhérent à toute démarche scientifique : c’est le seul moyen qui existe pour valider ou comparer différentes approches,
connaître l’impact de nouvelles méthodes, de nouveaux paramètres, ou encore de nouveaux domaines. De plus, l’évaluation a également pour vocation d’apporter les éléments
indispensables qui serviront à améliorer les sorties d’un système par des indicateurs de
performance ou par une analyse d’erreurs et un diagnostic élaboré.
De manière pragmatique, l’évaluation d’un système repose sur la mesure de sa qualité
selon des critères définis au préalable. La mesure d’évaluation s’effectue par comparaison
d’une sortie, produit d’un système, avec une référence, un repère bien défini. Cette référence est fondée sur des jugements humains (pour lesquels des juges humains décident du
niveau de qualité) ou des métriques automatiques (des programmes calculant le niveau de
1. Un glossaire est proposé en fin de thèse en plus des définitions données au fur et à mesure du
manuscrit, ainsi qu’une liste des acronymes en annexe E.
2. http ://atilf.atilf.fr
2
1.2. Contexte de travail
la qualité à partir de références pré-établies), tous deux appliqués sur la sortie du système
évalué.
Le défi suivant, plus ambitieux, concerne sans aucun doute la modélisation d’une
architecture d’évaluation qui permette de conduire des évaluations de tout type et pour
toute technologie et de reproduire des évaluations à loisir. Cela aiderait d’une part les
développeurs de systèmes à tester fréquemment les progrès réalisés, et cela faciliterait
d’autre part le travail de l’évaluateur, souvent freiné par les difficultés liées à l’organisation
d’évaluations.
L’évaluation en traitement automatique des langues en est à un stade relativement
avancé où la communauté commence à mesurer l’étendue de son importance, mais il reste
encore beaucoup à faire. Le caractère subjectif des jugements humains, l’automatisation
des mesures d’évaluation, les soucis de fiabilité et de précision des mesures automatiques
ou encore la mise en place d’architectures d’évaluation pérennes sont les enjeux actuels
pour l’évaluation en TAL. À partir de ces points de réflexion, notre thèse vise à définir et à modéliser une architecture type dédiée. En particulier, nous nous intéressons à
la problématique des jugements humains réalisés sur les sorties de systèmes. L’un des
tout premiers objectifs est de déterminer les réels enjeux et difficultés de ces jugements
humains. Cet effort nous poussera à établir des critères objectifs pour l’introduction d’automatismes d’évaluation. C’est un point de départ indispensable pour la modélisation de
notre architecture, puisque cette dernière se veut pérenne et générique.
1.2
Contexte de travail
Cette thèse s’inscrit dans le cadre de plusieurs projets français et européens qui ont
pour objet l’évaluation de systèmes dans le domaine du traitement automatique des
langues (traduction automatique de texte et de la parole, extraction terminologique, recherche d’information, analyse syntaxique, etc.). Après avoir souligné l’importance des
organismes d’encadrement et leurs besoins respectifs, nous donnons ci-après une brève
description de projets sur lesquels nous avons travaillé. Nous avons ainsi construit pas à
pas notre réflexion sur le domaine de l’évaluation du traitement automatique des langues.
1.2.1
ELDA et le LIPN : des organismes demandeurs
Le cadre applicatif de cette thèse se situe en plein cœur des activités d’évaluation en
traitement automatique des langues. ELDA (Evaluations and Language resources Distribution Agency 1 ) est une société agissant comme organisme d’évaluation. Elle a organisé
et organise des campagnes d’évaluation pour différentes technologies du traitement automatique des langues. Fondée en 1995, elle est l’organe opérationnel de l’association
ELRA (European Language Resources Association 2 ) qui a pour objectif de promouvoir
les ressources linguistiques dans le secteur du TAL et l’évaluation de ses technologies.
L’activité première d’ELDA se situe dans l’identification, la production, la validation,
la promotion et la distribution de ressources linguistiques. Par ailleurs, une activité d’évaluation de technologies est également conduite. De fait, ces six activités sont étroitement
1. http ://www.elda.org
2. http ://www.elra.info
3
liées, puisque les systèmes du traitement automatique des langues requièrent des données
au cours de leur développement, ainsi que pour leur évaluation. Il existe un grand besoin
d’augmenter le volume de ces données pour l’amélioration des systèmes, mais aussi de les
renouveler pour garder neutre le test des sorties dans le cadre d’une évaluation. En effet,
la connaissance des données de test aux participants d’une évaluation doit être restreinte
afin de respecter l’impartialité des actions (cf. chapitre 3, section 3.2.4).
Au début de ses activités d’évaluation, ELDA a pris part au projet EVALDA du
programme Technolangue 1 financé par le Ministère de la Recherche. Ce projet avait pour
but la mise en place d’une infrastructure pérenne d’évaluation des technologies de la
langue 2 . Cet objectif ambitieux avait pour contexte linguistique le traitement de la langue
française. C’est ainsi que huit « campagnes d’évaluation » (l’ensemble coordonné des
tâches visant à l’évaluation et la comparaison de plusieurs systèmes) ont eu lieu, dont
cinq autour de l’évaluation de technologies traitant des données textuelles :
– Alignement de corpus bilingues (ARCADE II) ;
– Extraction terminologique (CESART) ;
– Traduction automatique (CESTA) ;
– Annotation syntaxique (EASY) ;
– Question-réponse (EQueR).
Parmi ces campagnes d’évaluation, trois ont utilisé des mesures manuelles pour estimer
la qualité des systèmes : CESART, CESTA et EQueR. Trois ont utilisé des mesures
automatiques ou semi-automatiques (cf. section 5.3) : ARCADE II, CESTA et EASY.
Notons que trois autres campagnes ont été organisées avec comme objectif le traitement de données orales : ESTER (évaluation de systèmes de transcription automatique
de données audio), EvaSy (évaluation de systèmes de synthèse de la parole) et MEDIA
(évaluation de systèmes de dialogue), pour lesquelles aussi bien des mesures manuelles
que des mesures automatiques ont été utilisées.
Par ailleurs, d’autres campagnes d’évaluation ont été conduites au sein d’ELDA
comme, entre autres, celles conduites dans le projet européen TC-STAR 3 visant l’élaboration d’un système distribué de traduction automatique de l’oral vers l’oral en temps
réel et comptant une part importante d’évaluation sur la reconnaissance automatique de la
parole, la traduction automatique de la parole, la synthèse vocale ainsi qu’une évaluation
regroupant ces trois technologies. Le projet PASSAGE 4 , ayant pour objectif l’évaluation
des analyseurs syntaxiques, a également été prépondérant dans la réalisation de cette thèse
car il a donné lieu au développement d’une plate-forme d’évaluation (cf. section 7.2.1.2).
Le projet européen CLEF 5 qui a lancé des campagnes d’évaluation annuelles autour de la
recherche d’information, nous a permis à moindre échelle de poursuivre nos efforts pour
l’amélioration d’une interface de collecte de jugements humains développée dans le cadre
du projet EQueR.
1. http ://www.technolangue.net
2. Une infrastructure représentant l’entité qui rassemble la totalité des moyens et ressources de l’évaluation à long terme : organisations, acteurs, agents, etc. Au contraire, une architecture est une modélisation des relations entre composants technologiques. Sa partie technique, la plate-forme, permet la mise
en pratique de chaînes de traitement.
3. http ://www.tcstar.org
4. http ://atoll.inria.fr/passage
5. http ://www.clef-campaign.org
4
D’autres évaluations d’un système isolé, hors campagnes d’évaluation, ont également
eu lieu de manière plus confidentielle.
L’ensemble de ces projets couvre les différents aspects de l’évaluation en traitement
automatique des langues :
– Évaluations utilisant des mesures manuelles (les jugements humains) et évaluations
utilisant des mesures automatiques (les métriques automatiques), comparaison des
deux approches et étude de leur complémentarité ;
– Exploration des problématiques d’évaluation inhérentes à chaque technologie ;
– Développement de plates-formes en vue de conduire des évaluations pérennes.
Notre implication dans la plupart de ces projets nous a permis de découvrir un vaste
ensemble d’éléments constitutifs de l’évaluation en traitement automatique des langues.
La mise à disposition des ressources, protocoles, outils, etc. fait également partie des
objectifs à atteindre pour un projet d’évaluation par le biais de « kits d’évaluation ». Ceuxci permettent la distribution de l’ensemble des données et informations d’une évaluation,
compilées sur un support physique (CD-ROM, DVD-ROM, disque dur, etc.) ce qui facilite
la réutilisabilité des ressources et méthodologies employées.
D’un autre côté, le LIPN 1 assure l’encadrement scientifique de cette thèse qui s’articule
autour des travaux menés par l’équipe de « Représentation des Connaissances et Langage
Naturel » (RCLN). L’intérêt pour le langage et la représentation des connaissances se
situe autour de thématiques telles que l’étude sémantique de textes, l’accès au contenu
textuel ou l’acquisition de connaissances. Elles regroupent diverses technologies, telles
que l’accès à l’information, l’analyse de corpus, l’extraction et l’analyse terminologique,
la construction d’index de fin de livre, la reconnaissance d’entités nommées, la recherche
d’information et l’extraction d’information, etc.
Concernant l’évaluation des technologies du traitement automatique des langues, le
LIPN agit plus comme un développeur de technologie et un participant à des évaluations.
Cela n’empêche pas une réflexion de fond sur les méthodes d’évaluation, en particulier pour
l’extraction terminologique et l’acquisition d’ontologie. Le LIPN a notamment participé
à des évaluations dans les campagnes ESTER (repérage d’entités nommées), CESART
(détection de relations de synonymie entre termes), EQueR (question-réponse dans le
domaine médical), TAC 2008 (analyse de textes) ou DUC 2008 (résumé automatique).
Le LIPN participe aussi au projet Quaero 2 sur la partie acquisition de connaissances et
contribue dans ce cadre à la définition de protocoles d’évaluation adaptés à ce domaine
de recherche.
Cette collaboration, complémentaire, de deux organismes acteurs de l’évaluation trace
l’intersection entre le besoin d’organiser des évaluations de manière efficace et pérenne et
celui d’élaborer et de mettre au point les outils clés dans les domaines du TAL.
1.2.2
Des projets divers et variés
Nous résumons ci-dessous les caractéristiques des projets les plus pertinents et dont les
résultats ont été utilisés dans cette thèse pour donner une vue globale des expérimentations
sur lesquelles elle repose. Ces projets entrent dans deux catégories qu’il est nécessaire de
1. http ://www-lipn.univ-paris13.fr
2. http ://www.quaero.org
5
distinguer du point de vue méthodologique et organisationnel : les campagnes d’évaluation,
pour lesquelles un des objectifs est de comparer des systèmes entre eux en effectuant des
tests de performance ; les évaluations de systèmes isolés, où l’objectif est d’estimer la
qualité propre à un système par rapport à l’état de l’art.
Ces projets successifs nous permettent, entre autres, de tester nos approches sur de
nombreux domaines, technologies et thématiques de recherche. Bien que les exemples fournis focalisent essentiellement sur des domaines bien spécifiques (traduction automatique,
analyse syntaxique, etc.), ils nous permettent d’envisager l’automatisation souhaitée à
l’ensemble des domaines du TAL. Nous tentons d’explorer le maximum d’approches possibles à la fois dans un but d’élargissement et de généralisation des cas de figure. Ces
projets sont décrits dans la section suivante.
1.2.2.1
Les campagnes d’évaluation
TC-STAR [Mostefa et al., 2006, Mostefa et al., 2007a, Hamon et al., 2007b,
Hamon et al., 2008a, Hamon et Mostefa, 2008a, Hamon et Mostefa, 2008b], soutenu
par la Commission Européenne dans le cadre du sixième programme-cadre, est un
projet européen qui a pour but d’identifier les avancées technologiques des systèmes de
traduction automatique de l’oral vers l’oral dans un contexte multilingue (reconnaissance
automatique de la parole, traduction automatique et synthèse vocale). L’évaluation de
ces technologies y a aussi une part importante. Le projet réunit de nombreux acteurs
du domaine provenant de divers pays européens et a pour objectif de réduire l’écart
de performance entre les humains et les machines. TC-STAR se concentre sur trois
paires de langues : de l’anglais vers l’espagnol, de l’espagnol vers l’anglais et du chinois
vers l’anglais. Des compétitions annuelles sont organisées, au cours desquelles les trois
technologies sont évaluées sur des données issues des débats des sessions plénières du
parlement européen (pour l’anglais vers l’espagnol et l’espagnol vers l’anglais) ou sur des
données de l’émission radiophonique Voice of America (pour le chinois vers l’anglais). Par
exemple, lors de sa seconde année d’évaluation (sur les trois ans du projet), 30 organismes
ont participé : 8 pour la reconnaissance vocale, 12 pour la traduction automatique et
enfin 10 pour la synthèse vocale.
CESTA
[Surcin et al., 2005,
Hamon et al., 2006,
Hamon et al., 2007a,
Hamon, 2007b, Hamon, 2007a, Hamon et al., 2008c] est le premier projet européen
proposant une évaluation de systèmes de traduction automatique pour les deux directions
de traduction que sont l’anglais vers le français et l’arabe vers le français. Il s’est déroulé
dans le cadre de l’action Technolangue financée par le Ministère de la Recherche français.
Le but de ce projet est triple : fournir un protocole d’évaluation orienté utilisateur
pour l’évaluation des systèmes de traduction automatique, évaluer différents systèmes
académiques et commerciaux et enfin introduire des mesures d’évaluation expérimentales
automatiques et estimer ces mesures en les comparant à des évaluations conduites par
des juges humains. Au total 13 systèmes (10 pour l’anglais vers le français, 3 pour l’arabe
vers le français) ont participé aux deux campagnes d’évaluation proposées. La première
portait sur un domaine dit « général », la seconde sur un domaine de spécialité (la santé).
CESART
[Mustafa El Hadi et al., 2005,
Mustafa El Hadi et al., 2006,
Timimi et Mustafa El Hadi, 2008] s’inscrit dans la suite de la campagne d’évaluation d’outils d’acquisition de ressources terminologiques à partir de corpus écrits, ARC
A3 [Béguin et al., 1997]. Les systèmes évalués au cours de la seule campagne d’évaluation
6
couvrent deux modes d’acquisition de ressources terminologiques : les extracteurs
terminologiques et les extracteurs de relations sémantiques. La compétence de l’expertise
humaine lors d’une évaluation manuelle a été nécessaire pour estimer la qualité des
systèmes, dans le cadre des deux tâches d’évaluation : l’extraction des termes pour
la construction d’un référentiel terminologique (tâche T1) et l’extraction des relations
sémantiques à partir d’une liste amorce (tâche T2). Cinq systèmes ont participé à la
première tâche, tandis qu’un seul a participé à la seconde tâche. De plus, les systèmes
ont été testés sur deux domaines différents (la santé et l’éducation).
PASSAGE [Villemonte de la Clergerie, 2007, Villemonte de la Clergerie et al., 2008]
(« Produire des Annotations Syntaxiques à Grande Échelle ») a pour principal objectif
de créer semi-automatiquement un large corpus annoté syntaxiquement sur différents domaines. Dans un même temps, la pertinence des analyseurs utilisés est estimée au cours
de deux campagnes d’évaluation. Au final, en combinant plusieurs des analyseurs impliqués, une fusion des résultats des analyseurs est constituée afin de construire un corpus
du français annoté syntaxiquement. Le corpus est ensuite validé manuellement pour les
points les plus ambigus. Les ressources ainsi produites sont alors réutilisées par les analyseurs et le processus recommence alors (toujours en vue d’améliorer la qualité du corpus
annoté syntaxiquement et des analyseurs). Par ailleurs, la méthodologie d’évaluation est
également étudiée, notamment au travers du développement d’une architecture d’évaluation accessible par l’ensemble des participants au projet. Les analyseurs syntaxiques sont
évalués selon deux critères : par type de constituants (noyau verbal, groupe nominal, etc.)
et par type de relations (sujet/verbe, COD, etc.).
Infile 1 (Information, Filtrage, Evaluation) a pour but l’organisation de campagnes
d’évaluation autour du filtrage d’information cross-lingue. Trois langues ont été sélectionnées : l’anglais, le français et l’arabe. Les systèmes participants sont évalués sur des corpus
de fil de presse fournis par l’AFP 2 (Agence France Presse).
EQueR [Ayache et al., 2006] a pour objectif l’évaluation des systèmes de questionréponse dans un contexte général (constitué de documents issus du domaine journalistique) d’une part et spécialisé (dans le domaine médical) d’autre part. Au total, sept
systèmes ont été évalués.
1.2.2.2
Synergies
La mise en parallèle de ces campagnes permet d’induire et d’exploiter des synergies
entre technologies au niveau de l’évaluation. Il ne faut pas négliger l’apport d’une technologie à une autre, que ce soit au niveau des ressources linguistiques ou des mesures d’évaluation. Il est très fructueux d’organiser des rencontres entre communautés travaillant
sur des technologies différentes (comme par exemple lors des conférences JEP/TALN,
LREC, etc.). Ces croisements favorisent le développement de la recherche sur les méthodes et outils de mesure.
De plus, le cadre de toutes ces campagnes d’évaluation enrichit notre réflexion, dans
un contexte pratique, sur la problématique de l’évaluation afin d’arriver à en extraire les
composants communs. C’est un point essentiel pour mener à bien des évaluations au sein
d’une architecture générique.
1. http ://www.infile.org
2. http ://www.afp.com
7
1.2.2.3
L’évaluation d’un système isolé
L’évaluation d’un système isolé est une autre méthode d’évaluation. Les mesures d’évaluation sont similaires à celles d’une campagne d’évaluation dans la majorité des cas 1 ,
mais la méthodologie n’est pas la même. Les méthodes et ressources utilisées diffèrent
en terme d’échelle et il est nécessaire de bien faire la distinction entre une campagne
d’évaluation, pour laquelle l’objectif est souvent de comparer des systèmes entre eux, et
l’évaluation d’un système isolé, pour laquelle c’est la qualité du système dans l’absolu qui
est analysée. Dans ce dernier cas, le système n’est pas comparé à d’autres systèmes. Le
diagnostic n’est pas le même non plus et il est nécessaire de garder à l’esprit qu’il doit mener à l’amélioration d’un système par ses développeurs ou à un choix par ses utilisateurs
potentiels (d’achat, de téléchargement, etc.).
Nous aborderons ce point à partir de cas particuliers autour de l’évaluation d’un système de traduction de l’oral vers l’oral. Deux technologies ont été évaluées : la traduction
automatique et la combinaison d’un système de reconnaissance de la parole et d’un système de traduction automatique) [Hamon et al., 2009].
1.3
Conclusion et plan de thèse
Dans ce chapitre, nous avons abordé en guise d’introduction le contexte de travail de
notre thèse. L’aspect principal de notre thèse consiste en la modélisation d’une architecture
d’évaluation pérenne et générique de technologies du traitement automatique des langues.
Cela nous amène à une recherche axée autour du paradigme d’évaluation des technologies
et, d’une manière plus large, autour du cadre scientifique et économique de l’évaluation.
Dans ce contexte, l’aspect qui prime est sans nul doute l’automatisation de l’évaluation : les protocoles, les mesures ou encore l’organisation sont autant d’enjeux à explorer
lors de la définition de notre architecture. Un de nos axes de recherche est l’observation
des mesures manuelles et les moyens de remplacement par des mesures automatiques,
autant que faire se peut. Pour pallier une automatisation éventuelle, l’architecture doit
offrir une interface pour la réalisation des jugements humains et en tenir compte pour
la visualisation des résultats. Lorsqu’une mesure automatique est disponible, sa partie
technique, les métriques automatiques, doit être adaptée à l’architecture. Toutefois, l’utilisation de mesures automatiques implique de valider les résultats produits : des résultats
calculés automatiquement n’ont de sens que s’ils sont corrects, c’est-à-dire représentatives
des vraies performances des systèmes.
Dans le chapitre 2, nous présentons un état de l’art relatif au domaine de l’évaluation en
traitement automatique des langues. Les aspects théoriques et pratiques y sont développés.
Nous fournissons également un état des lieux du vocabulaire et de la terminologie de
l’évaluation qui est complété par un glossaire en fin de thèse. Finalement, nous nous
positionnons par rapport à cet état des lieux et nous présentons nos objectifs. Ceuxci peuvent se résumer à l’étude des mesures d’évaluation (humaines et automatiques),
l’automatisation de l’évaluation et enfin la modélisation d’une architecture d’évaluation
générique et pérenne.
1. Dans le cas contraire, il peut aussi s’agir de mesures de comparaison entre systèmes, comme la
mesure de préférence en traduction automatique, comparant les sorties entre systèmes, phrase à phrase.
8
1.3. Conclusion et plan de thèse
Dans le chapitre 3, nous introduisons l’évaluation dans sa partie la plus pratique en
étudiant son organisation et son déroulement. Notre propos se focalise avant tout sur
les aspects liés aux campagnes d’évaluation, comme l’image à grande échelle de toute
évaluation. Chaque évaluation, même d’un système isolé, n’est finalement que le reflet
d’une campagne d’évaluation à moindre échelle réduite à ses aspects les plus élémentaires.
Dans le chapitre 4, c’est un des aspects primordiaux d’une évaluation qui est abordé :
les ressources linguistiques. D’elles dépendront bien souvent les résultats d’une évaluation
ainsi que son déroulement, c’est un élément à ne pas négliger. Nous traiterons avant tout les
aspects pratiques (création, standardisation, validation, impact) mais aussi administratifs
(coût, identification, négociation).
Le chapitre 5 fait état des mesures d’évaluation et de leur propre évaluation (appelée
méta-évaluation), qu’elles soient manuelles ou automatiques. Nos expérimentations pour
la création de nouvelles mesures sont présentées dans ce chapitre.
Dans le chapitre 6, nous discutons des similarités des technologies et de leurs mesures
d’évaluation en traitement automatique des langues. C’est un point crucial avant d’aborder la modélisation de notre architecture. Nous cherchons dans ce chapitre à comprendre
et à déterminer quels sont les points communs entre les différentes technologies du TAL et
leur évaluation, quels sont les rapprochements à faire et quelles sont leurs caractéristiques
propres.
Finalement, nous présentons la modélisation de notre architecture d’évaluation dans le
chapitre 7. Cela se fait tout d’abord en évoquant nos retours de premières expériences puis
en discutant les difficultés et les différentes approches techniques. Enfin, nous proposons
notre propre vision d’une architecture d’évaluation générique et pérenne.
La thèse se conclut dans le chapitre 8 autour de réflexions sur l’évaluation de la modélisation d’une architecture d’évaluation. Nous résumons les réalisations de cette thèse
puis nous explorons les futurs travaux que nous envisageons de suivre.
9
10
Chapitre 2
L’évaluation en traitement automatique
des langues
De nombreux protocoles, métriques et méthodologies d’évaluation ont été définis au
cours des quelques 60 dernières années. Les accomplissements ont été considérables depuis
l’essor des premières campagnes ARPA au début des années 70. Toutefois, le chemin est
encore long à parcourir avant de déterminer avec efficacité les points forts ou les faiblesses
d’un système selon les attentes des utilisateurs, ou même de comparer objectivement un
système à un autre. Nous nous trouvons dans un contexte de développement croissant
de technologies imprégnées d’outils de TAL (recherche d’information, traduction automatique, etc.). L’évaluation de ces technologies est une étape indispensable afin de justifier
l’emploi de telle ou telle méthodologie ou système dans tel contexte applicatif. Que ce
soit pour les développeurs d’un système ou pour ses utilisateurs, il est indispensable de
connaître ses performances avant une mise en production ou une utilisation finale. La
difficulté d’apprécier les performances d’un quelconque système de TAL est accrue par la
variabilité de l’ensemble de ses caractéristiques.
L’évaluation s’est généralisée à l’ensemble des domaines du traitement automatique
des langues et de nombreuses technologies ont désormais leur lot de protocoles et mesures,
voire de campagnes d’évaluation régulières. Cependant, la part de l’évaluation n’est pas
homogène selon les technologies. Historiquement, la reconnaissance de la parole est considérée comme étant pionnière en terme d’évaluation, du simple fait que cette technologie
a connu les premières campagnes d’évaluation organisées. De manière moins établie, la
traduction automatique et l’analyse syntaxique n’ont pas été en reste : elles ont profité des
avancées technologiques et du besoin de les prouver. L’évaluation s’est ensuite étendue de
manière plus ou moins efficace à des systèmes ayant des approches éloignées, certes, mais
ayant des besoins similaires en mesure de qualité.
2.1
Le traitement automatique des langues
Il est difficile de parler d’évaluation en traitement automatique des langues sans aborder le TAL en lui-même, et dresser un bref bilan historique, politique et économique du
domaine au cours des 60 dernières années. En effet, l’automatisation des traitements linguistiques a pris beaucoup d’importance du fait des ambitions politiques au sortir de la
11
Chapitre 2 : L’évaluation en traitement automatique des langues
Seconde Guerre Mondiale. Plus tard, notamment avec la fin de la Guerre Froide, les perspectives économiques prennent le dessus. Mais c’est bien l’évaluation qui est au centre
des débats même si sa mise en œuvre ne devient effective que quelques années plus tard :
c’est aussi en fonction des performances de systèmes que les programmes de recherche se
sont dessinés.
2.1.1
Vision historique
Au sortir de la Seconde Guerre Mondiale, les premiers calculateurs sont développés
aux alentours de 1946 et leurs performances s’améliorent très vite avec l’apparition des
transistors en 1948, puis des circuits intégrés en 1965. L’arrivée de l’informatique va
donner naissance au traitement automatique des langues et leurs devenirs seront alors
étroitement liés. Chaque nouvelle montée en puissance ou en capacité des ordinateurs
bouleverse à chaque fois le traitement automatique des langues. Certains vont très vite
comprendre l’intérêt de l’ordinateur pour la linguistique, en s’attaquant notamment au
mythe de Babel, la traduction automatique. Il en sera de même pour l’une des disciplines
de base des sciences du langage, l’analyse syntaxique.
Un des pionniers en la matière, le mathématicien Warren Weaver, pensait dès 1947
à utiliser les calculateurs afin de produire des traductions automatiques, tout en restant conscient des limites : Même si je traduisais uniquement du matériel scientifique
(pour lequel les difficultés sémantiques sont bien moindres), et même si cela ne produisait
qu’un résultat pas très élégant (mais intelligible), il me semble que ça vaudrait le coup
[Weaver, 1955].
Bien que l’approche reste assez simpliste, il n’en reste pas moins que les premières
communications entre Weaver et ses collègues inaugurent les débuts de la traduction automatique. Dans un contexte de Guerre Froide, mais aussi d’un futur planétaire constructif
et de paix (sic), l’intérêt pour une automatisation de la traduction est fortement accru. Le
Memorandum de 1949, écrit par Weaver [Weaver, 1955], est alors le stimulant pour la recherche en traduction automatique aux États-Unis [Hutchins, 1997]. Il en demeure le texte
fondateur. La plupart des aspects théoriques et pratiques y sont abordés, et la question
encore bien actuelle de la fiabilité des traductions produites automatiquement et celle des
difficultés du traitement automatique des langues sont déjà clairement connues (comme
par exemple le cas de traductions multiples dépendant du contexte). Cependant, l’apparition de la traduction automatique n’est pas le fait d’un seul homme. L’enthousiasme
naissant est celui de nombreux groupes de chercheurs venant, il est vrai, essentiellement
des États-Unis : il peut être utile de mentionner ici d’autres pionniers tels que Andrew
Booth, Norbert Wiener ou encore Richard Richens, qui font partie des quelques deux
cents scientifiques auxquels Weaver avait envoyé son Memorandum [Cori et Léon, 2002].
En 1952, la première conférence sur la traduction automatique (Conference on Mechanical Translation, Massachusetts Institute of Technology - MIT ) a lieu sous la direction de
Yehoshua Bar-Hillel et en 1954 le premier journal dédié paraît, édité par William Locke
et Victor Yngve sous le nom Mechanical Translation. À l’époque, il est déjà très clair
qu’une traduction automatique parfaite n’est pas possible et que l’intervention humaine
est indispensable, par exemple en vue d’une post-édition (la traduction est manuellement
corrigée, a posteriori ). En effet, dès 1953, Bar-Hillel préconise une traduction assistée par
ordinateur, une traduction de haute qualité (FAHQT, pour Fully Automatic High Quality
12
2.1. Le traitement automatique des langues
Translation) n’étant réalisable que par un humain [Bar-Hillel, 1953].
Un premier système de traduction automatique rudimentaire est mis au point en 1954
par IBM (Peter Sheridan) et l’université de Georgetown (Paul Garvin). Quarante-neuf
phrases sont alors traduites du russe vers l’anglais avec un vocabulaire de 250 mots
et seulement 6 règles de grammaire. L’intérêt scientifique est faible, mais la portée est
telle que cela favorise l’émergence de nombreux projets, aux États-Unis, mais aussi dans
le monde entier et notamment en Union Soviétique, en Grande-Bretagne et en France
[Hutchins, 2001]. Les années 50 voient émerger de nombreuses approches fondamentales
(linguistique distributionnelle par Zellig Harris en 1954, théorie des langages formels par
Chomsky en 1957) et l’essor se poursuivra jusqu’au début des années 60.
C’est à la fin de cette période qu’apparaît l’intelligence artificielle, l’idée étant d’avoir
des ordinateurs capables d’appréhender le langage et la réflexion. En France, l’ATALA
(Association pour l’étude et le développement de la Traduction Automatique et de la Linguistique Appliquée, animée par Emile Delavenay) est créée en 1959, ainsi que la première
revue française La Traduction Automatique. Les premiers traducteurs automatiques voient
le jour, ainsi que les premières désillusions. L’exemple sans doute le plus célèbre concerne
la traduction de la phrase The spirit is willing but the flesh is weak (L’esprit est fort
mais la chair est faible) en russe. La traduction inverse du russe vers l’anglais de cette
traduction donnait alors The vodka is good but the meat is rotten (La vodka est bonne
mais la viande est pourrie). Au-delà de son côté amusant, ce genre de traduction pose
le problème de la connaissance du monde général et du contexte des textes à traduire :
ici, certains termes ont été traduits en fonction du sens spécifique à un autre contexte
que celui propre à cette phrase (par exemple spirit comme en tant qu’alcool plutôt que
l’esprit humain).
Finalement, l’optimisme des débuts chute radicalement à la suite de deux rapports
successifs. Un premier rapport de Bar-Hillel en 1960 critique la possibilité qu’une traduction automatique ne puisse pas se distinguer d’une traduction humaine (et doute par la
même occasion de la capacité à obtenir un jour une FAHQT). Son étude ne se base pas sur
l’état des ressources de l’époque, mais sur le principe en lui-même. L’impact est important
au sein de la communauté. Aussi, en 1964, les sponsors gouvernementaux de la recherche
commandent-ils au National Science Fondation de définir un comité afin d’examiner les
possibilités du domaine. Cela a mené au célèbre rapport ALPAC (Automatic Language
Processing Advisory Committee). Ce rapport provoque la réduction drastique des investissements de la recherche en traduction automatique tout en mettant en lumière l’échec de
la recherche au cours des années précédentes. L’influence du rapport ALPAC est profonde
mais ses conclusions sont à relativiser : la traduction automatique y est décrite comme
étant « plus lente, moins précise et deux fois plus chère qu’une traduction humaine » et
il est dit « qu’il n’y a aucune perspective immédiate ou prédictible pour une traduction
automatique utile » [ALPAC, 1966]. Ce rapport est déjà critiqué à l’époque (car biaisé et
manquant de vue à long terme) et l’état actuel de la traduction automatique tend à nous
prouver le contraire de ces deux affirmations. Il faut noter que les conclusions du rapport
appellent au développement d’outils d’aide aux traducteurs humains et à la poursuite du
soutien à la recherche en linguistique computationnelle [Hutchins, 2001]. Autrement dit,
si le rapport ALPAC sonne presque le glas de la traduction automatique en tant que telle,
il ouvre aussi la recherche à d’autres domaines de la linguistique computationnelle.
Ainsi, parallèlement au déclin de la traduction automatique, la linguistique compu13
tationnelle, elle, prend de l’intérêt aux yeux des scientifiques (parmi lesquels certains
avaient effectivement senti venir la tempête ALPAC). En 1965, la première conférence
internationale traitant de la linguistique computationnelle a lieu, qui deviendra la conférence Coling 1 , toujours organisée tous les deux ans. D’autres domaines émergent, tels que
l’analyse syntaxique (bien que déjà en vogue dès le début des années 50) ou l’intelligence
artificielle. De nombreux outils apparaissent, se rapprochant plus de l’intelligence artificielle et fondés sur des mots clef et des patrons syntaxiques. Ainsi, le programme ELIZA
en 1966 [Weizenbaum, 1966] simule un dialogue entre un patient et un psychothérapeute,
ou le programme SHRDLU [Winograd, 1971] permet l’interaction entre un humain et un
robot placé dans un univers composé de formes diverses et utilisant une approche plus
sémantique.
Des approches plus pragmatiques ont vu le jour à la fin des années 70, comme le
système de dialogues dirigés par la tâche, Grosz (1977). C’est au cours de cette période
que la traduction automatique émerge à nouveau avec l’apparition d’applications commerciales, comme par exemple Systran en 1975. La revue American Journal of Computational
Linguistics est créée en 1974 (faisant suite à la revue Mechanical Translation, elle sera renommée Computational Linguistics en 1984, traduisant l’évolution du traitement automatique des langues [Cori et Léon, 2002]) et désormais de nombreux domaines sont abordés :
correction orthographique, traitement de la parole, dialogue homme-machine, etc.
Depuis le début des années 80, d’autres méthodes émergent, laissant apparaître l’étude
du contexte, de la situation d’énonciation ou du raisonnement par analogie. Le traitement
automatique des langues a de plus en plus l’objectif d’un développement effectif de systèmes, notamment pour le grand public avec la généralisation de l’ordinateur personnel.
De nouvelles approches émergent aidées par le développement de l’Internet au début des
années 90 : travaux sur des textes réels, à large couverture ou approches statistiques nécessitant de grandes quantités de données. La plupart de ces approches ont été étudiées
dès le début des années 80 mais l’explosion de la puissance des ordinateurs les a rendues
souvent plus robustes. Le traitement automatique des langues tend à se focaliser sur la
recherche d’information, l’interrogation et l’exploitation de grandes masses de connaissances. Cela est sans doute dû au besoin des chercheurs de tester de nouvelles approches
suite à l’échec relatif des précédentes, mais aux facilités d’accès à de grande quantités de
données. Le monde du traitement automatique des langues a progressivement privilégié
les approches statistiques nécessitant un apprentissage du modèle recherché pour accomplir une tâche précise, par opposition aux approches à base de règles (sans toutefois s’en
passer définitivement) .
2.1.2
Applications et enjeux
Depuis quelques années maintenant, les développements technologiques rendent accessibles aux particuliers et aux entreprises des systèmes du TAL. En tant que telles, les
applications disponibles couvrent un vaste répertoire, d’autant plus que le développement
croissant de l’Internet pousse beaucoup d’acteurs du domaine à mettre en ligne leurs outils
linguistiques. Les enjeux, avant tout économiques, sont énormes. Il s’agit bien sûr, historiquement, de la traduction automatique : la masse de données à traduire est de plus en plus
importante (e-mails, articles, blogs, documents officiels, etc.) et la mondialisation gagne
1. http ://www.coling-2010.org
14
du terrain au travers d’Internet et des offices internationaux et gouvernementaux (ONU,
UNESCO, Union Européenne, etc.). D’autres outils de traduction sont aussi mis en avant
comme l’apprentissage des langues, la traduction de l’oral ou encore la traduction assistée par ordinateur. L’autre grand enjeu économique concerne la recherche d’information :
veille technologique ou stratégique, moteurs de recherche, etc.
Les apports récents de l’informatique expliquent en partie l’évolution du traitement
– augmentation de la puissance et de la capacité des ordinateurs : développement des
approches statistiques, larges quantités de données traitées, etc. ;
– amélioration du réseau et des taux de transfert : échange de données facilité, traitement plus aisé en recherche d’information, etc. ;
– nouveaux modes de communication : téléphones portables, systèmes embarqués. Ces
moyens de communication nécessitent de nouvelles approches mais créent aussi de
nouveaux besoins (comme par exemple une traduction orale à l’aide de son téléphone
portable, pour la réservation d’un hôtel à l’étranger [Stüker et al., 2006]).
D’après le rapport Van Dijk sur le marché et les tendances des technologies de la langue
en Europe (Van Dijk, 2006) sur l’année 2006, l’Europe comporte 160 millions d’internautes
(sur 460 millions d’habitants) et les dépenses en nouvelles technologies de l’information et
de la communication (NTIC) représentent 6 % du PIB (Produit Intérieur Brut). D’autre
part, il existe 482 sociétés européennes présentes de près ou de loin sur le marché des NTIC.
Ce marché n’a cessé de croître depuis le début des années 2000. La répartition de l’offre
est assez déséquilibrée entre le traitement textuel (70 %) et le traitement vocal (30 %).
Toutefois, il est à noter qu’une majorité des grands leaders européens sont spécialisés sur
le traitement vocal et que celui-ci est en tendance ascendante, les services de téléphonie
ayant de plus en plus de poids sur le marché.
2.1.3
Niveaux de traitement
Il est possible de considérer plusieurs niveaux d’analyse pour la compréhension d’un
document écrit en langage naturel (cf. figure 2.1). Le parcours de ces niveaux n’est pas
toujours linéaire, par exemple pour faciliter l’analyse.
La base de tout traitement est de reconnaître les formes de base de manière à
segmenter le document en unités. Les séparateurs et autres signes de ponctuation sont
pris en compte. Par exemple, la difficulté est de savoir distinguer un mot sachant que les
séparateurs peuvent être ambigus (en français, les fins de phrase sont marquées par des
points, qui apparaissent aussi dans les sigles ou les abréviations, et que faire, par exemple,
d’un sigle situé en fin de phrase...) et qu’une segmentation est dépendante de la langue
(la partie décimale est notée par une virgule en français et par un point en anglais, la
plupart des langues asiatiques n’ont pas de séparateurs). Les formes de base sont également
facteurs d’ambiguïté, notamment lorsqu’elles ne font pas partie du vocabulaire connu.
Le traitement lexical permet d’identifier les unités lexicales et de définir leurs
propriétés. Une analyse morpholexicale caractérise les formes de base reconnues par le
segmenteur et fournit toutes sortes d’informations à partir de lexiques et de règles morphologiques.
Ensuite, le traitement syntaxique permet de définir des groupes de taille supérieure
au mot (les constituants comme les groupes nominaux, les groupes verbaux, etc.) et les
15
Figure 2.1 – Les niveaux d’analyse du traitement automatique des langues.
relations de dépendance qu’ils entretiennent entre eux. À partir de grammaires, l’analyse
syntaxique vise l’étude des contraintes entre les catégories morphosyntaxiques, préalablement déterminées. Elles doivent être prises en compte afin de décrire des séquences
de phrases grammaticalement acceptables (ou correctes, selon la tâche). La résolution des
ambiguïtés à ce niveau facilite la représentation sémantique qui est construite par la suite.
En effet, de nombreuses ambiguïtés lexicales (vert : adjectif ou nom masculin singulier)
et liées au contexte (se mettre au vert) apparaissent.
Le traitement sémantique construit une représentation du sens afin de comprendre
le document. L’analyse sémantique consiste à étudier une unité de niveau phrastique
et à représenter conceptuellement sa partie significative. Ainsi, des expressions de type
logique représentent des relations entre les objets liés à la situation et ont pour but de
comprendre le sens de l’énoncé. De nombreuses difficultés rendent l’analyse compliquée,
comme la résolution des anaphores 1 (l’avocat a défendu son client, je l’ai vu pleurer :
qui a pleuré ?) ou le rattachement syntaxique (le propriétaire du chien qui n’arrête pas de
hurler ).
Finalement, le traitement pragmatique consiste à identifier et contextualiser le sens
concret du document, dans le contexte particulier de sa production. Il s’agit de la phase
pour laquelle on s’approche le plus du processus de compréhension humaine. La difficulté
du traitement consiste à repérer l’implicite, les attitudes et présupposés qu’un humain
aurait.
2.1.4
Difficultés
Deux difficultés majeures se distinguent en traitement automatique des langues : l’ambiguïté et l’implicite. La compréhension d’un document nécessite une désambiguïsation
morphosyntaxique (le terme partie peut correspondre à la fois au substantif féminin décrivant une portion d’un tout, mais aussi au participe passé du verbe partir ) et une
désambiguïsation lexicale (dans la phrase j’ai acheté un avocat pourri, le terme avocat
peut autant correspondre au fruit de l’avocatier qu’à l’homme de loi). Cette dernière est
1. La résolution des anaphores se fait aussi au niveau du traitement pragmatique.
16
fortement liée à la connaissance de l’univers contextuel du document (j’avais faim, j’ai
donc acheté un avocat, le lecteur comprend aisément qu’il s’agit d’un fruit 1 ). De manière
plus complexe, la compréhension d’un document passe par une désambiguïsation structurelle (la phrase c’est l’avocat de l’accusé qui a volé les pommes n’indique pas si c’est
l’avocat ou l’accusé qui a volé les pommes).
Au-delà de l’ambiguïté concernant la compréhension d’un texte, il y a également celle
concernant sa génération, et l’adaptation au récepteur afin qu’il comprenne bien le sens du
document. Dès lors que le vocabulaire d’un document est limité à un domaine spécifique,
l’ambiguïté peut, dans une certaine mesure, être levée. En effet, un vocabulaire plus limité
réduit la connaissance sur le monde qu’a l’outil automatique. De fait, un terme, ou une
structure grammaticale, ne trouvera pas (ou moins) de synonymes dans un vocabulaire
spécialisé (si l’avocat est acheté, on comprend qu’il y a acte de corruption dans le contexte
d’un document juridique 2 ).
2.1.5
Domaines d’application
Qu’elles répondent à des besoins professionnels ou privés, différentes tâches sont effectuées avec des systèmes du TAL selon des besoins bien spécifiques. Un premier découpage
consiste à distinguer les modalités de communication, et le type des données utilisées,
selon qu’elles proviennent de la langue orale, de la langue écrite ou du multimodal.
Ensuite, les technologies sont caractérisées par leur finalité : il existe des systèmes
finaux, applications ou produits pour l’utilisateur, ou des systèmes intermédiaires, utilisés
généralement par d’autres systèmes ou ne servant que d’assistance pour une étape humaine
conséquente.
Cette caractéristique de finalité n’est pas binaire : les outils sont plus ou moins intermédiaires et se positionnent sur une échelle graduée allant d’un niveau totalement
intermédiaire et produisant des résultats peu exploitables par un humain en tant que tels
(comme par exemple, à l’extrême : la lemmatisation, la segmentation, l’analyse morphologique, etc.), à un niveau directement utilisable (par exemple une traduction automatique).
Notre thèse a pour vocation d’être applicable à de nombreux types de technologies,
quel que soit leur niveau de finalité ou le type des données qu’elles utilisent. Ce choix est dû
à nos possibilités d’étude sur différents projets comme ceux présentés dans le chapitre 1.
Nous décrivons ci-dessous différentes technologies de traitement de la langue, cette liste
étant non exhaustive.
Les technologies de traitement du langage écrit permettent d’analyser, de générer ou
de transformer des données textuelles, comme par exemple :
– La recherche d’information qui consiste à représenter structurellement des informations selon leur degré de pertinence afin d’aider l’utilisateur à trouver les documents
l’intéressant.
– L’extraction de l’information qui permet d’identifier des informations pertinentes
dans un contexte spécifique pour les représenter sous forme structurée. Ces informations peuvent être de type entités nommées (un lieu, une personne, une organisation,
une date, etc.), évènements, passage d’un document, etc.
1. Exception faite d’un livre fantastique où des hommes de loi sont mangés...
2. Mais les contres-exemples sont toujours possibles : il peut très bien s’agir du jugement d’un vol à
l’étalage au cours duquel des avocats n’ont pas été achetés.
17
– La traduction automatique qui permet de convertir un texte source écrit en langue
A en un texte cible écrit en langue B.
– Le résumé automatique de texte qui consiste à extraire une ou des parties de documents pertinentes et à les présenter sous forme synthétique.
– La correction grammaticale, à partir de l’analyse syntaxique, qui permet de représenter un texte sous forme structurée en fonction de la grammaire de la langue du
texte.
– L’alignement multilingue de textes qui consiste à identifier des correspondances
entre deux documents parallèles de deux langues différentes et à les aligner selon
des critères variables (mot, phrase, paragraphe, document).
– L’analyse en question-réponse qui consiste à renvoyer une ou plusieurs réponses à
une question sous forme d’un paragraphe, d’une expression ou d’un terme.
– L’extraction terminologique qui consiste à renvoyer des termes ou des relations représentatifs d’un corpus de documents.
Les technologies de traitement de la langue orale permettent d’analyser des données
de la parole et/ou de les transformer à partir ou vers des données textuelles, comme par
exemple :
– La synthèse de la parole qui consiste à synthétiser un document au format oral à
partir d’un document au format texte.
– La reconnaissance de la parole qui consiste à transcrire un document oral en un
document texte.
– La détection de parole qui permet d’identifier dans un document audio les passages
parlés par un locuteur.
– La reconnaissance de la langue qui permet de reconnaître la langue d’un document
oral.
– La reconnaissance du locuteur qui permet d’identifier le ou les locuteur dans un
document oral.
Les technologies de traitement multimodal sont liées aux interactions homme-machine,
comme par exemple :
– La biométrie qui consiste à capturer des informations sur des éléments morphologiques ou comportementaux d’un être humain tels que la voix, l’iris, la gestuelle,
etc.
– Les interfaces multimodales, combinaison de différentes technologies (audio, image,
et/ou vidéo), qui permettent des interactions humaines ou homme-machine.
– Les interfaces vocales qui permettent l’interaction humaine sur des technologies
orales (par exemple la reconnaissance de la parole ou la synthèse de la parole).
Des combinaisons de technologies sont également envisageables, le besoin d’interconnecter les technologies étant de plus en plus fréquent. Par exemple, la traduction automatique de l’oral vers oral permet la traduction d’un document audio, présentée elle-même
sous forme orale : elle combine un composant de reconnaissance de la parole, un composant
de traduction automatique et un composant de synthèse de la parole.
Dans cette thèse, nous nous intéressons avant tout aux systèmes du traitement de
l’écrit mais de manière non restrictive. En effet, des systèmes traitant l’écrit sont souvent
combinés à des systèmes de traitement de l’oral ou du multimodal et il est nécessaire de les
prendre en compte. Aussi, il est intéressant d’avoir connaissance d’autres technologies et
de leurs différentes applications afin de modéliser une architecture générique et pérenne.
18
2.2. Évaluation en traitement automatique des langues
2.2
2.2.1
Évaluation en traitement automatique des langues
Généralités
L’évaluation est un élément essentiel pour estimer les performances d’un système. Que
ce soit pour un aperçu général ou pour une analyse plus fine, il existe trois raisons d’évaluer
un système :
– l’évaluation est un élément moteur pour son développement,
– elle permet de valider les directions de travail,
– de manière pragmatique, elle permet aussi la valorisation du système.
Le développeur est ainsi à même de justifier les investissements réalisés. Au-delà de
l’apport scientifique, il ne faut pas oublier qu’il s’agit également d’un objectif industriel
dans un marché souvent saturé en produits. La plupart du temps, il est d’ailleurs indispensable que les évaluations d’un ou de plusieurs systèmes soient conduites par des agents
extérieurs et sans lien avec leur développement. C’est d’autant plus crucial lorsque l’évaluation porte sur la comparaison de plusieurs systèmes développés par différents acteurs.
Les mesures de qualité nécessaires à toute évaluation se font à travers des jugements
humains ou des métriques automatiques, les applications techniques de la mesure. Cela
fournit des informations sur les performances d’un ou de plusieurs systèmes, dans sa
totalité ou en partie.
Toutefois, il existe différents types, différents niveaux ou encore différentes méthodes
pour évaluer un système de TAL. Cela mène à une grande variété de déroulements possibles. Ces nombreux aspects influencent fortement le résultat des évaluations entreprises
et sont à prendre en compte lors de l’analyse finale.
2.2.2
Historique
2.2.2.1
Les origines
Depuis de nombreuses années, le traitement automatique des langues nécessite l’emploi de méthodes, formelles ou non, pour estimer le niveau de performance des systèmes
développés. De fait, l’évaluation a été dès les premières recherches effectuées un élément
à part du domaine. Chaque expérimentation est évaluée à un moment ou à un autre, soit
de manière informelle en observant simplement les résultats obtenus, soit de manière plus
rigoureuse en mesurant la qualité à l’aide d’une méthodologie bien précise. Ainsi, un effort
conséquent a été consacré au développement de méthodes d’évaluation pour justifier les
travaux de recherche et rendre compte des progrès des systèmes.
L’intérêt croissant pour l’évaluation est tel que l’on peut désormais considérer la discipline comme un domaine à part entière en regroupant l’ensemble des méthodes propres
à chaque technologie. La fréquence des programmes d’évaluation s’est accrue (en particulier ceux organisés aux États-Unis) et chaque projet qui a pour objectif le développement
d’un système contient une partie propre à son évaluation. La conférence internationale
LREC 1 (Language Resources and Evaluation Conference) est devenue un événement majeur. Cette dernière est dédiée aux ressources linguistiques (étude, constitution, utilisation, etc.) et à l’évaluation en traitement automatique des langues autour des mesures,
protocoles, expérimentations, développements, etc.
1. http ://www.lrec-conf.org
19
Nous traçons ci-dessous un historique de l’évaluation en traitement automatique des
langues en parcourant les différentes campagnes et projets qui ont vu le jour au cours
des cinq dernières décennies. Parler de l’évaluation de systèmes isolés est plus compliqué
du fait de leur visibilité réduite, leur nombre et leur manque de standardisation. Au
contraire, les campagnes d’évaluation sont révélatrices des « modes » et approches de leur
temps. Elles ont bénéficié de l’intérêt grandissant des chercheurs et ont connu des phases
importantes, véritables bonds évolutifs des différents mécanismes liés à l’évaluation. D’un
point de vue général, les premières campagnes ont vu le jour dans les années 1960, mais
l’essor de l’évaluation s’est indubitablement produit vers la fin des années 1980.
2.2.2.2
Les prémices
Les premiers tests de systèmes sous forme de campagne d’évaluation remontent aux
années 60 avec les tests de Cranfield I et II [Cleverdon, 1967] en Angleterre, comparant 33
systèmes d’indexation. Les systèmes avaient à indexer 1 400 documents à partir de 331 requêtes. Des jugements de pertinence étaient ensuite donnés manuellement aux documents,
ceux-ci permettant de calculer des scores en rappel et en précision [Cleverdon et al., 1966].
Certains principes de base n’ont que peu évolué depuis ces premières campagnes et sont encore employés dans de nombreuses campagnes actuelles [Sparck Jones et Galliers, 1996],
comme l’engagement d’un panel de systèmes, l’utilisation du rappel et de la précision,
l’évaluation quantitative, l’approche de type boîte noire, etc.
2.2.2.3
L’essor américain
C’est surtout aux États-Unis qu’ont été réalisées les principales avancées en matière
d’évaluation. Ce fut souvent par le biais de programmes fédéraux largement financés
autour de l’ARPA (Advanced Research Projects Agency, renommée DARPA, Defense
Advanced Research Projects Agency) et le NIST (National Institute of Standards and
Technology) 1, et ce dès les années 1970. La plupart des évaluations se font alors en utilisant des mesures de rappel et de précision, ou encore des distances de Levenshtein
[Levenshtein, 1966] (cf. section 5.1.4).
Mais auparavant, le rapport ALPAC (cf. section 2.1.1) a mis en lumière les limites
de la traduction automatique. Il a surtout contraint (de manière non formelle) les développeurs à évaluer leurs systèmes, valorisant de la même façon l’évaluation en traitement
automatique des langues.
Le premier grand programme de recherche américain mené par l’ARPA, SUS (Speech
Understanding Systems) [Klatt, 1977] vise à évaluer les systèmes de reconnaissance de la
parole, domaine pionnier en ce qui concerne l’évaluation. Ce programme s’est déroulé de
1971 à 1976, avec des résultats décevants du fait de systèmes très disparates qui traitent
des langues différentes pour des tâches différentes. On voit dès lors l’importance de l’évaluation comparative, qui permet d’estimer la performance de systèmes par rapport à
d’autres dans un même contexte. De plus, aucun protocole ou mesure n’était assez standardisé à l’époque pour évaluer les systèmes de reconnaissance de la parole. Certains
développeurs se targuaient de taux d’erreur très faibles, quand bien même la comparaison
avec d’autres systèmes n’était pas possible [Bernsen et al., 1999].
1. http ://www.nist.gov
20
Ensuite, l’étude de nouvelles mesures se poursuit en dehors de ces campagnes
d’évaluation. La f-mesure fut développée en 1979 et combine rappel et précision
[van Rijsbergen, 1979] (cf. section 5.1.4). La même année, le rapport Van Slype présente
une étude très approfondie qui a pour thème les mesures d’évaluation des systèmes de
traduction automatique [van Slype, 1979].
Suite au programme SUS, une période moins faste (en terme de campagnes) a suivi
jusqu’au début des années 1980. Elle fut propice à la réflexion et mena au nouveau programme DARPA, démarré en 1984. Il repose sur une évaluation comparative ne prenant
en compte que les entrées/sorties des systèmes (évaluation de type « boîte noire », cf. section 2.2.4.2). Après trois années d’implémentations et de définitions, la première campagne
est conduite en 1987. La série des campagnes MUC (Message Understanding Conference) 1
lui fit suite et conclut à la nécessité de conduire des évaluations comparatives. En effet,
ces campagnes ont montré une amélioration générale de la performance des systèmes, ce
qui a provoqué l’apparition de certains produits sur le marché. Les campagnes MUC-1 à
MUC-7 furent menées jusqu’en 1998, la participation internationale étant ouverte à partir
de 1992. Elles ont été suivies par les campagnes TDT (Topic Detection and Tracking) 2 à
partir de 1998.
Au cours de ces campagnes, la DARPA confia au NIST la mission d’organiser les
programmes d’évaluation du gouvernement américain.
Parallèlement aux campagnes MUC, de nouveaux programmes américains d’évaluation
se sont ouverts à d’autres technologies, comme ATIS (Air Travel Information System)
[Price, 1990] de 1989 à 1995, concernant l’évaluation des systèmes de dialogue appliquée
au domaine du transport aérien. Ces campagnes sont d’une manière générale financées par
la DARPA et coordonnées par le NIST. Ensuite, les campagnes d’évaluation TREC (Text
REtrieval Conferences) 3, débutées en 1991, concernent de nombreuses technologies en
recherche d’information et sont encore en cours à l’heure actuelle. En 1992, les premières
campagnes d’évaluation centrées sur la traduction automatique débutent (DARPA-MT,
NIST-MT 4 ) et sont entreprises de manière périodique depuis 2001. En 1998, SUMMAC 5
est la première campagne organisée pour l’évaluation des systèmes de résumé automatique.
En 1992 est créé le LDC 6 (Linguistic Data Consortium) qui prend en charge la production et la distribution des ressources linguistiques des campagnes d’évaluation du NIST.
2.2.2.4
Le retard de l’Europe et de l’Asie
Avec quelques années de retard sur les programmes de recherche américains, d’autres
actions ont eu cours à des niveaux nationaux (Allemagne, Angleterre, Chine, France,
Japon, etc.) et européens, mais de manière moins pérenne. La plupart d’entre elles ont
été fortement influencées par les méthodologies employées par les programmes américains.
Entre 1982 et 1992, le projet EUROTRA a eu pour objectif la mise en place d’un
système de traduction automatique multilingue pour les neuf langues officielles de la
1.
2.
3.
4.
5.
6.
http
http
http
http
http
http
://www-nlpir.nist.gov/related_projects/muc/
://projects.ldc.upenn.edu/TDT/
://trec.nist.gov
://www.itl.nist.gov/iad/mig//tests/mt/
://www-nlpir.nist.gov/related_projects/tipster_summac/
://www.ldc.upenn.edu
21
Communauté Européenne : anglais, allemand, danois, espagnol, français, grec, italien,
néerlandais et portugais. Une évaluation a été conduite par des experts indépendants.
En 1992, la campagne japonaise JEIDA (Japan Electronics Industry Development Association) [Nomura, 1992] a pour but de déterminer quel système de traduction automatique est le plus approprié pour un utilisateur.
Au niveau européen, les projets Sundial (Speech Understanding and Dialogue, 19881993) [Peckham, 1991] et Plus (A Pragmatics-based Language Understanding System,
1991-1994) [Black et al., 1991] ont comporté des composantes d’évaluation. Mais c’est
surtout le projet SQALE 1 (Speech recognizer Quality Assessment for Linguistic Engineering) qui a pour objectif l’évaluation de systèmes de reconnaissance de la parole de 1993 à
1995. SQALE reprend les principes des tests de l’ARPA Spoken Language Program (dès le
début des années 80 aux États-Unis) en les appliquant au français, à l’anglais britannique
et à l’allemand. Ces projets montrent la prépondérance originelle des technologies de la
parole en évaluation.
Sur la même période (1993-1996), le projet allemand VerbMobil 2 a pour but le développement d’un système de traduction en temps réel. Une évaluation du système est alors
conduite [Nübel, 1997].
Au niveau de la recherche française et francophone, l’Aupelf-Uref (dorénavant AUF,
l’Association des Universités Francophones) lance sept campagnes pour le traitement de
langue écrite et parlée, qui se sont déroulées de 1994 à 1999, lors de l’Action de Recherche Concertée 3 (ARC). Les domaines concernés étaient la recherche d’information
(ARC A1), l’alignement de corpus (ARC A2), l’extraction de terminologies (ARC A3),
la compréhension de messages (ARC A4), la dictée vocale (ARC B1), la synthèse vocale
(ARC B2) et la transcription de la parole (ARC B3). Parmi ces campagnes, AMARYLLIS
1 et 2 (ARC A1) avaient pour objectifs l’évaluation de logiciels de recherche d’information du français et le développement d’une méthodologie d’évaluation de tels logiciels. Les
activités d’AMARYLLIS seront fusionnées plus tard avec celles du projet européen CLEF
(cf. ci-dessous).
Toujours au niveau national, la campagne GRACE 4 (Grammaires et Ressources pour
les Analyseurs de Corpus et leur Evaluation) a pour but l’évaluation d’étiqueteurs morphosyntaxiques. Elle s’est déroulée de 1994 à 1998 et ne considère que la langue française.
L’équivalent allemand, Morpholympics [Hausser, 1994] s’est déroulé en 1994, puis à un
niveau européen la campagne Sparkle 5 (1993-1996) d’évaluation d’analyseurs syntaxiques
sur quatre langues différentes (anglais, français, allemand et italien).
À partir de 1998 ont lieu au niveau européen les campagnes SENSEVAL/ROMANSEVAL 6 , évaluant les systèmes de désambiguïsation lexicale sur différentes langues. De
nouvelles campagnes SENSEVAL ont lieu en 2001, 2004 et 2007.
Entre 1998 et 1999 s’est déroulé le projet japonais IREX (Information Retrieval and
Extraction Exercise) basé sur deux tâches d’évaluation : la recherche d’information et
l’extraction d’entités nommées [Sekine et Isahara, 2000].
1.
2.
3.
4.
5.
6.
http
http
http
http
http
http
://www.limsi.fr/sqale.html
://verbmobil.dfki.de
://www.limsi.fr/Recherche/FRANCIL/frcl.html
://www.limsi.fr/TLP/grace
://www.ilc.cnr.it/sparkle/wp1-prefinal/wp1-prefinal.html
://www.senseval.org
22
Par ailleurs, le pendant européen de TREC, CLEF 1 , portant sur la recherche d’information crosslingue a débuté en 2000 [Braschler, 2000] et continue au cours de campagnes
annuelles qui ont été étendues à la recherche d’information multimodale (c’est-à-dire l’extraction d’information à partir d’images, de vidéos ou de sons).
En France, sur les bases du programme de l’Aupelf-Uref, le projet EVALDA a été lancé
en 2002, dans le cadre du programme Technolangue 2 . Huit campagnes furent menées à
bien, également autour du traitement de l’oral et de l’écrit : alignement de textes (ARCADE II 3 ), extraction terminologique (CESART 4 ), traduction automatique (CESTA 5 ),
analyse syntaxique (EASy 6 ), question-réponse (EQueR 7 ), reconnaissance de la parole
(ESTER 8 ), synthèse vocale (EvaSy 9 ) et dialogue oral (MEDIA 10 ). De nombreuses données et informations ont été tirées de ces campagnes, notamment sous formes de « kits
d’évaluation » contenant les ressources, protocoles utilisés, résultats et documentation des
différentes campagnes [Chaudiron et Choukri, 2008a].
Le projet européen TC-STAR 11 s’est déroulé de 2004 à 2007, ambitionnant le développement d’un système de traduction de l’oral vers l’oral et son évaluation. En plus du
développement d’une plate-forme d’évaluation dédiée, le projet proposait trois évaluations
successives dans les domaines de la reconnaissance automatique de la parole, la traduction
automatique de la parole et la synthèse vocale.
Depuis 2005 et de façon annuelle, le DÉfi Fouille de Texte 12 (DEFT) rassemble une
communauté autour de la fouille de texte (Text Mining) et son évaluation.
Un premier programme semblable à celui d’EVALDA a également été mené en Italie,
EVALITA en 2007 13 , puis en 2009 14 avec un périmètre plus réduit. Cinq campagnes se
sont déroulées en 2007 sur le traitement de l’écrit : désambiguïsation sémantique, analyse
syntaxique, étiquetage morphosyntaxique, reconnaissance d’expressions et reconnaissance
d’entités nommées. En 2009, ce sont huit campagnes qui se sont déroulées, cinq sur le
traitement de l’écrit et trois sur le traitement de l’oral.
2.2.2.5
Autres campagnes
Les exemples de campagnes ou projets d’évaluation sont nombreux, mais ils sont parfois de moindre portée ou moins connus. La plupart des évaluations du NIST sont annuelles
à l’heure actuelle, de même que les évaluations portées par CLEF.
Au Japon, le projet NTCIR 15 (NII Test Collection for IR Systems) réalise des évaluations annuelles depuis 1999 portant sur la recherche d’information.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
http
http
http
http
http
http
http
http
http
http
http
http
http
http
http
://www.clef.org
://www.technolangue.net
://www.technolangue.net/article201.html
://www.tcstar.org
://deft.limsi.fr/
://evalita.fbk.eu/2007/
://evalita.fbk.eu
://research.nii.ac.jp/ntcir/index-en.html
23
D’autres projets ont cours en Europe et en France mais de manière plus chaotique, les
moyens financiers étant plus complexes à obtenir. En France, il est notamment question
des projets financés par l’ANR 1 tels que Infile 2 ou PASSAGE 3 qui ont débutés en 2006.
En Inde, un récent programme a eu lieu et prenant en compte 19 des langues parlées
dans ce pays, TDIL 4 (Technology Development for Indian Languages). Ce programme
considère également la thématique de l’évaluation.
2.2.2.6
En dehors des campagnes
En marge des campagnes d’évaluation, quelques projets ont défini des standards méthodologiques pour l’évaluation. En premier lieu, la définition des premières normes
ISO/IEC 9126 [ISO 9126, 1991], en 1991, jette les bases d’un cadre pour l’évaluation
de logiciels et des critères sont définis. Il ne s’agit pas de critères spécifiques au TAL, mais
les technologies du TAL sont directement concernées. De nombreuses mesures de qualité
sont inspirées de ces normes et les systèmes de traitement de la langue sont inclus dans
la liste des logiciels que vise la définition des normes ISO/IEC 9126.
Sur la base de ces normes, le groupe de travail européen EAGLES 5 (Expert Advisory
Group on Language Engineering Standards) a mis au point une méthodologie d’évaluation
axée sur l’usage et de nouvelles normes ont été alors définies. EAGLES fait suite à des
activités de projets tels que ESPRIT Speech Assessment Methods (1987-1993) ou SQALE
(1993-1995) qui sont principalement axés sur le domaine de l’audio.
Dans un même temps, le projet européen ISLE (International Standards for Language
Engineering, 1999-2002) 6 aborde des objectifs similaires à ceux du projet EAGLES. Trois
groupes de travail sont alors chargés de développer des standards pour les lexiques, l’interaction homme-machine et l’évaluation. Alors qu’en 1998 une nouvelle version des standards ISO/IEC 14598 est fixée, le nouveau projet européen ELSE (Evaluation in Language
and Speech Engineering) 7 reprend les recommandations du projet EAGLES en 1999. Il
s’agit d’une étude de faisabilité, l’objectif étant d’étudier la possibilité d’organiser une
évaluation comparative et quantitative de type boîte noire. Le projet FEMTI (a Framework for the Evaluation of Machine Translation in ISLE ) 8 fera suite à ISLE avec pour
objectif de référencer les différentes méthodes existantes en traduction automatique et de
les lier au but et au cadre d’utilisation des systèmes.
Régulièrement depuis 2005, ELRA organise des ateliers autour du sujet de l’évaluation :
HLT Evaluation workshop en 2005 9 , Automatic Procedures in MT Evaluation en 2007 10
et ELRA Workshop on Evaluation en 2008 11 . ELRA organise aussi la conférence LREC 12
tous les deux ans depuis 1998, qui reste un évènement majeur en évaluation du TAL.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
http
http
http
http
http
http
http
http
http
http
http
http
://www.agence-nationale-recherche.fr/
://www.infile.org
://atoll.inria.fr/passage/
://tdil.mit.gov.in
://www.ilc.cnr.it/EAGLES/home.html
://www.ilc.cnr.it/EAGLES96/isle/ISLE_Home_Page.htm
://www.limsi.fr/TLP/ELSE/
://www.issco.unige.ch/en/research/projects/isle/femti/
://www.elra.info/HLT-Evaluation-Workshop-in-Malta.html
://www.elra.info/Automatic-Procedures-in-MT.html
://www.elra.info/ELRA-Workshop-on-Evaluation-at.html
://www.lrec-conf.org
24
2.2.2.7
Bilan
Tous ces exemples d’initiatives nationales et internationales illustrent l’intérêt croissant pour l’évaluation en traitement automatique des langues. Les technologies les plus
évaluées sont celles qui s’intéressent à la recherche d’information, la traduction automatique, les analyseurs syntaxiques et, d’un point de vue plus historique, les systèmes de
reconnaissance vocale.
La comparaison entre les programmes américains et européens montre de grosses différences, essentiellement dues aux méthodes de financement. La pérennisation des campagnes au niveau régional n’en est que plus complexe. Toutefois, l’évaluation en traitement
automatique des langues est en important développement, du fait d’un succès croissant.
L’impact le plus représentatif est lié à la progression des systèmes et la mise sur le marché
de nouveaux produits pour le grand public.
Cet historique nous permet de dresser un bilan des acteurs du domaine de l’évaluation
en traitement automatique des langues. En premier lieu, les principales agences de financement qui apportent les crédits nécessaires au développement des projets, qu’il s’agisse
de la DARPA aux États-Unis, la Communauté Européenne en Europe ou encore l’ANR
en France. Ensuite, les organisateurs et porteurs de projets : la plus importante institution
est le NIST et a peu d’équivalent dans d’autres régions. Les organisateurs d’évaluations
sont bien souvent des agences plus modestes, des universités ou des groupes de projet.
En amont de l’évaluation, les distributeurs et producteurs de ressources linguistiques que
sont LDC et ELDA/ELRA sont souvent remplacés ponctuellement par des possesseurs de
données ne souhaitant pas passer par ces organismes.
2.2.3
Trois questions fondamentales
En évaluation du TAL trois questions principales se posent :
– Pourquoi évaluer ? Quelle est la finalité du processus d’évaluation en traitement
automatique des langues ?
– Que peut-on évaluer ? À quels types de paramètres s’intéresse-t-on ?
– Comment évaluer ? Quels sont les critères d’évaluation à mettre en place pour estimer la performance des systèmes ?
D’autres questions secondaires font suite à ces trois premières questions, comme par
exemple : quand évaluer ?, avec qui évaluer ?
2.2.3.1
Pourquoi évaluer ?
Dans toute démarche de développement de systèmes informatiques, il est nécessaire
de connaître et d’estimer le niveau de qualité atteint par les produits développés. C’est
une tâche primordiale à laquelle le développeur doit s’attacher.
En premier lieu, il est utile de tester l’évolution d’un système en cours de développement. Les développeurs ont besoin de connaître l’impact d’une approche pour résoudre
une tâche donnée en observant les performances du système. Dans le même ordre d’idées,
un système contient des paramètres modifiables pour l’amélioration des performances générales comme pour l’adaptation à un domaine particulier. Les développeurs du système
mesurent l’impact des changements de paramètres sur les performances. Par exemple, la
présence de plusieurs modules dans un système peut nécessiter des évaluations successives.
25
Dans ce cas, une analyse fine permet de déterminer si les performances générales sont limitées par un module en particulier et ainsi de connaître les points faibles du système.
En se plaçant à un niveau plus théorique, l’évaluation aide à observer les possibilités
qu’offre un axe de recherche. Le but est alors de préciser dans quelles directions l’effort
doit être poursuivit, ce qui néanmoins risque d’affaiblir l’innovation puisque l’évaluation
se restreint alors à un contexte particulier.
L’évaluation justifie les investissements entrepris pour le développement d’un système.
C’est le cas lorsque des agences de financement ont besoin de savoir si leurs investissements ont abouti à des progrès significatifs [Chaudiron et Choukri, 2008a]. Cela permet
par la même occasion de rediriger les axes de recherche et développement en fonction des
avancées d’une technologie. Ainsi, à plus grande échéance et avec un recul suffisant, il
est possible d’estimer le degré de maturité d’une technologie. Finalement, le processus de
développement aboutit lorsque le système est mis en production : l’évaluation établit si
le système sera un produit utilisable ou non au travers de l’application commerciale.
Pour comparer de manière objective les performances de plusieurs systèmes, les critères
d’évaluation doivent être similaires d’un système à un autre. En définissant des tâches, des
mesures et des références communes, l’évaluation permet de confronter des résultats de
manière homogène et cohérente. Quand bien même les critères sont parfois discutables, il
est indispensable que la communauté scientifique comprenne et interprète les résultats de
la même manière 1 . L’homogénéisation s’effectue en particulier lors de campagnes d’évaluation, car elles regroupent plusieurs acteurs d’un même domaine qui s’entendent sur des
critères compréhensibles par tous. L’exemple de GRACE [Adda et al., 1999] est caractéristique, puisque la campagne a obtenu l’accord des développeurs d’analyseurs syntaxiques
pour un jeu commun d’étiquettes morphosyntaxiques de leurs systèmes.
Les raisons d’évaluer se retrouvent dans [Miller, 2005] qui résume une bonne évaluation
comme étant :
– objective : les résultats ne sont pas biaisés ;
– reproductible : les mesures fournissent les mêmes résultats pour les mêmes données
de test ;
– diagnosticable : l’évaluation donne des informations sur l’amélioration des systèmes ;
– efficace en terme de coût : peu de ressources sont nécessaires pour reproduire l’évaluation ;
– compréhensible : les résultats doivent avoir du sens pour le public visé.
C’est l’utilisation de ces critères qui satisfait l’évaluation d’un système, plutôt qu’une
estimation informelle de ses performances.
1. De même, dans un domaine à forte domination anglo-saxone, il est parfois difficile de trouver des
correspondances de vocabulaire entre l’anglais et le français. Nous nous efforçons au cours de la rédaction
d’utiliser des termes français, quoi qu’il soit souvent plus facile, voire naturel, d’utiliser des termes anglais.
Un cas typique porte sur les termes désignant les juges. Plusieurs termes existent dans la littérature :
on parlera le plus souvent de « evaluator » ou, moins souvent, de « judge », mais le terme « rater » est
également rencontré, ou encore « subject », etc. Pourtant, chacun des termes a sa spécificité et nécessite
d’être traduit correctement en français. Autant « evaluator » peut être traduit par « évaluateur » (notons
que nous considérons l’évaluateur comme celui qui organise l’évaluation, et non pas celui qui porte des
jugements), « subject » par « sujet » autant « rater » et « judge » devraient tous les deux être traduits par
« juge ». D’autres termes sont moins évidents à traduire, certainement plus à cause de la pratique que de
la difficulté intrinsèque de la traduction. Il n’est pas rare de voir dans des conférences en langue française
des orateurs utiliser des termes anglais. Les principales mesures utilisées sont nommées en anglais. Par
exemple, on parlera de taux d’erreurs de mots, mais abrégé par WER (pour Word Error Rate).
26
2.2.3.2
Que peut-on évaluer ?
Il est primordial de fixer un objectif d’évaluation et de situer l’évaluation sur une échelle
de temps (c.-à-d. Quand évaluer ?, à quel étape du développement d’un système ?). Cela
passe par une définition du domaine (celui du système à évaluer), de la tâche de contrôle
et de ces critères d’évaluation.
La tâche de contrôle définit ce que le système doit effectuer au cours de l’évaluation
(le plus souvent au début d’un cycle de développement) : traduire automatiquement des
documents du domaine médical de l’anglais vers l’arabe, répondre automatiquement à
des questions écrites en langage naturel en utilisant le Web, extraire des relations de synonymie d’un corpus du domaine de l’éducation, etc. Ses caractéristiques sont données
en amont, selon des conditions claires et précises ne laissant aucune place aux différences
d’interprétation. Elles fournissent un état des critères d’évaluation, compréhensibles par
la communauté scientifique, mesurables et ne faisant pas nécessairement état d’une fonctionnalité finale des systèmes évalués.
Les critères d’évaluation sont multiples et répondent à une demande de qualité, de
quantité ou de comparaison. Les systèmes visées étant aussi informatiques, nous nous
tournons vers les normes définies pour estimer la qualité des logiciels.
Les normes ISO/IEC 9126 et 14598 définissent un cadre pour l’évaluation de logiciels
et le développent de critères de qualité, divisé en six catégories :
–
–
–
–
–
efficacité : le logiciel doit avoir un bon rendement,
fiabilité : le logiciel doit maintenir son niveau de service,
fonctionnalité : le logiciel doit répondre aux besoins fonctionnels requis,
utilisabilité : le logiciel doit être facile à utiliser,
maintenance : le logiciel doit demander un minimum d’efforts pour son évolution
par rapport à de nouveaux besoins,
– portabilité : le logiciel doit pouvoir être adapté sur une plate-forme ou à un environnement différent.
Chaque catégorie est découpée en sous-catégories définissant plus finement les critères
de qualité d’un logiciel en fonction de son type et de la tâche de contrôle. Le découpage se fait ainsi consécutivement jusqu’à arriver aux terminaisons appelées attributs. À
chaque attribut est assignée une mesure qui lui fixe un niveau de qualité sur une échelle
[Popescu-Belis, 2007].
Les systèmes de traitement automatique de la langue sont concernées par ces critères
de qualité. Il est nécessaire de déterminer des moyens précis pour mesurer chaque critère.
Toutefois, nous pensons que tous les critères ne sont pas indispensables pour l’évaluation
en traitement automatique des langues : dans notre cas, les critères les plus pertinents
sont l’efficacité d’un système et sa fiabilité. Le critère de fonctionnalité est en fait un pré
requis : si la fonction souhaitée n’existe pas, l’évaluation ne peut pas se dérouler (et c’est
alors plus une question d’ordre technique qu’il faut valider que d’évaluation proprement
dite). L’utilisabilité fait partie de l’évaluation des interfaces et de l’ergonomie, quant à
la maintenance et à la portabilité, il s’agit d’un trait particulier du développement d’un
système. In fine, ce sont les traitements linguistiques des systèmes qui sont évalués, en
tant que partie d’une application. L’évaluation de l’application dans son ensemble porte
plus sur se caractéristiques, fonctionnalités, qualités ergonomiques, etc.
27
2.2.3.3
Comment évaluer ?
La décision des caractéristiques d’une évaluation n’est pas forcément la première tâche
à accomplir. ELSE [Bernsen et al., 1999] considère par exemple deux modes opératoires
spécifiques à l’organisation d’une campagne d’évaluation :
– proactif : la tâche de contrôle est définie en premier, avant la sélection des participants ;
– réactif : la tâche de contrôle dépend du projet et ne peut être définie que lorsque
toutes les étapes préliminaires sont connues (par exemple le nombre de participants).
Après avoir établi les critères d’évaluation correspondant à la tâche de contrôle, il
reste à déterminer les moyens mis à disposition de l’évaluateur pour mener le travail
d’évaluation. La mise en place d’une évaluation peut se révéler très vite complexe, même
si de prime abord cela passe par un axiome simple : un ou plusieurs systèmes renvoient des
données qui sont analysées pour en déterminer la qualité. Seulement, il existe un nombre
important de paramètres à prendre en compte afin de mener correctement une évaluation
(comme le type des données en entrée du système, la subjectivité de l’évaluation, le risque
d’erreur, ou encore à un niveau plus pragmatique l’organisation de l’évaluation en ellemême). La méthodologie, les protocoles, le domaine, ou encore la tâche doivent alors être
définis avec précision.
Il est aussi indispensable d’adopter un système de valeurs, compréhensible par tous
et représentant de manière correcte le niveau de qualité mesuré. Ce système de valeurs
organise le niveau d’un critère sur une échelle de point. Il est dépendant de la mesure
utilisée et du domaine du système. Par exemple, bien que compris entre 0 et 100, un taux
d’erreurs sur les mots n’a pas la même portée en reconnaissance vocale qu’en traduction
automatique du fait que des éléments différents sont mesurés (c.-à-d. respectivement une
solution unique vs une multitude de solutions, cf. chapitre 6) . Le système de valeurs influe
sur l’interprétation des résultats. Il est défini selon des normes précises liées à la définition
d’une mesure de performance.
2.2.4
Paradigme et méthodologies
Tout d’abord, il nous faut distinguer l’évaluation de deux autres concepts relativement
proches : la validation et la compétition. La validation s’oppose à l’évaluation dans le sens
où celle-ci détermine si un certain niveau de qualité a été atteint sans se soucier du niveau
en lui-même. L’échelle est alors binaire et les résultats sont valides, ou non. Il faut noter
que l’on associe plus souvent la validation aux données qu’aux technologies. Pour les
technologies, validation et évaluation ont une base commune, puisque les mêmes mesures
sont utilisées. C’est l’acceptation d’un seuil de performance qui fait passer de l’évaluation
à la validation.
La compétition se distingue également de l’évaluation puisque l’on s’attend à un « classement ». L’objectif est de déterminer la position d’un système par rapport à un autre
en laissant une part très faible quant à l’importance de leurs performances intrinsèques.
La frontière entre les deux pratiques est faible mais bien réelle : il arrive de « classer »
les systèmes d’une campagne mais plutôt dans l’objectif de comparer les différentes approches.
D’après [Bernsen et al., 1999], les trois concepts (évaluation, validation, compétition)
se différencient selon plusieurs caractéristiques, présentées dans le tableau 2.1.
28
Approche
Compétition
Validation
Evaluation
Critère
1
Plusieurs
Plusieurs
Classement
Strict
Partiel
Partiel
Performance
Pas d’audit
Seuil
Audit
Reproductibilité
Non
Oui
Oui
Table 2.1 – Distinction entre compétition, validation et évaluation.
2.2.4.1
Niveaux d’évaluation
Les niveaux d’évaluation que nous traitons ci-dessous correspondent aux types d’évaluation employés dans ELSE ou EAGLES. Nous procédons à une telle distinction, dans le
sens où un niveau définit le degré d’évaluation lié aux différentes étapes de la conception
d’un logiciel, tandis qu’un type caractérise l’évaluation au sens large et présente un moyen
de réalisation.
Nous représentons dans la figure 2.2 les niveaux d’évaluation par rapport au cycle de
vie d’un logiciel, présenté en cascade, comparés aux choix de ELSE et EAGLES.
Figure 2.2 – L’évaluation dans le cycle de vie d’un logiciel.
EAGLES définit trois niveaux d’évaluation : tout d’abord, l’évaluation de développement (progress evaluation) dont l’objectif est de mesurer les progrès d’un système en
fonction des performances d’un autre système de même type (le second système sert en
quelque sorte d’étalon) ; ensuite, l’évaluation de diagnostic (diagnostic evaluation) dont
l’objectif est de déterminer les points de dysfonctionnement et d’en identifier les raisons ;
29
enfin, l’évaluation d’adéquation (adequacy evaluation) dont l’objectif est de mesurer la
capacité d’un système à remplir une tâche spécifique.
Ces trois niveaux d’évaluation de EAGLES sont clairement spécifiés pour trois grandes
étapes du cycle de vie d’un logiciel (cf. ci-dessous) : les quatre étapes de la conception
à l’intégration (le développement à proprement parler sont regroupées et positionnent le
système par rapport aux systèmes types du domaine ; l’étape de maintenance voit les
performances du système être améliorées en diagnostiquant les problèmes ; l’étape de
mise en production (en partie liée à l’étape de maintenance) où le système est adapté aux
différentes tâches applicatives, incluant le retour utilisateur.
ELSE considère quant à lui cinq niveaux d’évaluation [Bernsen et al., 1999] qui reposent également sur plusieurs étapes du cycle de vie d’un logiciel. Toutefois, ELSE étend
les conclusions de EAGLES à l’identification de la maturité d’une technologie. Pour ce
faire, le niveau technologique est lui-même pris en compte avec son propre cycle de vie.
Les cinq niveaux de ELSE sont donnés ci-après suivant le cycle de vie d’une technologie :
– l’évaluation de recherche élémentaire (basic research evaluation) sert à évaluer les
travaux de recherche et à mesurer leur impact sur les performances par rapport aux
méthodes anciennes déjà établies,
– l’évaluation de technologie (technology evaluation) estime le niveau de performance
d’une technologie et sa capacité à résoudre un problème bien défini, schématisé
(simplifié) et théorique,
– l’évaluation orientée utilisateur (usage evaluation), également dénommée évaluation
d’usage, mesure l’utilisabilité d’une technologie pour résoudre un problème dans des
conditions réelles d’utilisation et en impliquant des utilisateurs finaux dans l’environnement d’utilisation du système testé,
– l’évaluation d’impact (impact evaluation) mesure les conséquences socioéconomiques du déploiement d’une technologie,
– l’évaluation de programme (program evaluation) tente d’estimer l’impact d’un programme 1 sur l’évolution d’un domaine.
On remarque dans la littérature que la définition de ce dernier niveau d’évaluation est
moins claire, voire très peu employée.
La figure 2.3 schématise les niveaux d’évaluation définis dans ELSE.
De manière plus anecdotique, dans [Saracevic, 1995] six niveaux d’évaluation sont
définis pour la recherche d’information et restent valables pour d’autres technologies :
– niveau ingénierie : l’évaluation des performances est matérielle et logicielle (fiabilité,
erreurs, vitesse, sécurité, etc.),
– niveau des données en entrée : cela relève du contenu du système et des caractéristiques des données fournies en entrée, comme leur couverture,
– niveau de traitement : c’est à ce niveau qu’est évaluée la manière de traiter les
données (algorithmes, techniques et approches),
– niveau des données en sortie : l’interaction entre le système et les données obtenues
en sortie est évaluée (retour sur information, recherche, etc.),
– niveau utilisateur : la question de l’évaluation selon une tâche et un problème donné
est soulevée, allant jusqu’à prendre en compte le marché,
– niveau social : l’impact sur l’environnement est évalué.
Nous observons que ces niveaux d’évaluations sont assez abstraits et que l’auteur
1. Au sens d’un programme d’appel d’offre de recherche et développement.
30
Figure 2.3 – Les types et niveaux d’évaluation d’après les travaux de ELSE.
considère l’évaluation à un degré industriel. Finalement, il ne prend en compte la qualité
de la sortie d’un système qu’à une échelle très réduite.
D’après [King, 2005], il existe deux points de vue : soit l’évaluation définit ce que le
système doit être capable de faire (évaluation traditionnellement utilisée en recherche et
représentée par des campagnes), soit elle décrit la tâche qu’un humain souhaiterait effectuer (évaluation traditionnellement utilisée dans le monde industriel, représentée par les
standards ISO/IEC, EAGLES, ou encore FEMTI en traduction automatique). Dans le
premier cas, l’évaluateur cherche à déterminer la qualité que le système atteint en effectuant une tâche précise (niveau technologique), dans le deuxième cas il s’agit davantage
de montrer à quel point le système aide un utilisateur à accomplir une tâche (niveau
utilisateur). La finalité n’est donc pas la même.
De manière plus pragmatique, trois cas typiques d’évaluation de technologies sont
abordés par [Hirschman et Thompson, 1996], avec des objectifs bien précis :
– l’évaluation de diagnostic : cette évaluation est conduite lors du développement
d’un système, notamment lors de son paramétrage. L’analyse des résultats confirme
ou infirme les directions de recherche proposées, les hypothèses de travail, ou les
paramètres utilisés.
– l’évaluation de performance : il s’agit ici de l’évaluation d’un système complet, finalisé ou en passe de l’être (une « solution »). L’objectif ici est de mettre en parallèle
plusieurs systèmes ou de mesurer la qualité des sorties du système d’après un étalon.
– l’évaluation d’adéquation : il s’agit d’une évaluation orientée utilisateur. L’évaluation
d’usage rend la priorité aux utilisateurs finaux en testant un système dans un cadre
bien spécifique et un contexte particulier. Cela concerne aussi bien l’évaluation du
système en lui-même que l’évaluation d’un système associé à d’autres (c.-à-d. une
combinaison de systèmes). C’est le sentiment et la perception de l’utilisateur final
qui sont mis ici en valeur en mesurant son « niveau d’acceptation » du résultat.
ELSE pousse plus loin l’étude des niveaux d’évaluation en étudiant les relations qu’ils
peuvent avoir entre eux. Lorsque c’est possible, l’évaluation de recherche de base réutilise
les résultats d’évaluations sur des approches existantes. Les objectifs sont de comparer les
31
performances avec l’état de l’art, de décider si la différence peut se combler rapidement et
d’identifier les points d’amélioration des performances en utilisant la nouvelle approche 1 .
L’évaluation de technologie et l’évaluation d’usage sont complémentaires : autant la
performance de la technologie que la qualité liée à l’usage sont nécessaires pour sélectionner un système. En théorie, l’évaluation de technologie devrait prédire l’évaluation
d’usage : ce n’est concrètement pas le cas. De plus, une fois que la technologie est arrivée
à maturité, l’évaluation d’usage peut être alors employée seule, en attendant des standards
de validation.
Les relations entre les évaluations de technologies et d’impact sont plus complexes à
identifier car les niveaux d’évaluation sont éloignés. L’évaluation d’usage est plus proche
de l’évaluation d’impact, car elle implique l’utilisateur et peut au moins prédire l’impact
de la technologie sur le consommateur d’un produit. Mais ce n’est qu’après plusieurs
années que l’impact socio-économique peut être mesuré, avec une prudence relative à la
complexité de la tâche.
Enfin, l’évaluation de programme est considérée, dans ELSE, comme une somme des
quatre autres niveaux d’évaluation. Toutefois, la relation entre ces évaluations n’étant pas
linéaire, il ne s’agit que d’indicateurs pour une évaluation de programme.
2.2.4.2
Types d’évaluation
Il existe deux principaux types d’évaluation en ingénierie logicielle : en boîte noire et en
boîte transparente [Illingworth, 1990]. Ils sont valables pour les évaluations en traitement
Avec l’approche en boîte noire (black box evaluation), le comportement externe du
système est observé d’après les données qu’il reçoit en entrée, qu’il fournit en sortie et
leurs relations. La structure interne du système n’est pas analysée.
Avec l’approche en boîte transparente (glass box evaluation), la structure interne du
système est analysée et chaque module est isolé pour être diagnostiqué. Les données de
test sont alors plus précises et en relation avec les modules.
Les deux approches sont employées, bien que l’approche en boîte noire soit plus courante notamment lors de campagnes d’évaluation. Cet état de fait est notamment dû à
la proximité de l’approche de type boîte noire avec les origines de l’évaluation, sur les
résultats en sortie d’un système et pour une entrée donnée [Bernsen et al., 1999]. Il faut
toutefois reconnaître que l’approche en boîte noire est aussi plus simple à organiser, la
description détaillée des modules pouvant être fastidieuse. Elle facilite aussi l’analyse simplifiée des résultats car seule la sortie finale du système est étudiée, indépendamment des
résultats intermédiaires.
L’évaluation de type boîte transparente permet, au contraire, de mesurer l’impact de
chaque module sur les performances du système entier et de mesurer ses propres performances dans ce contexte. L’objectif est d’identifier les modules à améliorer pour obtenir
une meilleure qualité générale du système.
À noter l’utilisation d’évaluations en cascade permettant l’évaluation de plusieurs technologies imbriquées (par exemple, la traduction de l’oral vers l’oral, incorporant les trois
1. Il faut noter que la réutilisation de résultats provenant d’évaluations antérieures implique une interprétation en conséquence : les conditions d’évaluation ne sont certainement pas reproduites à l’identique
pour une nouvelle évaluation.
32
composants de reconnaissance vocale, traduction automatique et synthèse vocale). Avec
ce type d’évaluation, deux approches peuvent être adoptées, souvent complémentaires :
d’une part appliquer un jeu de test différent à chaque composant afin d’observer leurs
performances intrinsèques ; d’autre part appliquer à chaque composant un jeu de test correspondant à la sortie du précédent afin d’observer l’évolution des performances au fur
et à mesure de la chaîne de composants (chaque composant évalué étant pénalisé par les
résultats des composants précédents). La combinaison de ces deux approches permet l’observation des composants les « moins performants », en comparant les résultats obtenus
deux à deux. De la même manière, il est possible de remplacer un composant par un autre,
d’une même technologie, afin de déterminer celui qui correspond le mieux à la tâche de
contrôle (à savoir le composant qui amène les performances les plus élevées). Toutefois,
l’évaluation en cascade est souvent beaucoup plus coûteuse, puisque chaque composant
nécessite un nouveau jeu de test ou l’adaptation à un jeu de test existant.
D’aucuns considèrent l’évaluation avec une approche orientée utilisateur comme étant
un type d’évaluation [Chaudiron et Choukri, 2008a], en opposition avec une approche
d’évaluation technologique. C’est à notre avis plutôt une méthode d’évaluation dans le
cadre d’une évaluation de type boîte noire.
2.2.4.3
Critères, méthodes et mesures d’évaluation
L’une des dernières étapes avant le lancement même de l’évaluation reste la mise en
place des moyens d’exécution. On parle alors de méthodes d’évaluation, c’est-à-dire de
techniques permettant d’estimer les performances selon des pratiques formelles.
Cela passe avant tout par la définition d’un critère d’évaluation des performances donné
pour chaque méthode d’évaluation : ils indiquent les caractéristiques prises en compte par
l’évaluateur. [Sparck Jones et Galliers, 1996] définit deux principaux types de critères. Le
critère intrinsèque considère ce qu’un système produit et s’il est correctement produit :
il est lié à l’objectif du système. Le critère extrinsèque considère l’effet des sorties du
système dans un ensemble : il est lié à la fonction du système dans son environnement
usuel. Par exemple, un aligneur de phrases parallèles est évalué de manière intrinsèque en
mesurant le taux de phrases correctement alignées, et de manière extrinsèque en calculant
son impact sur un système de traduction automatique statistique utilisant les données
alignées pour son entraînement.
La méthode d’évaluation comparative permet d’estimer le niveau de qualité en comparant des systèmes dans un même contexte, pour une même tâche et sur les mêmes données.
Les mesures de performance utilisées sont également identiques d’un système à un autre,
sans favoriser l’un ou l’autre des systèmes 1 . Cette méthode est notamment utilisée lors
de campagnes d’évaluation et peut servir autant pour une évaluation intrinsèque qu’une
évaluation extrinsèque. L’évaluation comparative s’oppose à une méthode d’évaluation
d’un système isolé ne fournissant que des résultats relatifs dont l’interprétation est limitée. Ses performances n’étant pas comparées à un autre système, il est difficile d’en saisir
le niveau. Toutefois, son intérêt réside dans l’analyse de diagnostic des données en sortie
du système.
Une fois que les critères d’évaluation sont définis et la méthode choisie, il reste à
sélectionner ou développer les mesures d’évaluation, qui sont les moyens mis en œuvre
1. Nous verrons par la suite que la mise en pratique montre que ce n’est pas toujours le cas.
33
pour formuler une valeur de la qualité d’une entité (phrase, document, terme, etc.). Ces
mesures sont de deux types bien distincts :
– Les mesures d’évaluation humaines ou manuelles emploient des juges, experts ou
utilisateurs, qui estiment manuellement la qualité des productions d’un système.
– Les mesures d’évaluation (semi-)automatiques, appelées plus communément mesures
d’évaluation automatiques, utilisent des programmes (les métriques) qui comparent
les productions d’un système à une référence. Les mesures automatiques sont appelées ainsi mais ne doivent pas induire le lecteur en erreur : l’emploi d’une référence
implique une intervention humaine 1 , construite avant les calculs de résultats.
Par exemple, en reconnaissance automatique de la parole, les systèmes sont évalués
automatiquement. Une évaluation humaine reviendrait à parcourir la transcription automatique produite par chaque système évalué en écoutant la piste audio : cette mesure
serait très coûteuse. Les systèmes sont donc évalués automatiquement, en comparant leurs
transcriptions à une transcription manuelle unique, établie au préalable.
Les mesures actuelles sont souvent imparfaites, aussi l’interprétation de leurs résultats
doit, sans exception, tenir compte du contexte de l’évaluation. Elles ont cependant le
mérite d’intéresser la communauté à un même problème et de stimuler l’effort de recherche.
Au minimum, elles fournissent une esquisse des performances.
Nous pensons que la principale différence du déroulement d’une évaluation humaine 2
et d’une évaluation automatique 3 se situe dans l’intervention de l’élément humain selon
qu’il est réalisé (cf. figure 2.4) :
– a posteriori dans le cas de l’évaluation humaine, par la conduite de jugements humains après la production des sorties par les systèmes,
– a priori dans le cas de l’évaluation automatique, par la construction d’une ou plusieurs références avant, pendant, voire après la production des sorties, mais de manière disjointe.
D’autre part, l’évaluation humaine a pour particularité d’être subjective : elle dépend
du niveau d’exigence des juges, de leurs connaissances et attitudes au moment de fournir
des jugements. À l’inverse, on parle pour l’évaluation automatique d’évaluation objective,
car sans lien avec la subjectivité des juges. Il nous faut toutefois nuancer cette objectivité
puisque les références des mesures automatiques sont à base d’expertise humaine. Les
références sont validées selon un niveau d’exigence et peuvent être ajustées en conséquence.
2.2.4.4
Synthèse
La figure 2.5 présente notre vision des types et niveaux d’évaluation tels qu’ils sont
employés dans cette thèse.
Le tableau 2.2 fournit des exemples simples d’évaluations pour un système de traduction de l’oral vers l’oral afin de distinguer les types, niveaux et méthodes d’évaluation que
nous avons présentés jusque là.
1. Car une mesure entièrement automatique peut logiquement être intégrée dans un système.
2. contexte d’une évaluation utilisant une mesure humaine
3. contexte d’une évaluation utilisant une mesure automatique
34
Figure 2.4 – Processus d’évaluation automatique et humaine.
Figure 2.5 – Les types, niveaux et mesures d’évaluation.
35
Caractéristique
Niveau
Évaluation
Technologie
Usage
Impact
Type
Diagnostic
Boîte transparente
Boîte noire
En cascade
Critère
Intrinsèque
Extrinsèque
Méthode
Comparative
Isolée
Mesure
Humaine
Automatique
Description
Évaluation de la sortie du système par des experts
Évaluation de la sortie du système lors de discours
du parlement européen dans un contexte d’utilisation
Après plusieurs années, étude de marché sur les
systèmes de traduction parole-parole selon des facteurs socio-économiques (par exemple, impact sur
le rôle des interprètes)
Analyse fine de la sortie du système
Évaluation d’un module de segmentation interne
au composant de traduction automatique
Évaluation en sortie du système de traduction
parole-parole
Évaluation successive des différents composants du
système de traduction parole-parole et leur impact
respectif sur la qualité générale
Mesure des performances du système à partir des
données produites
Mesure des performances dans un contexte d’utilisation et prise en compte des sorties dans ce
contexte
Évaluation de plusieurs systèmes et comparaison
de leurs résultats
Évaluation d’un seul système sans le comparer à
d’autres
Mesure manuelle des performances du système par
des juges
Mesure des performances par comparaison avec
une ou plusieurs références à l’aide de métriques
automatiques
Table 2.2 – Exemples de différents types, niveaux, critères, méthodes et mesures d’évaluation pour l’évaluation d’un système de traduction automatique de l’oral vers l’oral.
36
2.2.5
Difficultés
Bien que le traitement automatique des langues ait pour but la modélisation et la
compréhension de phénomènes linguistiques, l’évaluation de ses systèmes passe à une
moindre échelle par les mêmes difficultés.
D’après [Popescu-Belis, 2007], la principale difficulté de l’évaluation en traitement automatique des langues est due à l’impossibilité de fournir des spécifications formelles pour
les tâches de traitement faisant intervenir des données linguistiques. Ainsi, l’absence d’un
formalisme de spécifications restreint les moyens d’observer les capacités d’un système.
Seules les mesures d’évaluation rendent compte de l’état des performances du système,
pour des cas particuliers.
Nous ajoutons que la complexité de l’évaluation vient également des juges qui perçoivent la qualité différemment. Cela relève du caractère ambigu et non déterministe de
la langue, comme par exemple lors d’une traduction automatique.
La difficulté d’évaluer en traitement automatique des langues est par ailleurs liée à
l’organisation même d’une évaluation. Nous mettons en avant plusieurs points particuliers :
1. Difficultés selon la technologie prise en compte : Le difficulté d’évaluer dépend de
la complexité de la tâche et il existe une échelle de difficulté selon les technologies
évaluées : certaines sont plus « stables » que d’autres. Cela est dû à l’expérience
acquise, le degré de dépendance par rapport à une référence, ou encore à l’ambiguïté
linguistique. Nous traitons ce point dans le chapitre 6.
2. Définition des standards et des critères d’évaluation : Afin de mesurer les performances d’un système, il est nécessaire dans un premier temps d’établir des normes
communes, compréhensibles par tous. Des standards définis en amont de l’évaluation
serviront à interpréter correctement les résultats obtenus. Les critères d’évaluation
sont à définir le plus tôt possible afin de centrer et de limiter l’activité de l’évaluation.
3. Création des jeux de données et d’une référence : L’effort le plus conséquent lors
de la préparation d’une évaluation est souvent celui de la création des données aux
différentes étapes de l’évaluation (cf. chapitre 5). La difficulté de construire ces ressources réside dans leur adéquation avec la tâche d’évaluation, leur représentativité
(par rapport à la tâche, la langue ou la technologie) ou leur taille.
4. Analyse et interprétation des résultats : La plupart des évaluations produisent pléthore de chiffres et de tableaux. Une interprétation correcte nécessite de mettre en
évidence les résultats les plus pertinents et d’en extraire les informations les plus
utiles (cf. chapitre 5).
5. Comparaison des approches de traitement automatique des langues : Pour une même
technologie, les mesures employées ou la méthode d’évaluation peuvent avoir tendance à favoriser certaines approches de traitement automatique plus que d’autres.
Par exemple en traduction automatique, la métrique BLEU est connue pour pénaliser les systèmes qui n’utilisent pas l’approche statistique [Hovy, 2007] (cf. chapitre
6).
6. Définition de méthodes d’évaluation objectives : Pour la majorité des mesures humaines, les résultats dépendent fortement des juges, qu’ils soient utilisateurs finaux
ou experts. En effet, la perception de la qualité varie d’un juge à l’autre pour de
37
nombreuses raisons. L’objectif d’une bonne évaluation est de limiter la part de subjectivité. Le cas échéant, l’interprétation des scores est effectuée selon le niveau de
subjectivité atteint. Il en va de même pour les mesures automatiques puisque certaines mesures peuvent influencer la mesure des performances de certains systèmes
ou technologies (cf. chapitre 6).
7. Conduite de méta-évaluations : La précédente section a fait état de la subjectivité
des mesures ou de leurs imperfections. Par conséquent, il est nécessaire d’en saisir
les limites en procédant à l’évaluation des mesures elles-mêmes, dénommée métaévaluation. Celle-ci permet de cerner les limites de la mesure d’évaluation sans forcément la rejeter. Elle sert aussi à fournir une meilleure interprétation des résultats.
Nous y revenons plus en détail en section 5.4.
8. Variations de la langue : L’évaluateur fait un choix quant aux paramètres (langues,
domaines, etc.) sur lesquels se focaliser [Miller, 2005] car les mesures et ressources
utilisées ne sont pas forcément adaptées à tous. Par exemple, les taux d’erreurs sur les
mots en reconnaissance de la parole (WER - Word Error Rate) fonctionnent pour les
langues indo-européennes, mais pas pour les langues sino-tibétaines qui utilisent des
caractères comme unités de base (sinogrammes ou idéogrammes) et que l’on ne peut
pas segmenter : un taux d’erreur sur les caractères (CER - Character Error Rate) est
alors employé. Il existe aussi le problème de la multilingualité [Peñas et al., 2004] :
complexité de la tâche, difficulté de la construction des ressources, besoins, etc.
9. Organisation de campagnes d’évaluation : Quelle que soit sa dimension, des difficultés surviennent à chaque étape de l’organisation d’une évaluation. La critique sans
doute la plus répandue, à juste titre, concerne la conception même des campagnes
qui se focalisent sur une même tâche dans un cadre restreint et qui contraignent
les systèmes à s’améliorer sur une partie spécifique d’un domaine. Bien souvent, la
mise en place d’une nouvelle campagne d’évaluation consiste à définir de nouveaux
problèmes de traitement automatique des langues. Pourtant, l’objectif initial devrait être d’évaluer des systèmes à partir de problèmes existants et un problème
devrait donner lieu à une évaluation, et non l’inverse. La mise en pratique de campagnes rend compte de la réalité du terrain et de la nécessité de restreindre le
cadre applicatif des évaluations. Parfois cela aboutit à la création de tâches artificielles. D’autre part, l’intérêt d’organiser des campagnes est limité par l’absence de
bons résultats sur de nouvelles technologies avant qu’elles ne montrent leur vraie
valeur [Bernsen et al., 1999]. C’est aisément contourné par l’organisation de campagnes évaluées sur la durée (et notamment les méga-évaluations évoquées dans le
chapitre 1).
10. Coûts : L’estimation des coûts d’une évaluation est complexe, mais il est déjà possible d’en identifier les différentes étapes [Chaudiron et Choukri, 2008a] : l’identification, la négociation, le traitement et/ou la production des ressources linguistiques
pour les phases d’entraînement, de développement ou de tests (cf. chapitre 3) ; l’organisation de l’ensemble des activités ; la contribution des équipes participantes (y
compris le comité scientifique et les experts) ; l’évaluation elle-même (développement
des outils de mesure et des interfaces de jugement, mesure de la qualité, adjudication
des résultats 1 , etc.) ; organisation des réunions et divers ateliers. Si les évaluations
1. L’adjudication des résultats fait suite aux premiers résultats calculés avec leur vérification par les
38
de systèmes isolés (c.-à-d. hors campagne) sont moins contraignantes, leurs coûts
n’en sont pas moins importants.
2.2.6
De la théorie à la pratique
L’évaluation en traitement automatique des langues repose sur un cadre définit au
cours des 30 dernières années. Il est relativement aisé d’en tirer les éléments les plus
pertinents afin de définir les bases théoriques d’une évaluation. Son déroulement consiste
à mettre en place des éléments génériques pour toutes les technologies étudiées, quels que
soient le type, le niveau ou la méthode d’évaluation. L’évaluation se limite alors à une
répétition de procédures et méthodologies déjà menées.
Selon le standard ISO/IEC 9126 [ISO 9126, 1991], le processus d’évaluation se déroule
en trois étapes : la définition des exigences de qualité, puis la préparation de l’évaluation, et enfin la procédure d’évaluation. L’étape de préparation de l’évaluation se déroule
elle-même en trois phases : la sélection des mesures, puis la définition des niveaux de
classement, et enfin la définition des critères de jugement. À noter qu’à aucun moment le
standard n’accorde de place aux ressources nécessaires à l’évaluation. Elles sont pourtant,
selon nous, indissociables du processus d’évaluation. De plus, l’ordre des phases de l’étape
de préparation n’est pas très cohérent en pratique : définir les critères de jugements, puis
les niveaux de classement et enfin sélectionner les mesures nous semble plus conforme à
la réalité.
[Forsbom, 2002] a repris de manière simplifiée ce processus d’évaluation en l’appliquant
à la traduction automatique. Il se déroule également en trois étapes principales :
1. Définir les besoins en qualité :
– Analyser les besoins : définir les exigences de qualité,
– Adapter l’évaluation aux besoins : définir le protocole selon les besoins.
2. Préparer l’évaluation :
– Sélectionner les mesures : déterminer les mesures adéquates d’après le protocole,
– Définir les niveaux de score ou de classement : préparer les données en attente
des résultats,
– Définir les critères d’évaluation : définir les caractéristiques qui seront évaluées
durant l’évaluation.
3. Conduire l’évaluation :
– Mesurer : mesurer la performance des systèmes selon les critères identifiés en 2,
– Classer : classer les systèmes en fonction des résultats obtenus, en prenant en
compte les niveaux de scores précédemment définis,
– Évaluer : faire le bilan des classements, évaluer les systèmes et conclure.
Ce processus d’évaluation a le mérite d’être appliqué à une technologie spécifique. Par
contre, tout comme avec le standard ISO, il nous paraît curieux de placer la définition
des critères d’évaluation après la sélection des mesures et aucune place n’est accordée aux
ressources. Il est possible de noter deux autres écueils : il est d’une part très difficile, en
pratique, de définir les niveaux de score avant l’évaluation ; d’autre part, il n’y a pas de
participants et les évaluateurs. Les résultats et les références sont alors ajustés en fonction des commentaires reçus.
39
phase d’adjudication des résultats permettant la vérification des résultats de l’évaluation,
et leur correction le cas échéant.
Le projet EAGLES va plus loin et définit 7 étapes principales pour entreprendre avec
succès une évaluation en traitement automatique des langues :
1. Définir les raisons et les objectifs d’une évaluation (« pourquoi faire une évaluation ? ») : un consensus est établi entre tous les participants impliqués dans l’évaluation. Le protocole est admis et validé par tous les acteurs, il est compris de tous
et de la même manière. Dès le départ, les caractéristiques à évaluer sont déterminées
dans le but de savoir ce que l’on cherche à évaluer (par exemple : un système dans
son ensemble, un module d’un système ou de plusieurs systèmes). Le contexte et le
cadre de l’évaluation sont délimités lors de cette étape, de même que les contraintes
que supportent les systèmes.
2. Élaborer un modèle de tâches : les rôles et les agents pertinents sont identifiés, en
tant qu’entités impliquées dans le modèle d’évaluation (système, utilisateur, évaluateur, etc.). Les tâches correspondantes sont ensuite définies et associées à des
types de données. Autrement dit, l’évaluateur définit l’utilisation du système et ses
caractéristiques principales.
3. Définir des caractéristiques de haute qualité : c’est au cours de cette étape que sont
détaillées les caractéristiques et leur degré d’importance.
4. Spécifier des critères détaillés pour l’évaluation des systèmes : pour chaque caractéristique explicitée à l’étape 3, l’étape 4 se penche sur l’aspect méthodologique :
l’évaluateur cherche l’existence d’une méthode cohérente et fiable pour mesurer les
performances du système à partir des caractéristiques retenues. Toutefois, si aucune
méthode ne peut être trouvée, le critère correspondant sera décomposé en des critères secondaires qui peuvent être mesurés, et ce jusqu’à ce que tous les critères,
primaires ou secondaires, soient mesurables.
5. Définir les mesures pour calculer les performances sur les critères retenus : à partir
des critères trouvés à l’étape 4, la mesure et la méthode sont définies afin d’identifier
les performances correspondantes. De même, en plus de la méthode et de la mesure, il
est nécessaire de définir le seuil d’acceptabilité des résultats, afin de savoir distinguer,
à la fin de l’évaluation, un résultat correct (c’est-à-dire conforme aux attentes) d’un
résultat incorrect d’un résultat satisfaisant, etc. Le seuil d’acceptabilité dépend du
modèle des tâches défini à l’étape 2. Lorsqu’un critère primaire a été décomposé en
plusieurs critères secondaires, il doit être possible de définir une combinaison des
critères secondaires.
6. Définir des techniques pour exécuter les mesures : un matériel de test doit être
développé pour procéder à l’évaluation du système (ou des systèmes, le cas échéant).
De plus, les agents impliqués ont connaissance de leurs tâches respectives : à quel
moment, sous quelles conditions, de quelle manière, comment les résultats doivent-ils
être présentés, etc.
7. Procéder à l’évaluation et interpréter ses résultats : c’est lors de cette dernière étape
que sont effectuées les mesures préalablement définies. Les résultats sont comparés
aux seuils d’acceptabilité définis lors de l’étape 5. Cela se conclut en résumant les
résultats et les analyses dans un rapport d’évaluation.
40
Le point de vue d’EAGLES 1 regroupe à la fois les évaluations de systèmes isolés et de
plusieurs systèmes lors d’évaluations comparatives. Toutefois, il se focalise avant tout sur
la partie qui sert à définir l’évaluation et non sa conduite : la dernière étape mérite d’être
détaillée et explicitée. De même que pour les standards ISO, EAGLES fait abstraction des
ressources utilisées dans l’évaluation et de leur création/acquisition. L’étape 5 nous paraît
problématique dans le sens où une confusion est faite entre l’évaluation et la validation
(« définir le seuil d’acceptabilité des résultats »). Nous revenons sur ce point dans le
chapitre 5. Enfin, il n’est toujours pas question d’une étape d’adjudication des résultats
ni d’un « atelier final » réunissant des différents acteurs pour conclure l’évaluation.
D’après les conclusions du projet ELSE, une campagne d’évaluation se déroule en
quatre phases :
1. La phase d’apprentissage, ou d’entraînement :
– Les participants potentiels sont ciblés selon la tâche de contrôle. Les détails sont
annoncés, puis les participants sont contactés afin de déterminer leur intérêt.
– Les spécifications et les mécanismes de collecte des résultats sont déterminés, en
s’assurant qu’ils sont représentatifs, comparables et reproductibles.
– Les standards, les critères de comparaison et les mesures sont définis.
– Les données d’entraînement (représentatives des données de test et qui ont une
couverture suffisante des variations du domaine) sont collectées, formatées et distribuées aux participants.
– Ces derniers acceptent ou non de participer à la campagne d’évaluation.
– Le protocole d’évaluation est communiqué aux participants, de même que les
outils qui seront utilisés durant la campagne.
2. La phase de « test à blanc » ou de développement :
– Le protocole d’évaluation est testé sans être rendu public. Il implique les participants comme s’il s’agissait d’un test réel. Le test est effectué sur des données
différentes des données de test mais leur volume est similaire 2 .
– La phase se conclut par une évaluation sur les données de test à blanc puis le
retour des participants est pris en compte. C’est également au cours de cette
phase que les participants décident s’ils veulent voir les résultats anonymisés ou
non.
3. La phase de test :
– La phase de test est exécutée de manière similaire à la phase de test à blanc en
utilisant des données inconnues des participants. Le protocole est similaire et les
performances sont calculées en fonction des données de référence. Le volume des
données utilisées et les contraintes de temps doivent empêcher tout traitement
manuel sur les données, de même que l’identification des parties utilisées pour le
calcul des performances.
– La phase de test se termine par un atelier final restreint aux seuls participants. Ils
y présentent leurs systèmes ou algorithmes et commentent les résultats obtenus.
1. Le projet ISLE a fait suite au projet EAGLES, en développant des standards pour trois domaines du
traitement automatique des langues : les lexiques, l’interaction multimodale homme-machine et l’évaluation. La structure FEMTI (http ://www.isi.edu/natural-language/mteval/) a poursuivi les investigations
en évaluation des systèmes de traduction automatique, son objectif étant d’établir une classification des
différentes méthodes d’évaluation.
2. Dans les fait, c’est surtout la forme des données de test à blanc qui importe, plutôt que le contenu.
41
La publication des résultats et la distribution des données, des protocoles et des
outils produits clôt cette phase.
4. L’étude d’impact :
– Les bénéfices apportés par la campagne d’évaluation sont estimés à ce niveau. Ils
sont de sources variées : augmentation de la masse de données annotées et validées,
identification de directions de recherche et d’algorithmes prometteurs, nouveaux
produits et outils créés, nouveaux acteurs du domaine et progrès réalisés par les
participants.
– Les résultats de cette phase servent à modifier et à améliorer le protocole de
futures campagnes d’évaluation. Ces résultats sont constitués après publication
des résultats de la campagne d’évaluation et suivent généralement une discussion
entre les acteurs de la campagne.
Il faut noter que ELSE se consacre strictement à l’étude des campagnes d’évaluation,
qui, toujours d’après ELSE, durent environ deux ans. Dans le cas contraire, soit les résultats ne sont pas capitalisés par les participants faute de temps (lorsque la campagne
dure moins longtemps), soit la motivation des participants faiblit (lorsque la campagne
dure plus longtemps). S’ajoute à cela une année préliminaire qui établit les bases de la
campagne : définition de la tâche de contrôle, communication autour de la campagne,
création d’une communauté, définition des mesures et sélection des données 1 .
ELSE est le projet qui va le plus loin pour définir l’organisation d’une évaluation :
la partie pratique est clairement mise en avant, contrairement aux précédents standards,
plus théoriques. Toutefois, nous souhaitons renforcer le poids des données et des mesures :
elles sont au cœur de l’évaluation mais ELSE n’aborde pas le sujet. De plus, la partie
administrative n’est pas prise en compte par ELSE. C’est pourtant ce qui fait « tourner »
l’évaluation. Nous souhaitons les mettre davantage en avant, car c’est une limitation
importante pour établir une architecture d’évaluation.
2.3
Architectures
langues
en
traitement
automatique
des
C’est depuis un peu plus d’une dizaine d’années que les premières architectures modulaires et distribuées ont commencé à être développées. Au milieu des années 90, les
environnements GATE [Cunningham et al., 1996, Cunningham et al., 2002] et Tipster
[Grishman, 1996] ont défini un environnement apte à développer des outils linguistiques,
toutefois limité aux données textuelles. Développée quelques années après GATE, UIMA
[Ferrucci et Lally, 2004] est une architecture très utilisée actuellement en TAL et certainement celle qui offre le plus de possibilités. Dans un même temps, la plate-forme
LinguaStream [Widlöcher et Bilhaut, 2005] définit des chaînes de traitement par assemblage de modules et possède une approche qui repose sur l’enrichissement incrémental de
documents.
Peu de ces architectures utilisent Internet (telle UIMA) pour effectuer leurs traitements
[Cerbah et Daille, 2006]. Mais leur modularité et leur facilité d’utilisation, reposant sur
une approche de services, permet d’adapter des systèmes et des outils afin de les intégrer
1. La plupart des projets européens sont d’une durée maximale de trois ans.
42
2.3. Architectures en traitement automatique des langues
dans une même structure [Witte et al., 2010]. Par exemple, les travaux effectués dans le
cadre du projet TC-STAR ont vu se développer une architecture modulaire utilisant UIMA
d’IBM 1 [Fanta et al., 2007]. Celle-ci était modélisée par une architecture distribuée autour
d’un serveur central, les trois types de technologies étant successivement pris en compte
(reconnaissance de la parole, traduction automatique, synthèse vocale) et suivis par un
module d’évaluation. Chaque module traitant d’une technologie était disponible sur un
ordinateur distant et appelé automatiquement par le serveur après s’être préalablement
enregistré sur un serveur d’authentification (voir figure 2.6).
Figure 2.6 – Schéma de l’architecture UIMA dans TC-STAR.
Malgré cette première expérimentation dans TC-STAR, il n’existe pas à notre connaissance d’architecture dédiée à l’évaluation dans le domaine du traitement automatique des
langues et qui puisse automatiser les protocoles. Plus étonnant, il semble qu’aucune campagne d’évaluation n’ait mené au développement d’une architecture permettant l’évaluation automatique de systèmes dans un cadre commun.
Nous décrivons succinctement dans cette section quelques-unes des architectures existantes et pouvant nous être utiles. Nous étudions également plusieurs outils qui ont pu
servir au cours d’évaluations : même s’il est difficile de les nommer « architecture » puisqu’il n’y est pas question d’un contexte commun et distribué, il ont permis des avancées
non négligeables pour l’automatisation des procédures d’évaluation.
1. http ://dl.alphaworks.ibm.com/technologies/uima/UIMA_SDK_Users_Guide_Reference.pdf
43
2.3.1
Infrastructure, architecture ou plate-forme ?
L’emploi des termes « infrastructure », « architecture » et « plate-forme » peut prêter
à confusion. Proches, ils représentent pourtant des concepts bien distincts.
L’infrastructure rassemble l’ensemble des notions liées au cadre de l’évaluation et à
son organisation. Les éléments de l’évaluation sont interconnectés et servent de support
à sa conduite. Il s’agit des acteurs de l’évaluation (organisateurs, experts, participants,
développeurs, fournisseurs de ressources, etc.), des outils, des protocoles, de la partie
administrative, des architectures, etc.
Nous avons délibérément centré notre propos autour d’une architecture d’évaluation,
car cette notion regroupe les aspects relationnels et informatiques de l’évaluation à organiser. Les éléments de l’évaluation (composants technologiques, procédures, outils, etc.)
sont organisés et structurés.
L’architecture modélise les relations entre composants technologiques, la plate-forme
en est son développement (informatique) concret que ce soit d’un point de vue logiciel
ou matériel. C’est la plate-forme qui est développée et mise en place sur un serveur ou
autour d’un réseau. Les chaînes de traitements y sont déployées concrètement à l’aide de
programmes.
2.3.2
GATE
À l’origine, GATE propose un environnement de développement permettant à des
utilisateurs de composer des modules de traitement afin de produire des ressources (des
corpus annotés la plupart du temps) et/ou de créer un système. Dans un second temps,
l’architecture GATE donne la possibilité d’évaluer des systèmes ainsi créées.
Le passage d’informations entre les modules se fait à l’aide d’annotations ajoutées sur
les documents traités dans une base centralisée, accessible par chaque module. L’architecture est développée en Java, et une interface dédiée permet de composer des chaînes de
traitements, visualiser les résultats et effectuer des traitements manuels.
Il est certainement possible de nommer autant de points forts que de points faibles liés
à l’utilisation de GATE [Plamondon, 2004]. Parmi ses points forts, l’utilisation du XML,
la modularité et l’aspect uniforme de son utilisation (une interface et un langage unique)
répondent aux attentes d’une telle architecture. Toutefois, il faut noter les lenteurs de
traitement, les gros besoins en mémoire, un langage à base de règles complexe et quelques
bugs, ce qui semble toutefois inévitable dans ce genre d’architecture. Nous regrettons
aussi le développement de l’architecture en code Java pour des raisons de lourdeur ou de
compatibilité entre versions, bien que ce point dépende plus des goûts de chacun. Enfin,
même si l’architecture inclut des modules d’évaluation, il n’est pas possible de démarrer
une chaîne de traitement distribuée à travers un réseau.
2.3.3
UIMA
Les principes d’UIMA (Unstructured Information Management Architecture) sont
proches de ceux de GATE, même si l’approche est différente et offre plus de possibilités. L’architecture UIMA est également modulaire et distribuée. Elle permet d’effectuer
44
2.3. Architectures en traitement automatique des langues
des chaînes de traitement en parallèle 1 . De plus, son utilisation n’est pas limitée aux seules
données textuelles : il est aussi possible d’utiliser des ressources audio ou multimodales.
Autre point fort de UIMA, son architecture intègre des modules à la fois en local ou à
distance, via le réseau.
Dans UIMA, les metadonnées sont décrites dans des fichiers XML pour chaque module du système global. Ces modules, écrits en Java ou en C++ et appelés Annotators,
sont englobés dans des outils d’analyse, (« AE », pour Analysis Engines). Les AE font
l’interface avec l’architecture UIMA qui lance tour à tour les AE en respectant la chaîne
de traitement demandée par l’utilisateur.
Une structure de données, le CAS (Common Analysis Structure) autorise le partage
d’informations entre Annotators. Ces informations sont représentées sous forme d’objets,
de propriétés ou de valeurs. Afin de disposer d’un aperçu multiple d’un même document,
UIMA fournit également des Sofa (multiple Subject of Analysis) qui représentent les objets
du document selon l’analyse effectuée. Par exemple, le document est représenté de manière
différente selon que l’analyse porte sur la partie audio du document ou sur la partie
textuelle : les attributs, indépendants, sont alors différents. Plusieurs Sofa peuvent ainsi
être inclus dans un CAS.
UIMA possède plusieurs avantages pour l’évaluation en traitement automatique des
langues : automatisation des processus, notamment pour l’appel aux modules faisant
partie de la chaîne de traitement ; possibilité de reconduire des évaluations à loisir et,
pourquoi pas, en laissant le choix de combinaison des modules ; capacité de l’architecture
à empêcher l’accès aux données utilisées, etc.
Mais malgré ces avantages, UIMA ne nous semble pas exempts de défauts : le développement peut se révéler long et fastidieux, en particulier pour des participants à une
évaluation qui n’ont pas forcément la capacité matérielle et financière d’adapter leur système à l’architecture en place. Bien que cela puisse se compenser par le développement
d’interfaces d’échanges de données, cela ne fait que repousser le coût en développement
vers l’évaluateur. Dans UIMA, nous mettons aussi en cause le manque de souplesse et
les problèmes de robustesse fortement liés au type de matériel utilisé (performance des
serveurs, fiabilité du réseau, etc.).
2.3.4
Architectures en évaluation
La majeure partie des évaluations en traitement automatique des langues se fait plutôt
manuellement qu’automatiquement. Les différentes tâches des organisateurs représentent
un important travail manuel, puisque la plupart du temps c’est à l’aide de scripts lancés
par ligne de commande que sont calculés les résultats des évaluations. Cette étape, obligatoire, devient vite fastidieuse lorsque plusieurs systèmes sont évalués, ou lorsqu’il faut
se rappeler quels sont les bons paramètres à appliquer. Pour éviter cela, des interfaces
ont été développées, bien souvent pour aider les jugements humains en leur fournissant
des fonctionnalités spécifiques. Il faut toutefois remarquer que les juges n’interagissent
pas avec les organisateurs d’évaluation ou les participants, et qu’ils ne jugent que très
rarement via Internet. Diverses expériences ont vu le jour, nous en fournissons quelques
exemples ci-dessous pour plusieurs technologies.
1. Ce n’était pas le cas pour les premières versions d’UIMA, telle l’architecture que nous avons utilisée
dans le projet TC-STAR.
45
En résumé automatique, la plate-forme QARLA [Amigó et al., 2005a] permet l’utilisation de plusieurs métriques automatiques (les métriques QUEEN, KING et JACK), dès
lors qu’elle reçoit en entrée des références humaines et des sorties de systèmes. Elle a été
utilisée lors de la campagne DUC 2004 [Amigó et al., 2005b]. La plate-forme IQMT est
une adaptation de QARLA à la traduction [Giménez et Amigó, 2006] et inclut quatre métriques différentes du domaine (ROUGE, GTM, METEOR et BLEU/NIST). Toutefois,
ces plates-formes nécessitent encore une intervention humaine relativement importante,
similaire à l’utilisation d’une seule et unique métrique d’évaluation (comme le lancement
de scripts en ligne de commande, la lecture des fichiers contenant les résultats, etc.).
De même que pour IQMT, plusieurs autres initiatives ont eu cours en traduction
automatique. Cela se justifie par l’existence de plusieurs métriques automatiques et des
possibilités de calculs de scores plus ou moins robustes ne nécessitant pas de jugements
humains. EvalTrans 1 [Niessen et al., 2000] est une des plates-formes les plus abouties pour
la recherche en traduction automatique. De nombreuses fonctionnalités sont disponibles :
ajout des jugements humains, utilisation de métriques automatiques calculant des taux
d’erreurs, informations diverses sur les erreurs rencontrées. Du reste, la plate-forme dispose
d’une base de données contenant les segments sources, de référence, ainsi que l’ensemble
des segments en sortie des systèmes évalués.
Dans le même ordre d’idées, l’utilisation de jugements humains a justifié le développement d’interfaces en traduction automatique afin de faciliter le calcul des scores et de
rendre plus robustes ces jugements. Citons entre autres les interfaces d’évaluation humaine des projets CESTA [Hamon et al., 2006], WMT [Koehn, 2007] ou encore IWSLT
[Fordyce, 2007].
En recherche d’information, des interfaces de jugements humains ont été développées de manière similaire, comme lors des campagnes CLEF [Di Nunzio et Ferro, 2006].
Puisque dans CLEF le même type d’évaluation se répète sur des corpus de langues différentes, le mieux est d’effectuer les jugements à travers une même interface, mais à partir
de sites différents (un par partenaire de langue différente). L’interface a été développée
afin d’être utilisée via Internet et l’ensemble des données, jugements, etc. est stocké sur
un serveur.
En reconnaissance de la parole, une plate-forme pour l’évaluation des systèmes de dialogue, PARADISE [Walker et al., 1997], a permis l’évaluation selon différentes mesures
combinées. PARADISE permettait notamment la comparaison de plusieurs systèmes.
Pourtant, la plate-forme a été peu utilisée, probablement, d’après les auteurs, à cause
de sa complexité et de son coût.
Une plate-forme pour la traduction parole-parole à été développée dans le cadre du
projet TC-STAR, mais de manière limitée et expérimentale.
À l’heure actuelle, il est relativement difficile de trouver trace dans la littérature de
plate-forme permettant à des participants de déposer leurs données et d’accéder à l’évaluation de leur système sans avoir à effectuer des manipulations complexes. La raison
est essentiellement due à un manque de publicité faite autour des développements réalisés, souvent dans l’intimité de laboratoires ou de projets. Nous pouvons toutefois citer les
travaux réalisés dans le cadre du projet Quaero, notamment autour de la plate-forme OSIRIM 2 (Open Services for Indexing and Research Information in Multimedia) en recherche
1. http ://www-i6.informatik.rwth-aachen.de/web/Software/EvalTrans
2. https ://osirim.irit.fr
46
2.4. Vers une automatisation de l’évaluation en traitement automatique des langues
d’information.
Les plates-formes souffrent d’un manque majeur en traitement automatique des
langues, entraînant une faiblesse dans la réutilisabilité et le prolongement des activités d’évaluation en communauté. Actuellement, l’évaluation est plutôt vue comme une
activité ponctuelle de fréquence relativement faible à cause des ressources requises et la
synergie créée a tendance à retomber une fois l’évaluation terminée.
2.4
2.4.1
Vers une automatisation de l’évaluation en traitement automatique des langues
Aspects méthodologiques et organisation d’évaluations
Quels que soient les critères et les mesures d’évaluation, une évaluation et ses résultats
sont énormément influencés par son organisation et son déroulement. Ils sont d’une importance capitale. Une évaluation bien organisée et sans écueil de déroulement présente
des résultats plus probants et pertinents qu’une évaluation mal ficelée.
La préparation des données, l’enregistrement des participants, l’envoi des données,
la récupération des sorties de systèmes, ou le protocole d’évaluation sont des exemples
de tâches pour lesquelles il est impératif de respecter une procédure correcte. Une fois
posés les jalons d’une évaluation, rien ne devrait gêner a priori son bon déroulement.
Mais malgré l’apparente facilité d’organiser une évaluation, il existe de nombreux points
critiques lors de son exécution. Cela peut concerner des données erronées ou non validées,
des participants n’ayant pas compris le protocole ou, à l’inverse, un protocole pas assez
adapté ou incomplet, etc. Cela provoque au mieux un contretemps, au pire un retard
conséquent qu’il faut être capable de gérer.
2.4.2
Utilité des ressources linguistiques
Il ne nous semble pas possible d’aborder la problématique de l’évaluation sans qu’une
partie ne traite des ressources utilisées. Outre les métriques d’évaluation, les systèmes
ou même les ressources humaines, les ressources linguistiques sont nécessaires à toute
évaluation. Elles sont aussi variées qu’il y a de systèmes de TAL : données textuelles
(corpus brut, corpus annoté, etc.), données audio (corpus audio, signaux sonores, etc.),
données vidéo (corpus d’images, corpus de vidéos annotées, etc.).
L’acquisition des ressources linguistiques fait l’objet d’un effort très conséquent lors
de la préparation d’une évaluation. Leur production est longue, voire très longue, leur
acquisition peut être coûteuse autant en termes d’effort humain que financier, et elles
impliquent souvent la négociation de droits d’utilisation (et/ou de distribution dans le cas
de campagnes d’évaluation).
La réutilisation de données existantes est une alternative à la production de nouvelles
données. Mais cette solution est à adopter avec précaution : un jeu de test ne doit pas être
connu des systèmes évalués. Le risque est de biaiser l’évaluation par « sur apprentissage »,
le jeu de test ayant été utilisé pour l’apprentissage du système évalué.
La qualité des données produites influence les résultats de l’évaluation tant en terme
de format que de contenu. La définition et le contrôle de qualité des ressources utilisées
ne doivent pas être laissés à l’écart sans décrédibiliser les résultats de l’évaluation.
47
2.4.3
Un point de départ : les jugements
De prime abord, il semble indispensable de faire vérifier les sorties de systèmes de TAL
par des yeux humains. En pratique, des juges font guise d’observateurs. Ils produisent des
jugements en fixant une valeur sur une solution proposée par un système. Toutefois, cette
tâche n’est pas aussi aisée qu’il y paraît [Vilar et al., 2007]. Par leur perception personnelle de la langue, les humains ne donnent pas forcément des jugements identiques, que ce
soit entre plusieurs juges, ou bien pour un même juge à deux instants différents. Leur jugements sont dits subjectifs 1 . En effet, leurs choix ne sont pas toujours homogènes, ils sont
même dépendants de nombreux critères. Un même juge est capable de fournir un jugement
différent au cours du temps pour des raisons de fatigue, de contraintes temporelles, d’humeur, d’intérêt (variable au cours d’une évaluation) ou d’un environnement perturbant.
De même, deux juges différents ont souvent des jugements radicalement différents, selon
leurs cultures, leurs compétences, leurs dispositions, en plus des raisons précédemment
évoquées. Beaucoup de questions se posent [Hamon et al., 2008a] et plusieurs paramètres
sont à considérer pour interpréter les résultats :
– Les qualités et l’expérience des juges (par exemple experts ou utilisateurs finaux),
– Les conditions de conduite des jugements (par exemple via Internet ou sous contrôle
de l’évaluateur),
– L’aptitude des juges à effectuer des jugements (liée à la fatigue, la période, etc.),
– La préparation et le niveau d’information des juges (entraînement préalable ou non).
Toutefois, des jugements différents ne constituent pas pour autant des erreurs d’interprétation : chacun a sa propre idée d’une valeur de qualité à fixer. L’intérêt des jugements
porte néanmoins sur l’avis d’un humain comme référence sur la qualité d’une production
automatique. C’est l’interprétation et la mise en contexte des résultats, et surtout l’accumulation des avis de plusieurs juges qui atténuent ou empêchent les erreurs d’analyse et
permettent de disposer d’un avis général. Cela signifie que le contexte d’évaluation doit
toujours être spécifié pour une meilleure compréhension des résultats et empêcher toute
contestation possible.
Les jugements sont subjectifs non seulement parce que le langage naturel est ambigu,
mais aussi et surtout parce qu’ils sont liés à la psychologie. La perception et la connaissance
de la langue qu’ont les juges sont très variables. Il est aussi certain qu’un expert n’a pas
le même point de vue qu’un « utilisateur lambda » ou qu’un développeur de système,
du simple fait que leurs objectifs ne sont pas les mêmes. Par ailleurs, les attentes des
utilisateurs ne sont pas les mêmes selon leur utilisation d’un système : professionnelle,
sociale, scolaire, fréquente ou non, exigeante ou non, niveau d’expertise, etc.
2.4.4
Automatisation et substitution aux jugements humains
La problématique de l’évaluation automatique consiste, dans une certaine limite, à imiter les jugements de manière à les reproduire sans aide manuelle et de manière cohérente
avec les résultats attendus. Dans de nombreux cas, c’est une tâche qui s’avère aussi complexe que celles qui réalisent les technologies évaluées. Dans d’autres cas, l’automatisation
est recommandée, voire nécessaire pour réduire les coûts : par exemple, la transcription
1. Certaines communautés du TAL utilisent le terme « jugements subjectifs » plutôt que « jugements
humains ». Ainsi, on aura tendance à parler « d’évaluation humaine » en traduction automatique, mais
« d’évaluation subjective » en synthèse de la parole.
48
2.4. Vers une automatisation de l’évaluation en traitement automatique des langues
manuelle en reconnaissance de la parole reste plus pratique et rapide en établissant une
référence que des jugements comparant deux signaux manuellement.
Une mesure automatique pousse à créer une référence (création humaine correspondant
à ce qui doit être produit automatiquement) et à appliquer une métrique (programme de
calcul des résultats) en comparant les données produites automatiquement à la référence.
Pourtant, cette création humaine qu’est la référence inhibe l’automatisation complète de
l’évaluation. L’évaluation automatique comporte ainsi une part de subjectivité.
Quel est donc l’intérêt d’automatiser des phénomènes qui sont, a priori, somme toute
assez complexes à modéliser ? La réponse est simple : une évaluation humaine est coûteuse
[Papineni et al., 2001] et les objectifs actuels sont la réduction du temps passé à évaluer
et surtout celle du coût [Hamon, 2007a]. Les développeurs observent régulièrement la
qualité de leurs systèmes, les utilisateurs choisissent rapidement entre plusieurs systèmes
ou applications, une entreprise doit savoir quelle système ou application lui convient le
mieux, et tout cela à moindre coût. Ainsi, l’automatisation des jugements doit rendre
plus aisée la reproductibilité des évaluations. Le volume des données utilisées n’est pas
non plus le même : la machine est capable de gérer de grandes quantités de données à
moindre coût tandis que l’évaluation humaine est plus coûteuse, plus longue, et avec des
risques non négligeable d’erreurs.
Certaines mesures automatiques actuelles potentiellement pertinentes ne reflètent pas
le choix des juges. Elles fournissent une approximation des performances d’un système, ce
qui est souvent suffisant. De plus, leur manque d’adaptation provoque parfois des écueils
dès lors que l’évaluateur s’éloigne des sentiers bien bornés de ces mesures.
2.4.5
Évaluation des mesures
Une fois les mesures définies, elles sont validées puis évaluées sur un critère de pertinence. On parle alors de méta-évaluation [Stufflebeam, 1974, Callison-Burch et al., 2007],
l’évaluation de l’évaluation. Dans ce souci de perpétuelle évaluation, il est facile d’imaginer le besoin constant de vérifier la pertinence des actions, de vérifier si la méthode de
vérification est elle-même correcte et juste, et ainsi de suite. Il faut cependant se fixer des
limites. La méta-évaluation touche à des domaines éprouvés en mathématiques, lorsque
l’on cherche à comparer deux méthodes ou deux résultats l’un par rapport à l’autre.
Dans notre cas, des mesures d’évaluation automatiques sont comparées à des mesures
d’évaluation humaines. Ces dernières servent alors de référence.
Les mesures d’évaluation automatiques et humaines sont également méta-évaluées en
considérant leur robustesse, à savoir leur capacité à produire des scores cohérents pour
des données ayant une qualité constante : on observe la stabilité des mesures par rapport
à la variation des données, à qualité supposée constante.
Du reste, toute mesure humaine est aussi validée en bonne et due forme. Cela se fait
le plus souvent par des calculs d’accord entre juges : l’évaluateur s’attend à ce que les
décisions des juges soient homogènes et cohérentes.
La méta-évaluation est une étape essentielle dans la « vie » d’une mesure d’évaluation :
elle justifie l’emploi d’une mesure efficace (cf. figure 2.7). À partir des données de test,
les évaluations automatique et humaine produisent des résultats. Les résultats de l’évaluation automatique subissent des calculs de corrélation avec les résultats de l’évaluation
humaine. Ces derniers sont, eux, méta-évalués en comparant les résultats des juges entre
49
eux (accord inter-juges) ou pour chaque juge (accord intra-juge). Finalement, un calcul de
robustesse des mesures est réalisés, généralement par des méthodes statistiques. La principale difficulté est de comparer concrètement des mesures automatiques à des jugements
humains : ces derniers sont généralement soumis à une grande variabilité. Nous tentons
de réfléchir à des moyens de contourner ces inconvénients.
Figure 2.7 – Méta-évaluation des mesures automatiques et humaines.
2.4.6
Automatisation des protocoles : un vaste avenir
La répétition d’évaluations est bien plus qu’une étape supplémentaire dans le processus
d’évaluation ou qu’un enjeu de plus en TAL. C’est une représentation de ce que devrait
être l’évaluation à long terme : la mise en place d’observatoires pérennes de performances,
reproductibles dans le temps et comparables. Ainsi, l’évolution de la qualité générale d’un
domaine particulier pourra être décryptée : l’évaluation d’impact, la comparaison au cours
du temps d’un même système ou entre plusieurs systèmes passe par le développement
d’architectures d’évaluation. Elles facilitent le stockage des données et des résultats, ainsi
que l’utilisation de mesures communes.
Nous défendons l’emploi d’architectures d’évaluation. Elles structurent les composants
d’une chaîne d’évaluation (et par extension les composants d’une chaîne de TAL) et
facilitent leurs interactions.
Au-delà des intérêts mentionnés précédemment, c’est également une réduction des
coûts de l’évaluation qui est proposée. Une architecture d’évaluation rend possible la
réutilisation de protocoles automatisés et de données. C’est une nouvelle vision de l’évaluation qui est désormais possible : une architecture laisse envisager la combinaison de
50
2.5. Conclusion
plusieurs technologies via des composants interchangeables (à partir du moment où les
technologies peuvent s’associer). Nous proposons en premier lieu une architecture simple
permettant de pérenniser une campagne d’évaluation et nécessitant peu d’efforts. Mais
nous souhaitons concevoir une plate-forme d’évaluation plus ambitieuse. L’objectif final
est de modéliser une architecture type, permettant l’évaluation de n’importe quelle technologie de TAL. Les mesures d’évaluation automatiques comme les mesures d’évaluation
humaines sont concernées. Auparavant, nous appréhendons les possibilités d’une mise en
commun des ressources de chaque technologie après avoir étudié leurs similarités. Cette
étude est indispensable, dès lors que l’aspect générique de l’architecture implique de mutualiser au mieux les aspects communs aux différentes technologies.
Enfin, une telle architecture d’évaluation laisse envisager la conduite de méga évaluations [Sparck Jones et Galliers, 1996] : des évaluations répétées au cours du temps sur des
jeux de test similaires et avec différentes versions d’un même système, afin d’observer son
évolution en terme de performances 1 .
2.5
Conclusion
Nous avons dressé dans ce chapitre un état des lieux du traitement automatique des
langues dans un contexte d’évaluation. Plusieurs philosophies de l’évaluation existent,
mais elles se rejoignent autour d’un même but : déterminer quel est le niveau de performance atteint par des systèmes. L’évaluateur identifie jusqu’à quel point les systèmes se
rapprochent de ce que ferait un humain. Dans notre contexte, les attentes des utilisateurs
sont prises en compte mais dans une moindre mesure : il faudrait également considérer
l’ergonomie, l’utilisabilité, etc.
Il est difficile de définir les tâches de l’évaluation : les « grands » standards comme ISO,
EAGLES, ELSE, etc. ne se situent pas sur un même plan. De notre côté, nous estimons que
ces standards ne font pas assez état du côté pratique de l’évaluation. Ainsi, les décisions ne
sont ni séquentielles ni linéaires : en pratique, l’évaluateur parcourt un arbre de décision
et revient en arrière lorsque les tâches ne correspondent pas. Elles peuvent également
être menées en parallèle les unes des autres. Ce sont autant de cas qui limitent la portée
des standards comme ceux qui précèdent, même s’ils donnent de nombreux détails sur
des cas particuliers en évaluation. L’autre grand inconvénient est d’avoir des standards
essentiellement orientés vers les campagnes d’évaluation et qui ne tiennent pas compte de
l’évaluation de systèmes isolés.
Ce chapitre nous a permis de poser les bases de l’architecture que nous cherchons à
définir. En premier lieu, nous souhaitons renforcer l’importance des ressources, notamment
face aux métriques d’évaluation. Car si ces dernières sont indispensables pour effectuer
une mesure de qualité, l’impact des ressources utilisées sur les résultats d’évaluation est
indéniable. D’autre part, ce sont les ressources, en plus des métriques d’évaluation, qui
mettront à mal la plate-forme d’évaluation : leur volume et leur complexité seront une
des variables pour la définition des caractéristiques techniques de la plate-forme.
Nous avons également observé que les mesures d’évaluation automatiques sont loin
d’être adoptées par les acteurs du TAL, et que beaucoup de mesures sont encore à base
1. Par exemple, nous avons procédé à une étude sur trois ans pour les systèmes de traduction automatique impliqués dans le projet TC-STAR [Mostefa et al., 2007a].
51
de jugements humains. Les mesures humaines sont indispensables dans bien des cas, ce
qui peut entraver l’utilisation d’une plate-forme d’évaluation générique et pérenne. Il
faut donc faciliter leur intégration à notre architecture d’évaluation. L’automatisation des
protocoles et mesures est nécessaire pour celle-ci et passe par leur étude.
Enfin, nous avons remarqué que la plupart des standards proposent différentes visions
du déroulement d’une évaluation. La participation à plusieurs évaluations de systèmes
nous permet d’en proposer une synthèse et d’y ajouter notre propre contribution, essentiellement d’un point de vue pratique.
52
Chapitre 3
Le déroulement d’une évaluation
Les attentes d’une évaluation vont au-delà des simples résultats de mesures d’évaluation d’un ou de plusieurs systèmes évalués. Elles passent par l’analyse des résultats
obtenus afin d’améliorer ce qui est évalué ou de comparer les performances de systèmes.
La mise en pratique d’une évaluation donne parfois lieu à l’amélioration des mesures, des
protocoles ou des méthodes.
La conception même d’une évaluation influe sur les résultats obtenus : ils sont dépendants de son organisation et de ses caractéristiques. Il est impératif de faire les bons choix
dès son élaboration. De cette manière, il nous paraît judicieux de construire une méthodologie générique prenant en compte chaque technologie. Cela ne signifie pas pour autant
qu’il faut oublier les particularités propres de chacune, mais que le maximum de similarités sont mises en commun. C’est un premier pas vers la définition d’une méthodologie
type.
Nous nous intéressons dans ce chapitre aux aspects méthodologiques d’après nos participations à des projets d’évaluation divers. Par ailleurs, nous nous plaçons dans une
démarche plus pragmatique que celle de EAGLES ou ELSE. Nous considérons avant tout
l’évaluation sous forme de campagnes impliquant plusieurs systèmes. Nous constatons
que les caractéristiques d’une campagne d’évaluation s’appliquent facilement à l’évaluation d’un système isolé.
Afin de mettre en perspective les aspects d’organisation d’une campagne d’évaluation,
nous fournissons des exemples dans le cadre des campagnes CESTA et CESART (cf.
annexes A.3 et A.2) auxquelles nous avons activement collaboré. Nous nous limitons aux
points liés à l’organisation et au déroulement des campagnes d’évaluation. Les aspects liés
à la mesure des performances et à l’analyse des résultats seront détaillés dans les chapitres
suivants.
La phase de préparation consiste à spécifier les caractéristiques des systèmes et les
méthodes pour les évaluer. En conséquence de quoi, l’évaluateur adapte les critères aux
caractéristiques observées. Il délimite également un cadre strict autour de la technologie
évaluée, sans quoi une évaluation hors contexte n’aurait aucun sens.
La mise en place d’une évaluation est rigoureuse pour des raisons scientifiques et
d’équité entre systèmes. Quelquefois, elles sont aussi politiques. Par contre, il ne faut pas
oublier son objectif principal : améliorer les performances d’un ou de plusieurs systèmes,
ou d’une technologie. La déviation dans l’application d’une méthodologie rigoureuse peut
53
Chapitre 3 : Le déroulement d’une évaluation
avoir comme conséquence des biais dans les résultats ou une compréhension erronée des
acteurs du domaine.
Par contre, il ne faut pas négliger la question du coût de l’évaluation. Dans le cas
d’une campagne, le coût est un paramètre fondamental : dans bien des cas, la planification
des tâches se fait selon le budget alloué [Chaudiron et Choukri, 2008a]. Dans le cas d’un
système isolé, cette question est plus complexe à traiter car les conditions sont moins
encadrées que des campagnes : l’évaluateur-développeur a tendance à connaître à l’avance
les caractéristiques qu’il cherche à évaluer. Il adapte son évaluation en conséquence et
« jongle » entre critères, ressources et budget.
L’évaluation se déroule en deux cycles principaux. Le premier cycle consiste à définir
l’évaluation, sa mise en œuvre et les moyens pour la mener à bien. Le second cycle met en
pratique l’évaluation et applique le protocole défini au cours du premier cycle. En pratique,
les deux phases se chevauchent régulièrement et un affinement de l’organisation se fait
au fur et à mesure de l’évolution des phases. Cela est souvent dû à des aspects n’ayant
pas été anticipés. Ils sont à prendre en compte lors de la constitution d’un programme
d’évaluation. Le but est notamment de laisser des marges de manœuvre.
3.1
Phases préliminaires
Les phases préliminaires d’une évaluation ont pour objectifs de planifier son déroulement, d’établir ses spécifications et enfin de développer et préparer les éléments indispensables pour la mener à bien. La mise en place de ces caractéristiques de base n’est pas
à négliger car c’est à partir de cela que les expérimentations seront effectuées. Plus ces
étapes préliminaires sont suivies correctement, plus les étapes suivantes sont exécutées
facilement.
Le tableau 3.1 fait la synthèse des différentes phases préliminaires.
1.
2.
3.
4.
5.
6.
7.
8.
Planifier l’évaluation
Définir la tâche de contrôle et ses objectifs
Cibler les participants et les acteurs
Établir des critères de qualité
Définir des mesures de la qualité
Constituer les ressources linguistiques
Spécifier et organiser les interactions entre acteurs
Préparer l’évaluation
Table 3.1 – Les phases préliminaires de l’organisation d’une évaluation.
3.1.1
Planifier l’évaluation
3.1.1.1
Description
L’organisation d’une évaluation nécessite la mise en place de procédures strictes. Cela
commence par la planification des étapes clés. Celles-ci varient peu d’une évaluation à une
autre. Lorsque la planification des étapes est fixée, les partenaires du projet d’évaluation
54
3.1. Phases préliminaires
se voient affecter la responsabilité d’une ou de plusieurs tâches. Un coordinateur de l’ensemble du projet est également désigné. C’est particulièrement le cas dans des projets de
grande envergure (projets européens, nationaux, etc.) qui incluent de nombreuses tâches.
Les composantes administratives sont ensuite fixées : le budget, les participants, etc.
Un calendrier est spécifié selon les possibilités des partenaires. Il lui arrive d’être
modifié en cours de projet, en fonction de nouvelles contraintes susceptibles d’apparaître.
Toutefois, le calendrier de base doit toujours servir de référence. Dans ce calendrier, un
certain nombre de réunions sont prévues en plus des tâches : réunion servant de « coup
d’envoi », réunion de parcours, atelier final ou réunion de clôture, etc. Le besoin de se
rencontrer entre partenaires est important.
Lorsque tous ces détails sont acceptés par tous les partenaires, ils sont formalisés dans
un document final : le « programme d’évaluation » (evaluation plan). Il est validé par
l’ensemble des organisateurs et/ou participants impliqués.
Finalement, la communication générale autour du projet est aussi planifiée : site Internet, publications, liste de diffusion, etc. Elle tient la communauté informée et procure
un apport important par les retours engendrés et l’émulation suscitée.
Le tableau 3.2 fait la synthèse des différentes étapes de cette phase.
1.1. Définition des étapes de l’évaluation
1.2. Assignation aux acteurs
1.3. Planification des échéances
1.4. Choix du coordinateur
1.5. Administration du projet
1.6. Définition du calendrier
1.7. Planification des réunions
1.8. Validation des étapes par tous les acteurs
1.9. Formalisation des étapes
1.10. Communication générale
Table 3.2 – Les étapes de la planification d’une évaluation.
3.1.1.2
L’exemple de CESART
Dans le cadre du projet EVALDA, financé par le Ministère de la Recherche et des
Technologies, le projet CESART (extraction terminologique, cf. annexe A.3) était coordonné par l’Université Lille 3 et l’ELDA. Le CISMeF 1 (Catalogage et l’Indexation des
Sites Médicaux Francophones) a rapidement été identifié comme un potentiel fournisseur
de corpus en plus des deux coordinateurs car le domaine médical était fortement pressenti
dès le début comme un domaine sur lequel porter évaluation.
Les contraintes de calendrier étaient celles du projet EVALDA et le projet était planifié
sur trois ans. La première année était destinée à la réflexion méthodologique autour de
l’évaluation des systèmes. La seconde année devait servir à la production des ressources
nécessaires (données et mesures). Enfin, la troisième année développait une campagne
d’évaluation à proprement parler.
1. http ://www.cismef.org
55
Une page Internet dédiée a été conçue sur le portail Technolangue 1 et une liste de
diffusion interne a été créée. Tout au long du projet, plusieurs publications ont été réalisées,
que ce soit pour informer de ses caractéristiques ou pour présenter les résultats.
3.1.1.3
L’exemple de CESTA
Dans le cadre du projet EVALDA, financé par le Ministère de la Recherche et des
Technologies, le projet CESTA (traduction automatique, cf. annexe A.2) était coordonné
par l’ELDA, associée à l’Université de Lille 3. Des partenaires étrangers étaient invités en
tant qu’experts : l’École Polytechnique Fédérale de Lausanne (Laboratoire d’Intelligence
Artificielle - LIA, Suisse), l’Université de Leeds (Royaume-Uni), l’Université de Montréal
(Recherche appliquée en linguistique informatique - RALI, Canada) et l’Université de
Genève (Institut Dalle Molle pour les études sémantiques et cognitives - ISSCO, Suisse).
Les contraintes de calendrier étaient celles du projet EVALDA : la durée du projet
était planifiée sur trois ans. Deux campagnes ont été entreprises. La première année était
destinée à la réflexion méthodologique autour de l’évaluation des systèmes et la définition
des mesures d’évaluation. La seconde année servait à la production et au développement
des ressources nécessaires (données et mesures), puis la première campagne d’évaluation
était démarrée. Enfin, la troisième année avait pour but le déroulement de la seconde
campagne d’évaluation. Les ressources nécessaires étaient produites au préalable et le
protocole a été amélioré entre la première campagne et la seconde.
Une page Internet dédiée a été créée sur le portail Technolangue de même qu’une liste
de diffusion interne. De nombreuses publications ont été réalisées, autant pour annoncer
les campagnes d’évaluation que pour en publier les résultats ou pour décrire des mesures
d’évaluation ou des systèmes de traduction automatique utilisés au cours du projet.
3.1.2
Définir la tâche de contrôle et ses objectifs
3.1.2.1
Description
La conduite d’une évaluation passe par la définition de ce qui sera évalué et la description des résultats attendus. L’évaluateur justifie les actions entreprises ou à entreprendre
en fonction des objectifs initiaux. C’est lors de cette étape qu’il définit les grandes lignes
du projet d’évaluation : ce que l’on cherche à évaluer et dans quel contexte.
Les acteurs impliqués dans l’évaluation sont parfois nombreux et il est nécessaire qu’ils
aient la même vue d’ensemble du problème, la même compréhension et la même interprétation. Dès lors qu’un consensus est établi, un modèle de tâches à accomplir est défini. Il
identifie les différentes tâches liées à l’évaluation, puis les agents susceptibles de remplir
ces tâches et enfin assigne une tâche à un ou plusieurs agents.
La formulation du problème est primordiale : elle met en accord tous les acteurs de
l’évaluation. Les éléments sont ensuite communiqués, partiellement ou non, à l’ensemble
de la communauté. L’intérêt de l’évaluation doit y être clair. Il se reflète dans la description de la tâche de contrôle et l’assignation des différentes actions aux acteurs du projet
d’évaluation.
1. http ://www.technolangue.net
56
2.1.
2.2.
2.3.
2.4.
2.5.
Définition des caractéristiques évaluées
Mise au point des résultats attendus
Justifications et établissement d’un consensus entre les acteurs
Définition d’un modèle des tâches
Dissémination des informations sur l’évaluation
Table 3.3 – Les étapes de la définition de la tâche de contrôle.
3.1.2.2
Dans CESART, trois tâches de contrôle ont été définies :
– Extraction des termes pour la création d’un référentiel terminologique sans qu’aucun
référentiel de base soit fourni (tâche T1 ), le but étant de fournir une liste ordonnée
(par défaut selon la fréquence documentaire) ;
– Indexation contrôlée pour l’enrichissement de thésaurus (tâche T2 ) à partir d’un
corpus spécialisé et d’un thésaurus pré existant ;
– Extraction des relations sémantiques (synonymie) à partir d’une liste de termes
amorces (tâche T3 ), le but étant de trouver les relations entre un terme amorce et
un autre terme.
Les campagnes d’évaluation correspondant aux trois tâches se déroulaient séquentiellement et les données de sorties étaient réutilisées en entrée pour les tâches suivantes.
3.1.2.3
L’objectif de la première campagne d’évaluation était de fournir une mesure des performances de systèmes de traduction automatique. Celle-ci se faisait à l’aide de l’ensemble des
métriques prévues pour les campagnes CESTA en utilisant des textes du domaine général.
Deux directions de traduction, de l’anglais et de l’arabe vers le français, ont été testées
[Surcin et al., 2005]. Par ailleurs, un second objectif de cette campagne d’évaluation était
de développer et d’expérimenter de nouvelles métriques d’évaluation.
Au delà de l’évaluation comparative des performances, l’un des objectifs de la seconde campagne était d’améliorer la robustesse et la fiabilité du protocole d’évaluation
[Hamon et al., 2006]. Mais l’objectif innovant de cette seconde campagne était surtout de
mesurer l’impact d’une adaptation des systèmes de traduction automatique au domaine
des textes à traduire (celui de la santé). C’est pourquoi deux séries de scores étaient prévues avec ce protocole d’évaluation amélioré : l’une utilise des versions « génériques » des
systèmes et l’autre utilise des versions adaptées au domaine spécialisé. Les participants
à la seconde campagne recevaient un corpus bilingue d’adaptation afin d’adapter leurs
systèmes pendant deux semaines avant l’évaluation proprement dite 1 .
1. En pratique, le corpus d’adaptation était de taille relativement faible - environ 20 000 mots - ce qui
a posé problème à certains participants. Toutefois, tous les systèmes ont obtenus de meilleurs résultats
après adaptation, signifiant par cela l’intérêt d’un tel corpus, même de faible taille.
57
3.1.3
Cibler les participants et les acteurs
3.1.3.1
Description
Les différents acteurs extérieurs sont identifiés en relation directe avec la tâche de
contrôle et des objectifs. De prime abord, ils sont susceptibles d’être intéressés par l’évaluation proposée et d’être associés à la réflexion autour de l’évaluation. Ces acteurs sont
d’origines diverses : développeurs de système et participants, développeurs ou distributeurs de ressources, évaluateurs, experts, etc. Cela s’étend aux personnes intéressées par
les résultats de l’évaluation, tels que les examinateurs d’un projet, ou tout simplement la
communauté autour d’une technologie.
L’identification des acteurs et, avant tout, celle des participants proposant leurs systèmes passe bien souvent par l’utilisation de « réseaux » alliant rapidité et souplesse :
associations, connaissances, partenaires anciens ou actuels, sur d’autres projets, etc. Il
existe aussi les listes de diffusion, forums, conférences, réunions, etc.
Ensuite, les acteurs potentiels sont contactés et les formalités administratives sont
effectuées après acceptation, comme la signature d’un contrat ou de licences d’utilisation. Ces derniers rendent possible légalement l’utilisation de ressources ou d’outils et
concrétisent les obligations et droits des acteurs.
L’objectif est d’ouvrir le projet d’évaluation au maximum de personnes intéressées par
le sujet, lesquelles apportent en retour une valeur ajoutée au projet.
Finalement, une fois cette équipe formée, il faut la maintenir impliquée dans le projet
autour de réunions, animations, liste de diffusion, etc.
3.1.
3.2.
3.3.
3.4.
Identification des acteurs
Contact des acteurs identifiés
Formalisation administrative
Animation de l’équipe formée
Table 3.4 – Les étapes pour cibler les acteurs de l’évaluation.
3.1.3.2
Plusieurs acteurs ont été identifiés au cours des deux premières années. Sur la douzaine
de participants potentiels identifiés [Timimi et Mustafa El Hadi, 2008], six ont réellement
participé : cinq pour la tâche T1 (CEA, deux systèmes de l’Université de Montréal, EDF
et TEMIS), un seul pour la tâche T3 (l’Université Paris XIII). La tâche T2 n’a pas eu
lieu faute de participant.
3.1.3.3
Plusieurs acteurs ont été identifiés au cours des différentes conférences du domaine,
via des contacts directs ou par le biais des listes de diffusion : les participants, d’une part,
mais aussi des experts du domaine et des fournisseurs ou producteurs de ressources.
Au total, sept systèmes ont participé à la première campagne d’évaluation (cinq pour
la direction de l’anglais vers le français, deux pour la direction de l’arabe vers le français).
58
Six systèmes ont participé à la seconde campagne (cinq pour la direction de l’anglais
vers le français et un pour la direction de l’arabe vers le français). Le manque de temps,
de moyen (la participation aux campagnes d’évaluation n’était pas subventionnée) ou
d’intérêt (directions de traduction, données, protocole...) sont des explications possibles
au manque de participants. Selon les conventions de CESTA et dès le début du projet, il
a été décidé que les résultats des systèmes seraient anonymisés.
3.1.4
Établir des critères de qualité
3.1.4.1
Description
À partir des caractéristiques des systèmes évalués, l’évaluateur détermine quels sont
les critères adéquats pour estimer le niveau de qualité atteint. Après les avoir identifiées,
les plus pertinentes sont sélectionnées afin de déterminer les critères de qualité qui sont
utilisés par la suite. Tous les critères sont décrits afin d’ôter toute ambiguïté sur leur
compréhension ou leur interprétation. Une échelle graduée de valeurs est ensuite établie
pour identifier les niveaux de qualité atteints.
Une fois que les critères de qualité et que leur description sont acceptés par tous
les acteurs du projet d’évaluation, une recherche des mesures d’évaluation (cf. section
2.2.4.3) correspondantes est effectuée. Le type de critère (intrinsèque ou extrinsèque) est
décidé, de même que la méthode d’évaluation, selon que l’on veuille comparer des systèmes
ou bien évaluer un système isolé. D’autres paramètres entrent en jeu comme le coût de
l’évaluation. Cela force parfois à modifier la définition des critères, voire à les changer.
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
Recueil des caractéristiques du type de système évalué
Définition des critères de qualité
Description détaillée des critères
Définition d’une échelle de valeurs
Recherche des mesures d’évaluation
Retour à l’étape 4.2 si les méthodes d’évaluation ne conviennent pas
Table 3.5 – Les étapes pour établir les critères de qualité.
3.1.4.2
Les critères de qualité ont été définis pour chacune des tâches de contrôle à partir de
caractéristiques communes aux systèmes évalués (cf. tableau 3.6) 1 .
3.1.4.3
Quelle que soit la campagne, deux critères de qualité ont été retenus, présentés dans
le tableau 3.7 2 .
1. Pour les détails des éléments du tableau, se référer à la section 2.2.4.4
2. Pour les détails des éléments du tableau, se référer à la section 2.2.4.4
59
Tâche
T1
T3
Caractéristique
Renvoi de candidats termes
Critère
Type
Les candidats termes ren- Intrinsèque
voyés sont pertinents pour
la création d’un référentiel
selon un corpus donné
Renvoi de relations Les relations de synonymie Intrinsèque
de synonymie
candidates sont pertinentes
par rapport aux domaine et
corpus
Méthode
Comparative
Comparative
Table 3.6 – Caractéristiques des systèmes et critères de qualité dans CESART.
Caractéristique
Le système renvoie une
traduction conservant le
contenu sémantique
Le système renvoie une
traduction écrite correctement en langue cible
Critère
Type
Adéquation : le texte cible Intrinsèque
contient les mêmes informations que le texte source
Fluidité : le texte renvoyé Intrinsèque
est écrit en français compréhensible (fluide)
Méthode
Comparative
Comparative
Table 3.7 – Caractéristiques des systèmes et critères de qualité dans CESTA.
3.1.5
Définir les mesures de la qualité
3.1.5.1
Description
Après avoir défini les critères d’évaluation, le niveau de qualité atteint doit être identifié pour chaque système évalué. Pour ce faire, des mesures d’évaluation sont utilisées,
utilisant des métriques d’évaluation automatiques ou humaines. Les premières dépendent
du modèle de référence (restriction à un domaine, à une approche, au manque de données, etc.), mais les secondes sont subjectives et dépendent du choix des juges, qu’ils
soient experts ou non. L’objectif de l’évaluateur est de limiter l’impact de ces défauts. En
conséquence, il définit au mieux les mesures avant que l’évaluation ne soit conduite.
D’après l’ISO 9126, la sélection des mesures d’évaluation est la première étape lors
de la préparation de l’évaluation 1 . Pour l’ISO, les caractéristiques du système doivent
être prises en compte pour la définition des mesures et être conformes aux attentes d’un
utilisateur. Nous considérons que cette sélection se fait par rapport aux critères définis, la
mesure devant être en adéquation avec le critère. Associée à cette sélection, la définition
d’une échelle de valeurs a aussi son importance puisqu’elle indique la façon d’interpréter
les résultats. Elle rend compte du niveau atteint pour un critère donné et, par extension,
indique si les caractéristiques des systèmes remplissent les attentes ou non.
Une mesure a pour objectif d’être valide et fiable. La validité caractérise l’aptitude de
la mesure à atteindre ses objectifs tout en étant dépourvue d’erreurs. Quant à la fiabilité
de la mesure, elle s’établit au fur et à mesure des expérimentations partir de la variation
des paramètres de l’évaluation : contexte, systèmes, domaines, etc. Nous revenons sur ces
points dans le chapitre 5.
1. Ce qui la situe loin de notre position, puisqu’elle se situe en cinquième phase de ce premier cycle.
60
Après avoir défini les mesures de la qualité, il reste à définir plus concrètement la
ou les métriques utilisées, c’est à dire les outils de calcul des résultats. Trois possibilités
s’offrent alors à l’évaluateur : utiliser l’existant, l’adapter ou développer de nouvelles
métriques (lorsque l’existant est peu fiable ou inadapté, ou lorsqu’une nouvelle méthode
d’évaluation apparaît).
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
Définition ou sélection des mesures
Sélection des niveaux de classement
Définition des métriques d’évaluation
Développement des métriques d’évaluation
Test des métriques développées
Retour à l’étape 5.3. si les métriques ne conviennent pas
Table 3.8 – Les étapes pour définir les mesures de la qualité.
3.1.5.2
Pour la tâche T1, nous avons défini la mesure suivante [Mustafa El Hadi et al., 2006]
de manière originale. Les participants renvoient une liste de candidats termes triés selon un ordre de pertinence au choix, et sinon par fréquence décroissante 1 . Des experts
exploitent ces candidats termes à l’aide d’une base terminologique représentative du domaine spécialisé. Les jugements se font hors contexte et en comparant les candidats termes
aux termes certifiés de la base terminologique.
Pour chaque candidat terme, l’expert a le choix entre cinq valeurs. Ces valeurs prennent
en considération les mots composant un candidat terme qui est souvent une expression
composée.
– Valeur 1 : le candidat est présent dans la terminologie ;
– Valeur 2 : le candidat est valide, mais n’est pas dans la terminologie ;
– Valeur 3 : tous les composants du candidat sont certifiés individuellement dans la
terminologie ;
– Valeur 4 : un seul composant du candidat est certifié dans la terminologie ;
– Valeur 5 : aucun composant du candidat n’est certifié dans la terminologie.
Nous partons du principe que plus un terme est composé de mots présents dans la
terminologie de référence et plus l’ordre de ces mots est respecté, plus ce terme est pertinent. Par ailleurs, le terme peut ne pas être dans la terminologie et être néanmoins valide,
le référentiel n’étant pas fixe dans ce cas précis. Cela montre toute l’intérêt d’utiliser une
mesure humaine dans ce cas précis.
L’expert suit l’ordre des critères, après une première passe automatique pour les termes
remplissant le critère 1 et pouvant être appariés automatiquement avec la base terminologique. Ainsi, lorsque le candidat terme expertisé ne répond pas au critère 1, l’expert teste
le critère 2 et ainsi de suite. Une précision cumulée est ensuite calculée sur les n premiers
candidats termes (cf. chapitre 5).
1. Ce choix peut prêter à discussion : deux critères sont alors évalués, la pertinence des candidats
termes et le choix de classement, rendant plus difficile l’interprétation des résultats. La comparaison
entre systèmes est déjà elle-même rendue difficile.
61
Pour la tâche T3, la mesure est la suivante. Les systèmes d’extraction de synonymie
renvoient une liste de relations de synonymie entre les termes issus d’une liste de termes
amorces et des termes au choix dans le corpus d’évaluation. Pour chaque relation candidate, l’expert décide manuellement entre les deux critères : soit elle est « valide » soit elle
est « non valide ». Un score de précision est ensuite calculé automatiquement.
3.1.5.3
Deux types de mesures d’évaluation ont été employées dans CESTA : automatiques
et humaines. Cinq métriques automatiques ont été déployées lors des deux campagnes.
Elles se divisent en deux catégories. Celles de la première catégorie adoptent comme
approche la proximité de la traduction automatique avec une ou plusieurs traductions
humaines, les traductions de référence, fournies par des traducteurs professionnels. Elle
utilise la métrique BLEU (BiLingual Evaluation Understudy), une métrique automatique, développée par IBM [Papineni et al., 2002]. Comme pour sa variante élaborée par
le NIST [Doddington, 2002], le principe est de comparer les phrases sorties du système
aux phrases de référence correspondantes sur la base de séquences de n-grammes (à savoir une séquence ordonnée de n mots) ; la méthode WNM (Weighted N-gram Model)
[Babych et Hartley, 2004, Babych et al., 2005] part du principe que, étant donné la variation légitime inhérente à toute traduction, tous les mots ont des raisons différentes
d’être préservés par un processus de traduction. Tout en adoptant l’approche utilisant les
n-grammes, elle introduit une pondération pour les mots identifiés comme étant significatifs.
En revanche, les métriques de la deuxième catégorie ne font pas appel à des traductions
de référence des textes source, mais à des corpus autonomes représentatifs de la langue
cible et, éventuellement, de la langue source. Ces métriques sont le X-score et le D-score
[Rajman et Hartley, 2001, Rajman et Hartley, 2002, Hamon et Rajman, 2006] que nous
avons développées. Celles-ci ont été utilisées à titre expérimental car leur fiabilité n’est
pas entièrement démontrée, comme le suggèrent les résultats (cf. chapitre 5).
Les mesures humaines ont pour double intérêt l’évaluation des systèmes et la métaévaluation des mesures automatiques en comparant les scores humains aux scores automatiques. Deux métriques d’évaluation ont été retenues : la fluidité et l’adéquation,
s’inspirant des campagnes d’évaluation DARPA [White et al., 1994].
3.1.6
Constituer les ressources linguistiques
3.1.6.1
Description
Une étape essentielle et souvent sous-estimée lors de l’organisation d’évaluations est le
développement ou l’acquisition des ressources. Elles sont utilisées par les mesures d’évaluation, ou directement par les systèmes. C’est une des étapes les plus coûteuse si l’on fait
abstraction des mesures humaines.
Six grandes étapes sont généralement fixées pour la constitution de ressources. Il s’agit
tout d’abord de spécifier les ressources nécessaires dans le contexte de l’évaluation en
cours, en termes de quantité mais aussi en termes de qualité : les ressources utilisées
doivent être représentatives de la tâche. Puis, l’évaluateur identifie les ressources à utiliser.
Il peut aussi bien s’agir de nouvelles données (provenant par exemple de pages Internet) ou
62
de données préexistantes qui seront réutilisées. Quel que soit le cas de figure, cela nécessite
d’engager des négociations afin d’obtenir les droits d’utilisation des ces données. Ensuite,
les données sont extraites et formatées en fonction de la tâche de contrôle et du format.
Cette étape se fait manuellement ou automatiquement, ou combine les deux possibilités,
selon les cas de figure. Finalement, il est indispensable de valider les ressources constituées,
ce qui peut se faire de manière formelle (par l’utilisation de critères de validation spécifiés
à l’avance) ou non (vérification rapide par un humain). Dans le second cas, le développeur
de ressources estime de manière moins rigoureuse qu’une vérification rapide et succincte
est suffisante.
Par ailleurs, il faut prendre en compte le renouvellement des ressources et l’importante
demande, dus à une utilisation plus fréquente et croissante dans le temps : les données
sont de moins en moins intéressantes au fur et à mesure que le temps passe. Dès lors
que les données sont de plus en plus « connues » par les systèmes, elles ne seront alors
plus utiles pour l’apprentissage, ou biaiseront l’évaluation si elles sont utilisées en tant
que corpus de test. Il est alors nécessaire de constituer de nouvelles ressources, sur de
nouveaux domaines, pour des contextes différents.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
Spécification des besoins
Identification des ressources
Négociation des droits d’utilisation
Acquisition de données
Formatage des données
Validation des données créées
Correction des données (le cas échéant)
Table 3.9 – Les étapes pour constituer les ressources.
3.1.6.2
Plusieurs ressources ont été utilisées pour mener à bien la campagne du projet CESART :
– un corpus de textes issus d’un domaine spécialisé pour les deux tâches d’évaluation ;
– un thésaurus du même domaine comme référence de la tâche T1 ;
– une liste de termes amorces correspondant au corpus pour la tâche T3 ;
– les résultats des jugements humains.
L’idée originale était de collecter des ressources dans le but de constituer un corpus
de textes d’un domaine spécialisé, en vue d’une extraction terminologique. Le domaine
retenu a été le domaine de la santé. Il était également question de « masquer » le corpus
sur lequel porterait l’évaluation, à la manière dont sont masquées les données à traduire
en traduction automatique : du contenu est ajouté afin que les participants ne sachent
pas sur quelles données porte l’évaluation. Dès lors, deux choix était possibles : séparer
le corpus en plusieurs parties (l’une servant pour l’évaluation, l’autre pour le masquage
du premier), mais la couverture terminologique en aurait été biaisée ; construire deux
autres corpus qui ne seraient pas évalués mais que les systèmes traiteraient tout de même.
Le second choix a été retenu et finalement deux des trois corpus ont été évalués, un seul
63
faisant office de masquage, pour « perturber » les participants. Après coup, il nous semble
que ce corpus de masquage n’est pas utile en évaluation des systèmes terminologiques : le
volume des données est généralement suffisamment important pour que les participants
ne puissent réaliser de travail manuel.
Les fichiers contenant les corpus devaient être encodés en UTF-8, selon une DTD bien
précise (cf. figure 3.1), de même que la liste de termes amorces (cf. figure 3.2).
<!DOCTYPE FILESET [
<!ELEMENT FILESET (DOC∗)>
<!ATTLIST FILE f i l e i d CDATA #REQUIRED>
<!ELEMENT DOC (SEG∗)>
<!ATTLIST DOC d o c i d CDATA #REQUIRED>
<!ELEMENT SEG (#PCDATA)>
<!ATTLIST SEG s e g i d CDATA #REQUIRED>
]>
Figure 3.1 – DTD du corpus original.
<!DOCTYPE FILESET [
<!ELEMENT FILESET (TERME∗)>
<!ATTLIST FILESET s e t i d CDATA #REQUIRED>
<!ELEMENT TERME (#PCDATA)>
<!ATTLIST TERME ( t e r m e i d ) CDATA #REQUIRED>
]>
Figure 3.2 – DTD de la liste de termes amorces.
La thématique du premier corpus CESART (corpus C1 ) est le domaine de la santé, créé
à partir de pages Internet provenant du site Santé Canada 1 . La thématique du deuxième
corpus (corpus C2 ) est le domaine de l’éducation, il s’agit du corpus Spirale tiré de la
revue du même nom 2 . Enfin, la thématique du troisième et dernier corpus (corpus C3 )
est le domaine politique, tiré du Journal Officiel de la Communauté Européenne 3 (JOC).
Le domaine médical étant choisi, il nous a semblé normal de nous intéresser au site
de Santé Canada car les droits d’utilisation existaient déjà suite à la campagne EVALDA/EQueR (cf. annexe A.5) et les ressources étaient nombreuses. De plus, le CISMeF 4
(Catalogage et Indexation des Sites Médicaux Francophones) était à même de fournir le
thésaurus Mesh 5 . Le choix d’un corpus sur l’éducation s’est également imposé, puisque
1.
2.
3.
4.
5.
http
http
http
http
http
://www.hc-sc.gc.ca
://spirale-edu-revue.fr
://catalog.elra.info/product_info.php ?products_id=534
://www.chu-rouen.fr/cismef/
://www.nlm.nih.gov/mesh
64
l’Université de Lille 3 disposait du corpus Spirale (provenant de la revue scientifique Spirale) et le thésaurus Motbis 1 était lui aussi disponible. Comme corpus de masquage, nous
avons choisi le JOC car il était disponible rapidement dans le catalogue d’ELRA. L’ensemble de ces choix montre l’importance de l’existant et de la connaissance des ressources
disponibles.
Pour la constitution du corpus médical, un partenaire du projet a fourni près de 13 000
URLs provenant du site Santé Canada. À partir de ces URLs, il a été possible « d’aspirer »
les pages correspondantes. À l’origine, les documents contiennent beaucoup de bruit, avec
beaucoup de données inutiles, comme par exemple les index ou les menus des pages, mais
le format HTML est simple, avec un étiquetage < DOC > pour les documents, et < P >
pour les paragraphes qui contenaient plusieurs phrases et ont été considérés comme les
parties intéressantes à conserver. Après transformation du code HTML en format brut,
les données étaient encore très bruitées. Nous avons donc effectué un nettoyage du corpus
obtenu. Ce nettoyage, laborieux, a été fait pour une petite partie automatiquement, et
pour une grande partie manuellement. La procédure automatique est sommaire : suppression des retours à la ligne au milieu d’une phrase, formatage des données (une phrase par
segment, suppression des espaces doubles, encodage UTF-8, etc.), suppression du balisage
HTML, nettoyage des erreurs générées lors de la conversion des fichiers PDF, etc. Il s’est
avéré (lors de la phase d’adjudication) que beaucoup d’erreurs subsistaient même après
ce nettoyage, comme des mots collés. Au final, plus de 7 500 documents ont été formatés selon notre DTD pour un total de 255 161 phrases. Ils représentent un volume de 9
millions mots environ.
Le corpus Spirale a été constitué approximativement de la même manière, à ceci près
que les fichiers d’origine étaient au format RTF. Nous avons préféré les convertir en format
HTML afin de pouvoir les convertir à nouveau en données brutes de la même manière que
pour le corpus médical. 152 documents étaient disponibles et les opérations appliquées
ont été les mêmes avec un nettoyage automatique, puis un nettoyage manuel. Au final,
149 documents ont été constitués comprenant plus de 12 000 phrases, ce qui représente
environ 535 000 mots.
Le corpus JOC était déjà constitué et un simple reformatage a été nécessaire pour qu’il
soit conforme à notre DTD. Au final, le corpus JOC est constitué de 1 477 documents
pour environ 9 000 phrases et environ 240 000 mots.
La construction des termes amorces pour la tâche T3 s’est faite en plusieurs étapes.
Nous avons tout d’abord choisi de réutiliser la sortie des systèmes de la tâche T1. Seuls
deux systèmes étaient alors disponibles. Nous avons appariés les deux sorties pour en faire
ressortir les termes les plus pertinents, d’après les systèmes automatiques. À cette sortie,
nous avons ensuite apparié le thésaurus UMLS 2 (Unified Medical Language System) afin
d’enrichir et de valider la liste obtenue et de supprimer les synonymes qui auraient pu
y être inclus. Au final 423 termes ont été retenus. Le même principe à été adopté pour
créer la liste des termes amorces du corpus Spirale. Le thésaurus utilisé a été le Thésaurus
Européen de l’Éducation Motbis. De même que pour les deux autres domaines, la liste
des termes amorces a été constituée en appariant les sorties des outils d’extraction.
1. http ://www.motbis.fr
2. http ://umlsinfo.nlm.nih.gov
65
3.1.6.3
Les fichiers contenant les corpus source, les corpus de référence et les traductions
candidates sont encodés en UTF-8 et respectent le format SGML qu’utilise le NIST
[NIST, 2003] pour ses campagnes d’évaluation. Nous présentons ci-dessous des exemples
de format pour les corpus source (3.3), de référence (3.4) et cible (3.5).
<SRCSET SetID="CESTA−RUN1−EN" SrcLang="E n g l i s h">
<DOC DocID="DOC−1">
<SEG i d ="1"> s o u r c e t e x t </SEG>
<SEG i d ="2" >... </SEG>
</DOC>
...
</DOC>
...
</SRCSET>
Figure 3.3 – Format SGML des documents sources des campagnes d’évaluation CESTA.
<REFSET SetID="CESTA−RUN1−EN" SrcLang="E n g l i s h " Trglang="French">
<DOC DocID="DOC−1" SysID=" r e f −1">
<SEG i d ="1"> t e x t e s o u r c e </SEG>
<SEG i d ="2" >... </SEG>
</DOC>
...
</DOC>
...
</REFSET>
Figure 3.4 – Format SGML des documents références des campagnes d’évaluation
CESTA.
Lors des campagnes d’évaluation, chaque participant identifie son système de traduction automatique à l’aide de l’attribut SysID qui lui est fourni par l’ELDA. Chaque
participant a la possibilité de soumettre plusieurs systèmes avec des SysID différents pour
chaque fichier envoyé.
Les documents ont été segmentés par phrase et trois traductions de référence ont été
produites par des agences de traduction, en plus de la traduction officielle du site Santé
Canada. Le corpus d’évaluation que nous avons envoyé aux participants se décomposent
en deux parties : le corpus de test et le corpus de masquage. Le corpus de test contient les
données sur lesquelles sont calculés les résultats. Ce corpus de test est noyé dans un corpus
66
<TSTSET SetID="CESTA−RUN1−EN" SrcLang="E n g l i s h " TrgLang="French">
<DOC DocID="DOC−1" SysID="system −1">
<SEG i d ="1"> t e x t e s o u r c e </SEG>
<SEG i d ="2" >... </SEG>
</DOC>
...
</DOC>
...
</TSTSET>
Figure 3.5 – Format SGML des documents tests des campagnes d’évaluation CESTA.
de masquage qui « cache » le corpus de test aux participants. Ceux-ci ignorent donc sur
quelle partie des données leur système sera évalué. Le corpus de masquage est beaucoup
plus volumineux que le corpus de test afin d’empêcher la traduction ou la correction
manuelle des textes, mais il est de même nature que celle du corpus de test. Pour les deux
campagnes d’évaluation, le corpus de masquage est à chaque fois de 200 000 mots, tandis
que le corpus de test est de 20 000 mots.
L’idée initiale était de trouver un ensemble de textes parallèles directement disponibles
en 3 langues (anglais, français et arabe). La raison est simple : le fait de travailler sur les
mêmes textes dans les deux directions nous procurait un certain « confort d’utilisation »
et l’obtention de textes déjà parallèles nous permettait aussi d’économiser une traduction
humaine par rapport au protocole établi par le NIST, qui préconisait à l’époque quatre
traductions de référence pour chaque texte.
Pour la première campagne d’évaluation, notre choix s’est initialement porté sur les
rapports de la 32e Conférence générale de l’UNESCO parce qu’ils sont disponibles dans
un grand nombre de langues, y compris les trois qui nous intéressaient et que l’ELDA
dispose des droits pour leur utilisation. Malheureusement, l’exploitation des documents
pose d’énormes problèmes, en particulier quand il s’agit de récupérer les documents arabes
sous un format facilement utilisable : ils se présentent sous forme de documents PDF et
nous n’avons trouvé aucun logiciel de conversion capable de fournir des fichiers de sortie
exploitables. De plus, pour procéder à une étude de faisabilité des outils et des ressources,
nous avons mené une mini campagne au sein d’ELDA sur un corpus anglais/français
tiré des documents de l’UNESCO. L’une des conclusions que nous avons tirées de cette
étude est que le style et le vocabulaire rendent les textes « extrêmement difficiles à lire »
[Hamon, 2004a]. Beaucoup de tournures et de termes techniques y sont propres à l’administration et à la diplomatie. Face à ces difficultés qui commençaient à être nombreuses,
nous avons préféré éliminer ces documents pour cette campagne d’évaluation censée utiliser des textes plus généraux. Nous avons donc cherché d’autres sources de documents.
Pour la direction de traduction de l’anglais vers le français, afin de minimiser les
négociations de droits et les coûts afférents, nous nous sommes tourné vers des documents
déjà présents dans le catalogue d’ELRA, le corpus MLCC 1 . Il est composé de deux parties :
1. Référence W0023 du catalogue ELRA.
67
un corpus multilingue parallèle reprenant les Questions Écrites au Parlement Européen
et des Débats du Parlement Européen dans toutes les langues officielles de l’Union de la
période 1992-1993 ; un corpus multilingue contenant des collections d’articles de journaux
de la même époque pour chaque langue de l’Union. Les documents originaux se présentent
sous forme d’un ensemble de fichiers au format TEI lui-même issu de SGML. Après
vérification de l’encodage, le contenu des balises < P > est extrait et formaté dans notre
format SGML, plus simple.
Le corpus de test est finalement composé de 16 documents extraits du corpus MLCC
provenant du Journal Officiel des Communautés Européennes 1993, section des Questions
Écrites au Parlement Européen. Il représente un volume supérieur à 20 000 mots anglais et
22 000 mots français pour la traduction de référence officielle tirée directement du corpus
MLCC. Les trois autres références ont été établies à partir de trois traducteurs différents.
Pour construire le corpus de masquage, nous sommes parti d’un sous-ensemble du corpus
du Financial Times 1993. Son volume total est supérieur à 200 000 mots anglais.
Pour la direction de traduction de l’arabe vers le français, nous nous sommes concerté
avec l’équipe du projet ARCADE II [Véronis et al., 2008] afin de réutiliser un corpus aligné arabe/français en cours de production dans le cadre de ce projet. Le corpus que nous
avons obtenu est constitué d’un ensemble d’articles issus du Monde diplomatique 2001,
2002 et 2003, sous forme XML et encodés en UTF-8. Seuls certains articles de ce corpus ont réellement été utilisés pour la campagne, car de nombreux articles présentaient
des problèmes similaires à ceux rencontrés dans presque tous les corpus parallèles arabe/français : les deux versions ne correspondent pas vraiment car la plupart du temps la
version traduite tient plus de la réécriture que de la traduction. Même sans cela, il subsiste
beaucoup d’autres problèmes relatifs, entre autres, aux chiffres, à la typographie et aux
notes de bas de page. Nous nous sommes donc limité au sous-ensemble des articles qui ne
présentent pas de problème d’alignement : certains articles de 2002 et une paire d’articles
de 2003.
Le corpus de test est composé de 16 articles du Monde diplomatique publiés en 2002
et en 2003. Ils représentent un volume supérieur à 23 000 mots arabes et 28 000 mots
français pour la traduction de référence qui provient du Monde diplomatique. Les trois
autres traductions humaines ont été produites par des agences de traduction. Le journal
arabe Al-Hayat 1998 1 , section « nouvelles » a été utilisé pour construire le corpus de
masquage après conversion dans notre format. Son volume total est d’environ 223 813
mots arabes.
3.1.7
Spécifier et organiser les interactions entre acteurs
3.1.7.1
Description
L’étape concernant l’organisation des interactions entre les acteurs du projet d’évaluation est le plus souvent faite de manière informelle, à tort selon nous. En effet, elle
facilite la cohésion du projet et permet d’éviter certains pièges lors du déroulement de
l’évaluation : perte de données, erreurs de format, mauvaise compréhension du protocole,
interprétation différente des résultats. C’est un des intérêts de l’architecture automatisée
que de délimiter strictement les interactions entre acteurs.
1. Référence W0030 du catalogue ELRA W0030.
68
Nos expérimentations menées au cours des divers projets d’évaluation nous ont permis
de constater l’impact de l’aspect humain dans les interactions entre partenaires. Avant
même de parler du format des fichiers (XML, SGML, etc.), le format des noms de fichiers
peut déjà poser problème. Par exemple dans le cadre du projet TC-STAR/SLT, les noms
de fichier renvoyés par les participants devaient identifier à la fois le participant, la direction de traduction, le domaine et le type de soumission pour une meilleure organisation
de l’évaluation et des traitements automatiques ; peu de participants ont finalement renvoyé un fichier correspondant à ce format. Alors, lorsqu’une centaine de fichiers doit être
renvoyée par e-mail, cela devient rapidement un casse-tête. Étant donné l’utilisation de
certains outils d’évaluation, la modification des fichiers et de leur format peut se révéler
encore plus complexe : modification des balises XML, du format d’encodage, etc.
Finalement, les recommandations faites aux participants doivent être les plus claires
et simples possibles. La plupart du temps, les participants sont déjà préoccupés par les
problèmes relatifs à leurs systèmes et ne sont pas vraiment concernés par ceux relatifs
à l’évaluation. D’un autre côté, la plus grande attention doit être accordée aux données
envoyées aux participants et fournies aux systèmes.
7.1. Définition de recommandations claires et simples aux acteurs
7.2. Validation des procédures
Table 3.10 – Les étapes d’organisation des interactions entre acteurs.
3.1.7.2
Les participants devaient renvoyer les résultats de leurs systèmes selon une DTD bien
précise, que ce soit pour la liste ordonnée de termes (cf. figure 3.6) ou la liste de relations
(cf. figure 3.7). Les fichiers renvoyés étaient alors testés à l’aide de l’outil XMLInt et
renvoyés s’ils ne correspondaient pas à la DTD.
<!DOCTYPE FILESET [
<!ELEMENT FILESET (TERME∗)>
<!ELEMENT TERME (FORME_CANONIQUE, RANG_PERTINENCE,
\\ VARIATIONS+, FREQUENCE, CONTEXTE)>
<!ATTLIST TERME t e r m e i d CDATA #REQUIRED>
<!ELEMENT FORME_CANONIQUE (#PCDATA)>
<!ELEMENT RANG_PERTINENCE (#PCDATA)>
<!ELEMENT VARIATIONS (#PCDATA)>
<!ELEMENT FREQUENCE (#PCDATA)>
<!ELEMENT CONTEXTE (#PCDATA)>
<!ATTLIST CONTEXTE ( docid , s e g i d ) CDATA #REQUIRED>
]>
Figure 3.6 – DTD du corpus de la liste ordonnée de termes.
69
<!DOCTYPE FILESET [
<!ELEMENT FILESET (TRIPLET∗)>
<!ELEMENT TRIPLET (TERME_SOURCE, RELATION,
\\ TERME_CIBLE, OCCURRENCES, CONTEXTE)>
<!ATTLIST TERME t e r m e i d CDATA #REQUIRED>
<!ELEMENT TERME_SOURCE (#PCDATA)>
<!ELEMENT RELATION (#PCDATA)>
<!ELEMENT TERME_CIBLE (#PCDATA)>
<!ELEMENT OCCURENCES (#PCDATA)>
<!ELEMENT CONTEXTE (#PCDATA)>
<!ATTLIST CONTEXTE ( docid , s e g i d ) CDATA #REQUIRED>
]>
Figure 3.7 – DTD des relations renvoyées.
3.1.7.3
Les participants devaient renvoyer des résultats de leurs systèmes conformes au pseudo
XML du corpus cible détaillé précédemment. Des scripts en langage PERL permettaient
de valider les fichiers et d’accepter ou non leur format. En théorie, des fichiers mal formatés
étaient renvoyés aux participants, sous peine de ne pas être évalués. En pratique les erreurs
mineures sont bien souvent corrigées par l’évaluateur...
3.1.8
Préparer l’évaluation
La préparation de l’évaluation est le résultat des phases précédentes et finalise le cycle
afin de faciliter le démarrage du cycle suivant. La préparation passe tout d’abord par
le développement des ressources et mesures comme nous l’avons décrit précédemment.
Puis, tous les éléments applicatifs et structurels sont mis en place : pour le dépôt de
fichiers (comptes FTP, mots de passe, autorisations, etc.), l’envoi de mails, le rappel des
procédures ou des délais, l’usage d’outils d’évaluation ou de formatage de données, etc.
Cette partie peut sembler fastidieuse, mais garantit (presque) le bon déroulement de
l’évaluation.
3.2
Phases d’évaluation
Après la préparation, le second cycle d’une évaluation permet la mise en place des
systèmes et leurs sorties sont traitées. D’après notre expérience, huit phases ponctuent
cette étape. Les trois premières phases sont optionnelles : l’apprentissage des systèmes,
le réglage des systèmes et le test à blanc. Les deux phases suivantes sont au cœur même
de l’évaluation (le test et l’analyse des résultats) et trois suivantes sont aussi optionnelles
(l’adjudication des résultats et les retours d’expérience, la diffusion des résultats et enfin la
pérennisation et la recherche de synergie). La méthodologie se définit par l’enchaînement
et le contenu de ces phases. La reproduction de toute évaluation devrait suivre dans le
70
3.2. Phases d’évaluation
moindre détail cette méthodologie originale pour pouvoir être comparée avec objectivité,
les divergences ne menant qu’à des approximations difficilement comparables. En pratique,
c’est en tenant compte du contexte et en relativisant les résultats obtenus que deux
évaluations différentes sont comparables.
Le tableau 3.11 fait la synthèse des différentes phases d’évaluation.
1.
2.
3.
4.
5.
6.
7.
8.
Phase d’apprentissage
Phase de réglage
Phase de test à blanc
Phase de test
Phase d’analyse des résultats
Phase de retour d’expériences et d’adjudication des résultats
Phase de diffusion
Pérennisation et recherche de synergie
Table 3.11 – Les phases d’une évaluation.
Dans CESART, aucune phase d’apprentissage ni de réglage des systèmes n’était prévue. La méthodologie d’évaluation comprenait une phase de test à blanc, une phase de test
et une phase d’analyse des résultats. Cette méthodologie est difficilement reproductible
en temps que telle car les tâches étaient exploratoires.
Dans CESTA, aucune phase d’apprentissage n’était prévue. Un test à blanc a eu lieu
pour la première campagne d’évaluation et les deux campagnes ont vu des phases de test,
d’analyse des résultats et d’adjudication. De plus, une phase de réglage s’est déroulée pour
la seconde campagne.
La méthodologie CESTA est aisément reproductible : les outils, les méthodes et le
protocole sont clairement établis. Les données sont également disponibles. Toutefois, une
comparaison des systèmes évaluées a posteriori serait malvenue, car le contexte est tout
de même différent : les juges ne seraient pas les mêmes, les systèmes et leurs données
d’entraînement à une date donnée seraient aussi différentes, etc.
3.2.1
Phase d’apprentissage
La phase d’apprentissage a pour objectif d’améliorer les systèmes. Le terme issu de
l’anglais training phase est plus souvent traduit par phase d’entraînement ce qui est à
notre sens un anglicisme : un système n’est pas « entraîné » au cours de cette phase, mais
le développeur lui fait « apprendre » quelque chose par expérience en lui fournissant des
connaissances. Dans la plupart des cas, de grandes quantités de données sont utilisées, qui
couvrent plusieurs types de domaines, genre, etc. Les systèmes découvrent un ensemble
de possibilités sans faire cas d’un type de données en particulier. Cette phase est en
particulier utile aux systèmes qui utilisent des modèles statistiques de traitement de la
langue. Dans une certaine mesure, plus la taille des données est importante, plus le modèle
est performant, du fait de la rencontre d’un plus grand nombre de manières de modéliser
la langue.
Dans le cadre d’une campagne d’évaluation, force est de reconnaître que l’évaluateur
est généralement moins regardant sur la qualité des données d’apprentissage que sur celles
71
des données de test. Avec la taille des données traitées 1 , il est très coûteux de valider
l’ensemble des données. De plus, le volume est tel que les erreurs sont noyées parmi
l’ensemble du corpus, dans une certaine mesure.
Les délais laissés à la phase d’apprentissage sont les plus longs car le développement
des systèmes requiert du temps (pouvant être supérieur à 6 mois). Les données sont
habituellement déposées sur un serveur FTP et les participants sont libres de télécharger
les corpus les intéressant. Dans nombre de campagnes d’évaluation, deux types de données
d’apprentissage émergent : celles qui se limitent aux données d’apprentissage du projet
d’évaluation ; celles qui se limitent à l’ensemble des données disponibles publiquement ou
non. Une restriction majeure est généralement imposée : l’utilisation des données n’est
autorisée que jusqu’à une date limite de création, correspondant au début de la sélection
des données de test (afin de ne pas superposer les données d’apprentissage et de test). Il
est aussi possible de supprimer les données de test de celles d’apprentissage, toujours pour
que les systèmes ne connaissent pas les données de test lors du démarrage de l’évaluation
et que les résultats ne soient pas biaisés.
3.2.2
Phase de réglage
3.2.2.1
Description
La phase de réglage, parfois appelée phase d’adaptation, permet aux participants d’optimiser les paramètres de leurs systèmes en utilisant des données de même type que celles
de la phase de test. Nous utilisons le terme « phase de réglage » pour désigner le terme anglais development phase qui est presque toujours traduit, à tort d’après nous, par « phase
de développement » : le risque est de confondre cette phase avec celle du réel développement informatique et technologique des systèmes. Nous préférons donc adopter le terme
de « phase de réglage ».
Au cours de cette phase, de nouvelles données sont fournies aux participants. Elles sont
similaires (c.-à-d. de même nature et de même domaine linguistique) à celles qui seront
fournies lors de la phase de test. Avec ces données, les participants règlent les paramètres
du système afin d’obtenir les meilleures performances possibles sur les données de test.
Le but recherché est d’optimiser les différents modules du système. La durée de la phase
de réglage n’est pas très longue (de l’ordre de quelques semaines) car elle nécessite peu
de travail de la part des participants et le volume de données est moindre 2 .
Plus particulièrement, la phase de réglage sert d’adaptation à un domaine spécifique,
un modèle de voix (en reconnaissance automatique de la parole), etc. Elle s’apparente
à un apprentissage sur de nouvelles données de taille plus réduite, mais spécialisées. En
effet, la taille des données n’est pas nécessairement très importante, mais elle contient
suffisamment d’éléments pour que les systèmes s’améliorent [Hamon et al., 2008c].
Tout comme pour la phase d’apprentissage, les données utilisées lors de la phase de
réglage ont une limite temporelle afin de ne pas superposer ces données avec celles de la
phase de test.
1. Dans le cadre du projet TC-STAR, la quantité de données d’apprentissage des systèmes de traduction automatique étaient supérieure à 35 millions de mots, au regard des 25 000 mots utilisés pour le test
des systèmes [Déchelotte et al., 2006].
2. Dans le cadre du projet TC-STAR, la taille des données de réglage était d’environ 20 000 mots, un
volume similaire aux données de test.
72
3.2.2.2
En traduction automatique (par règles), l’adaptation à un domaine consiste bien souvent à un enrichissement terminologique. Dans CESTA, cette phase implique d’utiliser un
dictionnaire préexistant du domaine de la santé, d’extraire des termes du corpus représentatif fourni par les organisateurs et de les insérer dans un dictionnaire utilisateur, ou
encore d’adapter le système à partir d’un corpus parallèle.
Aucune contrainte n’était imposée quant à la procédure d’adaptation, le risque étant
par conséquent que les participants cherchent à obtenir davantage de données similaires
au corpus fourni et parviennent à se procurer les données de test elles-mêmes (par exemple
via Internet). Lorsque cela s’est produit, dans un seul cas, un accord avec les développeurs
du système a permis de revenir à une version du système non adaptée aux données de
test.
Un corpus d’adaptation a été envoyé aux participants, d’une taille de 20 000 mots. Ils
disposaient de deux semaines pour adapter leurs systèmes.
3.2.3
Phase de test à blanc
3.2.3.1
Description
La phase de test à blanc (ou dry-run en anglais) sert à valider le protocole, le format
des données et les échanges entre partenaires. Elle sert de « répétition » à la phase de test
à venir, à la différence près que le contenu des données est différent, que les résultats ne
sont pas toujours calculés entièrement (pour les mesures humaines par exemple) et qu’il
n’y a pas d’étude des résultats.
Au cours de cette phase, des données ayant un format similaire à celles du test sont
envoyées aux participants, et leur contenu importe peu. Les sorties des systèmes sont
renvoyées de la même manière que pour la phase de test. Elles sont validées à l’aide
d’outils afin de déterminer si leur format est correct. Par exemple, un système d’extraction
terminologique reçoit un corpus d’un domaine sur lequel il n’est pas préparé. Des termes
incohérents (compte tenu de la tâche) sont renvoyés par le système, mais seul le format
est validé.
En fin de phase, chaque participant reçoit une notification quant aux problèmes rencontrés. Ces vérifications valent aussi pour l’évaluateur. La durée de la phase de test à
blanc est assez variable, elle dépend souvent de la disponibilité des participants mais aussi
de la difficulté à adapter les formats.
En résumé, le test à blanc est destiné à vérifier que les participants récupèrent bien le
corpus d’évaluation, qu’ils arrivent à le lire et à le traiter, que le format des données est
correct et enfin qu’aucun problème ne survient lorsque les productions des systèmes sont
renvoyées.
Cette phase est souvent organisée de manière informelle mais elle reste rigoureuse
quant aux résultats attendus, puisque le bon déroulement de l’évaluation de test en dépend.
3.2.3.2
Pour construire les corpus du test à blanc, nous avons utilisé une partie du corpus du
test à blanc de la campagne CESTA. Au total, le corpus était constitué de cinq documents
73
d’une taille d’environ 3 860 mots. Nous avons produit 40 termes amorces à partir du corpus
Eurovoc 1 en vérifiant manuellement leur présence dans le corpus.
La phase de test à blanc a débuté le 8 avril 2005 pour la tâche T1 et le 6 mai 2005 pour
la tâche T3. Elle a duré 3 semaines pour chaque tâche et tenait compte des obligations
respectives des participants. Quatre participants ont testé leur système pour la tâche T1,
deux participants pour la tâche T3.
Le protocole était le suivant. Pour la tâche T1, extraction de termes pour la création
de ressources terminologiques :
– ELDA envoie le jour J un corpus sur un domaine spécifique, au format de la DTD ;
– les participants envoient le jour J+2 une liste ordonnée de termes au format de la
DTD.
Pour la tâche T2, indexation contrôlée et enrichissement :
– le même corpus que celui de la tâche T1 est envoyé le jour J+4, accompagné du
thésaurus de termes. Ce thésaurus est la liste de termes et les descripteurs correspondants qui ont été envoyés par les participants lors de la tâche T1 ;
– les participants envoient au jour J+7 la liste de termes référant à chaque document
du corpus, susceptibles de l’indexer.
Pour la tâche T3, extraction de relations :
– ELDA envoie le jour J+9 le même corpus que celui de la tâche T1, une liste de
termes amorces et l’étiquetage morphosyntaxique du corpus ;
– les participants envoient le jour J+11 les triplets [terme source ; relation ; terme
cible] au format de la DTD.
D’une manière générale la campagne de test à blanc s’est bien déroulée. Il n’y a pas
eu de problème majeur dans les échanges entre les organisateurs et les participants, mis
à part quelques problèmes de construction de la DTD soulevés par des participants.
3.2.3.3
La phase de test à blanc s’est déroulée de la fin du mois d’août au début du mois de
septembre 2004. Six systèmes de traduction automatique ont participé à cette campagne :
cinq pour la direction de l’anglais vers le français, un pour la direction de l’arabe vers le
français.
Le protocole était le suivant :
1. Chaque participant envoie un e-mail pour déclarer la ou les directions de traduction
qu’il souhaite traiter parmi les deux choix proposés : l’anglais vers le français, l’arabe
vers le français.
2. À une date J, le corpus de test à blanc est envoyé aux participants, dans un format
SGML et encodé en UTF-8, selon la DTD des documents sources définie par le
NIST. Un identifiant unique de système est fourni à chaque participant.
3. À la date J+7, tous les participants renvoient par e-mail leurs traductions automatiques, également au format NIST (SGML et encodé en UTF-8, selon la DTD des
documents cibles).
4. À partir de ce moment, les fichiers fournis sont vérifiés. Un retour des participants
est également attendu sur les problèmes qu’ils ont éventuellement rencontrés.
1. http ://europa.eu/eurovoc/PDF/dom_12_FR.pdf
74
Nous avons produit un rapport de recommandations faisant suite aux problèmes rencontrés aussi bien par les organisateurs que par les participants au test à blanc (cf. tableau 3.12).
Éviter la séquence «<» en début de segment source
Isoler les balises <SEG...> et </SEG> sur des lignes séparées du contenu
du segment
Ne pas ajouter de saut de ligne à l’intérieur d’un segment
Ne pas remplacer l’attribut sysid par system
Bien respecter l’attribut docid (ne pas transformer CESTA_0001 en
CESTA0001)
Ne pas traduire le contenu des attributs (ne pas transformer trglang="French" en trglang="Français")
Bien respecter le balancement des balises SGML (ne pas fermer la balise
ouvrante initiale <TSTSET...>par une balise fermante <SRCSET>)
Bien respecter la DTD attendue en sortie de traduction (DTD pour un
TSTSET)
Table 3.12 – Recommandations faisant suite au test à blanc CESTA.
D’une manière générale, la campagne de test à blanc s’est bien déroulée, il n’y a pas
eu de problème majeur dans les échanges entre les organisateurs et les participants. Seuls
quelques soucis de mise en forme ont été repérés et ont permis d’améliorer le déroulement
de la campagne.
3.2.4
Phase de test
3.2.4.1
Description
La phase de test est la phase majeure d’une évaluation et la dernière étape avant l’analyse des résultats. Il s’agit pour l’évaluateur d’estimer le niveau de performance atteint
par les systèmes évalués.
Dans un premier temps, les données de test sont envoyées aux participants. Ceux-ci
les traitent automatiquement via leur système. Le délai accordé pour ce traitement est
court : les systèmes ont été améliorés par l’apprentissage, puis réglés et adaptés lors des
précédentes phases, il n’y a dès lors qu’à utiliser les données comme le ferait un utilisateur
normal. Toutefois, quelques jours sont laissés aux participants afin de régler les derniers
détails (les données ne sont pas exactement les mêmes) et de leur donner suffisamment de
temps (l’évaluation des systèmes n’est pas leur seule activité !). Les données de test sont
inconnues des participants lorsqu’elles leur sont envoyées.
Les données traitées sont ensuite envoyées à l’évaluateur. Cela peut se faire par e-mail,
dans le cas de données de faible taille, ou par dépôt sur un serveur FTP. L’envoi sur CDROM, DVD-ROM ou disque dur est de moins en moins utilisé, compte tenu des avancées
technologiques pour transférer et stocker des données (mais cela peut encore se faire pour
des données volumineuses comme en multimodal).
Les données sont collectées par l’évaluateur et une notification est envoyée aux participants afin de confirmer la bonne réception des données. Puis, le format de ces données
75
est validé. Cela se fait manuellement (et succinctement) ou automatiquement, cette seconde possibilité apportant une plus grande précision dans la validation. Une notification
des résultats de cette validation peut aussi être envoyée aux participants. Cette étape est
utile pour éviter toute erreur des outils d’évaluation, qui amène à de longues et fastidieuses recherches pour identifier la source du problème. L’outil de validation renvoie le
type de l’erreur et la localise parmi les données. Il peut aussi se retrouver intégré à l’outil
d’évaluation.
Après validation, les sorties des systèmes sont évaluées, si nécessaire après un reformatage pour les adapter au format utilisé par les outils d’évaluation. Deux cas se présentent :
l’utilisation de mesures automatiques ou l’utilisation de mesures humaines. Dans les deux
cas, il est préférable que les mesures se fassent le plus rapidement possible afin d’informer
les participants au plus tôt. En effet, le développement et l’amélioration des systèmes
dépendent souvent de l’émulation qu’il y a autour des résultats d’une évaluation ; obtenir
des résultats plusieurs mois après la phase de test n’est pas propice à cela : les participants
sont passés à d’autres travaux, sur d’autres projets. Cette émulation liée à la phase de
test s’essouffle facilement à cause des impératifs de chacun.
Dans le cas de jugements humains à grande échelle, il faut contacter un grand nombre
de personnes qui ne sont pas nécessairement expertes dans le ou les domaines concernés,
et faire connaître la tâche en cours partout où cela peut être pertinent. Par exemple,
pour la campagne de jugements humains sur l’espagnol du projet TC-STAR, nous avons
diffusé des annonces à la Cité Internationale Universitaire à Paris, contacté nos partenaires
Espagnols notamment en université, fait travailler le bouche-à-oreille lorsque des personnes
étaient recrutées. Dans ce genre de cas, le recrutement d’étudiants est le plus facile bien
que certains problèmes pratiques apparaissent : emploi d’étudiants étrangers en France,
accès Internet, disponibilité surtout en période d’examens, etc.
Lorsque les mesures ont été effectuées, un rapport d’évaluation est écrit et envoyé aux
participants (parfois, les résultats des mesures sont anonymisés).
3.2.4.2
La phase de test de la tâche T1 s’est déroulée de la manière suivante :
– Étape 1 - Extraction des candidats termes : le système d’extraction terminologique
retourne une liste ordonnée de termes, dont le respect de la DTD est vérifiée.
– Étape 2 - Appariement automatique : la première étape consiste à apparier automatiquement la sortie du système avec un thésaurus pré-existant.
– Étape 3 - Évaluation via des experts : la seconde étape consiste en une mesure
humaine, à partir du fichier renvoyé par l’appariement automatique et d’après les
critères définis au préalable. Pour CESART, seuls les 1 000 premiers termes étaient
jugés.
– Étape 4 - Calcul des scores : la dernière étape est le calcul des scores du système
à partir des jugements. La métrique adoptée lors de la campagne CESART est la
précision cumulée sur les n premiers candidats termes, qui estime les résultats du
système en fonction des scores de pertinence (cf. chapitre 5).
La phase de test de la tâche T3 s’est déroulée de la manière suivante :
– Étape 1 - Extraction des relations : le système d’extraction de relations retourne
une liste de triplets [terme source ; relation ; terme cible] respectant la DTD.
76
– Étape 2 - Préparation de l’évaluation : une première étape consiste à modifier le
format du fichier, afin de faciliter le travail des experts.
– Étape 3 - Évaluation via des experts : la seconde étape consiste à mettre en place
une mesure humaine, à partir du fichier envoyé lors de l’étape 2. Pour CESART,
seules les 1 000 premières relations étaient évaluées.
– Étape 4 - Calcul des scores : la dernière étape est le calcul des scores du système à
partir des jugements des experts en effectuant la moyenne des scores de pertinence
obtenus pour chaque relation.
Les résultats finaux de la campagne d’évaluation sont disponibles dans
[Timimi et Mustafa El Hadi, 2008].
3.2.4.3
Les deux campagnes de test CESTA se sont déroulées de la manière suivante :
– Étape 1 - Envoi des données : le corpus est envoyé par e-mail aux participants.
– Étape 2 - Traduction des données : le système de traduction automatique retourne
les données traduites respectant la DTD.
– Étape 3 - Mesure d’évaluation automatique : les traductions des systèmes sont évaluées d’après les mesures automatiques.
– Étape 4 - Mesure d’évaluation humaine : chaque segment traduit par le système de
traduction automatique est jugé selon les critères d’adéquation et de fluidité.
– Étape 5 - Calcul des scores de l’évaluation humaine.
Une dernière étape de calcul des corrélations entre les mesures d’évaluation automatiques et humaines a eu lieu afin de méta-évaluer les mesures automatiques (cf. chapitre 5).
Les résultats de l’évaluation sont disponibles dans [Hamon et al., 2008c].
3.2.5
Phase d’analyse des résultats
Une fois les résultats calculés, il est temps d’en faire l’analyse et d’interpréter les
informations obtenues. La durée de l’analyse est très variable et dépend de la complexité
de la tâche, de la quantité de données, des mesures disponibles ou du nombre de systèmes
à analyser. Le niveau de profondeur de l’analyse est à définir très tôt et peut aller d’une
étude en surface (déduire des comportements suite à l’observation des résultats et d’après
les paramètres de l’évaluation) à une étude en profondeur (effectuer un diagnostic fin des
systèmes allant jusqu’au niveau linguistique).
Il est possible d’utiliser des outils autres que ceux servant au calcul des résultats, mais
ils ne sont pas indispensables. La plupart du temps, l’étude se fait manuellement en se
focalisant sur les parties des données évaluées ayant reçu des résultats particuliers.
Finalement, l’analyse des résultats donne lieu à un rapport d’analyse qui fait état des
points faibles et des points forts des systèmes évaluées et des conseils d’amélioration sont
prodigués.
3.2.6
Phase de retour d’expériences et d’adjudication des résultats
Quel que soit le niveau d’analyse, un rapport d’évaluation est envoyé aux participants
et contient les données de l’évaluation : les références, les résultats détaillés, voire les
77
informations sur les participants anonymisées ou non. Suit alors la phase d’adjudication,
pendant laquelle les participants étudient ce rapport, comparent les analyses de l’évaluateur avec leurs propres analyses et renvoient leur point de vue à l’évaluateur. Parfois,
cette démarche s’effectue lors d’une réunion regroupant l’ensemble des partenaires (cf.
section 3.2.7), ou de manière moins formelle par des retours succincts.
La présentation des résultats révèle ici toute son importance : affichage de la validité
statistique des scores (par exemple avec un intervalle de confiance), description des résultats ou des mesures employées, manière d’afficher les scores, etc. Les résultats et les
analyses sont présentées de façon claire pour que les partenaires comprennent mieux ce
que l’évaluateur a fait durant l’évaluation, et de quelle manière. Cela aide les partenaires
à fournir plus facilement un retour à l’évaluateur.
Une adjudication a lieu sur les résultats et les données, selon que les résultats sont
déclarés corrects ou non. Quatre étapes successives forment cette adjudication :
1. Envoi du rapport d’évaluation, incluant les résultats et données ;
2. Étude du rapport par les participants et envoi de leurs commentaires à l’évaluateur ;
3. Correction des références ou des mesures d’évaluation selon les commentaires ;
4. Retour à l’étape de calcul des résultats (cf. section 3.2.4) s’il y a eu des corrections
des données.
L’adjudication terminée, les résultats sont déclarés corrects.
De plus, les participants fournissent habituellement un retour d’expérience, souvent
non formalisé mais allant de pair avec leurs commentaires. L’évaluateur recueille des
informations pertinentes quant au projet d’évaluation dans son ensemble : organisation,
analyse scientifique, moyens mis en œuvre, etc. Ainsi, les évaluations successives sont
régulièrement améliorées à l’aide de ces retours d’expériences. Par exemple, cela nous a
été particulièrement utile lors des deux campagnes CESTA en traduction automatique
suivies par les trois campagnes TC-STAR en traduction automatique de l’oral vers l’oral.
3.2.7
Phase de diffusion
Lorsque les résultats officiels sont finalisés 1 , ils sont diffusés à l’ensemble de la communauté scientifique afin de valoriser le projet et d’établir un état des lieux. Il faut toutefois
noter que la finalisation des résultats n’est pas un prérequis à toute publication. Comme
nous l’avons vu au cours des phases préliminaires, les possibilités de publication intermédiaire sont nombreuses : présentation du projet d’évaluation, description de la préparation
des données, diffusion de résultats intermédiaires, description de méthodologies, distribution de ressources, etc.
Différents aspects sont à en prendre en compte pour valoriser le projet d’évaluation :
– les listes de diffusion : elles entretiennent la réflexion autour d’une thématique et
servent à informer sur l’état d’avancement d’un projet ;
– les ateliers : ils sont souvent le moteur de la réflexion autour d’un thème précis car
ils réunissent les différents acteurs de ce thème. Chacun d’eux a l’occasion de donner
son avis, partager ses expériences, etc.
1. En pratique, la diffusion est souvent effectuée en parallèle de l’adjudication, compte tenu des délais
de publication.
78
– les conférences : les présentations lors de conférences ont l’avantage à la fois de faire
partager les détails d’un projet à une partie de la communauté (qu’elle soit ou non
initiée à la thématique du projet) et de découvrir d’autres méthodologies du même
thème ou proches ;
– les revues scientifiques : la diffusion à travers les revues scientifiques informe des
travaux effectués l’ensemble de la communauté scientifique de manière étendue,
tout en animant le débat autour d’une question précise ;
– la distribution de ressources : elle existe sous plusieurs formes telles que les « kits
d’évaluation » (contenant les données et outils d’évaluation, les rapports, etc.), les
technologies développées, les services déployés (sites Internet, serveurs d’évaluation),
les ressources produites, etc.
Un point important lors de la diffusion de résultats ou de ressources du projet d’évaluation concerne leur anonymisation. Il faut garder à l’esprit que les informations diffusées
sont accessibles par un nombre important d’individus ou d’institutions, et qu’elles sont
attentivement étudiées. C’est pourquoi il est nécessaire que les partenaires décident clairement, avant toute diffusion, si les données seront anonymisées, partiellement ou non, et
sous quelle forme. La crainte d’une identification des systèmes évalués est généralement
de voir certains utilisateurs déçus par les performances d’un système sur la seule base
d’une évaluation dans un contexte précis. Pourtant, cela ne saurait en aucun cas prouver
qu’il n’est pas capable d’accomplir une tâche correctement. L’anonymisation des résultats
est discutable et nous semble stérile. Mais elle est compréhensible car, sans vouloir être
réducteur, une simple évaluation ou un « benchmark » dans une revue de vulgarisation
scientifique peut provoquer de lourdes pertes sur les ventes d’une application industrielle.
Il est alors nécessaire de peser le pour et le contre d’une anonymisation des résultats. Toutefois, il faut garder à l’esprit que l’absence d’anonymat permet une meilleure lecture pour
comparer les approches des systèmes évalués. Notre sentiment est que l’aspect scientifique
de l’évaluation devrait primer : c’est à l’évaluateur de fournir le cadre de l’évaluation et
de faire comprendre au lecteur que les résultats sont obtenus dans un contexte précis.
Quant à l’anonymisation des ressources, elle est dans certains cas indispensable, pour
ne pas dire obligatoire. Prenons l’exemple d’un corpus d’e-mails contenant de la correspondance personnelle, tirés de la campagne EASY ([Vilnat et al., 2004a]) : il y a obligation
pour les producteurs de la ressource de supprimer les passages personnels, de modifier les
noms et les adresses électroniques, le tout relatif aux individus et afin de protéger leur
vie privée. C’est un travail fastidieux à construire, mais obligatoire. De même, en théorie,
pour les juges qui ont participé à des évaluations en proposant leurs jugements.
Enfin, la diffusion d’informations doit se faire avec rigueur. Il est nécessaire, par
exemple, de :
– indiquer la valeur et les intervalles de confiance des résultats : [%],[0-1],[1-5], etc. ;
– mettre un nombre significatif de décimales ;
– utiliser des mots corrects en limitant l’aspect subjectif : score plus haut plutôt que
score meilleur, score plus bas plutôt que score moins bon, etc. 1
Même si ces cas semblent triviaux, ils ont de manière évidente un impact sur la compréhension de l’évaluation et son interprétation.
1. Nous considérons ici que le jugement de la qualité se restreint à l’observation, et non à un quelconque
jugement de préférence.
79
3.2.8
Niveau supérieur : pérennisation et recherche de synergie
La pérennisation d’évaluations et la recherche de synergie entre évaluations forment
une étape complémentaire d’un projet d’évaluation. Elle est presque indispensable lors de
l’évaluation d’un système et vivement conseillée lors d’une campagne d’évaluation.
Un des objectifs du programme Technolangue, et en particulier du projet EVALDA,
est de pérenniser les produits et de créer des synergies entre les différentes campagnes
d’évaluation du projet. Au-delà des ressources linguistiques, il est possible d’étendre cette
synergie aux méthodologies, aux outils d’évaluation, voire aux applications technologiques.
L’intérêt est double : la réutilisation de ressources et d’outils réduit les coûts de développement. Cela les rend plus robustes car ils sont utilisés et vérifiés dans différents
cadres, par différentes personnes, etc.
Avec l’ELDA, nous avons observé des synergies entre plusieurs projets d’évaluation,
au-delà des ressources humaines (sept campagnes d’évaluation avaient cours en même
temps à la même période). De fait, nous avons observé la pérennisation des ressources
utilisées sur plusieurs domaines différents [Choukri, 2005]. Par exemple, le corpus médical
de la campagne EQueR (question-réponse) a été réutilisé dans la campagne CESART
(extraction terminologique), dont une partie a été à nouveau réutilisée dans le cadre de la
campagne CESTA (traduction automatique). L’interface d’évaluation humaine (cf. chapitre 7) que nous avons développée pour les campagnes CESTA a été adaptée et réutilisée
pour la campagne EVASy (synthèse vocale) ainsi que pour le projet européen TC-STAR
et trois des technologies évaluées, représentant un total de six campagnes différentes. Les
outils d’évaluation et la méthodologie de la campagne CESTA ont également été partiellement repris dans le projet TC-STAR.
3.3
Conclusion
À travers ce chapitre, nous avons décrit le déroulement d’une évaluation (cf. figure 3.8).
Nous avons identifié huit phases pour l’organisation et la préparation d’une évaluation :
– Planifier l’évaluation ;
– Définir la tâche de contrôle et ses objectifs ;
– Cibler les participants et les acteurs ;
– Établir des critères de qualité ;
– Définir des mesures de la qualité ;
– Constituer les ressources ;
– Spécifier et organiser les interactions entre acteurs ;
– Préparer l’évaluation ;
L’analyse de ces phases nous donne un aperçu des différentes possibilités méthodologiques d’une évaluation.
Nous avons également identifié huit phases d’évaluation :
– la phase d’apprentissage ;
– la phase de réglage ;
– la phase de test à blanc ;
– la phase de test ;
– la phase d’analyse des résultats ;
– la phase de retour d’expériences et d’adjudication des résultats ;
80
3.3. Conclusion
– la phase de diffusion ;
– la phase de pérennisation et de recherche de synergie.
En comparant ces phases avec l’étude de ELSE (cf. chapitre 2) à ce sujet, nous notons
plusieurs différences. Il y a tout d’abord moins de phases dans ELSE : quatre au lieu de
huit. Nous avons sciemment choisi d’ignorer l’étude d’impact qui à notre sens se fait à un
niveau plus haut et ne fait pas réellement partie d’une évaluation pour un ou plusieurs
systèmes.
Quatre phases supplémentaires apparaissent : l’analyse des résultats, l’adjudication des
résultats, la diffusion et la pérennisation et synergie (que l’on peut rapprocher de l’étude
d’impact de ELSE). À cela s’ajoute une modification du sens de la phase de test à blanc.
Ainsi, ELSE appelle phase d’entraînement ce que nous nommons phase d’apprentissage
(des données). La phase d’apprentissage de ELSE (notre phase de réglage) est fusionnée
avec la phase de test à blanc. Elles nous semblent pourtant indépendantes : l’une sert à
adapter les systèmes, l’autre à tester le protocole. Nous décomposons également la phase
de test que ELSE considère comme une seule et même tâche : nous considérons l’analyse
des résultats, l’adjudication des résultats et leur diffusion comme des tâches à part entière.
Enfin, la phase d’adaptation n’est pas considérée dans ELSE.
Nous nous distinguons d’ELSE par notre souhait de mettre à disposition de la communauté un modus operandi pratique pour voir clairement les étapes et bonnes démarches
d’une évaluation réussie.
Il est possible d’éviter des étapes lorsque l’évaluation est conduite en interne. Par
exemple, la phase de test à blanc est liée au développement du système puisque l’évaluateur/développeur connaît le système et les formats utilisés. Par contre, conduite en
externe, l’évaluation d’un système isolé conserve l’ensemble des étapes d’une campagne
d’évaluation.
L’étude du déroulement d’une évaluation met en lumière les attentes d’une architecture
d’évaluation, à savoir :
– le respect des différentes phases de préparation et d’évaluation ;
– la mise en option des phases qui ne sont pas obligatoires ;
– la mise en place des caractéristiques (optionnelles ou non) des phases ;
– les interconnexions entre les différentes actions de l’évaluateur.
81
Figure 3.8 – Phases préliminaires et phases d’évaluation. Les flèches pleines indiquent
les liens obligatoires, les flèches en pointillés les liens optionnels. De même, plus les boîtes
sont en pointillés, plus les phases sont optionnelles.
82
Chapitre 4
Les ressources linguistiques pour
l’évaluation
Il n’est pas envisageable de traiter du sujet de l’évaluation en traitement automatique
des langues sans aborder l’aspect des ressources linguistiques. Elles sont un des éléments
de base indispensable à toute évaluation, servant à la fois au développement des systèmes
et à leur évaluation. Même si l’emploi de ressources linguistiques n’est pas une finalité en
soi, leur choix et leur qualité sont cruciaux pour le bon déroulement d’une évaluation.
Nous l’avons vu dans les chapitres précédents, les ressources linguistiques occupent
une place importante dans l’organisation d’une évaluation : l’identification, la production,
le formatage ou la validation des données sont des étapes essentielles consommant une
grande partie du budget d’un projet d’évaluation. C’est pour cela que nous souhaitons
en comprendre les caractéristiques et les mécanismes d’utilisation avant de considérer
l’évaluation des systèmes.
De plus, le développement d’une architecture pour l’évaluation mérite d’en prendre
en compte tous les aspects. Les ressources linguistiques font partie intégrante d’une telle
architecture. Par ailleurs, la production ou la validation des données sont des composants
potentiels de l’architecture qui agissent comme des modules parallèles.
En premier lieu, nous précisons ce qu’est une ressource linguistique et quelle en est
notre définition. Nous précisons les limites de notre étude aux données textuelles essentiellement. L’objectif est l’intégration des contraintes associées aux ressources linguistiques
dans notre architecture d’évaluation. Nous effectuons un rapide état des lieux des systèmes possibles liés aux ressources linguistiques, puis nous explicitons les moyens de les
acquérir. Ensuite, nous abordons les aspects de standardisation des ressources et de validation de leur qualité. Ce sont des étapes indispensables dans notre contexte. Finalement,
nous revenons sur la place des ressources dans l’évaluation, leur pérennité et leur impact
sur les résultats.
4.1
Définition
Les ressources linguistiques représentent un ensemble de données relatives à la langue
et lisibles dans un format électronique. Dans notre contexte, elles sont utilisées principa83
Chapitre 4 : Les ressources linguistiques pour l’évaluation
lement pour le développement de systèmes et leur évaluation 1 .
4.1.1
Le développement de systèmes
Les systèmes de traitement automatique de la langue exploitent des ressources linguistiques afin d’accroître leurs performances en établissant des modèles de langage, des
règles, etc. Le champ d’utilisation des systèmes est étroitement lié à leur qualité. Les intérêts de leur utilisation sont multiples : extension du domaine des systèmes, amélioration
des performances, rapidité d’exécution, etc.
De nombreuses ressources sont ainsi utilisées pour le développement de systèmes :
corpus oraux, écrits, lexiques et dictionnaires, corpus bilingues et multilingues, corpus
parallèles, thésaurus, grammaires, etc. Dans un même temps, les systèmes développés
peuvent avoir un effet sur des ressources linguistiques lorsqu’ils en produisent, modifient
ou annotent.
La plupart des ressources sont utilisables par plusieurs technologies différentes. De
la même manière, la plupart des technologies se servent de plusieurs types de ressources linguistiques comme spécifié dans le Basic Language Resource Kit 2 (BLARK)
[Krauwer, 2003] comme nous le présentons dans le tableau 4.1 à travers quelques exemples
autour des ressources textuelles :
Technologie
Correction orthographique
Traduction automatique
Extraction terminologique
Extraction d’information
Résumé automatique
Indexation de documents
Recherche d’information
Reconnaissance de la parole
Synthèse
Monolingue
Lex. Term. Corp. Corp.
oral
écrit
X
X
X
X
X
X
X
X
X
X
X
X
Multilingue
Lex. Term. Corp. Corp.
oral
écrit
X
X
X
X
X
X
X
X
X
Table 4.1 – Aperçu des ressources utilisées en fonction des technologies (Lex. : Lexique ;
Term. : Terminologie ; Corp. : Corpus).
Par ailleurs, BLARK fournit un aperçu des ressources linguistiques utilisées ou nécessaires pour des modules de chaque technologie.
4.1.2
Évaluation de systèmes
Lorsqu’un système de traitement automatique des langues est évalué, des ressources
linguistiques sont nécessaires lors de la comparaison du système à une référence, ou de
1. Dans un contexte plus linguistique, par exemple, les ressources linguistiques peuvent être utilisées
pour une étude exclusive de la langue.
2. http ://www.elda.org/article26.html
84
4.2. Identification, production et négociation
l’observation par des juges. Tous les domaines du traitement automatique des langues
sont concernés : recherche d’information, traduction automatique, analyse terminologique,
analyse syntaxique, etc. C’est avant tout ici que se porte notre intérêt en particulier pour
les données touchant aux corpus textuels.
Lors d’une évaluation, les cas d’utilisation d’une ressource linguistique sont multiples
et comme nous l’avons présenté au chapitre 3 nous considérons :
– les données d’apprentissage ;
– les données de réglage ;
– les données de test ;
– les références pour les évaluations de test.
Chaque type de ressource est ainsi produit dans un but précis qui le différencie d’une
autre ressource.
4.2
Identification, production et négociation
Utiliser des ressources linguistiques signifie qu’il faut les acquérir. Nous distinguons
trois grandes étapes avant d’aboutir à une ressource utilisable : l’identification, la production et la validation des données. À cela, s’ajoute une étape de négociation des
droits d’utilisation ou de distribution. L’étude que nous fournissons dans cette section
repose avant tout sur l’expérience acquise au sein d’ELDA/ELRA, et de ses activités autour des ressources linguistiques. Elle est tirée en partie de [Arranz et al., 2007,
Arranz et Choukri, 2010].
4.2.1
Identification
L’acquisition de ressources linguistiques commence par une identification de l’existant
afin de réduire les efforts de production. L’objectif est de réutiliser des données déjà disponibles au sein de la communauté. En effet, dans le cadre d’une évaluation, des données
existantes sont potentiellement recyclables, pour une tâche différente ou dans une même
tâche, à condition qu’elles soient inconnues du système évalué. Par exemple, un corpus
parallèle bilingue d’apprentissage utilisé en traduction automatique est susceptible d’être
réutilisé pour l’évaluation de systèmes d’alignement ou pour l’évaluation d’un système de
traduction automatique, à condition que ce corpus n’ait pas déjà servi pour son apprentissage.
Les informations caractérisant les ressources identifiées sont de première importance
car elles déterminent leur cadre d’utilisation, en particulier lors d’une évaluation. Il faut
en premier lieu considérer le type de ressource, mais aussi des informations essentielles
telles que la taille, le domaine, le type d’annotations (le cas échéant), ou le format. Une
description succincte et un bref échantillon donnent déjà une idée d’une potentielle utilisation.
Par ailleurs, la relation entre évaluation et ressource linguistique peut aller dans les
deux sens : chercher à identifier la ressource adéquate pour une évaluation donnée, ou
bien adapter l’évaluation à une ressource disponible. En effet, l’évaluateur a tendance à
définir la tâche de contrôle en premier lieu, puis à chercher une ressource pour satisfaire
cette tâche. Par contre, lorsqu’un corpus est déjà disponible et proche du besoin de l’évaluateur, il faut considérer la possibilité de modifier légèrement la tâche. Bien souvent,
85
les ressources se trouvent adaptées au contexte de l’évaluation, avant tout au niveau du
format mais aussi par le biais d’annotations ou de modifications linguistiques (nettoyage,
enrichissement, etc.)
Par ses efforts d’identification de ressources linguistiques, ELRA a su enrichir son
propre catalogue de ressources 1 , mais aussi son « Catalogue Universel » 2 qui a pour but
de recenser l’ensemble des ressources linguistiques identifiées dans le monde. En effet,
il faut garder à l’esprit qu’une identification correcte ne se fait pas sans une recherche
constante des ressources susceptibles d’être pertinentes. Concrètement, un certain nombre
de méthodes d’identification sont pratiquées, entre autres à ELRA [Arranz et al., 2007] :
– assurer une veille des listes de diffusion (par exemple les listes LN, Linguist ou
Corpora) ;
– engager des experts dont la mission est d’identifier des ressources linguistiques ;
– coopérer avec des institutions qui produisent des ressources linguistiques ;
– participer à des projets de production de ressources linguistiques ;
– développer une expertise autour de programmes de recherche ou de « réseaux »
(comme par exemple le réseau d’excellence META-NET 3 ) ;
– participer à des évènements (conférences, ateliers, etc.) ;
– effectuer des recherches dans les publications et autres documentations ;
– pratiquer le bouche-à-oreille.
L’évaluateur ne se limite pas à ces activités et c’est aussi via des recherches Internet
que l’identification de ressources se fait. Se référer à des agences de distribution 4 (ou des
« agences d’identification » dans le cadre du Catalogue Universel) évite une charge de
travail conséquente.
4.2.2
Production
L’étape de production de données est aussi importante, sinon plus, que celle d’identification. Le renouvellement des ressources linguistiques et leur extension à d’autres domaines la rendent indispensable.
Concrètement, l’étape de production de données est longue et fastidieuse et prend une
grande part de l’effort lié à une évaluation, notamment lorsqu’il s’agit d’une campagne
d’évaluation où la réutilisation de données est moins fréquente. La durée de la production
dépend de la quantité de données à produire, du type de données, du type d’annotations
sur les ressources d’origine (les « données brutes »), ou encore de la provenance des
données. Nous faisons par exemple la distinction entre un corpus de plusieurs millions
de mots et un corpus de quelques milliers de mots, entre un corpus audio et un corpus
textuel, entre un corpus brut reformaté et un corpus annoté, entre un corpus issu de pages
Internet formatées correctement et un corpus issu de documents PDF. Ces exemples,
souvent extrêmes, montrent qu’il faut prendre en compte de nombreux paramètres pour
estimer la durée de production d’un corpus.
La plupart des actions de production sont communes aux différents types de ressources : gestion et coordination du projet de production, définition des formats de don1. http ://catalog.elra.info
2. http ://universal.elra.info
3. A Network of Excellence forging the Multilingual Europe Technology Alliance, http ://www.metanet.eu
4. ELRA, LDC, CCC, GSK, etc.
86
nées (incluant ceux des annotations) et leur spécifications, collecte des données brutes,
formatage des données, recrutement des annotateurs, annotations, validation, compilation, documentation.
La coordination d’un projet de production de ressources linguistiques est en relation
étroite avec l’ensemble des sections suivantes, allant des spécifications à la documentation
des données produites.
4.2.2.1
Spécification
Il est possible de classer les ressources linguistiques dans de nombreuses catégories
(par exemple dans le cas de l’utilisation de corpus textuels), leurs critères de définition
pouvant se réduire à :
– ses objectifs (entraînement, développement, évaluation, analyse, etc.) ;
– son contexte (domaine, langue, tâche, etc.) ;
– sa structure (monolingue, multilingue, parallèle, aligné, etc.) ;
– sa taille (en mots, phrases, documents, heures etc.) ;
– son format (brut, annoté, etc.) ;
– son origine (Web, transcriptions, journalistique, etc.).
La spécification d’une ressource linguistique passe par une étude préalable de son utilisation finale. Cela signifie que les données brutes sont acquises de manière à se rapprocher
le plus possible des données souhaitées, et de manière à coller au cadre de la tâche de
contrôle. Par exemple, un corpus utilisé pour l’évaluation de systèmes de question-réponse
sur des documents du domaine journalistique peut contenir des erreurs orthographiques :
la tâche de contrôle spécifie la correction du corpus avant de le fournir aux systèmes
ou, au contraire, laisse l’adaptation du système à ces conditions de manière plus réaliste.
Quelle que ce soit son utilisation finale, ce genre de spécification doit être convenu avant
le démarrage de la production d’une ressource linguistique.
En 1996, un des groupes de travail du projet EAGLES (TCWG - Text Corpora Working
Group) a eu pour but d’établir des recommandations sur la typologie des corpus textuels.
Certaines caractéristiques ont été établies avec des valeurs par défaut (le corpus devenant
spécialisé lorsque ces valeurs par défaut sont modifiées). Ces caractéristiques peuvent être
étendues à tout type de ressource linguistique :
– Sa taille : par défaut, elle est importante, en terme de mots. Elle doit par ailleurs
refléter la difficulté à établir ce corpus. D’une manière pragmatique, la taille d’un
corpus textuel utilisé pour un traitement automatique dépend de son utilisation,
mais aussi du domaine et des objectifs visés. Par exemple, un corpus d’un domaine
spécialisé de petite taille sera généralement plus pertinent qu’un corpus d’un domaine général volumineux pour de l’extraction terminologique.
– Sa qualité : par défaut, elle est authentique. Le langage employé est celui d’une
communication ordinaire, sans aucune circonstance artificielle. La frontière est complexe à identifier, toujours est-il qu’une quelconque intervention linguistique doit
être notifiée. De plus, un corpus imparfait ne doit pas être négligé, dès lors que ses
imperfections sont connues et prises en compte lors de l’interprétation des résultats.
– Sa simplicité : par défaut, il s’agit d’un texte brut. Concrètement, l’emploi du jeu de
caractères ASCII étendu ANSI est considéré comme valeur par défaut. Le critère de
simplicité a évolué depuis EAGLES, et s’est « complexifié » par la même occasion.
87
Il est dorénavant coutume d’employer des format balisés (SGML, XML, etc.) et le
jeu de caractères UTF-8, qui autorise l’emploi de caractères non latins.
– Sa documentation : par défaut, le corpus est documenté. Cela concerne les détails
sur les composants d’un corpus. Cette documentation est, de manière représentative,
fournie par la DTD des formats SGML ou XML qui procurent de manière séparée
du corpus les informations permettant de comprendre sa structure. Cela permet
aussi de séparer les données brutes de leurs annotations.
Dans le cadre de travaux d’évaluation de technologies, il est possible de distinguer de
façon simplifiée deux grandes catégories de ressources linguistiques. Certaines d’entre elles
sont utilisés pour l’apprentissage de systèmes et d’autres pour tester leurs fonctionnalités
post-développement dans un cadre d’évaluation clairement défini. La fonction principale
d’une ressource d’apprentissage est de présenter le maximum de possibilités linguistiques
(liées au contexte de l’évaluation) afin que le système s’adapte à un maximum de cas de
figure. La plupart des ressources linguistiques sont utilisées dans un but d’apprentissage
à partir de modèles probabilistes ou statistiques afin de développer des systèmes. À partir de calculs plus ou moins complexes, des probabilités sont déduites pour reproduire
des modèles de langues. En théorie, plus la taille des ressources utilisées est importante
meilleures sont les performances obtenues. A contrario, leur taille minimale est difficile à
déterminer puisqu’elle dépend le plus souvent de la tâche de contrôle et de sa complexité.
4.2.2.2
Collecte
La collecte des ressources linguistiques s’effectue de diverses manières et les moyens de
mise en œuvre sont multiples. Par exemple, l’enregistrement audio requiert des moyens
plus importants que la collecte de documents textuels. Le matériel d’enregistrement audio
peut-être composé d’une carte d’acquisition et du logiciel correspondant ou d’un microphone, matériel relativement coûteux. À l’inverse, la collecte de documents textuels est
souvent menée à partir de simples scripts collectant, puis formatant les données.
Certaines données sont collectées directement via Internet, en « aspirant » des pages
Web. Des opérations de sélection d’informations pertinentes sont conduites, plus ou moins
aisément du seul fait de l’aspect chaotique des structures HTML : chaque site possède sa
propre organisation, qui peut être différente pour chaque page du site. L’objectif est de
trouver un point commun à toutes les pages HTML, afin de rentabiliser le développement
d’un script spécifique (le « nettoyage » manuel est rarement envisageable). La plupart
du temps, lorsque le volume de données est suffisamment important pour envisager des
pertes, il est possible de restreindre la sélection des données.
D’autres données sont directement accessibles auprès d’un fournisseur ayant son propre
format. C’est par exemple le cas du corpus Le Monde 1 , les articles du journal étant
distribués (à travers ELRA) sous un format propriétaire.
Enfin, une troisième possibilité est la collecte de ressources linguistiques directement
auprès d’utilisateurs. Les moyens mis en œuvre sont alors plus conséquents, car ils nécessitent la mise en place d’un recrutement, parfois rémunéré, le développement d’outils de
collecte, et la gestion de toute une phase de collecte généralement sur plusieurs semaines.
C’est par exemple le cas dans [Fairon et al., 2006] où une collecte massive de SMS a eu
lieu en Belgique, permettant ainsi de recueillir quelques 30 000 SMS.
1. http ://catalog.elra.info/product_info.php ?products_id=438
88
Dans le projet TC-STAR [Van den Heuvel et al., 2006], des données audio et textuelles
ont été recueillies en utilisant ces trois méthodes de collecte. Les données audio pour
l’entrée des systèmes de reconnaissance vocale, à savoir les discours des députés européens,
étaient disponibles directement via le site Internet du Parlement Européen, sous forme de
fichier WAV. Les données audio provenant des interprètes (correspondant à la sortie des
systèmes de synthèse) étaient recueillies sur place par l’équipe de l’Université de Aachen
à l’aide de microphones. Enfin, nous avons collecté les données textuelles brutes, pour les
systèmes de traduction automatique, à partir du site Internet du Parlement Européen 1 .
Les discours recueillis devaient correspondre aux discours oraux déjà en notre possession.
Pour ce faire, nous avons téléchargé les pages HTML du Parlement Européen. Chaque
page contient, en plus des horaires et description des sujets débattus, une session plénière
avec pour chaque orateur différentes informations dont son discours transcrit et reformulé,
dans la langue originale de l’orateur. Puisque nous n’avions besoin que d’environ 25 000
mots en espagnol et en anglais, nous avons choisi de collecter manuellement les discours
dans les deux langues. Cela a pris tout au plus une heure de travail. Puis, nous avons
appliqué des scripts sur ces données brutes afin d’obtenir un corpus pré-formaté.
4.2.2.3
Formatage
Les données brutes collectées, il est ensuite nécessaire de les mettre au format spécifié
par l’évaluateur. Il s’agit par exemple, pour des données textuelles, d’appliquer un balisage
XML ou SGML conforme aux spécifications. Afin d’éviter toute erreur de manipulation,
cette étape se fait en général automatiquement. Toutefois un « nettoyage » des données
peut nécessiter une intervention manuelle lorsque les modifications sont trop complexes
pour qu’un outil puisse les faire automatiquement.
Dans le projet TC-STAR, les données pour l’évaluation des systèmes de traduction
automatique ont été formatées d’après les spécifications du NIST [NIST, 2003], un format
SGML qui décompose le texte en documents, eux-mêmes décomposés en phrases. Le
passage du format brut au format NIST n’est pas compliqué, mais il a tout de même fallu
une vérification manuelle, entre autres pour la séparation des phrases, des données brutes
contenant des approximations (comme des sauts de ligne mal placés). De plus, les fichiers
devant être encodés en UTF-8, une conversion et une validation de l’encodage ont été
effectuées.
L’exemple de TC-STAR semble simple mais ce n’est pas toujours le cas, notamment
lorsque la quantité de données est plus grande. Nous en avons fait l’expérience dans le
cadre du projet CESART, pour lequel un corpus de plusieurs millions de mots devait être
produit. Tiré d’un site Internet, le corpus contenait de nombreux problèmes d’encodage
de caractères, un formatage aléatoire des données brutes (extraites de pages HTML), la
présence de textes non pertinents (les menus des pages) ou mal formaté (les tableaux),
ou la mauvaise orthographe de certains mots (ce qui était gênant étant donné la tâche de
contrôle). Une phase de nettoyage automatique, puis manuel des données a été nécessaire.
Celle-ci a duré plusieurs semaines, montrant par ailleurs le coût énorme que représente le
nettoyage d’un tel corpus.
1. http ://www.europarl.europa.eu
89
4.2.2.4
Annotation
Passées les phases de collecte et de formatage des données, il arrive que ces dernières
soient « annotées », à savoir que des méta-données soient manuellement ajoutées aux
données. L’ajout se fait à partir de spécifications définies à l’avance afin de faciliter le
travail des annotateurs. Nous considérons que l’annotation est l’action de modifier les
données formatées. L’annotation se rapporte autant à l’ajout d’un étiquetage, par exemple
morphosyntaxique, sur les données originales qu’à la traduction du texte dans une autre
langue. Dans une moindre mesure, il est aussi possible de considérer les jugements humains
sur des sorties des systèmes comme une annotation.
Ces annotateurs sont recrutés afin d’annoter les données formatées, ils sont experts
ou non selon la tâche. Le recrutement n’est pas toujours chose facile, et le suivi ne l’est
pas moins. Il faut tout d’abord réussir à contacter des experts compétents pour la tâche,
qui sont rares ou qui ne sont pas disponibles. Cette phase peut se révéler assez longue et
nécessite parfois de nombreux contacts et entretiens.
4.2.2.5
Compilation et documentation
Une fois les données annotées et/ou mise au format final d’utilisation, il ne reste plus
qu’à rassembler les données et à les compiler, puis à décrire ces données et leur format dans
une documentation. Cela semble assez fastidieux, mais cette étape est indispensable non
seulement parce que les données sont susceptibles d’être réutilisées par la suite mais aussi
parce que le collecteur/producteur de données n’est pas forcément l’évaluateur. Parfois,
les deux phases de production et d’évaluation sont trop décorrélées dans le temps, ce
qui augmente le risque d’erreur dû à l’oubli de certains aspects des données comme leur
formatage, leur structure, etc.
4.2.3
Négociation
La disponibilité ou la productibilité des ressources linguistiques ne signifie en aucun
cas qu’elles sont utilisables, ou réutilisables, à souhait. Pour ce faire, des démarches sont
forcément à entreprendre. Leur durée et leur complexité est très variable. Elles dépendent
à la fois des données (coût, facilité d’accès, etc.), du fournisseur, du client et/ou du
négociateur des ressources lorsqu’il est différent.
L’évaluateur doit penser aux aspects contractuels d’une ressource linguistique. Cela
influe sur la planification du projet, par rapport au temps d’obtention des données et à
leur utilisation. Une ressource est censée n’être utilisable que si les droits de distribution
sont signés 1 .
Plusieurs aspects contractuels entrent en jeu : l’utilisation de données, leur distribution à des tiers et leur modification. Qu’elles soient au format brut ou dans un format
propriétaire, les données « appartiennent » à une ou plusieurs institution et elle(s) seule(s)
décide(nt) de l’accord d’utilisation et de distribution, même si ces données sont des pages
Internet. La plupart du temps, un processus assez long est nécessaire pour finaliser cet
accord. Face au coût parfois important de leur production, les propriétaires de données
ne veulent bien souvent les fournir qu’à prix d’or. Même une utilisation dans un cadre
dit « libre » a ses limites et ses contraintes. Par exemple, le site Internet du Parlement
1. Auxquels il faudrait ajouter la négociation des droits de distribution d’un package futur.
90
4.3. Validation
Européen qui laisse à disposition « librement » le contenu de ses pages précise que leur
utilisation est limitée, entre autres stipulations, à des fins non commerciales et moyennant
mention de la source 1 .
Que l’on considère un producteur de données (modification), un évaluateur (distribution) ou un participant à une évaluation (utilisation), il est soumis à des contraintes de
type juridique. Dans le meilleur des cas, les aspects contractuels sont déjà clairement définis et, après un premier contact, un contrat est signé et les données envoyées. Parfois, des
contraintes plus importantes nécessitent de réelles négociations (telles que des contraintes
financières, de propriété, etc.).
4.3
Validation
La qualité d’une ressource linguistique est un élément essentiel à retenir. Il est utilisé
par la suite et les résultats obtenus par les systèmes dépendent de son état. La question
de la qualité se pose aussi lorsque des informations sont perdues ou altérées, et lorsque
l’on vérifie la qualité de l’encodage et le format des données.
La validation des ressources linguistiques s’établit autour de trois axes majeurs : la
validation de la documentation, la validation formelle et la validation du contenu linguistique 2 . Mis à part quelques exceptions comme la validation du format, les validations se
font manuellement afin d’éviter tout risque d’erreur.
La validation de la documentation vérifie la conformité des documents fournis pour une
ressource donnée. Le contenu des spécifications de production est vérifié dans un second
temps. Les principales recommandations imposent qu’une documentation soit :
– claire et suffisante pour permettre l’utilisation de la ressource ;
– en anglais au minimum ;
– au minimum la description du copyright, de la personne à contacter, du formats
des fichiers et de l’encodage (comprenant les conventions pour nommer ces fichiers),
taille de la ressource, langues utilisées, domaine, technologie visée, ainsi que les
informations caractéristiques du domaine (la documentation d’un corpus pour la
traduction automatique n’est pas nécessairement la même que pour la recherche
d’information).
La validation formelle vérifie la facilité d’utilisation de la ressource par rapport à son
format et sa structure. Elle examine :
– l’accès à l’ensemble des données (les fichiers peuvent-ils s’ouvrir ?) ;
– l’absence de virus informatiques ;
– le format et l’encodage des fichiers par leur conformité avec la documentation et les
spécifications ;
– la taille du corpus, qui doit correspondre à la documentation ;
– la justesse des structures ;
– l’intégrité des données ;
– la validité d’un point de vue légal.
La validation du contenu mesure la fiabilité des données linguistiques brutes. Cette
validation se fait la plupart du temps sur un échantillon le plus représentatif possible de
1. http ://www.europarl.europa.eu/tools/disclaimer/default_fr.htm#copyright
2. La sous-section « Standards » des pages du site Internet d’ELRA (http ://www.elra.info dédiées à la
validation présentent notamment les standards à suivre pour les ressources écrites [Burnard et al., 1998].
91
la ressource. Elle dépend du type de ressource. Les vérifications portent sur :
– le balisage et la structure des données ;
– l’information morphologique ;
– l’information syntaxique ;
– l’information sémantique.
Des critères spécifiques sont définis dans un guide de validation. Chaque critère est
habituellement lié à un score qui synthétise les informations collectées manuellement par
un expert, le validateur.
Lorsque toutes les validations sont terminées, un rapport de validation est rédigé et
inclus à la compilation de la ressource.
4.4
Coût des ressources
Comme nous l’avons vu précédemment, de nombreux paramètres sont à prendre en
compte lors de la production ou de l’identification de ressources linguistiques. Chacun
des paramètres a un impact sur le coût d’une ressource. Il s’agit, dans certains cas, des
données brutes en elles-mêmes, qui peuvent être acquises auprès de la source. Mais cela
peut aussi être le coût de collecte, comme par exemple lors de collecte de données auprès
d’utilisateurs et la mise en place des instruments de collecte.
Ensuite, il faut prendre en considération le coût de modification des données : il s’agit
avant tout des annotations, mais aussi de l’effort lié au formatage des données qui peut
s’avérer relativement long. La gestion de l’ensemble a également un coût, car toutes ces
étapes ne peuvent s’effectuer sans un minimum d’organisation et de coordination, de
même que la compilation des données et leur documentation, qui sont généralement très
coûteuses. Enfin, l’impact de la validation n’est pas non plus négligeable : même si elle
ne fait office que de « vérification », elle nécessite une organisation propre et des moyens
particuliers qui accroissent le coût général de la production des données.
4.5
Standardisation
À travers la standardisation des ressources linguistiques, c’est leur utilisation par des
systèmes ou leur réutilisation dans d’autres évaluations qui sont prises en compte. Cette
standardisation est d’autant plus importante pour une campagne d’évaluation car les
systèmes utilisent de plus en plus de données dans un même format. Cet effort n’est pas
nouveau : l’action GRACE [Adda et al., 1999], par exemple, a su définir un référentiel
commun aux analyseurs morpho-syntaxiques.
D’autre part, la standardisation des ressources est utile à une architecture d’évaluation
générique. La généralisation à un format unique pour une ressource donnée permet à
l’ensemble des systèmes de s’y rattacher et de s’intégrer à l’architecture. À l’inverse, une
multitude de formats implique d’avoir autant d’outils de transformation et de prendre en
compte le plus de formats possibles. Un exemple sur les corpus textuels est disponible en
annexe D.
92
4.6. Impact des ressources sur l’évaluation
4.6
Impact des ressources sur l’évaluation
Les ressources linguistiques sont un des points centraux du traitement automatique
des langues et son évaluation en dépend. Cela affecte autant le niveau méthodologique de
ses évaluations que l’analyse et l’interprétation des résultats.
4.6.1
Impact méthodologique
Les ressources ont un impact sur la méthodologie d’un projet d’évaluation. Selon celles
qui sont disponibles et leurs caractéristiques, l’évaluation n’est pas agencée de la même
manière. Par exemple pour la campagne CESART, c’est la disponibilité d’un corpus de la
santé qui a fait que la campagne s’est déroulée en partie sur ce domaine. Mais auparavant,
il a fallu confirmer que les systèmes d’extraction terminologique étaient à même de traiter
ce type de données ou qu’ils s’y adapteraient.
4.6.2
Impact de la qualité
La qualité des ressources utilisées lors d’une évaluation est variable et dépend de
plusieurs facteurs : la manière de les produire, qui les a produites, leur validation, etc.
Par exemple, dans PASSAGE, les annotations manuelles en constituants et en relations
pour créer le corpus de référence sont validées par consentement mutuel des annotateurs.
Des accords inter-annotateurs ont été calculés afin de déterminer la cohérence entre les
annotateurs. C’est l’accord entre les annotateurs et le seuil que nous nous sommes fixé
qui détermine si les annotations sont valides ou non. Cette qualité des ressources va
avoir tendance à affecter les résultats d’une évaluation. Les systèmes étant comparés aux
références, plus la qualité sera haute, plus les résultats seront corrects.
Pourtant, nous présentons dans la section suivante un contre-exemple de validation
qui n’impacte pas les résultats de l’évaluation. Cet exemple, pris dans le cadre du projet
TC-STAR, a tout de même le mérite de présenter une méthodologie de validation de
ressources dans un contexte d’évaluation.
4.6.3
(Contre)-exemple en traduction automatique
En traduction automatique, les scores des métriques automatiques utilisées pour mesurer les performances dépendent fortement des traductions de référence. Nous souhaitons
déterminer à quel point les scores calculés avec une référence de mauvaise qualité divergent
de ceux calculés avec une référence de meilleure qualité. Après avoir défini notre méthode
de validation d’une traduction humaine (utilisée comme référence), nous étudions l’impact
de la qualité des références sur les évaluations automatiques du projet.
4.6.3.1
Contexte
Nous étudions dans cette section les nombreuses validations des traductions de référence qui ont été produites pour les deuxième et troisième campagnes d’évaluation du
projet TC-STAR. La technologie évaluée est la traduction automatique de la parole. Pour
chacune des deux campagnes, trois directions de traduction étaient utilisées : de l’anglais vers l’espagnol, de l’espagnol vers l’anglais et du chinois vers l’anglais. Les systèmes
93
pouvaient traiter trois sortes de données : les transcriptions automatiques provenant des
systèmes de reconnaissance de la parole (dénommées ASR, pour Automatic Speech Recognition), les transcriptions manuelles correspondantes (dénommées Verbatim) et les textes
correspondants fournis par le Parlement Européen (dénommés FTE pour Final Text Editions). Chaque type de données a ses propres caractéristiques et difficultés : l’ASR contient
les phrases erronées des systèmes automatiques, le Verbatim contient de la parole spontanée (c’est-à-dire des répétitions de mots, des hésitations, des corrections, etc.) et le FTE
contient des phrases reformulées. Seule la direction du chinois vers l’anglais n’a pas de
données Verbatim et les données ont été collectées à partir de données Voice of America 1 .
Types de données
ASR
Verbatim
FTE
Directions de traduction
anglais-espagnol espagnol-anglais chinois-anglais
X
X
X
X
X
X
X
X
Table 4.2 – Directions de traduction et types de données du projet TC-STAR.
4.6.3.2
Données
Au total, nous utilisons 14 ensembles de données, chaque ensemble étant composé du
document source à traduire, des traductions de référence traduites deux fois par deux
agences de traduction différentes et des traductions des systèmes automatiques. Chaque
ensemble représente environ 25 000 mots. Nous avons donc 28 traductions de référence si
l’on considère les évaluations et les directions de traduction pour les deux années d’évaluation. Les systèmes de traduction automatique sont évalués par la métrique BLEU
[Papineni et al., 2001] dans cette étude (cf. chapitre 5).
4.6.3.3
Validation
Des guides de validation ont été produits dans le cadre du projet TC-STAR. Ils ont été
discutés en interne, mais aussi avec le LDC (Linguistic Data consortium) qui a de l’expérience dans ce domaine. Les agences de traduction sont informées du contrôle de qualité de
leurs traductions. Des recommandations leur sont fournies, comme par exemple : le sens
et le style de la traduction doivent coller au mieux à ceux du document source ; aucune
annotation n’est ajoutée ; la casse est respectée avec attention, selon les conventions de
la langue cible ; les traductions de néologismes ou de mots inconnus prennent en compte
l’intention de l’orateur ; le format des dates suit les conventions établies de la langue cible.
Les fichiers traduits sont envoyés à une agence de validation 2 afin de vérifier leur qualité. Chaque traduction est validée en sélectionnant au hasard 1 200 mots (environ 5 %
du total) provenant de segments contigus. Les validateurs sont des traducteurs professionnels qui classent les erreurs selon des catégories déterminées à l’avance. Des points de
pénalités sont ensuite donnés aux traduction de référence selon des critères définis dans
le tableau 4.3.
1. http ://www1.voanews.com
2. L’agence SPEX (Speech Processing EXpertise) dans le contexte de TC-STAR.
94
Erreur
Points de pénalité
Année 2 Année 3
Syntaxique
4
3
Divergence avec le guide
3
Lexicale
2
3
Mauvais usage
1
1
Casse
1
Ponctuation / orthographe (max. 10)
0.5
0.5
Table 4.3 – Pénalités pour les erreurs de traduction.
Pour être considérée valide, une traduction de référence doit avoir moins de 40 points
de pénalité. Les traductions invalidées sont renvoyées à l’agence de traduction afin d’être
révisées et améliorées. Un rapport contenant les erreurs trouvées est également fourni à
l’agence.
Le passage de la seconde année à la troisième a vu l’amélioration du protocole de
validation en modifiant les critères et les points de pénalité (cf. tableau 4.3).
Nous donnons ci-dessous quelques exemples de traduction validées pour la direction
de l’espagnol vers l’anglais. La phrase source est présentée, puis sa traduction par un
professionnel et ensuite sa correction. Finalement, le type d’erreur est donné pour chacune
des erreurs (en gras).
Source (FTE) : Declaro reanudado el período de sesiones del Parlamento Europeo,
interrumpido el jueves 7 de julio de 2005.
Traduction : I declare resumed the period of sessions of the European Parliament,
broken off on Thursday, the 7th July 2005.
Erreur : lexicale
Correction : I declare resumed the period of sessions of the European Parliament,
interrupted on Thursday, the 7th July 2005.
Source (FTE) : Señor Presidente, como ha recordado el Comisario de Medio Ambiente, este verano hemos sido víctimas en la Unión Europea de catástrofes producidas por el fuego y por el agua, y mientras unas regiones están seriamente amenazadas
por la progresiva desertización, otras, sin embargo, temen las inundaciones.
Traduction : Mister President, as the Environment Commissioner reminded us of,
this summer we in the European Union were victims of disasters caused by fire and
by water, and while some regions see themselves seriously threatened by a progressive
growth of aridity, others, in change, fear the floods.
Erreur : mauvais usage de la langue, lexicale, lexicale
Correction : Mister President, as the Environment Commissioner reminded us,
this summer we in the European Union were victims of disasters caused by fire and
by water, and while some regions see themselves seriously threatened by a progressive
desertification, others, by contrast, fear the floods.
95
Source (Verbatim) : yo , evidentemente , estimo , por ejemplo , voy a ir con algunos
puntos ; ha hablado brevemente , pero ha hablado , de de , del FAD ¿ no ? , y de ,
de ese porcentaje en la ayuda al desarrollo , que es el , en estos momentos el
más bajo de los que representan los FAD dentro de ellas ¿ no ?
Traduction : , I , obviously , I think , for example , I shall come back to only a
few points ; you mentioned it in passing , but you mentioned it , the FAD , didn’t
you , and that development aid percentage , the lowest at these moments of those
represented in the FAD , isn’t it .
Erreur : Syntaxique, lexicale, ponctuation
Correction : I , obviously , I think , for example , I shall come back to only a few
points ; you mentioned it in passing , but you mentioned , the FAD , didn’t you ,
and that development aid percentage , which is the , the lowest at this time of
those represented in the FAD , isn’t it ?
4.6.3.4
Erreurs type
La plupart des erreurs identifiées sont avant tout d’ordre lexical, suivi par un mauvais
usage de la langue. Les erreurs de syntaxe et d’orthographe sont moindres. Le nombre
d’erreurs varie aussi en fonction du type de données : le nombre d’erreurs lexicales, d’orthographe et de syntaxe est plus important pour le FTE que pour le Verbatim. Par contre,
le nombre d’erreurs d’usage et les divergences avec le guide sont plus importantes pour le
Verbatim.
De même, il y a plus d’erreurs pour les traductions de l’anglais vers l’espagnol que
de l’espagnol vers l’anglais. Pour le chinois vers l’anglais, les traducteurs ont produit
beaucoup d’erreurs, en particulier des erreurs lexicales.
Nous présentons quelques exemples d’erreurs représentatives trouvées dans les traductions validées, pour la direction de l’espagnol vers l’anglais (la partie gauche de chaque
exemple présente le segment mal traduit, la partie droite sa correction).
Exemples d’erreurs syntaxiques :
– mauvais placement de l’adjectif (fruits and fresh vegetables / fresh fruits and vegetables) ;
– mauvais forme de pronom (from her explanation / from your explanation) ;
– erreur de conjugaison (did what it could / does what it can ; was used / has been
used ) ;
– utilisation d’un nom au lieu d’un adjectif (plenaries / plenary sessions).
Les déviations du guide de validation offrent moins de cas :
– omission de mots ou d’un morceau de phrase ;
– mauvaise traduction d’un nom propre (Serge / Sergio) ;
– qualité de la traduction / expression curieuse (few, no ? / few, aren’t there ? ; a little
moment / a brief moment ; since a few weeks / in the last few weeks).
Aussi, cette catégorie d’erreurs a été répartie dans d’autres catégories pour la troisième
année d’évaluation.
Les erreurs lexicales sont d’une plus grande variété, cela étant probablement dû au
vocabulaire spécifique utilisé :
– erreur de traduction d’acronymes (SICA / AECI ; WTO / OCM ) ;
– mauvais ordre de mots (period 2007-2013 / 2007-2013 period ) ;
96
– erreur de nombre (woman / women) ;
– traduction littérale (simply would / would just) ;
– mauvaise terminologie ou approximation (Euro-Asian / Eurasian ; growth of aridity
/ desertification ; Table / Board ) ;
– mauvaise préposition (in what / as ; of the world / in the world ; consists in /
consists of ) ;
– traduction contradictoire (of the United States or the Japanese / of the United States
or Japan).
Autres type d’erreurs :
– mauvaise ponctuation ;
– erreurs de frappe (thee / the ; nemgotiations / negotiations).
Toutes ces erreurs diminuent la qualité des traductions de référence et biaisent en
théorie l’évaluation. Le but de la validation est alors de réduire, autant que faire se peut,
leur impact afin d’améliorer l’évaluation des traductions automatiques.
4.6.3.5
Résultats
Plusieurs résultats sont disponibles dans cette expérimentation. Tout d’abord, nous
présentons les scores de validation pour toutes les traductions de référence. Puis, nous
ne conservons que les traductions qui ont été validées une seconde fois, après correction.
Ainsi, nous identifions les différences entre versions. Finalement, nous considérons les
corrélations entre les versions de références après le calcul des résultats des systèmes de
traduction automatique.
Dans les résultats ci-dessous nous adoptons la convention de notation des différents ensembles de données : « Année/Donnée_direction. Par exemple, « 3/EPPS-FTE_ESEN »
correspond à la troisième année d’évaluation pour la direction de l’espagnol vers l’anglais,
en utilisant les données FTE.
Sur la totalité des 14 ensembles de données, 10 ont été corrigés et validés à nouveau
au moins une fois (pour l’une ou les deux traductions de référence de l’ensemble). Le
tableau 4.4 fournit les scores de validation pour chacune des traductions. Le WER (Word
Error Rate, taux d’erreur sur les mots) est également fourni, entre une version intermédiaire et la version finale de chaque traduction de référence. Le score de gauche indique le
résultat pour la première traduction de référence d’un ensemble, le score de droite celui
pour la seconde traduction de référence du même ensemble. Les différentes lignes pour
un même ensemble sont les résultats de validation à différents niveaux (d’une traduction
intermédiaire non validée à la traduction finale validée). Comme cela, nous observons
l’évolution des validations. Une traduction avec un score de validation inférieur à 40 est
acceptée et n’est pas à nouveau corrigée.
Le score de validation moyen avant toute correction est aux alentours de 62, tandis
qu’après correction il est d’environ 23 : les traductions finales ne sont elles-mêmes pas
parfaites mais leur qualité est déclarée suffisante pour qu’elles soient utilisées comme
traductions de référence.
Un maximum de 130 est obtenu pour une traduction du chinois vers l’anglais dont la
traduction semble tout de même être plus difficile que pour les autres directions.
Nous observons également que le WER n’est pas forcément très haut et que beaucoup
de valeurs sont en dessous de 1%, ce qui signifie une forte proximité entre les versions.
97
Ensemble
3/EPPS-FTE_EsEn
3/Cortes-FTE_EsEn
3/Cortes-Verb_EsEn
3/VoA-Verb_ZhEn
2/EPPS-FTE_EnEs
2/EPPS-FTE_EsEn
2/EPPS-Verb_EnEs
2/Cortes-FTE_EsEn
2/Cortes-Verb_EsEn
2/VoA-Verb_ZhEn
Moyenne
Score de validation
Réf. 1
Réf. 2
59,5
104,5
18
73,5
18
38
43,5
120,5
34
70,5
34
35
54
67
26,5
22.5
130
129
53,5
37
27
37
23
31
23
23,5
18,5
33
18,5
17
59,5
17
11,5
17
42
61,5
6
9
69
54
18,5
0
84
38
39,5
38
62
23
WER / traduction finale
Réf. 1
Réf. 2
12,5
8,2
1,3
6,2
-
5,1
1,2
0,5
0,3
24,2
6,3
15,3
-
-
0,9
-
2,6
0,7
-
0,2
5,3
20,7
4,7
17,0
6,2
Table 4.4 – Scores de validation des traductions de référence et WER entre les traductions intermédiaires (lignes les plus hautes) et la traduction finale (lignes du bas) pour la
première traduction de référence (Réf. 1) et la seconde (Réf. 2) de chaque ensemble.
98
Nous comparons la différence de score de validation avec leur WER et le coefficient
de corrélation de Pearson est de 58%, ce qui est faible. Par exemple, une différence de
score de validation de 36 entre une traduction non validée et sa correction correspond à
un WER de 0,2, tandis qu’une autre différence de 26,5 correspond à un WER de 6,3. Il y
a a priori plus de corrélation entre la qualité des traductions de référence et le WER.
Nous pensons que, par extension, la mesure d’évaluation automatique est remise en
question : en effet, si le WER ne reflète pas une amélioration de la qualité, comment
pourrait-il être fiable pour l’évaluation des systèmes de traduction automatique ?
Nous comparons en figure 4.1 les corrélations entre les différences de score de validation
et les WER pour tous les ensembles.
Figure 4.1 – Comparaison des différences de score de validation et les WER entre les
traductions non validées et leurs corrections.
D’après nous, cela confirme que la qualité n’est pas bien corrélée avec le WER car il
n’y a aucune tendance générale. L’explication est double : l’amélioration d’une traduction
humaine n’implique pas nécessairement de nombreuses modifications ; le WER ne reflète
pas la qualité d’une traduction avec précision et est limité sur des problèmes cruciaux et
la finesse de la langue.
La métrique BLEU [Papineni et al., 2001] a été utilisée pour calculer les scores des
systèmes de traduction automatique. Pour chaque ensemble, les références de tous les
niveaux de validation ont été utilisés, qu’elles soient valides ou non. Nous présentons les
résultats des systèmes selon qu’il s’agit de traductions de référence intermédiaires ou de
traductions de référence finales. Nous obtenons deux sortes de résultats : soit les scores
sont presque identiques, comme il est possible de le voir en figure 4.2 pour l’ensemble
Cortes-Verbatim de la direction de l’espagnol vers l’anglais de la troisième année ; soit les
scores sont légèrement divergents comme il possible de le voir en figure 4.3 pour l’ensemble
Cortes-FTE de la direction de l’espagnol vers l’anglais de la seconde année.
Pour aller plus loin, nous calculons les corrélations sur les scores BLEU des systèmes
entre les traductions de référence intermédiaires et les traductions de référence finales.
Nous obtenons ainsi deux coefficients de corrélation lorsque deux traductions de référence
consécutives n’ont pas été validées. Le tableau 4.5 montre les coefficients de corrélation
pour toutes les traductions de référence intermédiaires, selon les scores BLEU et selon le
classement des systèmes.
Les corrélations sur les scores montrent des coefficients supérieurs à 99%. Cela signifie
que même si les scores diminuent ou augmentent, le classement des systèmes reste in99
Figure 4.2 – Résultats BLEU [%] pour l’ensemble Cortes-Verbatim de la direction de
l’espagnol vers l’anglais de la troisième année
Figure 4.3 – Résultats BLEU [%] pour l’ensemble Cortes-FTE de la direction de l’espagnol vers l’anglais de la seconde année
100
Ensemble
3/EPPS-FTE_EsEn
3/Cortes-FTE_EsEn
3/Cortes-Verb_EsEn
3/VoA-Verb_ZhEn
2/EPPS-FTE_EnEs
2/EPPS-FTE_EsEn
2/EPPS-Verb_EnEs
2/Cortes-FTE_EsEn
2/Cortes-Verb_EsEn
2/VoA-Verb_ZhEn
Corrélation sur
les scores BLEU
99,60
99,99
99,88
99,30
100
99,73
100
100
99,98
100
99,96
99,47
100
Corrélation sur
le classement
98,60
100
99,99
99,30
100
100
100
98,79
100
100
100
96,36
100
Table 4.5 – Corrélations sur les scores BLEU [%] et sur les classements des systèmes.
changée. Cela se confirme par la corrélation sur les classements car les coefficients sont
au-dessus de 96%. Ainsi, dans notre contexte, le fait d’améliorer la qualité des traductions de référence ne permet pas de mieux distinguer, via des mesures automatiques, les
systèmes de traduction automatique.
4.6.3.6
Discussion
Nous avons montré que la qualité des traductions de référence n’a pas nécessairement
un impact important sur une métrique automatique, en l’occurrence la métrique BLEU.
Le WER, certes moins utilisé en évaluation de la traduction automatique, a aussi montré
ses limites face à la qualité d’une traduction humaine. Ici, c’est l’évaluation utilisant les ngrammes qui est prise en défaut : même lorsque des traductions de référence de plus basse
qualité sont utilisées, les résultats restent similaires d’une traduction de référence à une
autre. De plus, d’importantes modifications de la traduction humaine (comme par exemple
la direction du chinois vers l’anglais de la troisième année) n’affectent pas concrètement
les résultats des systèmes automatiques. Toutes les directions et types de données testées
sont concernées.
Toutefois, il faut relativiser ces tests par deux points importants. D’une part, le
contexte de nos expériences utilise des métriques automatiques actuelles. L’impact sur
les résultats n’est pas si clair et il est même discutable lorsque l’on considère que l’objectif
est de comparer des systèmes : les scores n’évoluent pas selon la qualité des références
ce qui demeure un problème également lié aux mesures automatiques ; a contrario, le
classement des systèmes ne change pas non plus, ce qui aurait tendance à souligner la robustesse des métriques automatiques à distinguer les systèmes de la même manière quelles
que soient les références utilisées. D’autre part, il ne faut pas ignorer la qualité des traductions automatiques : comme cette qualité est faible, les modifications des traductions
de référence ont un impact faible sur les scores.
Par-delà la modification des scores, la validation des traductions de référence ouvre
101
plusieurs discussions :
– les critères de validation : bien que définis avec rigueur, ils ne sont pas toujours
faciles à appliquer par l’équipe de validation ;
– la cohérence entre traducteurs : les différences entre traductions de référence sont
parfois importantes, ce qui montre comment la traduction humaine varie en fonction
du traducteur ;
– les erreurs des traducteurs : elle sont parfois discutables, la validation étant difficile
selon le contexte, le type des données, etc.
Ces trois points doivent être pris en compte lors de la procédure de validation. Les
résultats des métriques automatiques devraient être étudiés en accord avec la variation
de la qualité et de la validation.
4.7
Conclusion
Nous avons présenté dans ce chapitre les ressources linguistiques telles qu’elles sont
utilisées au cours d’évaluations. La difficulté principale liée aux ressources linguistiques
réside dans leur coût qui influence le budget de l’évaluation.
Plusieurs phases ont lieu avant d’obtenir des ressources linguistiques utilisables : identification, production, négociation, standardisation, validation. La figure 4.4 présente le
cycle de vie d’une ressource linguistique en fonction de ces phases. La plupart de ces
phases sont relativement simples mais elles sont cruciales pour le développement d’une
ressource linguistique.
À chaque phase correspond un travail important qui ne doit pas être négligé dans
le processus d’évaluation. L’intérêt de l’évaluateur est d’avoir des données. Toutefois, il
ne faut pas oublier la question des droits légaux des ressources linguistiques. Dans notre
cas, il est nécessaire que notre architecture respecte les questions légales d’utilisation afin
qu’elle soit mise à disposition de tous, par le biais de licence d’utilisation notamment.
Dans un second temps, nous avons abordé l’aspect relatif à l’impact des ressources
sur l’évaluation et avons identifié deux répercussions sur l’évaluation : sur la méthodologie d’évaluation et sur la qualité des résultats obtenus. Ce dernier point, moins trivial,
a été étudié plus en détail dans le cadre d’un projet d’évaluation (TC-STAR) sur plusieurs campagnes d’évaluation, langues, domaines et systèmes. Bien qu’étant conscient
qu’il s’agit d’un contre-exemple, cette expérimentation a présenté une méthodologie pour
mesurer l’impact de ressources linguistiques sur les performances de système. Dans un
même temps, elle nous a permis de montrer les faiblesses des métriques automatiques
utilisées.
Les ressources linguistiques sont nécessaires aux systèmes mais aussi aux mesures
d’évaluation que nous étudions dans le chapitre suivant.
102
4.7. Conclusion
Figure 4.4 – Cycle de vie d’une ressource linguistique.
103
104
Chapitre 5
L’étude des mesures d’évaluation
La question des mesures d’évaluation se place à un tournant du processus d’évaluation.
C’est lors de leur utilisation que prennent corps toutes les phases d’organisation qui ont
précédé. Les mesures sont inévitables car elles permettent d’estimer le niveau de la qualité
atteint par les systèmes évalués. Dans un même temps, le fait de mesurer initialise l’analyse
des sorties des systèmes. Pour ce faire, une métrique est appliquée sur un jeu de données.
Cette métrique est l’organe exécutif de la mesure qui calcule les résultats. Le troisième
élément de la mesure, la méthode, représente la démarche qui va permettre d’arriver au
résultat final. La méthode est organisée par l’évaluateur, en accord avec les autres acteurs
de l’évaluation.
Deux types de mesures émergent : les mesures humaines, pour lesquelles la métrique est
à base de jugements ou d’expertise humains, et les mesures automatiques, pour lesquelles
la métrique dépend plus de programmes, d’algorithmes et de références. Comme nous
l’avons vu dans le chapitre 1 (figure 2.4), l’information donnée par les humains se fait
a posteriori dans le cas de l’évaluation humaine et a priori dans le cas de l’évaluation
automatique. Dans un même temps, le jeu de données n’est pas nécessairement le même et
la méthode est différente selon que la mesure est humaine ou automatique. L’interprétation
et l’analyse des résultats ne se fera pas de la même manière, leurs objectifs étant différents.
Dans ce chapitre, nous commençons par donner les notions de base sur les mesures
d’évaluation en TAL. Identifier et définir une mesure donne à l’évaluateur la possibilité
de formaliser les aspects de qualité attendus. Cela se fait par une réutilisation de mesures
existantes ou la définition d’une nouvelle mesure. Ensuite, nous fournissons un état des
lieux sur l’évaluation humaine et les moyens pour la mettre en place, puis nous faisons
de même pour l’évaluation automatique. Nous illustrons nos choix par des expérimentations concrètes. Finalement, puisque toute nouveauté doit être vérifiée, nous clôturons ce
chapitre par les aspects concernant la méta-évaluation des mesures et de leur métriques.
5.1
5.1.1
Description
Généralités et définitions
Les mesures d’évaluation représentent les moyens mis en œuvre pour estimer la qualité
d’un système. Elles utilisent une ou plusieurs références dans le cas d’une évaluation
105
Chapitre 5 : L’étude des mesures d’évaluation
automatique, ou les connaissances d’un ou plusieurs individus (les juges) dans le cas
d’une évaluation humaine. In fine, les mesures d’évaluation donnent une représentation
quantitative de la qualité pour permettre à l’évaluateur d’interpréter et d’analyser les
résultats.
L’usage de mesures d’évaluation passe par trois éléments fondamentaux :
– La méthode : en amont de la mesure, elle est issue de la réflexion sur l’évaluation
à conduire qui a eu lieu au cours de ses étapes préliminaires (voir chapitre 3). Elle
définit les critères d’évaluation, les éléments sur lesquels sont évalués les caractéristiques des systèmes, et elle spécifie les moyens à mettre en place pour le déroulement
de la mesure. La méthode d’évaluation fournit le contexte nécessaire à toute interprétation de résultats.
– Le jeu de données : ce sont les ressources linguistiques sur lesquelles porte l’évaluation. Elles ont été définies au préalable (voir chapitre 4) et sont spécifiques à la
méthode qui est employée, voire propres à la technologie. Le jeu de données comprend les données de test envoyées aux systèmes évalués et les références utilisées
pour les tester.
– La métrique d’évaluation : c’est le programme mis en place pour calculer les résultats de l’évaluation. La métrique quantifie la qualité. Il s’agit concrètement de
programmes de calculs ou d’algorithmes ramenant l’appréciation d’un critère à une
ou plusieurs valeurs. Cette notion de métrique est étroitement liée à celle de mesure
car la métrique est l’application technique de la mesure.
Mesurer permet de formuler une qualité. Au-delà d’un « simple chiffre », la qualité
d’un système est liée à une valeur, interprétable et non ambiguë. Il est ensuite possible
de la comparer à une autre valeur issue de l’évaluation d’un autre système dans un même
contexte, ou bien, dans certains cas, à l’état de l’art 1 .
Nous distinguons avant tout les mesures humaines des mesures automatiques.
La mesure humaine est dépendante de juges humains qui estiment la qualité en fournissant des jugements sous forme de valeurs. Ces jugements sont ramenés à du quantitatif,
ce qui permet d’agréger l’ensemble des jugements et d’avoir une valeur globale pour représenter la qualité perçue. Par contre, la conduite de jugements est la cause de la non
reproductibilité de la mesure, car des êtres humains ne reproduiront pas exactement les
mêmes jugements d’une évaluation à une autre : leur jugements sont subjectifs par nature.
La mesure automatique est, elle, dépendante de programmes ou d’algorithmes qui
comparent la sortie d’un système à une référence construite manuellement par un expert.
En cela, elle est dite objective car les résultats ne seront pas dépendants du couple juge/sortie comme pour l’évaluation humaine : la référence est construite « à l’aveugle », sans
que l’expert ait connaissance de la sortie du système.
Ainsi, l’évaluation humaine se déroule directement sur une sortie de système. Au
contraire, l’évaluation automatique contient une première étape certes manuelle mais elle
est désolidarisée de la sortie produite. De plus, l’humain a connaissance de la sortie des
systèmes dans le premier cas mais, généralement, pas dans le second.
Lorsque l’on cherche à mesurer les performances d’un système selon certains critères,
il est impératif de définir :
1. Attention toutefois à ne pas prendre la comparaison avec l’état de l’art au pied de la lettre. Comme
nous le verrons par la suite, cette comparaison ne peut se faire de manière formelle, les contextes étant
vraisemblablement toujours différents.
106
5.1. Description
– une méthode, qui détermine avec exactitude le déroulement de la mesure ;
– un jeu de données, qui représente en partie le contexte d’utilisation dans lequel la
mesure va s’exécuter ;
– la ou les caractéristiques du système, qui servent à spécifier le ou les phénomène(s)
mesuré(s) et définir les critères d’évaluation ;
– le modèle de qualité, qui lie les caractéristiques aux critères ;
– une métrique, qui calcule les performances du système évalué, selon les critères, à
l’aide d’opérations et suivant le modèle défini ;
– l’échelle de valeurs, qui permet d’interpréter les résultats.
C’est l’ensemble de ces aspects (figure 5.1) qui indique à l’évaluateur comment estimer
les performances d’un système et en interpréter les résultats.
Figure 5.1 – Différents aspects d’une mesure.
5.1.2
Identification des mesures
La qualité de la mesure elle-même est à prendre en compte lors de son utilisation.
Pour ce faire, il faut en premier lieu identifier correctement la mesure que l’on souhaite
utiliser. Par exemple, [King, 2005] définit les critères d’une bonne mesure comme étant :
– Valide : la capacité de la mesure à fournir des résultats pertinents et corrects est le
principal critère à retenir. En effet, la mesure doit fournir des résultats conformes
aux attentes de l’évaluateur. Dans le cas de mesures imparfaites ou approximatives,
il faut déterminer un intervalle de confiance qui est clairement précisé et pris en
compte lors de l’interprétation des résultats. Par exemple, lorsque l’on mesure la
fluidité d’un texte traduit avec des juges humains, on sait estimer un intervalle de
confiance en calculant l’accord inter-juges.
– Fiable : étroitement liée à la validité de la mesure la fiabilité d’une mesure détermine
sa reproductibilité dans un contexte donné et l’uniformité du calcul des performances
du système évalué. Par exemple, les taux d’erreurs sont uniformes quel que soit le
système évalué et la répétition de l’évaluation ne cause pas de modification dans les
résultats.
– Objective : aucun type de système ne doit être privilégié par la mesure. Dans bien
des évaluations, un des principaux intérêts est de comparer différentes approches
107
technologiques (statistique, à base de règles, de connaissances, etc.). Une bonne
mesure unanimement reconnue ne saurait favoriser l’une ou l’autre des méthodes.
– Économique : ce critère se rapporte au coût de la mesure en termes de production,
de développement, d’utilisation, etc. Même si une mesure ne doit effectivement pas
être trop coûteuse, ce critère nous semble discutable, car il peut amener à réduire
l’importance des autres critères.
– Informative : les résultats retournés par la mesure sont censés être les plus exhaustifs
possible, sans pour autant être rébarbatifs. L’évaluateur doit accéder à des résultats succincts et effectuer une analyse correcte. De plus, la mesure rend compte de
manière pertinente des performances d’un système.
Ces critères sont indispensables pour identifier la mesure idéale, la définir, ou développer la métrique qui lui correspond. Toutefois, il faut parfois faire des concessions sur
certains critères pour en privilégier d’autres car la « mesure parfaite » n’est, hélas, pas
courante. Par exemple, les mesures humaines ont tendance à fournir des résultats plus
valides que des mesures automatiques mais leur coût est plus élevé et leur fiabilité est
réduite.
Côté économique, une mesure est effectivement liée aux ressources qu’elle utilise dont
le coût influence par conséquent celui de la mesure, et donc de l’évaluation. Ce coût n’est
pas négligeable (cf. chapitre 4) et l’impact des productions humaines est de première
importance. Cela concerne autant la création d’une référence (par exemple la création
de jugements de pertinence sur une grande quantité de données pour la recherche d’information ou établir des traductions de référence pour la traduction automatique) que
l’implication de juges humains lors des évaluations ou l’exécution même de la métrique.
Enfin, le coût de la mesure restreint aussi le contexte de l’évaluation : on sait évaluer le
rappel des systèmes en recherche d’information, mais le coût d’un corpus de référence est
tellement important que la plupart du temps seule la précision est considérée, ou alors
combinée à un rappel partiel.
Finalement, l’utilisation de plusieurs mesures sur un même jeu de données est un point
essentiel pour l’optimisation des résultats. Une mesure unique peut introduire un biais
dans les résultats (en privilégiant une approche, en étant inadaptée à un domaine, etc.) et
par conséquent la corrélation de différentes mesures améliore la validité de l’évaluation.
5.1.3
Modélisation
La modélisation d’une métrique, en particulier lorsqu’elle est automatique, passe par
deux chemins parallèles et complémentaires (figure 5.2). Nous nous inspirons pour cela
de [Popescu-Belis, 2007]. Le premier chemin traite de la modélisation informatique d’une
métrique automatique, tandis que le second traite des productions manuelles effectuées
pour le bon fonctionnement de la métrique et incluant une métrique humaine. Nous faisons ici la synthèse des étapes de développement d’une métrique, au cœur de la mesure
d’évaluation.
Ainsi, l’évaluateur commence par sélectionner une caractéristique de performance à
évaluer qui permettra de modéliser la métrique. Il s’agit de focaliser l’évaluation sur une
caractéristique, un aspect fonctionnel d’un système. Cela nous amène ensuite à choisir
entre la définition d’une métrique automatique ou celle permettant à des humains d’apporter de l’information sur les données.
108
5.1. Description
Figure 5.2 – Modélisation d’une métrique d’évaluation.
La constitution d’une métrique automatique commence par la définition des critères de
pertinence relatifs à la caractéristique sélectionnée. Par exemple, ce critère est la proportion de constituants correctement annotés syntaxiquement dans le cas d’une évaluation
d’analyseurs syntaxiques, pour laquelle la caractéristique retenue est la capacité à annoter
en constituants.
Ensuite, la métrique est produite et développée pour fournir des valeurs automatiquement. En suivant l’exemple précédent, cette métrique permet de parcourir les données
pour comparer les analyses automatiques des systèmes à une référence produite manuellement. Une étape de méta-évaluation contrôle le bon fonctionnement de la métrique en
comparant ses résultats à ceux d’une métrique humaine. Finalement, une dernière étape
consiste à utiliser la métrique et à en analyser les résultats.
La seconde partie de notre modélisation consiste à effectuer manuellement des jugements sur les données renvoyées par les systèmes, ou bien à annoter manuellement les
données d’entrée de la même manière que le feraient les systèmes. L’évaluateur définit des
directives pour les juges ou les annotateurs qui effectueront le travail. Dans le cas d’une
évaluation humaine (sous-partie de gauche de la figure 5.2), des spécifications sont établies
pour faciliter la compréhension de la tâche par les juges. Ceux-ci procèdent ensuite aux
jugements selon les critères qui auront été définis dans les directives d’évaluation. Finalement, un accord inter-juges est calculé afin de veiller au bon déroulement de l’opération,
et l’analyse des résultats est effectuée.
L’évaluateur définit aussi des spécifications pour les annotateurs qui ajoutent de l’information aux données d’évaluation, ou les transforment. Une référence est ainsi créée et
109
est utilisée pour la comparer aux sorties des systèmes. Un accord inter-annotateur est
calculé et la référence est corrigée si besoin est.
Notre modélisation contient de nombreuses flèches pointillées renvoyant à des étapes
antérieures. Il s’agit de retours d’expérience qui modifient la définition de la métrique. Par
exemple, l’étape de méta-évaluation peut affecter l’étape de développement de la métrique
(si les résultats ne sont pas ceux attendus), qui elle-même peut affecter la définition des
critères de pertinence (s’il s’avère que les critères de pertinence n’étaient pas correctement
définis).
5.1.4
Métriques de base
Une métrique automatique mesure l’écart avec une référence qui symbolise les attentes
d’un utilisateur potentiel. Une comparaison est possible en utilisant une mesure de distance entre la sortie d’un système et la référence. La proximité calculée détermine le niveau
de performance du système. Il est aussi possible d’utiliser des métriques de précision et de
rappel : à partir d’une sortie de système, ces deux métriques fournissent respectivement
la pertinence de la réponse et sa couverture. Si l’on considère un objet comme étant la
plus petite unité utilisée par l’évaluateur pour mesurer la qualité des données renvoyées
par le système, la précision et le rappel se définissent comme :
précision =
nombre d′ objets pertinents renvoyés
nombre d′ objets renvoyés
(5.1)
Une précision de 100 % signifie que tous les objets renvoyés sont pertinents.
rappel =
nombre d′ objet pertinents renvoyés
nombre d′ objet pertinents de réf érence
(5.2)
Un rappel de 100 % signifie que tous les objets pertinents de la référence ont été
renvoyés.
La précision et le rappel sont des métriques complémentaires : aucune ne se suffit à
elle seule pour donner une indication des performances mesurées. En effet, une précision
de 100 % ne signifie pas que tous les objets de la référence ont été renvoyés car sinon il
suffit de ne renvoyer que quelques objets dont on est certain de la pertinence : le rappel
est alors très bas. De la même manière, un rappel de 100 % ne signifie pas pour autant
que d’autres objets n’ont pas été renvoyés, à tort, car sinon il suffit de renvoyer tous les
objets possibles : la précision est alors plus basse.
Afin de combler cette lacune, [van Rijsbergen, 1979] a introduit une métrique d’efficacité globale qui combine la précision et le rappel en une métrique unique, la f-mesure.
f − mesure = (β 2 + 1) ∗ (précision ∗ rappel)/(β 2 ∗ précision + rappel)
(5.3)
En supposant β > 0 et que le système ait renvoyé au moins 1 document pertinent.
β permet de pondérer la précision ou le rappel et ainsi de différencier leur poids dans
l’estimation des performances. Cette métrique, qui est en réalité la moyenne harmonique
de la précision et du rappel, est généralement utilisée sous la forme :
f − mesure = 2 ∗ (précision ∗ rappel)/(précision + rappel)
110
(5.4)
5.1. Description
Où la précision et le rappel sont pondérés équitablement.
L’utilisation de la f-mesure pêche par l’analyse binaire qui est faite d’un problème et
manque parfois de finesse pour juger la qualité d’un système. La pertinence d’un objet
renvoyé peut correspondre à un degré de pertinence sur une échelle plutôt qu’à un choix
entre deux valeurs. D’autres métriques doivent alors être employées.
Ces métriques « de base » sont considérées comme des métriques automatiques fonctionnant en tant que programme. Mais il ne faut pas oublier qu’elles nécessitent la participation de l’humain pour être exécutées. Cela se produit lorsque les références sont
constituées (traductions de référence, documents pertinents d’une base, etc.).
Une métrique humaine fournit des jugements de pertinence en fonction de l’avis d’un
juge, humain ou expert. Les métriques de base sont souvent spécifiques aux différentes
technologies mais consistent la plupart du temps à fournir un jugement sur une petite
unité de la sortie renvoyée (une phrase en traduction automatique, un terme en extraction
terminologique, une expression en question-réponse, etc.). Le jugement est donné sur une
échelle de valeurs prédéfinie et la moyenne des jugements est calculée pour établir un score
moyen par système.
Une grande majorité des métriques utilisées en évaluation du traitement automatique
des langues sont dérivées de ces trois mesures.
Dans les sections suivantes, les métriques d’évaluation de plusieurs technologies sont
abordées plus en détails et les mesures d’évaluation explicitées. Cette liste des technologies,
mesures et métriques n’est pas exhaustive mais traite différents aspects de l’évaluation en
traitement automatique des langues.
5.1.5
Applications
Dans les deux sections suivantes, nous appliquons notre modélisation sur des technologies particulières : nous prenons notamment comme support le détail des travaux conduits
sur les projets CESTA (cf. annexe A.2), pour l’évaluation de la traduction automatique,
et CESART (cf. annexe A.3), pour l’évaluation de l’extraction terminologique, ainsi que
les analyses qui en résultent. Pour plus de clarté et de compréhension, nous décrivons ici
les grandes lignes de ces projets, en particulier le protocole et les données d’évaluation.
Les détails concernant l’organisation et le déroulement des projets ont déjà été donnés
dans le chapitre 3.
5.1.5.1
Dans le projet CESTA, une première campagne visait à mesurer la qualité des traductions produites par des systèmes de traduction automatique dans un domaine général tout
en définissant un protocole d’évaluation clair et réutilisable. La seconde campagne, après
adaptation et ajustement du protocole d’évaluation, étudiait la capacité des systèmes à
s’adapter à un domaine spécialisé.
La seconde campagne d’évaluation avait pour objectif particulier d’observer l’adaptation des systèmes à un domaine, parfois appelé enrichissement terminologique, et son
impact sur les performances des systèmes. Deux séries de scores ont été établies avec le
protocole d’évaluation amélioré : l’une utilise des versions « génériques » des systèmes, et
l’autre utilise des versions adaptées au domaine choisi par les organisateurs de CESTA, à
savoir celui de la santé.
111
Au total, 13 systèmes ou versions de systèmes ont pris part à l’une ou les deux campagnes CESTA 1 . Les résultats des systèmes évalués ayant été diffusés de manière anonyme, les résultats sont présentés d’après les mêmes conventions : les différentes instances
des systèmes sont numérotées de S1 à S13, ce qui signifie que certains systèmes sont
dupliqués entre la première et la seconde campagne. En outre, nous précisons entre parenthèses la langue source (« en » pour l’anglais ou « ar » pour l’arabe) et le numéro de
la campagne (1, 2a ou 2b). La première campagne concerne ainsi les systèmes de S1(en,1)
à S5(en,1) pour l’anglais et les systèmes S6(ar,1) et S7(ar,1) pour l’arabe, alors que la seconde concerne les systèmes S8(en,2) à S12(en,2) pour l’anglais et S13(ar,2) pour l’arabe.
Pour la seconde campagne, déclinée en deux phases, les systèmes sont plus spécifiquement notés avec 2a (avant adaptation) ou 2b (après adaptation), par exemple S8(en,2a)
ou S13(ar,2b). Il n’est donc pas possible de comparer les performances entre les deux campagnes pour les systèmes ayant participé aux deux, mais il est possible de comparer les
performances d’un même système avant et après adaptation du domaine, dans la seconde
campagne, par exemple les scores de S9(en,2a) et S9(en,2b), ou S13(ar,2a) et S13(ar,2b).
Les données utilisées sont telles que décrites dans le chapitre 4.
5.1.5.2
À l’origine, trois tâches ont été prévues : l’extraction des termes pour la construction d’un référentiel terminologique ; l’extraction des termes pour l’indexation contrôlée
et l’extraction des relations sémantiques. Faute de participants à la tâche d’extraction
des termes pour l’indexation contrôlée, la campagne d’évaluation s’est déroulée sur deux
tâches :
– Tâche T1 : Extraction des termes pour la création et construction d’un référentiel
terminologique. ;
– Tâche T2 : Extraction des relations sémantiques (synonymie) à partir d’une liste de
termes amorces.
Cinq systèmes ont participé à l’évaluation sur la tâche T1, tandis qu’un seul a participé
à l’évaluation sur la tâche T3 2 . Puisque les résultats étaient diffusés de manière anonyme,
ils seront présentés sous la forme Sys1, Sys2, etc.
Les ressources utilisées pour mener à bien la campagne d’évaluation sont décrites dans
le chapitre 4.
5.2
Évaluation humaine
L’objectif final des outils de traitement automatique des langues est avant tout de
satisfaire les utilisateurs de ces outils. Comme l’évaluateur cherche à connaître la qualité
d’un outil, il va en premier lieu s’adresser à des utilisateurs potentiels, ou des experts
utilisant la technologie de l’outil concerné. Cela se fait par le biais d’évaluations humaines
1. Les noms des systèmes et/ou des organisations les développant sont les suivants : Comprendium
(Translendium), MLTS (CIMOS), Ramses (RALI, Université de Montréal), Reverso (Softissimo), RWTH
Aachen, SDL Enterprise Translation Server, Systran et l’Université Polytechnique de Catalogne.
2. Les noms des organisations sont les suivants : CEA, EDF, TEMIS, Université de Montréal (RALI)
et Université Paris 13 (LIPN).
112
5.2. Évaluation humaine
qui sont entreprises par des juges, des personnes adéquates à qui l’on demande de déterminer la qualité d’un système. Habituellement, les jugements se font sur une partie des
résultats d’un système. Les juges sont sélectionnés ou recrutés selon différents critères en
rapport avec la tâche : niveau d’études, niveau d’expertise, langue, connaissance spécifique d’un domaine ou d’une technologie, etc. Plutôt que de leur demander directement ce
qu’ils pensent de la qualité d’un système, ils ont à leur disposition plusieurs critères avec
des échelles de valeur explicites pour juger des unités de base (par exemple une phrase
en traduction automatique plutôt qu’un document entier). Au final, c’est avant tout la
connaissance humaine, celle des juges sélectionnés, qui est utilisée pour analyser les sorties
du système.
Ces évaluations humaines se font en considérant les juges humains comme référence
pour la tâche qui leur est donnée. Toutefois, il est établi que les jugements de juges
différents varient, de même que les jugements d’un même juge au cours du temps : les
jugements sont dépendants de l’instant du jugement ou de ses conditions.
La variation des jugements, d’importance plus ou moins grande, amène l’évaluateur
à désigner les évaluations humaines comme étant subjectives. La terminologie employée
varie beaucoup d’une technologie à une autre, et même au sein d’une même communauté.
Les termes évaluation humaine, évaluation manuelle, évaluation subjective, tests subjectifs
sont les plus fréquents. Nous avons décidé dans cette étude d’employer le terme d’évaluation humaine tout d’abord par habitude 1 , mais aussi car les nuances avec les autres
termes nous semblent assez significatives : le terme d’évaluation manuelle est proche de
celui d’une annotation et ôte une partie de l’indépendance des jugements ; au contraire, le
terme d’évaluation subjective donne, à notre avis, une part trop forte à la subjectivité des
jugements qu’il faut tout de même relativiser (et dont on cherche par ailleurs à réduire la
portée). L’évaluation humaine est à mi-chemin entre les deux notions et permet de lisser
notre propos.
En suivant la chronologie de la vie d’un système, nous considérons que l’évaluation
d’un système part d’une observation non formelle des performances par ses développeurs.
Concrètement, il s’agit d’observer les sorties du système sans aucune échelle de pertinence
et en fonction de la simple perception du développeur. Pourtant, ce n’est pas la même
chose d’observer des sorties par soi-même que de les faire juger par des tiers : il faut se
rendre à l’évidence que des critères précis doivent être établis.
Toutefois, à partir du moment où l’opinion humaine est requise pour évaluer, la logique
s’efface rapidement devant l’esprit subjectif d’un juge, et deux juges évaluant les mêmes
données peuvent obtenir des jugements radicalement différents. Chaque humain pense
différemment, et cela se ressent directement lorsqu’une évaluation humaine est conduite.
S’il est toutefois possible de limiter l’impact subjectif, c’est à un coût accru en multipliant
les points de vue, les jugements, afin de minimiser l’impact des positions extrêmes.
Malgré leur coût et leurs imprécisions, il y a tout de même des avantages à mener des
évaluations humaines. En premier lieu, les critères de qualité sont la plupart du temps
difficilement quantifiables à partir d’un programme informatique (par exemple la fluidité d’un texte en français). Pour pallier les faiblesses techniques ou l’absence de mesure
automatique, seul le jugement d’un humain est possible. Le niveau de performance d’un
système est évalué, tel qu’il est perçu par l’humain. De plus, l’usage de jugements humains
1. Human Evaluation est beaucoup utilisé dans le domaine très anglophone de la traduction automatique.
113
nécessite peu de développement technique : c’est la connaissance des juges qui est utilisée
et seules les interfaces de jugement sont à développer, généralement simples et faciles à
utiliser. Les jugements humains effectués en profondeur donnent aussi les moyens d’analyser en détail la sortie d’un système, dans un contexte réel. Par exemple, en traduction
automatique, à chaque phrase correspond un ou plusieurs jugements : il est alors possible
pour l’évaluateur de déterminer quelles sont les phrases problématiques (pour le système
comme pour les juges) et d’en identifier les raisons.
Enfin, nous voyons aussi l’intérêt pour l’évaluateur d’être relativement proche des
besoins finaux pour un système donné : que ce soit l’avis d’utilisateurs potentiels ou
d’experts, les résultats apportés sont en relation directe avec les attentes du système.
5.2.1
Caractéristiques
5.2.1.1
Description
Différentes approches existent pour traiter de l’évaluation humaine. Elles sont directement dépendantes du détail des mesures d’évaluation et servent avant tout au calcul
synthétique des jugements pour que l’évaluateur puisse les interpréter. À notre sens, sept
caractéristiques bien distinctes sont à prendre en compte pour définir une mesure d’évaluation humaine. Ils représentent différents aspects de l’évaluation humaine et varient
selon l’approche adoptée.
Tout d’abord, le niveau d’expertise permet de choisir les individus qui effectuent
les jugements de pertinence. Il sert à définir correctement qui sont les acteurs des jugements, leurs caractéristiques et leur rôle. Le niveau d’expertise est pris en compte lors
de l’interprétation finale et de l’analyse des données collectées. Son échelle va du niveau
utilisateur potentiel au niveau expert, avec tous les intermédiaires possibles. Nous pensons
toutefois qu’il faut éviter de prendre des juges sans aucun lien avec le système évalué, car
l’évaluation nécessite des juges ayant les capacités requises pour estimer la qualité des
sorties. L’évaluateur veillera à collecter un maximum de caractéristiques pertinentes, afin
que les résultats de l’évaluation soient compris de personnes externes. Les caractéristiques
des juges peuvent être de différentes natures : niveau d’expertise, niveau d’étude, culture,
âge, genre, niveau d’apprentissage, etc. Par exemple, dans CESART, nous avons comparé
les jugements de deux documentalistes à deux d’un docteur en médecine et linguiste sur
une même tâche (voir section 5.3.3).
Ensuite, la description des critères de jugements et l’échelle de valeurs correspondante. Il s’agit de fournir l’explication la plus claire et succincte possible (l’évaluation
humaine restant par définition subjective) des critères qu’ont à utiliser les juges pour
estimer la pertinence des sorties. La description des critères donne un axe d’évaluation
commun à tous les juges et son échelle de valeurs délimite les paliers de qualité. Le système
de jugement est traditionnellement binaire, ternaire ou à 5 niveaux (appelé échelle de Likert [Likert, 1932]), mais cela peut être plus. Le choix du nombre de niveaux dépend de la
tâche et de sa difficulté. Un faible nombre de niveaux est généralement lié à un jugement
facile : plus la difficulté des jugements augmente, plus il y aura de niveaux. Une échelle
à niveaux impairs accorde un niveau central moyen, représentant un jugement neutre ou
« sans avis ».
Le volume des données évaluées fait état du travail effectué par les juges et par
conséquent des difficultés liées à la lourdeur de la tâche. De plus, cela donne une idée des
114
proportions sur lesquelles le ou les systèmes ont été évalués. La proportion des données
sélectionnées est plus ou moins importante, allant jusqu’à la totalité des données, mais
elle doit toujours rester représentative de l’ensemble pour rester cohérente avec ce que
l’évaluateur cherche à évaluer. Le volume dépend de la tâche d’évaluation (par exemple,
la création d’un corpus à grande échelle dans PASSAGE a poussé les évaluateurs à ne
sélectionner pour l’évaluation qu’une partie d’un corpus de 100 millions de mots), mais
aussi des moyens mis à disposition : habituellement, la totalité des données renvoyées est
évalué, mais des contraintes de budget ou humaines poussent parfois l’évaluateur à ne
sélectionner qu’une moindre proportion. C’est par exemple le cas de la seconde campagne
CESTA où les systèmes de traduction automatique ont été évalués sur le tiers des données
renvoyées, car nous ne trouvions pas facilement, dans le temps imparti de juges pour les
textes spécialisés.
Selon les critères d’évaluation, les données évaluées sont accompagnées d’une référence, qui sert d’indicateur au juge concernant la qualité recherchée, supposée idéale, ou
le type d’information que devrait retourner le système. Lors de l’évaluation, le juge a sous
les yeux une ou plusieurs références, aucune référence (et ne se servir que de ses propres
connaissances) ou une « pré-référence » qui a subi un traitement automatique.
La plupart du temps, les jugements font l’objet d’une validation. Le plus souvent, cela
sert à prouver le bon déroulement de l’évaluation et à relativiser l’impact des différences
entre systèmes (en calculant un intervalle de confiance par exemple). Les jugements sont
validés ou non, partiellement ou en totalité, ou comparés (automatiquement ou non)
avec d’autres jugements. Nous étudions ce point plus en détail dans la section 5.2.3, la
validation faisant partie du processus même de l’évaluation et du travail de l’évaluateur
a posteriori.
Un contrôle du juge peut être mis en place. L’évaluateur décide de surveiller le
travail du juge en temps réel même si le risque est d’influencer son travail. Il cherche à
évacuer toute idée de subjectivité en normalisant les jugements à travers le point de vue
d’un expert ou d’un comité d’expertise, ayant pouvoir de décision sur les jugements. Ce
dernier regroupe plusieurs juges qui prennent une décision unique sur un jugement. A
contrario, les juges peuvent être libres d’effectuer les jugements de pertinence comme ils
l’entendent, l’évaluateur vérifiant a posteriori leurs jugements (voir section 5.3.3.5).
À cela s’ajoutent les conditions de l’évaluation : interfaces, lieux, entraînement des
juges, anonymisation des données, etc. Elles rendent compte des difficultés que les juges
rencontrent et aident l’évaluateur à expliquer des résultats inattendus.
Chaque combinaison de ces sept caractéristiques définit une approche spécifique de
l’évaluation humaine. Sa description est utile pour l’interprétation des résultats afin de
connaître les conditions de l’évaluation.
Le tableau 5.1 résume les caractéristiques à prendre en compte pour définir une mesure
d’évaluation humaine, les valeurs possibles, ainsi qu’un exemple en traduction automatique à partir de nos connaissances acquises au cours des projets CESTA et TC-STAR.
5.2.1.2
Application : CESTA
Les deux campagnes d’évaluation du projet CESTA ont comporté une étape d’évaluation humaine afin d’une part de mesurer la qualité des systèmes et d’autre part de
méta-évaluer des métriques automatiques en comparant les scores humains aux scores automatiques. Deux critères d’évaluation ont été retenus, la fluidité et l’adéquation, d’après
115
Caractéristique
Niveau d’expertise des
juges
Critères de jugements
et échelle de valeurs
Volume des données
évaluées
Utilisation de référence(s)
Validation des jugements
Contrôle du juge
Conditions
tion
d’évalua-
Valeurs possibles
D’utilisateur final à expert d’un domaine
N niveaux, généralement
N étant fixé à 2, 3, ou 5
Proportion représentative du total des données
ou ensemble des données
Une à plusieurs références ou pré-références
Oui/Non/Partiellement
Exemple
Utilisateur final d’un domaine
spécialisé
Adéquation et échelle de Likert
Un tiers du corpus
Une référence utilisée pour la
mesure d’adéquation
Calcul d’un accord inter-juges
Oui/Non, a priori /a pos- Validation a posteriori
teriori
Ensemble de l’environne- Interface d’évaluation, anonyment d’évaluation
misation des données, travail à
domicile des juges
Table 5.1 – Caractéristiques de définition d’une mesure humaine, valeurs possibles et
exemples en traduction automatique.
les campagnes d’évaluation DARPA [White et al., 1994].
Pour que les juges puissent évaluer les traductions automatiques, nous avons spécialement développé une interface accessible via Internet 1 . À l’aide de cette interface, chaque
segment traduit (correspondant à une phrase la plupart du temps) est évalué par deux
juges différents. Les segments de toutes les traductions disponibles sont mélangés, pour
que les juges ne puissent pas mémoriser des informations sur deux segments adjacents. En
effet, cela risque de biaiser l’évaluation dans le sens ou les juges pourraient inconsciemment deviner la signification d’un segment à partir d’autres segments vus précédemment.
C’est ce que nous avons aussi observé lors d’une évaluation en cascade d’un système de
traduction de l’oral vers l’oral [Hamon et Mostefa, 2008a]. En effet, la tâche d’évaluation
est limitée à la traduction automatique seule et en devinant le contenu d’une phrase, le
juge ne ferait pas uniquement état de la qualité en traduction.
Pour chacun des deux critères les évaluateurs répondent à une seule question. Pour la
fluidité, la question posée est : « Ce texte est-il écrit en bon français ? ». Les juges ont
alors à choisir une note sur une échelle de cinq valeurs, allant de « français impeccable »
(note égale à 5) à « français incompréhensible » (note égale à 1). Pour l’adéquation, la
question posée est : « À quel point le sens exprimé dans la traduction à noter est le même
que celui du texte de référence ? ». Une échelle de cinq valeurs est également proposée aux
juges, allant de « tout le sens » (note égale à 5) à « aucun sens » (note égale à 1).
Dans un premier temps, les échelles de valeurs intermédiaires sont nommées explicitement lors de la première campagne. Mais il a finalement été décidé de laisser le libre arbitre
aux juges des valeurs intermédiaires en ne spécifiant par leurs noms, mais seulement les
1. Plus de détails sur cette interface sont disponibles dans le rapport du projet CESTA [Hamon, 2007b]
disponible à l’adresse : http ://www.technolangue.net/IMG/pdf/Rapport_final_CESTA_v1.04.pdf.
116
valeurs des scores (2, 3, 4) pour la seconde campagne. De plus, les jugements de la fluidité
et de l’adéquation ont été effectués en même temps pour la première campagne, mais de
manière séparée pour la seconde : les juges évaluaient à la suite tous leurs segments selon
la fluidité, puis selon l’adéquation. La dernière modification entre les deux campagnes
d’évaluation concerne l’évaluation de la traduction officielle en plus des traductions automatiques lors de la seconde campagne. En effet, seules les traductions automatiques ont
été évaluées pour la première campagne.
5.2.1.3
Application : CESART
Les sorties des extracteurs se trouvent sous la forme de candidats termes triés par un
ordre de pertinence (par défaut par fréquence décroissante). L’évaluation de l’extraction
terminologique consiste à effectuer dans un premier temps l’appariement automatique
de la sortie des extracteurs avec la référence sans aucune variation terminologique dans
l’appariement (c’est-à-dire en conservant les termes tels quels, sans lemmatisation ou
autre modification). Les experts analysent ensuite les candidats termes en s’aidant de la
référence terminologique représentative du domaine du corpus analysé. Ils procèdent à
une évaluation hors contexte en comparant les candidats aux termes certifiés.
Pour chaque candidat terme en sortie d’un système, l’expert a le choix entre 5 valeurs
de jugement. Elles prennent en considération les mots composant un candidat terme, qui
se trouve souvent être une expression composée :
– Valeur 1 (score=4) : le candidat terme est présent dans la terminologie (appariement
automatique) ;
– Valeur 2 (score=3) : le candidat terme est valide, mais n’est pas dans la terminologie ;
– Valeur 3 (score=2) : tous les composants du candidat terme sont certifiés individuellement dans la terminologie ;
– Valeur 4 (score=1) : un seul composant du candidat terme est certifié dans la terminologie ;
– Valeur 5 (score=0) : aucun composant du candidat terme n’est certifié dans la
terminologie.
L’expert suit l’ordre des valeurs. Ainsi, si le candidat terme expertisé ne correspond
pas à la valeur 1, l’expert teste la valeur 2, et ainsi de suite.
5.2.2
Déroulement
Les évaluations humaines sont à encadrer strictement, du fait de leur grande consommation financière, humaine et en temps. Des lacunes dans le protocole ne font qu’accentuer
les difficultés de l’évaluateur, des juges, et des agents externes cherchant à comprendre les
résultats. Les différentes étapes de l’évaluation humaine sont à identifier clairement. Elles
doivent être suivies avec précaution. Le protocole que nous proposons est relativement
simple et se déroule en sept grandes étapes :
1. Sélection des données à évaluer ;
2. Mise en place des données dans la ou les interfaces de jugement ;
3. Jugement des données sélectionnées ;
4. Collecte et formatage des jugements ;
117
5. Vérifications et corrections le cas échéant ;
6. Calcul des résultats ;
7. Interprétation et analyse des résultats.
Les étapes sont plus au moins longues et certaines se déroulent en parallèle à partir de
l’étape 3, comme le montre la figure 5.3. Le calcul de résultats intermédiaires est possible
afin de vérifier que les jugements humains sont bien réalisés.
Figure 5.3 – Déroulement d’une évaluation humaine.
5.2.3
Validation des jugements humains
La conduite d’évaluations humaines semble être un gage de pertinence des jugements.
Cependant, nous avons déjà expliqué que les juges ne sont pas toujours d’accord entre
eux, ni même d’accord avec eux-mêmes au cours du temps. Quels que soient le domaine
et la tâche, il y aura toujours des variations dans les jugements car l’usage de la langue
n’est pas déterministe. Ainsi, les variations de jugements sont souvent dues à une erreur
d’appréciation, mais aussi à de réelles divergences de point de vue entre juges ou l’influence
de l’environnement d’évaluation sur ceux-ci. L’évaluation humaine reste subjective, mais
nous écartons l’idée que le désaccord entre juges est synonyme d’erreur : le point de vue
peut être différent sans toutefois être faux. Ainsi, nous soulignons l’intérêt de multiplier le
nombre de juges et de jugements lors d’une évaluation humaine. C’est le moyen de réduire
l’intervalle de confiance (c.-à-d. le degré de confiance des valeurs obtenues) et de tendre
vers un écart-type (c.-à-d. la dispersion des valeurs autour de la moyenne) acceptable.
À titre d’exemple, les évaluations de la campagne CESART ont donné lieu à un test
de corrélation entre trois juges. Deux d’entre eux étaient documentalistes, le troisième
118
docteur en médecine et linguistique. Leur tâche était d’évaluer la pertinence des cent premiers termes renvoyés par un système d’extraction terminologique, selon les cinq critères
décrits en section 5.2.1.3. Une référence était à leur disposition, le MeSH. À l’issue des
jugements, les jugements étaient très disparates selon les paires de juges. L’accord entre
les deux documentalistes était relativement bon, bien que 15 termes aient été jugés de
manière différente sur les 100 termes. L’accord entre les documentalistes et le médecin
linguiste était par contre beaucoup plus réduit, avec 65 et 67 termes en désaccord. Même
si quelques termes étaient redondants (présence de variantes de termes au pluriel et au
singulier) et la distance entre deux jugements était de un ou 2 sur une échelle de 5, cet
exemple met en lumière la difficulté pour des juges à dire la même chose, quand bien
même ils sont experts.
Ainsi, comme nous l’avons fait dans CESART, l’évaluateur doit analyser et interpréter
les résultats des évaluations humaines en prenant en compte les désaccords entre juges. Son
objectif est soit de réduire la variabilité des jugements, soit d’interpréter les résultats en
conséquence et en nuançant son propos. Plusieurs mesures existent pour estimer le niveau
d’accord entre juges et agir en conséquence. Nous en décrivons certaines, de manière non
exhaustive, dans la section suivante en nous appuyant sur des exemples réels. Pour la
plupart d’entre elles, de nombreux paramètres sont à prendre en compte : nombre de
juges, modalités d’évaluation, taille de l’échantillon, etc. De plus, nous définissons un bon
calcul d’accord comme étant :
– objectif : aucun juge ne doit être privilégié, de même que la période des jugements
(dans le cas de comparaisons au cours du temps) ;
– robuste : le calcul d’accord est reproductible à l’identique sans que les résultats
changent ;
– informatif : la description de l’accord doit être compréhensible et donner le maximum
d’informations pertinentes à l’évaluateur ;
– fiable : les résultats du calcul représentent au mieux l’état de l’accord.
Par ailleurs, il faut noter que la distinction entre la validation des jugements humains
et la méta-évaluation, que nous verrons par la suite, est bien réelle, même si la frontière
est très fine. À l’instar de la différence entre évaluation et validation, la méta-évaluation
prouve à quel point une métrique est pertinente. La validation des jugements humains,
elle, détermine s’il est approprié de se fier aux résultats, subjectifs, obtenus par évaluation
humaine. De plus, la validation des jugements humains ne compare pas une métrique
humaine à une autre métrique, mais observe intrinsèquement la robustesse et la fiabilité
des jugements.
5.2.3.1
Accord inter-juges simple
L’accord inter-juges « simple » permet d’observer la concordance entre les juges. Il est
moins utilisé que d’autres calculs d’accord, car la mesure est binaire et ne permet pas de
comparer des juges sur une échelle de plusieurs valeurs. De plus, seul l’accord entre deux
juges est observé. Il est tout de même possible de calculer des accords deux à deux pour
plusieurs juges sur un même échantillon.
Pour N jugements, l’accord inter-juges entre un juge a et un juge b se définit par :
119
N
1 X
accord =
δ(Sia = Sib )
N i=1
(5.5)
L’accord inter-juges correspond au rapport entre la somme des jugements concordants
et le nombre total des jugements effectués par deux juges. Les jugements concordants sont
statués par la différence entre le premier jugement Sia d’un échantillon S, et son second
jugement, Sib . L’accord inter-juges est compris entre 0 et 1, plus généralement indiqué
sous forme d’un taux entre 0 % et 100 %.
Par exemple, deux juges du projet Infile [Besançon et al., 2008] avaient à déterminer
la pertinence de documents pour une tâche de veille technologique. Les documents étaient
alors soit pertinents, soit non-pertinents. Les résultats pour 608 documents en français
sont présentés dans le tableau 5.2.
Juge 1
Juge 2
Pertinent Non pertinent
347
18
51
192
398
210
Pertinent
Non pertinent
Total
Total
365
243
608
Table 5.2 – Concordance des jugements de pertinence sur les mêmes documents, pour
608 documents portant sur le français lors du projet Infile.
Ainsi, 347 documents ont été jugés pertinents à la fois par les deux juges et 192 non
pertinents, soit 347 + 192 = 539 documents concordants. L’accord inter-juges est alors de
539/608 = 0, 89. Les juges concordent donc pour 89 % de leurs jugements. L’évaluateur
sait par ailleurs que 11 % des documents sont à vérifier.
5.2.3.2
Coefficient Kappa simple
C’est certainement la mesure la plus utilisée en traitement automatique des langues
pour quantifier l’accord entre deux juges. Il se définit, pour r modalités de jugement et
un échantillon de N jugements [Cohen, 1960] comme suit (nii correspondant au nombre
de jugements de valeur i donné par les deux juges) :
κ=
Où :
Po =
Et :
Po − Pe
1 − Pe
(5.6)
r
1 X
nii
N i=1
r
1 X
ni. ∗ n.i
Pe = 2
N i=1
En d’autres termes, le test de Kappa exprime une différence relative entre la proportion
d’accord observée Po et la proportion d’accord aléatoire Pe divisée par la quantité disponible au-delà de l’accord aléatoire. C’est-à-dire que le test de Kappa prend en compte
120
l’effet du hasard pour ajuster l’accord maximum entre deux juges s’ils avaient agi de
manière aléatoire.
La valeur minimale du coefficient Kappa est de -1, lorsque le désaccord est total entre
les juges (Po = 0 et Pe = 0,5). Sa valeur maximale est de 1, lorsque l’accord est total entre
les juges (Po = 1 et Pe = 0,5). Une valeur de 0 signifie l’indépendance des jugements (Po
= Pe ), autrement dit que le seul lien entre les jugements est dû au hasard.
[Landis et Koch, 1977b] ont fourni un classement pour interpréter les valeurs du coefficient Kappa (tableau 5.3) :
Kappa
Interprétation
0,81 – 1,00 Accord quasi-parfait
0,61 – 0,80
Accord important
0,41 – 0,60
Accord moyen
0,21 – 0,40
Accord juste
0 – 0,20
Accord faible
<0
Aucun accord
Table 5.3 – Interprétation des valeurs du coefficient Kappa.
Même s’il est communément admis et utile pour la compréhension du coefficient
Kappa, ce classement possède quelque défauts. Ainsi, l’interprétation du coefficient Kappa
est avant tout celle que l’évaluateur en fait. Les valeurs négatives sont toutes considérées
comme un accord nul : on peut pourtant parler de désaccord plus ou moins faible, même
s’il intéresse moins l’évaluateur (à partir du moment où il n’y a pas d’accord, les résultats de l’évaluation sont déjà discutables). De plus, l’échelle linéaire (une interprétation
représente 20 points de coefficient Kappa) est issue d’expérimentations et non de calculs
formels.
En reprenant l’exemple précédent d’Infile (tableau 5.2), nous calculons le coefficient
Kappa simple :
Po =
Et :
Pe =
1
(347 + 192) = 0, 887
608
1
(365 ∗ 398 + 243 ∗ 210) = 0, 531
6082
Soit :
κ=
0, 887 − 0, 531
≈ 0, 759
1 − 0, 531
D’après le tableau 5.3, l’accord est important entre les juges, ce qui confirme la bonne
tenue des évaluations estimées lors du calcul de l’accord inter-juges. Bien que le coefficient
Kappa paraisse plus faible que l’accord inter-juges, les deux valeurs restent proche si l’on
rapporte le premier à l’échelle du deuxième ( c’est à dire 88 % pour le Kappa, contre 89 %
pour l’accord inter-juges).
Toutefois, [Feinstein et Cicchetti, 1990] ont présenté les limites du coefficient Kappa,
dont les valeurs sont faibles, alors que l’accord est tout de même important. De plus, à
notre sens, deux juges ayant des résultats proches, mais différents, sont trop pénalisés si
121
l’on compare à deux juges ayant des résultats bien distincts : la proximité des jugements
n’est pas considérée par le coefficient Kappa qui agira de la même manière dans l’un
et l’autre des cas. On retrouve ce cas en traduction automatique, où bien souvent les
jugements humains sont, sur une échelle de 5 valeurs, proches mais différents.
Un dernier cas problématique concerne les erreurs systématiques entre juges (et un
déséquilibre entre les désaccords) amenant à un coefficient plus élevé puisque Pe serait
alors plus faible. Les tableaux 5.4 et 5.5 fournissent deux exemples pour comparer d’une
part des résultats avec des désaccords équilibrés entre les juges et d’autre part des résultats
avec des désaccords déséquilibrés entre les juges.
Juge 1
Pertinent
Non pertinent
Total
Juge 2
40
20
20
20
60
40
Total
60
40
100
Table 5.4 – Exemple de résultats avec des désaccords équilibrés.
Juge 1
Pertinent
Non pertinent
Total
Juge 2
40
35
5
20
45
55
Total
75
25
100
Table 5.5 – Exemple de résultats avec des désaccords déséquilibrés.
Si l’on compare les tableaux 5.4 et 5.5, on s’aperçoit que la taille de l’échantillon en
désaccord est la même, mais elle n’est pas équilibrée de la même manière dans les deux
cas. Bien que les effectifs en désaccord soient du même nombre, 40 dans les deux cas, les
deux coefficients Kappa sont différents, respectivement de 0,167 (Po =0,600 et Pe = 0,520)
et de 0,238 (Po = 0,600 et Pe = 0,475). Les différences récurrentes entre juges amènent
donc à des valeurs Kappa plus élevées.
5.2.3.3
Coefficient Kappa global
Une autre limite du coefficient de Kappa simple est l’impossibilité d’estimer un
« Kappa global », lorsque plus de deux juges ont effectué des jugements sur un même
échantillon. L’intérêt du Kappa global est de déterminer l’accord sur l’ensemble des juges,
plutôt que d’agir par couple de juges. Un désaccord global amène ensuite à une étude plus
profonde pour cibler les juges en réel désaccord.
[Landis et Koch, 1977b] ont ainsi défini le coefficient Kappa global qui permet de mesurer l’accord entre n juges pour r critères de jugements en prenant en compte la chance
que les juges donnent le même jugement sur un même segment :
κg =
Po − Pe
1 − Pe
122
Où :
Et :
N
r
X
1 X
1
Po =
nij (nij − 1)
N i=1 n(n − 1) j=1
N
r
X
1 X
nij )2
Pe =
(
Nn i=1
j=1
Le nombre de juges évaluant le ie échantillon selon le j e critère est représenté
par nij . Le problème principal réside dans la comparaison exacte des jugements
[Feinstein et Cicchetti, 1990].
Nous prenons comme exemple les données des deux campagnes CESTA en traduction automatique de l’anglais vers le français, pour les évaluations humaines de fluidité
et d’adéquation. Pour la première campagne d’évaluation, 112 juges ont évalué 3 950
segments (deux fois), soit environ 71 segments par juge. Pour la seconde campagne d’évaluation, 48 juges ont évalué 3 456 segments (deux fois), soit environ 72 segments par juge.
Le nombre d’évaluations effectuées par juge était similaire d’une campagne à l’autre. Les
valeurs des coefficients Kappa global sont présentées dans le tableau 5.6.
Évaluation
Campagne 1
Campagne 2
Fluidité
Adéquation
Fluidité
Adéquation
Po
0,394
0,364
0,516
0,566
Pe
0,233
0,215
0,267
0,280
κg
0,210
0,189
0,340
0,398
Table 5.6 – Coefficients Kappa global κg [0-1] pour les évaluations en fluidité et adéquation des deux campagnes d’évaluation CESTA.
Les résultats montrent un accord assez faible entre les juges. Ici, les faibles valeurs
obtenues nous paraissent être plus dues à un manque de flexibilité du coefficient Kappa
et à la comparaison binaire des jugements, plutôt qu’à une mauvaise compréhension de
la tâche de la part des juges.
5.2.3.4
Accord inter-juges relatif (ou n-agreement)
Nos précédentes conclusions sur le coefficient Kappa global nous amènent à penser
qu’il est nécessaire d’adopter une certaine flexibilité dans l’accord inter-juges en ajustant
la proximité des jugements.
Plutôt que de calculer un accord inter-juges strict s’appuyant sur un accord binaire
(pour lequel deux évaluateurs sont en accord ou en désaccord sur le jugement d’un même
segment 1 ), nous choisissons de mesurer un accord inter-juges relatif, ou n-agreement,
pour lequel n est la différence entre la valeur de deux jugements sur un même segment
[Hamon et al., 2008a].
1. Ici, nous basons notre propos sur la notion de segment, car nos illustrations sont prises à partir
d’exemples de traduction automatique : les entités minimales sont différentes pour d’autres domaines,
telles que des termes en extraction terminologique, des réponses en question-réponse, des documents en
veille technologique, etc.
123
Pour N segments, le n-agreement se définit comme :
où :
N
1 X
δ(|Sia − Sib | ≤ n)
n − agreement(n) =
N i=1
δ(|Sia
−
Sib |
≤ n) =
(5.7)
1 if |Sia − Sib | ≤ n
0 if |Sia − Sib | > n
Autrement dit, le n-agreement calcule le ratio du nombre de segments pour lesquels la
valeur absolue de la différence entre le premier jugement d’un segment S, Sia , et son second
jugement, Sib , est inférieure ou égale à n. La valeur maximale est de 1, lorsque tous les
juges sont d’accord entre eux à n près, la valeur minimale est de 0, lorsque tous les juges
sont en désaccord entre eux à n près. Si n = 0, alors le n-agreement se rapporte à l’accord
inter-juges simple. Même si l’accord relatif permet d’affiner l’observation de l’accord interjuges, son défaut majeur réside dans sa limitation à deux jugements comparés 1 .
Comme précédemment, nous prenons comme exemple les deux campagnes CESTA en
traduction automatique. Les résultats pour la fluidité et l’adéquation du n-agreement sont
présentés dans le tableau 5.7.
Évaluation
Fluidité
Adéquation
Fluidité
Campagne 2
Adéquation
Campagne 1
0
0,39
0,36
0,41
0,47
n-agreement
1
2
3
0,84 0,97
1
0,76 0,93 0,99
0,78 0,94 0,99
0,80 0,93 0,99
4
1
1
1
1
Table 5.7 – n-agreement [0-1] pour les deux campagnes d’évaluation CESTA.
Les juges ont donné des scores strictement identiques pour environ 40 % des segments :
cela nous semble refléter la subjectivité des jugements humains, car les juges ont plus
tendance à être en désaccord qu’en accord 2 .
Toutefois, lorsque n > 0, le n-agreement donne une bien meilleure idée de l’accord
entre juges. L’évaluation nous paraît alors plus fiable et les jugements plus stables entre
les différents juges, contrairement à ce que l’on pourrait penser avec un simple accord
inter-juges. La tendance est similaire pour les résultats des deux campagnes d’évaluation,
bien que les données soient différentes dans les domaines et les lexiques employés.
La perception de ce qu’est une « bonne » traduction est différente d’un juge à l’autre,
expert ou utilisateur, et, par conséquent, nous sommes convaincu qu’il n’est pas concevable
d’atteindre un 0-agreement de 100 %. C’est à l’évaluateur de pallier cette réalité des
jugements humains en associant les résultats des évaluations aux accords inter-juges. Mais
un accord binaire n’est pas la bonne solution, comme dans notre cas présenté ci-dessus :
1. Toutefois, on pourrait très bien concevoir un n-agreement global de la même manière qu’il existe
un Kappa global.
2. Au passage, nous remarquons que, contrairement à ce que l’on pourrait penser, il n’y a pas de
critère d’évaluation plus subjectif qu’un autre : l’adéquation n’est a priori pas plus difficile à évaluer que
la fluidité, tout du moins les divergences entre juges ne sont pas très importantes.
124
il est parfois nécessaire de nuancer les différences entre juges. Avec les résultats de ces
deux campagnes, les juges sont à première vue en désaccord, ils ont très souvent la même
opinion sur la qualité d’un segment sans qu’elle soit strictement identique. Montrer un
1-agreement supérieur à 80 % nous semble plus significatif, notamment dans les cas où
la part de subjectivité est importante, que de montrer un accord strictement inférieur à
40 %. De même, dire que le 2-agreement est supérieur à 90 % nous permet de préciser
que les évaluations données sont dans la même zone de valeurs.
Pour aller plus loin, nous cherchons à comparer les résultats du n-agreement à ceux du
coefficient Kappa global présentés dans le tableau 5.6. Le point majeur reste le manque
de flexibilité du coefficient Kappa global : si le 0-agreement (l’accord inter-juges simple)
permet d’interpréter les résultats de la même manière que le Kappa global (un accord
relativement faible), le 1-agreement et les n-agreement successifs apportent plus d’information quant à la proximité des juges sur leurs jugements de qualité. Le Kappa global
nous paraît alors être dédié à des tâches moins subjectives, pour lesquelles les juges n’ont
pas à hésiter sur leur propre jugement.
Les mêmes expérimentations dans le cadre du projet TC-STAR [Hamon et al., 2008a]
nous ont amené aux mêmes conclusions, sur différents types de données et domaines.
5.2.3.5
Accord intra-juge
L’accord intra-juge mesure la cohérence intrinsèque d’un juge que ce soit au cours du
temps ou lors d’une même évaluation. Typiquement, l’accord intra-juge se mesure en deux
temps : le juge effectue tout d’abord ses jugements sur des échantillons, puis un certain laps
de temps (à définir, selon la tâche) est laissé et le juge effectue à nouveau ses jugements
sur les mêmes échantillons. Toute la problématique de la méthode réside dans le temps
laissé entre les deux jugements : plus la durée est courte, plus le calcul de l’accord est
biaisé car le juge a plus de chance de se souvenir, inconsciemment ou non, des jugements
précédemment effectués. À l’inverse, plus la durée est longue, plus il y a de chance que
la manière de penser soit modifiée radicalement. D’un point de vue plus pratique, le juge
peut ne plus être disponible après une certaine durée. Il faut donc allier intérêt scientifique
et difficultés pratiques pour calculer un accord intra-juge. Parallèlement à ces aspects, le
juge ne doit pas avoir conscience de refaire le même travail, ce qui est particulièrement
complexe à mettre en place : même après un long laps de temps, notre expérience en
traduction automatique montre que les juges arrivent à se souvenir de certains segments
évalués. Reste à savoir si les jugements sont effectués de la même manière et à identifier
les difficultés rencontrées par les juges.
En ce qui concerne la mesure de l’accord intra-juge, elle se fait de la même manière que
pour l’accord inter-juges en ne considérant qu’un seul juge effectuant les mêmes jugements.
On se trouve donc dans un cas particulier d’accord inter-juges simple, de coefficient Kappa,
d’accord inter-juges relatif, etc.
Nous prenons comme cas d’étude l’observation de juges dans le cadre du projet
CESTA.
Dans [Callison-Burch et al., 2007], les auteurs utilisent 10 % du jeu d’évaluation d’un
juge, évalué deux fois par le même juge, au cours d’une même session. Nous estimons le
délai insuffisant pour que le juge ne soit pas influencé par ses jugements précédents. Tout
au plus, cette méthode permet de vérifier l’attention du juge, et non la cohérence de ses
jugements.
125
Dans le cadre de CESTA, nous avons demandé à plusieurs juges de répéter leurs
évaluations, sans qu’ils le sachent, après un délai se situant entre quatre et douze mois selon
les évaluations. Pour ce faire nous avons utilisé les données des deux campagnes du projet
CESTA. Malheureusement, l’étude pêche par le nombre de juges, puisque seulement trois
juges ont pu reproduire leurs deux évaluations (seuls quatre de l’ensemble des juges étaient
communs aux deux évaluations). Les résultats nous donnent toutefois des indications sur
l’accord intra-juge du projet. L’objectif est double : nous voulons tout d’abord observer
l’accord intra-juge de manière stricte avec les résultats de la seconde campagne, mais nous
voulons également tester l’impact de l’interface d’évaluation sur les jugements, avec les
résultats de la première campagne. En effet, deux interfaces étaient disponibles : celle de
la première campagne d’évaluation et celle de la seconde campagne d’évaluation qui est
une modification de la première. Elle diffère de deux manières : les jugements de fluidité
et d’adéquation sont effectués de manière distincte, et l’échelle de 5 valeurs de jugements
n’est nominative que pour les bornes supérieures et inférieures plutôt que pour chaque
valeur.
Compte tenu du nombre de juges, nous avons tout d’abord testé la représentativité
des trois juges sélectionnés (nommés par la suite « Juge A », « Juge B » et « Juge C ») en
observant la corrélation de Pearson de leurs propres résultats, système par système, avec
les résultats officiels. Seuls les résultats de fluidité du Juge B pour la première campagne
d’évaluation présentent une corrélation faible de 60 %. Le reste des résultats montre des
corrélations au-dessus de 80 %, et plus généralement au-dessus de 90 %. Tout en prenant
les résultats suivants avec beaucoup de précautions, nous avons considéré les trois juges
comme étant représentatifs.
Les évaluations ont été croisées afin d’observer les différences de jugements, et selon
le protocole suivant :
– les juges mènent une première évaluation pendant la première campagne en utilisant
la première interface d’évaluation ;
– les juges mènent une première évaluation pendant la seconde campagne en utilisant
la seconde interface d’évaluation ;
– un délai de quelques mois est laissé après les deux évaluations ;
– les juges évaluent à nouveau les données de la première campagne en utilisant la
seconde interface d’évaluation ;
– les juges évaluent à nouveau les données de la seconde campagne en utilisant la
seconde interface d’évaluation.
Ainsi, la double évaluation de la seconde campagne nous permet de calculer un accord
intra-juge et d’observer les différences de jugement pour un même juge. La double évaluation de la première campagne en utilisant une interface différente nous permet, elle,
d’observer l’influence de l’interface d’évaluation sur les jugements.
Nous calculons ensuite les corrélations entre les premières et secondes évaluations à
l’aide du score des systèmes (tableau 5.8) et de leur rang (tableau 5.9).
En ne prenant en compte que les résultats de la seconde campagne afin de n’observer
que l’accord intra-juge, les corrélations sont hautes, comprises entre 90 % et 99 %. Toutefois, elles indiquent que les juges varient leurs jugements au cours du temps. Le défaut
du calcul de corrélation étant de ne pas voir les dégradations ou les améliorations des
valeurs, nous avons observé les scores des systèmes évalués. Au final, ces scores diffèrent
en moyenne et de manière absolue entre 0,08 et 0,42 point (sur 4 points au maximum)
126
Juges
Juge A
Juge B
Juge C
Campagne 1
Fluidité Adéquation
0,47
0,63
0,96
0,66
0,98
0,62
Campagne 2
0,96
0,99
0,97
0,92
0,90
0,89
Table 5.8 – Accord intra-juge [0-1] pour les deux campagnes, mesuré à partir du score
des systèmes.
Juges
Juge A
Juge B
Juge C
Campagne 1
0,60
0,60
0,90
0,50
1
0,50
Campagne 2
0,92
1
0,95
0,98
0,92
0,89
Table 5.9 – Accord intra-juge [0-1] pour les deux campagnes, mesuré en fonction du rang
des systèmes.
que ce soit pour la fluidité ou l’adéquation. Cela représente une variation relativement importante, la différence maximale trouvée sur un système étant de 1,08 point. La tendance
des scores est à la baisse lors de la seconde évaluation, en particulier pour l’adéquation.
L’expérience des juges joue probablement un rôle ici, d’autant plus que les juges nous ont
fait part de leur souvenir d’avoir déjà jugé telle ou telle phrase, sans toutefois se souvenir
du jugement donné.
Concernant les corrélations sur le rangs des systèmes, elles sont toujours très proches de
100 % pour la seconde campagne d’évaluation (les deux évaluations se sont alors déroulées
dans le même contexte). Lorsque variation il y a, elle est souvent due à l’inversion de deux
systèmes ou à l’égalité entre deux systèmes lorsque leur qualité est très proche.
Nous avons ensuite calculé l’accord relatif sur les résultats de la seconde campagne
entre les jugements des deux évaluations (tableau 5.10). De cette manière, nous affinons
les observations sur chacun des juges.
Évaluation
Fluidité
Adéquation
Juge
Juge
Juge
Juge
Juge
Juge
A
B
C
A
B
C
0
0,44
0,44
0,47
0,63
0,43
0,56
n-agreement
1
2
3
0,88 0,99
1
0,74 0,86 0,96
0,86
1
1
0,93
1
1
0,74 0,88
1
0,97
1
1
Table 5.10 – Accord relatif intra-juge [0-1] pour la seconde campagne d’évaluation.
Comme auparavant, si l’on excepte n=0, les accords sont très hauts, plus que pour
l’accord inter-juge. Plus de la moitié des jugements ne sont pas identiques mais les résultats
127
sont tout de même très proches. Même si le juge B (le juge le moins représentatif) semble
être en décalage avec les deux autres juges, d’une manière générale le maximum est presque
atteint pour n=2, tandis qu’il faut attendre n=3 pour l’accord inter-juge. De la même
façon que nous l’avons observé pour l’accord inter-juge, il semble plus difficile de conserver
les mêmes jugements pour la fluidité que pour l’adéquation. L’explication nous semble être
la même : l’absence de référence.
Finalement, un dernier point nous paraît intéressant à observer, même si le contexte
(seulement trois juges étudiés) limite nos conclusions : l’impact de l’interface sur les résultats et la corrélation intra-juge. Pour les évaluations concernant la première campagne
d’évaluation, deux paramètres ont été modifiés : la fluidité et l’adéquation sont évaluées
indépendamment et l’échelle de 5 valeurs n’est nominative que pour les extrêmes. Le fait
de changer deux paramètres à la fois peut être discutable (sauf à considérer le changement
dans sa globalité), alors nous supposons que :
– Modifier l’ordre d’évaluation n’affecte que les jugements pour la mesure d’adéquation : dans la première évaluation, le juge porte son attention sur deux critères à la
fois, toujours en commençant par la fluidité ; dans la seconde évaluation, le juge se
focalise sur un critère, mais les jugements d’adéquation ne sont plus influencés par
ceux de fluidité ;
– Modifier la définition de l’échelle de valeurs devrait affecter à la fois l’adéquation et
la fluidité, puisque les deux échelles des critères sont modifiées de la même manière.
Ainsi, nous supposons que l’adéquation sera plus affectée par les modifications que la
fluidité. En observant les tableaux 5.8 et 5.9, les corrélations permettent de comparer des
évaluations entre celles utilisant une interface modifiée (campagne 1) et celles utilisant
une interface qui ne l’est pas (campagne 2). Nous observons que les corrélations sur l’adéquation de la première campagne sont plus basses pour les trois juges, tandis qu’un seul
juge obtient une plus basse corrélation pour la fluidité. Dans un même temps, toutes les
corrélations sont très hautes pour la seconde campagne.
À première vue, modifier l’interface influence le jugement des critères de fluidité et
d’adéquation. Les changements pour l’adéquation sont plus prononcés que ceux de la
fluidité. Sans savoir quelle interface est la plus pertinente, nous aurons tendance à penser
que l’ordre d’affichage des critères affecte beaucoup les jugements d’adéquation, tandis que
l’échelle de valeurs ne l’affecte que très peu. Même s’il ne s’agit que d’une supposition,
ces résultats nous amènent toutefois à confirmer que les modifications d’une interface
d’évaluation, même mineures, affectent les résultats de l’évaluation.
5.2.3.6
Du double intérêt des calculs d’accord
Mise à part l’observation du comportement des juges, les accords inter-juges, ou intrajuges fournissent un diagnostic des problèmes relatifs à l’évaluation humaine : mauvaise
compréhension des spécifications, problème dans les données, etc. Un mauvais accord peut
aussi signifier que la tâche est mal définie, ou que les juges ont des difficultés avec celle-ci.
Avant toute chose, il est d’usage de ne pas dire aux juges qu’un accord est calculé à
partir de leurs jugements. Se savoir comparé influe logiquement sur le comportement d’un
juge, d’autant plus si les juges se connaissent entre eux. Une réaction d’adaptation a lieu,
un juge pensant, inconsciemment ou non, à ce que va juger « l’autre » qu’à prendre en
compte son jugement propre. L’évaluation s’en trouve alors biaisée et l’on s’éloigne d’un
scénario « proche de l’utilisateur ».
128
Nous l’avons vu au cours des descriptions des différentes mesures d’accord, il n’y a
pas de mesure « parfaite ». Chaque mesure est plus ou moins adaptée à un problème, il
convient de l’interpréter en fonction du contexte précis de son utilisation.
De plus, l’analyse des accords entre juges affine ou nuance les résultats des systèmes
en replaçant les scores obtenus dans le contexte des jugements effectués. Par exemple, des
systèmes ayant des résultats distincts, mais dans le cadre d’une évaluation où les juges
sont en profond désaccord relativise l’écart entre les systèmes ; à l’inverse, des systèmes
ayant des résultats très proches, évalués par des juges en accord parfait donne la certitude
du classement des systèmes. Le tout réside dans la nuance dans les résultats selon le
comportement des juges.
5.2.3.7
Vote majoritaire
Même si le vote majoritaire n’agit pas exactement comme une validation de mesure
d’évaluation humaine, il lisse les résultats d’une évaluation. Pour ce faire, il nécessite un
nombre impair de juges pour chaque jugement, supérieur ou égal à trois. Cela permet
de décider de la valeur définitive d’un jugement, si par hasard un des juges a agi de
manière plus arbitraire ou s’il existe un désaccord non soluble entre juges. De plus, par un
calcul typique d’accord entre juges, l’évaluateur peut observer les points litigieux d’une
évaluation.
Lors du projet Infile (cf. section 5.2.3.1), les documents litigieux, pour lesquels les
deux juges étaient en désaccord, ont été jugés par un troisième juge. Ce dernier a donc
été en quelque sorte « l’arbitre » entre les deux premiers juges. Sur les 69 documents ne
concordant pas, 37 ont été jugés pertinents, 32 non pertinents par ce troisième juge. Cela
nous a alors donné un taux de pertinence des documents jugés de 63 %, tandis qu’il aurait
été de 64 % si les documents litigieux avaient été supprimés (avec une variation allant de
60 % à 65 % selon qu’on eût fait confiance à l’un ou l’autre des deux premiers juges).
Cela nous donne aussi la possibilité de voir si l’un des deux juges fournit des jugements plus arbitraires que l’autre. En l’occurrence, les deux juges étaient au même niveau,
puisque le troisième juge a confirmé 34 des documents pour le premier juge, et 35 pour le
second (soit une répartition de 50 % 1 ).
5.2.4
Identification de juges « problématiques »
Comme nous l’avons déjà mentionné, l’important lors d’une évaluation humaine est
d’analyser l’accord inter-juges. Cette analyse permet d’une part d’estimer la subjectivité et la fiabilité des jugements et d’autre part d’aider l’évaluateur à identifier les juges
problématiques (outliers). Nous définissons ces juges problématiques comme étant trop
divergents par rapport aux autres juges. Cela ne signifie pas nécessairement que leurs
jugements sont erronés, ils peuvent avoir une opinion de l’utilisation d’un système très
distincte des autres juges. Nous justifions cette identification par la gêne que peut causer
une diversité trop grande dans les jugements pour l’analyse des résultats. Quand bien
même l’évaluateur cherche à disposer d’un panel de juges afin de réduire la subjectivité,
1. Il faut toutefois noter que ce taux de 50 % pourrait parfaitement signifier que le troisième juge a
jugé les documents litigieux de manière totalement hasardeuse. D’autres jugements ont été faits par ce
même juge qui laissent penser que ce n’est pas le cas.
129
il n’a pas besoin de données perturbant la « pensée commune » : le but de la plupart des
évaluations est d’obtenir une idée moyenne de la qualité d’un système et non de savoir
si un juge en particulier a un point de vue radicalement différent. Ainsi, nous acceptons
une frange de diversité acceptable, mais sans qu’il y ait aberration dans les résultats. Cela
peut amener à éliminer les juges pour les remplacer ou réduire l’échantillon évalué en le
rendant plus objectif et précis, et ainsi affiner l’analyse. Identifier les juges problématiques
revient aussi à catégoriser les juges afin d’observer leurs résultats plus en détail.
Lorsque des jugements sont effectués, il n’est pas facile de savoir s’ils ont été effectués
de manière correcte ou non. C’est particulièrement le cas si les juges ne sont pas des
experts ou que leur nombre est grand. Les juges font la plupart du temps un travail très
contraignant et l’évaluateur ne s’aperçoit pas toujours des difficultés liées à leur tâche.
Un travail répétitif sur plusieurs heures n’est pas toujours homogène.
Nous distinguons trois méthodes principales pour identifier les juges problématiques :
– calculer la moyenne d’un juge sur un échantillon et la comparer à celle des autres
juges sur un même échantillon ;
– calculer l’accord moyen d’un juge par rapport aux autres juges sur un même échantillon ;
– placer des « pièges » dans l’évaluation, comme insérer des répétitions dans l’échantillon (pareil à une intra-évaluation, section 5.2.3.5), ajouter des portions d’échantillons « faciles » pour observer facilement des résultats aberrants, etc.
Si les deux premières méthodes calculent une distance sur les jugements entre juges,
la troisième utilise des données linguistiques plus concrètement. Pour chaque méthode,
un seuil de tolérance est défini afin de distinguer les juges les plus divergents. De manière
évidente, moins il y aura de juges, moins les deux premières méthodes seront utilisables.
À la suite de notre étude sur l’accord inter-juges relatif et le coefficient Kappa global,
nous avons utilisé les résultats afin d’identifier les juges problématiques sur les données
des projets TC-STAR et CESTA. En effet, les résultats obtenus nous amènent à nous
demander si les juges étaient fiables ou non : certains d’entres eux ont pu se tromper en ne
comprenant pas la tâche ou, plus problématique, en ne faisant pas les jugements de manière
sérieuse. Plusieurs aspects d’une évaluation entravent la bonne conduite des jugements
humains : tâche mal définie ou non explicite, fatigue, perturbations extérieures, etc. Nous
nous ne cherchons pas ici à accabler tel ou tel juge, mais plutôt à comprendre pourquoi
des résultats d’un juge auraient tendance à diverger de ceux d’autres juges.
Nous détaillons ci-dessous les expérimentations et résultats obtenus lors de la seconde
campagne TC-STAR d’évaluation [Hamon et al., 2008a]. L’évaluation portait sur des systèmes de traduction automatique pour la direction allant de l’anglais vers l’espagnol.
5.2.4.1
Score moyen par juge
Chacun des 125 juges évalue un sous-ensemble d’environ 163 segments, construit de
manière aléatoire parmi 10 180 segments afin d’être le plus représentatif du corpus évalué. Chaque segment est évalué par deux juges différents, selon les critères de fluidité et
d’adéquation sur une échelle de 5 points. De cette manière, il est possible de calculer un
score moyen pour chaque juge sur son sous-ensemble de segments, et de le comparer avec
le score moyen obtenu sur le même sous-ensemble pour tous les autres juges.
Les figures 5.4 et 5.5 montrent les scores moyens par juge obtenus pour les mesures
de fluidité et d’adéquation. Les juges sont présentés en abscisse selon leur score moyen
130
croissant et ainsi classés du plus bas score moyen au plus haut.
Figure 5.4 – Score moyen par juge pour les jugements de fluidité et score moyen pour
les jugements correspondants provenant des autres juges.
Figure 5.5 – Score moyen par juge pour les jugements d’adéquation et score moyen pour
les jugements correspondants provenant des autres juges.
La variation des scores moyens est similaire pour les deux mesures : le score de chaque
sous-ensemble pour tous les autres juges (courbe pleine oscillant) est très proche du score
global de l’ensemble des segments (droite pointillée). Nous estimons que cela traduit
la représentativité des sous-ensembles par rapport à l’ensemble des jugements. Elle est
nécessaire pour pouvoir comparer les juges entre eux. Plus surprenant, le score moyen par
juge (courbe pointillée) varie beaucoup selon les juges, certains juges ayant de très basses
ou très hautes moyennes comparées à celles des autres juges sur le même échantillon.
Nos explications sont diverses : les juges peuvent avoir mal compris l’échelle de 5
points proposée, ne pas avoir fait assez attention à l’évaluation, ou avoir été trop – ou
131
trop peu – stricts. Les juges divergents, ici présentés au dessus et en dessous de l’écart type
(droites pointillées), pourraient parfaitement être supprimés des calculs afin d’homogénéiser les jugements. L’évaluateur pourrait aussi leur redemander de produire de nouveaux
jugements.
Cette méthode a pour avantage de comparer les scores moyens de chaque juge par
rapport aux scores moyens des sous-ensembles de segments respectifs et ainsi d’observer
la divergence des juges. Toutefois, il s’agit d’un score moyen et le score moyen d’un juge
donné peut être proche du score moyen du reste des autres juges, avec des scores sur les
segments pris un à un très divergents : tous les juges problématiques ne sont pas forcément
détectés par cette méthode.
5.2.4.2
Accord moyen par juge
Chaque segment évalué par un juge est comparé à celui évalué par un autre juge. Pour
un même juge, la distance moyenne est calculée entre tous les jugements de ses segments
et les seconds jugements provenant des autres juges. De ce calcul résulte un accord interjuges moyen pour un juge donné avec l’ensemble des autres juges. Les figures 5.6 et 5.7
montrent les résultats sur chacun des juges, obtenus de manière à présenter les juges par
accord croissant.
Figure 5.6 – Accord moyen par juge pour les jugements de fluidité.
Les courbes de fluidité et d’adéquation augmentent de la même manière que pour le
score moyen, bien que la courbe pour l’adéquation augmente plus rapidement, lorsque
l’accord est plus important. Pour certains juges, l’accord moyen est au-dessus de 1,5
points, ce qui est relativement important compte tenu d’une distance maximale de 4
points. Autrement dit, certains juges sont en désaccord avec les autres juges de 1,5 points
en moyenne : sans pour autant déclarer que leurs jugements sont erronés, nous observons
qu’ils ont été effectués d’une manière plus sévère et stricte que d’autres.
132
Figure 5.7 – Accord moyen par juge pour les jugements d’adéquation.
5.2.4.3
Segments simples et pièges
La plupart des évaluations contiennent des parties plus « simples » que d’autres.
C’est souvent le cas en traduction automatique. La simplicité d’un jugement se situe
dans la longueur de ces phrases, mais aussi correspond à un lexique moins étoffé, une
structure syntaxique moins élaborée, etc. De cette manière, il nous est possible d’observer
les jugements et de les valider ou non en ne retenant que ces segments simples. Ils ne posent
pas de problèmes aux systèmes de traduction automatique. Ainsi, une grande majorité des
segments sélectionnés doit atteindre la valeur maximale lors des évaluations humaines (ce
qui simplifie d’autant plus cette « validation sur jugements simples »). Par conséquent,
un de ces segments ayant reçu une valeur plus faible de la part d’un juge est analysé plus
finement afin de savoir dans un premier temps si le système a correctement traduit, puis
de déterminer si le juge s’est trompé dans son jugement ou non dans un second temps.
Par exemple, les segments simples sont décrits comme contenant peu de mots, tel que
le segment gracias (merci ). Un autre critère concerne la répétition de segments dans le
jeu de test, comme les phrases ci-dessous.
¿ podría hacer más la Comisión ?
gracias , Presidente .
la respuesta es compleja .
gracias .
Dans les données de la seconde campagne TC-STAR, un total de 80 segments simples
ont été identifiés manuellement, nous permettant de déterminer si des juges ont effectué
des évaluations incohérentes. Suite à l’étude que nous avons faite, il apparaît que quelques
segments ne sont pas jugés correctement, ce qui ne signifie pas nécessairement que tous les
jugements des juges associés soient incorrects également : ces jugements restent localisés et
leur valeur peut être due à de multiples raisons telles que la fatigue, une baisse d’attention.
D’autres raisons peuvent être davantage liées à la tâche même qu’aux compétences du juge
en question.
133
L’étude des segments simples est coûteuse en temps et relativement complexe à mettre
en place. Pour cela, elle doit se faire au niveau du segment, manuellement, et dans notre
cas n’avoir que deux évaluations par segment ne nous a pas facilité les choses.
Il faut toutefois noter que le volume de ces segments (80 au total) n’est pas important.
Cela montre les limites de l’expérimentation, mais il faut reconnaître que la proportion
des segments se retrouve noyée dans la masse totale des segments jugés. Certains juges
ont toutefois tendance à juger de manière incorrecte un nombre plus significatif de ces
segments.
Ainsi, nous avons défini une troisième méthode pour identifier des juges problématiques. Elle est relativement coûteuse à la base, mais permet d’identifier rapidement ces
juges par la suite. Sa fiabilité n’est pas pour autant meilleure : il arrive que des jugements
soient erronés ponctuellement par le simple fait que les juges ne sont pas toujours à 100 %
de leurs moyens. Toutefois, nous considérons que la méthode peut s’appliquer facilement
à d’autres évaluations, comme par exemple en ajoutant des termes évidents dans une terminologie, en plaçant des questions « faciles » en entrée d’un système de question-réponse
ou en ajoutant des références supposées recevoir les jugements les plus hauts.
5.2.4.4
Identification des juges divergents
Pour chacune des trois méthodes, l’écart-type nous permet d’observer la dispersion
statistique des juges par rapport à la moyenne générale. Nous choisissons de mettre de côté
les juges figurant au-dessus de l’écart-type positif (pour le score moyen et l’accord moyen)
et en-dessous (pour le score moyen) de l’écart-type négatif. Notre premier objectif est
bien sûr d’identifier les juges problématiques mais il s’agit aussi d’identifier une certaine
portion de juges divergents et ainsi d’homogénéiser l’évaluation vers des résultats plus
généraux en supprimant leurs jugements.
La suppression de certains juges fait courir le risque de réduire l’originalité des jugements. Cependant, dans ce type d’évaluation nous ne cherchons pas à identifier l’originalité, mais bien à obtenir une estimation moyenne de la qualité, telle qu’un utilisateur
moyen la percevrait.
A contrario, le fait de seulement isoler ou de mettre en évidence certains juges rend
l’analyse des jugements plus fine. Un diagnostic plus détaillé aide l’évaluateur à comprendre les raisons de leurs jugements.
Sur le même exemple, le tableau 5.11 permet de comparer le nombre de juges identifiés
pour chacune des trois méthodes en considérant les mesures de fluidité et d’adéquation,
ainsi qu’une combinaison des deux mesures d’évaluation.
Fluidité
Adéquation
Fluidité + adéquation
Score moyen
45
45
30
Accord moyen
23
18
10
Segments simples
9
10
4
Table 5.11 – Nombre de juges divergents identifiés pour chacune des méthodes de validation.
20 juges sont identifiés en combinant les méthodes de score moyen et d’accord moyen
pour la fluidité, tandis que 15 le sont pour l’adéquation. La plupart font partie de la
134
portion haute du score moyen (17 juges pour la fluidité, 5 pour l’adéquation), le reste de
la portion basse (respectivement 3 et 10 juges). Nous en concluons que si les juges sont
plus tolérants pour la fluidité, ils sont plus stricts pour l’adéquation. Ce comportement
s’explique dans la manière d’évaluer les segments. En effet, les juges n’ont que le segment à
évaluer de visible pour la fluidité, mais ils ont un segment de référence comme comparaison
pour l’adéquation.
De ce fait, les juges sont plus flexibles sans avoir de comparaison à faire, les possibilités
de jugements subjectifs sont plus nombreuses. En comparant le segment à une référence
pour l’adéquation, les juges ont tendance à vouloir apparier les deux segments, même
involontairement. Par ailleurs, ils ont aussi tendance, à juste titre, à tolérer des erreurs
syntaxiques dans une traduction plutôt que des erreurs qui modifient le sens du segment
d’origine.
La suppression des juges problématiques revient dans cet exemple à réduire d’un tiers
le nombre de juges pour le score moyen, à diviser leur nombre par 6 pour l’accord moyen,
ou encore à diviser par 13 pour les segments simples. Nous avons testé quelles seraient
les modifications sur les résultats des systèmes en les supprimant. Pour ce faire, nous
avons tout d’abord supprimé les juges, recalculé les scores, puis calculé une corrélation de
Pearson avant et après la suppression des juges (cf. section 5.4.2). Le tableau 5.12 présente
les résultats obtenus.
Fluidité
Adéquation
Score moyen [%]
98
99
Accord moyen [%]
99
100
Segments simples [%]
98
99
Table 5.12 – Corrélations de Pearson entre les scores originaux et les scores après suppression des juges problématiques.
Les corrélations de Spearman (cf. section 5.4.2) sur le classement des systèmes sont
au-dessus de 99 % pour chaque méthode. Les résultats obtenus sur le score moyen ne nous
surprennent pas vraiment : les juges qui ont les plus hauts et les plus bas scores ont été
supprimés, mais leurs résultats se complétaient dans les résultats avant suppression.
Les résultats sur l’accord moyen sont, eux, plus surprenants, les suppressions ne se
faisant que sur la fourchette haute des juges et les jugements étant en grand désaccord
avec ceux des autres juges.
En comparant les juges supprimés aux juges qui ne le sont pas, on s’aperçoit que les
scores moyens sont proches : 3,47 contre 3,24 pour la fluidité, 3,26 contre 3,91 pour l’adéquation. Les juges supprimés sont donc encore représentatifs du jeu d’évaluation dans son
ensemble, bien que certains d’entre eux puissent réellement être des juges problématiques.
Le fait de noyer ces derniers dans la masse des juges réduit la possibilité de biaiser les
résultats. Cela justifie d’autant plus d’avoir un grand panel de juges lors d’une évaluation.
Cela montre également qu’un désaccord important entre plusieurs juges ne signifie pas
nécessairement que leurs moyennes respectives ne sont pas similaires.
Les segments simples ne changent en rien les résultats, probablement du fait que peu
de juges ont été supprimés par rapport au nombre total de juges. Les jugements ne sont
pas réellement divergents et n’ajoutent pas plus d’informations dans ce cas précis.
Finalement, nous avons testé si les juges supprimés fournissent réellement des résultats
135
erronés suite à leur désaccord avec les autres juges conservés. Pour ce faire, nous avons
calculé la corrélation de Pearson entre les résultats officiels et les seuls résultats des juges
supprimés. Cela donne une corrélation de 84 % pour la mesure de fluidité et de 96 %
pour celle d’adéquation. Ces résultats ne montrent pas de différences importantes, mais
de petits écarts, plus faibles pour l’adéquation que pour la fluidité.
On s’aperçoit que, dans ce cas précis, conserver l’ensemble des juges affecte peu les
résultats, en particulier le classement des systèmes que ce soit pour la fluidité ou l’adéquation. Les scores sont pourtant, d’une manière générale, plus bas comme le montre la
figure 5.8.
Figure 5.8 – Résultats officiels des systèmes comparés aux résultats après suppression
des juges problématiques.
Les tests effectués pour l’identification des juges problématiques du projet CESTA
nous ont donné des résultats du même ordre.
5.2.5
Calcul et analyse des résultats de l’évaluation humaine
5.2.5.1
CESTA
Nous présentons les résultats humains des systèmes de la première campagne d’évaluation pour la direction de l’anglais vers le français dans le tableau 5.13.
Il présente la moyenne des scores obtenus sur les segments des systèmes, où 5 est le
score d’une traduction idéale. Les mesures d’accords nous ont permis de juger de la fiabilité
de ces scores. Les résultats des mesures de fiabilité obtenus par échantillonnage sur les
segments évalués conduisent à des écarts-type compris entre 0,03 et 0,09 pour la fluidité
et l’adéquation. Nous avons calculé des intervalles de confiance à partir des scores des
segments pour chaque système, sans passer par l’échantillonnage : ils sont compris entre
±0,05 et ±0,07 pour les différents scores et les différents systèmes. La même technique
136
Système
S1(en,1)
S2(en,1)
S3(en,1)
S4(en,1)
S5(en,1)
Fluidité
Score
Classement
2,41±0,05
5 (p=1)
3,04±0,06 1 (p=0,99)
3,01±0,06 2 (p=0,99)
2,67±0,06
4 (p=1)
2,84±0,07
3 (p=1)
Adéquation
Score
Classement
2,96±0,06
5 (p=1)
3,54±0,06
1 (p=1)
3,43±0,06
2 (p=1)
3,18±0,07 4 (p=0,89)
3,24±0,06 3 (p=0,89)
Table 5.13 – Résultats des jugements humains pour la première campagne : scores sur
une échelle de 1 à 5 (5 étant la meilleure note et 1 la moins bonne) avec leurs intervalles
de confiance, et classements avec leurs probabilités.
d’échantillonnage nous permet d’ailleurs de calculer la probabilité du classement observé
pour chaque système, qui est indiquée dans le même tableau 5.13 à partir des scores
moyens (l’utilisation des rangs moyens pour chaque échantillon réduit quelque peu cette
probabilité).
L’évaluation humaine indique donc avec une fiabilité suffisante le même classement
des systèmes selon la fluidité et l’adéquation de leurs traductions. Toutefois, nous constatons que les deux meilleurs systèmes, S2 et S3, paraissent impossibles à départager avec
certitude, car les intervalles de confiance à 95 % ont une intersection non nulle. De même,
S4 et S5 présentent une différence non significative de scores d’adéquation ainsi que des
scores de fluidité proches. Enfin, notons que l’adéquation est globalement plus élevée que
la fluidité pour la plupart des systèmes.
En recueillant les jugements humains, nous établissons dans un même temps des classements en fonction des juges. Chaque juge établit de fait son propre classement des
systèmes évalués, ce qui nous permet de calculer un rang moyen par système. Nous présentons les résultats dans le tableau 5.14 pour la mesure de fluidité et le tableau 5.15 pour
la mesure d’adéquation. Pour chaque système, nous fournissons le nombre de juges l’ayant
classé 1er, 2e, etc., son rang moyen et son classement final en fonction du rang moyen.
Système 1er
S2(en,1) 43
S3(en,1) 31
S5(en,1) 22
S4(en,1) 16
S1(en,1) 0
2e
36
44
17
11
4
3e
18
17
41
25
11
4e 5e Rang moyen
11 4
2,08
18 2
2,25
21 11
2,87
30 30
3,42
32 65
4,41
Classement
1
2
3
4
5
Table 5.14 – Rang moyen des systèmes en fonction des classements par juge pour la
mesure de fluidité de la première campagne.
Nous observons que les résultats sont plus nets pour la fluidité, car l’écart entre les
rangs moyens de chaque système est plus marqué. De plus, quel que soit le score ou le
rang moyen, les classements des systèmes sont identiques pour la fluidité et l’adéquation
de la première campagne.
Les performances de la seconde campagne ne sont présentées que pour les résultats des
137
Système 1er
S2(en,1) 42
S3(en,1) 29
S5(en,1) 19
S4(en,1) 17
S1(en,1) 5
2e
28
39
19
19
7
3e
21
23
25
18
25
4e 5e Rang moyen
16 5
2,23
13 8
2,39
26 23
3,13
28 30
3,31
29 46
3,93
Classement
1
2
3
4
5
Table 5.15 – Rang moyen des systèmes en fonction des classements par juge pour la
mesure d’adéquation de la première campagne.
systèmes adaptés (campagne 2b) dans le tableau 5.16, puisque les systèmes non adaptés
(campagne 2a) n’ont pas été évalués par des juges. Les moyennes des scores obtenus, avec
leurs intervalles de confiance calculés directement sur l’ensemble des segments traduits par
chaque système sont accompagnées des classements correspondants et de leurs probabilités
(ou fréquences) calculées également par échantillonnage.
Système
Fluidité
Score
Classement
S8(en,2b) 2,28±0,10
5 (p=1)
S9(en,2b) 3,19±0,11 3 (p=0,51)
S10(en,2b) 3,30±0,10 2 (p=0,95)
S11(en,2b) 3,19±0,10 3 (p=.51)
S12(en,2b) 3,57±0,09
1 (p=1)
Adéquation
Score
Classement
2,84±0,11
5 (p=1)
3,15±0,10
4 (p=1)
3,44±0,11 2 (p=0,88)
3,38±0,11 3 (p=0,88)
3,78±0,09
1 (p=1)
Table 5.16 – Résultats des jugements humains pour la seconde campagne après adaptation des systèmes au domaine : scores sur une échelle de 1 à 5 avec leurs intervalles de
confiance, et classements avec leurs probabilités.
On constate que les résultats les plus élevés sont obtenus par le système S12, alors que
les performances des systèmes S9, S10 et S11 sont très proches, parfois indiscernables, et
que le système S8 est loin derrière. Dans la plupart des cas, l’adéquation des traductions
est supérieure à leur fluidité.
Les juges ont aussi évalué (sans explicitement le savoir) la traduction officielle de
chaque segment (c’est-à-dire celle disponible sur le site d’origine) à des fins de comparaison
avec les résultats des systèmes. Pour la direction allant de l’anglais vers le français, la
traduction officielle a obtenu un score de fluidité de 4,55 et un score d’adéquation de
4,20. Le score maximal étant de 5, on constate que les valeurs de fluidité sont proches du
maximum, mais que l’adéquation se situe bien en dessous, avec des valeurs étonnamment
faibles pour une traduction humaine. Plusieurs explications peuvent être envisagées, sans
que l’on puisse les départager : sévérité des juges, compréhension trop littérale par les
juges de la notion d’adéquation, faible qualité intrinsèque des traductions officielles, ou
différences linguistiques entre les juges français et les traductions québécoises (provenant
du site de Santé Canada).
Les scores de fluidité et d’adéquation des traductions officielles sont toujours supérieurs
à ceux des meilleurs systèmes, bien que la distance ne soit pas toujours très grande. À
138
l’inverse des systèmes de traduction automatique, les traductions humaines reçoivent de
bien meilleures notes pour leur fluidité que pour leur adéquation, ce qui renforce peutêtre la deuxième hypothèse ci-dessus, celle d’une compréhension trop restrictive de la
notion d’adéquation. Cette différence peut être également due à la fréquence plus élevée
des reformulations dans les traductions humaines, alors que les systèmes traduisent plus
souvent en suivant l’ordre du texte.
5.2.5.2
CESART
Nous ne donnons ici que les résultats de la tâche T1, qui est la seule tâche à avoir
réellement donné lieu à une évaluation comparative, la tâche T3 n’ayant reçu la participation que d’un seul système. Les statistiques sur les sorties des systèmes sont présentées
dans le tableau 5.17 :
Système
Sys1
Sys2
Sys3
Sys4
Sys5
Santé Canada
Spirale
Candidats termes Avec variations Candidats termes Avec variations
26 053
37 936
3 447
4 609
108 074
168 484
60 695
67 944
286 018
286 022
41 377
41 377
10 000
11 620
10 000
10 000
50 848
50 848
–
–
Table 5.17 – Statistiques des candidats termes renvoyés par les systèmes pour la tâche
T1 de CESART et par corpus d’évaluation.
Si l’on excepte l’extracteur Sys4 (la limite inférieure du nombre de candidats termes
renvoyés demandée par les organisateurs était en fait de 10 000), on peut d’ores et déjà
observer la grande variabilité dans le volume des réponses des extracteurs. De plus, sur
les 5 extracteurs, deux ont réellement distingué les termes de leur variation, ce qui pose
la question de la légitimité d’une telle tâche, à savoir s’il faut mélanger l’évaluation de
l’extraction terminologique à celle concernant l’identification des variations ou s’il faut en
faire deux tâches bien distinctes [Nazarenko et al., 2009].
Après l’analyse des experts et l’appariement des candidats termes avec la liste de
termes de référence, les précisions sur les N premiers candidats termes sont calculées. La
mesure retenue repose sur la notion classique de précision, que nous pouvons considérer
comme étant :
Cscore=S
(5.8)
N
Où Cscore=S est le nombre de candidats termes corrects parmi les N premiers retournés
ayant un score égal à S
Les précisions sur les N premiers candidats termes retournés par les extracteurs sont
données pour N = {10, 100, 1000}, les experts ayant jugés les 1 000 premiers candidats
termes de chaque extracteur.
Un appariement automatique rudimentaire (c’est-à-dire une simple comparaison de
chaînes de caractères) ayant été fait pour aider les experts, nous dressons les résultats
P (N, S) =
139
automatiques (S = 4) des extracteurs en terme de précision, comme par exemple sur le
corpus de la santé (cf. tableau 5.18).
N
Sys1
10
0
100
15
1000
9
Max
3
Sys2
40
30
27
4
Sys3
1
12
6
1
Sys4
0
0
1
1
Sys5
20
20
14
14
Table 5.18 – Précision [%] des extracteurs sur le corpus de la santé d’après l’appariement automatique aidant les experts, sur les N premiers candidats termes renvoyés (Max
correspond à l’appariement sur l’ensemble des candidats termes renvoyés).
L’aide apportée par l’appariement automatique aux experts n’est pas négligeable. Il
permet de minimiser le coût d’évaluation en réduisant le nombre de candidats termes à
juger. Ce gain est allé de 1 % des candidats termes jusqu’à 27 % selon les systèmes (sur
les 1 000 premiers termes).
La mesure d’évaluation est établie à partir de la précision cumulée ces N premiers
candidats termes en considérant les différents critères d’évaluation décrits précédemment
et définie par :
4
X
(P (R, S))
P C(R, S) =
(5.9)
s=S
Ainsi les résultats de PC(R,4) proviennent des R premiers candidats termes ayant le
score 4, PC(R,3) de ceux ayant les scores 3 et 4, etc. Par exemple :
PC(R,3) = 20 % de P4 + 10 % de P3 = 30 %
PC(R,2) = 20 % de P4 + 10 % de P3 + 0 % de P2 = 30 %
PC(R,1) = 20 % de P4 + 10 % de P3 + 0 % de P2 + 30 % de P1 = 60 %
Le tableau 5.19 présente les résultats de l’évaluation humaine en prenant en compte
différentes variations de PC(R,S).
D’après les résultats, l’extracteur Sys4 est assez éloigné des autres extracteurs, qui
obtiennent des précisions cumulées relativement correctes bien qu’elles soient rarement
au dessus de 50 %. D’une manière générale, les résultats sont assez faibles lorsque S=4,
mais s’améliorent de manière conséquente pour S={1,2,3} : sans pour autant valider les
candidats termes par rapport au référentiel, cela représente un degré de pertinence pouvant
s’avérer intéressant pour le terminologue. De plus, nous constatons que les résultats ont
tendance à décroître lorsque R augmente : plus il y a de termes renvoyés, moins les
termes renvoyés sont pertinents, ce qui valide quelque peu le classement fourni par les
extracteurs. Au contraire, l’extracteur Sys1 n’a pas de bonnes performances lorsqu’il y
a peu de candidats termes (N=10), mais s’améliore beaucoup plus rapidement que les
autres extracteurs lorsque le nombre de candidats termes augmente. Autre cas de figure,
les extracteurs Sys2 et Sys5 sont beaucoup plus homogènes et leurs résultats varient moins
que les autres extracteurs lorsque N est modifié.
140
5.3. Évaluation automatique
Précision cumulée
PC(10,4)
PC(10,3)
PC(10,2)
PC(10,1)
PC(100,4)
PC(100,3)
PC(100,2)
PC(100,1)
PC(1000,4)
PC(1000,3)
PC(1000,2)
PC(1000,1)
Sys1
0
20
20
30
17
41
48
52
11
34
47
52
Sys2
50
60
60
70
31
37
38
43
29
34
36
39
Sys3
20
30
30
60
20
29
33
59
9
15
21
36
Sys4
0
0
0
10
0
2
3
15
0
3
10
29
Sys5
20
50
50
50
26
46
47
52
17
44
47
50
Table 5.19 – Précision cumulée [%] des extracteurs sur le corpus de la santé.
5.3
Évaluation automatique
Les caractéristiques de l’évaluation automatique se rapprochent de celles des systèmes
du traitement automatique des langues. Des raccourcis existent, notamment via l’utilisation d’une référence créée manuellement, mais le problème de savoir estimer la qualité
des systèmes est lié aux difficultés de comprendre le langage naturel. Accéder à une mesure d’évaluation implique d’avoir une métrique, un programme déterministe calculant
un score [Blanchon et Boitet, 2007] dont les caractéristiques principales sont d’éviter les
désaccords entre juges et la variation dans le temps des résultats.
Nous faisons la distinction avec une évaluation entièrement automatique, c’est-à-dire
sans aucune intervention humaine :le programme ou l’algorithme créé pourrait alors être
intégré au système évalué et biaiserait irrémédiablement l’évaluation et les résultats obtenus. Il faut donc réfléchir à la manière de minimiser la partie humaine de l’évaluation
lorsque l’on cherche à automatiser l’évaluation, tout en gardant à l’esprit la nécessité
d’une intervention humaine dans le processus. L’emploi du terme « semi-automatique »
serait plus judicieux. Mais par facilité le terme « automatique » est plus largement utilisé
au sein de la communauté. Il insiste ainsi sur le côté reproductible de l’évaluation dû à
cette automatisation via un programme. Nous utilisons donc dans notre thèse le terme de
« mesure automatique ».
De plus, nous faisons une différence entre le développement d’une mesure en vue d’évaluer un critère précis défini par l’évaluateur et l’automatisation d’une mesure humaine,
afin de pallier l’utilisation de juges.
5.3.1
Objectifs
Les développeurs de systèmes ont besoin d’observer régulièrement les performances
de leurs systèmes. Au-delà de leur simple observation, il est également utile, à certains
niveaux du développement, de procéder à une évaluation plus formelle. La mise en place
141
d’une évaluation humaine est souvent compliquée du fait de son coût. L’évaluation automatique, lorsqu’elle est possible, est alors un bon substitut à l’évaluation humaine.
L’évaluation automatique ne vaut pas une évaluation humaine, il s’agit donc de trouver un compromis entre la rapidité et la reproductibilité des mesures automatiques et
l’assurance d’un point de vue utilisateur de l’autre. Comme nous l’avons vu dans la section 5.2, l’évaluation humaine n’est pas nécessairement un gage de fiabilité, pas plus que
l’évaluation automatique la plupart du temps.
Le but premier en définissant des mesures automatiques est donc de suppléer l’évaluation humaine. Nous dressons ci-dessous les quatre caractéristiques les plus importantes
quant au déploiement d’une mesure automatique, en fonction des objectifs de l’évaluateur.
La vitesse d’exécution. Là où les évaluations humaines sont longues, les mesures
automatiques permettent de conduire des évaluations plus rapides au niveau applicatif.
Toutefois, la vitesse d’exécution doit être relativisée en fonction des performances des
programmes développés et des algorithmes utilisés dans le processus d’évaluation. Il arrive
que des programmes prennent jusqu’à plusieurs heures pour fournir des résultats, mais
ils restent en-deçà des délais d’une évaluation humaine. L’objectif est d’avoir une mesure
rapide, sans toutefois que cela ne viennent perturber la fiabilité des résultats.
Par ailleurs, un point souvent oublié concerne le développement de la ou des références.
Cette étape fait partie du processus d’évaluation et sa réalisation doit être prise en compte.
En traduction automatique, par exemple, un traducteur professionnel peut traduire de
600 à 1 200 mots par jour selon le type de documents à traduire, le domaine, etc. Cela
représente d’ores et déjà une quinzaine de jours minimum pour un corpus de 20 000 mots
auquel il faut ajouter une relecture par un autre traducteur professionnel, une validation,
des corrections si nécessaire, etc. Malgré tout, la rapidité d’exécution reste un avantage
compte tenu de l’aspect reproductible d’une mesure automatique (voir ci-dessous).
L’objectivité. L’objectivité des mesures automatiques reste toute relative : le choix
de la référence, l’adaptabilité de la métrique à un domaine ou à une tâche, ou l’algorithme
utilisé sont autant de paramètres dont les résultats dépendent, allant même jusqu’à les
biaiser. Du reste, les mesures automatiques s’attachent souvent à n’évaluer que certains
aspects de la qualité d’un système, la plupart du temps via la comparaison à une référence
humaine. Le tout est de savoir analyser et interpréter les résultats de l’évaluation : peu
importe qu’ils proviennent d’une évaluation humaine ou automatique, dès lors qu’ils sont
pertinents il suffit de prendre en compte leurs avantages et leurs inconvénients. Dans le cas
du développement d’un système notamment, ce n’est pas tant les résultats ou « scores » qui
comptent que les moyens mis en place pour analyser les sorties sur des points particuliers
et ainsi améliorer les systèmes.
Bien souvent, les mesures automatiques ont pour but de remplacer des mesures humaines et subjectives, en ôtant justement le caractère subjectif des résultats. Cela signifie
que les résultats ne varient pas dans le temps (ce que l’on peut assimiler à un accord
intra-juge parfait) et qu’ils ne sont pas dépendants d’un point de vue (ce que l’on peut
assimiler à un accord inter-juges parfait). Les mesures d’évaluation doivent, en théorie,
éviter de favoriser tel ou tel système, telle ou telle stratégie (statistique ou à base de
règle par exemple). L’enjeu est de diminuer la part de subjectivité dans l’évaluation, les
mesures automatiques utilisées doivent donc être objectives.
Le coût. Lorsque l’on compare l’évaluation humaine à l’évaluation automatique, on estime généralement que la première est largement plus coûteuse que la seconde. Ce point de
142
vue n’est pas aussi simple, et nous considérons qu’il est même faux dans certains cas. Pour
qu’une évaluation automatique soit moins coûteuse, il faut qu’elle soit reproduite, avec les
mêmes données, un certain nombre de fois. De plus, comparée à une évaluation humaine,
plus il y a de sorties évaluées et plus elle est rentable. En effet, comme nous l’avons vu précédemment, l’utilisation d’une mesure automatique nécessite le développement d’une ou
plusieurs références, ce qui prend du temps et est coûteux financièrement. Nous prenons
exemple en traduction automatique, autour de la première campagne CESTA, pour laquelle deux évaluations, humaine et automatique, ont eu lieu [Hamon, 2007a]. La production des quatre traductions de référence pour l’évaluation automatique a coûté 8 000 euros,
avec un temps d’attente de 3 semaines (avant la collecte des sorties des systèmes). Le coût
des juges évaluant les systèmes a été de 3 000 euros, avec un temps d’attente de 4 semaines
(après la collecte des sorties de systèmes), sachant qu’une traduction de référence était en
plus nécessaire à l’évaluation pour la mesure d’adéquation. Ici, seul le coût de l’évaluation
humaine varie, en fonction du nombre de systèmes évalués et du nombre d’évaluations
conduites. Le coût de production des références reste le même, seule l’application de la
métrique (habituellement peu coûteuse) est répétée. On voit clairement ici l’intérêt de
développer une mesure reproduisant les évaluations humaines, moins coûteuse à terme,
puisqu’il suffirait d’une seule série de jugements (vs. une seule production de références)
pour pouvoir reproduire à volonté des évaluations.
La reproductibilité. Les développeurs ont besoin de reproduire des évaluations, tout
comme l’évaluateur pour observer l’adaptabilité à un domaine des systèmes par exemple.
Trois cas apparaissent dans un cycle de développement de systèmes [Giménez, 2008] :
– l’analyse d’erreurs : en affinant l’évaluation automatique, les développeurs mènent
des évaluations peu coûteuses et identifient des erreurs précises pour améliorer leurs
systèmes ;
– la comparaison de systèmes : indispensable dans le cadre d’une campagne d’évaluation, mais aussi pour comparer deux versions différentes d’un même système
[Callison-Burch et al., 2006], ou comparer un système à un système de l’état de
l’art ;
– l’optimisation de systèmes : pour optimiser, ou adapter un système, les développeurs
ont besoin de mesurer les performances régulièrement afin d’adapter les paramètres
de fonctionnement.
L’évaluation humaine rejoint difficilement ces cas de figure du fait de sa non reproductibilité.
5.3.2
Formalisme et approches
D’une manière générale, une métrique d’évaluation automatique compare la sortie d’un
système à une ou plusieurs références produites par des humains. Une référence est censée
être la sortie idéale que devrait fournir un système. C’est rarement le cas, car la langue
est telle que plusieurs possibilités s’offrent aux systèmes. En traduction automatique, par
exemple, une solution apportée est de collecter plusieurs références afin d’offrir une plus
grande gamme de possibilités. À l’inverse, en reconnaissance automatique de la parole,
les possibilités sont réduites et une seule référence est suffisante.
La comparaison automatique entre la ou les références et la sortie d’un système se
définit selon la technologie évaluée ou le critère de performance recherché. La précision, le
143
rappel et la f-mesure (voir section 5.1.4) sont certainement les mesures les plus utilisées
en évaluation humaine et sont également à la base de nombreuses mesures automatiques.
D’autres métriques utilisent la mesure de distance pour comparer des objets (phrases,
mots, caractères, n-grammes, etc.) entre eux. Une représentation vectorielle au niveau de
l’objet évalué est utilisée pour ensuite calculer une mesure de distance. Cela permet alors
de déterminer si la ou les références et la sortie du système sont séparées par une faible
distance ou non. Plus la distance est faible, plus elles se ressemblent.
De manière assez proche, un troisième type de métrique utilise la similarité entre
documents : en se servant de la représentation vectorielle des documents, la mesure de
similarité détermine si leurs deux vecteurs ont des directions semblables ou si les extrémités
sont proches en calculant l’angle qui existe entre eux.
Ces trois types de métriques (précision/rappel/f-mesure, mesure de distance, mesure
de similarité) s’appliquent à une grande majorité de cas. Bien qu’imparfaites, elles sont
suffisantes pour estimer la qualité d’un système.
Nous prenons comme exemple la distance d’édition (appelée aussi distance de Levenshtein [Levenshtein, 1966]) qui mesure l’importance des différences entre deux séquences,
habituellement deux chaînes de caractères. Elle se définit par le nombre minimal d’opérations nécessaires pour obtenir une séquence par rapport à une autre, les trois opérations
étant l’insertion, la suppression ou la substitution. Chaque opération a la possibilité d’être
pondérée différemment (par exemple, la substitution est considérée comme une suppression suivie d’une insertion et a un coût deux fois plus grand que les deux autres opérations),
même si le poids de chaque opération est habituellement fixé à 1.
Utilisées en premier lieu pour l’évaluation en reconnaissance de la parole, les métriques
calculant les taux d’erreurs (sur les mots ou les caractères) sont dérivées de la distance
de Levenshtein. Elles fournissent le taux de mots erronés par rapport à un document de
référence. Ainsi, le taux d’erreur sur les mots (Word Error Rate – WER – en anglais) est
calculé d’après l’équation suivante :
(5.10)
W ER = (I + D + S)/N
Où I est le nombre d’insertions, D le nombre de suppressions, S le nombre de substitutions
et N le nombre de mots de référence.
Le taux d’erreur sur les mots a été adapté pour les besoins de la traduction automatique
et à donné lieu à plusieurs nouvelles mesures.
La pertinence de la mesure réside dans sa capacité à distinguer une sortie d’un système
et la référence. Une sortie identique obtient des résultats maximaux, mais une sortie
différente doit être pondérée selon le degré de différence. Pour cela, l’évaluateur définit
avant tout ce qu’il cherche à évaluer et sur quels critères, à commencer par les traits
linguistiques (syntaxiques, sémantiques) qui sont utilisés.
Pour affiner notre exemple, nous poursuivons dans le domaine de la traduction automatique pour lequel de nombreuses métriques automatiques existent. Des stratégies de
calcul de similarité avec des traductions de référence sont habituellement utilisées. Dans
CESTA, trois métriques ont particulièrement été étudiées 1 : BLEU, NIST et WNM. La
métrique BLEU (BiLingual Evaluation Understudy) est une métrique automatique, développée par IBM [Papineni et al., 2001]. Comme pour sa variante élaborée par le NIST
1. De nombreuses autres
Callison-Burch et al., 2009].
métriques
existent
144
en
traduction
automatique
[Estrella, 2008,
[Doddington, 2002], le principe est de comparer les phrases sorties du système de traduction automatique aux phrases de référence correspondantes sur la base de séquences de
n-grammes (une séquence ordonnée de n mots).
D’une manière simplifiée, il faut considérer que ces métriques comptent le nombre de
mots d’une phrase contenus dans une ou plusieurs phrases de référence. Une traduction est
d’autant meilleure qu’elle partage un grand nombre de n-grammes avec une ou plusieurs
de ces traductions de référence. BLEU applique une pénalité aux traductions ayant une
différence de taille importante par rapport à la traduction de référence afin d’éviter qu’un
mot apparaisse plus fréquemment dans le document traduit que dans le document de
référence, et d’empêcher ainsi des scores trop importants. La méthode NIST applique
différentes pondérations aux n-grammes, et utilise le gain d’information (qui calcule à
quel point un n-grammes fournit de l’information en donnant plus d’importance aux ngrammes plus rares) et une pénalité sur la taille du document traduit. La méthode BLEU
et sa variante NIST, même si elle sont contestées, restent actuellement les mesures les plus
utilisées dans le domaine de la traduction automatique. Les raisons de contester BLEU
et NIST sont multiples : elles biaisent les résultats en favorisant les systèmes statistiques,
la corrélation avec les juges humains n’est pas robuste et est finalement peu fréquente, on
ne sait pas exactement ce qu’elles mesurent, etc.
La méthode qui utilise le WNM (Weighted N-gram Model) [Babych et Hartley, 2004]
part du principe que, étant donné la variation légitime inhérente à toute traduction,
chaque mot à des besoins et des droits différents pour être préservés par un processus de
traduction. Tout en adoptant la formule des n-grammes, elle introduit une pondération
pour les mots identifiés comme significatifs, cette identification se faisant sur la base de
leur fréquence relative à l’intérieur d’un document par rapport à toute une collection de
documents (il s’agit d’une variante du score tf.idf utilisé en recherche d’information).
WNM calcule trois types de scores : la précision, le rappel et la f -mesure. On peut considérer que le rappel correspond à l’adéquation, tandis que la f -mesure correspond à la
fluidité.
5.3.3
Déroulement
Un des intérêts de l’évaluation automatique se situant dans sa reproductibilité, il
convient d’en définir les grandes étapes afin généraliser les procédures. Nous avons identifié
sept étapes, que nous utiliserons par la suite pour définir notre plate-forme d’évaluation :
1. sélection des données à évaluer ;
2. préparation de la référence ;
3. adaptation des métriques automatiques aux données ;
4. collecte et reformatage des données à évaluer ;
5. calcul des résultats ;
6. tests de validité ;
7. interprétation et analyse des résultats.
La troisième étape est optionnelle selon la tâche, la technologie et les données évaluées.
Il arrive qu’au cours de la quatrième étape les données elles-mêmes soient modifiées, en
145
plus de leur format. Par exemple, il est possible de lemmatiser les sorties avant de les envoyer vers la mesure (dans les faits, cette tâche peut être effectuée à l’aide de la métrique).
C’est à prendre en compte lors de l’analyse des résultats, puisque ce prétraitement risque
d’influer sur l’évaluation : le choix d’un outil (le lemmatiseur par exemple) plutôt qu’un
autre doit être justifié et l’information doit être prise avec soin lors de l’interprétation des
résultats.
5.3.4
Calcul et analyse des résultats de l’évaluation automatique
Pour illustrer le calcul et l’analyse des résultats d’une évaluation automatique, nous
prenons comme exemple le cas de la traduction automatique autour des campagnes
CESTA pour la direction de l’anglais vers le français.
Les résultats obtenus lors de la première campagne d’évaluation sont indiqués dans le
tableau 5.20 ci-dessous, en utilisant les n-grammes jusqu’à 4 pour la mesure BLEU, et
jusqu’à 5 pour la mesure NIST et en tenant compte de la casse des mots pour les deux
mesures. La mesure WNM est présentée ici avec ses valeurs de f-mesure (notées WNMf)
qui sont en réalité la moyenne des scores WNMf obtenus en considérant tour à tour chaque
traduction humaine comme référence [Hamon, 2007b]. Le tableau fait figurer également les
écarts-types des scores, obtenus par échantillonnage des segments [Estrella et al., 2007].
Système
S1(en,1)
S2(en,1)
S3(en,1)
S4(en,1)
S5(en,1)
BLEU
%
cl.
37,60±2,6 5
44,76±1,7 3
57,33±2,0 1
46,64±1,9 2
43,87±2,9 4
NIST
v.a.
cl.
9,03±0,30 5
9,78±0,22 3
11,03±0,25 1
9,98±0,25 2
9,65±0,53 4
WNMf
v.a.
cl.
49,48±0,33 5
55,57±0,39 3
57,29±0,39 1
56,98±0,35 2
53,22±0,42 4
Table 5.20 – Scores des métriques automatiques pour les traductions de la première
campagne d’évaluation CESTA : valeurs, en pourcentage (%) ou en valeur absolue (v. a.),
écarts-types (±) et classements (cl.).
Les résultats des mesures apparaissent particulièrement homogènes, non tant par leurs
valeurs que par les classements identiques qui en résultent. Les écarts-types, affichés ici
à la place des intervalles de confiance, indiquent une proximité assez grande de S4, S2 et
S5, alors que S3 se démarque comme ayant les scores les plus élevés, et S1 les plus bas.
La seconde campagne se proposait, de manière entièrement originale par rapport à des
campagnes précédentes, de mesurer la capacité des systèmes à s’adapter rapidement à un
domaine spécifique, ici celui de la santé. Nous en présenterons d’abord les performances
enregistrées par les mesures automatiques pour les systèmes non adaptés (campagne 2a)
dans le tableau 5.21.
Les résultats avant adaptation au domaine obtenus grâce aux métriques sur les ngrammes conduisent encore une fois à un classement concordant, ce qui permet d’accorder
à ces résultats une confiance acceptable. L’un des systèmes, S9(en,2a) se détache particulièrement, suivi du groupe S10-S11, puis du groupe S8-S12. Au sein de ces deux paires,
il semble difficile de départager de manière fiable les systèmes. Pour la paire S8-S12 une
146
Système
S8(en,2a)
S9(en,2a)
S10(en,2a)
S11(en,2a)
S12(en,2a)
BLEU
%
cl.
32,83 4
37,96 1
33,80 3
35,19 2
25,61 5
NIST
v.a. cl.
7,76 4
9,14 1
8,58 3
8,71 2
7,38 5
WNMf
v.a. cl.
48,09 4
51,37 1
50,02 2
49,79 3
48,06 5
Table 5.21 – Scores des métriques automatiques pour les résultats de la seconde campagne avant adaptation au domaine (2a).
différence très notable est toutefois observée pour la métrique BLEU, mais celle-ci n’est
pas confirmée par le score WNMf.
Les résultats de l’évaluation après adaptation des systèmes sont présentés dans le
tableau 5.22.
Système
S8(en,2b)
S9(en,2b)
S10(en,2b)
S11(en,2b)
S12(en,2b)
BLEU
%
cl.
33,04±3,00 2
38,07±2,70 4
36,60±2,40 5
35,74±4,60 3
40,43±1,00 1
NIST
v.a.
cl.
8,35±0,40 5
9,13±0,34 2
8,97±0,31 3
8,77±0,49 4
9,27±0,17 1
WNMf
v.a.
cl.
50,05±0,66 4
51,50±0,71 3
52,47±0,68 2
50,59±0,66 5
56,25±0,77 1
Table 5.22 – Scores des métriques automatiques pour les résultats de la seconde campagne CESTA après adaptation au domaine (2b).
Le tableau 5.23 reproduit à des fins de comparaison les résultats des mesures automatiques pour les traductions produites par les systèmes avant (tableau 5.21) et respectivement après (tableau 5.22) l’adaptation au domaine.
Système
S8
S9
S10
S11
S12
BLEU
NIST
WNMf
avant après avant après avant après
32,83 33,04 7,76
8,35 48,09 50,05
37,96 38,07 9,14
9,13 51,37 51,50
33,80 36,60 8,58
8,97 50,02 52,47
35,19 35,74 8,71
8,77 49,79 50,59
25,61 40,43 7,38
9,27 48,06 56,25
Table 5.23 – Comparaison des scores des métriques automatiques pour les résultats de
la seconde campagne CESTA avant et après adaptation au domaine.
Cette comparaison illustre les difficultés à s’adapter correctement à un domaine de
spécialité. La plupart des scores augmentent bien après l’adaptation, pour les systèmes
147
S9, S10 et S11 mais l’amélioration reste toutefois faible, ce qui peut être dû à un niveau de
qualité initial déjà élevé. Mais nous préférons considérer la difficulté d’adapter le système
eu égard à la faible taille des données d’adaptation (20 000 mots) ainsi qu’aux délais
relativement brefs accordés pour l’adaptation (une semaine).
Nous notons toutefois que le système S12, et dans une moindre mesure S10, parviennent à s’adapter au domaine avec une grande efficacité. Le cas de S12, passant de
la dernière à la première place, est particulièrement édifiant. On peut penser que ce système peut atteindre d’excellentes performances si le domaine d’application a été bien
appréhendé initialement.
5.3.5
Expérimentations en traduction automatique
5.3.5.1
Problème
La plupart des métriques automatiques en traduction automatique utilisent des traductions humaines, de référence afin de comparer les traductions des systèmes. Ces métriques, telle que BLEU [Papineni et al., 2002], utilisent un maximum de références disponibles, tandis que d’autres, plus récentes, limitent la comparaison à une traduction de
référence (WNM [Babych et Hartley, 2004], METEOR [Banerjee et Lavie, 2005]). L’objectif est d’éviter les évaluations humaines, coûteuses, mais n’empêche pas l’emploi de
l’humain pour créer les traductions de référence qui sont elles-mêmes coûteuses. La métrique X-Score, originellement imaginée par [Rajman et Hartley, 2001] s’appuie sur la distribution de traits linguistiques élémentaires, tels que les catégories morphosyntaxiques ou
les relations de dépendance syntaxique. L’hypothèse des auteurs est de considérer que la
distribution de ces traits linguistiques est similaire d’un texte à un autre dans une langue
donnée.
Le X-Score se limite à l’évaluation de la grammaticalité d’un texte traduit, bien que
sa fonctionnalité puisse s’étendre à n’importe quel texte dans une langue donnée. Selon
la nature et le niveau des traits linguistiques choisis, la précision de la métrique variera :
travailler sur des relations de dépendance syntaxique est plus précis que de travailler sur
des catégories morphosyntaxiques, mais aussi plus complexe.
L’avantage souligné par les auteurs est que la métrique n’a pas besoin du texte source
pour être utilisée : seul le texte traduit est utilisé. Comme nous l’avons précédemment
mentionné, cela peut constituer un problème en soi : si la métrique et les données utilisées
sont connues des systèmes évalués, les développeurs peuvent parfaitement l’intégrer aux
systèmes. Comme nous le verrons par la suite, il est nécessaire d’étendre la métrique à
d’autres perspectives. Autre point faible de la métrique, elle suppose que la grammaticalité
du document source est correcte, puisque le niveau de grammaticalité d’un texte est censé
être conservé durant la traduction (qu’elle soit humaine ou automatique, la traduction
ne passe vraisemblablement pas par une amélioration du contenu de départ). Ce n’est
toutefois pas toujours le cas, il suffit pour cela de prendre exemple de la traduction
de documents oraux. Il nous semble nécessaire de tenir compte des documents sources
dans un premier temps, et d’avoir un corpus d’apprentissage (voir ci-dessous) adapté aux
documents évalués, et non pas générique comme le rapportent les auteurs.
À partir de l’étude que nous avons faite dans [Hamon et al., 2006], nous proposons
ici un algorithme faisant suite aux travaux de [Rajman et Hartley, 2001] pour calculer
un score de grammaticalité d’un texte traduit. Il s’appuie sur le principe suivant (cf.
148
figure 5.9) : notre choix de traits linguistiques se porte sur les catégories morphosyntaxiques ; un modèle des catégories morphosyntaxiques est tout d’abord calculé d’après un
corpus représentant la langue cible et dont les phrases sont annotées selon un score de fluidité (ce critère étant très proche de la grammaticalité d’après [Rajman et Hartley, 2001]).
Puis le nombre d’occurrences des catégories morphosyntaxiques est calculé sur ce même
corpus, appelé « corpus d’apprentissage ». À partir de ces deux résultats, nous obtenons
un prédicteur linéaire capable de déduire un score de fluidité à partir de n’importe quelle
liste de fréquence de catégories morphosyntaxiques issue d’un document traduit. Les tests
que nous avons menés sont effectués à partir des données du projet CESTA.
Figure 5.9 – Déroulement de la métrique X-Score.
5.3.5.2
Prétraitement
Avant de démarrer toute évaluation, il est nécessaire de procéder à une première étape
qui consiste à créer manuellement un « corpus de fluidité » : il est composé de documents
dans lesquels chaque phrase est associée à un score de fluidité. Dans notre cas, nous avons
utilisé le corpus issu de la campagne d’évaluation DARPA 94 [White et al., 1994] qui est
similaire à celui sur lequel les tests ont eu lieu, pour la direction de l’anglais vers le français
de la première campagne d’évaluation CESTA. Le volume des données est d’environ 30 000
mots. Nous avons mené une évaluation consistant à fournir un score de fluidité sur chacune
des phrases du corpus traduit par plusieurs systèmes de qualités différentes 1 afin d’avoir
1. La traduction de référence de DARPA 94 a été conservée et plusieurs systèmes de traduction
automatique commerciaux disponibles sur Internet ont été utilisés.
149
une gamme de qualité suffisante. Les scores de fluidité obtenus (deux par phrase, dont
nous avons calculé la moyenne) permettent de construire le modèle grammatical associé
au langage cible en fonction des catégories morphosyntaxiques des documents du corpus.
5.3.5.3
Modèle grammatical et phase d’apprentissage
Même si nous gardons à l’esprit qu’une grammaire n’est pas figée pour une langue
donnée (elle dépend notamment du domaine d’application, du style d’écriture, etc.), nous
considérons ici que le modèle grammatical est établi à partir du corpus d’apprentissage une
fois pour toute. Un étiqueteur morphosyntaxique est appliqué sur chaque document du
corpus et le nombre d’occurrences des catégories morphosyntaxiques obtenues est calculé.
La fréquence d’apparition de chaque catégorie k par document i est alors calculée d’après
l’équation :
fk (i) =
dk (i)
N
(5.11)
Où :
– dk (i) est le nombre d’occurrences de la catégorie k pour le document i
– N est le nombre total de types de catégories morphosyntaxiques
Ainsi, nous obtenons un vecteur de fréquences des catégories pour chaque document,
et une liste de vecteurs pour l’ensemble du corpus. [Rajman et Hartley, 2001] définissent
le score de fluidité d’un document i comme linéairement dépendant des fréquences de
catégories :
Fi =
X
(ak fk (i)2 )
(5.12)
k
Où :
– fk (i) est la fréquence de la catégorie k dans le document i
– ak est le coefficient linéaire pour la catégorie k
La seule variable inconnue est alors le coefficient linéaire ak , qui justifie le calcul du
prédicteur linéaire afin de définir le coefficient pour chaque catégorie, de telle manière que
l’équation suivante soit minimale :
X
(Fi )
(5.13)
i
Cela implique que les coefficients sont les mêmes pour tous les documents du corpus.
Le vecteur des coefficients minimaux est défini par :
b = (X ′ X)ˆ(−1)(X ′ Y )
(5.14)
Où :
– X est la liste des vecteurs de fréquence
– Y est le vecteur des scores de fluidité
Le vecteur b constitue la liste des coefficients minimaux qui est utilisée par la suite pour
évaluer des documents traduits et prédire un score de fluidité à partir de ce prédicteur
linéaire.
150
5.3.5.4
Phase de test
La troisième étape du calcul du X-Score a pour but de calculer le score de fluidité
d’un document traduit à partir du prédicteur linéaire. À partir du vecteur des coefficients
minimaux, nous projetons le score de fluidité associé aux catégories morphosyntaxiques
d’un corpus représentatif de la langue sur celles d’un document traduit.
Le même processus de transformation est appliqué au document traduit : un étiqueteur
morphosyntaxique est appliqué, puis les fréquences des catégories sont calculées d’après
l’équation 5.11, pour obtenir un vecteur de fréquence de catégories. Finalement, les coefficients minimaux calculés lors de la phase d’apprentissage sont projetés sur ce vecteur
pour obtenir le score de fluidité Fd du document d évalué, d’après l’équation :
Fd =
X
(ak fk (d)2 )
(5.15)
k
Où :
– fk (d) est la fréquence de la catégorie k dans le document d
– ak est le coefficient linéaire minimal pour la catégorie k
La valeur minimale du X-Score est de 0, tandis que la valeur maximale est de 1.
Plus haut est le score, meilleur est le système. Par contre, le X-Score n’a pas vocation
à exprimer un score tel quel pour un système, mais plutôt de chercher à comparer des
systèmes entre eux : nous privilégierons donc le classement des systèmes étudiés plutôt
que leurs scores.
5.3.5.5
Résultats
Les tests présentés ici utilisent les données des deux campagnes d’évaluation CESTA.
De nombreux paramètres sont susceptibles de modifier la métrique, à commencer par
les traits linguistiques sélectionnés. Ici, nous considérons les catégories morphosyntaxiques. Par conséquence, les résultats dépendent également de l’étiqueteur morphosyntaxique choisi. Dans nos expériences, nous avons effectué des tests avec l’étiqueteur Brill
[Brill, 1995] pour le français 1 et le Treetagger [Schmid, 1994] 2 . Nous présentons ci-dessous
les résultats calculés à l’aide de l’étiqueteur Brill, du fait de résultats décevants rencontrés
lors des premières versions du X-Score utilisant le Treetagger [Hamon et al., 2006].
Dans un premier temps, nous avons étudié les coefficients de la matrice de prédiction
faisant suite à la phase d’apprentissage, ainsi que la fréquence d’apparition des catégories
morphosyntaxiques de Brill, présentés dans le tableau 5.24 par ordre décroissant de poids
rapporté au nombre total des fréquences de catégories morphosyntaxiques.
La figure 5.10 présente les poids de chacune des catégories rapporté au nombre total
des fréquences.
Nous avions choisi en premier lieu de ne considérer que les catégories morphosyntaxiques les plus pertinentes de manière assez subjective (nom, verbe, etc.), mais le graphique résultant ne nous donne pas vraiment d’indication sur les catégories à utiliser ou
à enlever pour le calcul du X-Score. Par conséquent nous avons choisi de conserver toutes
les catégories morphosyntaxiques pour calculer les scores.
1. http ://www.atilf.fr
2. http ://www.ims.uni-stuttgart.de/projekte/corplex/TreeTagger/
151
Catégorie
Signification
Poids
DTN
SBC
CAR
SBP
PREP
DTC
COO
ADJ1PAR
VCJ
ACJ
ANCFF
Déterminants Nominaux
Substantifs (noms communs)
Cardinaux
Substantifs (noms propres)
Prépositions
Déterminants Contractés
Coordonnants
Participes Passés derrière un verbe être
Verbes forme conjuguée
Verbe avoir forme conjuguée
Verbe avoir forme non conjuguée infinitif
Mots Étrangers
Particules
Verbe être forme conjuguée
Verbe être forme non conjuguée gérondif ou participe présent
Préfixes
Verbe avoir forme non conjuguée gérondif ou participe présent
Symboles
Pronoms non supportés par le verbe
Noms propres
Participes Passés du verbe être
Relatifs
Participes Passés du verbe avoir
Noms communs
Participes Passés autres
Verbes forme non conjuguée gérondif
ou participe présent
Verbes forme non conjuguée infinitif
Verbe être forme non conjuguée infinitif
Subordonnants
Participes Passés (hormis être et avoir )
Adjectifs
Subordonnant que (ambigu)
Pronoms supportés par le verbe
Adverbes
0,927
0,253
0,908
0,664
0,274
0,951
0,789
2,097
0,690
0,714
5,333
Fréquence Poids
rapporté
6876
0,14582
9952
0,05760
2244
0,04661
2892
0,04393
6417
0,04022
1508
0,03281
1790
0,03231
429
0,02058
1158
0,01828
516
0,00843
10
0,00122
5,311
0,081
0,003
-0,226
8
61
507
9
0,00097
0,00011
0,00003
-0,00005
-4,753
-4,972
4
4
-0,00043
-0,00045
-5,044
-0,039
-2,385
-0,311
-0,118
-3,800
-0,817
-0,176
-0,500
4
519
9
107
422
15
79
610
286
-0,00046
-0,00046
-0,00049
-0,00076
-0,00114
-0,00130
-0,00148
-0,00246
-0,00327
-0,165
-1,083
-0,410
-1,149
-0,104
-1,511
-0,842
-0,805
973
153
594
273
3048
289
731
1214
-0,00367
-0,00379
-0,00557
-0,00718
-0,00725
-0,00999
-0,01408
-0,02236
FGW
PUL
ECJ
ENCNT
PFX
ANCNT
SYM
PRO
NNP
EPAR
REL
APAR
NN
ADJ2PAR
VNCNT
VNCFF
ENCFF
SUB
VPAR
ADJ
SUB$
PRV
ADV
Table 5.24 – Poids des catégories morphosyntaxiques pour le calcul du X-Score.
152
Figure 5.10 – Poids catégories morphosyntaxiques rapporté au nombre total des fréquences du X-Score.
Nous présentons ci-dessous les résultats obtenus sur les données des deux campagnes
CESTA (cf. tableau 5.25 pour la première campagne et le tableau 5.26 pour la seconde
campagne) auxquels nous avons associé les scores de fluidité correspondant aux systèmes
évalués.
Système
S1(en,1)
S2(en,1)
S3(en,1)
S4(en,1)
S5(en,1)
X-Score
%
Cl.
40,87 1
40,20 3
40,53 2
37,97 5
38,91 4
Fluidité
[1-5] Cl.
2,41 5
3,04 1
3,01 2
2,67 4
2,84 3
Table 5.25 – Scores et classement X-Score et fluidité des systèmes de la première campagne CESTA.
Les résultats obtenus ne sont pas réellement concluants et ils sont le plus souvent éloignés des scores de fluidité. Les coefficients de corrélation sur les scores sont respectivement
de 2,46 pour la première campagne et de 51,69 pour la seconde campagne. Les classements
ne correspondent pas non plus, avec même pour la première campagne le premier système
selon le classement de la fluidité qui se retrouve dernier selon le classement du X-Score.
153
Système
X-Score
%
Cl.
S8(en,2b) 35,58 5
S9(en,2b) 36,71 4
S10(en,2b) 38,50 1
S11(en,2b) 38,15 2
S12(en,2b) 37,30 3
Fluidité
[1-5] Cl.
2,28 5
3,19 3
3,30 2
3,19 3
4,28 1
Table 5.26 – Scores et classement X-Score et fluidité des systèmes de la seconde campagne
CESTA.
5.3.5.6
Discussion
Les résultats du X-Score nous ont permis de détecter les limites de la métrique, en
particulier la trop forte dépendance de la métrique aux poids des étiquettes. Ainsi, si
un système privilégie, à tort, une étiquette ayant un poids fort, ce système obtiendra
forcément un score plus haut que d’autres systèmes favorisant d’autres étiquettes. Nous
comparons par exemple les traductions du segment source « Subject : Commission buildings » de chaque système d’après le score obtenu à l’aide de la métrique X-Score (cf.
tableau 5.27).
Système
S1(en,1)
S2(en,1)
S3(en,1)
S4(en,1)
S5(en,1)
Traduction
Étiquetage Brill
Sujet
:
construcSBC SBC ADJ PREP SBC
tions(bâtiments) de commission
Objet : Les bâtiments de la SBC DTN PRO PREP PRO SBP
Commission
Le sujet : les bâtiments de DTN SBC DTN PRO PREP SBP
Commission
Objet : la Commission bâtiSBC DTN SBP SBC
ments
Sujet : Constructions de
SBC SBP PREP SBC
commission
Score [%]
18,56
33,99
50,08
52,41
36,09
Table 5.27 – Exemple de résultats du X-Score.
A priori, la meilleure traduction est celle du système S2(en,1), la référence étant « Objet : Bâtiments de la Commission ». Mais le meilleur score est celui accordé au système
S4(en,1), suivi de très près par le système S3(en,1), tandis que les trois autres systèmes ont
des scores beaucoup plus faibles. Or, si l’on observe la matrice de prédiction, la catégorie
ayant le poids le plus important est celle des déterminants nominaux (DTN). Ainsi, plus
les sorties des systèmes contiennent de DTN, plus hauts sont les scores.
Sur l’ensemble du corpus évalué, la traduction du système S1(en,1) contient beaucoup
plus de DTN que les autres systèmes, ce qui explique sa première position dans les résultats
généraux.
154
Il est certain que le X-Score comporte actuellement des limitations et reste une métrique expérimentale. D’une part, tous les étiqueteurs morphosyntaxiques disponibles sur
le marché n’opèrent pas de la même manière et par conséquent ne produisent pas les
mêmes étiquetages qui par ailleurs sont de qualités différentes. Les résultats de la métrique s’en ressentent. Ensuite, le choix du corpus d’apprentissage est déterminant et les
catégories morphosyntaxiques peuvent être différentes selon le domaine du corpus utilisé,
même si pour un même domaine la répartition des catégories semble être homogène. Mais
ces problèmes, inhérents à la métrique n’expliquent pas les résultats décevants que nous
avons obtenus.
À travers les expérimentations que nous avons conduites, il apparaît que deux paramètres sont manquants. Tout d’abord, il est nécessaire de calculer le X-Score en pondérant
chaque étiquette par l’ensemble des catégories présentes dans chacune des phrases de la
phase d’apprentissage. Cela réduit le poids des catégories trop prédominantes. Autrement
dit, il est nécessaire de travailler sur des fréquences de catégories plutôt que sur des catégories. L’équation 5.11 est alors remplacé par l’équation suivante calculant les fréquences
de ratios entre les catégories k et k ′ pour chaque couple d’étiquette :
fk−k′ (i) =
dk
dk′
N
(5.16)
Où :
– dk est le nombre d’occurrences de la catégorie k pour le document i
– dk′ est le nombre d’occurrences de la catégorie k ′ pour le document i
– N est le nombre total de ratios calculés
Ainsi, une catégorie en surnombre ne biaise pas la métrique.
Autre paramètre manquant, la métrique ne tient pas compte du nombre et de l’ordre
des catégories. Il nous semble nécessaire d’ajouter la notion de n-grammes de catégories,
tout du moins de bi-grammes. L’inconvénient principal concerne le volume des données à
stocker dû au nombre déjà important de catégories, mais aussi à l’utilisation des ratios
sur bi-grammes. En effet, cela consisterait à utiliser les bi-grammes ou les n-grammes
d’étiquettes nous paraît très lourde à gérer. C’est d’autant plus le cas si nous utilisons les
fréquences de ratios de catégories (équation 5.16) plutôt que les fréquences de catégories
uniquement (équation 5.11). Avec les 35 étiquettes de Brill pour le français, cela représente
1 225 ratios de catégories, un maximum de 1 225 bi-grammes de catégories et le nombre
de ratios de bi-grammes de catégories dépasse les 1,5 millions d’entrées. Sans compter le
nombre de segments d’apprentissage, ce qui pose la question de mener l’apprentissage et
l’évaluation au niveau du document. Ce dernier point réduirait la finesse de la métrique
ainsi que l’analyse des données afin de corriger les systèmes de traduction automatique.
Nous avons toutefois calculé les résultats sur les données des deux campagnes pour le
premier paramètre ajouté, en considérant les ratios d’unigrammes (cf. tableau 5.28).
Ces nouveaux résultats ne nous permettent pas d’améliorer la métrique, puisque si
la corrélation avec les scores de fluidité s’améliore légèrement pour les résultats de la
première campagne (corrélation de 0,31), elle diminue pour ceux de la seconde campagne
(corrélation proche de 0). Les résultats sur les bi-grammes ne sont pas plus concluants.
Bien d’autres paramètres viennent complexifier la définition de cette métrique d’évaluation et les dépendances des résultats sont nombreux : choix du corpus d’apprentissage,
choix de l’étiqueteur, choix des étiquettes et de leur pondération, nombre et ordre des
155
Système
X-Score
%
Cl.
S1(en,1)
25,33 4
S2(en,1)
29,91 3
S3(en,1)
35,33 1
S4(en,1)
33,96 2
S5(en,1)
20,85 5
S8(en,2b) 25,16 3
S9(en,2b) 20,00 5
S10(en,2b) 20,39 4
S11(en,2b) 33,46 1
S12(en,2b) 25,58 2
Fluidité
[1-5] Cl.
2,41 5
3,04 1
3,01 2
2,67 4
2,84 3
2,28 5
3,19 3
3,30 2
3,19 3
4,28 1
Table 5.28 – Scores et classement X-Score des systèmes des deux campagnes CESTA en
considérant les ratios d’unigrammes.
mots, etc. Le choix de l’étiqueteur est particulièrement problématique : il peut biaiser
l’évaluation en favorisant l’un ou l’autre des systèmes, mais il peut aussi introduire des
erreurs d’annotation.
Les différents tests que nous avons effectués ne nous ont pas encore permis de finaliser
une métrique d’évaluation pertinente. Cela reflète, nous semble-t-il, la complexité de la
métrique imaginée au départ de manière théorique. À plus grande échelle, de telles expérimentations viennent montrer la difficulté d’évaluer automatiquement en essayant de se
rapprocher le plus possible des jugements humains.
5.3.6
Expérimentations en extraction terminologique
5.3.6.1
Problème
Notre seconde expérimentation pour définir et développer une métrique d’évaluation
automatique a pour cadre l’extraction terminologique. Nous l’avons testée sur les données
du projet CESART. La conception d’une métrique automatique pour évaluer les extracteurs terminologiques est complexe [Zargayouna et al., 2007], et les différents travaux réalisés mettent en évidence les difficultés pour une telle tâche [Amar et al., 2001]. Certains
travaux ont toutefois proposé des méthodes d’évaluation prometteuses justifiant les recherches dans ce domaine. Par exemple, alors que [Bourigault et Habert, 1998] évaluent les
extracteurs terminologiques en comparant leurs sorties, [Mustafa El Hadi et Jouis, 1998]
comparent la sortie d’un système à une terminologie. Nous avons choisi de partir dans
cette seconde direction, c’est-à-dire de comparer la sortie d’un système à une référence.
Notons d’emblée que comparer des outils terminologiques se révèle problématique
[Hamon et Hû, 2002] du fait des différentes méthodes d’extraction utilisées par ceux-ci.
Une autre grande difficulté concerne l’adéquation entre le vocabulaire issu du corpus et
celui de la terminologie. En général, les outils d’extraction de terminologie reposent sur
l’analyse de corpus en proposant des candidats termes au sein d’un corpus donné. Or,
il est impossible d’avoir un corpus ne couvrant qu’un seul domaine : un corpus ne peut
156
être représentatif que d’une partie des phénomènes visés [Nazarenko et Poibeau, 2004]. La
référence qu’est la terminologie est donc un point d’observation qui permet de comparer
la production des systèmes à une idée que l’on se fait d’une terminologie d’un domaine à
un moment donné. Cette référence est le reflet du domaine du corpus sur lequel les outils
travaillent [Daille, 2002] : il existe nécessairement une différence de vocabulaire entre la
référence et le corpus. Un candidat terme peut être valide sans être présent dans le référentiel et de la même façon un terme certifié de la terminologie peut ne pas être présent
dans le corpus.
Cette constatation nous a amené à effectuer deux types de calculs. D’une part le calcul
des taux de précision et de rappel des outils par rapport à une terminologie du domaine, et
d’autre part le calcul du taux de rappel des outils sur une terminologie réduite au corpus.
Cette terminologie réduite est constituée des termes à la fois présents dans la terminologie
complète et dans le corpus. Elle est de ce fait représentative de la couverture du corpus
sur la terminologie du domaine.
L’autre difficulté porte sur la forme des termes. Les variations d’un terme dans le
corpus peuvent être difficiles à apparier avec le référentiel contenant des termes sous
une forme canonique. Par exemple, si un corpus contient le terme infirmières, comment
l’apparier automatiquement avec le terme infirmier contenu dans la terminologie ? La
comparaison entre les candidats termes du corpus d’évaluation et les termes certifiés
du référentiel terminologique pose ainsi de nombreux problèmes [Ninova et al., 2005] et
nécessite de prendre en compte les variations des termes.
5.3.6.2
Prétraitement
Les données utilisées sont de trois types : celui de la base terminologique, du corpus
et de la sortie de l’outil d’extraction à évaluer. Pour pouvoir apparier les données, il faut
les transformer en une forme comparable. Nous effectuons les mêmes opérations pour les
trois types de données. Le premier formatage consiste à supprimer les balises XML, afin
de n’avoir que des données textuelles brutes à utiliser.
Nous avons choisi dans une seconde étape de lemmatiser l’ensemble des données afin
de nous affranchir de certaines variations terminologiques notamment des variations morphologiques. Ce traitement facilite avant tout les comparaisons entre le corpus et la base
terminologique mais n’est pas sans poser certains problèmes. Des ambiguïtés mal résolues
lors de la lemmatisation peuvent mettre en échec l’appariement. Par exemple, le nom produit peut être lemmatisé par le verbe produire s’il n’est pas en contexte, comme ce peut
être le cas avec les candidats termes, alors qu’il peut s’agir du substantif correspondant.
En dernier lieu, les termes lemmatisés sont normalisés selon les catégories morphosyntaxiques, afin d’optimiser l’appariement du corpus avec la terminologie. Ainsi, nous
éliminons une partie des catégories grammaticales, comme par exemple les déterminants.
Il faut toutefois bien faire attention à ne pas supprimer des catégories utiles. Par exemple
les verbes ne font pas à première vue partie de la terminologie. Or, le verbe exprimer
sous la forme d’un participe passé se retrouve dans le terme gènes exprimés synonyme du
terme expression des gènes. Il est ainsi primordial de sélectionner avec soin les catégories
grammaticales à exclure. Par ailleurs, nous estimons que les formes canoniques sont bien
construites, les systèmes ne sont pas jugés ici sur leur capacité à les fournir. De fait, notre
méthode à l’heure actuelle se révèle incapable de procéder à tous les appariements car
certaines variations sont difficiles à traiter. C’est le cas par exemple des préfixes (cf. le
157
terme cardiaque est préfixé cardio).
5.3.6.3
Protocole
Le principe de notre méthode automatique prend appui sur le protocole de l’évaluation
humaine établi dans le cadre du projet CESART. Pour notre évaluation automatique,
seules les valeurs 1 (le candidat est présent dans la terminologie), 3 (tous les composants
du candidat sont certifiés individuellement dans la terminologie), 4 (un seul composant
du candidat est certifié dans la terminologie) et 5 (aucun composant du candidat n’est
certifié dans la terminologie) ont été retenues. La deuxième valeur est en effet la seule
qu’il n’est pas possible d’évaluer automatiquement : décider si une expression absente de
la terminologie de référence est un terme valide demande en effet des compétences qui ne
nous semblent pas formalisables et leur automatisation l’est encore moins.
Une alternative possible consiste à établir manuellement la terminologie à partir du
corpus, sans utiliser la terminologie du domaine. Cette méthode est évidemment très
coûteuse, mais offre l’avantage de limiter le volume des termes de référence.
5.3.6.4
Appariement des données pour l’évaluation automatique
Nous avons utilisé deux terminologies, l’une pour l’évaluation et l’autre pour l’appariement des candidats termes. Dans les deux cas, les taux de rappel et de précision des
extracteurs sont calculés. Dans le premier cas, l’évaluation est effectuée à partir de la terminologie du domaine sans considération du corpus. Dans le second cas, la terminologie
prise en compte est une terminologie réduite aux termes présents dans le corpus de test.
En toute logique, la précision de l’outil est la même dans les deux cas, mais le rappel
doit être beaucoup plus faible dans le cas de la terminologie complète, les termes certifiés
n’étant pas forcément tous dans le corpus. Cependant, les classements entre les différents
systèmes évalués doivent être similaires. Si un système obtient des résultats supérieurs à
ceux d’un autre sur la terminologie complète cela doit aussi être le cas sur la terminologie
réduite, à moins que le corpus n’introduise un biais différencié selon les systèmes (et par
conséquent ne soit pas représentatif de la terminologie). Notons également que le rappel
rend compte de phénomènes différents selon la terminologie utilisée. Pour la terminologie
complète, le rappel rend compte de l’adéquation entre le vocabulaire du corpus et celui de
la terminologie. Pour la terminologie réduite, le rappel met en évidence la capacité d’un
système à extraire l’ensemble des termes certifiés.
La figure 5.11 présente le principe d’évaluation automatique que nous avons adopté.
Le point 1 consiste à apparier la terminologie et la sortie du système. Après lemmatisation et normalisation, les termes sont comparés entre eux selon les mêmes critères que
ceux de l’évaluation humaine, à l’exception du critère 2 qui n’est pas pris en compte. Mis
à part ce dernier cas de figure, nous obtenons le même format de sortie que celui produit
par l’expert. La liste des candidats termes annotés nous permet alors de calculer les taux
de rappel et de précision de la sortie du système sur la terminologie du domaine.
Le point 2 consiste à construire la terminologie réduite à partir du corpus. Elle est le
reflet de la couverture du corpus par la terminologie complète. Pour ce faire, nous testons
pour chaque terme de la terminologie, lemmatisé et normalisé, s’il est présent ou non dans
le corpus qui a été préalablement segmenté en « phrases », mais également lemmatisé et
normalisé. Un terme est considéré comme étant dans la terminologie s’il est directement
158
Figure 5.11 – Évaluation automatique sur les terminologies complète et réduite.
apparié, ou si les composants du terme sont proches dans le texte, en l’occurrence s’il n’y
a qu’un autre mot entre deux composants du terme.
Cette étape permet de passer à la suivante, le point 3 du schéma. Pour ce dernier point,
les calculs sont exactement les mêmes que ceux du premier point. Les taux de précision
et de rappel sont calculés mais cette fois-ci sur la terminologie réduite au corpus.
5.3.6.5
Résultats
La lemmatisation et l’étiquetage morphosyntaxique ont été faits à l’aide du lemmatiseur Brill pour le français. Les catégories grammaticales suivantes ont été supprimées :
DTC (déterminants contractés), PREP (prépositions), PRO (pronoms), DTN (déterminants nominaux). Le problème s’est posé dans le cas de l’appariement des « composants
proches » d’un terme. Comme nous l’avons mentionné pour le X-Score, le choix d’un
lemmatiseur particulier pose déjà la question de son influence sur les résultats finaux.
Nous présentons les résultats selon la terminologie complète, les calculs sur la terminologie réduite n’ayant pas encore été réalisés. De plus, les experts ayant évalué les 1 000
premiers termes renvoyés par les systèmes, nous n’avons effectué la comparaison entre
l’évaluation automatique et l’évaluation humaine que sur ces 1 000 premiers termes.
Nous présentons dans le tableau 5.29 les résultats obtenus pour l’évaluation automatique, en considérant les termes ainsi que toutes leurs variations. Il s’agit de la précision
cumulée sur les n premiers candidats termes extraits par un outil. Ainsi, la colonne V1
présente les précisions des systèmes selon la valeur 1, V2 selon les valeurs 1 et 2, etc. La
première colonne P(1000) concerne les précisions cumulées pour 1 000 termes. La seconde
P(MAX) et la troisième colonne R(MAX) indiquent respectivement la précision et le rappel pour le maximum de termes que les systèmes ont renvoyés. Le rappel est calculé en
considérant la valeur V1 comme étant valide et correspond à la proportion de termes du
domaine que les outils ont renvoyés. La précision correspond aux candidats termes faisant
159
partie de la terminologie du domaine.
Système
Sys1
Sys2
Sys3
P(1000) [%]
V1 V2
V3
5,9
–
62,3
18,8 –
25,2
5
– 40,69
P(MAX) [%]
R(MAX)
V4
V1 V2
V3
V4
V1 [%]
96,8 2,36 – 48,59 91,30
2,7
69,6
3
– 30,07 73,62
14,2
85,7 0,47 – 19,59 82,24
6
Table 5.29 – Résultats de l’évaluation automatique sur CESART.
D’après notre métrique, la performance des extracteurs n’est pas très bonne. En effet
les précisions selon V1 sont très basses. Mais cette contre-performance est à relativiser,
étant donné les précisions en V4, qui montre que les systèmes ont des difficultés à trouver
les termes exacts de la terminologie. Nous notons toutefois que la précision maximale est
au dessus de 90 %.
La couverture de la terminologie établie par les systèmes, représentée par le taux de
rappel, est plutôt mauvaise également, située entre 2,7 % et 14,2 %. Mais cela peut être
dû au fait que la terminologie n’est pas représentative du corpus, comme nous pourrons
le montrer avec les résultats obtenus sur la terminologie réduite.
On peut voir dans le tableau 5.30 les comparaisons des taux de précision entre les
évaluations automatiques et humaines pour les trois outils, sur les 1 000 premiers termes.
Système
Sys1
Sys2
Sys3
Évaluation
V1 V2
5,9
–
18,8 –
5
–
automatique [%]
V3
V4
62,3
96,8
25,2
69,6
40,7
85,7
Évaluation
V1
V2
10,6 34,3
28,8 34,1
8,5 14,6
humaine [%]
V3
V4
47,3 52,1
35,7 38,5
20,7 36,1
Table 5.30 – Résultats de l’évaluation automatique sur CESART.
Nous constatons que les précisions entre les deux types d’évaluation présentent des
écarts pour tous les critères. Ainsi, pour le critère V1 la précision de l’évaluation humaine
est supérieure à celle de l’évaluation automatique, mais ce constat se trouve inversé en ce
qui concerne les critères V3 et V4. De plus, cet écart est beaucoup plus grand pour V4
que pour V3.
Le taux de précision sur V1 devrait être a priori le même pour les deux évaluations.
Ce n’est pourtant pas le cas, alors qu’il s’agit d’un simple appariement avec la base terminologique. Nous expliquons ces écarts de deux manières. Du côté de l’évaluation humaine,
certains termes absents de la terminologie ont été placés en V1 alors qu’ils devaient l’être
en V2. Du côté de l’évaluation automatique, certaines variations des termes (variation
typographique comme le tiret par exemple) empêchent les candidats de s’apparier correctement.
En ce qui concerne les écarts sur les critères V3 et V4, nous avançons également deux
explications. L’évaluation automatique est trop peu contraignante puisqu’il suffit qu’un
candidat terme ait un mot en commun avec un terme pour que l’appariement réussisse
160
même si ce mot n’est pas central. Les experts ont de leur côté des difficultés à distinguer
les critères V3, V4 et la non pertinence d’un candidat terme.
Prenons l’exemple du candidat terme abus sexuel. Il devrait a priori être présent
dans la terminologie, hors seul abus sexuel chez l’enfant est certifié. Lors de l’évaluation
automatique, le candidat terme est jugé selon la valeur 3, car tous les composants du
terme sont présents dans le terme principal, alors que l’expert l’a jugé valide, c’est-à-dire
selon la valeur 1. La difficulté pour l’expert est qu’il ne peut pas parcourir la terminologie
entièrement pour des raisons de temps et doit faire appel à sa propre connaissance du
domaine.
Le tableau 5.31 présente les corrélations de Pearson pour chaque système entre l’évaluation automatique et le jugement des experts, pour les listes de scores produites à partir
des 1 000 premiers candidats termes renvoyés.
Système
Sys1
Sys2
Sys3
Corrélation [%]
38
68
46
Table 5.31 – Corrélations de Pearson pour chaque système entre les évaluations automatique et humaine.
La corrélation moyenne est de 43 %, avec une corrélation maximale de 68 %. À première
vue, ces corrélations ne sont pas très bonnes, mais comme nous l’avons évoqué, elles sont
dues au fait que les deux évaluations ne rendent pas toujours compte de la même chose
et de la même façon.
5.3.6.6
Discussion
Plusieurs voies d’améliorations sont envisagées. Le premier point concerne les étapes
de normalisation et de lemmatisation. Ces différentes transformations ne permettent pas
de rendre compte de la capacité des systèmes à fournir les formes canoniques des termes.
Deux systèmes proposant respectivement expression des gènes et expressions gènes sont
par exemple jugés équivalents alors que l’un des candidats est plus proche de la forme
canonique du terme. Un système mesurant la distance entre l’expression d’un terme et sa
forme canonique pourrait pallier ce problème. Par ailleurs, la prise en compte de certaines
variations (typographie, préfixation) devrait améliorer l’efficacité de cette étape.
Le second point concerne la réduction de la terminologie. Déceler automatiquement si
un terme est présent dans un texte nécessite de repérer ses variations. À l’heure actuelle,
seule l’insertion d’un mot dans un terme composé et les variations morphologiques sont
prises en compte. L’amélioration consiste à déceler d’autres variations comme la coordination ou le changement de catégorie d’un composant comme pour système d’audition et
système auditif.
La méthode proposée ici nous semble ouvrir de nouvelles perspectives pour l’évaluation
des extracteurs terminologiques. Non seulement cette méthode est applicable dans le cadre
de l’évaluation automatique, mais elle peut également permettre de soutenir le travail
des experts dans le cadre de l’évaluation humaine. Elle peut affecter automatiquement à
chaque candidat terme une pertinence qui reste à corriger manuellement.
161
Nous sommes allé plus loin dans [Nazarenko et al., 2009] en étudiant plusieurs pistes
pour l’évaluation des extracteurs terminologiques et notamment la problématique de la
variation des termes. L’objectif est toujours d’adapter la sortie des systèmes pour qu’elle
soit ajustée à la référence. Cette dernière différencie la liste plate de termes de référence et
les variantes de termes. Le protocole se distingue alors en comparant les candidats termes
extraits automatiquement aux termes de la liste plate, puis en comparant les variantes
de termes après calcul de variation par les systèmes. Ainsi, le fait de distinguer les deux
tâches que sont l’extraction terminologique et le calcul de variation permet de les évaluer
de manière autonome et plus particulièrement de simplifier l’évaluation en extraction
terminologique. Reste la problématique de la distance entre termes et la question de leur
comparaison. L’approche d’une distance terminologique utilisant la distance d’édition sur
les chaînes de caractères et sur les termes (pour pouvoir comparer les termes complexes
entre eux) ne nous paraît toutefois pas complètement satisfaisante. En effet, il peut s’avérer
que des chaînes de caractères très proches ne correspondent pas à des termes eux-mêmes
proches (comme par exemple les termes chevaux et cheveux ). L’approche se justifie tout
de même par l’appréciation d’une liste complète de termes. L’ensemble des termes évalués
doit être à même d’atténuer le poids des rapprochements incohérents. De plus, il ne faut
pas oublier l’aspect pratique, à savoir que le domaine d’une extraction terminologique est
généralement assez spécifique pour ne pas rencontrer deux chaînes de caractères proches
sans que les termes ne le soient eux-mêmes.
5.4
5.4.1
Méta-évaluation
Généralités
L’évaluation en traitement automatique des langues est une chose, mais n’a aucun
sens si elle n’est pas évaluée elle-même. L’évaluateur a besoin de connaître le degré de
pertinence d’une mesure pour deux principales raisons : choisir la mesure la plus adéquate
et interpréter les résultats selon ses performances. C’est l’un des points les plus importants
lors du développement d’une mesure automatique, voire de son utilisation. Il s’avère aussi
utile dans le cadre de l’étude d’une évaluation humaine. Cette « évaluation de l’évaluation » est plus souvent désignée sous le terme de méta-évaluation. Avec la méta-évaluation
d’une mesure, l’évaluateur cherche à étudier le degré de corrélation des résultats de cette
mesure avec les critères de qualité qu’elle est censée mesurer. Il évalue son propre travail.
Nous distinguons ici la méta-évaluation de la validation, qui cherche plus à estimer la
pertinence d’une mesure dans un contexte donné par rapport à un seuil. La limite est très
fine entre les deux notions, mais le niveau de complexité et d’étude est plus important
pour la méta-évaluation.
L’état de l’art en ce qui concerne la méta-évaluation est assez limité. D’après nous,
l’étude la plus aboutie au sujet de la méta-évaluation est celle de [Stufflebeam, 1974],
même si elle a pour cadre le domaine de l’éducation. Toutefois, la méthodologie et les
critères de méta-évaluation sont intéressant et peuvent facilement s’appliquer au traitement automatique des langues. En traduction automatique, [Callison-Burch et al., 2007]
étudie quelques mesures d’évaluation du domaine. Globalement le domaine du traitement
automatique des langues ne s’est que peu intéressé au sujet, du moins spécifiquement,
jusqu’à ces dernières années où la question s’est timidement développée.
162
5.4. Méta-évaluation
D’après [Stufflebeam, 1974], la méta-évaluation tourne autour de trois standards totalisant 11 critères pour développer une méthodologie de méta-évaluation, que nous adaptons
au traitement automatique des langues :
– L’adéquation technique :
– La validité interne : la mesure doit produire au minimum une réponse précise
au problème d’évaluation pris en considération. Elle doit également proposer des
résultats sans équivoque.
– La validité externe : détermine si la mesure peut se généraliser et si les résultats
valent pour le cas particulier étudié ou si l’on peut les extrapoler à d’autres cas.
– La fiabilité : concerne la robustesse de la mesure, c’est-à-dire que reproduire l’évaluation ne devrait pas changer les résultats.
– L’objectivité : les résultats ne devraient pas dépendre du choix des données 1 , des
juges ou de l’algorithme utilisé par les systèmes.
– L’utilité :
– La pertinence : la mesure doit répondre aux objectifs de l’évaluation, et aux
attentes des acteurs.
– L’importance : l’évaluateur choisit d’utiliser les données qui seront les plus représentatives pour le bon déroulement de l’évaluation.
– La portée : les informations que procure la mesure ont une ampleur qui ne se
limite pas à certains aspects du critère étudié, mais prend en compte le maximum
de caractéristiques.
– La crédibilité : la confiance en la mesure doit être suffisante pour que l’audience
suppose que l’évaluation évite tout biais. Les auto-évaluations sont à exclure ainsi
que l’évaluateur ou les juges qui sont impartiaux et externes aux systèmes évalués.
– Délai de réponse : la mesure doit fournir des résultats dans les délais escomptés.
– L’omniprésence : les résultats de l’évaluation sont fournis aux acteurs adéquats
afin d’être utilisés de la meilleure manière possible.
– Le coût et l’efficacité : l’évaluateur a besoin de maintenir l’évaluation à un coût le
plus bas possible sans sacrifier la qualité des résultats.
Ces critères s’appliquent à tous les niveaux de l’évaluation : protocole, méthodologie,
mesure, métrique, etc. Il est toutefois plus simple d’observer la qualité de la mesure ou
de la métrique puisque les résultats en sont mesurables. Le protocole, ou la méthodologie,
ont des résultats plus abstraits et fonctionnels. La décomposition en plusieurs critères
permet bien souvent de les améliorer, sans toutefois apprécier des valeurs formelles. La
mesure et la métrique, elles, fournissent des résultats quantifiables, et donc en théorie
comparables avec d’autres résultats quantifiés. Le tout est de connaître exactement ce
qui est méta-évalué, évalué, et de savoir comparer les résultats entre eux. D’un point
de vue plus pratique, nous conservons par la suite le standard d’adéquation technique.
Il permet davantage de décider quelle métrique choisir pour officialiser les résultats de
l’évaluation, pour analyser un système en détails ou pour observer l’amélioration de ses
versions successives.
La méta-évaluation regroupe un ensemble de procédures et de méthodes pour juger
l’évaluation et la confronter à ce qui est considéré comme une bonne évaluation. Mais que
dire de l’évaluation de la méta-évaluation, et son évaluation, etc. ? La régression est infinie
et nous ne nous intéresserons ici qu’au premier degré de méta-évaluation. De plus, la méta1. Paramètre discutable puisque la plupart des technologies dépendent du domaine de la tâche.
163
évaluation reste une évaluation en elle-même, et les principes de l’évaluation développés
précédemment s’y rapportent donc.
5.4.2
Procédure et méthodes
Trois grandes étapes précèdent la procédure de méta-évaluation. En premier lieu, l’évaluateur définit ce qu’il cherche à méta-évaluer et ses objectifs. Ensuite, il définit le cadre
dans lequel aura lieu la méta-évaluation : le type des données, le type d’évaluation, etc.
La troisième étape correspond au déroulement de l’évaluation elle-même et à la collecte
des résultats, tels que nous les avons présentés auparavant. Après quoi, la méta-évaluation
peut commencer. Elle a pour but de comparer les résultats de l’évaluation aux résultats
attendus et sert à les interpréter.
Nous identifions deux méthodes pouvant être entreprises pour méta-évaluer et juger la
pertinence d’une métrique. Outre la comparaison des résultats obtenus, il existe le calcul
de robustesse qui se fait souvent via l’échantillonnage des données (bootstrapping). Ce
dernier permet la mesure de la fiabilité d’une métrique. L’échantillonnage est en particulier
utilisé dans le cas de métriques humaines, dont les résultats sont difficilement comparables
à une référence [Efron et Gong, 1983].
La comparaison de deux métriques, l’une méta-évaluée et l’autre servant de référence,
se fait sur un jeu de données similaire à celui d’une évaluation. L’échantillon choisi est
représentatif de ce que l’on cherche à évaluer afin de vérifier un maximum de cas de figure.
Après avoir sélectionné les données, plusieurs systèmes 1 traitent les données et renvoient
leurs résultats. À partir de ces sorties de systèmes, les différentes métriques sont ensuite
appliquées et leurs résultats collectés.
Finalement, la comparaison effective des métriques se fait en calculant un coefficient de
corrélation. Les principales mesures de corrélation utilisées sont celles de Pearson, Spearman ou Kendall. Elles mesurent le degré de dépendance qui existe entre deux variables.
Le coefficient de corrélation de Pearson est celui le plus utilisé pour mesurer la liaison
linéaire (c.-à-d. la corrélation de scores dans notre cas), mais les coefficients de corrélation
de Spearman et Kendall sont plus pertinents lorsque les variables sont ordinales ou discrètes (dans notre cas, lorsqu’il s’agit de coefficients de corrélation calculés sur des rangs).
Il ne reste plus qu’à interpréter les résultats, voire à analyser les données plus en détails.
Pour comparer le classement des systèmes, un calcul de proximité peut être également possible, comme la distance de Hamming [Hamming, 1950], par exemple dans
[Rajman et Hartley, 2001] sur des métriques de traduction automatique.
Le calcul de robustesse permet de mesurer la capacité intrinsèque des métriques à
produire des scores constants pour des données de qualité constante. Le but est notamment
d’observer la stabilité des métriques par rapport à la variation des données, à qualité
supposée constante. La meilleure façon de mesurer cette stabilité, lorsque les données sont
limitées, est de rééchantillonner les données par un tirage avec remise, afin d’obtenir une
grande quantité d’ensembles de traductions différents. L’hypothèse est que des échantillons
différents produits par un même système auront une « qualité stable », qui doit être mise
1. En effet, nous estimons qu’une méta-évaluation ne peut se conduire qu’avec l’évaluation d’un nombre
relativement important de systèmes et, si possible, utilisant plusieurs stratégies de traitement. Cela permet
d’une part de comparer le classement obtenu par les différentes métriques, et d’autre part d’avoir accès
à un nombre suffisant de résultats différents en multipliant les cas de figure pour la méta-évaluation.
164
en évidence par une métrique stable. Les échantillons étant généralement de la même
taille que l’ensemble de départ, de nombreuses données sont par conséquent dupliquées
dans chaque échantillon.
Le rééchantillonnage permet d’étudier la distribution d’une variable par approche statistique [Efron et Gong, 1983]. Les jeux de données utilisés sont créés en faisant une
sélection aléatoire parmi les données d’origine en autorisant la répétition des données
sélectionnées. De nombreux échantillons sont ainsi créés. Plus il y aura d’échantillon,
plus la probabilité des résultats observés se rapprochera des données réelles. L’algorithme de rééchantillonnage, simple à mettre en place, se présente sous la forme suivante
[Estrella et al., 2007] :
– à partir d’une population X = (x1 , x2 , ..., xn ),
– B échantillons sont tirés, notés Xb∗ = (x∗1 , x∗2 , ..., x∗n ), où chaque x∗i est tiré avec
remise parmi les xi ,
– pour chaque échantillon d’un système a donné, le score ma (Xb∗ ) de la métrique
méta-évaluée, m, est ensuite calculé,
PB
(m (X ∗ ))
– pour le système a, la moyenne des scores des échantillons ma = b=1 Ba b est
calculée,
q
PB
(m (X ∗ )−m2 )
a
a
b=1
est calculé.
– pour le système a, l’écart-type σa =
B
La difficulté restante concerne le choix de la taille de B, le nombre d’échantillons
sélectionnés. En effet, la taille de l’échantillon doit être représentative de l’ensemble
du jeu de données d’origine. D’après la littérature [Efron et Gong, 1983, Koehn, 2004,
Bisani et Ney, 2008, Zhang et Vogel, 2004, Estrella et al., 2007], il apparaît qu’une sélection d’un segment pour vingt est un échantillonnage suffisant.
5.4.3
Méta-évaluation de l’évaluation manuelle
Aussi peu rigoureuse qu’elle soit, une des premières méthodes pour méta-évaluer une
métrique humaine est liée à la connaissance de l’évaluateur ou du développeur. Par
exemple, dans le cadre d’une campagne d’évaluation, le classement des systèmes peut
ne pas paraître cohérent. Autre exemple, un développeur « sait », ou a une idée de l’évolution du système qu’il développe : des résultats improbables peuvent donner lieu à une
vérification de la pertinence de la métrique utilisée (en plus du fonctionnement du système).
Pour méta-évaluer plus formellement les jugements humains, la méthode la plus simple
est de tester la robustesse des jugements produits par échantillonnage. En traduction automatique, dans le projet CESTA, nous avons choisi de créer 100 échantillons (figure 5.12).
Nous échantillonnons les documents de deux manières différentes : en considérant la
distribution à partir d’une part des segments et d’autre part à partir des juges. Cela signifie
que dans le premier cas le tirage se fait en répétant les segments, et dans le second cas en
répétant tous les segments d’un même juge. L’échantillonnage à partir des juges évalue
par ailleurs la cohérence des juges en comparant les résultats à ceux de l’échantillonnage
à partir des segments.
Pour chaque système, quatre types de résultats sont calculés pour les deux échantillonnages, selon :
– le score moyen sur l’ensemble des échantillons ;
– le rang moyen sur l’ensemble des échantillons ;
165
Figure 5.12 – Échantillonnage des jugements pour tester la robustesse de l’évaluation
humaine.
– le classement des scores moyens sur l’ensemble des échantillons ;
– le classement des rangs moyens sur l’ensemble des échantillons.
Puisque deux critères d’évaluation sont considérés (la fluidité et l’adéquation), nous
obtenons seize mesures différentes pour tester la robustesse de l’évaluation humaine. Les
résultats de la première campagne d’évaluation CESTA sont contenus dans le tableau 5.32.
Les probabilités d’obtenir les classements de l’évaluation selon les deux critères sont
très bonnes, même si elles sont toujours meilleures si l’on échantillonne sur les segments
plutôt que sur les juges. En effet, elles sont pour la plupart proches de 100 %. Seules
les probabilités sur les deux systèmes arrivant dans les deux premières positions sont
un peu plus faibles, signifiant que les rangs de ces deux systèmes sont très proches. Au
niveau des scores, les écarts-types sont eux très faibles. Les écarts-types sur les juges
sont proches du double des écarts-types sur les segments et approximativement les mêmes
pour tous les systèmes. Au total, nous en déduisons que l’évaluation humaine s’est bien
déroulée, puisque la variation des scores est très faible, que l’on prenne les résultats selon
les segments ou selon les juges.
5.4.4
Méta-évaluation de l’évaluation automatique
Comme nous l’avons déjà exprimé précédemment, la méta-évaluation des métriques
automatiques se fait essentiellement par comparaison et/ou, plus rarement, par échantillonnage. La comparaison des métriques automatiques se fait habituellement par rapport aux métriques humaines, supposées correctes et utilisées comme référence. Même si la
comparaison avec des métriques déjà validées reste possible, seuls les scores humains nous
166
Évaluation
Fluidité
Score
moyen
Cl.(segment)
Cl.(juges)
[1-5](segment)
[1-5](juges)
Rang
moyen
Cl.(segment)
Cl.(juges)
[1-5](segment)
[1-5](juges)
Adéquation
Score
moyen
Cl.(segment)
Cl.(juges)
[1-5](segment)
[1-5](juges)
Rang
moyen
Cl.(segment)
Cl.(juges)
[1-5](segment)
[1-5](juges)
S1
5
(1,00)
5
(1,00)
2,41
±0,03
2,42
±0,06
5
(1,00)
5
(1,00)
4,13
±0,09
4,40
±0,11
5
(1,00)
5
(0,98)
2,95
±0,03
2,97
±0,07
5
(1,00)
5
(0,99)
3,79
±0,09
3,93
±0,14
S2
4
(1,00)
4
(0,95)
2,67
±0,03
2,68
±0,06
4
(1,00)
4
(0,99)
3,34
±0,09
3,44
±0,17
4
(0,99)
4
(0,72)
3,18
±0,03
3,19
±0,07
4
(0,80)
4
(0,79)
3,20
±0,08
3,31
±0,18
S3
3
(1,00)
3
(0,91)
2,83
±0,03
2,85
±0,06
3
(1,00)
3
(0,98)
2,82
±0,09
2,85
±0,15
3
(0,99)
3
(0,71)
3,24
±0,03
3,25
±0,07
3
(0,80)
3
(0,80)
3,11
±0,08
3,14
±0,17
S4
1
(0,89)
1
(0,62)
3,04
±0,03
3,06
±0,06
1
(0,68)
1
(0,83)
2,31
±0,08
2,08
±0,13
1
(1,00)
1
(0,83)
3,54
±0,03
3,55
±0,07
1
(0,96)
1
(0,78)
2,34
±0,08
2,23
±0,15
S5
2
(0,89)
2
(0,58)
3,00
±0,03
3,03
±0,07
2
(0,68)
2
(0,82)
2,40
±0,09
2,23
±0,13
2
(1,00)
2
(0,78)
3,43
±0,03
3,44
±0,06
2
(0,96)
2
(0,78)
2,56
±0,10
2,39
±0,13
Table 5.32 – Résultats de l’échantillonnage des jugements humains pour la première
campagne d’évaluation CESTA : scores sur une échelle de 1 à 5 (5 étant la meilleure note
et 1 la moins bonne) avec leurs intervalles de confiance (±), et classements avec leurs
probabilités (entre parenthèses).
167
paraissent réellement valables. De la même manière, la méta-évaluation permet d’estimer
la variabilité des métriques par rapport aux scores humains, notamment en définissant un
intervalle de confiance.
En utilisant les données du projet CESTA, nous reprenons tout d’abord les échantillons
humains obtenus précédemment sur les segments, puis nous calculons les mêmes résultats
sur les scores moyens. Le tableau 5.33 fournit par exemple les résultats obtenus avec la
métrique BLEU.
BLEU
Classement
Score [%]
S1
S2
S3
S4
S5
5 (0,82)
3 (0,89)
1 (0,99)
2 (0,89)
4 (0,83)
35,58±2,9 47,18±1,7 54,41±2,0 49,40±1,9 39,06±2,6
Table 5.33 – Résultats de l’échantillonnage sur les scores moyens pour la métrique BLEU
(cumul. 4-gram avec casse) pour la première campagne CESTA.
Nous cherchons maintenant à comparer les résultats des métriques automatiques à
ceux des métriques humaines, à partir des tableaux de résultats obtenus dans les sections
précédentes. Les corrélations de Pearson pour les métriques BLEU, NIST, WNMf avec la
fluidité et l’adéquation sont affichées dans le tableau 5.34.
Évaluation
Fluidité
Adéquation
BLEU
0,69
0,69
NIST
0,63
0,64
WNMf
0,72
0,72
Table 5.34 – Corrélation de Pearson (échelle -1 à 1) entre les métriques automatiques et
les juges humains de la première campagne CESTA.
Les corrélations sont acceptables, mais plus faibles que celles observées dans la littérature pour ces mêmes métriques appliquée à l’anglais cible. Le classement établi par les
juges humains correspond à (S4>S5)>(S3>S2)>S1, les parenthèses indiquant des scores
comparables. Or, le classement des trois métriques automatiques est S3>S4>S2>S5>S1,
ce qui diffère en plusieurs points. La fiabilité des métriques automatiques n’est donc pas
parfaite. Comme annoncé par ses auteurs, la métrique WNMf [Babych et Hartley, 2004]
est relativement plus proche des juges humains que BLEU ou NIST.
Enfin, pour expliquer la différence de classement observée entre les juges humains et
les métriques automatiques – (S4 > S5) > (S3 > S2) > S1 contre S3 > S4 > S2 > S5 > S1
– nous faisons l’hypothèse que les métriques automatiques à base de n-grammes favorisent
le système S4, qui utilise en réalité un modèle de langage pour sélectionner les phrases
traduites, et que les performances de S2 et S3 sont objectivement trop proches pour être
distinguées. Dans tous les cas, les différences majeures entre les systèmes semblent bien
capturées par les métriques automatiques, bien que leur fiabilité paraisse moindre lorsque
le français est la langue cible que lorsqu’il s’agit de l’anglais, par comparaison avec les
résultats disponibles dans la littérature.
168
5.5. Conclusion
5.5
Conclusion
Dans ce chapitre, nous avons analysé la place des mesures dans l’évaluation en traitement automatique des langues. Leurs paramètres et variations (des outils, métriques,
méthodes, etc.) sont tels que l’évaluateur n’a que l’embarras du choix. La principale caractéristique d’une mesure d’évaluation est d’être soit humaine, soit automatique. L’opposition entre les deux types d’évaluation n’est pas évidente en soi. Mais nous considérons que
le choix d’utiliser l’un, ou l’autre, ou les deux, doit se faire en amont de la planification
d’une évaluation. Pour des raisons de coût, mais aussi d’organisation, de délais, etc., ce
choix va profondément influer sur le reste de l’évaluation.
Aucun des deux types d’évaluation, humaine ou automatique, n’a finalement d’avantage sur l’autre. Chacun présente des avantages et des inconvénients, il faut alors peser
le pour et le contre pour savoir celle(s) qui convien(nen)t le mieux pour une évaluation
donnée. Nous avons une préférence pour les mesures humaines : facilité d’étude, mise
en place, interactions, justesse jusqu’à un certain point, etc. Les évaluations humaines
sont nécessaires, c’est pourquoi nous cherchons par la suite à intégrer des composants
spécifiques dans notre architecture. Toutefois, il ne faut pas oublier que les mesures automatiques permettent la reproductibilité des opérations et l’objectivité (souvent apparente
puisque les mesures dépendent de références établies manuellement) des résultats. En ce
sens, elles ont plus de place dans notre architecture d’évaluation. Il s’agit par ailleurs d’un
type d’évaluation indispensable à certaines évaluations (comme pour l’analyse syntaxique
qui en pratique peut difficilement se passer de mesures automatiques).
Nous avons vu dans le chapitre 3 les différents chemins que peut prendre une évaluation
d’un point de vue méthodologique. Ici, c’est d’un point de vue fonctionnel que les mesures
affectent l’organisation de l’architecture d’évaluation.
Concrètement, ce chapitre nous permet d’établir les bases de notre architecture où
nous distinguons les mesures d’évaluation humaine des mesures d’évaluation automatique.
Pour les premières, des interfaces de jugement doivent être mises à disposition et leur
déroulement ne se fait pas dans la continuité du processus : il faut attendre que les
juges aient terminé leur tâche pour calculer les résultats et les rendre visibles (même
s’il est techniquement possible d’afficher les résultats en cours d’évaluation). Pour les
évaluations automatiques, les résultats sont calculés immédiatement, même si un délai
peut être également nécessaire (les temps de calculs sont parfois longs). Ce délai n’est
cependant pas dépendant d’un facteur humain et est facilement estimé en fonction du
volume des données.
D’autre part, le point de vue technique n’est pas le seul à considérer pour incorporer des
métriques d’évaluation à notre architecture. Encore faut-il qu’elles soient performantes et
fiables : la méta-évaluation justifie notre intérêt pour déterminer quelles sont les métriques
« utiles », et quelles sont celles qui le sont moins. C’est en termes de performance, fiabilité
ou encore de délais que nous pourrons décider d’accepter telle ou telle métrique pour
le calcul des résultats. Nous avons également pour objectif d’intégrer à l’architecture
des composants spécifiques de méta-évaluation, appelant diverses métriques à des fins de
comparaison, ou permettant un échantillonnage des données afin de déterminer un niveau
d’acceptation des métriques, voire des mesures, pour les conserver dans l’architecture
d’évaluation.
Finalement, nous avons posé la question du côté générique des mesures d’évaluation,
169
à savoir l’uniformisation de certains aspects des mesures d’évaluation pour les associer à
plusieurs technologies du TAL. C’est ainsi que nous pourrons plus facilement augmenter
le volume des champs auxquelles notre architecture touche. Pour ce faire, nous étudions
les similarités entre évaluations de ces technologies dans le chapitre suivant.
170
Chapitre 6
Les similarités entre évaluations de
technologies du TAL et les
combinaisons de technologies
Les chapitres précédents amènent à réfléchir aux similarités entre les différentes technologies du TAL, du point de vue de l’évaluation. Tout porte à croire qu’elles sont nombreuses. Nous commençons par synthétiser les similarités entre technologies, puis entre
leurs évaluations. Nous passons par une illustration et une hiérarchisation des grandes
familles d’approches et de méthodologies. À partir de ce constat, nous rassemblons les
éléments communs avec pour objectif la définition d’un cadre général d’évaluation. Ce
dernier se caractérise de manière à distinguer les méthodes, mesures et métriques qui sont
réutilisables d’une technologie à une autre, de celles qui sont propres à une technologie
uniquement. Nous cherchons à clarifier ces différences et similarités en vue d’incorporer
des mécanismes génériques dans notre architecture d’évaluation. Nous nous plaçons dans
un contexte d’évaluation technologique, c’est-à-dire sans prendre en compte des critères
tels que l’ergonomie ou l’utilisabilité des systèmes. La partie conceptuelle de l’évaluation
a déjà été vue dans les chapitres 2 et 3, et sa partie technique dans le chapitre 5. Nous
appuyons notre synthèse sur des faits observés lors de nos expérimentations sur plusieurs
technologies. Sans être exhaustif, nous essayons d’explorer un maximum de cas de figure.
6.1
Objectifs
En premier lieu, nous cherchons à mettre en évidence les aspects communs et les
aspects divergents des mesures et métriques de plusieurs technologies du TAL. Notre
objectif est d’établir un formalisme d’évaluation générique qui s’adapte à ces technologies.
Ce formalisme d’évaluation est avant tout nécessaire pour la modélisation de l’architecture
d’évaluation et pour limiter les coûts de mise en place. Il vise à concilier les aspects propres
à chaque mesure d’évaluation, voire chaque technologie : les formats d’entrée et de sortie,
les données nécessaires à la conduite de l’évaluation, l’apport humain, etc.
Dans un second temps, ce chapitre vise à analyser le niveau de difficulté des mesures
et à identifier leurs avantages ou leurs faiblesses. Il est possible d’établir une hiérarchie
de types de mesures non pas dans un objectif de comparaison mais de mutualisation.
171
Chapitre 6 : Les similarités entre évaluations de technologies du TAL et les
Les différentes technologies du traitement automatique des langues ne sont pas toujours
évaluées de la même manière, pourtant nous avons le sentiment que certaines d’entre
elles sont plus « simples » à évaluer que d’autres. Cela est dû à un niveau de maturité
plus avancé comme à de réelles facilités techniques. Toutefois, l’étude des similarités entre
mesures ne se fait sans d’abord observer quelles sont les similarités entre technologies.
Dans une dernière partie, nous étudions la combinaison de technologies. Cela se rapproche de la similarité entre évaluations de technologies différentes dans le sens où l’on
cherche à obtenir un concept commun d’évaluation entre celles-ci. En effet, l’évaluation
en cascade permet d’étudier le comportement propre à chaque technologie, mais aussi
l’impact d’une technologie sur une autre en aval. Cet impact ne peut se mesurer qu’en
identifiant des caractéristiques de qualité communes.
6.2
Similarités entre technologies
D’un point de vue général, les technologies du traitement automatique des langues se
comportent de la même manière au cours de trois phases au cours desquelles se déroulent
successivement : l’analyse les données qui sont fournies au système en entrée et leur représentation formelle ; le traitement de ces représentations formelles et leur transformation
selon la tâche à accomplir ; la génération de nouvelles données en sortie du système.
De manière plus fine, [Popescu-Belis, 2007] a classifié les principaux champs de recherche en traitement automatique des langues selon la place des données linguistiques en
entrée et/ou en sortie, d’après [Dale et al., 2000, Mitkov, 2003]. Cependant, nous considérons que la sortie des systèmes permet de distinguer les technologies dans un contexte
d’évaluation, au contraire de leur entrée. En effet, deux natures de données en entrée sont
généralement possibles, quel que soit leur format : un corpus audio ou un corpus textuel.
En se plaçant du point de vue de l’évaluateur, et non celui du développeur de technologies, nous proposons une classification différente des technologies d’après leur fonction de
traitement et leur type de données en sortie.
Nous séparons les technologies du TAL en quatre catégories :
– Génération des données en language naturel : le système traite les données en entrée
pour en créer de nouvelles en langage naturel. Par exemple, un système de résumé
automatique renvoie un texte qui n’existait pas auparavant.
– Analyse des données en language naturel : le système modifie l’information linguistique des données sans en ajouter, les données sont transformées. Par exemple, un
aligneur de textes analyse des portions de données dans une langue source et dans
une langue cible et cherche à les relier entre elles. Les données analysées ne sont pas
nouvelles, mais une information supplémentaire leur a été ajoutée.
– Annotation des données linguistiques : le système traite les données et y ajoute
des méta-données. Celles-ci sont clairement définies à l’avance et leur nombre est
fini. Par exemple, un analyseur syntaxique annote un corpus en constituants et en
relations. L’action d’annoter ne modifie pas le contenu des données traitées mais
leur apporte des traits linguistiques supplémentaires.
– Extraction des informations linguistiques : le système renvoie des portions de données selon leur pertinence à la tâche de contrôle. Par exemple, un extracteur terminologique renvoie des termes représentatifs du corpus traité. En extrayant des
données pertinentes, les systèmes améliorent l’accès au corpus.
172
6.2. Similarités entre technologies
La plupart de ces catégories se décomposent en deux sous-catégories selon le format
des données produites. Les catégories de génération et d’analyse se décomposent selon que
le format de sortie des systèmes est textuel (texte généré, texte analysé) ou audio (texte
synthétisé, son analysé), et la catégorie d’extraction selon que la sorties des systèmes est
sous la forme d’une liste de documents ou sous la forme d’une liste d’informations. Pour la
catégorie d’annotation, qui n’est pas décomposée en sous-catégories, le format des données
en sortie dépend de celui des données en entrée par l’ajout de méta-données.
En répartissant les technologies dans ces différents catégories, nous cherchons à les
classifier pour les relier ensuite aux mesures d’évaluation, si possible similaires (cf. tableau 6.1). Ainsi, nous distinguons les technologies selon un premier niveau établissant le
traitement qu’elles effectuent et un deuxième niveau selon les résultats produits en sortie.
Traitement
Génération
Format des données en sortie
Texte généré (TG)
Texte synthétisé (TS)
Analyse
Texte analysé (TA)
Son analysé (SA)
Annotation Documents annotés (DA)
Extraction
Liste de documents (LD)
Liste d’informations (LI)
Exemple de technologie
Question-réponse
Synthèse vocale
Traduction oral-oral
Segmentation
Alignement textuel
Analyse syntaxique
Analyse sémantique
Analyse morphosyntaxique
Indexation automatique
Fouille de texte
Table 6.1 – Technologies classifiées selon le traitement effectué et le format des résultats.
Nous explicitons ci-dessous un exemple de technologie par catégorie :
– les systèmes de traduction automatique (TG) génèrent des données écrites dans une
langue cible à partir de données écrites dans un langue source ;
– les systèmes de synthèse vocale (SS) produisent des documents audio à partir de
documents textuels qu’ils traitent.
– les systèmes d’alignement textuel (TA) relient deux corpus entre eux ;
– les systèmes de reconnaissance automatique de la parole (SA) transcrivent des mots
ou des groupes de mots à partir du traitement de documents audio ;
– les systèmes d’analyse sémantique (DA) produisent un corpus étiqueté par classe
sémantique ;
– les systèmes de recherche d’information (LD) renvoient des documents pertinents
pour une requête donnée dans un domaine spécifique ;
– les systèmes d’extraction terminologique (LI) renvoient des termes pertinents pour
une tâche donnée et un corpus spécifique.
173
6.3
Similarités entre mesures ou métriques
Après avoir identifié les similarités entre technologies, nous nous intéressons aux similarités dans leur évaluation. Nous identifions en particulier les similarités entre les différentes
mesures et métriques du TAL.
6.3.1
Mesure humaine vs mesures automatiques
Nous considérons que les mesures se séparent en deux catégories principales, selon
qu’elles sont humaines ou automatiques. Leur distinction se tient dans la construction de
jugements. Dans le cas d’une mesure humaine, les jugements sont fournis aux métriques
et sont utilisés pour un calcul d’agrégation des jugements afin d’obtenir un niveau de
qualité d’ensemble. Dans le cas d’une mesure automatique, les jugements sont construits
par la métrique qui effectue dans un second temps un calcul d’agrégation. Le type d’une
mesure, humain ou automatique, se définit par la disposition des jugements. C’est cette
particularité qui influe sur le protocole d’évaluation. Nous la mettons en avant car elle est
une caractéristique déterminante pour l’organisation de notre architecture.
La tâche des métriques se résume la plupart du temps à calculer une moyenne de
jugements, à mesurer le rappel/précision/f-mesure ou bien à calculer une distance avec
une référence. D’autre part, les métriques se distinguent de par leurs valeurs reçues en
entrée, qu’elles soient à valeurs multiples (un ou plusieurs critères sur des échelles de n
valeurs, n étant supérieur à 2) ou binaire (le choix entre un jugement pertinent ou non
pertinent).
6.3.2
Catégories
Nous proposons dans le tableau 6.2 d’associer les technologies du tableau 6.1 à des
catégories de métriques. Il fait état des mesures habituellement utilisées dans le monde
du traitement automatique des langues.
6.3.3
Métriques humaines
Nous faisons la distinction entre les métriques humaines appliquant leurs critères selon
une échelle sur plusieurs valeurs (HM) et celles n’appliquant qu’une échelle binaire (HB)
pour trois raisons. La première est due à l’approche différente qu’en ont les juges : plus il
y a de valeurs, plus la réflexion est importante pour les juges, et plus les cas limites seront
importants. Une échelle binaire nécessite moins de prises de décision et seules celles qui
sont à la frontière des deux valeurs sont parfois difficiles à prendre. Le nombre de ces cas
limites dépendent du niveau des spécifications de la tâche de contrôle. La seconde raison
de distinguer ces deux sous-catégories de métriques humaines réside dans le calcul des
jugements. La moyenne arithmétique est la plupart du temps calculée lorsque l’échelle est
binaire. Par contre, l’utilisation d’un plus grand nombre de valeurs oblige à d’autres sortes
de calculs. Enfin, les interprétations sont également différentes et opposent une analyse
manichéenne à une analyse nuancée.
Les métriques humaines se différencient d’autant plus en considérant la subjectivité
des jugements : certaines tâches sont plus subjectives que d’autres. La décision pour
174
6.3. Similarités entre mesures ou métriques
Mesures
Humaine
Métriques
Mesure sur n valeurs (HM)
Mesure binaire (HB)
Automatique
Mesure de distance (AMD)
Précision / Rappel / F-mesure (APR)
Apprentissage automatique (AAA)
Exemples
Question-réponse
Synthèse vocale
Alignement textuel
Segmentation
Analyse sémantique
Analyse syntaxique
Indexation automatique
Extraction syntaxique
Fouille de texte
Table 6.2 – Classification de mesures pour l’évaluation de technologies du traitement
juger une réponse correcte ou non dans le cas de l’évaluation d’un système de questionréponse nous semble plus simple que celle pour juger la fluidité d’un système de traduction
automatique sur une échelle de 5 valeurs. Cependant, il est difficile de voir des similarités
entre métriques à ce niveau là : la subjectivité des résultats est très liée à la complexité
même de la résolution des problèmes technologiques.
6.3.4
Métriques automatiques
La catégorisation des métriques automatiques se fait plus facilement : les différences de
calcul sont plus claires et leur nature les pousse à utiliser une approche et un algorithme
spécifiques. C’est pour cela que nous distinguons les métriques utilisant la précision, le
rappel et la f-mesure (APR) des métriques utilisant une mesure de distance (AMD). Un
troisième type de métriques automatiques utilise des algorithmes qui apprennent à reconnaître un comportement relatif à une tâche en observant les données de corpus spécifiques
(AAA). Des modèles sont constitués à partir d’informations pertinentes collectées pour
175
l’apprentissage et appliqués aux données renvoyées par les systèmes. À notre connaissance,
ces métriques en sont encore à un stade expérimental plutôt que dans état utilisable. La
principale difficulté de ce type de métrique concerne la définition d’algorithmes pour déterminer la structure des composants de base étudiés. Ils sont sujets aux mêmes difficultés
que des systèmes de TAL car il faut souvent conjuguer subjectivité et complexité de la
langue naturelle. En théorie, le corpus utilisé pour l’apprentissage est conçu de telle manière à permettre à un algorithme de produire des modèles. Mais en pratique, ce corpus
contient souvent du bruit gênant la structuration de modèles performants. Nous avons
étudié ce type de métrique en section 5.3.5 avec le X-Score.
Le rappel et la précision sont des mesures imparfaites qui se complémentent via la
f-mesure. Les deux types de métriques que sont les mesures de distance et la mesure de
rappel-précision ont pour base la comparaison avec une référence sur lequel se comparer.
Cependant, elles se distinguent par leur symétrie. En effet, les résultats du rappel et
de la précision sont dissymétriques : la référence évaluée contre une sortie de système
ne donnera pas les mêmes résultats que l’évaluation inverse. Au contraire, les résultats
d’une mesure de distance sont, eux, symétriques. Nous constatons ainsi qu’une mesure de
distance correspond à un calcul de proximité entre deux objets, tandis que la précision
et le rappel sont des mesures de quantité de réponses correctes renvoyées. En d’autres
termes, les mesures de distance permettent de déterminer la proximité entre deux objets
pour lesquels les résultats devraient être identiques 1 . Les mesures de précision/rappel
permettent, elles, de calculer la proportion d’objets retournés étant pertinents (précision)
et la proportion d’objets pertinents étant retournés (rappel).
Par conséquent, lorsque les deux types de métriques s’appliquent sur les mêmes types
de données, leur interprétation n’en est pas la même. Ils ne sont d’ailleurs que très rarement
employés en même temps pour évaluer une même technologie 2 .
6.3.5
Synergies
Nous observons à partir du le tableau 6.2 qu’une technologie utilise parfois plusieurs
types de métriques et que certaines technologies utilisent certaines catégories de mesures
plutôt que d’autres. Dans ce dernier cas, il existe toutefois des exceptions qui sont souvent
le fait d’expérimentations suite à des rapprochement entre technologies. C’est par exemple
le cas de l’extraction terminologique (LI) située dans la catégorie « mesure sur n valeurs »
(HM) : l’évaluation en traduction automatique a inspiré les critères des jugements humains
pour déterminer si les candidats termes étaient corrects ou non (selon différents niveaux
de jugement) [Timimi et Mustafa El Hadi, 2008].
Nous rapprochons les types de mesures identifiées dans le tableau 6.2 avec les formats
de données en sortie identifiés dans le tableau 6.1 (cf. tableau 6.3). Il est indiqué les types
de technologies dont un type de mesure connu (par la communauté) est appliqué pour au
moins une technologie à notre connaissance.
À l’exception des mesures APR, cela confirme que la grande majorité des types de
mesures sont confinées à certaines technologies. À vrai dire, seule la catégorie LI utilisant
1. Ce qui pose par exemple problème en traduction automatique, avec les calculs de taux d’erreur,
puisqu’il est reconnu qu’une traduction n’est pas unique.
2. Un contre-exemple de technologie employant les deux types de mesures est la traduction automatique, même si certains ne voient que peu d’intérêt à utiliser des taux d’erreurs – une mesure de distance
– sur les traductions.
176
6.4. Formalisme
Mesures
TG
Mesure sur n valeurs (HM)
X
Mesure binaire (HB)
Mesure de distance (AMD)
X
Précision / Rappel / F- X
mesure (APR)
Apprentissage automatique X
(AAA)
TS
X
TA
SA
DA
X
X
X
X
X
X
LD LI
X
X X
X
X
Table 6.3 – Types de mesures selon les types de traitement et formats de données en
sortie des technologies du TAL (TG : Texte généré ; TS : Texte synthétisé ; TA : Texte
analysé ; SA : Son analysé ; DA : Documents annotés ; LD : Liste de documents ; LI : Liste
d’informations).
les mesures de type HM amoindrie cette hypothèse, même s’il s’agit plus d’expérimentations que de réels standards au sein de la communauté. En ce qui concerne APR, les
mesures sont utilisées par presque toutes les technologies (APR n’est pas pertinent pour
les technologies SA).
6.4
Formalisme
D’après [Popescu-Belis, 1999], une mesure d’évaluation automatique se décompose en
un cadre formel de trois phases : la mesure de la capacité à traiter des données, l’appréciation du résultat mesuré et le bilan intégrant les appréciations de plusieurs mesures. La
mesure de la qualité est accompagnée de différents critères de cohérence tels que les bornes
inférieure et supérieure, l’indulgence ou la sévérité, la monotonie, etc. Nous regrettons que
le modèle proposé repose uniquement sur des métriques comparant la sortie d’un système
avec une référence et nous cherchons à aller plus loin en étendant le principe à l’ensemble
des types de métriques présentées en section 6.3.
Pour cela, nous nous appuyons sur les cinq catégories de métriques : humaine à échelle
binaire (HB), humaine à valeurs multiples (HM), automatique utilisant une mesure de
distance (AMD), automatique utilisant précision et rappel (APR) et automatique avec
apprentissage automatique (AAA).
[Popescu-Belis, 1999] décrit une métrique pour le calcul d’une distance comme étant
calculable automatiquement à l’aide de la réponse attendue (à savoir la référence) selon :
mAM D (rep(Di )) = min{d(rep(Di ), k(Di ))kk ∈ K(Di )}
Où :
–
–
–
–
(6.1)
Di est la donnée i servant à l’évaluation ;
K(Di ) est l’ensemble des références établies par des experts ;
rep(Di ) est la réponse, la sortie du système sur la donnée Di ;
d est la distance calculée entre la sortie du système et une des références, sa valeur
est comprise dans l’intervalle [0, 1].
177
La « variable humaine », k(Di ), donne un caractère non déterministe aux mesures
de distance car elle apporte de la subjectivité à la mesure. Nous allons voir que cette
variable reste présente sous des formes différentes dans le formalisme de chaque catégorie
de métriques. Afin d’homogénéiser les notations, nous avons conservé les variables de
l’équation 6.1 : nous cherchons à établir m(rep(Di )) de la même manière pour les quatre
autres catégories de métriques.
Pour les métriques HB, m(rep(Di )) est calculable à partir de jugements. Ils ne sont
pas construits au préalable par des experts mais font partie de la connaissance personnelle
et subjective de chaque juge. Nous avons ainsi pour les n juges :
Pn
j=1 ({e(rep(Di ), c(Jj ))kc ∈ C(Jj )})
mHB (rep(Di )) =
(6.2)
n
Où :
– Di est la donnée i servant à l’évaluation ;
– C(Jj ) est l’ensemble des connaissances du juge j qui lui permet de juger la réponse ;
– rep(Di ) est la réponse, la sortie du système sur la donnée Di ;
– e correspond au jugement du juge j, avec e ∈ {0, 1}.
Pour les métriques HM, seule la valeur de e change de manière formelle, puisque
e ∈ {0, v} avec v comme valeur maximale, et peut être pondéré en fonction de v :
Pn
j=1 ({pv ∗ e(rep(Di ), c(Jj ))kc ∈ C(Jj )})
mHM (rep(Di )) =
(6.3)
n
Au niveau pratique, la connaissance C(Jj ) n’est pas la même que pour les autres
métriques car la connaissance requise par le juge n’est a priori pas la même.
Les métriques APR sont calculables automatiquement, à partir d’une référence, tout
comme le sont celles de type AMD selon l’équation 6.1. Cela donne l’équation suivante :
m
si rep(Di ) ∈ R(D)
mAP R (rep(Di )) =
(6.4)
n
sinon
Où :
– Di est la donnée i servant à l’évaluation ;
– R(D) est le ou les ensembles de référence établis par des experts sur l’ensemble des
données D servant pour l’évaluation ;
– rep(Di ) est la réponse, la sortie du système sur l’ensemble de donnée D ;
– m et n sont les valeurs à attribuer selon que rep(Di ) trouve une correspondance
dans la référence ou non.
Pour les métriques AAA, le calcul de mAAA (rep(Di )) se fait en deux temps. L’apprentissage se fait tout d’abord à partir de couples (Xn , Yn ) de manière à déterminer
Yn = h(Xn ), tel que h(Xn ) soit minimale. Lorsque h(Xn ) est connu, on calcule alors :
mAAA (rep(Di )) = f (rep(Di ), h(xn ))kxn ∈ rep(Di )})
Où :
–
–
–
–
(6.5)
Di est la donnée i servant à l’évaluation ;
rep(Di ) est la réponse, la sortie du système sur la donnée Di ;
xn représente l’ensemble des composants évalués ;
f est l’application de la fonction h(xn ), pondérée ou non sur la réponse rep(Di ).
178
6.5. Difficultés et « hiérarchie » des technologies
6.5
Difficultés et « hiérarchie » des technologies
En généralisant le problème au traitement automatique des langues et à l’ensemble de
ses technologies, la question centrale de cette section s’appuie sur la difficulté d’évaluer en
fonction de la métrique utilisée et surtout en fonction de la technologie évaluée. Autrement
dit : y a-t-il des domaines du TAL plus faciles à évaluer que d’autres ? Au delà de la
volonté, politique, scientifique ou commerciale, de s’intéresser à des technologies plutôt
qu’à d’autres, ou à des méthodes d’évaluation en particulier, nous nous apercevons qu’il
existe une réelle difficulté propre à l’évaluation de chacune d’entre elles. Explorer cet
aspect de l’évaluation a pour intérêt sa mutualisation. D’autre part, la combinaison de
technologies ou évaluation en cascade doit tenir compte des difficultés à évaluer chacune
des technologies intégrées.
6.5.1
Subjectivité
La difficulté d’évaluer n’est vraisemblablement pas liée aux difficultés technologiques.
Les systèmes produisent des résultats et, quelle que soit la manière, seuls les résultats
sont explorés. À notre sens, c’est la nature même des résultats retournés qui crée la
problématique de l’évaluation.
Nous avons déjà vu dans le chapitre 5 les difficultés inhérentes à l’aspect subjectif de
l’évaluation humaine. Cela peut s’étendre à l’évaluation automatique lorsque l’on considère la complexité à construire une référence. Les accords inter-juges ou les validations
montrent l’étendue des difficultés rencontrées par les juges et les experts. Même si l’idée
est tentante, il n’est pas très pertinent de comparer des accords sur des technologies différentes car les données évaluées sont de natures distinctes. Au mieux, cette comparaison
montrerait à quel point il est difficile d’évaluer certaines données.
6.5.2
Diversité des réponses possibles
La diversité des réponses possibles correspond aux variations des cas de traitement par
les systèmes ou par un humain. Quel que soit le type de métrique, l’estimation de la qualité
pose des problèmes cognitifs lorsque l’ensemble des réponses correctes est insuffisamment
défini. Il est lié aux possibilités multiples de réponses, par exemple pour les technologies
de génération de texte (en traduction automatique, une phrase en langue source peut se
traduire en de nombreuses phrases en langue cible). La connaissance des juges est dans
une certaine mesure à même de surmonter cela, selon leur degré d’expertise. Par contre,
la construction de la référence pose plus de problèmes tout comme son intégration à
une métrique automatique puisqu’elles ont tendance à réduire le nombre de réponses à
comparer. Certains résultats posent moins de problèmes, par exemple avec l’évaluation sur
des documents annotés : la diversité des réponses possibles est finie, de par la définition
des jeux d’annotations. Toutes les possibilités d’annotations sont alors connues et il ne
reste plus qu’à les comparer aux données d’évaluation, même si ce n’est pas une moindre
difficulté.
La figure 6.1 schématise d’après notre expérience la difficulté cognitive d’évaluer en
fonction du nombre de réponses possibles et selon qu’il est fini ou non, à partir de positionnements relatifs. Nous distinguons les deux types de mesures, humaine et automatique.
179
Figure 6.1 – Schématisation de la difficulté cognitive d’évaluer en fonction du nombre
des réponses possibles et de son caractère fini.
Il nous semble évident qu’une diversité finie des réponses possibles permet une évaluation plus simple qu’une diversité non finie. Par exemple, les possibilités limitées d’annotations d’un analyseur syntaxique pour un terme facilite l’évaluation, contrairement à
la multitude de possibilités que peut renvoyer un système de synthèse vocale. Dans le
cas d’une diversité finie, l’évaluation humaine est menée plus facilement que l’évaluation
automatique lorsqu’il existe peu de réponses possibles mais cette tendance s’inverse dès
lors que leur nombre augmente. La difficulté croît beaucoup plus lorsque la diversité des
réponses possibles n’est pas finie que lorsqu’elle l’est : il est plus difficile de « stocker »
toutes les possibilités dans le premier cas.
6.5.3
Non comparabilité
Nous avons identifié deux problèmes : la subjectivité des résultats produits en langage
naturel et la diversité des réponses possibles.
En plus de cela, nous distinguons la « non comparabilité » qui considère la difficulté à
comparer la sortie automatique avec la ou les références et surtout à déterminer quel est
le niveau de perturbation acceptable. La non comparabilité se situe strictement dans un
contexte d’évaluation automatique et de calculs.
6.5.4
Complexité
Nous définissons la complexité Ω de l’évaluation d’une technologie t comme fonction
de la subjectivité Σ, de la diversité des réponses possibles ∆ et de la non comparabilité Γ :
180
6.5. Difficultés et « hiérarchie » des technologies
(6.6)
Ω(t) = σΣ(t) + δ∆(t) + γΓ(t)
Nous rapportons ces variables aux parties humaine et automatique d’une évaluation,
telles que :
– Σ, la subjectivité, se rapproche des caractéristiques de choix des jugements, mais
aussi pour la création de références ;
– ∆, la non comparabilité, se rapproche des caractéristiques automatiques de l’évaluation, car elle représente la difficulté à calculer la perturbation (ou proximité) de
la sortie d’un système par rapport à sa référence ;
– Γ, la diversité des réponses possibles, regarde le nombre de références possibles dans
le cas d’une mesure automatique, et de l’étendue des connaissances d’un juge dans
le cas d’une mesure humaine.
6.5.5
Synthèse et hiérarchisation
Même si déterminer Σ, ∆ et Γ pour chacune des technologies de la langue peut paraître
très abstrait en soi, nous avons choisi d’explorer notre hypothèse sur certaines d’entre
elles en tenant compte de notre expérience en la matière (cf. tableau 6.4). Les valeurs
sont données de manière subjective sur une échelle de difficulté croissante allant de 1 à 5.
Technologie
Σ ∆
Traduction de l’oral vers l’oral 5 4
Synthèse vocale
5 2
4 5
4 5
4 4
3 4
3 3
Analyse syntaxique
3 2
Question-réponse
2 3
Alignement textuel
2 1
1 1
1 1
Γ
5
5
5
2
4
3
3
1
4
1
2
1
Table 6.4 – Difficulté d’évaluations de différentes technologies, d’après les indices [1-5]
de subjectivité (Σ), de diversité des réponses possibles (∆) et de non comparabilité (Γ)
(plus les valeurs sont élevées, plus l’évaluation est complexe).
Les technologies très subjectives telles que la traduction de l’oral vers l’oral, la synthèse vocale ou le résumé automatique font partie de celles dont peu ou pas de mesures
automatiques ont été définies. Lorsqu’elles existent (comme la traduction automatique)
leur utilité est discutable. Au contraire, les technologies à faible subjectivité, comme l’alignement textuel ou la reconnaissance de la parole, ont des mesures automatiques établies
et reconnues par la communauté depuis longtemps. Le domaine des questions-réponses
fait exception, car aucune mesure automatique n’existe à ce jour : cela s’explique par la diversité relativement importante des réponses possibles (vaste choix de réponses – rédigées
181
– possibles) et la comparabilité faible (mesure de distance entre deux réponses d’autant
plus complexe !).
Les technologies ayant une diversité de réponses possibles importante (traduction automatique, résumé automatique) sont celles dont les résultats prêtent à discussion du
fait d’un nombre élevé de possibilités. À l’inverse, les technologies ayant peu de réponses
correctes possibles (reconnaissance de la parole, analyse morphosyntaxique, etc.) ont généralement des évaluations sans équivoque, la phase d’adjudication ne servant à corriger
que les erreurs dans la référence.
Un haut niveau de non comparabilité est surtout lié à des technologies vocales (traduction de l’oral vers l’oral, synthèse vocale) ou à un apport cognitif plus important (résumé
automatique). Les valeurs basses, elles, concernent des technologies dont les perturbations
sont très distinctes les unes des autres (comme par exemple un substantif annoté au lieu
d’un groupe verbal en analyse syntaxique).
Nous illustrons cette hiérarchisation des technologies à l’aide de la figure 6.2.
Figure 6.2 – Hiérarchisation des évaluations de technologies du traitement automatique
des langues. Plus les valeurs sont élevées, plus l’évaluation est complexe.
Les trois niveaux de difficulté vont souvent de pair, mais de faibles variations permettent de distinguer les technologies entre elles. Ainsi, nous constatons qu’il y a des
technologies globalement plus complexes (la traduction de l’oral vers l’oral, le résumé
automatique et l’extraction d’information étant parmi les plus complexes) que d’autres
(la reconnaissance de la parole, l’alignement textuel ou l’analyse morphosyntaxique étant
parmi les moins complexes). Il existe aussi des technologies dont les trois critères de difficulté se retrouvent assez distincts, comme la synthèse vocale (Σ = 5, Γ = 5, mais ∆ = 2)
ou la traduction automatique (Σ = 4, ∆ = 5, mais Γ = 2). Pour d’autres technologies, ces
valeurs sont homogènes (recherche d’information, reconnaissance de la parole, extraction
d’information).
182
6.6. Combinaison de technologies
Par cette hiérarchisation des technologies en fonction de la difficulté à les évaluer, nous
identifions leurs particularités propres et surtout leurs caractéristiques pour améliorer
leurs mesures. Ainsi, il nous paraît plus intéressant de nous arrêter sur la construction
d’une référence et les moyens de la comparer en question-réponse, plutôt que de chercher
à réduire sa subjectivité. De plus, les difficultés propres aux technologies ne sont pas à
négliger lorsque l’on s’attelle à combiner des technologies, comme nous le présentons dans
la section suivante.
6.6
Combinaison de technologies
L’évaluation de technologies combinées est un cas à part en évaluation du traitement
automatique des langues. Cette évaluation qui n’est ni de type boite noire, ni de type
boite transparente est également appelée évaluation en cascade (cf. 2.2.4.2). Les technologies combinées font office de nouvelle technologie à part entière, analysant des données
en entrée et générant des données en sortie, et composées de deux ou plusieurs composants technologiques qui sont eux-même évalués. Ces composants technologiques sont des
systèmes produisant des données utilisables et compréhensibles par l’humain. Il ne faut
pas les confondre avec les modules d’un système.
6.6.1
Généralités
L’objectif et l’avantage d’évaluer la combinaison de plusieurs technologies est de
connaître l’impact d’une technologie sur l’ensemble de la chaîne de traitement et sur
les technologies la suivant dans cette chaîne. Deux méthodes d’évaluation sont possibles :
– évaluation en fin de chaîne (évaluation de type boite noire pour déterminer le ou
les composants les plus adaptés) en modifiant l’impact des composants intermédiaires, par exemple en remplaçant un-à-un les composants par d’autres de même
technologie ;
– évaluation des composants séparément au cours du traitement en articulant entrées
et sorties des composants suivants dans la chaîne (mesure de l’impact d’un ou de
plusieurs composants sur la chaîne). Cette évaluation se fait généralement selon les
méthodes propres aux technologies, mais aussi, de préférence, à l’aide d’une méthode
commune à toutes les technologies afin d’accéder à une évaluation objective de
l’évolution des résultats.
Quelle que soit la méthode d’évaluation, les résultats des mesures sont normalisés afin
de rendre comparables les résultats des technologies respectives et de faciliter l’interprétation sur l’ensemble de la chaîne de traitement. Cela veut dire que l’évaluateur est capable
soit de modifier les composants technologiques à loisir, soit d’obtenir des résultats intermédiaires pour les évaluer indépendamment les uns des autres. Il faut tout de même avoir
conscience des risques de la première méthode car elle ne prévient pas de la « récupération d’erreurs » par un composant suivant celui produisant ces erreurs. En effet, il est très
simple d’imaginer deux systèmes comparés via un même composant effectuant tous les
deux un traitement erroné sur le même échantillon de données, mais le second composant
corrigeant le premier. Il est plus probable que l’évaluateur repère l’erreur avec la seconde
méthode d’évaluation qu’avec la première.
183
Concernant la seconde méthode, chaque composant est évalué de deux manières différentes : en recevant une première fois la sortie du composant précédent et en recevant
une seconde fois des données de format similaire mais produites manuellement. Ainsi
l’impact du premier composant est clairement visible en comparant les deux résultats
(cf. figure 6.3). L’inconvénient de procéder autrement, en observant la sortie finale de la
chaîne de traitement, est d’avoir un composant robuste qui compenserait les défauts d’un
composant précédent.
Figure 6.3 – Calcul de l’impact de la sortie d’un composant sur un autre pour une
évaluation en cascade.
Chaque composant utilisé a un effet, propre à la technologie employée, sur la chaîne de
traitement et le résultat final. Dans le même esprit, il est possible de comparer les résultats
locaux des composants, les résultats intermédiaires ou les résultats globaux au sortir de
la chaîne de traitement : cela donne également une idée de l’évolution des performances
au fur et à mesure de l’enchaînement des composants.
Il faut également prendre en compte le cas de composants non disjoints n’utilisant pas
uniquement la sortie du composant les précédant, mais également des données propres. Il
est fréquent, en prenant l’exemple d’une traduction de l’oral vers du texte, qu’un composant de traduction automatique utilise l’arbre de décision d’un composant de reconnaissance de la parole en vue d’améliorer ses performances : le système modifie le parcours de
l’arbre en fonction des possibilités de traduction.
Il y a ainsi plusieurs intérêts à conduire des évaluations en cascade. L’amélioration des
performances n’est plus propre à la qualité intrinsèque d’une technologie, mais s’inscrit
dans un cadre plus large. Son utilisation ne doit pas influer sur d’autres technologies en
aval. Il est également question de modularité de technologies, où l’on peut imaginer qu’un
système est plus performant qu’un autre de même technologie au sein d’une chaîne de
traitement. Par conséquent, il n’est pas impensable que certains systèmes aient tendance
à mieux se combiner que d’autres.
184
6.6.2
Expérimentation
L’illustration que nous proposons concerne l’évaluation en cascade (end-to-end ) du
projet TC-STAR [Hamon et al., 2008a, Hamon et Mostefa, 2008a] qui utilise une évaluation selon la seconde méthode que nous avons décrite plus haut. Au cours du projet, une
évaluation en cascade d’un système de traduction de l’oral vers l’oral a été mise en place.
Le système résulte de la combinaison d’un composant de reconnaissance automatique de
la parole, d’un composant de traduction automatique de la parole et d’un composant de
synthèse vocale. L’objectif est de traduire un discours oral dans une langue source vers un
discours oral dans une langue cible. Dans notre cas, la langue source utilisée est l’anglais,
tandis que la langue cible est l’espagnol. L’évaluation des technologies correspondant aux
trois composants est également effectuée durant le projet. Pour la reconnaissance automatique de la parole, l’évaluation est conduite à l’aide d’une mesure de distance, le Word
Error Rate (WER). Pour la traduction automatique, des métriques automatiques et humaines sont utilisées, telles que BLEU [Papineni et al., 2001], le multireference Word Error Rate (mWER) [Niessen et al., 2000], ou la fluidité et l’adéquation [White et al., 1994].
Pour la synthèse vocale, une indication numérique de la qualité perçue est fournie à l’aide
de tests subjectifs appelés Mean Opinion Score (MOS) [ITU-T, 1993]. Nous étudions dans
cette section les résultats de la première évaluation en cascade de TC-STAR.
6.6.2.1
Résumé des résultats de l’évaluation des composants
Nous présentons brièvement dans cette section les résultats des composants individuels (reconnaissance automatique de la parole, traduction automatique de la parole et
synthèse vocale) afin de mettre en relief l’évaluation en cascade dans le contexte des résultats propres à chaque composant [Mostefa et al., 2006]. Trois directions de traduction
sont évaluées : de l’anglais vers l’espagnol, de l’espagnol vers l’anglais et du chinois vers
l’anglais. Pour chaque direction, trois tâches sont organisées correspondant au format des
données utilisées en entrée par les systèmes de traduction automatique de la parole : la sortie des systèmes de reconnaissance automatique de la parole (ASR pour Automatic Speech
Recognition), la transcription manuelle des mêmes données (Verbatim) qui contient les répétitions, les hésitations des locuteurs, etc., et la transcription réécrite officiellement (FTE
pour Final Text Edition). Nous n’étudions que les résultats obtenus pour la direction de
l’anglais vers l’espagnol, qui correspond à notre évaluation en cascade. Le tableau 6.5
compare les résultats acquis à l’aide de mesures automatiques du système utilisé pour
l’évaluation en cascade (TC-STAR, qui est la combinaison de plusieurs systèmes) d’une
même technologie et le meilleur système de la campagne d’évaluation (Top 1 ).
Les résultats du meilleur système individuel de reconnaissance de la parole sont relativement faibles avec un taux d’erreur de 8,2 % tandis que le système TC-STAR obtient
de meilleurs résultats avec un taux d’erreur de 6,9 %. En traduction automatique de la
parole, les résultats sont meilleurs pour le système TC-STAR également.
Par ailleurs, le tableau 6.6 présente les résultats de l’évaluation humaine en traduction
automatique de la parole. Pour cette évaluation, deux évaluations par segments ont été
effectuées par 130 juges natifs de l’espagnol, pour un total de 20 360 segments évalués.
Les résultats des deux systèmes automatiques sont relativement hauts avec des scores
situés au-dessus de 3 points. Toutefois, la différence avec la référence humaine reste assez
importante. Le système TC-STAR obtient des résultats inférieurs à ceux du meilleur des
185
Système
Top 1
TC-STAR
Reconnaissance automatique
de la parole [%]
8,2
6,9
ASR [%] Verb. [%] FTE [%]
35,97
46,61
49,81
47,53
50,74
Table 6.5 – Résultats des mesures automatiques de la seconde campagne TC-STAR pour
les composants de reconnaissance automatique de la parole avec le WER (plus le score est
bas, meilleure est la transcription) et de traduction automatique de la parole avec BLEU
(plus le score est haut, meilleure est la traduction). Les résultats du meilleur système (Top
1 ) et du système (TC-STAR) sont présentés.
Métrique
Fluidité
Adéquation
Top 1
ASR Verb. FTE
[1-5] [1-5] [1-5]
3,06 3,39 3,63
3,13 3,54 3,79
TC-STAR
Verb. FTE
[1-5] [1-5]
3,32 3,46
3,55 3,72
Réf.
Verb. FTE
[1-5] [1-5]
4,31 4,56
4,31 4,44
Table 6.6 – Résultat des mesures humaines de la seconde campagne TC-STAR pour le
composant de traduction automatique de la parole (SLT ) avec les scores de fluidité et
d’adéquation (plus le score est haut, meilleure est la traduction) ; les résultats du meilleur
système (Top 1 ), de la combinaison de systèmes (TC-STAR) et d’une référence humaine
(Réf.) sont présentés.
systèmes évalués mais la différence n’est pas significative. Nous notons par ailleurs que
les scores d’adéquation sont situés au-dessus de ceux de la fluidité pour les systèmes
automatiques, tandis que c’est l’inverse qui est de mise pour la référence humaine. Cela
s’explique par des scores plus élevés pour cette dernière et le rapprochement des niveaux
de score.
Enfin, le tableau 6.7 présente les résultats de l’évaluation humaine en synthèse vocale
selon la qualité globale (de nombreux autres critères étaient également utilisés, que nous
ne détaillerons pas ici). Les jugements ont été faits par 20 juges natifs de l’espagnol sur
le meilleur système de la campagne d’évaluation (Top 1 ) et une voix humaine.
Système
Top 1
Voix humaine
Synthèse vocale
[1-5]
4,33
4,66
Table 6.7 – Résultat des mesures humaines de la seconde campagne TC-STAR pour le
composant de synthèse vocale avec la qualité globale (plus le score est élevé, meilleure
est la synthèse) ; les résultats du meilleur système (Top 1 ) et d’une voix humaine sont
présentés.
La voix humaine obtient de meilleurs résultats que le système automatique, même si
les deux performances sont au final très proches.
186
6.6.2.2
Tâche de contrôle et critères d’évaluation
De nombreux concepts sont mis en jeu lors d’une évaluation en traduction de l’oral vers
l’oral. Ils amènent beaucoup de subjectivité aux jugements apportés. Le fait d’impliquer
trois composants différents accroît la difficulté pour estimer les performances du système.
Deux critères ressortent dans la littérature : mesurer la conservation de l’information
depuis l’entrée jusqu’à la sortie (l’adéquation), et déterminer à quel point la traduction est
compréhensible (la fluidité). Plusieurs évaluations de ce type ont été menées à bien, comme
par exemple dans les projet JANUS [Gates et al., 1996], Verbmobil [Nübel, 1997] et TCSTAR [Hamon et al., 2007b]. Ce sont les mêmes critères qui sont définis mais l’approche
diffère en terme de préparation des données, de classification des critères, de protocole, etc.
Les données utilisées pour cette expérimentation sont celles des Sessions Plénières du
Parlement Européen (EPPS, pour European Parliament Plenary Session) pour les orateurs en langue anglaise. Les enregistrements audio ont été sélectionnées sur la période
courant de septembre à décembre 2005 des débats parlementaires. Nous n’avons sélectionné que les discours en anglais des politiciens (vs les interprètes), qui ont été traités
par le système TC-STAR. Les données d’évaluation sont composées de 20 segments de 3
minutes chacun. Cela représente au total une heure de documents audio et environ 8 000
mots anglais. L’interprétation dans plusieurs langues des sessions plénières par les interprètes professionnels du Parlement Européen nous a fourni les segments correspondants
en espagnol, dans des formats texte et audio. De cette manière, nous comparons les résultats de l’interprétation automatique (le système TC-STAR) à ceux de l’interprétation
humaine.
Le système TC-STAR évalué combine les composants suivants :
– Reconnaissance automatique de la parole, résultant de la combinaison de plusieurs
systèmes [Lamel et al., 2006] à l’aide d’une méthode de Recognizer Output Voting
Error Reduction (ROVER) [Fiscus, 1997] ;
– Traduction automatique de la parole, fourni par l’Université de Aachen (RWTH)
[Matusov et al., 2006] ;
– Synthèse vocale, fourni par l’Université Polytechnique de Catalogne (UPC)
[Bonafonte et al., 2006].
Pour chaque fichier audio (en anglais), le composant de reconnaissance automatique
de la parole produit une transcription automatique en anglais, puis le composant de traduction automatique traduit ce texte en espagnol, et finalement le composant de synthèse
vocale synthétise le texte espagnol pour donner un fichier audio en espagnol (cf. 6.4). Les
données sont transférées d’un composant à un autre manuellement, sans aucune forme de
modification supplémentaire.
6.6.2.3
Protocole d’évaluation
Notre
approche
d’évaluation
se
distingue
des
précédents
travaux.
[Somers et Sugita, 2003] ont demandé aux juges d’écrire une paraphrase de ce qu’ils
avaient retenus du document audio traduit, tout en sachant que le document était
synthétisé. Les réponses étaient jugées sur une échelle à 7 points, pour la traduction
automatique et la synthèse, tandis que la reconnaissance automatique de la parole était
jugée à partir d’un taux d’erreur sur les morphèmes (Morpheme Error Rate, MER).
Cette échelle à 7 points a également été retenue dans le cadre du projet LC-STAR
187
Figure 6.4 – Le processus de traduction de l’oral vers l’oral.
[Banchs et al., 2006] pour une évaluation sur les énoncés. À chaque fois, les juges
produisent et évaluent des sorties audio sans évaluer leurs propres productions.
Nous avons choisi une approche différente en nous plaçant du point de vue de la
traduction automatique de la parole plutôt que de celui de la synthèse vocale. D’autre
part, nous pensons qu’il n’est pas nécessaire de présenter aux juges les documents audio
comme étant produits automatiquement : cela influence leur perception, involontairement
ou non, et biaise les résultats. Enfin, bien que le fait de paraphraser les traductions
orales soit intéressant, il ajoute une perturbation des résultats avec cette étape subjective
supplémentaire (celle des juges effectuant les paraphrases) et technique (le calcul de taux
d’erreurs).
Dans un deuxième temps, l’objectif de cette évaluation est de comparer le système
automatique aux interprètes du Parlement Européen. Pour ce faire, les documents audio
correspondant ont été collectés directement sur place par l’Université de Aachen. Sans
que ce soit spécifié aux juges, la répartition est égale entre les sorties audios du système
automatique et ceux des interprètes. De cette manière, les juges agissent comme des
utilisateurs finaux, en jugeant la conservation et la qualité de l’information pour les deux
types d’entrée.
Nous avons vu qu’en traduction automatique les deux critères couramment utilisés
pour l’évaluation humaine sont l’adéquation et la fluidité, qui utilisent une échelle de valeur
à 5 points. Nous avons spécifié une approche similaire à partir d’un premier questionnaire
de qualité (fluidité de la sortie audio) et d’un second questionnaire de compréhension
(adéquation de la sortie audio avec l’entrée correspondante). De plus, les juges ont un
profil d’utilisateur potentiel plutôt qu’expert, si possible non bilingues, et qui ne sont pas
particulièrement spécialistes du domaine de la traduction comme du domaine de l’oral.
Afin de mesurer la conservation du contenu entre le source en anglais et la sortie en
espagnol (cf. 6.5), nous avons préparé des questionnaires de compréhension composés
de 10 questions par échantillon. Pour ce faire, la transcription manuelle de l’anglais est
utilisée afin d’obtenir 10 questions par échantillon dont les réponses (les réponses de réfé188
rence) sont conservées pour les comparer aux réponses des juges.
Par exemple, pour une partie d’un échantillon en anglais, Of course the nature of our
societies has changed dramatically over these years, economically, socially and technologically (Bien sûr, la nature de notre société a changé de façon significative au cours de
ces années, économiquement, socialement et technologiquement), la question What has
changed dramatically over these years ? (Qu’est-ce qui a changé de manière significative
au cours de ces années ? ) est créée tandis que la réponse de référence est The nature of
our societies (La nature de notre société).
Figure 6.5 – L’évaluation de la traduction de l’oral vers l’oral.
Ensuite, les questions et les réponses de référence sont traduites en espagnol. Les
jugements sont effectués en utilisant une interface spécifique via Internet. On demande
aux juges de lire le questionnaire, puis d’écouter le document audio proposé, d’écouter
une seconde fois, et enfin d’écrire leur réponse en ayant la possibilité d’arrêter l’écoute
pour plus de facilité d’écriture.
Lorsque tous les jugements sont terminés, un expert natif hispanophone compare les
réponses des juges aux réponses de référence. Puisque les réponses de référence ne sont
pas exactement identiques à celles des juges, il est demandé à l’expert d’être « flexible ».
Par exemple, à la question ¿Qué publicación concierne al grupo del ponente ? (Quelle
publication concerne le groupe du locuteur ? ), la réponse de référence est La publicación
del código de conducta para las organizaciones no lucrativas (La publication du code de
conduite pour des organisations à but non lucratif ), tandis que le juge répond el código
de conducta sobre las organizaciones sin ánimo de lucro (le code de conduite au sujet des
organisations à but non lucratif ).
Il est évident que seul un expert est capable de noter les réponses comme correctes
ou incorrectes au contraire d’une métrique automatique : chaque réponse a une forme
différente, même si la réponse est correcte. Cela dépend du style d’écriture, d’une réponse
formulée par une phrase ou par un mot, de la synonymie des termes etc. De plus, les
189
traductions évaluées peuvent être différentes et entraîner des variations dans les réponses.
Ainsi, l’expert, qui observe à la fois les réponses de référence et les réponses des juges,
doit particulièrement faire attention au sens des questions.
À la fin de chaque questionnaire de compréhension, les juges remplissent le questionnaire de qualité censé observer la fluidité des documents audio. Ils jugent alors la qualité
audio selon 4 critères, présentés dans le tableau 6.8, ici en anglais.
Critère
Understanding
Fluent Speech
Effort
Overall Quality
Question
Do you think that you have understood the message ?
(Pensez-vous avoir compris le message ? )
1 - Not at all (pas du tout)
5 - Yes, absolutely (Oui, tout à fait)
Is the system fluent ?
(Est-ce que le système est fluide ? )
1 - No, it is very bad ! (Non, il est très mauvais ! )
5 - Yes, it is perfect Spanish (Oui, il est en parfait espagnol)
Rate the listening effort
(Estimez le niveau d’effort pour l’écoute)
1 - Very high (Très élevé)
5 - Low, as natural speech (Faible, comme un discours naturel)
Rate the overall quality of this translation system
(Estimez le niveau global de qualité de ce système de traduction)
1 - Very bad, unusable (Très mauvais, inutilisable)
5 - It is very useful (C’est très utile)
Table 6.8 – Questionnaire de qualité pour l’évaluation en cascade de TC-STAR.
Chaque question est associée à une échelle de 5 valeurs possibles : de manière similaire à
nos expérimentations en traduction automatique, seules les marques extrêmes sont définies
et vont du plus bas niveau de qualité (1) au plus haut (5). Lorsque l’évaluation est
terminée, les moyennes des jugements sont calculées pour chacun des critères. De cette
manière, 8 scores sont disponibles avec les deux « systèmes » (à savoir les interprètes et
le système TC-STAR).
Pour le déroulement de l’évaluation, nous avons sélectionné 20 échantillons en anglais
de 3 minutes chacun, d’un même locuteur. 20 hispanophones natifs ont été recrutés pour
les jugements. Contrairement à des expériences précédentes [Banchs et al., 2006], ils ne
sont pas experts des technologies concernées par l’évaluation et sont payés pour leur
travail. L’objectif est de se rapprocher le plus possible d’un scénario réel d’utilisation.
Chaque juge évalue trois échantillons différents dont un, au moins, provient du système
automatique et un autre d’un interprète. Aucune distinction n’est faite entre les deux
sorties, mais les juges n’évaluent pas deux fois le même échantillon provenant soit du
système automatique soit d’un interprète. Puisqu’il y a 40 échantillons à évaluer (20
provenant des interprètes et 20 du système automatique), certains ont été évalués deux
fois afin de calculer un accord inter-juges.
190
6.6.2.4
Résultats
Nous calculons un accord inter-juges à l’aide des 20 échantillons qui sont évalués
deux fois par deux juges différents. Sur un total de 200 réponses de compréhension (10
par échantillon), 153 sont identiques, c’est-à-dire lorsque les deux juges ont trouvé une
réponse correcte ou qu’ils ont tous les deux trouvé une réponse incorrecte. Les juges sont
en accord pour 77 % des questions posées : certaines questions posent problème. Que ce
soit les jugements pour le système automatique ou ceux pour les interprètes, l’accord est
quasiment identique (79 % pour le système TC-STAR contre 75 % pour les interprètes).
Concernant les questionnaires de fluidité, les accords inter-juges sont relativement
bons, comme le montre le tableau 6.9 pour les réponses dont la différence des scores ne
diffère pas plus de 1 (c’est-à-dire le 1-agreement).
Système
Ensemble
Interprète
TC-STAR
Understanding [%]
95
100
89
Fluent Speech [%]
75
64
89
Effort [%]
75
91
56
Overall Quality [%]
80
73
89
Table 6.9 – 1-agreement [%] du questionnaire de qualité pour l’évaluation en cascade de
TC-STAR.
Le tableau 6.10 détaille les résultats en adéquation de l’évaluation selon trois types de
scores pour l’évaluation de la compréhension :
– les résultats subjectifs (Eval. Subj.) effectués par les juges et montrant le pourcentage de bonnes réponses validées par l’expert ;
– les résultats objectifs (Eval. Obj.) effectués par l’expert en ayant les réponses
de référence sous les yeux. Les sorties audio sont vérifiées afin de savoir si elles
contiennent les réponses aux questions ou non. Cela montre le pourcentage maximal
de réponses qu’auraient dû trouver les juges.
– la même vérification objective cette fois-ci effectuée sur les sorties du composant
de traduction automatique de la parole (Trad) et du composant de reconnaissance
automatique de la parole (Reco). Cela permet de déterminer à quel niveau de
traitement l’information a été la plus perdue.
Système
Interprètes
TC-STAR
Sortie audio
Eval. Subj. Eval. Obj.
50
72
58
83
Trad.
Reco.
83
91
Table 6.10 – Résultats des tests d’adéquation [%] pour l’évaluation en cascade de TCSTAR.
Les résultats obtenus sur les sorties des interprètes sont bien plus bas pour l’évaluation
subjective que pour l’évaluation objective. Autrement dit, les juges ont trouvé 50 % des
réponses, alors qu’ils auraient pu en trouver 72 %. Ce dernier résultat nous fait penser
que, a priori, on peut considérer que 28 % de l’information originale n’a pas été traduite
par les interprètes.
191
Le système automatique semble avoir de meilleurs résultats que l’interprète puisque
le pourcentage de réponses trouvées est de 58 %, et que 83 % des réponses auraient pu
être trouvées : le système automatique traduit plus de contenu que les interprètes. Ces
résultats sont vraisemblablement dus au fait que le système automatique « colle » au
contenu et traduit l’ensemble des informations apportées par le flux audio. Au contraire,
les interprètes sont obligés de résumer leur discours, autant que de le reformuler.
Plusieurs faits peuvent expliquer les meilleurs résultats du système automatique :
– la difficulté des questions est trop focalisée sur un contexte bien précis : un (très)
court passage sert généralement pour les créer ;
– le filtrage de l’information par les interprètes : encore une fois, l’interprète a supprimé
de l’information par manque de temps ou par inutilité (supposée ou non) ;
– la reformulation faite par les interprètes cause une ambiguïté du discours : les interprètes reformulant une bonne partie de leurs traductions, il est possible que l’interprétation ne soit pas exactement ce que l’orateur dit.
La perte d’information du système automatique est due principalement aux composants de reconnaissance automatique de la parole et au composant de traduction automatique 1 . La qualité de l’audio a fait perdre 25 % de l’information en plus, par le seul fait
du caractère subjectif de l’évaluation.
Afin de comparer plus équitablement les résultats des interprètes et ceux du système
automatique, nous avons conservé uniquement les questions pour lesquelles les réponses
sont incluses dans les échantillons des interprètes. Notre hypothèse est de considérer les interprétations humaines comme étant limitées à l’information principale et « importante ».
Ici, l’objectif est d’atteindre notre objectif réel, l’estimation du niveau de qualité, et comparer ce qui est comparable. L’idée d’origine est de comparer les deux interprétations
selon les qualités intrinsèques des systèmes en faisant abstraction de la perte d’information qui amène beaucoup de bruit dans l’évaluation de la qualité. Un sous-ensemble de
144 questions a été composé dont les réponses sont présentes dans la sortie des interprètes
(c.-a-d. Eval_obj.(interprete) = 100%). Les résultats sont présentés de la même manière
dans le tableau 6.11.
Système
Interprètes
TC-STAR
Sortie audio
Eval. Subj. Eval. Obj.
67
100
63
86
Trad.
Reco.
86
95
Table 6.11 – Résultats des tests de compréhension [%] pour l’évaluation en cascade de
TC-STAR, restreints au sous-ensemble des questions pour lesquelles les réponses sont
trouvées dans les sorties des interprètes.
Les résultats sont ici plus hauts, même si la quantité d’information que les juges
identifient est plus faible que pour l’ensemble complet des questions. En considérant que
la perte d’information est nulle pour l’interprète dans ce cas, le système automatique
1. Il faut noter que pour d’autres expérimentations, même le composant de synthèse vocale a fait perdre
de l’information au système automatique [Hamon et al., 2009] : par exemple, la traduction automatique
de qualité très faible associée aux pauses mal placées de la synthèse vocale ont donné une sortie audio
incompréhensible.
192
obtient des résultats assez hauts en ne perdant que 14 % de l’information. Toutefois, la
« perte subjective », due à l’intervention des juges est de 37 % pour la sortie TC-STAR,
tandis qu’elle est de 33 % pour la sortie des interprètes. Les résultats des interprètes
sont finalement plus hauts que ceux du système automatique. Toutefois, ce dernier a plus
tendance à interpréter tout le discours du locuteur anglais.
La perte objective du système TC-STAR se décompose en 5 % provenant du composant
de reconnaissance automatique de la parole et 9 % provenant de celui de traduction automatique. Cela confirme, comme lors d’expériences antérieures [Somers et Sugita, 2003],
que la traduction automatique est le maillon faible d’un tel système.
Nous pouvons déterminer à l’aide de telles expériences quelles sont les faiblesses d’un
système combinant des technologies. Une identification plus fine des problèmes permettrait certainement d’améliorer ses performances [Hamon et al., 2009] et laisse présager des
améliorations futures. Deux solutions nous viennent à l’esprit pour pallier les problèmes
récurrents de la traduction automatique dans ce genre de système : ou bien tout miser sur
cette technologie, en faisant abstraction des deux autres qui obtiennent des résultats vraisemblablement corrects ; ou bien fournir de meilleures données en entrée du composant de
traduction automatique en améliorant la reconnaissance automatique de la parole, mais
aussi en fournissant d’autres données pour obtenir un composant plus élaboré (tels que le
sont déjà les arbres de décision).
Le tableau 6.12 présente les résultats de fluidité qui utilisent les questionnaires de
fluidité, à la fois pour les interprètes et le système automatique.
Système
Interprètes
TC-STAR
Understanding
3,45
2,34
Fluent Speech
3,48
1,93
Effort Overall Quality
3,19
3,52
1,55
1,93
Table 6.12 – Résultats des tests de fluidité [1-5] pour l’évaluation en cascade de TCSTAR.
Les résultats des interprètes sont élevés, mais n’atteignent toutefois pas les scores
maximaux. Les conditions d’interprétation expliquent ces résultats : traduction en temps
réel, discours anglais original en arrière-plan, bruits variés tels que des respirations ou des
bruits de table, etc. Le système automatique obtient, lui, des résultats nettement plus
bas, puisqu’un quart des échantillons sont estimés comme n’étant pas fluides et difficiles
à écouter.
À partir des performances obtenues par les interprètes, nous analysons deux principales
situations de dégradation :
– Bruits lors de l’enregistrement : bien que les documents audio ne contiennent pas
le discours de l’orateur, il est légèrement audible en arrière-plan. À cela s’ajoute
divers bruits de fond dans les documents, comme des cognements contre une table,
la respiration de l’interprète, etc. Ces bruits de fond ne sont pas présents dans la
sortie du système TC-STAR, ce qui le rend plus audible et plus agréable à l’écoute.
– Hésitations de l’interprète : contrairement au système TC-STAR, l’interprète écoute
l’orateur en même temps que lui-même parle. Cela pose évidemment problème pour
parler normalement. Par exemple, dans certains échantillons, l’interprète hésite
beaucoup, fait souvent des pauses, commence à parler puis se reprend, prolonge
193
certaines syllabes, ou encore fait des erreurs avec le début de certains mots, etc. Il
ne faut pas non plus accabler les interprètes : leur tâche est difficile, et la qualité
de ce que produit peut elle-même être faible (les problèmes étant grosso modo les
mêmes que ceux des interprètes...).
De la même manière, nous observons trois situations de dégradation pour le système
TC-STAR :
– Problèmes d’accords grammaticaux (en genre, nombre et temps de verbes) et problèmes de syntaxe au sein des phrases. Par exemple, dans la phrase suivante, nous
observons une combinaison d’erreurs qui accentue la difficulté de compréhension du
juge :
Phrase source (issue du composant de reconnaissance automatique de la parole) :
that this debate is attended by French , German , Austrian , Belgian , British and
and other colleagues . (que ce débat est suivi par des français, des allemands, des
autrichiens, des belges, des britanniques et et d’autres collègues .)
Phrase traduite automatiquement et synthétisée :
que este debate es *la* que *asistieron* francés alemán *austríaca* belga y británico
y colegas de otros . (que ce débat est celle qui sont assistés par français allemand
autrichien belge britannique et collègues d’autres .)
Le manque d’accord entre « débat » (masculin) et « la » (féminin) force le juge à un
effort supplémentaire pour comprendre ce qui est dit. C’est aggravé par le fait que
le verbe est à la troisième personne du pluriel tandis que le nom est à la troisième
personne du singulier, sans déterminant pour l’indiquer. La structure syntaxique a
également été modifiée : la construction, passive à l’origine (« is attended by ») a
été transformée en une forme active inversée (« es la que asistieron ») en espagnol,
ce qui est en fait plus commun qu’une construction passive en espagnol, mais qui
a posé plus de difficultés au système pour retrouver le bon accord en genre et en
nombre.
Enfin, il y a aussi un changement de structure syntaxique entre l’anglais « other colleagues » et l’espagnol « colegas de otros », ce qui change quelque peu le sens en fin
de phrase.
– Pause entre deux phrases : l’interprète marque une pause entre deux phrases, tandis
que le système TC-STAR a tendance à concaténer les phrases à l’oral, sans les
distinguer. Lorsque deux phrases sont prononcées comme une seule phrase, suivre
le discours est plus difficile pour le juge.
– Mots de connexion moins naturels : le système TC-STAR produit à l’oral des connecteurs entre les mots dont la prononciation sonne moins naturellement que par un
humain, tels que les mots « well », « so », etc. Cela perturbe le juge, car si les
mots eux-mêmes n’ont pas une bonne prosodie, les connecteurs semblent contribuer
significativement au sens de la phrase, alors que tel n’est pas le cas. Encore une fois,
le juge produit un effort supplémentaire pour ne pas prendre en compte ces mots
afin de mieux comprendre ce qui est dit.
Bien que toutes ces erreurs paraissent mineures prises individuellement, elles posent
de gros problèmes aux juges quand elles sont regroupées de la sorte. Ils ont besoin d’un
effort accru pour suivre et comprendre la traduction orale et sont facilement distraits en
essayant de trouver une association entre les mots dont l’accord est erroné ou en recréant
la structure de la phrase.
194
6.7. Conclusion
Par ailleurs, nous avons comparé ces résultats avec ceux des évaluations isolées des
différents composants : le score de fluidité pour la traduction automatique, et le score de
Word Error Rate pour la reconnaissance automatique de la parole (cf. tableau 6.13).
Système
Interprètes
TC-STAR
Sortie audio [1-5] Trad [1-5] Reco [%]
3,48
4,31
1,93
3,38
6,90
Table 6.13 – Résultats des tests de qualité pour chaque composant de l’évaluation en
cascade de TC-STAR.
La dégradation se situe à chaque composant, en particulier avec l’apparition du composant de synthèse vocale. Nous avons conduit d’autres expériences qui ont mené à des
résultats similaires [Hamon et Mostefa, 2008a, Hamon et al., 2009].
6.6.2.5
Discussion
Nous avons présenté une méthodologie d’évaluation pour une combinaison de technologies, la traduction de l’oral vers l’oral. Plusieurs critères ont été définis, afin d’évaluer
autant la sortie d’un interprète que celle d’un système automatique. Pour ce faire, de
nombreuses informations ont été analysées.
La méthodologie n’est pas parfaite, les critères d’évaluation sont notamment à affiner,
mais nous avons démontré que l’évaluation d’une chaîne de plusieurs technologies est possible, en prenant en compte l’évolution des performances. Ainsi, il ressort de cette étude
que le système automatique est encore loin des performances d’un interprète. Toutefois,
un point positif majeur est à souligner : si l’interprète ne traduit qu’une partie de l’information, quelquefois n’atteignant pas la qualité souhaitée, le système automatique, lui,
traduit toute l’information apportée par le locuteur source. C’est un avantage indéniable
du traitement automatique, même si la qualité et la compréhension de la traduction n’est
pas encore satisfaisante.
6.7
Conclusion
Nous avons observé dans ce chapitre les caractéristiques d’évaluation de différentes
technologies du traitement automatique des langues afin d’y trouver des ressemblances.
Cela s’est fait en regroupant dans un premier temps les technologies elles-mêmes. Dans
un second temps, nous avons classifié ces technologies en fonction de leur similarités, puis
leurs mesures types, communes à plusieurs technologies.
À partir de cela, nous avons alors établi un premier bilan en ce qui concerne une hiérarchisation des technologies en terme d’évaluation. L’évaluation est plus complexe à mettre
en place pour des technologies comme la traduction de l’oral vers l’oral, le résumé automatique, la synthèse vocale ou l’extraction d’information. À l’inverse, la reconnaissance
de la parole, l’analyse morphosyntaxique ou l’alignement textuel sont des technologies
dont l’évaluation est plus simple à réaliser. La complexité de l’interprétation des résultats
varie en conséquence de cette complexité.
195
En fin de chapitre, nous avons étudié la combinaison de technologies et son évaluation
en cascade. C’est un cas particulier de l’évaluation qui permet d’estimer l’impact d’une
technologie sur une autre. Autour d’une expérimentation, nous avons ainsi pu identifier,
par exemple, les effets d’une traduction automatique de faible qualité sur un système de
synthèse de la parole.
Nous avons besoin pour la conception de notre architecture de ce genre d’étude, non
pas à un niveau conceptuel (pour le développement de la plate-forme), mais à un niveau
fonctionnel. En effet, avec la possibilité d’effectuer des combinaisons de technologies, il faut
pouvoir effectuer les opérations adéquates et savoir interpréter les résultats de manière
correcte.
Hiérarchiser les technologies et identifier les effets de combinaisons a pour objectif de
prendre de la hauteur et de connaître l’état des lieux en TAL : quels sont ses atouts et ses
lacunes, quelles sont les technologies matures et celles dont la pertinence des résultats est
moins certaine. C’est autant d’efforts qui permettront de mettre en place une architecture
d’évaluation adaptée à la situation pour chaque technologie.
196
Chapitre 7
Vers une architecture d’évaluation
générique et pérenne en TAL
Dans un contexte de multiplication des évaluations, de synergie de données, protocoles
et métriques ou de recherche d’automatismes, l’évolution du traitement automatique des
langues justifie le développement d’architectures d’évaluation.
L’idée d’une architecture est inspirée par les progrès constants des différentes technologies. Cela comprend à la fois ceux de l’informatique pure (protocoles de transfert de
fichiers, langages de programmation, serveurs de données, etc.) et ceux du traitement automatique des langues (serveurs de corpus, partage d’outils, distribution de données, etc.).
Les expériences des deux domaines réunis sont complémentaires : elles apportent d’un
côté le cadre technique d’architectures interconnectant des systèmes et d’un autre côté la
gestion des données linguistiques à travers les différents standards.
De plus, si une telle approche de l’évaluation en traitement automatique des langues
semblait peu envisageable il y a 20 ans, le développement d’Internet, la multiplication des
technologies d’interopérabilité de services et l’apparition du Web 2.0 permettent dorénavant d’imaginer des architectures bien moins coûteuses.
Le traitement automatique des langues a besoin d’architectures d’évaluation car elles
facilitent en particulier :
– le parcours des différentes étapes de l’évaluation ;
– l’accès aux ressources linguistiques ;
– l’accès aux métriques d’évaluation et leur automatisation ;
– la combinaison de technologies et leur évaluation.
Dans les chapitres précédents, nous avons ainsi établi différents cas de figure pour
lesquels une architecture d’évaluation a tout à fait sa place. Le retour d’expérience lors
de l’organisation de campagnes d’évaluation ou d’évaluation de systèmes isolés nous a
également fourni les éléments nécessaires quant aux fonctionnalités qu’une architecture
d’évaluation pérenne et générique doit offrir. L’évaluation de systèmes de TAL pose des
problèmes liés tant à son organisation qu’aux contraintes propres au protocole adopté et
à la mesure.
La plupart des étapes d’une évaluation (chapitre 3) sont à inclure dans notre architecture. Les étapes des phases d’évaluation sont plus concernées que les étapes des phases
préliminaires.
197
Chapitre 7 : Vers une architecture d’évaluation générique et pérenne en TAL
L’intégration dans l’architecture des ressources nécessaires à l’évaluation (chapitre 4)
impose également certaines contraintes : outre les coûts de développement et de maintien,
cela nécessite le respect des standards existants ou la standardisation des formats le cas
échéant. En effet, l’utilisation de ressources par des systèmes hétérogènes dans une même
structure est facilitée en évitant la spécification de formats multiples.
L’étude des mesures d’évaluation (chapitre 5), point central de l’architecture d’évaluation, nous a permis d’identifier différentes techniques d’évaluation et les approches à
définir pour mettre en place l’architecture. Cette étape a été confortée par l’étude des
similarités en terme d’évaluation de technologies (chapitre 6), justifiant en cela le développement d’une architecture générique. En effet, les mesures d’évaluation se séparent en
deux grandes familles (automatiques et humaines) mais, au sein de ces familles, le principe de fonctionnement des métriques est globalement le même. L’architecture peut donc
satisfaire l’évaluation de nombreuses technologies sur des mêmes principes, moyennant un
choix de métriques différent.
Dans ce chapitre, nous fixons les objectifs de notre architecture, puis nous présentons
nos premières expérimentations autour du développement d’architectures d’évaluation et
discutons de résultats obtenus. Enfin, nous proposons la modélisation de notre architecture
type avant de conclure.
7.1
Objectifs
Notre proposition repose sur une architecture utilisant le réseau afin de faire interagir des systèmes de TAL et les métriques à distance. L’indépendance des programmes
utilisés doit être garantie quelles que soient leurs caractéristiques comme le langage de
programmation, la localisation, le format de données en entrée et en sortie.
Notre objectif principal est de mettre en place une architecture générique, capable de
rassembler plusieurs types de technologies et leurs mesures, et pérenne, qui puisse être
réutilisée pour d’autres évaluations dans le futur. Le choix d’une architecture d’évaluation
est d’ordinaire propre à une technologie : nous cherchons à mutualiser les technologies au
sein d’une architecture générique. Nous justifions cela par les besoins en pérennisation
du TAL (réutilisation des moyens comme les protocoles, les données, les outils, les métriques, etc.). L’évaluation est coûteuse mais doit pouvoir être reproductible au cours du
temps. L’architecture doit donc inclure les différents types, niveaux et méthodes d’évaluation décrits dans le chapitre 2.
En pratique, nous avons plusieurs attentes :
– Qu’il s’agisse d’une campagne d’évaluation ou de l’évaluation d’un système isolé,
les interactions avec les participants ou les développeurs de systèmes sont très nombreuses, à toutes les étapes de l’évaluation. L’automatisation de certaines procédures
(par exemple la validation du format des données) est un bénéfice non négligeable
pour l’évaluateur (effort réduit) comme pour le participant (temps d’attente réduit).
– Il faut limiter les opérations manuelles (validation, calcul des résultats, manipulation
de données, etc.) qui apparaissent régulièrement au cours d’une évaluation et qui
augmentent le risque d’erreur.
– L’accent doit être mis sur le transfert des données d’évaluation qui est fastidieux,
autant pour leur envoi que pour leur réception. Les points à risque sont nombreux et
augmentent en fonction du nombre de systèmes à évaluer et de la taille des données.
198
7.1. Objectifs
– Les formats de données doivent être respectés. Dans le meilleur des cas, l’architecture
pousse à une standardisation des formats de données. Sinon, l’architecture permet
la gestion de plusieurs formats différents pour une même technologie.
– Le calcul des résultats est long, fastidieux et sujet à erreurs : l’automatisation résoud
une partie des problèmes, mais il faut tout de même encadrer les calculs par des
règles strictes.
– Les évaluations manuelles sont complexes et gagneraient à être automatisées. Il y a
tout d’abord un gain à attendre des interfaces d’évaluation humaine et la réalisation
des jugements. Ce sont des opérations d’évaluation qui peuvent être automatisables,
au mieux en remplaçant des jugements humains par des métriques automatiques
aussi efficaces.
– Les délais sont difficiles à respecter, ce qui ne donne pas toujours une bonne image de
l’évaluateur. Ce dernier se trouve en fin de parcours d’évaluation dans la plupart des
projets et les attentes sont souvent inversement proportionnelles à la durée restante
pour l’évaluation. Automatiser les procédures rendrait la tâche plus rapide.
Ainsi, l’architecture doit être pourvue de fonctions automatisées : démarrage des différentes étapes d’évaluation (entraînement des systèmes, test, etc.), appel aux programmes
de calcul des résultats automatique, intégration des données aux métriques humaines,
dépôt des données, etc.
L’automatisation de l’évaluation dans notre architecture semble, de fait, aller à l’encontre des mesures d’évaluation humaine : l’intégration de mesures nécessitant une intervention humaine semble relativement lourde à mettre en place. Cependant, nous considérons qu’il est possible d’intégrer les mesures d’évaluation humaines en adaptant le protocole avec des interfaces appropriées. Il faut alors prendre en compte les différents aspects
de ces mesures : délais d’attente, calcul des résultats, mesures d’accord inter-juges, etc.
L’utilisation des deux types de mesures (automatique et humaine) permettrait alors de
mener une méta-évaluation. Les mesures automatiques sont aussi concernées par l’automatisation au sein d’une architecture : l’objectif est de se soustraire totalement aux parties
manuelles (déplacement des données, lancement des métriques, etc.) du fait de leur automatisation déjà avancée. Nous souhaitons tout de même proposer une architecture qui
supporte ces deux types de mesures.
De plus, la place des ressources linguistiques est à améliorer par rapport à une évaluation « standard » : l’architecture doit les centraliser. Bien sûr, les données sources, les
mesures et les références sont communes à l’ensemble des systèmes évalués dans un même
contexte. Mais nous privilégions aussi la mise en commun des données pour une même
technologie (cf. chapitre 6) et le stockage de l’ensemble des ressources linguistiques sur un
serveur de données couplé à une gestion des droits d’accès et d’utilisation.
Les principes informatiques sont communs à toutes les technologies du traitement
– La gestion des données, des systèmes, du serveur, etc. se fait à travers l’architecture :
compte tenu de la taille parfois importante des données, elles ne sont pas forcément
stockées (par défaut, les dernières données utilisées peuvent être conservées comme
historique minimal) ; un historique des transferts et données utilisées est conservé.
– Les interfaces utilisateurs sont généralement accessibles à distance, via Internet, et
sont intuitives et complètes. Les interfaces sont de plusieurs types et sont dédiées
aux développeurs de systèmes, aux évaluateurs, aux juges, etc. Dans le cadre d’une
199
campagne d’évaluation, les participants accèdent aux mêmes types de données, aux
mêmes mesures et aux mêmes types de résultats. Les interfaces sont normalement
multi plate-forme ou adaptables facilement 1 .
– Les accès sont sécurisés : les utilisateurs d’une même architecture n’ont, en théorie, pas accès aux données des autres utilisateurs, ni aux résultats obtenus. Des
agents extérieurs ne sont pas autorisés à avoir accès à l’architecture et aux données
librement.
– La récupération des résultats d’évaluation (jugements et calculs automatiques) et
le calcul des scores se font avec le moins de manipulations humaines possibles.
Les processus sont robustes et respectent les principes d’évaluation décrits dans
les chapitres précédents.
– Des interfaces d’analyse des résultats sont susceptibles d’être intégrées à l’architecture.
Le codage de l’architecture est lui-même sujet à toute sorte d’aléas : charge mémoire
ou physique, injections SQL, failles CSRF, gestion de sessions, code source, etc. Des bancs
de test suffisants auront été établis avant de déployer l’architecture.
De même, les types d’utilisateurs de l’architecture sont nombreux, pour chacune des
technologies :
– Les propriétaires ou développeurs de systèmes : ils ont accès aux résultats de leurs
systèmes, aux données disponibles et lancent des expérimentations comme évaluations de développement ou d’expérimentation.
– Les organisateurs d’évaluations : ils ont accès aux informations relatives aux évaluations les concernant. Cela va des statistiques d’utilisation aux résultats pour lesquels
ils ont les droits d’accès. Par contre, il faut noter que les organisateurs d’évaluations
sont susceptibles de faire partie de la catégorie précédente, dans le cas de l’évaluation
d’un système isolé par exemple.
– Les administrateurs de l’architecture : ils gèrent la base de données des évaluations
et l’utilisation de l’architecture à partir d’une interface logicielle.
– Les développeurs de l’architecture : ils ont un accès restreint aux services d’évaluation pour mettre à jour le code ou pour effectuer des tests et corriger les éventuelles
erreurs.
– Des visiteurs extérieurs : on peut facilement imaginer que les résultats d’une évaluation puissent être mis à disposition d’agents extérieurs (commissions, public, etc.)
sans qu’ils aient pour autant le pouvoir de modifier les données.
Chaque type d’utilisateur possède des droits spécifiques. Il faut encore souligner l’importance de la sécurisation de l’architecture, tant au niveau interne (les différents utilisateurs) qu’externe (les agents extérieurs).
L’ensemble de ces objectifs vise à établir des évaluations pérennes et reproductibles
pour une même technologie ou pour des technologies combinées.
1. Dans le cadre d’une campagne d’évaluation par exemple, les participants n’ont pas nécessairement
la même configuration de travail.
200
7.2. Premières expériences
7.2
Premières expériences
Nous avons conçu et développé deux types d’architectures que notre modèle d’architecture finale devra regrouper :
– les architectures pour l’évaluation automatique se limitant à l’utilisation de mesures
automatiques ;
– les architectures pour l’évaluation humaine se composant d’interfaces d’aide aux
jugements humains.
Ces architectures, simples, sont à la base de notre architecture finale.
7.2.1
Architectures pour l’évaluation automatique
Comme nous l’avons mentionné précédemment, l’intérêt de développer des architectures pour l’évaluation automatique réside dans la limitation des risques d’erreurs et le
gain de temps.
Nous faisons ici état de deux expériences, la première au cours du projet TC-STAR
avec la mise en œuvre d’une chaîne de traitement en traduction de l’oral vers l’oral et
la seconde au cours du projet PASSAGE avec la mise en place d’un service d’évaluation
pour une campagne d’évaluation sur des systèmes d’analyse syntaxique.
7.2.1.1
TC-STAR
L’architecture déployée dans le projet TC-STAR repose sur le Framework UIMA, une
des premières versions développées par IBM. L’objectif était alors de créer une chaîne de
traitement expérimentale pour la traduction de l’oral vers l’oral. Elle est composée de six
Annotators :
– un pour la reconnaissance automatique de la parole ;
– un pour la traduction automatique ;
– un pour la synthèse vocale ;
– enfin, trois Annotators pour l’évaluation des trois composants précédents.
Les trois Annotators d’évaluation sont limités à la reconnaissance automatique de la
parole et la traduction automatique, auquel s’ajoute un Annotator final pour résumer et
afficher les résultats à l’utilisateur.
À travers ces technologies, UIMA permet la distribution de plusieurs systèmes et de
créer des chaînes de traitements à partir de systèmes situés sur des machines distantes.
Dans TC-STAR, plusieurs systèmes de chaque technologie étaient disponibles, autorisant
la mobilité d’un ou de plusieurs composants et le test de nombreuses chaînes de traitement
variantes.
Au-delà de l’intérêt technique, l’intérêt scientifique se trouvait dans le test et la comparaison de plusieurs chaînes fixées à l’avance et dont l’évaluation permettait d’observer
les performances en termes de qualité et de vitesse d’exécution 1 . De plus, l’architecture
étant modulaire, elle permet une évaluation en cascade de manière à observer l’impact
de technologies ou de systèmes sur d’autres. UIMA a aussi été une bonne solution pour
utiliser des systèmes ou des outils ayant été développés dans des langages distincts : C++,
Java, mais aussi Perl, Python, etc.
1. Les résultats n’étant pas publics, ils ne sont pas présentés ici.
201
Concernant l’accès aux données, nous avons développé à ELDA un serveur de téléchargement pour que les Annotators de composants, via le serveur central, puissent obtenir
les données à traiter en entrée et renvoyer les données en sortie. Les données étaient
continuellement stockées sur un serveur de données. Une série d’authentifications était
nécessaire pour pouvoir effectuer des actions sur le serveur, comme le montre la figure 7.1.
De plus, les transferts de données étaient sécurisés à l’aide du protocole HTTPS et de
règles de pare-feu définies pour les serveurs de chaque partenaire.
Figure 7.1 – Schéma d’utilisation du serveur de données dans TC-STAR.
Le développement des Annotators a été conduit par chaque participant pour la ou les
technologies le concernant. Nous nous sommes chargé du développement des Annotators
d’évaluation. Cela a nous a demandé de déployer un Analysis Engine spécifique pour
évaluation, puisque la version d’origine d’UIMA prévue pour TC-STAR était spécifique
aux Analysis Engine englobant les Annotators des trois technologies évaluées (des « Light
Annotators », sortes d’Annotators permettant aux développeurs d’inclure rapidement
leurs systèmes). Simple d’utilisation, le code existant a été partiellement réutilisé.
Après avoir déployé l’Analysis Engine spécifique aux évaluations, les Annotators d’évaluation sont développés en C++, en appelant des routines Perl puisque la majeure partie
des métriques d’évaluation sont développées dans ce langage de programmation. Les trois
Annotators d’évaluation se répartissent entre :
– un Annotator pour la reconnaissance automatique de la parole, calculant les scores
WER des sorties provenant de l’Annotator du composant correspondant en considérant ou non la casse ;
– un Annotator pour la traduction automatique, calculant les scores BLEU, WER et
202
PER des sorties provenant de l’Annotator du composant correspondant en considérant la casse ;
– un Annotator pour le formatage des données, qui collecte les scores obtenus par
chaque composant dans le CAS et les affiche sur une page HTML ; de plus, les
moyennes globales de tous les documents traités par la chaîne sont calculées, des
figures affichent les courbes de résultats au moyen de la librairie Gnuplot, et enfin
des liens envoient vers les documents traités (les fichiers d’alignement pour la reconnaissance automatique de la parole, les traductions et la référence correspondante
pour la traduction automatique, la sortie audio pour la synthèse vocale).
Les trois Annotators d’évaluation sont appelés séquentiellement, après ceux de la
chaîne de traitement.
Les métadonnées des quatre composants ont été fixées au début du projet, puis améliorées en fonction de futurs besoins. Elles respectent les standards des trois technologies
évoquées et les formats typiques utilisés pour leur évaluation. Cette standardisation a été
le rouage essentiel pour la mise en place des systèmes issus de plusieurs institutions dans
une même architecture.
Un ensemble de tests à blanc a permis d’améliorer l’ensemble de l’architecture (allant
des systèmes à l’architecture UIMA en passant par l’interface d’utilisation). Certaines
caractéristiques de l’architecture n’avaient pas été imaginés au départ : organisation des
chaînes de traitement et des évaluations, limitations technologiques (performances du
réseau, des ordinateurs et des serveurs, etc.) ou de sécurité (pare-feux, disponibilité des
Annotators distants, etc.), etc. Nous mettons par la suite tous ces aspects à profit pour
définir notre architecture d’évaluation.
7.2.1.2
PASSAGE (première campagne d’évaluation)
Dans le cadre du projet PASSAGE (Produire des Annotations Syntaxiques à Grande
Échelle pour aller de l’avant), traitant de l’évaluation des analyseurs syntaxiques du français, une plate-forme d’évaluation a été déployée [Hamon et al., 2008b] afin d’aider les
participants et les organisateurs dans leurs tâches d’évaluation 1 . Le projet fait suite aux
deux campagnes EASY [Paroubek et al., 2007] qui ont aidé à mettre en place un protocole
d’évaluation prenant en compte de manière séquentielle :
– la création d’un large corpus de textes ;
– la définition d’un guide d’annotation ;
– la constitution d’une annotation de référence sur une partie du corpus servant au
test des systèmes ;
– l’utilisation du corpus de test par des systèmes participants ;
– l’évaluation des sorties de ces systèmes sur la partie annotée du corpus de test ;
– l’extension des annotations sur l’ensemble du corpus de test en fusionnant les sorties
des analyseurs syntaxiques.
Nous ne traiterons pas ici des mesures d’évaluation [Vilnat et al., 2004b] mais de leur
intégration dans la plate-forme.
L’évaluation officielle de la première campagne d’évaluation PASSAGE adhère strictement au protocole de la campagne d’évaluation EASY [Paroubek et al., 2005] et fixe pour
1. Les différentes tâches étaient l’entraînement des systèmes d’analyse syntaxique, les tests d’interface
ou l’évaluation à proprement parler et son adjudication.
203
les corpus une segmentation en mots et en phrases que les participants doivent obligatoirement respecter. Les données utilisent le format XML avec une DTD 1 dérivée de celle
de la campagne d’évaluation EASY.
Le corpus utilisé comprend 40 000 énoncés (généralement une phrase) dont un sousensemble de 4 000 énoncés annotés a servi de référence lors de la campagne EASY. Le
corpus et ces annotations sont connus des participants et utilisés par eux pour améliorer
les performances de leur système pendant la phase de développement. À ce corpus de
4 000 énoncés, un complément d’annotations manuelles pour 400 énoncés pris dans la
partie du corpus EASY non encore annotée a été ajouté spécifiquement pour l’évaluation.
Ce complément de corpus permet de s’assurer, en partie, que les systèmes n’ont pas été
surentraînés sur le corpus de développement en vérifiant à la fin de la phase de développement que les performances obtenues sur l’ancienne référence EASY et celles obtenues
sur son complément apporté pour PASSAGE sont corrélées. Bien entendu, la validation
eût été meilleure si au lieu de réaliser des annotations de référence à partir d’énoncés
déjà connus des participants nous avions apporté un nouveau matériau annoté ; dans une
campagne d’évaluation le corpus de test doit toujours être disjoint du corpus de développement. Mais ce critère de validation nous a néanmoins paru suffire car, d’une part, les
participants n’ont de leur propre aveu pas eu le temps de modifier leur système depuis
la fin de la campagne EASY et, d’autre part, la suite des activités de PASSAGE après
cette première campagne, n’utilisera plus de segmentation en mots et en phrases définie a
priori. Pour ces raisons, il nous a paru suffisant de nous contenter d’un test de validation
sur des annotations complémentaires portant sur un matériau connu des participants.
Pour résumer, le corpus de référence de cette première campagne EASY se décompose en
trois parties :
1. Le corpus annoté manuellement, utilisé en phase de développement (quantité
moyenne : 4 000 énoncés dont le texte et les annotations sont connus des participants).
2. Le corpus complémentaire annoté manuellement, utilisé en phase de test (quantité
faible : 400 énoncés dont seul le texte est connu des participants).
3. Le corpus non annoté (quantité importante : 40 000 énoncés), qui sera utilisé pour
mener une annotation automatique de l’ensemble du corpus à l’aide de la fusion de
l’ensemble des sorties de système selon un algorithme de vote majoritaire.
C’est la première phase de développement qui est capitale et qui a nécessité la création d’une plate-forme d’évaluation accessible depuis un serveur Web commun. En effet,
un tel processus d’évaluation implique des expérimentations à répétition de la part des
participants. Celles-ci deviennent très rapidement fastidieuses à réaliser et nécessitent
l’installation et l’utilisation de la chaîne d’évaluation. La plate-forme d’évaluation leur
sert donc pour répéter ces évaluations de développement. À tout point négatif son point
positif, si nous prenons le risque d’évaluer des analyseurs surentraînés sur le corpus EASY,
nous gagnons un temps précieux lors de la phase de test. En effet, le matériau devant être
étiqueté par les participants est déjà à la disposition des participants, puis téléchargé
par leurs soins sur le serveur commun lors de chaque mesure effectuée pendant la phase
de développement ; et ainsi, la phase de test se résume simplement à lancer la chaîne
d’évaluation sur le corpus de référence complet réunissant l’ancienne référence EASY et
1. Document Type Definition.
204
les annotations complémentaires ajoutées pour la première campagne d’évaluation PASSAGE (ce qui peut être fait automatiquement et quasi instantanément).
L’impact de l’intervention de l’évaluateur est ainsi non négligeable alors que nous le
souhaitons minimal dans notre cas : la plate-forme d’évaluation doit être à même d’effectuer un maximum de tâches sans aucune intervention manuelle. Nous limitons aussi à
trois tâches les manipulations humaines des participants nécessaires aux expérimentations
sur leurs données de développement :
– envoi des fichiers destinés à être évalués ;
– démarrage d’une évaluation de développement ;
– visualisation des résultats de l’évaluation.
Le risque d’erreur potentiellement introduit par un participant lors du développement
en est d’autant réduit.
Pour la première campagne d’évaluation PASSAGE, 13 systèmes d’analyse syntaxique
ont été testés et tous ont apprécié les apports du serveur d’évaluation, à tel point que
dès la phase de test terminée, certains ont spontanément demandé à ce que le serveur
d’évaluation soit ouvert à nouveau afin de poursuivre leurs expérimentations avec les
corpus de référence et la chaîne d’évaluation. Cela a été rendu possible en conservant les
données de la campagne d’évaluation puisque le serveur d’évaluation permet de définir
plusieurs campagnes d’évaluation fonctionnant en parallèle. Plusieurs critères sont retenus
et associés à une campagne : possibilité d’établir une phase de développement, date limite
de soumission, métrique utilisée, etc.
Notre serveur d’évaluation est purement orienté Internet, si bien que les participants à
la campagne d’évaluation n’ont besoin que d’un navigateur Internet pour pouvoir charger
leurs soumissions, lancer les évaluations et obtenir les résultats. Toutes les tâches sont
effectuées à même le serveur. La plate-forme se décompose en trois parties (cf. figure 7.2).
Le serveur d’évaluation figure en partie centrale. À ce serveur se rattache le serveur de
stockage des données. Les navigateurs des participants complètent la structure, en tant
que clients : ils permettent le téléchargement des données, le démarrage des évaluations
et la consultation des résultats.
Les détails de la base de données utilisée peuvent être trouvés dans
[Hamon et al., 2008b], de même que la description des interfaces utilisateurs. Le téléchargement des données sur le serveur se fait de manière simple via des formulaires, les
données étant cryptées par transfert HTTPs. Un fichier de soumission dans un format
compressé est téléchargé, placé dans un répertoire spécifique au participant et à un identifiant d’évaluation. Le fichier est ensuite décompressé, soumis à une validation XML et
les scores sont calculés à l’aide de scripts présents eux-aussi sur le serveur. Les fichiers
d’enregistrement des résultats sont également entreposés sur le serveur d’évaluation.
Tout ceci se fait une fois que le participant s’est authentifié sur le serveur, à l’aide
d’un identifiant et d’un mot de passe. L’utilisation de l’interface d’évaluation est limitée
à une période précise pour la phase de développement 1 . Au-delà de cette date, seuls les
résultats des précédentes soumissions de développement et de la soumission de test sont
accessibles, plus aucune modification sur les soumissions effectuées n’est autorisée. De
plus, pour des contraintes d’espace disque, le nombre de soumissions de développement
était limité.
1. La date limite de soumission pour la première campagne PASSAGE était le 21 décembre 2007, à
23 h 59 CET.
205
Figure 7.2 – Architecture de la plate-forme d’évaluation.
Mis à part les fichiers XML soumis, les données relatives à l’évaluation (informations
sur les participants, résultats des évaluations, etc.) sont stockées dans une base de données
MySQL.
Techniquement parlant, la plate-forme PASSAGE est déposée sur un serveur avec des
disques RAID 1 comprenant un processeur Pentium 4 HyperThreading 3,2 GHz, une mémoire de 512 Mo, sous une distribution Linux Debian 4.0. Un espace disque de 120 Go est
alloué au serveur d’évaluation et l’interface réseau a un débit descendant de 20 Mo/s et
un débit montant de 1 Mo/s. Le débit réseau doit être suffisamment important pour des
raisons évidentes d’attente utilisateur, mais l’espace disque est aussi une des caractéristiques les plus importantes. En effet, la taille des données s’avère rapidement imposante,
d’autant que l’ensemble des données (fichiers soumis par les participants, résultats de
l’évaluation, etc.) est conservé et archivé sur le serveur d’évaluation.
Pour la première campagne PASSAGE, une seule soumission d’un système représente
environ 120 Mo, les résultats de l’évaluation prenant quant à eux, environ 70 Mo d’espace
disque. Dix évaluations de développement étant autorisées en plus de l’évaluation de test, il
est donc indispensable de réserver au minimum 30 Go rien que pour la première campagne
d’évaluation, totalisant 13 participants.
De plus, différents outils sont utilisés au sein même de la plate-forme pour les besoins de
l’évaluation : tar 1 et gzip 2 pour désarchiver et décompresser automatiquement les archives
soumises par les participants, xmllint 3 pour valider les fichiers XML soumis, Gnuplot 4
pour l’affichage des résultats en mode graphique, un script pour valider l’ordre des énoncés
contenus dans les fichiers XML, l’outil d’évaluation des annotateurs syntaxiques de la
1.
2.
3.
4.
http
http
http
http
://www.gnu.org/software/tar/tar.html
://www.gzip.org
://xmlsoft.org/xmllint.html
://www.gnuplot.info/
206
campagne EASY, ainsi que crontab 1 en tant que planificateur de tâches pour le démarrage
automatique de la phase de test.
Le serveur d’évaluation a été testé au niveau client avec les systèmes d’exploitation
Windows (versions 2000, XP), Linux (distributions Debian, Redhat) et Mac Os. Les navigateurs Firefox (version 2.0.0.8), Internet Explorer (version 6) et Epiphany (version
2.14.3) ont servi pour ces tests. Le développement du site initial a nécessité environ 80
heures de développement, auquel il faut ajouter les modifications ultérieures.
Finalement, la plate-forme d’évaluation PASSAGE a été très utilisée avec au total 167
expérimentations pour la phase de développement sur le mois et demi de disponibilité.
Les résultats des soumissions pour la phase de test ont été calculés automatiquement dès
la clôture de la phase de développement et les résultats étaient disponibles après moins
d’une heure. L’évaluation s’est ainsi faite de manière transparente et autant les participants que les organisateurs avaient accès à toutes les données relatives à l’évaluation. La
phase d’adjudication a également été rendue possible en permettant aux organisateurs de
recalculer automatiquement l’ensemble des résultats après modification de la référence.
Si le développement de notre serveur d’évaluation a été effectué pour une campagne
d’évaluation spécifique aux analyseurs syntaxiques, les principes peuvent en être étendus
à d’autres technologies, même celles utilisant éventuellement des jugements humains.
7.2.2
Architectures pour l’évaluation humaine
L’utilisation et le développement d’interfaces pour procéder à des jugements humains
permettent une réflexion quant à leur intégration dans l’architecture d’évaluation. C’est
à partir de ces expériences que nous aborderons leur mise en place dans une architecture
de plus grande importance.
A priori plus simples à mettre en place que les architectures d’évaluation automatique,
les architectures pour l’évaluation humaine n’en ont pas moins de multiples aspects. À
vrai dire, les expérimentations décrites ci-dessous sont plus des interfaces, voire des outils
en ligne, que de véritables architectures. Leur intérêt est d’amener à réduire très fortement
le risque d’erreurs. On peut aussi considérer qu’elles réduisent le travail conduit par les
juges et par l’évaluateur pour la mise en place des données, les jugements, etc.
Les expérimentations, décrites succinctement, concernent quatre interfaces développées dans le cadre de plusieurs campagnes d’évaluation. Trois des interfaces sont assez
similaires et ont été développées dans le cadre des projets CESTA, TC-STAR et EVaSY
pour l’évaluation en traduction automatique, l’évaluation en traduction de l’oral vers
l’oral et l’évaluation en synthèse de la parole. La dernière interface a été développée dans
le cadre du projet EQueR pour l’évaluation de systèmes de question-réponse et réutilisée
dans le cadre du projet CLEF.
7.2.2.1
Le projet CESTA a donné lieu au développement d’une interface pour la conduite des
jugements humains des deux campagnes d’évaluation. Celle-ci a été réutilisée et adaptée
pour les campagnes d’évaluation du projet TC-STAR. Nous en décrivons ici les différentes
caractéristiques.
1. http ://fr.wikipedia.org/wiki/Crontab
207
Notre interface d’évaluation a pour but d’aider les juges à estimer la qualité de textes
traduits qui leur sont présentés, selon les critères d’adéquation et de fluidité. Un ensemble
de phrases est donné à chaque juge qui estime phrase par phrase la qualité selon la fluidité
dans un premier temps et selon l’adéquation dans un second temps. Outre la présentation
de la phrase à juger et d’une traduction de référence (dans le cas des jugements d’adéquation), cinq choix lui sont proposés correspondant aux cinq valeurs de chaque critère.
L’objectif de développer une telle interface est de disposer à distance d’un moyen
fiable de collecter des jugements. Les juges n’ont pas nécessairement des connaissances en
informatique et l’utilisation de l’interface doit être la plus intuitive possible. Après avoir
été codée en PERL/TK [Hamon, 2004a], notre interface a été recodée en PHP/MySQL
afin de fournir à distance l’outil de collecte des jugements. L’intégration dans une base de
données à également facilité son utilisation. L’éloignement des juges ainsi que leur grand
nombre impliquaient le développement de cette interface spécifique accessible via Internet
à l’aide d’un simple navigateur. Un juge peut y accéder depuis n’importe quel système
d’exploitation Unix ou Windows. L’interface a été testée sous différentes distributions
Linux, plusieurs versions de Windows et plusieurs navigateurs tels que Netscape, Mozilla
Firefox ou Internet Explorer. En plus de la partie utilisateur, permettant la collecte des
jugements, une partie d’administration de l’interface d’évaluation a été développée en
R 1 dans un premier temps, distribuée sous licence
adaptant la solution OsCommerce
OpenGPL. Elle nous a permis de gérer les données relatives à une évaluation à savoir les
juges enregistrés, les phrases à évaluer et les jugements correspondants.
Les figures 7.3 et 7.4 montrent les pages concernant respectivement le jugement de
fluidité et le jugement d’adéquation. C’est dans ces pages que les juges estiment la qualité
des segments proposés selon les deux critères précités.
Figure 7.3 – Interface d’évaluation humaine CESTA - jugement de fluidité.
1. http ://www.oscommerce-fr.info/portail/
208
Figure 7.4 – Interface d’évaluation humaine CESTA - jugement d’adéquation.
Dans les deux cas, le segment à juger s’affiche dans la partie supérieure de la page. Pour
l’évaluation selon l’adéquation, un segment de référence, traduction du segment à juger,
s’affiche dans le bas de la page. Le juge peut alors cocher un des choix qui lui sont proposés,
parmi cinq valeurs ou niveaux de qualité. L’évaluation selon la fluidité se déroule sur la
totalité des segments proposés au juge, puis l’évaluation selon l’adéquation est effectuée
sur les mêmes segments. Mis à part les jugements à effectuer, la seule possibilité qu’a le
juge est de passer au segment suivant ou de quitter l’interface d’évaluation. Les jugements
sont enregistrés à chaque chargement d’un segment afin de ne pas perdre d’information.
Enfin, le bas de la page contient des informations sur le nombre de segments déjà jugés
ainsi qu’un lien pour envoyer un mail si le juge a une question ou un problème.
La figure 7.5 montre la page d’administration des segments à juger avec leurs identifiants, le système de traduction automatique auquel ils se rattachent, le texte correspondant, etc. Outre cette page, il est possible de gérer les informations sur les juges
(identifiant de connexion, mot de passe, mail, etc.), les évaluations conduites (faisant la
correspondance entre les identifiants de segment et les identifiants de juges, et où l’on
peut voir les jugements effectués), les informations sur les administrateurs de l’interface
ou des informations techniques sur le serveur utilisé. Plusieurs opérations sont possibles,
comme l’insertion ou la suppression de juges, de segments et de jugements, offrant ainsi
une réelle gestion de l’évaluation. L’exportation vers un fichier XML des jugements est
également possible afin de calculer les résultats par la suite.
Dans le cadre du projet TC-STAR, l’interface d’évaluation a été réutilisée et adaptée
à l’espagnol (les jugements se faisant pour la direction de traduction de l’anglais vers
l’espagnol). Au total, de nombreux jugements ont été effectués à travers cette interface et
plus de 400 juges l’ont utilisée au cours des deux projets et quatre campagnes d’évaluation.
209
Figure 7.5 – Interface d’évaluation humaine CESTA - partie administration.
7.2.2.2
Synthèse de la parole
L’interface utilisée pour les jugements de traduction automatique a été réutilisée, toujours dans le cadre du projet TC-STAR, pour l’évaluation des systèmes de synthèse de
la parole. L’adaptation a été relativement facile puisque les principes généraux restent
les mêmes : les juges écoutent des documents audio et estiment leur qualité en pointant
des valeurs sur des critères préalablement définis. Les critères étaient plus nombreux (de
l’ordre d’une dizaine), mais la principale difficulté fut d’adapter l’interface de manière à
lire les documents audio, sans perte de qualité et de manière à ne pas gêner le déroulement
de l’évaluation. Le développement d’une simple interface HTML permet de réaliser cela de
manière relativement simple, mais il faut garder à l’esprit les problèmes de compatibilité.
Dans ce cas précis, il a été décidé de n’utiliser l’interface qu’à partir de Mozilla Firefox
et non Internet Explorer, la compatibilité des deux navigateurs en termes audio restant
assez limitée puisque certaines balises à employer sont différentes.
La notion de qualité audio est aussi liée aux juges et à leur matériel : bonne écoute
à l’aide d’un casque audio et bande passante suffisamment correcte pour ne pas gêner
la lecture des documents audio. La solution utilisée et permettant la lecture en continu
(streaming) a profondément diminué les problèmes d’écoute. En effet, cette technologie
permet de compenser les faiblesses du protocole IP en permettant de démarrer l’écoute
avant que la totalité des données ne soit téléchargée.
L’interface a également été adaptée pour l’évaluation de systèmes de synthèse de la
parole dans le cadre de la campagne EVaSY [D’Alessandro et al., 2008].
210
7.2.2.3
Traduction de l’oral vers l’oral
Toujours dans le cadre du projet TC-STAR, la même interface a été réutilisée pour
l’évaluation en cascade de traduction de l’oral vers l’oral. L’objectif étant de répondre à des
questions à partir de document audio, l’évolution de l’interface n’était pas très complexe
puisqu’en lieu et place des valeurs de jugement se trouvent des boîtes de dialogue pour
répondre aux questions posées. En effet, chaque juge répond tour à tour aux questions de
trois échantillons audio différents, avec un total de 40 échantillons à juger.
L’interface, ici en espagnol, se présente sous la forme montrée dans la figure 7.6. Les
juges disposent en haut de la page des commandes pour lire le document audio, puis, en
dessous, les questions sont présentées et combinées avec des boites de dialogue pour y
répondre.
Figure 7.6 – Interface de réponse aux questionnaires TC-STAR pour l’évaluation de la
traduction de l’oral vers l’oral (en espagnol).
Il est demandé aux juges de lire le questionnaire dans un premier temps, puis d’écouter
le document audio dans un second temps, et enfin de lire le questionnaire une seconde
fois pour répondre aux questions. Ils ont également la possibilité de stopper la lecture afin
d’écrire leurs réponses.
Finalement, en bas de la page, un questionnaire de fluidité est proposé et permet de
juger de la qualité audio des documents écoutés. Quatre critères sont proposés, à chaque
fois à juger sur une échelle de cinq valeurs.
211
7.2.2.4
Question-réponse
Dans le cadre de la campagne EQueR, il nous a paru nécessaire de développer un
outil permettant à des juges d’estimer si des systèmes de question-réponse répondent aux
critères d’évaluation. Depuis une dizaine d’années, il existe plusieurs campagnes dédiées
à cette tâche : les campagnes TREC 1 au niveau international, les campagnes CLEF 2 au
niveau européen et la plus récente campagne française EQueR 3 . Dans ces campagnes,
les jugements sont souvent effectués manuellement. Mais lorsqu’il s’agit de traiter des
centaines, voire des milliers de documents, cette tâche se révèle alors difficile, d’autant
plus que les réponses aux questions comportent de nombreux jugements possibles.
Nos attentes envers outil d’aide aux jugements étaient multiples : conduire des jugements plus rapidement et aisément, systématiser l’évaluation, et finalement accroître
sa fiabilité grâce à l’automatisation de son environnement. Une interface était nécessaire
pour permettre aux juges de bénéficier d’un affichage automatique des informations de
référence par rapport aux sorties des systèmes.
À notre connaissance, un seul outil d’aide à l’évaluation de tels systèmes existe à ce
jour mais son utilisation n’est en théorie pas publique et réservée à l’institut NIST aux
États-Unis. Néanmoins, notre équipe a pu utiliser cet outil lors de la première tâche d’évaluation question-réponse de la campagne CLEF 2003. Plusieurs difficultés nous étaient
alors apparues :
– en premier lieu, cet outil ne fonctionne que sous environnement UNIX, tandis qu’au
moment où s’est déroulée la campagne d’évaluation les évaluateurs ne disposaient
que d’ordinateurs fonctionnant sous environnement Windows ;
– de plus, les fichiers nécessaires au déroulement de l’évaluation sont dépendants des
droits alloués aux juges, et de ce fait, chaque évaluateur doit posséder ses propres
fichiers, contrairement aux spécifications des tâches d’évaluation de EQueR ;
– enfin, il nous fallait adapter un outil spécifique aux campagnes TREC en fonction
des critères d’évaluation des campagnes EQueR ou CLEF, ce qui n’est pas une chose
aisée et requiert un travail conséquent.
Dans ce contexte, nous avons donc décidé de développer notre propre outil d’aide
à l’évaluation des systèmes de question-réponse : QASTLE 4 [Moreau et al., 2010]
(Question-Answering Systems TooL for Evaluation, pour « Outil pour l’Évaluation de
Systèmes de Question-Réponse »).
En évaluation de systèmes de question-réponse, la validité d’une réponse contient une
part de subjectivité. Il demeure difficile d’établir une réponse de référence, tout au plus
une liste non exhaustive, établie à partir de plusieurs systèmes. Pour la plupart des cas,
la réponse est dépendante du document dans lequel elle est trouvée. Par exemple, à la
question « Qui a gagné la Coupe du Monde de football ? », la réponse pourra dépendre de
l’année du document. Ainsi, le principe de l’évaluation des systèmes de question-réponse
paraît simple, d’un premier abord : il s’agit de décider si, pour une question donnée, la
réponse renvoyée automatiquement par un système est correcte ou non. Mais plusieurs
paramètres apparaissent et introduisent des variations dans les jugements selon :
– le type de réponse (réponse courte ou passage) ;
1.
2.
3.
4.
http
http
http
http
://trec.nist.gov
://clef.isti.cnr.it
://www.elda.org/article139.html
://www.elda.org/qastle
212
– le type de question (factuelle, liste, définition, etc.) ;
– le nombre de réponses par question que peut renvoyer le système ;
– la dépendance de la réponse au document (une réponse est alors considérée comme
correcte uniquement si elle est justifiée par un document) ;
– les jugements possibles (correct, incorrect, inexact ou incomplet, non justifié, etc.)
pour les réponses courtes et les passages ;
– l’absence d’une réponse valide dans le corpus de documents (la réponse renvoyée
par le système est alors « NIL »).
L’ensemble de ces paramètres a été pris en compte lors du développement de QASTLE
et chacun d’eux peut être utilisé sous forme d’option.
Pour utiliser l’interface, les données sont dans un premier temps préparées de manière
à installer le corpus de documents, le corpus de questions, de même que les soumissions à
évaluer. Ensuite, les documents sont indexés afin de permettre un accès plus rapide lors
de l’utilisation de l’outil. Finalement, lorsque ces deux premières étapes sont terminées,
l’outil est utilisé en chargeant un fichier de soumission.
L’interface, présentée dans la figure 7.7, se décompose en deux parties principales. La
partie gauche de l’interface permet le jugement des réponses courtes et des passages. La
partie droite permet l’affichage du document correspondant à la réponse et au passage
renvoyés par le système évalué.
Figure 7.7 – Interface d’évaluation QASTLE pour les systèmes de question-réponse.
Ainsi, le juge a accès à la question posée, à l’ensemble des réponses possibles à cette
question dans l’ordre de soumission du système évalué, au passage de la réponse sélectionnée, ainsi qu’aux boutons permettant de statuer sur le(s) jugement(s). Il peut naviguer
213
dans l’interface en choisissant la question précédente, la question suivante, ou encore en
sélectionnant directement un numéro de question. Toutefois, afin qu’aucune réponse ne
soit oubliée, un bouton permet d’accéder à l’ensemble des réponses et passages restant
encore à juger. La première réponse non jugée apparaît alors directement dans l’interface.
D’autre part, le document est affiché immédiatement après la sélection d’une nouvelle
réponse. Le juge y effectue des recherches à l’aide d’expressions régulières. Les occurrences
appariées sont alors surlignées, le curseur se plaçant directement sur la première occurrence
trouvée. Le texte correspondant à la réponse courte est également surligné dans le texte
du document lors de la sélection d’une nouvelle réponse à évaluer.
La tâche pouvant s’avérer parfois longue, une sauvegarde automatique des jugements
est effectuée à chaque clic de l’utilisateur, afin de ne perdre aucune information.
Les fichiers en sortie de l’outil sont présentés dans le même format qu’en entrée, auquel
sont ajoutés les jugements effectués. Par exemple, deux colonnes sont ajoutées automatiquement en début de chaque ligne-réponse si l’évaluation concerne les réponses courtes
et les passages : l’une pour les réponses courtes, l’autre pour les passages. Les valeurs
possibles correspondent au jugement de la réponse courte (resp. passage) et sont les suivantes : -1 si le jugement n’a pas encore été fait, 0 pour une réponse courte (resp. passage)
correcte, 1 pour une réponse courte (resp. passage) incorrecte, etc.
QASTLE a été testé pour la première fois au cours de la campagne EQueR
[Ayache et al., 2006], ensuite lors des campagnes QA@CLEF de 2006 à 2009
[Magnini et al., 2006, Giampiccolo et al., 2008, Forner et al., 2008, Turmo et al., 2009] et
enfin pour la tâche QR de CHIL 2006 [Mostefa et al., 2007b]. L’utilisation de cet outil
lors de ces campagnes, sur plus de 150 soumissions de systèmes, nous a permis de le tester
et de l’améliorer au fur et à mesure des commentaires des juges. Par exemple, nous avons
ajouté et amélioré les fonctions liées à la recherche d’expressions régulières, à la validation
finale du fichier évalué, ou encore à la mise en surbrillance de la réponse sélectionnée. Ces
modifications ont permis d’obtenir un gain appréciable de temps lors de l’évaluation.
Chaque campagne d’évaluation ayant des contraintes bien spécifiques, nous avons
adapté et modifié l’outil pour chacune d’entre elles. Par exemple, la campagne d’évaluation CLEF 2005 reposait uniquement sur les réponses courtes, mais en tenant compte
du passage, tandis que, dans EQueR, la réponse courte et le passage ont été évalués séparément. Les boutons de jugement du passage ont alors dû être supprimés pour CLEF
2005, tout en laissant l’affichage du passage correspondant à la réponse courte. Ces modifications sont disponibles sous forme d’option dans la version actuelle de QASTLE. Ainsi,
le type de campagne peut être sélectionné via un fichier de configuration et les options de
l’outil sont modifiées en conséquence.
Suite aux diverses expérimentations, nous voyons plusieurs avantages à l’utilisation de
cet outil :
– au niveau informatique, cet outil est facilement modifiable, peu gourmand en ressources, et présente une installation pratique et facile ;
– au niveau des jugements humains, il permet d’économiser un temps non négligeable
et de fiabiliser les résultats en limitant les erreurs dues à l’intervention humaine.
Il serait possible d’améliorer l’outil en y incluant le calcul des scores parmi ses fonctionnalités puisque la plupart des outils de calcul sont disponibles.
214
7.2.3
Discussion
Le développement et l’étude d’interfaces ou d’architectures d’évaluation nous a permis
d’acquérir certaines pratiques pour mettre en place des évaluations génériques et pérennes
et en saisir certains mécanismes. Nous savons maintenant comment mettre en place une
architecture simple pour une technologie donnée. L’exemple de PASSAGE pour une plateforme de métriques automatiques est aisément reproductible pour une autre technologie,
de même que l’interface d’aide aux jugements développée pour CESTA et déjà réutilisée.
L’objectif est dorénavant d’aller au-delà de ces architectures.
Les avantages d’une architecture d’évaluation, même la plus simple possible, sont indéniables. Nous avons pu l’observer avec PASSAGE au niveau de la qualité, avec TC-STAR
au niveau technique. Les différentes interfaces d’évaluation humaine nous ont montré qu’il
est possible d’automatiser les procédures pour une meilleure efficacité.
Par l’utilisation d’architectures d’évaluation, il est possible d’améliorer des systèmes
de TAL grâce notamment aux évaluations répétées et plus rapidement menées à bien. Le
suivi des erreurs permet de travailler plus efficacement à partir des sorties du système :
en présentant rapidement une synthèse des résultats, des résultats plus détaillés ou une
analyse d’erreurs, les développeurs effectuent des corrections et des modifications plus
facilement.
La centralisation des informations, données et mesures d’évaluation permet une
meilleure cohésion lors d’une campagne d’évaluation et un meilleur équilibre entre partenaires. De plus, le stockage des données, centralisé, évite la dispersion de plusieurs versions
d’une même ressource.
La consultation quasi instantanée des résultats, que ce soit pour le développement ou
le test des systèmes, donne aux développeurs d’un système un aperçu de la qualité de
leur système actuel, et non d’une version datant de plusieurs semaines, voire de plusieurs
mois.
L’aspect modulaire d’une architecture permet l’enchaînement et la combinaison de
technologies ainsi que les commutations entre systèmes d’une même technologie. Cela rend
possible la mesure de l’impact d’un module spécifique sur la sortie finale d’un système
utilisant plusieurs technologies.
Pourtant, les diverses expérimentations conduites n’ont pas répondu à tous les objectifs
et ont même soulevé de nouvelles questions, essentiellement d’ordre technique :
– Les interventions manuelles peuvent être intégrées à l’architecture en automatisant
les tâches, à commencer par le lancement des évaluations et le calcul des résultats.
Mais il faut également penser à la validation des données, la réutilisation des références, le stockage des données, le stockage des informations et de l’historique, etc.
– La compatibilité et l’homogénéisation des formats : le fait d’utiliser une architecture
d’évaluation signifie que plusieurs organismes s’en serviront pour évaluer plusieurs
systèmes. Ils utiliseront plus ou moins les mêmes formats de données sans qu’ils
soient forcément identiques. Trois solutions sont alors possibles : soit les organismes
adaptent leurs systèmes à un même format, soit plusieurs formats sont acceptés
par l’architecture, ou une solution intermédiaire propose des outils de conversion.
La troisième solution nous semble être la meilleure car elle satisfait la majorité des
utilisateurs, en cherchant toutefois à tendre vers une uniformatisation des formats.
– La taille des données, les ressources mémoire et la bande passante : elles influent sur
la configuration matérielle de l’architecture, mais aussi sur le temps de réponse à
215
ses utilisateurs. La qualité du service proposé va dépendre de leur prise en compte.
– La vitesse d’évaluation : les outils d’évaluation ont des performances variables en
termes de temps de calcul. Tout utilisateur doit obtenir des informations sur l’évolution de la procédure d’évaluation. Dans le cas d’un temps de traitement trop
important, il est envisageable d’envoyer des notifications par e-mail en laissant les
processus s’appliquer en tâche de fond.
– La combinaison de composants technologiques : différents modules sont à prendre en
compte lors du déploiement de l’architecture. Cela concerne les échanges de données
entre composants, mais aussi la capacité de l’architecture à gérer des combinaisons
de modules. Nous considérons que l’intégration des composants technologiques dans
la plate-forme est une option qui pourrait se révéler très utile.
– La portabilité des interfaces : de la même manière, plusieurs organismes étant susceptibles d’utiliser l’architecture, leur environnement de travail n’est pas forcément
le même. Il est par conséquent nécessaire d’avoir des interfaces suffisamment portables pour que chacun puisse les utiliser sans qu’elles gênent leur travail.
– La sécurité de l’architecture et la sécurisation des données : c’est un point essentiel lorsqu’une architecture est envisagée pour des évaluations multiples, et lorsque
plusieurs organismes l’utilisent. Il en va de l’intégrité des données, informations et
résultats des systèmes. Ainsi, des droits utilisateurs sont créés, les ressources matérielles et logicielles sont sécurisées, les données sont identifiées, etc.
Surtout, des interfaces d’évaluation humaine peuvent elles aussi être intégrées à l’architecture. Il faut garder à l’esprit que cela nécessite de définir de nouveaux protocoles et
de revoir l’organisation de l’évaluation. En effet, l’intégration d’une interface d’évaluation
humaine implique d’avoir des juges à disposition dans un laps de temps relativement court,
à partir du moment où les données sont disponibles aux jugements. L’intégration automatique des données et la répartition parmi n juges ne posent pas de problème (parce
que des outils automatiques existent déjà). La principale contrainte est de prendre en
compte la disponibilité des juges : la mise à disposition d’un jeu de données à évaluer ne
signifie pas nécessairement qu’un juge puisse effectuer ses jugements dans l’immédiat. Par
contre, il est facile de calculer en temps réel les résultats d’une soumission dès lors que les
jugements sont finalisés.
Dans la section suivante, nous tentons de répondre à ces questions en présentant notre
proposition d’architecture.
7.3
Proposition d’une architecture d’évaluation
Les sections précédentes ont permis d’identifier la plupart des points qui permettent
de définir notre architecture d’évaluation. Les avantages qu’elle doit procurer sont désormais connus, de même que les difficultés majeures. Dans cette section, nous proposons la
définition d’une architecture d’évaluation générique et pérenne. Dans une première partie,
nous synthétisons les spécifications fonctionnelles de l’architecture. Puis, à partir de cette
base, nous formulons ses spécifications techniques. Nous formalisons ces deux points dans
une troisième partie concernant la modélisation de notre architecture d’évaluation. En vue
d’un développement futur, nous précisons quel est l’environnement de développement que
nous envisageons d’utiliser. Finalement, nous discutons les apports d’une telle réflexion.
216
7.3. Proposition d’une architecture d’évaluation
7.3.1
Spécifications fonctionnelles
7.3.1.1
Caractéristiques
Nous abordons dans cette section l’architecture d’un point de vue fonctionnel. Pour
ce faire, nous prenons en compte les chapitres précédents en ce qui concerne 1 :
– les phases d’une évaluation : apprentissage, réglage, test à blanc, test, analyse des
résultats, adjudication, constitution de ressources linguistiques, préparation de l’évaluation ;
– la gestion des ressources linguistiques : constitution de ressources (données d’apprentissage, de réglage, de test à blanc et de test, références, etc.), stockage des
données (temporaire ou non), validation du format des données ;
– l’intégration des mesures d’évaluation : automatiques et humaines ;
– le stockage des résultats de l’évaluation afin d’être rendu visible dans un second
temps ;
– la méta-évaluation des mesures ;
– le paramétrage des évaluations ;
– la combinaison de technologies et son évaluation ;
– la spécification des types d’évaluation : boîte noire, boîte transparente ou en cascade
(cf. tableau 2.5) ;
– la spécification des méthodes d’évaluation : comparative ou système isolé (cf. tableau
2.5) ;
– la présentation et la visualisation des résultats, notamment pour l’analyse des résultats et la phase d’adjudication ;
– l’intégration de systèmes de TAL (version étendue. Par défaut, la version minimale
interagit avec l’utilisateur) ;
À partir de la plupart de ces points, la figure 7.8 présente le schéma fonctionnel de
l’architecture, en reprenant la figure 2.5
Nous considérons deux versions de l’architecture : minimale et étendue. La version
étendue ajoute la gestion des systèmes de TAL dans des chaînes d’évaluation, le développement étant plus conséquent (à la fois pour l’évaluateur et pour le participant). L’idéal
est donc d’avoir une architecture étendue.
Dans un premier temps, la définition de l’architecture d’évaluation passe par la décision
d’une distribution minimale ou étendue. L’un ou l’autre choix se fait selon la présence
(architecture minimale, telle celle de PASSAGE) ou non (architecture étendue, telle celle
de TC-STAR) de systèmes de TAL dans la chaîne de traitement automatique. Dans le
cadre d’une architecture minimale l’utilisation des systèmes se fait manuellement en marge
de la chaîne de traitement. Cette décision est cruciale dans notre architecture car elle
influence deux variables : le niveau d’utilisation de l’architecture (c’est-à-dire par rapport
aux entrées et sorties du serveur d’évaluation) et de manière plus conséquente le coût de
développement puisqu’il faut pouvoir inclure les systèmes à la plate-forme. L’utilisateur
a alors le choix de proposer des données à évaluer via une interface ou de démarrer une
chaîne de traitement automatiquement via une seconde interface.
1. Les quatre niveaux d’évaluation (technologie, usage, impact et diagnostic) et les deux critères d’évaluation (extrinsèque, intrinsèque) correspondent à des situations et n’influent pas sur l’aspect fonctionnel
de l’architecture d’évaluation (cf. tableau 2.5).
217
Figure 7.8 – Schéma fonctionnel de l’architecture. en gris la version étendue de l’architecture intégrant les systèmes de TAL.
218
Ainsi, soit l’utilisateur du service d’évaluation fournit des données destinées à des
systèmes de TAL qui sont traitées puis évaluées, soit il lance une chaîne de traitement
qui produit des données qui sont directement évaluées. L’organisateur, sous couvert d’un
accord avec le participant 1 spécifie les paramètres de l’évaluation dans la plate-forme
(a priori ou non, l’évaluation pouvant se conduire après le dépôt des données). Ces paramètres servent à définir en détails l’évaluation que ce soit en termes de données, de
protocole, d’outils, de chaîne de traitement, etc. Ainsi, en fonction de la ou des technologie(s) évaluée(s), l’organisateur sélectionne les critères adéquats pour mener à bien
l’évaluation. Par exemple, en traduction automatique, il choisit le type de mesure(s) pour
évaluer les systèmes puis, le cas échéant, les métriques automatiques et/ou les métriques
humaines qui sont utilisées. Leurs critères sont également définis. L’organisateur choisit
de valider ou non les données, de stocker ou non les résultats. Il définit les différentes
étapes de l’évaluation et les différents modules utilisés dans la chaîne de traitement. En
résumé, un arbre de décision est parcouru pour créer le contexte de l’évaluation.
La spécification de mesures d’évaluation (cf. figure 2.4) amène parfois à des étapes
pouvant être mises en parallèle, puisque plusieurs métriques (humaine ou automatique)
peuvent être lancées sans attendre que les unes ou les autres soient terminées. Le stockage
des résultats s’effectue alors au fur et à mesure qu’une métrique est terminée.
C’est également le cas lorsque plusieurs technologies sont traitées dans une chaîne
d’évaluation : les mesures propres à chaque technologie peuvent être démarrées en parallèle
et même à partir du moment où les résultats sont disponibles pour une technologie donnée.
Le protocole s’applique de la même manière que ce soit pour l’évaluation d’une technologie
seule ou pour l’évaluation d’une combinaison de technologies. Nous notons toutefois que
les mesures d’évaluation peuvent être différentes dans l’un ou l’autre des cas puisqu’il
peut être nécessaire de prendre en compte les autres technologies combinées.
Nous traitons dans les sections suivantes trois cas particuliers de fonctionnalités de
notre architecture d’évaluation : l’intégration de métriques automatiques, l’intégration de
métriques humaines et la méta-évaluation des métriques.
7.3.1.2
Intégration de métriques automatiques
L’existence de métriques automatiques favorise le déploiement d’une architecture
d’évaluation car leur intégration est d’ordre technique (l’humain n’entre pas, ou peu,
en jeu). Leur utilisation est d’autant plus aisée après validation du format des données
évaluées. Cette dernière permet l’usage d’outils automatiques sans presque aucune crainte.
Ils envoient aussi bien des résultats, chiffrés, que des données ou informations pour une
analyse d’erreurs. Toutes ces informations et données sont destinées à être gérées par
notre plate-forme d’évaluation qui se charge de les stocker et de les mettre à disposition
des utilisateurs intéressés.
Les métriques automatiques utilisées par les services d’évaluation se distinguent selon
deux catégories : celles présentées comme étant des métriques « par défaut » et celles
disponibles en option. Ces dernières permettent de proposer des métriques expérimentales
et moins robustes.
1. généralement sous le format d’une « licence »
219
7.3.1.3
Intégration de métriques humaines
L’utilisation de mesures humaines est le talon d’Achille de notre architecture d’évaluation et ralentit indéniablement le processus d’évaluation. Lorsque la chaîne de traitement
arrive aux métriques impliquant des jugements humains, l’étape attribuée aux juges agit
comme un goulot d’étranglement. Pourtant, une grande part des actions sont automatisables : le formatage des données, la mise en place des interfaces d’évaluation, le formatage
des résultats, voire le contact des juges humains, etc. L’évaluateur, à travers l’architecture
d’évaluation doit attendre les résultats qui seront calculés indépendamment de la chaîne
de traitement. Pour limiter l’attente utilisateur, la mise à disposition des résultats est
différée.
Dans un premier temps, l’évaluation dans l’architecture est limitée par le recrutement
des juges. Dans un second temps, elle dépend de la durée de réalisation des jugements
humains pour l’estimation de la qualité des données.
Il n’est pas toujours facile de planifier le recrutement des juges, ni même leur nombre.
Dans le cadre de campagnes d’évaluation, le nombre de systèmes évalués est souvent
fixé à l’avance, mais le nombre de soumissions par système ne l’est pas toujours. Et
dans le cas de l’évaluation simple d’un système, la partie humaine doit être prévue à
l’avance : cela va quelque peu à l’encontre d’un service automatisé et libre d’accès. Ainsi,
le recrutement dépend de la quantité de données, leur spécificité, la période de réalisation
des jugements 1 , etc.
Par ailleurs, il est parfois difficile d’estimer le temps nécessaire aux jugements. Cela
dépend des données (taille, technologie, complexité, etc.) comme des utilisateurs, et si
l’état de l’art donne parfois un aperçu de leur durée, ce temps varie indépendamment
d’une évaluation à une autre.
Si la mise en place de l’évaluation humaine au sein d’une architecture automatisée est
difficile, elle n’est pas impossible. L’aspect relatif aux juges est prépondérant et ne doit
pas être sous-estimé. Mais dès lors que les paramètres nécessaires sont pris en compte il
ne reste plus qu’à prévoir un délai de mise à disposition des résultats.
7.3.1.4
Méta-évaluation des métriques
L’architecture d’évaluation permettant le traitement des données par plusieurs métriques en même temps, automatiques et humaines, le travail de méta-évaluation s’en
trouve simplifié. En effet, nous avons vu la méta-évaluation comme étant le fruit de trois
méthodes principales de calcul :
– un calcul de corrélation comparant les résultats des métriques automatiques à ceux
des métriques humaines ;
– un rééchantillonnage des données, automatique lui aussi, qui permet un calcul de la
robustesse des métriques ;
– un calcul d’accord inter-juges ou intra-juge, spécifiques aux métriques humaines.
Les méthodes de méta-évaluation sont donc d’ores et déjà automatiques et viennent
facilement s’intégrer à la plate-forme d’évaluation. Le point le plus important concerne la
planification de la méta-évaluation, puisqu’il faut attendre que les résultats des métriques
humaines soient calculés (compte-tenu des délais de jugement).
1. Il faut par exemple penser aux périodes de vacances scolaires ou d’examens pour le recrutement
d’étudiants !
220
7.3.2
Spécifications techniques
Les aspects techniques à prendre en compte pour le déploiement de notre architecture
sont relativement importants. Les choix à faire ne sont pas triviaux et nécessitent de
prendre en compte les spécifications fonctionnelles.
Les détails techniques peuvent être autant matériels (notamment pour les ressources)
que logiciels (essentiellement pour les mesures et les outils de développement). Pourtant,
le fait d’automatiser les tâches impose de prendre des décisions plus rapidement. Par
exemple, dans le premier cas, si un corpus est trop volumineux pour être téléchargé sur
un disque dur, il est toujours possible de racheter un disque dur plus gros dans un laps
de temps réduit. Avec une architecture automatisée, le même corpus serait impossible à
télécharger sans une vérification humaine : l’utilisateur recevrait alors une notification
d’erreur. Dans cet exemple, il est bon d’avoir suffisamment à l’avance une estimation de
la place que prendraient des données.
Le fait est que l’automatisation demande une planification accrue, et impose de
connaître les risques d’erreur à l’avance. La gestion en temps réel par l’évaluateur n’est
pas réaliste et l’architecture n’a pas les capacités de résoudre des problèmes qui lui sont
inconnus.
7.3.2.1
Caractéristiques générales
De nombreux défis techniques sont à relever pour le déploiement de notre architecture :
– Transferts de données et d’informations : l’évaluation se déroule autour de nombreuses phases. Entre chaque phase un volume élevé de données et d’informations
sont copiées et/ou transférées d’un module de l’architecture à un autre, d’un serveur
à un autre, entre un client et un serveur, etc. La plate-forme d’évaluation est capable
de transférer l’ensemble des données requises. Dans le cas contraire, une notification
est formulée.
– Format des données : vouloir tendre vers un format homogène de données pour un
même domaine relève de l’utopie. Étant donné le nombre d’acteurs du domaine et
leur manque de concertation, il s’avère difficile de regrouper les entrées et sorties de
systèmes autour d’un même format unifié (des contre-exemples existent, comme en
traduction automatique dans le cadre des campagnes d’évaluation). Il s’agit ici de
permettre au mieux l’utilisation des formats les plus employés, voire de permettre
l’intégration de nouveaux formats.
– Mise en place du matériel : l’installation de l’architecture comprend celle des serveurs
centraux et celle des ordinateurs distants. L’utilisation d’un réseau implique des
configurations propres à chaque ordinateur ou serveur ; différents droits d’accès sont
mis en place.
– Compatibilité des configurations : l’utilisation de l’architecture amène à utiliser
différentes configurations, ne serait-ce que des environnements utilisateurs tels que
des systèmes d’exploitation Unix (les différentes distributions Linux amenant déjà
à des spécificités), Windows, Mac, etc. Les outils employés modifient également les
spécifications de configuration.
– Différences entre langages de programmation : les outils existants utilisés dans l’architecture, ou par les utilisateurs, ne sont pas forcément développés dans un même
langage de programmation. Il peut être parfois complexe et coûteux de convertir son
221
code dans un langage unifié dans l’architecture. De même, l’intégration de ces outils
par un simple appel peut réduire les performances. L’architecture doit permettre
l’utilisation d’un grand nombre de langages de programmation, sans pour autant
amoindrir les performances (cf. section 7.3.4).
– Sécurisation des données : les données transitant dans l’architecture doivent être
sécurisées, de même que les systèmes lorsque cela est nécessaire (lors d’accès réservés
par exemple). Des mesures d’authentification sont obligatoires pour s’en assurer et
le développement de l’architecture et de ses systèmes se fait en conséquence.
– Interfaces : plusieurs interfaces viennent agrémenter l’architecture que ce soit pour
les utilisateurs, les développeurs, les organisateurs, etc. Les spécificités de ces interfaces sont dépendantes du domaine (par exemple, l’analyse d’erreur n’est pas la
même pour une analyseur syntaxique que pour un système de traduction automatique) même si nous avons présenté des similarités (cf. chapitre 6).
– Notifications d’erreur : nous ne pouvons prétendre à l’absence d’erreurs pour quelque
architecture que ce soit. Bien souvent, des cas d’utilisation n’ont pas été imaginés.
Il va de soi que les utilisations successives sont surveillées afin d’aider à la résolution
des erreurs rencontrées. De même, ces dernières font l’objet d’un traitement spécifique afin de ne pas perturber les utilisateurs, mais aussi pour ne pas surprendre le
développeur par des cas complexes à résoudre. Ainsi, à chaque erreur d’utilisation
rencontrée, un rapport est enregistré, voire notifié aux développeurs de l’architecture
ou de ses systèmes. De plus, un grand nombre de cas de figure doit être envisagé
afin de ne pas laisser l’utilisateur dans l’impasse.
– Robustesse de l’ensemble : le passage par un réseau, la lourdeur du matériel et des
outils imposent d’être très vigilant face à la robustesse de l’architecture. Des tests
extrêmes sont menés de manière à connaître ses limites : tests de charge, utilisation
du réseau, capacité des matériels, etc.
– Validation de l’architecture : la démarche de développement d’un « produit » ne peut
se faire sans validation des spécifications techniques et fonctionnelles. La validation
est aussi bien menée pendant la phase de développement qu’après, tant qu’elle se
fait avant la phase d’utilisation finale.
Chacune des parties techniques pose des problèmes différents d’autant que les solutions
proposées ne sont généralement pas uniques afin de pouvoir s’adapter au maximum de
configurations possibles.
Nous étudions dans les sections suivantes quelques cas techniques particuliers : l’utilisation des ressources linguistiques, l’intégration de métriques automatiques et l’intégration
de métriques humaines.
7.3.2.2
Utilisation des ressources linguistiques
Les ressources exploitées au sein de l’architecture et leur stockage implique un matériel
et un protocole de transfert de fichiers adéquats. Le matériel de stockage dépend fortement du volume type des données, ainsi que du nombre d’évaluations conduites et de ses
caractéristiques. Compte tenu des besoins croissants des systèmes, notamment en termes
de développement ou d’apprentissage, le stockage des soumissions des participants peut
être limité. Par exemple, dans le cadre de la première campagne PASSAGE, l’estimation
minimale était de 30 Go sur l’ensemble des participants. Il n’est pas difficile d’imaginer
que pour d’autres campagnes, par exemple traitant de l’audio, les données soient d’une
222
taille de 10, voire 100 fois plus importantes 1 . Et que dire si les évaluations se multiplient,
ou même si l’architecture est laissée en « libre service » ? Ce qui semble minime au premier
abord peut vite devenir envahissant au cours du temps. Il est légitime de prévoir les cas
extrêmes.
Le transfert de fichier s’avère problématique lorsqu’il s’agit de transférer des données
de taille importante par HTTP (plus exactement HTTPS pour les transferts sécurisés).
Les taux de transfert ne sont à l’heure actuelle pas suffisamment importants pour tout
le monde et gênent la soumission de résultats par exemple. L’intégrité des données est
également en jeu lors du transfert de gros volumes notamment. De par notre expérience
au cours de la seconde campagne PASSAGE (avec l’usage et le transfert de gros volumes
de données), nous estimons que le protocole HTTP n’est pas assez robuste. Il empêche
notamment le transfert de fichiers dépassant une taille de 2 Go. Nous suggérons donc
l’utilisation d’autres moyens de transfert de données, par exemple FTP.
L’utilisation de ressources implique également une réflexion concernant l’annotation
des fichiers et la conservation des informations ajoutées. Il est parfaitement envisageable,
comme ce fut le cas dans TC-STAR, que les annotations fassent partie de l’architecture,
dans le sens où les données sont représentées sous forme d’objets. Des informations sont
alors ajoutées en fonction de l’analyse effectuée. En ce sens, le standard XML est l’idéal
pour la représentation des données utilisées dans la plate-forme.
Finalement, concernant les ressources, le mode de gestion des soumissions a également
son importance : outre leur volume et la manière de les représenter, le stockage est fait
soit par la gestion de fichiers soit par base de données. Dans PASSAGE nous avons
choisi la première solution, plus par facilité car cette manière nous semble plus proche
de la tâche. Toutefois, l’usage d’une base de données nous semble plus adaptée pour la
gestion de nombreuses occurrences. L’avantage est double, puisque l’accès est plus rapide
et l’organisation plus robuste. Toutefois, dans le cas d’un stockage de gros fichiers, il peut
être envisageable de revenir à une solution de stockage de fichiers.
7.3.2.3
Intégration de métriques automatiques
L’intégration technique de métriques automatiques n’est pas aussi simple qu’il y paraît.
Tous les cas d’erreurs n’ont pas toujours été prévus : volume des données dépassant les
limites en mémoire ou en stockage 2 , mauvaise langue attribuée, changements de format
de dernière minute 3 , etc. Lorsque cela arrive, le suivi des erreurs est indispensable et
nécessite une intervention humaine. De plus, l’intégration des mesures automatiques peut
être coûteuse et nécessiter de gros besoins pour adapter le code, le format des données, etc.
Enfin, l’architecture se voulant générique et pérenne, il faut penser aux multiples formats
d’utilisation possibles, à leur possibilités d’évolution, mais aussi aux capacités d’utilisation
à long terme (telles que les ressources en mémoire, la réutilisation de données ou l’injection
de nouvelles, etc.)
1. Lors de la seconde campagne PASSAGE, la soumission compressée d’un seul participant dépassait
les 2 Go.
2. Il nous est par exemple arrivé de « découvrir » des phrases dépassant les 1 000 mots –des transcriptions de discours oraux– pour des systèmes pouvant supporter au mieux 250 mots.
3. L’évaluateur ne pense pas forcément à tout...
223
7.3.2.4
Intégration de métriques humaines
En suivant les fonctionnalités propres à l’intégration des métriques humaines (cf. section 7.3.1.3), il est facile d’imaginer comment une évaluation humaine se déroule au sein
de notre architecture d’évaluation. Il suffit pour cela d’adopter des procédures strictes
dès que les données sont mises à disposition. Ces dernières sont tout d’abord formatées
pour être injectées dans une base de données, reliée à une interface de jugements humains. Ensuite, les données sont réparties entre les différents juges qui sont contactés.
Le contact peut se faire automatiquement par e-mail, à partir du moment où les juges
sont connus et déjà recrutés. Les jugements humains peuvent alors s’effectuer de manière
désynchronisée de la procédure d’évaluation à l’aide de l’interface de jugements humains.
Lorsque les jugements sont terminés, l’interface d’évaluation interagit directement avec le
serveur d’évaluation afin de signaler la reprise de la procédure d’évaluation. Une synthèse
des résultats est alors calculée. Les données de jugements sont, elles, collectées et entreposées afin d’être mises à disposition des utilisateurs. Finalement, une notification est
envoyée à ces derniers et/ou aux organisateurs pour qu’ils puissent accéder à l’ensemble
des informations disponibles.
7.3.3
Modélisation
7.3.3.1
Alternatives
Au regard des différentes hypothèses et expérimentations présentées précédemment,
trois alternatives nous semblent envisageables pour modéliser notre architecture d’évaluation (cf. figure 7.9) :
– Architecture centralisée : un serveur unique d’un côté, centralisant l’ensemble des
données et des opérations, et des utilisateurs passifs d’un autre côté, en tant que
clients. En d’autres termes, les utilisateurs n’ont que la possibilité d’envoyer leurs
soumissions pour recevoir des résultats d’évaluation.
– Architecture semi-distribuée : un serveur se focalisant uniquement sur l’évaluation,
dont les processus d’évaluation sont appelés par des applets entreposés chez les
utilisateurs.
– Architecture distribuée : un serveur centralisant les informations et répartissant les
tâches sur plusieurs autres serveurs dédiés à des tâches bien spécifiques : chaque
utilisateur (actif) adapte son système au format du serveur, de même que pour les
organisateurs d’évaluation en ce qui concerne les métriques d’évaluation. Aucune
opération n’est réellement effectuée sur le serveur central.
La première solution est celle entreprise dans le cadre du projet PASSAGE, la dernière
celle utilisée dans le projet TC-STAR avec UIMA. Techniquement parlant, la première
solution est la plus simple à déployer et sans doute la moins coûteuse. Par contre, il
faut adapter l’architecture à chaque nouvelle technologie évaluée, voire à chaque nouvelle
évaluation.
Dans le cas d’une architecture à plus grande échelle et se voulant pérenne, c’est la
troisième solution qui paraît être la plus satisfaisante. À noter qu’un modèle de type peerto-peer n’est pas un modèle envisageable dans notre cas du fait de la taille des données,
des temps de calcul et d’une attente utilisateur accrue.
224
Figure 7.9 – Alternatives d’architectures d’évaluation.
7.3.3.2
Solution adoptée
L’activité d’évaluation en traitement automatique des langues requiert de plus en
plus l’enchaînement de technologies et l’application de méthodes automatisées. L’emploi
d’architectures distribuées plus évoluées est devenu une ressource indispensable pour agir
plus librement et plus rapidement. C’est désormais un objectif largement accessible avec
le développement constant de métriques automatiques, mais aussi et surtout le transfert
de données de plus en plus volumineuses via Internet permettant le transfert de fichiers
et l’accès à distance de systèmes modulaires.
Nous avons déjà abordé le cas des architectures modulaires et distribuées, comme les
environnements GATE ou UIMA, qu’il est possible de modifier à sa guise. Pas forcément
utilisée via Internet, l’intégration de systèmes rend inévitable le déploiement d’architectures sur le réseau. De telles entreprises se font de plus en plus sur des sites distants.
Chaque institution souhaite généralement conserver la main sur ses propres données et
systèmes, d’autant plus dans un contexte industriel. Le concept d’une évaluation automatisée est aussi en grande part nécessaire à distance. Cela se produit notamment lorsque
l’évaluateur n’est pas le développeur du système évalué.
Cela signifie que notre modèle d’architecture permet les interactions entre systèmes
ainsi qu’avec les modules d’évaluation. Cela se fait entre autres grâce à une couche intermédiaire de normalisation des données utilisées.
Nous proposons une plate-forme d’évaluation reposant sur plusieurs couches, à savoir :
– une base de stockage des données utilisées et retournées par les modules applicatifs ;
– un serveur de centralisation des opérations effectuées par les chaînes de traitement ;
225
– un serveur centralisant le développement de ressources dédiées à l’évaluation ;
– des modules contenant les systèmes ou les métriques d’évaluation ;
– une interface de contrôle des flux et des données ;
– une interface de paramétrage.
Par ailleurs, nous définissons différents types de modules permettant au choix, d’observer, de stocker ou de transformer les données. Les modules interagissent entre eux,
combinent des technologies et sont évalués (sous forme combinée ou non).
Notre modélisation d’architecture se construit sur les bases d’une distribution autour
d’un serveur central, chaque module étant successivement appelé pour conduire une tâche
prédéterminée. Cela se justifie d’une part par le besoin de centraliser les données et informations lors d’une campagne d’évaluation, mais aussi le souhait de conserver l’impartialité
de l’évaluation en ne conservant qu’un évaluateur indépendant des systèmes évalués. Nous
pensons que l’emploi d’une grande quantité de ressources, d’outils et de données communs, ainsi que l’utilisation d’un protocole similaire au gré des évaluations nécessitent
une centralisation des éléments de l’évaluation axée autour d’un point central. Toutefois,
l’architecture générale se développe autour d’un serveur d’évaluation couplé à un serveur
de ressources chacun d’entre eux ayant leurs propres caractéristiques techniques selon
leurs tâches. Différents modules de différentes natures et fonctions se connectent alors sur
ce ou ces points centraux.Le schéma de cette architecture est visible en figure 7.10
Figure 7.10 – Combinaison d’une architecture d’évaluation et d’une architecture de production de ressources.
De même, nous souhaitons intégrer une interface d’adjudication à la plate-forme d’évaluation tel qu’il est possible de le voir dans la figure 7.8.
226
La définition de cette architecture fait immédiatement penser aux services Web dont
le principe est d’interconnecter des systèmes entre eux et/ou d’y accéder via le réseau.
Pour ce faire, divers protocoles et standards sont utilisés afin de faciliter les échanges de
données dont le contenu est spécifié dans un format de codage particulier. Ce dernier point
est important, puisqu’il facilite la connexion d’un système par la compréhension unique
de l’architecture, par exemple symbolisée par des spécifications XML.
D’un point de vue applicatif, une occurrence d’évaluation se déroule telle que présentée
dans la figure 7.11.
Figure 7.11 – Une occurrence d’évaluation au sein de l’architecture.
L’organisation d’une évaluation se fait selon un cheminement précis décidé par l’utilisateur de la chaîne de traitement (organisateur, participant, développeur...). Plusieurs
composants sont associés au traitement de l’évaluation.
Point central de la plate-forme d’évaluation, et donc de l’architecture, le gestionnaire
de flux de données gère la chaîne de traitement. Il assure la transmission des données entre
les différents composants de l’architecture, d’après une chaîne de traitement commandée
par l’utilisateur et impliquant plusieurs tâches applicatives. C’est le gestionnaire de flux
de données qui détermine quels sont les modules à utiliser en fonction des demandes de
l’utilisateur et leur attribue un rôle.
Les services Web interagissent alors avec les systèmes enregistrés pour effectuer la
tâche désirée. Au fur et à mesure que le gestionnaire de flux de données parcourt la chaîne
de traitement, des services Web sont appelés tandis que d’autres, inutiles, sont laissés
de côté. Dans ce schéma applicatif, une tâche concerne autant un système de traitement
227
automatique des langues qu’un outil d’évaluation.
Le gestionnaire de tâches est associé à une interface utilisateur et permet de configurer
et d’initier la chaîne de traitement. Il envoie les informations concernant cette chaîne
au gestionnaire de flux de données et accède aux résultats du traitement. Les résultats
peuvent être les « scores » mêmes de l’évaluation, mais aussi les données (par exemple la
référence utilisée ou le rapport d’une analyse d’erreurs). En fin de chaîne, le gestionnaire
de tâches permet, toujours via l’interface utilisateur, de mettre à disposition les résultats
de l’évaluation.
L’annuaire de services Web et les annuaires de systèmes stockent et recensent respectivement les services Web disponibles et les systèmes associés à ces services Web (et
pour une tâche donnée). Les annuaires contiennent des informations telles que les formats
d’entrée et de sortie, les méthodes d’accès ou les spécifications techniques. D’autres informations moins indispensables sont incluses comme le contact du développeur, le nom du
composant, le nombre d’utilisations, etc.
Enfin, même s’il ne sont pas des composants à part entière, le mécanisme de transfert
des données (par FTP) ou les outils de résolution de problème (rapports d’erreur, correction de données, interactions entre développeurs et utilisateurs, etc.) font également
partie de la plate-forme d’évaluation.
7.3.4
Environnement de développement
L’environnement de développement a son importance et nécessite de faire des choix.
Ces derniers dépendent de plusieurs critères : les ressources déjà disponibles et réutilisables, les connaissances des développeurs et / ou des utilisateurs et les différentes possibilités qu’offrent ces environnements.
7.3.4.1
Alternatives
Si la plupart des langages de programmation sont utilisables pour une architecture
utilisant le réseau, certains y sont tout de même plus adaptés. Citons parmi les plus
connus : PHP, Python, PERL/CGI, Java, Javascript, C ou encore C++. Le PHP est une
solution de « facilité » dû à son déploiement simple, mais il nous semble moins fiable que
le C++ ou le Java, plus robustes et rapides et avec plus de possibilités.
L’utilisation du XML pour la déclaration des modules est idéale, puisque leurs caractéristiques seront reconnues quel que soit le langage utilisé.
Le développement de l’architecture passe par l’utilisation de bibliothèques d’outils,
mais aussi et surtout par la réutilisation d’environnement de développements ou d’interfaces de programmation (API) préconçus. Ils évitent de repartir de zéro mais nécessitent
généralement un développement supplémentaire. Là encore, plusieurs possibilités s’offrent
à nous. Il s’agit de procédures, fonctions ou classes (au sens informatique) qui sont partagées via une bibliothèque. Il est toutefois nécessaire d’adapter ces bibliothèques aux
besoins de l’architecture, l’ensemble API/architecture permet l’interopérabilité des modules s’y rattachant, à partir du moment où les entités sont connues (et documentées).
Ainsi, les interfaces de programmation permettent tout de même l’interopérabilité de
modules, systèmes ou outils. En ce qui nous concerne, trois interfaces de programmation
ont retenu notre attention : RMI, Corba et JMS.
228
RMI (Remote Method Invocation) est spécifique à un seul langage, Java. Des procédures et des objets sont enregistrés sur une machine distante et sont appelés lorsqu’un
client cherche à les utiliser. Les échanges se font à l’aide du protocole HTTP et permettent
la distribution des processus dans une architecture de type client/serveur.
Le « concurrent » de RMI le plus direct est CORBA (Common Object Request Broker Architecture) et associe C++ et Java. C’est une architecture qui associe un modèle
générique de communication (Object Model), un service central de distribution des messages (Objet Request Broker ), des gestionnaires de fonction pour gérer les objets (Object
Services) et des utilitaires appelés par des systèmes (Common Facilities). Les processus
sont également appelés de manière distribuée, depuis des machines distantes.
Le JMS (Java Message Service) est, tout comme RMI, spécifique à Java. Les échanges
se font de manière asynchrone, c’est-à-dire qu’ils ne se font pas directement entre les
systèmes, mais via un intermédiaire qui envoie les informations lorsque les systèmes sont
disponibles.
Malgré leurs qualités (en particulier les performances et la rapidité d’accès, comparées
à celles des services Web présentés plus loin), ces trois API ne sont pas exemptes de
défauts : CORBA est trop lourd et RMI et JMS sont spécifiques à un seul langage.
Cela pose déjà des contraintes non négligeables comme nous l’avons vu dans les sections
précédentes.
La notion d’API, utilisant Internet, est étroitement liée à celle des services Web. L’intérêt d’une interface Web pour l’utilisation d’outils existe, mais reste limité lorsqu’il s’agit
d’en intégrer de nouveaux, ou de modifier l’existant. Il apparaît alors que l’accès aux fonctionnalités d’un service Web est plus complet et intéressant d’un point de vue fonctionnel
s’il se fait à l’aide d’une API.
Les services Web, contrairement aux interfaces de programmation citées plus haut,
ont pour principal intérêt d’être indépendants du langage de programmation. Ainsi, les
paramètres utilisés sont encodés en XML, que chaque système utilise. C’est cette partie
commune à tout langage qui permet l’interopérabilité des systèmes. De plus, les échanges
se font par via le réseau, tout en utilisant les technologies Internet. Ils permettent alors
des accès à distance.
Un « annuaire universel » l’UDDI (Universal Description Discovery and Integration)
permet d’enregistrer les services Web disponibles afin d’être localisés par des systèmes
tiers, à travers le réseau Internet. De plus, les échanges se font à l’aide du protocole SOAP
(Simple Object Access Protocol) permettant l’accès à des procédures distantes, encodant
les paramètres en XML pour la partie client et les décodant pour la partie serveur. Enfin,
le langage WSDL (Web Service Description Language) décrit les API des services Web et
tous leurs paramètres. Cette description est issue du langage XML.
C’est ainsi que des architectures de type UIMA, GATE, ou encore OpenNLP sont
développées sur la base de services Web.
7.3.4.2
Solution envisagée
Nous envisageons d’utiliser UIMA pour le développement de notre architecture, et ce
pour quatre raisons principales. Tout d’abord, le degré de maturité d’UIMA est maintenant assez avancé dans sa version Apache, et les problèmes de départ, que nous avons
connu avec TC-STAR, semblent loin. Ensuite, UIMA bénéficie d’une importante communauté, sans doute du fait de sa disponibilité Open-Source et de sa maintenance active. De
229
plus, UIMA utilise tout ce qui a trait aux services Web et correspond ainsi parfaitement
à la modélisation que nous avons proposée. Enfin, UIMA fournit une architecture « clé
en main » qui, après une période d’adaptation, permet d’obtenir des résultats rapides.
7.4
Discussion et conclusion
Le déploiement de notre architecture d’évaluation reste ouvert aux diverses formes de
procédures des technologies du traitement automatique des langues. Faute de temps et par
manque de projets spécifiques à ELDA, nous n’avons malheureusement pas pu entamer
son développement. Malgré tout, les premières expérimentations nous permettent d’avoir
des plate-formes déjà utilisables en l’état.
Comme le montre la figure 7.8 notre architecture générique et pérenne ne se limite
pas à une seule plate-forme d’évaluation : un serveur de ressources facilitant la création
de l’ensemble des ressources nécessaires à l’évaluation (données sources ou de référence,
données texte ou audio, données annotées, etc.) et d’une interface d’adjudication pour
la vérification des résultats de l’évaluation. Nous avons également réfléchi à l’ajout de
modules de méta-évaluation de manière similaire aux métriques d’évaluation, tels des
services Web. Ceux-ci s’ajoutent à une chaîne de traitement classique.
Finalement, après avoir défini notre architecture d’évaluation, nous souhaitons réfléchir aux différents moyens de valider sa pertinence. Ici, c’est l’utilisation de l’architecture
qui est en jeu, et non les résultats obtenus. Les mesures et métriques sont méta-évaluées,
les juges sont mis en corrélation, les protocoles contrôlés et tout comme les ressources,
validés, etc. Mais l’architecture a pour seule nécessité de satisfaire les utilisateurs en leur
facilitant la tâche. Ici, nous ne tenons pas compte de possibles erreurs informatiques qui
ne seraient dues qu’à la simple technicité de l’architecture. C’est donc par cette seule
particularité que nous souhaitons valider l’architecture : l’utilisation par des participants,
des développeurs de système, des organisateurs d’évaluation, etc. Bref, tout utilisateur
susceptible un jour ou l’autre d’être en contact avec l’architecture d’évaluation, comme
nous avons pu déjà le faire dans le projet PASSAGE. D’une manière générale, des questionnaires de satisfaction peuvent être produits à intervalles régulier afin d’interroger les
utilisateurs, connaître leurs besoins et les fonctionnalités les satisfaisant. En allant plus
loin et en complexifiant nos capacités à valider, c’est aussi la pérennisation de l’architecture qui prouve la capacité à satisfaire ses utilisateurs.
230
Chapitre 8
Conclusions et travaux futurs
Dans ce chapitre, nous présentons les principales contributions de cette thèse ainsi que
les perspectives. Nous résumons en premier lieu les principales réflexions, expérimentations
et résultats qui ont été produits.
8.1
Résumé
Nous avons traité de l’évaluation du traitement automatique des langues afin d’en
intégrer ses composantes dans une architecture générique et pérenne. Notre thèse s’axe
autour de trois thèmes principaux : la méthodologie, la généralisation à travers plusieurs
technologies et l’automatisation.
8.1.1
Méthodologie
Dans un premier temps, nous avons étudié le déroulement typique d’une évaluation et
en avons proposé une synthèse. Dans celle-ci, nous considérons l’évaluation d’un point de
vue pratique. C’est en effet notre principale préoccupation pour la mise en œuvre d’une
évaluation au sein de notre architecture.
Nous avons renforcé la place des ressources linguistiques dans l’évaluation : leur intérêt
est capital puisqu’elles sont le support par lequel les systèmes sont évalués. Les différentes
étapes pour obtenir une ressource linguistique utilisable ont été formulées. Nous avons
également souligné l’impact des ressources linguistiques sur l’évaluation. Malgré tout,
nous avons prouvé à travers une expérimentation que ce n’est pas toujours le cas.
L’étude des mesures humaines et des mesures automatiques nous a permis d’établir
leurs avantages et inconvénients. L’utilisation de l’une ou l’autre des mesures est dépendante des résultats de l’évaluation que l’évaluateur attend. Nous avons observé à travers
un certain nombre d’expérimentations que les choses ne sont pas figées et que de nombreux paramètres viennent perturber l’évaluation. C’est avant tout l’interprétation des
résultats qui compte.
Enfin, nous avons précisé les moyens de méta-évaluer les mesures, qu’elles soient humaines ou automatiques. Différentes procédures et méthodes ont été décrites afin de mesurer la fiablité et la robustesse de métriques.
231
Chapitre 8 : Conclusions et travaux futurs
8.1.2
Généralisation
À travers toutes nos études et expérimentations, nous avons cherché à généraliser
l’évaluation du point de vue de sa méthodologie et de sa mise en œuvre.
Ainsi, la plupart des procédures d’évaluations se déroulent de la même manière et
autour de deux phases principales : la préparation de l’évaluation et son exécution.
De plus, nous avons vu que des ressources linguistiques peuvent être réutilisées d’une
évaluation à une autre (les données de test ne devant toutefois pas être connues des
systèmes) et être partagées entre différentes technologies.
La réutilisation d’interfaces et de mesures ou métriques est également un élément
important en évaluation de systèmes de TAL. Nous avons adapté, par exemple, des interfaces de jugements à des technologies différentes et des métriques ont été utilisées pour
des technologies dont les approches étaient similaires. La mesure de la qualité pour deux
technologies différentes ne signifie pas que les métriques et protocoles sont eux-mêmes
différents. C’est d’autant plus le cas lorsque des campagnes d’évaluation sont reproduites
pour une même technologie : les spécifications et les outils utilisés sont les mêmes la
plupart du temps.
L’étude de ces généralisations a été approfondie au cours d’une réflexion sur les similarités entre technologies et surtout entre évaluations de technologies différentes. Nous
avons alors obtenus une classification des technologies et de leur mesures d’évaluation.
8.1.3
Automatisation
La troisième grande étape de notre thèse concerne l’automatisation de l’évaluation en
vue d’une incorporation dans une architecture.
Le plus simple semble l’utilisation de métriques automatiques. Toutefois, nous remarquons que leur fiabilité prête généralement à discussion et qu’elle dépend du contexte
de l’évaluation réalisée. Ensuite, nous ne savons pas toujours exactement ce que les métriques fournissent comme résultats, et cela implique d’analyser plus en détails les données
évaluées. Enfin, les métriques automatiques sont tout de même dépendantes de parties
manuelles : les références sont établies à l’aide d’experts et sont indispensables. L’inverse
reviendrait à ce que les systèmes puissent intégrer une métrique entièrement automatique.
Les jugements humains sont eux aussi automatisables, et ce de deux manières. D’une
part, la recherche pousse à reproduire des jugements humains de manière automatique, à
l’aide de métriques automatiques. Nous avons étudié différentes possibilités en traduction
automatique et en extraction terminologique. Les résultats nous ont montré la difficulté
à agir de la sorte. Pourtant, de nombreuses métriques automatiques existent par ailleurs
et ont des résultats encourageants, voire suffisants. D’autre part, les jugements humains
sont automatisables via des interfaces de jugements qui aident les juges humains dans
leur tâche. La mise en place des données, la collecte des données et le calcul des résultats
sont des actions qui sont toutes automatisables.
Nous avons proposé la modélisation d’une architecture qui inclue les différentes possibilités d’automatisation de l’évaluation. Elle s’appuie sur des expérimentations que nous
avons pu réaliser. Les promesses d’une telle architecture sont importantes : vitesse d’acquisition des résultats, reproductibilité des évaluations, accessibilité et visibilité accrues,
etc.
232
8.2. Principaux développements
8.2
Principaux développements
Cette thèse nous a poussé à réaliser plusieurs développement dans le cadre de projets
d’évaluation. Ces développements ont pu être testés via des campagnes d’évaluation.
Tout d’abord, nous avons développé des interfaces de jugements humains. Relativement simples à concevoir, elles ont été d’un grand apport pour faciliter la collecte des
jugements et le calcul des résultats. Elles constituent en cela une économie de temps non
négligeable. Nous avons ainsi développé des interfaces de jugements pour les technologies
suivantes : traduction automatique, question-réponse, synthèse vocale, traduction de l’oral
vers l’oral. Au total, plus d’une dizaine de campagnes ont utilisé l’une de ces interfaces.
Ensuite, nous avons expérimenté des métriques automatiques. Le X-Score nous a permis d’explorer les possibilités d’estimer automatiquement la fluidité d’un texte traduit
automatiquement. La métrique est peu fiable à l’heure actuelle mais les champs de recherche restent ouverts. Notre évaluation automatique en extraction terminologique est
aussi à un état intermédiaire de fiabilité et nous continuons à étudier les différentes possibilités.
Il faut également noter que nous avons développé nos propres versions des mWER
(multiple reference Word Error Rate), mPER (multiple reference Position independant
word Error Rate) et mCER (multiple reference Character Error Rate) pour la traduction
automatique. Par ailleurs, nous avons testé et étudié quelques unes des métriques utilisées
pour l’évaluation des systèmes de traduction automatique.
Enfin, nous avons eu l’occasion à travers deux projets (TC-STAR pour la traduction
de l’oral vers l’oral et PASSAGE pour l’analyse syntaxique) de développer ou de participer
au développement de deux plates-formes d’évaluation. Dans le cadre de TC-STAR, nous
avons participé au développement de composants d’évaluation au sein d’une architecture
UIMA. Bien que cela n’ait pas donné suite à une plate-forme pérenne, ce développement
nous a permis de comprendre davantage les mécanismes d’une architecture d’évaluation.
Nous avons mis à profit cette expérience dans le cadre de PASSAGE avec une plate-forme
dédiée. Celle-ci a été utilisée au cours de deux campagnes d’évaluation par plusieurs
participants. Le gain de temps a été appréciable notamment pour la première campagne
d’évaluation, autant pour les organisateurs que pour les participants. Les résultats de la
seconde campagne ont été plus nuancés, des difficultés techniques ayant émergé face au
volume des données.
8.3
Perspectives
Les perspectives que notre thèse annonce font suite aux points mentionnés ci-dessus.
L’étude des mesures d’évaluation a soulevé de nouvelles questions. Les jugements humains
sont, semble-t-il, très liés aux aspects psychologiques et culturels des juges : l’observation
de la qualité des systèmes à un niveau utilisateur apporte une grande part de variabilité
dans les mesures humaines qui deviennent alors moins pertinentes ou moins objectives.
La difficulté de prédire (automatiquement) les jugements humains s’en trouve alors décuplée. L’organisation d’évaluations utilisant des mesures humaines est relativement facile à
mettre en place. Pourtant, la définition des critères de jugement reste complexe : l’interprétation des résultats n’en est que plus difficile mais il faut alors banaliser leur analyse
détaillée.
233
Chapitre 8 : Conclusions et travaux futurs
Les métriques automatiques sont un cas particulier en évaluation. Elles peuvent être
satisfaisantes mais l’évaluateur sait toujours qu’elles ne sont pas exemptes de défauts et
d’approximations. Cela justifie une interprétation des résultats en conséquence. Pourtant,
il faut améliorer le développement de métriques automatiques car elles permettent la
reproductibilité des évaluations. Une des perspectives de cette thèse est donc de continuer
l’effort pour trouver de nouvelles métriques automatiques et/ou améliorer celles existantes,
pour quelque technologie que ce soit.
Pour continuer dans ce sens, notre thèse a pointé des cas particuliers comme exemples
d’expérimentations et il est bon de continuer l’effort pour d’autres technologies et d’autres
domaines. Plus les cas seront multipliés et plus les approches apporteront à l’évaluation en
TAL. L’exploration de mesures pour des technologies moins étudiées pourra ainsi apporter
de nouvelles approches aux technologies plus avancées. Cela rejoint l’idée d’étudier les
similarités en évaluation de technologies du TAL : la complémentarité des technologies ne
peut être que bénéfique.
Finalement, le développement d’une architecture complète, générique et pérenne pour
l’évaluation en traitement automatique des langues reste à faire. L’accent devra être mis
sur les limites technologiques : lorsque de grandes quantités de données sont utilisées,
comme par exemple en recherche d’information, les limites de l’informatique sont mises
à rude épreuve. L’évaluation n’a pas pour unique but la mesure de la qualité mais est
également concernée par la vitesse d’échange des données et leur traitement, le niveau de
stockage, et toutes les performances technologiques qui lui sont liées.
Le fait de posséder une architecture d’évaluation, permettant la répétition d’évaluations à loisir, accroît la possibilité de mener des « méga-évaluations ». Celle-ci sont nécessaires pour l’observation de l’évolution d’un domaine ou d’une technologie. Ainsi, par
un effort répété d’évaluations sur une longue période, généralement sur une même base
de données, il peut être prouvé qu’une technologie est mature, ou en passe de l’être. Nous
avons pu faire cette expérience dans le cadre de TC-STAR dans lequel, sur trois années
consécutives d’évaluation, les trois versions de chaque système de traduction automatique
ont été évaluées sur un même jeu de données. Il était alors clair que les systèmes avaient
progressé.
Une architecture d’évaluation est non seulement importante pour ses apports industriels, mais elle apporte également une réflexion sur l’évaluation en elle-même. Elle permet
la combinaison de technologies, ce qui présente un indéniable intérêt quant aux procédures
à adopter. De fait, cela amène à réfléchir à de nouvelles méthodes d’évaluation, de nouvelles mesures et métriques, tandis que l’analyse qui en découle est enrichie de nouveaux
paramètres. Le gain d’une architecture d’évaluation est important, de par la reproduction des évaluations et l’automatisation de leur exécution. Cette dernière apporte quant
à elle l’obligation de formaliser les méthodologies d’évaluation, ce qui s’associe à d’autant plus de rigueur dans les choix effectués. Finalement, prendre comme cas d’étude le
traitement automatique des langues dans son ensemble amène à comparer les différentes
technologies entre elles, leurs problématiques et leurs mesures d’évaluation. C’est en capitalisant l’évaluation à l’aide d’une architecture que des familles de technologies peuvent
être construites, et les mesures rapprochées pour ces technologies.
234
Bibliographie
[Adda et al., 1999] Adda, G., Mariani, J., Paroubek, P., Rajman, M. et Lecomte,
J. (1999). L’action GRACE d’évaluation de l’assignation de parties du discours pour
le français. Langues, 2(2):119–129.
[Agarwal et Lavie, 2008] Agarwal, A. et Lavie, A. (2008). Meteor, M-BLEU and MTER : Evaluation Metrics for High-Correlation with Human Rankings of Machine
Translation Output. In Proceedings of the Third Workshop on Statistical Machine
Translation, pages 115–118, Columbus, Ohio. Association for Computational Linguistics.
[ALPAC, 1966] ALPAC (1966). Language and machines : computers in translation and
linguistics. Rapport technique, Automatic Language Processing Advisory Committee,
Washington DC, National Academy of Sciences.
[Amar et al., 2001] Amar, M., Béguin, A., De Brito, M., David, S., L’Homme, M.C., Mustafa El Hadi, W. et Paroubek, P. (2001). Rapport final AUF ARC A1 :
Évaluation d’outils d’aide à la Construction Automatique de Terminologie et de Relations Sémantiques entre termes à partir de corpus. Rapport technique, Université
Charles-de-Gaulle, Lille-3.
[Amigó et al., 2005a] Amigó, E., Gonzalo, J., Peñas, A. et Verdejo, F. (2005a). Evaluating DUC 2004 with QARLA Framework. In Proceedings of the ACL’05 Workshop
on Intrinsic and Extrinsic Evaluation Measures for MT and/or Summarization, pages
49–56, Ann Arbor, Michigan.
[Amigó et al., 2005b] Amigó, E., Gonzalo, J., Peñas, A. et Verdejo, F. (2005b).
QARLA : a Framework for the Evaluation of Text Summarization Systems. In Proceedings of the 43rd Annual Meeting of the Association for Computational Linguistics
(ACL 2005), pages 280–289, Ann Arbor, Michigan.
[Arranz et Choukri, 2010] Arranz, V. et Choukri, K. (2010). ELRA’s Services 15
Years on...Sharing and Anticipating the Community. In Proceedings of the Seventh
conference on International Language Resources and Evaluation (LREC’10), Valletta,
Malta. European Language Resources Association (ELRA).
[Arranz et al., 2007] Arranz, V., Mapelli, V. et Mazo, H. (2007). The ELRA Newsletter. ELRA. ISSN 1026-8200.
[Ayache et al., 2006] Ayache, C., Grau, B. et Vilnat, A. (2006). EQueR/EVALDA,
the French Evaluation Campaign of Question-Answering System. In Proceedings of the
5th International Conference on Language Resources and Evaluation, Genoa, Italy.
[Babych et Hartley, 2004] Babych, B. et Hartley, A. (2004). Extending the BLEU
MT evaluation method with frequency weightings. In ACL’04 : Proceedings of the
235
BIBLIOGRAPHIE
42nd Annual Meeting on Association for Computational Linguistics, pages 621–628,
Morristown, NJ, USA. Association for Computational Linguistics.
[Babych et al., 2003] Babych, B., Hartley, A. et Atwell, E. (2003). Statistical modelling of mt output corpora for information extraction. In Lancaster University (UK,
page 31.
[Babych et al., 2005] Babych, B., Hartley, A. et Elliott, D. (2005). Estimating the
predictive power of n-gram MT evaluation metrics across language and text types. In
Proceedings of the MT Summit X, pages 412–418, Phuket, Thailand.
[Banchs et al., 2006] Banchs, R. E., Bonafonte, A. et Pérez, J. (2006). Acceptance
Testing of a Spoken Language Translation System. In Proceedings of the 5th International Conference on Language Resources and Evaluation, pages 1157–1160, Genoa,
Italy.
[Banerjee et Lavie, 2005] Banerjee, S. et Lavie, A. (2005). METEOR : An automatic metric for MT evaluation with improved correlation with human judgments. In
Proceedings of the ACL Workshop on Intrinsic and Extrinsic Evaluation Measures for
Machine Translation and/or Summarization, pages 65–72, Ann Arbor, Michigan. Association for Computational Linguistics.
[Bar-Hillel, 1953] Bar-Hillel, Y. (1953). The present State of Research on Mechanical
Translation [1951]. American Documentation, 2:229–237.
[Béguin et al., 1997] Béguin, A., Jouis, C. et Mustafa El Hadi, W. (1997). Evaluation d’outils d’aide à la construction de terminologie et de relations sémantiques entre
termes à partir de corpus. In JST’97, FRANCIL, AUPELF-UREF, pages 419–426,
Avignon, France.
[Benzitoun et Véronis, 2005] Benzitoun, C. et Véronis, J. (2005). Problèmes d’annotation d’un corpus oral dans le cadre de la campagne EASY. In Actes des Ateliers de
la 12ème Conférence annuelle sur le Traitement Automatique des Langues Naturelles
(TALN 2005), pages 13–16, Dourdan, France.
[Bernsen et al., 1999] Bernsen, N. O., Blasband, M., Calzolari, N., Chanod, J.-P.,
Choukri, K., Dybkjær, L., Gaizauskas, R., Krauwer, S., Lamberterie, I. d.,
Mariani, J., Netter, K., Paroubek, P., Rajman, M. et Zampolli, A. (1999).
A Blueprint for a General Infrastructure for Natural Language Processing Systems
Evaluation Using Semi-Automatic Quantitative Black Box Approach in a Multilingual
Environment, Deliverable D1.1 ELSE Project - Evaluation in Language and Speech
Engineering LE4-8340. Rapport technique, LIMSI, Paris.
[Besançon et al., 2008] Besançon, R., Chaudiron, S., Mostefa, D., Hamon, O., Timimi, I. et Choukri, K. (2008). Overview of CLEF 2008 INFILE pilot track. In
Working notes for the CLEF 2008 workshop, ECDL conference, pages 939–946, Aarhus, Denmark.
[Bisani et Ney, 2008] Bisani, M. et Ney, H. (2008). Joint-sequence models for graphemeto-phoneme conversion. Speech Communication, 50(5):434–451.
[Black et al., 1991] Black, W. J., Allwood, J., Bunt, H. C., Dols, F. J. H., Donzella, C., Ferrari, G., Gallagher, J., Haidan, R., Imlah, B., Jokinell, K.,
Lancel, J.-m., Nivre, J., Sabah, G. et Wachtel, T. (1991). A Pragmatics-based
Language Understanding System. In Proceedings of the ESPRIT Conference 1991.
236
BIBLIOGRAPHIE
[Blanchon et Boitet, 2007] Blanchon, H. et Boitet, C. (2007). Pour l’évaluation externe des systèmes de TAL par des méthodes fondées sur la tâche. TAL, 48(1):33–65.
[Blanchon et al., 2004] Blanchon, H., Boitet, C., Brunet-Manquat, F., Tomokiyo, M., Hamon, A., Hung, V. T. et Bey, Y. (2004). Towards Fairer Evaluations
of Commercial MT Systems on Basic Travel Expressions Corpora. In Proceedings of
IWSLT 2004 (ICLSP 2004 Satellite Workshop), pages 21–26, Kyoto, Japan.
[Bonafonte et al., 2006] Bonafonte, A., Agüero, P. D., Adell, J., Pérez, J. et Moreno, A. (2006). Ogmios : The UPC Text-to-Speech Synthesis System for Spoken
Translation. In Proceedings of the TC-STAR Workshop on Speech-to-Speech Translation, pages 31–36, Barcelona, Spain.
[Bourigault et Habert, 1998] Bourigault, D. et Habert, B. (1998). Evaluation of Terminology Extractors : Principles and Experiments. In Proceedings of the first International Conference on Language Resources and Evaluation (LREC), pages 299–305,
Granada, Spain.
[Braschler, 2000] Braschler, M. (2000). CLEF 2000 - Overview of Results. In CLEF,
pages 89–101.
[Brill, 1995] Brill, E. (1995). Transformation-Based Error-Driven Learning and Natural Language Processing : A Case Study in Part of Speech Tagging. Computational
Linguistics, pages 543–565.
[Burnard et al., 1998] Burnard, L., Baker, P., McEnery, A. et Andrew, W. (1998).
Validation of Linguistic Corpora. Rapport technique, European Language Resources
Association, Paris.
[Callison-Burch et al., 2007] Callison-Burch, C., Fordyce, C. S., Koehn, P., Monz,
C. et Schroeder, J. (2007). (Meta-) Evaluation of Machine Translation. In Proceedings of Second Workshop on Statistical Machine Translation, pages 136–158, Prague,
Czech Republic.
[Callison-Burch et al., 2009] Callison-Burch, C., Koehn, P., Monz, C. et Schroeder, J. (2009). Findings of the 2009 Workshop on Statistical Machine Translation.
In Proceedings of the Fourth Workshop on Statistical Machine Translation, pages 1–28,
Athens, Greece. Association for Computational Linguistics.
[Callison-Burch et al., 2006] Callison-Burch, C., Osborne, M. et Koehn, P. (2006).
Re-evaluating the role of bleu in machine translation research. In EACL, pages 249–256.
[Carroll, 1966] Carroll, J. B. (1966). An experiment in evaluating the quality of translations. Mechanical Translation and Computational Linguistics, 9(3 and 4):55–66.
[Carroll et al., 2002] Carroll, J. B., Frank, A., Lin, D., Prescher, D. et Uszkoreit,
H. (2002). Toward improved evaluation measures for parsing systems. In Proceedings
of the Workshop Beyond Parseval at the 3rd International Conference on Language
Resources and Evaluation (LREC), pages 1–3, Las Palmas, Spain.
[Cerbah et Daille, 2006] Cerbah, F. et Daille, B. (2006). Une architecture de services
pour mieux spécialiser les processus d’acquisition terminologique. Traitement Automatique des Langues (TAL), 47(3):39–61.
[Chaudiron et Choukri, 2008a] Chaudiron, S. et Choukri, K. (2008a). L’évaluation :
fondements, processus et résultats, pages 23–45. Hermès, Lavoisier, Paris. ISBN 978-27462-1992-2.
237
BIBLIOGRAPHIE
[Chaudiron et Choukri, 2008b] Chaudiron, S. et Choukri, K. (2008b). L’évaluation
des technologies de traitement de la langue. Hermès, Lavoisier, Paris. ISBN 978-2-74621992-2.
[Choukri, 2005] Choukri, K. (2005). L’apport des campagnes Evalda à l’évaluation de
technologies. In Journée Technolangue et Technovision sur l’évaluation des technologies, Colloque ASTI 2005, page 40, Clermont Ferrand.
[Cleverdon, 1967] Cleverdon, C. W. (1967). The Cranfield tests on index language
devices. Aslib, 19(6):173–194.
[Cleverdon et al., 1966] Cleverdon, C. W., Mills, J. et Keen, M. (1966). Factors
determining the performance of indexing systems. Rapport technique, Aslib Cranfield
Project.
[Cohen, 1960] Cohen, J. (1960). A coefficient of agreement for nominal scales. Educational and Psychological Measurement, 20(1):37–46.
[Cole et al., 1995] Cole, R. A., Mariani, J., Uszkoreit, H., Zaenen, A. et Zue, V.
(1995). Survey of the State of the Art in Human Language Technology. Center for
Spoken Language Understanding CSLU, Carnegie Mellon University, Pittsburgh, PA.
[Cori et Léon, 2002] Cori, M. et Léon, J. (2002). La constitution du TAL, Étude historique des dénominations et des concepts. TAL, 43(3):21–55.
[Cunningham et al., 2002] Cunningham, H., Maynard, D., Bontcheva, K. et Tablan, V. (2002). GATE : an architecture for development of robust HLT applications.
In ACL ’02 : Proceedings of the 40th Annual Meeting on Association for Computational Linguistics, pages 168–175, Morristown, NJ, USA. Association for Computational
Linguistics.
[Cunningham et al., 1996] Cunningham, H., Wilks, Y. et Gaizauskas, R. (1996).
GATE – a General Architecture for Text Engineering. In Proceedings of the 16th
Conference on Computational Linguistics (COLING-96), pages 1057–1060, Copenhagen.
[Daille, 2002] Daille, B. (2002). Découvertes linguistiques en corpus. Dossier de synthèse
des activités de recherche en vue de l’obtention du diplôme d’Habilitation à Diriger des
Recherches. Rapport technique.
[Dale et al., 2000] Dale, R., Moisl, H. et Harold, S. (2000). Handbook of Natural
Language Processing. Marcel Dekker, New York, NY.
[D’Alessandro et al., 2008] D’Alessandro, C., Boula de Mareüil, P., Garcia, M.-N.,
Bailly, G., Morel, M., Alexander, R., Béchet, F., Véronis, J. et Prudon, R.
(2008). La campagne EvaSy d’évaluation de la synthèse de la parole á partir du texte,
pages 183–206. Hermès, Lavoisier, Paris. ISBN 978-2-7462-1992-2.
[Déchelotte et al., 2006] Déchelotte, D., Schwenk, H. et Gauvain, J.-L. (2006). The
2006 LIMSI Statistical Machine Translation System for TC-STAR. In Proceedings of the
TC-STAR Workshop on Speech-to-Speech Translation, pages 25–30, Barcelona, Spain.
[Declerck, 2006] Declerck, T. (2006). SynAF : towards a Standard for syntactic annotation. In In proceedings of the fifth international conference on Language Resources
and Evaluation (LREC 2006), pages 36–43, Genoa, Italy. ELRA.
238
BIBLIOGRAPHIE
[Déjean et Gaussier, 2002] Déjean, H. et Gaussier, E. (2002). Une nouvelle approche
à l’extraction de lexique bilingues à partir de corpus comparables. Lexicometrica, No
spécial 2002:22.
[Di Nunzio et Ferro, 2006] Di Nunzio, G. M. et Ferro, N. (2006). Scientific evaluation
of a dlms : A service for evaluating information access components. In Proceedings
of the 10th European Conference for Digital Libraries (ECDL 2006), pages 536–539,
Alicante, Spain.
[Dijk, 2007] Dijk, B. V. (2007). Technologies de la langue en Europe : marché et tendances, 2005-2006. Rapport technique, Bureau Van Dijk.
[Doddington, 2002] Doddington, G. (2002). Automatic evaluation of machine translation quality using n-gram co-occurrence statistics. In Proceedings of ARPA Workshop
on Human Language Technology, pages 138–145.
[Eck et Hori, 2005] Eck, M. et Hori, C. (2005). Overview of the IWSLT 2005 Evaluation
Campaign. In International Workshop on Spoken Language Translation : Evaluation
Campaign on Spoken Language Translation, page 22, Pittsburgh, PA, USA.
[Efron et Gong, 1983] Efron, B. et Gong, G. (1983). A leisurely look at the bootstrap,
the jackknife, and cross-validation. The American Statistician, 37(1):36–48.
[Estrella, 2008] Estrella, P. (2008). Evaluating Machine Translation in Context : Metrics and tools. Thèse de doctorat, Université de Genè, École de traduction et d’interprétation.
[Estrella et al., 2007] Estrella, P., Hamon, O. et Popescu-Belis, A. (2007). How
Much Data is Needed for Reliable MT Evaluation ? Using Bootstrapping to Study
Human and Automatic Metrics. In Proceedings of the MT Summit XI, pages 167–174,
Copenhagen, Denmark.
[Fairon et al., 2006] Fairon, C., Klein, J.-R. et Paumier, S. (2006). SMS pour la
science. Corpus de 30.000 SMS et logiciel de consultation, volume 3.2 de Cahiers du
CENTAL. IGMLP-UCL.
[Fanta et al., 2007] Fanta, M., Fleury, P., Kleindienst, J. et Macek, T. (2007).
Overview of WP5 : Architecture and Showcases. In Proceedings of the TC-STAR
Workshop, page 23, Aachen, Germany.
[Feinstein et Cicchetti, 1990] Feinstein, A. R. et Cicchetti, D. V. (1990). High agreement but low kappa : I. The problems of Two Paradoxes. J. Clin. Epidemiol, 43:543–548.
[Ferrucci et Lally, 2004] Ferrucci, D. et Lally, A. (2004). UIMA : an architectural
approach to unstructured information processing in the corporate research environment.
Nat. Lang. Eng., 10(3-4):327–348.
[Fiscus, 1997] Fiscus, J. G. (1997). A Post-Processing System To Yield Reduced Word
Error Rates : Recognizer Output Voting Error Reduction (ROVER). pages 347–352.
[Fiscus et Ajot, 2007] Fiscus, J. G. et Ajot, J. (2007). The Rich Transcription 2007
Speech-to-Text (STT) and Speaker Attributed STT (SASTT) Results. In Rich Transcription 2007 Meeting Recognition Workshop, Baltimore, MD, USA. NIST.
[Fordyce, 2007] Fordyce, C. S. (2007). Overview of the IWSLT 2007 evaluation campaign. In Proceedings of the IWSLT 2007 : International Workshop on Spoken Language
Translation, page 12, Trento, Italy.
239
BIBLIOGRAPHIE
[Forner et al., 2008] Forner, P., Peñas, A., Alegria, I. n., Forascu, C., Moreau,
N., Osenova, P., Prokopidis, P., Rocha, P., Sacaleanu, B., Sutcliffe, R. F. E.
et Tjong Kim Sang, E. (2008). Overview of the CLEF 2008 Multilingual Question Answering Track. In et al., C. P., éditeur : Working Notes for the CLEF 2008
Workshop, pages 262–295. Springer. Working Notes. Online Proc.
[Forsbom, 2002] Forsbom, E. (2002). Machine Translation Evaluation. Rapport technique, Uppsala universitet.
[Francis et Kucera, 1982] Francis, W. N. et Kucera, H. (1982). Frequency Analysis of
English Usage : Lexicon and Grammar. Boston : Houghton Mifflin Company.
[Francopoulo, 2008] Francopoulo, G. (2008). TagParser : Well on the Way to ISOTC37 Conformance. In In proceedings of the International Conference on Global Interoperability for Language Resources (ICGL), pages 82–88, Hong Kong.
[Francopoulo et al., 2008] Francopoulo, G., Declerck, T., Sornlertlamvanich,
V., Villemonte de la Clergerie, E. et Monachini, M. (2008). Data Category Registry : Morpho-syntactic and Syntactic Profiles. In In proceedings of the Workshop on use
and usage of language resource-related standards at the sixth international conference
on Language Resources and Evaluation (LREC), pages 31–40, Marrakech. LREC.
[Garcia et al., 2006] Garcia, M.-N., D’Alessandro, C., Bailly, G., Boula de Mareüil, P. et Morel, M. (2006). A joint prosody evaluation of French text-to-speech
systems : the EvaSy Prosody campaign. In Proceedings of the 5th International Conference on Language Resources and Evaluation, pages 307–310, Genoa, Italy.
[Gates et al., 1996] Gates, D., Lavie, A., Levin, L., Waibel, A., Gavalda, M., Mayfield, L. et Woszcyna, M. (1996). End-to-End Evaluation in JANUS : A Speech-tospeech Translation System. In Proceedings of the 6th ECAI, pages 195–206, Budapest.
[Gendner et al., 2003] Gendner, V., Illouz, G., Jardino, M., Monceaux, L., Paroubek, P., Robba, I. et Vilnat, A. (2003). Peas, the first instanciation of a comparative framework for evaluating parsers of French. In Proceedings of the 10th Conference
of the European Chapter of the Association for Computational Linguistics, pages 95–98,
Budapest, Hungary. ACL. Companion Volume.
[Giampiccolo et al., 2008] Giampiccolo, D., Forner, P., Herrera, J., Peñas, A.,
Ayache, C., Forascu, C., Jijkoun, V., Osenova, P., Rocha, P., Sacaleanu, B.
et Sutcliffe, R. F. E. (2008). Overview of the CLEF 2007 Multilingual Question
Answering Track. pages 200–236, Berlin, Heidelberg. Springer-Verlag.
[Giménez, 2008] Giménez, J. (2008). Empirical Machine Translation and its Evaluation.
Thèse de doctorat, Universitat Politécnica de Catalunya.
[Giménez et Amigó, 2006] Giménez, J. et Amigó, E. (2006). IQMT : A Framework for
Automatic Machine Translation Evaluation. In Proceedings of the 5th International
Conference on Language Resources and Evaluation, pages 685–690, Genoa, Italy.
[Grishman, 1996] Grishman, R. (1996). TIPSTER Text Phase II Architecture Design
Version 2.1p 19 June 1996. In Proceedings of the TIPSTER Text Program : Phase II,
pages 249–305, Vienna, Virginia, USA. Association for Computational Linguistics.
[Hamming, 1950] Hamming, R. W. (1950). Error-detecting and error-correcting codes.
Bell System Technical Journal, 29(2):147–160.
240
BIBLIOGRAPHIE
[Hamon, 2004a] Hamon, O. (2004a). Évaluation automatisée et méta-évaluation des
systèmes de traduction automatique. Mémoire de D.E.A., Université Paris-Nord, Villetaneuse.
[Hamon, 2004b] Hamon, O. (2004b). Mise au point d’un environnement d’évaluation automatisé de systèmes de traduction automatique. Rapport de fin d’Études d’ingénierie
logicielle, Université Paris-Nord, Villetaneuse.
[Hamon, 2007a] Hamon, O. (2007a). Experience and Conclusions from the CESTA Evaluation Project. In Proceedings of the MT Summit XI Workshop on Automatic procedures in MT evaluation, page 22, Copenhagen, Denmark.
[Hamon, 2007b] Hamon, O. (2007b). Rapport du projet CESTA. Rapport technique,
ELDA.
[Hamon et al., 2009] Hamon, O., Fügen, C., Mostefa, D., Arranz, V., Kolss, M.,
Waibel, A. et Choukri, K. (2009). End-to-end Evaluation in Simultaneous Translation. In In proceedings of EACL 2009, pages 345–353, Athens, Greece.
[Hamon et al., 2007a] Hamon, O., Hartley, A., Popescu-Belis, A. et Choukri, K.
(2007a). Assessing Human and Automated Quality Judgments in the French MT Evaluation Campaign CESTA. In Proceedings of the MT Summit XI, pages 231–238,
Copenhagen, Denmark.
[Hamon et Mostefa, 2008a] Hamon, O. et Mostefa, D. (2008a). An Experimental Methodology for an End-to-End Evaluation in Speech-to-Speech Translation. In ELRA,
éditeur : In proceedings of the sixth international conference on Language Resources
and Evaluation (LREC), pages 3539–3546, Marrakech, Morroco. ELRA.
[Hamon et Mostefa, 2008b] Hamon, O. et Mostefa, D. (2008b). The Impact of Reference Quality on AutomaticMT Evaluation. In In proceedings of Coling 2008, pages
39–42, Manchester, UK. Coling 2008 Organizing Committee.
[Hamon et al., 2008a] Hamon, O., Mostefa, D. et Arranz, V. (2008a). Diagnosing
human judgments in MT evaluation : an example based on the Spanish language. In
Proceedings of MATMT 2008 : Mixing Approaches to Machine Translation, pages 19–
26, San Sebastian, Spain.
[Hamon et al., 2007b] Hamon, O., Mostefa, D. et Choukri, K. (2007b). End-to-End
Evaluation of a Speech-to-Speech Translation System in TC-STAR. In Proceedings of
the MT Summit XI, pages 345–353, Copenhagen, Denmark.
[Hamon et al., 2008b] Hamon, O., Paroubek, P. et Mostefa, D. (2008b). SEWS : un
serveur d’évaluation orienté Web pour la syntaxe. Traitement Automatique des Langues
(TAL), 49(2):247–270.
[Hamon et al., 2006] Hamon, O., Popescu-Belis, A., Choukri, K., Dabbadie, M.,
Hartley, A., Mustafa El Hadi, W., Rajman, M. et Timimi, I. (2006). CESTA :
First Conclusions of the Technolangue MT Evaluation Campaign. In Proceedings of the
5th International Conference on Language Resources and Evaluation, pages 179–184,
Genoa.
[Hamon et al., 2008c] Hamon, O., Popescu-Belis, A., Hartley, A., Mustafa El Hadi, W. et Rajman, M. (2008c). CESTA : Campagne dÉvaluation
des Systèmes de Traduction Automatique, pages 93–116. Hermès, Lavoisier, Paris.
ISBN 978-2-7462-1992-2.
241
BIBLIOGRAPHIE
[Hamon et Rajman, 2006] Hamon, O. et Rajman, M. (2006). X-Score : Automatic Evaluation of Machine Translation Grammaticality. In Proceedings of the 5th International
Conference on Language Resources and Evaluation, pages 155–160, Genoa.
[Hamon et Hû, 2002] Hamon, T. et Hû, O. (2002). How to Evaluate Necessary Cooperative Systems of Terminology Building ? In Proceedings of the 3rd International Conference on Language Resources and Evaluation (LREC), pages 1543–1550, Las Palmas,
Spain.
[Hausser, 1994] Hausser, R. (1994). Results of the 1. Morpholympics. Rapport technique, Universität Erlangen - Nürnberg.
[Hirschman et Thompson, 1996] Hirschman, L. et Thompson, H. S. (1996). Overview
of evaluation in speech and natural language processing. R. Cole, editor, Survey of the
State of the Art in Human Language Technology. Cambridge University Press, pages
409–414.
[Hovy, 2007] Hovy, E. (2007). Investigating why BLEU penalizes non-statistical systems. In Proceedings of the MT Summit XI Workshop on Automatic procedures in MT
evaluation, page 10, Copenhagen, Denmark.
[Hutchins, 1997] Hutchins, W. J. (1997). From first conception to first demonstration :
the nascent years of machine translation, 1947-1954. A chronology. Machine Translation, 12(3):195–252.
[Hutchins, 2001] Hutchins, W. J. (2001). Machine Translation over fifty years. Histoire,
Epistemologie, Langage, XXII(1):7–31.
[Ide et Romary, 2002] Ide, N. et Romary, L. (2002). Standards for Language Ressources.
In Proceedings of the 3rd International Conference on Language Resources and Evaluation (LREC), pages 839–844, Las Palmas, Spain.
[Ide et Véronis, 1996] Ide, N. et Véronis, J. (1996). Application de la TEI aux industries
de la langue : le Corpus Encoding Standard. Cahiers GUTenberg, 24:166–169.
[Illingworth, 1990] Illingworth, V. (1990). Dictionary of computing. Oxford University
Press, London.
[ISO 9126, 1991] ISO 9126 (1991).
Information Technology–Software Product
Evaluation–Quality Characteristics and Guidelines for Their Use. Rapport technique,
Genève, ISO/IEC.
[ITU-T, 1993] ITU-T (1993). A method for subjective performance assessment of the
quality of speech voice output devices. Rapport technique COM 12-R 6, ITU-T.
[King, 2005] King, M. (2005). Evaluation in Human Language Technology. In ELRAHLT Evaluation Workshop, page 32, Malta.
[Klatt, 1977] Klatt, D. H. (1977). Review of the ARPA Speech Understanding Project.
The Acoustical Society of America, 62:1324–1366.
[Koehn, 2004] Koehn, P. (2004). Statistical Significance Tests for Machine Translation
Evaluation. In Lin, D. et Wu, D., éditeurs : Proceedings of EMNLP 2004, pages
388–395, Barcelona, Spain. Association for Computational Linguistics.
[Koehn, 2007] Koehn, P. (2007). Evaluating Evaluation Lessons from the WMT 2007
Shared Task. In Proceedings of the MT Summit XI Workshop on Automatic Procedures
in Machine Translation Evaluation, page 38, Copenhagen, Denmark.
242
BIBLIOGRAPHIE
[Krauwer, 2003] Krauwer, S. (2003). The Basic Language Resource Kit (BLARK) as
the First Milestone for the Language Resources Roadmap. In Proceedings of SPECOM
2003, page 8, Moscow, Russia.
[Lamel et al., 2006] Lamel, L., Bilinski, E., Adda, G., Gauvain, J.-L. et Schwenk,
H. (2006). The LIMSI RT06s Lecture Transcription System. In Renals, S., Bengio,
S. et Fiscus, J., éditeurs : Machine Learning for Multimodal Interaction : Third International Workshop, MLMI 2006, Bethesda, MD, USA, volume 4299 de Lecture Notes
in Computer Science, pages 457–468. Springer Verlag Berlin/ Heidelberg.
[Landis et Koch, 1977a] Landis, J. R. et Koch, G. G. (1977a). A One-Way Components
of Variance Model for Categorical Data. Biometrics, 33(1):671–679.
[Landis et Koch, 1977b] Landis, J. R. et Koch, G. G. (1977b). The Measurement of
Observer Agreement for Categorical Data. Biometrics, 33(1):159–174.
[Levenshtein, 1966] Levenshtein, V. I. (1966). Binary codes capable of correcting deletions, insertions and reversals. Soviet Physics-Doklady, 10:707–710.
[Likert, 1932] Likert, R. A. (1932). Technique for the Measurement of Attitudes. Archives of Psychology, 22(140):55.
[Magnini et al., 2006] Magnini, B., Giampiccolo, D., Forner, P., Ayache, C., Jijkoun, V., Osenova, P., Peñas, A., Rocha, P., Sacaleanu, B. et Sutcliffe,
R. F. E. (2006). Overview of the CLEF 2006 Multilingual Question Answering Track.
In CLEF, pages 223–256.
[Makhoul et al., 1999] Makhoul, J., Kubala, F., Schwartz, R. et Weischedel, R.
(1999). Performance measures for information extraction. In Proceedings of DARPA
Broadcast News Workshop, pages 249–252, Herndnon VA.
[Matusov et al., 2006] Matusov, E., Mauser, A. et Ney, H. (2006). Automatic Sentence Segmentation and Punctuation Prediction for Spoken Language Translation. In
International Workshop on Spoken Language Translation, pages 158–165, Kyoto, Japan.
[Miller, 2005] Miller, K. J. (2005). Evaluation principles and objectives : ISLE,
EAGLES (a play in three acts). In ELRA-HLT Evaluation Workshop, page 48, Malta.
[Miller et Vanni, 2005] Miller, K. J. et Vanni, M. (2005). Inter-rater agreement measures, and the refinement of metrics in the PLATO MT evaluation paradigm. In Proceedings of the MT Summit X, pages 125–132, Phuket, Thailand.
[Mitkov, 2003] Mitkov, R. (2003). The Oxford Handbook of Computational Linguistics.
Oxford University Press, Oxford.
[Moreau et al., 2010] Moreau, N., Hamon, O., Mostefa, D., Rosset, S., Galibert,
O., Lamel, L., Turmo, J., Comas, P. R., Rosso, P., Buscaldi, D. et Choukri, K.
(2010). Evaluation Protocol and Tools for Question-Answering on Speech Transcripts.
In In proceedings of LREC 2010, pages 2769–2773, Valletta, Malta.
[Mostefa et al., 2006] Mostefa, D., Hamon, O. et Choukri, K. (2006). Evaluation
of automatic speech recognition and speech language translation within TC-STAR :
results from the first evaluation campaign. In Proceedings of the 5th International
243
BIBLIOGRAPHIE
[Mostefa et al., 2007a] Mostefa, D., Hamon, O., Moreau, N. et Choukri, K. (2007a).
Technological Showcase and End-to-End Evaluation Architecture, Technology and Corpora for Speech to Speech Translation (TC-STAR) projects. Rapport technique Deliverable D30, ELDA.
[Mostefa et al., 2007b] Mostefa, D., Moreau, N., Choukri, K., Potamianos, G.,
Chu, S. M., Tyagi, A., Casas, J. R., Turmo, J., Cristoforetti, L., Tobia, F.,
Pnevmatikakis, A., Mylonakis, V., Talantzis, F., Burger, S., Stiefelhagen,
R., Bernardin, K. et Rochet, C. (2007b). The CHIL audiovisual corpus for lecture
and meeting analysis inside smart rooms. Language resources and evaluation, 41(3–
4):389–407.
[Mustafa El Hadi et Jouis, 1998] Mustafa El Hadi, W. et Jouis, C. (1998). Terminology extraction and acquisition from textual data : criteria for evaluating tools and
methods. In Proceedings of the first International Conference on Language Resources
and Evaluation (LREC), pages 1175–1178, Granada, Spain.
[Mustafa El Hadi et al., 2005] Mustafa El Hadi, W., Timimi, I., Choukri, K.,
Chiao, Y.-C. et Hamon, O. (2005). CESART : Campagne dÉvaluation de SystÃ¨mes
dÁcquisition des Ressources Terminologiques. In Atelier dÉvaluation des outils déxtraction terminologique dans le cadre des 6èmes Rencontres Terminologie et Intelligence
Artificielle TIA0́6, page 9, Rouen, France.
[Mustafa El Hadi et al., 2006] Mustafa El Hadi, W., Timimi, I., Dabbadie, M.,
Choukri, K., Hamon, O. et Chiao, Y.-C. (2006). Terminological resources acquisition tools : towards a user-oriented evaluation. In Proceedings of the 5th International
[Nazarenko et Poibeau, 2004] Nazarenko, A. et Poibeau, T. (2004). Evaluation des
systèmes d’analyse et de compréhension du texte, pages 127–148. Lavoisier, Paris. ISBN
2-7462-0862-8.
[Nazarenko et al., 2009] Nazarenko, A., Zargayouna, H., Hamon, O. et van Puymbrouck, J. (2009). Evaluation des outils terminologiques : enjeux, difficultés et propositions. Traitement Automatique des Langues (TAL), 50(1):257–281.
[Niessen et al., 2000] Niessen, S., Och, F. J., Leusch, G. et Ney, H. (2000). An Evaluation Tool for Machine Translation : Fast Evaluation for MT Reseach. In Proceedings of
the 2nd International Conference on Language Resources and Evaluation, pages 29–45,
Athens, Greece.
[Ninova et al., 2005] Ninova, G., Nazarenko, A., Hamon, T. et Szulman, S. (2005).
Comment mesurer la couverture d’une Ressource Terminologique pour un Corpus ? In
Actes des Ateliers de la 12ème Conférence annuelle sur le Traitement Automatique des
Langues Naturelles (TALN 2005), pages 293–302, Dourdan.
[NIST, 2003] NIST (2003). The 2003 NIST Machine Translation Evaluation Plan
(MT03). Rapport technique, NIST.
[Nomura, 1992] Nomura, H. (1992). JEIDA Methodology and Criteria on Machine
Translation Evaluation. Rapport technique, Japan Electronic Industry Development
Association (JEIDA), Tokyo.
[Nübel, 1997] Nübel, R. (1997). End-to-End Evaluation in VerbMobil I. In Proceedings
of the MT Summit VI, pages 232–239, San Diego.
244
BIBLIOGRAPHIE
[Och et Ney, 2000] Och, F. J. et Ney, H. (2000). A comparison of alignment models
for statistical machine translation. In Proceedings of the 18th International Conference
on Computational Linguistics (COLING-ACL 2000), pages 1086–1090, Saarbrücken,
Germany.
[Papineni et al., 2001] Papineni, K., Roukos, S., Ward, T. et Zhu, W.-J. (2001).
BLEU : a Method for Automatic Evaluation of Machine Translation. Rapport technique, IBM Research Division, Thomas J. Watson Research Center.
[Papineni et al., 2002] Papineni, K., Roukos, S., Ward, T. et Zhu, W.-J. (2002).
BLEU : A method for automatic evaluation of machine translation. In Proceedings
of the 40th Annual Meeting of the Association for Computational Linguistics, pages
311–318. Association for Computational Linguistics.
[Paroubek et al., 2005] Paroubek, P., Robba, I., Vilnat, A. et Pouillot, L.-G.
(2005). Easy : Campagne dévaluation des analyseurs syntaxiques. In Actes des Ateliers
de la 12ème Conférence annuelle sur le Traitement Automatique des Langues Naturelles
(TALN 2005), Dourdan.
[Paroubek et al., 2007] Paroubek, P., Vilnat, A., Robba, I. et Ayache, C. (2007). Les
résultats de la campagne EASY d’évaluation des analyseurs syntaxiques du françcais.
In Actes de la 14ème Conférence annuelle sur le Traitement Automatique des Langues
Naturelles (TALN 2007), pages 243–252, Toulouse.
[Peckham, 1991] Peckham, J. (1991). Speech understanding and dialouge over the telephone : an overview of the ESPRIT SUNDIAL. In HLT ’91 : Proceedings of the
workshop on Speech and Natural Language, pages 14–27, Morristown, NJ, USA. Association for Computational Linguistics.
[Peñas et al., 2004] Peñas, A., Verdejo, F. et Herrera, J. (2004). Spanish Question
Answering Evaluation. In CICLing, pages 472–483.
[Plamondon, 2004] Plamondon, L. (2004). L’ingénierie de la langue avec GATE. Rapport technique, Université de Montréal, RALI.
[Popescu-Belis, 1999] Popescu-Belis, A. (1999). L’évaluation en génie linguistique :
un modèle pour vérifier la cohérence des mesures. Langues : cahiers d’études et de
recherches francophones, 2(2):151–162.
[Popescu-Belis, 2007] Popescu-Belis, A. (2007). Le rôle des métriques d’évaluation
dans le processus de recherche en TAL. Traitement Automatique des Langues (TAL),
48(1):67–91.
[Price, 1990] Price, P. J. (1990). Evaluation of spoken language systems : the ATIS
domain. In HLT ’90 : Proceedings of the workshop on Speech and Natural Language,
pages 91–95, Morristown, NJ, USA. Association for Computational Linguistics.
[Rajman et Hartley, 2001] Rajman, M. et Hartley, A. (2001). Automatically predicting MT systems ranking compatible with Fluency, Adequacy and Informativeness
scores. In Proceedings of the 4th ISLE Workshop on MT Evaluation, MT Summit
VII, pages 29–34, Santiago de Compostela, Spain.
[Rajman et Hartley, 2002] Rajman, M. et Hartley, A. (2002). Automatic ranking of
MT systems. In Proceedings of the 3rd International Conference on Language Resources
and Evaluation (LREC), volume 4, pages 1247–1253, Las Palmas, Spain.
245
BIBLIOGRAPHIE
[Raymond, 2007] Raymond, S. (2007). Ajax on Rails. O’Reilly. ISBN 10 :0-596-52744-6.
[Sampson, 1995] Sampson, G. (1995). Susanne Corpus. School of Cognitive & Computing Sciences, University of Sussex.
[Saracevic, 1995] Saracevic, T. (1995). Evaluation of Evaluation in Information Retrieval. In Fox, E. A., Ingwersen, P. et Fidel, R., éditeurs : SIGIR’95, Proceedings of
the 18th Annual International ACM SIGIR, Conference on Research and Development
in Information Retrieval, pages 138–146, Seattle, Washington, USA. ACM Press.
[Schmid, 1994] Schmid, H. (1994). Probabilistic Part-of-Speech Tagging Using Decision
Trees. In Proceedings of the International Conference on New Methods in Language
Processing, pages 44–49, Manchester, UK.
[Sekine et Isahara, 2000] Sekine, S. et Isahara, H. (2000). IREX : IR and IE evaluationbased project in Japanese. In Proceedings of the 2nd International Conference on
Language Resources and Evaluation, pages 1106–1110, Athens, Greece.
[Somers et Sugita, 2003] Somers, H. et Sugita, Y. (2003). Evaluating Commercial Spoken Language Translation Software. In Proceedings of the Ninth Machine Translation
Summit, pages 370–377, New Orleans, USA.
[Sparck Jones et Galliers, 1996] Sparck Jones, K. et Galliers, J. R. (1996). Evaluating Natural Language Processing Systems : An Analysis and Review. Number 1083 in
Lecture Notes in Artificial Intelligence. Springer.
[Stufflebeam, 1974] Stufflebeam, D. L. (1974). Meta Evaluation. Occasional Paper
Series, page 121.
[Stüker et al., 2006] Stüker, S., Zong, C., Reichert, J., Cao, W., Kolss, M., Xie,
G., Peterson, K., Ding, P., Arranz, V., Yu, J. et Waibel, A. (2006). Speech-toSpeech Translation Services for the Olympic Games 2008. In MLMI, pages 297–308.
[Surcin et al., 2005] Surcin, S., Hamon, O., Hartley, A., Rajman, M., PopescuBelis, A., Mustafa El Hadi, W., Timimi, I., Dabbadie, M. et Choukri, K.
(2005). Evaluation of Machine Translation with Predictive Metrics beyond BLEU/NIST : CESTA Evaluation Campaign #1. In Proceedings of the MT Summit X, pages
117–124, Phuket, Thailand.
[Tillmann et al., 1997] Tillmann, C., Vogel, S., Ney, H., Zubiaga, A. et Sawaf, H.
(1997). Accelerated dp based search for statistical translation. In In European Conf.
on Speech Communication and Technology, pages 2667–2670.
[Timimi et Mustafa El Hadi, 2008] Timimi, I. et Mustafa El Hadi, W. (2008). CESART : une campagne d´évaluation de systèmes d’acquisition de ressources terminologiques, pages 71–89. Hermès, Lavoisier, Paris. ISBN 978-2-7462-1992-2.
[Turmo et al., 2009] Turmo, J., Comas, P. R., Rosset, S., Galibert, O., Moreau,
N. et Mostefa, D. (2009). Overview of QAst 2009. In Working Notes for the CLEF
2009 Workshop, Corfu, Greece.
[Van den Heuvel et al., 2006] Van den Heuvel, H., Choukri, K., Gollan, C., Moreno, A. et Mostefa, D. (2006). TC-STAR : New language resources for ASR and
SLT purposes. In In proceedings of the sixth international conference on Language
Resources and Evaluation (LREC), pages 2570–2573, Genoa, Italy. ELDA.
246
BIBLIOGRAPHIE
[van Rijsbergen, 1979] van Rijsbergen, C. J. K. (1979). Information Retrieval, 2nd
edition. Dept. of Computer Science, University of Glasgow.
[van Slype, 1979] van Slype, G. (1979). Critical Study of Methods for Evaluating the
Quality of Machine Translation. Rapport technique Final report BR 19142, Brussels :
Bureau Marcel van Dijk.
[Véronis et al., 2008] Véronis, J., Hamon, O., Ayache, C., Belmouhoub, R., Kraif,
O., Laurent, D., Nguyen, T. M. H., Semmar, N., Stuck, F. et Zaghouani, W.
(2008). La campagne d´évaluation ARCADE II, pages 47–69. Hermès, Lavoisier, Paris.
ISBN 978-2-7462-1992-2.
[Vidal, 1997] Vidal, E. (1997). Finite-State Speech-to-Speech Translation. Acoustics,
Speech, and Signal Processing, IEEE International Conference on, 1:111.
[Vilar et al., 2007] Vilar, D., Leusch, G., Ney, H. et Banchs, R. E. (2007). Human
Evaluation of Machine Translation Through Binary System Comparisons. In Proceedings of the Second Workshop on Statistical Machine Translation, pages 96–103, Prague,
Czech Republic. Association for Computational Linguistics.
[Villemonte de la Clergerie, 2007] Villemonte de la Clergerie, E. (2007). PASSAGE,
Produire des Annotations Syntaxiques à Grande Échelle. In Actes du Grand Colloque
STIC 2007, Paris, France.
[Villemonte de la Clergerie et al., 2008] Villemonte de la Clergerie, E., Ayache, C.,
de Chalendar, G., Francopoulo, G., Gardent, C. et Paroubek, P. (2008). Large
scale production of syntactic annotations for French. In In proceedings of the First
Workshop on Automated Syntactic Annotations for Interoperable Language Resources
at IGCL’08, pages 45–52, Hong Kong.
[Vilnat et al., 2004a] Vilnat, A., Paroubek, P., Monceaux, L., Robba, I., Gendner,
V., Illouz, G. et Jardino, M. (2004a). The ongoing Evaluation campaign of Syntactic
Parsing of French : EASY. In Proceedings of LREC’04, pages 2023–2026, Lisboa,
Portugal.
[Vilnat et al., 2004b] Vilnat, A., Paroubek, P., Monceaux, L., Robba, I., Gendner, V., Illouz, G. et Jardino, M. (2004b). The ongoing Evaluation campaign of
Syntactic Parsing of French : EASY. In Proceedings of LREC’04, pages 2023–2026,
Lisboa, Portugal.
[Walker et al., 1997] Walker, M. A., Litman, D. J., Kamm, C. A. et Abella, A.
(1997). PARADISE : A Framework for Evaluating Spoken Dialogue Agents. In Proceedings of the 35th Annual Meeting of the Association for Computational Linguistics
(ACL 1997), pages 271–280, Madrid, Spain.
[Weaver, 1955] Weaver, W. (1955). Translation. Reproduced in : Locke. W. N. & Booth,
A. D. (eds.) Machine translation of languages : fourteen essays (Cambridge, Mass. :
Technology Press of the Massachusetts Institute of Technology), pages 15–23.
[Weizenbaum, 1966] Weizenbaum, J. (1966). ELIZA—a computer program for the
study of natural language communication between man and machine. Communications of the ACM, 9(1):36–45.
[White et al., 1994] White, J. S., O’Connel, T. A. et O’Mara, F. E. (1994). The
ARPA MT evaluation methodologies : evolution, lessons, and future approaches. In
247
BIBLIOGRAPHIE
Proceedings of the First Conference of the Association for Machine Translation in the
Americas, pages 193–205, Columbia, Maryland, USA.
[Widlöcher et Bilhaut, 2005] Widlöcher, A. et Bilhaut, F. (2005). La plate-forme
LinguaStream : un outil d’exploration linguistique sur corpus. In Actes de la 12ème
Conférence annuelle sur le Traitement Automatique des Langues Naturelles (TALN
2005), pages 517–522, Dourdan.
[Winograd, 1971] Winograd, T. (1971). Procedures as a Representation for Data in a
Computer Program for Understanding Natural Language. Rapport technique, MIT AI.
[Witte et al., 2010] Witte, R., Cunningham, H., Patrick, J., Beisswanger, E.,
Buyko, E., Hahn, U., Verspoor, K. et Coden, A. R., éditeurs (2010). New Challenges for NLP Frameworks (NLPFrameworks 2010), Valletta, Malta. ELRA.
[Ye et Abney, 2006] Ye, Y. et Abney, S. (2006). How and Where do People Fail with
Time : Temporal Reference Mapping Annotation by Chinese and English Bilinguals. In
Workshop on Frontiers in Linguistically Annotated Corpora 2006, pages 13–20, Sydney,
Australia.
[Yvon, 2007] Yvon, F. (2007). Une petite introduction au traitement automatique des
langues. Rapport technique, LIMSI.
[Zargayouna et al., 2007] Zargayouna, H., Hamon, O. et Nazarenko, A. (2007). Evaluation des outils terminologiques : état des lieux et propositions. In Actes des 7èmes
rencontres Terminologiques et Intelligence Artificielle TIA’07, Sophia Antipolis.
[Zhang et al., 2005] Zhang, X., Li, Y. et Jewel, S. (2005). Design and Evaluation of
a Prototype User Interface Supporting Sharing of Search Knowledge in Information
Retrieval. In Proceedings of the 68th Annual Meeting of the American Society for
Information Science and Technology (ASIST), page 32, Charlotte, North Carolina.
[Zhang et Vogel, 2004] Zhang, Y. et Vogel, S. (2004). Measuring Confidence Intervals
for the Machine Translation Evaluation Metrics. In International Conference on Theoretical and Methodological Issues in Machine Translation (TMI 2004), Baltimore, MD
USA, October 4-6, 2004, pages 4–6.
248
Annexe A
Résultats succincts de projets abordés
A.1
TC-STAR
Les meilleurs systèmes de reconnaissance automatique de la parole ne dépassent pas
6 % de taux d’erreur (c’est-à-dire de mots non reconnus ou erronés). Pour les systèmes
de traduction automatique, les scores vont au-delà de 50 % d’après la métrique BLEU,
et au-dessus de 3 sur une échelle de 5 lorsque les traductions sont évaluées par des juges
humains (au-dessus de 4 pour les traductions de référence). Enfin, pour les systèmes de
synthèse de la parole, les meilleurs scores de qualité donnés par des juges humains se
situent entre 3 et 4 sur une échelle de 5 (contre 4,80 sur 5 pour des sons issus de voix
humaines). Une évaluation en cascade permet aussi d’évaluer un « système TC-STAR »
dans son ensemble en combinant les trois technologies. Des juges humains répondent à
des questions sur le contenu de ce qu’ils écoutent, « comme s’ils étaient des députés
européens ». Il s’avère qu’entre 60 % et 80 % de l’information peut être captée, malgré
une qualité à l’écoute plutôt faible si l’on compare les résultats automatiques à ce que
fournit un interprète de la Communauté Européenne. Les évaluations successives nous
ont permis de voir les améliorations des technologies, même s’il reste beaucoup de chemin
à parcourir pour atteindre le niveau d’un interprète.
A.2
CESTA
CESTA 1 , avait pour cadre l’évaluation des systèmes de traduction automatique. L’objectif de CESTA était d’organiser deux campagnes de test, la première mesurant la qualité des traductions produites automatiquement par des systèmes - commerciaux ou de
recherche - dans un domaine général, la seconde mettant en évidence la capacité des systèmes à s’adapter à un domaine spécifique, en un temps limité. Parallèlement, CESTA
visait à étudier la fiabilité des mesures d’évaluation automatiques, en vue d’offrir à la
communauté un protocole et des données d’évaluation réutilisables, pour des systèmes
traduisant de l’anglais ou de l’arabe vers le français. Du point de vue de l’organisation,
une des problématiques était de rassembler des systèmes de traduction automatique dans
1. http ://www.technolangue.net/article199.html
249
Annexe A : Résultats succincts de projets abordés
une même campagne autour d’un protocole commun. La définition d’un jeu de données de
bonne qualité et l’expérimentation de nouvelles mesures d’évaluation étaient également
prévues.
Les résultats des deux campagnes ont été riches en enseignements, notamment lors
de la seconde campagne, où il a été rendu compte des difficultés pour les systèmes de
s’adapter à un domaine de spécialité. Par exemple, bien que discutée actuellement au sein
de la communauté, la métrique d’évaluation la plus utilisée, BLEU, permet de se faire
une idée de la qualité d’une traduction en la comparant à une traduction humaine à l’aide
de séquences de n-grammes 1 . Là où les meilleurs systèmes automatiques obtiennent des
scores proches de 55 % de n-grammes reconnus, une traduction humaine est supposée être
parfaite 2 . De même, la comparaison entre un domaine général et un domaine de spécialité
traduit la difficulté des systèmes à s’adapter (avec des résultats BLEU respectivement
proches de 55 % et proches de 40 %). Par ailleurs, à l’heure actuelle les métriques humaines
comparent encore la qualité de deux traductions. Les traductions humaines dépassent
largement une note de 4,5 sur une échelle de 5 et les meilleures traductions automatiques
dépassent rarement la note de 3,5.
A.3
CESART
CESART 3 , avait pour but l’évaluation des outils d’acquisition de ressources terminologiques. Elle suit la campagne ARC A3 de l’AUF [Béguin et al., 1997] et poursuit la
recherche d’une méthodologie d’évaluation de différents types de systèmes sur des données
communes [Timimi et Mustafa El Hadi, 2008], tout en cherchant à définir de nouvelles
mesures d’évaluation. Outre le manque de disponibilité de telles mesures, une des problématique lors de l’organisation de la campagne fut de rassembler des outils hétérogènes
autour d’une même tâche : l’extraction terminologique regroupe différentes tâches qui ne
sont pas toujours en adéquation, et dont les formats d’entrée/sortie sont fortement indépendants. Les objectifs des systèmes évalués étaient d’ores et déjà difficiles à définir. Cela
s’est ressenti lorsqu’il a fallu faire le bilan de la campagne d’évaluation, où finalement
peu de systèmes ont concouru, comparé aux attentes des organisateurs et au nombre de
systèmes existants.
Deux domaines ont servi pour le test des systèmes : un premier, le domaine de la
santé était composé de pages Internet provenant du site Santé Canada 4, pour un corpus
d’environ 9 millions de mots (contenus dans 255 000 phrases et 7 500 documents) ; le
second, le domaine de l’éducation était composé d’articles de la revue de pédagogie et de
recherche en éducation Spirale, pour un corpus d’environ 535 000 mots (contenus dans
12 000 phrases et 149 documents).
Pour conduire l’évaluation lors de la tâche T1, deux listes de termes représentatives des
domaines respectifs ont été utilisées comme référentiel par les experts. Pour le domaine
médical, il s’agit de termes basés sur la terminologie provenant de l’équipe CISMeF 5 et
1. Un n-gramme est dans ce contexte une séquence ordonnée de n mots.
2. Supposée, car du fait des multiples possibilités de traduction (une phrase en anglais peut être
traduire de nombreuses manières différentes en français), il n’y a pas de traduction parfaite possible.
3. http ://www.technolangue.net/article.php3 ?id_article=200
4. http ://www.hc-sc.gc.ca/index_f.html
5. http ://www.chu-rouen.fr/terminologiecismef
250
A.4. PASSAGE
contenant 22 861 entrées. Pour le domaine de l’éducation, la liste de référence est issue
du thésaurus Motbis 1 et est composée de 36 081 entrées. La tâche d’évaluation consiste
alors à effectuer dans un premier temps un appariement automatique de la sortie des
systèmes avec le référentiel. L’évaluation manuelle par un expert est ensuite conduite en
attribuant aux candidats termes (c.-à-d. les termes proposés par les systèmes) un score de
1 à 5 correspondant au degré de pertinence. Pour la tâche T2 d’extraction des relations
synonymiques, l’évaluation manuelle par un expert est menée en donnant une note sur
une échelle de 1 à 3 pour mesurer la pertinence de la relation. Les résultats ont montré une
forte disparité entre systèmes, traduisant des approches et des objectifs très différents des
systèmes évalués. De plus, le niveau de qualité était considéré comme relativement bas,
compte tenu d’un corpus finalement peu adapté à la tâche, du fait de sa taille (supérieure
à 9 millions de mots) et de sa provenance (des pages Internet) introduisant beaucoup
d’erreurs et de bruit.
A.4
PASSAGE
PASSAGE avait pour cadre l’évaluation de systèmes d’analyse syntaxique pour le
français. L’objectif était double : améliorer les performances des analyseurs syntaxiques
et exploiter les annotations syntaxiques produites pour créer des ressources linguistiques.
PASSAGE fait suite à la campagne d’évaluation des analyseurs syntaxiques (EASy). Deux
campagnes d’évaluation ont été conduites. La première campagne, effectuée en 2007, a
vu 11 analyseurs syntaxiques être testés sur 45 000 phrases annotées manuellement au
préalable. Les résultats ont montré des pourcentages élevés en f-mesure pour l’évaluation
selon les types de constituants, et des performances plus mesurées en ce qui concerne
les relations. L’architecture développée a également porté ses fruits et soulevé un grand
intérêt parmi les participants et organisateurs de l’évaluation.
La seconde campagne, effectuée en 2009, était plus ambitieuse : 11 analyseurs syntaxiques avaient à produire des annotations automatiquement sur un corpus de 100 million de mots. Ils étaient alors évalués sur une sous-partie de ce corpus. Cette campagne
a montré les difficultés technique de gérer un tel volume de donnée, tout d’abord du
point de vue des participants mais aussi et surtout de celui des évaluateurs, l’architecture
développée ayant montré ses limites.
A.5
EQueR
EQueR avait pour but l’évaluation des systèmes de question-réponse. Deux tâches ont
été proposées aux participants : une tâche générique pour laquelle les systèmes étaient
évalués sur une collection hétérogène de documents et une tâche spécialisée pour laquelle
les systèmes étaient évalués sur une collection de documents provenant du domaine médical. Les systèmes devaient répondre à 500 pour la tâche générique et à 200 questions
pour la tâche spécialisée.
C’est par expertise humaine qu’est identifiée la qualité des sorties des systèmes, en
fournissant des jugements sur les réponses courtes (de l’ordre de quelques mots) ou sur
les passages (pouvant atteindre quelques phrases). À chaque type de question est alors
1. http ://www.cndp.fr/motbis
251
Annexe A : Résultats succincts de projets abordés
calculé un score de pertinence (Moyenne des Réciproques du Rang pour des questions de
types « factuel », « définition » et « oui/non », Précision Moyenne non Interpolée pour
des questions de type « liste ») et une moyenne est donnée pour chaque système. Les
résultats ont montré une très forte disparité selon les systèmes, un système ressortant
particulièrement tandis que les autres obtenaient des scores plus bas. Pour l’évaluation
sur les réponses courtes dans un domaine générique, le meilleur résultat est de l’ordre de
67 % et de 81 % pour les passages. Les taux baissent de 20 à 30 % lorsque les systèmes
sont évalués sur un domaine spécialisé.
252
Annexe B
Chronologie sur l’évaluation en TAL
253
Annexe B : Chronologie sur l’évaluation en TAL
254
Annexe C
Exemples de métriques utilisées en TAL
C.1
C.1.1
BLEU
BLEU (Bilingual Evaluation Understudy) est une métrique automatique, expérimentée
par le National Institut of Standard (NIST), et développée par IBM [Papineni et al., 2001].
L’idée de départ est de comparer des segments (généralement des phrases) à partir de
séquences de n-grams. Dans ce contexte, un n-gram est une séquence ordonnée de n mots,
considérés comme une suite de lettres séparées par des blancs.
D’une manière simplifiée, la métrique compte pour une phrase à évaluer le nombre de
mots contenus dans une ou plusieurs phrases de référence. La qualité d’une traduction
est d’autant élevée que la phrase à évaluer partage un nombre important de n-grams avec
une ou plusieurs des traductions de référence. Une des spécificités de BLEU est l’emploi
de plusieurs traductions de référence.
De plus, BLEU applique une pénalité aux traductions dont le différentiel (en termes
de n-grams) avec la traduction de référence est important cela afin d’éviter qu’un mot
n’apparaisse plus fréquemment dans le document traduit qu’il ne le peut dans le document
de référence, et ainsi empêcher les scores d’être trop importants.
Le calcul de BLEU (cf. équation C.1) se fait au moyen de la moyenne géométrique des
précisions des n-grams allant jusqu’à la taille N pondéré par un poids positif wn , établi à
1/N par le NIST lors de leur campagne. La pénalité de « brièveté » (taille du document
candidat plus court que celle du document de référence), BP , est un facteur modifiant le
score de BLEU par un facteur exponentiel sur le ratio entre la taille du document candidat
et celle du document de référence.
!
N
X
BLEU = BP · exp
wn log pn
(C.1)
n=1
où :
BP =
1
si c > r
(1− re )
e
si c ≤ r
r = taille du document de référence
255
Annexe C : Exemples de métriques utilisées en TAL
c = taille du document candidat
N =4
1
w =P
N
P
p=
c∈{candidats}
P
c∈{candidats}
n∈{candidats}
P
Countclip (n)
n∈{candidats} Count(n)
NIST (cf. équation C.2) est une métrique alternative à BLEU, qui calcule la moyenne
arithmétique des précisions des n-grams en prenant compte des comparaisons des longueurs. N sera plutôt fixé, avec la métrique NIST, à 5. Le score de NIST s’applique à
tous les mots du document de référence, tandis que le score de BLEU est appliqué localement à des séquences de mots. En effet, count(n-gram) compte le nombre d’occurrences
sur toutes les traductions de référence, et NIST permet ainsi de mieux distinguer les
différentes qualité de traduction.
NIST =
N
X
n=1
(P
n−gram∈Ei′
P
inf o(n-gram)
n-gram ∈ Ei′ 1
exp(βlog2 min(Lsys /Lref , 1))
)
(C.2)
où :
β = facteur de pénalité
N = taille maximale du n-gram
Lsys = nombre de mots en sortie du système
Lref = nombre moyen de mots dans la traduction de référence
count((n−1)-gram)
inf o(n-gram) = log2 ( count(n-gram) )
count(n-gram) = nombre d’occurences d’un n-gram dans toutes les traductions de
référence
C.1.2
mWER
Le WER (Word Error Rate) indique le pourcentage de mots qui sont insérés, supprimés, ou substitués dans une phrase traduite automatiquement par rapport à une phrase de
référence [Tillmann et al., 1997, Vidal, 1997]. La performance du système est évaluée en
termes de taux d’erreur au niveau des mots en utilisant une distance d’édition, également
appelée distance de Levenshtein [Levenshtein, 1966]. En d’autres termes, on comptabilise
le nombre minimal d’opérations nécessaires pour passer d’une traduction automatique à
la traduction de référence. La principale limite de cette mesure est de ne considérer qu’une
seule traduction de référence, alors que celle-ci n’est pas la seule valable et qu’il existe
presque toujours de nombreuses autres traductions de référence possibles pour un même
texte source.
Le mWER (multi-reference Word Error Rate) est similaire au WER, à la différence
que plusieurs traductions de références sont prises en compte [Niessen et al., 2000].
C.1.3
WNM
La métrique WNM (Weighted N-gram Model) [Babych et al., 2003] est une combinaison des métriques BLEU [Papineni et al., 2001] et LTV (Legitimate Translation Variation) [Babych et Hartley, 2004] et permet de prédire des scores d’adéquation et de fluidité.
WNM obtient globalement de meilleurs résultats sur l’adéquation ce qui est certainement
256
C.1. Traduction automatique
dû au fait que LTV fournit déjà de meilleurs résultats que BLEU. LTV applique une pondération aux mots du document statistiquement significatifs et calcule cette pondération
en comparant les fréquences des mots à l’ensemble du corpus.
La proposition des auteurs est d’étendre l’évaluation de BLEU et les scores de proximité (distance entre les traductions humaine et automatique) au poids statistique des
termes pertinents ou significatifs dans un texte. Leur hypothèse est basée sur la mesure
de l’importance relative des termes lexicaux pour les traductions humaines. Il s’agit ici
d’une combinaison des mesures tf.idf et S-score pour chaque catégorie lexicale.
Le modèle statistique td.idf (cf. équation C.3) mesure la pertinence des mots dans
un document. Il combine l’importance du terme pour un document (tf ), et le pouvoir
de discrimination de ce terme (idf ). Ainsi, un terme qui a une valeur tf.idf élevée doit
être à la fois important dans ce document, mais doit aussi apparaître peu dans les autres
documents. C’est le cas où un terme correspond à une caractéristique importante et unique
d’un document.
tf.idf (i, j) = (1 + log(tfij )log(N/dfi )
(C.3)
où :
tfij est le nombre d’occurrences du mot wi dans le document dj
dfi est le nombre de documents dans le corpus contenant wi
N est le nombre de documents dans le corpus
Le S-score (cf. équation C.4) calcule la pertinence des objets lexicaux d’un document
donné. Proche de tf.idf, la mesure est similaire et vise à déterminer si un terme est important sur tout le corpus ou s’il est spécifique à un document précis ; c’est un calcul de
pertinence.
s(i, j) = log
(Pdoc(i,j) − Pcorp−doc(i) ) × (N − df(i) )/N
Pcorp(i)
(C.4)
où :
Pdoc(i,j) est la fréquence relative du mot dans le texte
Pcorp−doc(i) est la fréquence relative de ce mot dans le corpus, texte exclu
(N − dfi )/N est le nombre de texte du corpus où le mot n’apparaît pas
Pcorp(i) est la fréquence relative du mot dans le corpus, texte inclus
Les différents mots, communs à la traduction de référence et la traduction évaluée,
n’ont pas le même poids. Un mot statistiquement significatif aura une meilleure pondération. Cette dernière est calculée en confrontant la fréquence d’un mot dans un texte
et dans le reste du corpus. La formule utilisée est celle du score td.idf, utilisé dans la
recherche d’information. La seule différence avec cette formule est la normalisation des
mots du corpus par la fréquence relative (apportée du S-score).
En règle générale, les mots tels que les noms d’évènement ou les termes spécifiques sont
plus signifiants statistiquement parce qu’il n’existe pour ces mots qu’une seule traduction
possible. À l’inverse, d’autres mots plus fonctionnels pourront être traduits de différentes
façons, selon les traducteurs humains ; on revient alors à la notion de LTV. Les mots dont
la signification statistique est plus importante auront une plus grande pondération. LTV
peut alors calculer trois types de scores : la précision, le rappel et le f-score. D’après les
expérimentations, le rappel correspond à l’adéquation, tandis que le f-score correspond à
la fluidité
257
C.2
C.2.1
Précision moyenne non interpolée ou UAP
La précision moyenne non interpolée (UAP pour Uninterpolated Average Precision,
aussi appelée NIAP, Non Interpolated Average Precision) calcule la pertinence du classement de documents retournés par un système. Pour chaque document retourné, cette mesure calcule la précision p en fonction de son rang dans la liste ordonnée des N documents
retournés. La précision moyenne non interpolée est finalement obtenue en additionnant
les précisions en rang des différents documents et en divisant cette somme par le nombre
total de documents pertinents retournés (cf. équation C.5).
N
1 X
UAP (N) =
p(i) ×
N i=1
Pi
j=1
p(j)
i
(C.5)
Le tableau C.1 présente un exemple de calcul de l’UAP. Supposons qu’un moteur de
recherche ait renvoyé sept documents ordonnés parmi lesquels trois sont pertinents.
Rang du document renvoyé
1
2
3
4
5
6
7
Pertinence (oui/non) Précision
non
oui
1/2
non
oui
2/4
non
non
oui
3/7
Table C.1 – Exemple de précisions calculées pour chaque document pertinent.
Pour cet exemple, la précision moyenne non interpolée est :
UAP (7) = 1/7(1/2 + 2/4 + 3/7) = 0, 20
Il s’agit d’un score de précision et plus le score est élevé, plus le moteur de recherche
est pertinent. Pour ce même exemple, le score de précision est de P(7) = 3/7 = 0 ,43. Il
est alors possible de dire que 43% des documents renvoyés sont pertinents. Cependant,
l’UAP permet de préciser que les documents ne sont pas ordonnés de manière optimale.
La limite supérieure de l’UAP étant le score de précision, si UAP (N) = P (N), alors il est
possible de dire que le classement est optimisé, même si la précision n’est pas suffisante.
C.2.2
Moyenne des Réciproques du Rang ou MRR
La mesure que nous avons adoptée était la Moyenne des Réciproques du Rang (MRR).
La Moyenne des Réciproques du Rang (MRR) tient compte du rang de la première
bonne réponse trouvée (d’après une métrique TREC) parmi un ensemble N de questions
posées. Si une bonne réponse est trouvée plusieurs fois, elle n’est comptée qu’une seule
fois (cf. équation C.6).
258
C.2. Recherche d’information
N
1
1 X
MRR =
N i=1 rang de la première réponse correcte
(C.6)
Les systèmes ne trouvant pas la bonne réponse en rang 1 sont désavantagés.
Par exemple, soit trois questions et pour chacune d’entre elles, les 5 réponses ordonnées
suivantes (1 étant une réponse correcte, 0 une réponse incorrecte) :
Question
1
2
3
Réponse 1 Réponse 2 Réponse 3
0
0
1
0
1
0
1
0
0
Réponse 4 Réponse 5
1
1
1
1
1
1
La moyenne des réciproques du rang vaut :
MRR = 1/2 × (1/3 + 1/2 + 1/1) = 1/2 × 11/6 = 11/12
259
260
Annexe D
Exemple de standardisation sur les
corpus textuels
D.1
Contexte et historique
Parmi les corpus précurseurs, le corpus Brown 1 (The Brown Corpus of Standard American English) est le premier corpus informatisé à avoir été compilé, en 1967, par la Brown
University de Providence, aux États-Unis. La taille du corpus est de 1 million de mots,
provenant de textes écrits en 1961. Encore utilisé de nos jours, il est composé de 500 documents de 2 000 mots chacun, repartis en 15 catégories (presse, religion, humour, etc.).
Peu de temps après, en 1968, un nouveau corpus de 1 million de mots (200 documents
de 5 000 mots chacun) est constitué par la University College of London. Son contenu est
représentatif de l’anglais britannique écrit, mais également parlé, puisqu’il contient autant des documents écrits que des transcriptions de documents parlés. Le corpus Brown a
inspiré bon nombre de corpus, tels que les corpus LOB, Kolhapur, SSE (Survey of Spoken
English), Wellington, Australian, etc. Ces corpus concernent chaque fois une langue anglaise régionale (Nouvelle-Zélande, Australie, Inde, etc.) et sont basés sur le même modèle
de structure. De la même manière, de nombreux et larges corpus « nationaux » ont vu
le jour à partir de la fin des années 1980, auxquels s’ajoutent la plupart du temps des
annotations. À commencer par le British National Corpus (100 millions de mots), puis
le American National Corpus (100 millions de mots), mais on peut citer entre autres les
Croatian National corpus, Czech National Corpus, Hellenic National Corpus, Hungarian
National corpus, etc.
L’utilisation de corpus pour la recherche ou des applications commerciales apporte de
nombreuses possibilités pour le traitement automatique des langues. Lors du développement de systèmes, l’approche à base de corpus permet de profondes améliorations, comme
notamment en étiquetage morphosyntaxique ou en traduction automatique. Cela nécessite l’annotation des corpus, qui est souvent coûteuse mais nécessaire. Il est utile ici de
citer les travaux de [Francis et Kucera, 1982] qui ont été parmi les premiers a étiqueter
un corpus, le corpus Brown, et à le rendre disponible à l’ensemble de la communauté,
1. http ://www.ldc.upenn.edu/cgi-bin/ldc/textcorpus ?doc=yes&corpus=BROWN
261
Annexe D : Exemple de standardisation sur les corpus textuels
permettant ainsi des progrès conséquents en recherche.
Les corpus sont également utilisés avec succès lors de campagnes d’évaluation,
comme la plupart d’entres elles peuvent le démontrer (MUC, TREC, CLEF, campagnes
EVALDA, etc.). Dans un même temps, ces campagnes permettent la production de nouvelles ressources, favorisant la recherche et le développement de systèmes, lorsque ces
ressources sont réutilisées.
En 1992, le corpus SUSANNE 1 (Surface and Underlying Structural ANalysis of Natural English) est développé par la University of Sussex [Sampson, 1995] et a pour but de
représenter une taxinomie des unités grammaticales sur l’anglais. Le corpus est étiqueté
syntaxiquement et est un sous-ensemble du corpus Brown. Il contient 64 fichiers de 2 000
mots annotés syntaxiquement.
En 1993, le groupe EAGLES définit des normes pour les corpus textuels à propos de
la typologie, l’encodage, l’annotation (syntaxique et morphosyntaxique) et autres recommandations sur ce type de corpus. Un des résultats concrets se trouve dans la définition
du standard d’encodage de corpus (CES 2 - Corpus Encoding Standard ), étant une application SGML des standard de la TEI 3 (Text Encoding Initiative). Ces standards se sont
développés et ont été maintenus depuis 1994, ils ont pour objectif de définir un guide pour
l’encodage et la représentation des textes sous forme électronique.
En 1994-1995, le projet européen MLAP-93/20 a développé et aligné un corpus parallèle (c.-à-d. contenant des traductions réciproques) anglais, français et espagnol (CRATER 4 - Corpus Resources and Terminology Extraction), devenant le premier corpus de ce
type a être rendu disponible à l’ensemble de la communauté. Divers outils ont également
été développés pour l’alignement de corpus, la navigation dans ce corpus trilingue, ainsi
que l’extraction de terminologie.
Associé au projet EAGLES, le projet Multext (Multilingual Text Tools and Corpora,
1996) définit lui aussi des standards et spécifications, entre autres pour l’encodage et le
traitement de corpus textuels. Sur un plan plus pratique que celui d’EAGLES, Multext a
travaillé sur deux corpus (JOC - Journal Officiel de la communauté Européenne - et Dagens Industri 1993) totalisant six langues (anglais, allemand, espagnol, français et italien
pour le JOC, suédois pour le Dagens Industri 1993).
Le projet PAROLE 5 (1996-1998) avait pour but de créer un ensemble de corpus pour
toutes les langues de l’Union Européenne de l’époque (français belge, catalan, hollandais,
anglais, français, finnois, allemand, grec, irlandais, italien, norvégien, portugais et suédois) et d’harmoniser ces corpus d’après certains critères : les textes ne devaient pas être
plus vieux que 1970 et contenir dans une certaine proportion les mêmes types de textes
(livres, journaux, périodiques, divers). Cet effort d’harmonisation était également appliqué à l’encodage textuel et linguistique des corpus. Chacun des corpus était ainsi codé
en respectant à la fois la DTD PAROLE (qui est dérivée de la DTD des guides TEI) et
celle de la CES. Environ 250 000 mots étaient étiquetés morphosyntaxiquement d’après
un guide d’annotation défini au cours du projet. Par la suite, en 1999, le projet SIMPLE 6
a permis d’ajouter des informations sémantiques sur les corpus PAROLE.
1.
2.
3.
4.
5.
6.
http
http
http
http
http
http
://www.csc.fi/english/research/software/susanne
://www.cs.vassar.edu/CES
://www.tei-c.org
://www.comp.lancs.ac.uk/linguistics/crater/corpus.html
://www.elda.fr/catalogue/en/text/doc/parole.html
://www.ub.es/gilcub/SIMPLE/simple.html
262
D.1. Contexte et historique
À partir de 1987 et ce jusqu’à nos jours, le corpus Le Monde a été développé progressivement en compilant l’ensemble des articles du journal du même nom. Cela représente
environ 50 000 articles par an, constituant la plus grosse base de données de la presse
française et très certainement un des corpus les plus utilisés en traitement automatique
de la langue française.
Si le développement de corpus monolingues, souvent représentatifs de la grammaire
d’une langue donnée, a été longtemps privilégié, les corpus parallèles sont a priori de
plus en plus demandés et a fortiori développés en conséquence. Pour aller plus loin, le
besoin de plus en plus pressant de grandes quantités de données amène les développeurs à
utiliser des corpus comparables [Déjean et Gaussier, 2002], composés de documents écrits
dans deux langues différentes et ayant un vocabulaire commun, sans pour autant être un
assemblage de documents parallèles.
Ainsi, un large corpus multilingue et parallèle a été développé dans le projet C-STAR 1
(Consortium for Speech Translation Advanced research), démarré en 1991, puis poursuivi
de 1993 à 1999 avec le projet C-STAR II.
De même, en 2001 le corpus Hansard 2 a été développé lors du projet Rewrite 3 et
contenait 1,3 million de paires de phrases alignées provenant d’enregistrement du 36e Parlement Canadien. Le format du corpus choisi est très simple, puisqu’il s’agit de fichiers
contenant une phrase par ligne.
Démarré en 1996, et se poursuivant encore actuellement, le corpus Europarl 4 (European Parliament Proceedings Parallel Corpus) inclus 11 langues extraites d’enregistrements du Parlement Européen. Le corpus multilingue contient à l’heure actuelle 44 millions
de mots par langue. Ce corpus fait partie d’un plus gros ensemble de corpus (OPUS 5 )
développé sous licence Open Source, regroupant différents corpus multilingues alignés de
domaines techniques (Open Office, opensubtitles.org, messages du système KDE, manuel
KDE, manuel PHP) ou institutionnels (Parlement Européen, constitution européenne,
agence médicale européenne).
Le JRC-Acquis 6 , actuellement dans sa version 3.0, est l’un des corpus parallèles les
plus importants, créé à partir de plus de 20 langues européennes incluant, de manière
quasi unique, des combinaisons rares (telle que la paire Estonien-Grec). Les documents
bilingues alignés respectent le format XML des standards de la TEI, et chacun d’entre
eux est classé selon des domaines bien spécifiques. Le nombre de mots varie entre 20 et
60 millions par langue présente.
Dorénavant, les très grands corpus sont de plus en plus employés, notamment dans le
cadre d’approches statistiques, demandeuses de grosses masses de données. La production
de telles ressources se fait notamment en utilisant des données provenant d’Internet, que
ce soit pour des données monolingues ou bilingues. On parle désormais de corpus TERABYTE, comme les corpus WT10g, GOV ou « terabyte» utilisés lors des campagnes
TREC 7 (tâches terabyte).
1.
2.
3.
4.
5.
6.
7.
http
http
http
http
http
http
http
://www.c-star.org
://www.isi.edu/natural-language/download/hansard
://www.isi.edu/natural-language/projects/rewrite/index.html
://www.iccs.inf.ed.ac.uk/ pkoehn/publications/europarl
://urd.let.rug.nl/tiedeman/OPUS
://langtech.jrc.it/JRC-Acquis.html
://trec.nist.gov
263
D.2
Formats de codage
Longtemps considéré comme le standard en la matière, l’encodage de caractères ASCII
n’est plus vraiment utilisé à l’heure actuelle, ou très peu. Il a tout d’abord été abandonné
par l’ISO (International Organization for Standardization) qui a défini les standards ISO8859-1 à ISO-8859-15, afin d’inclure des caractères indispensables comme les caractères
accentués des principales langues européennes. Seulement, le développement de l’informatique et des communications a créé un nouveau besoin de représentation des caractères
d’autres langues telles que les langues asiatiques, ce que ne permettaient pas les standards
ISO. Pour pallier ce problème, le format Unicode a été spécifié, rendant possible l’emploi
de nombreux caractères, mais pêchant encore par la taille accrue des documents. Ainsi,
l’encodage UTF-8 1 a été spécifié, qui permet de réduire les défauts du format Unicode.
De par ses nombreux avantages (encodage d’immenses quantités de caractères, taille, correspondance exacte avec l’encodage ASCII pour les États-Unis, etc.), l’encodage UTF-8
est finalement passé dans les mœurs, étant devenu le standard de l’Internet (l’UTF-8 est
utilisé par défaut pour les documents XML), et donc de l’informatique.
Par conséquence, mais aussi par facilité, l’UTF-8 est l’encodage le plus utilisé lors de
la construction de corpus textuels. Il est utile entre autres pour les corpus multilingues
ou la production de ressources pour des langues non européennes.
Le formatage des documents textuels constituants les corpus peut se faire de trois
manières différentes :
– formatage brut du texte, sans aucun élément autre que le contenu informatif,
– formatage balisé du texte, permettant d’enrichir le corpus d’informations complémentaires à l’aide d’un système de balisage (SGML, XML, XHTML, etc.),
– formatage compilé du texte, lisible la plupart du temps par un logiciel spécifique
(formats Word, RTF, PDF, ODT, etc.).
Le second format est le plus couramment utilisé, car il permet l’annotation de corpus
et l’ajout d’annotations afin d’enrichir le contenu d’informations complémentaires (ou
méta informations). Il est alors possible de distinguer à tout moment le texte brut de
ses annotations. Différent type d’annotations peuvent ainsi être ajoutées au corpus brut
initial, telles que :
– Des informations documentaires : langue employée, identification des segments, méthode, taille, etc.
– Des informations structurales : titre, paragraphe, phrase, mot, etc.
– Des informations linguistiques : syntaxe, sémantique, etc.
Par exemple en annotation syntaxique, la construction d’un corpus annoté de référence permet d’illustrer l’intérêt d’une telle démarche : ce corpus est constitué d’énoncés
clairement délimités par des balises, permettant lors d’une évaluation de le comparer aux
résultats des systèmes. En effet chaque corpus contiendra une annotation manuelle des
énoncés quant aux traits syntaxiques des mots les constituant.
Afin d’incorporer de manière simple ces annotations, plusieurs systèmes ont été employés, essentiellement le SGML (Standardized Generalized Markup Language) développé
en 1960, et le XML (eXtended Markup Language) développé en 1998. D’une structure
plus simple, c’est ce dernier qui s’est imposé pour la création de corpus. Le XML est un
langage de balisage générique pour lequel un document balisé est attaché à un schéma (la
1. Créé par Ken Thompson en 1992
264
D.3. Formats de stockage
DTD - Document Type Definition). Chaque document attaché à un même schéma doit
respecter le jeu de balises que ce dernier offre.
Dans un premier temps, la norme TEI (Text Encoding Initiative) 1 , application du
format SGML, définit une DTD à même de traiter les documents textuels dans leur
ensemble tout en prenant exemple sur de nombreux types de textes (prose, dictionnaire,
théâtre, poésie, etc.) et plusieurs domaines (publication électronique, analyse littéraire,
recherche documentaire, etc.). La DTD ainsi conçue pour la TEI, modulaire, permet
notamment de définir de nouvelles balises ou de redéfinir celles existantes. Cette possible
personnalisation de la DTD est alors considérée comme une application de la TEI, c’està-dire qu’elle est appliquée dans un cadre bien spécifique. C’est le cas pour le Corpus
Encoding Standard (CES) qui définit un standard d’encodage de corpus dans le cadre du
projet MULTEXT 2 , associé à EAGLES et la collaboration VASSAR/CNRS 3 . À partir
de la DTD de la TEI [Ide et Véronis, 1996], le CES fournit ainsi un ensemble de DTD
spécifiques au codage des corpus textuels, accompagnées de recommandations quant à
leur usage. Le standard a par la suite été redéfini en XML : XCES 4 .
Le CES distingue les données brutes des données annotées (et contenant des informations linguistiques uniquement), qui doivent être séparées : les deux types de données sont
placées dans des fichiers bien distincts, le lien entre données et données annotées se faisant via des liens hypertextes. Par ailleurs, trois DTD sont définies, issues des DTD de la
TEI : CesDoc (encodage des données brutes), CesAna (encodage des données annotées) et
CesAlign (alignement de textes parallèles multilingues). Finalement, le CES définit trois
niveaux d’encodage des documents, d’une structure grossière (jusqu’au niveau du paragraphe) à une structure plus fine (éléments internes au paragraphe) ; ces trois niveaux
d’encodage ont un coût croissant et une automatisation de production décroissante.
En dehors de MULTEXT, le CES a été employé dans le projet PAROLE 5 qui a approfondi la définition des modèles sur deux types de données spécifiques : les unités morphologiques et les unités syntaxiques. Une DTD est proposée pour permettre l’encodage
des données brutes analysées et annotées.
Si les principes (XML, DTD, niveau d’encodage, etc.) du CES sont communément
admis, il faut reconnaître qu’en pratique la séparation des données (brutes et annotées)
ne se fait que très rarement : la plupart du temps les données sont regroupées dans un
même document et sont attachées à une même DTD commune.
D.3
Formats de stockage
Les formats de stockage sont de deux types : le stockage du contenu et le stockage
physique.
Le format de stockage du contenu dépend des caractéristiques mêmes du corpus, à
savoir :
– La taille (un corpus très volumineux va être divisé en plusieurs fichiers pour plus
de commodité lors de son utilisation). Les corpus en recherche d’information sont
1.
2.
3.
4.
5.
http
http
http
http
http
://www.tei-c.org
://aune.lpl.univ-aix.fr/projects/multext
://www.cs.vassar.edu/ ide/research/
://www.xces.org
://www.ub.es/gilcub/SIMPLE/simple.html
265
souvent divisés de manière à n’avoir qu’une centaine de documents par fichier, afin
de ne pas avoir de fichiers trop volumineux, mais aussi de manière limitée afin de
ne pas avoir un trop grand nombre de fichiers (l’un comme l’autre des cas pouvant
poser des problèmes pour les systèmes).
– L’homogénéité : on pourra placer les documents dans des répertoires ou des fichiers
différents selon qu’il contiennent des parties bien distinctes ou non. Par exemple,
la structure d’un corpus bilingue anglais-français peut être telle que les documents
anglais sont placés dans un répertoire « EN » et les documents français dans un
répertoire « FR ».
– La structure : le corpus peut être constitué d’un document par fichier ou de plusieurs
documents par fichiers, le plus souvent regroupés selon le contexte ou la thématique.
Il est très facile d’imaginer un corpus annoté, composé de données provenant de
domaines variés (courriers électroniques, journaux, discours, etc.) : il devient alors
judicieux de décomposer le corpus en plusieurs sous corpus, dans plusieurs fichiers
distincts, afin d’observer ou de paramétrer le système en fonction des besoins. Au
contraire, dans d’autres cas d’utilisation (une évaluation en contexte par exemple)
il pourra être plus judicieux de ne pas distinguer ces différents corpus.
La documentation du corpus aura tendance à être placée à part de manière bien
distincte. Elle doit être facilement accessible.
D’une manière générale, les corpus textuels « bruts » sont placés dans des fichiers
« textes » (avec ou sans extension txt), les corpus avec encodage balisé dans des fichiers
avec l’extension .xml, .sgml, etc. Un corpus textuel peut également être composé de fichiers
compilés non reformaté, de type Word ou PDF, dans des cas d’utilisation en contexte réel.
La plupart du temps, le format de stockage physique dépend d’une part du volume
des documents composants le corpus, et d’autre part de ses caractéristiques, selon que le
corpus est homogène ou contient des parties bien distinctes. Pour de petits corpus, les
données peuvent être déposées sur un serveur FTP pour être directement téléchargées via
le réseau. Ce stockage peut également se faire sur CD-ROM ou DVD-ROM si le corpus est
plus volumineux. L’emploi de disque dur est l’ultime recours lors de corpus extrêmement
volumineux.
266
Annexe E
Liste des acronymes
E.1
Liste des acronymes de projets et de campagnes
ARC
ARCADE
ATIS
C-STAR
CESART
CESTA
CLEF
CRATER
DUC
EASy
EQueR
ESTER
EVALDA
EvaSy
GALE
GRACE
IREX
LC-STAR
MEDIA
Actions de Recherche Concertée
Action de Recherche Concertée sur l’Alignement de Documents et son
Évaluation
Air Travel Information System
Consortium for Speech Translation Advanced research
Campagne d’Évaluation de Systèmes d’Acquisition de Ressources Terminologiques
Campagne d’Évaluation de Systèmes de Traduction Automatique
Cross Language Evaluation Forum
Corpus Resources and Terminology Extraction
Document Understanding Conferences
Évaluation des analyseurs Syntaxiques
Évaluation de systèmes de Question-Réponse
Évaluation des Systèmes de Transcription enrichie d’Émissions Radiophoniques
EVALuation à ELDA
Évaluation de systèmes de Synthèse de la parole
Global Autonomous Language Exploitation
Grammaires et Ressources pour les Analyseurs de Corpus et leur Evaluation
Information Retrieval and Extraction Exercise
Lexica and Corpora for Speech-to-Speech Translation Components
Méthodologie d’Évaluation automatique de la compréhension hors et en
contexte du DIAlogue
267
Annexe E : Liste des acronymes
MUC
Multext
OSIRIM
PASSAGE
Plus
SQALE
Sundial
SUS
TC-STAR
TAC
TDIL
TDT
TREC
E.2
Message Understanding Conference
Multilingual Text Tools and Corpora
Open Services for Indexing and Research Information in Multimedia
Produire des Annotations Syntaxiques à Grande Échelle pour aller de
l’avant
A Pragmatics-based Language Understanding System
Speech recognizer Quality Assessment for Linguistic Engineering
Speech Understanding and Dialogue
Speech Understanding Systems
Technology and Corpora for Speech to Speech Translation
Text Analysis Conference
Technology Development for Indian Languages
Topic Detection and Tracking
Text REtrieval Conferences
Liste des acronymes d’institutions
AFP
ANR
ARPA
ATALA
AUF
CEA
CNRS
DARPA
EDF
ELDA
ELRA
IBM
ISLE
ISSCO
JEIDA
LDC
LIA
LIPN
MIT
NIST
ONU
RALI
RCLN
SPEX
UNESCO
Agence France Presse
Agence Nationale de la Recherche
Advanced Research Projects Agency
Association pour l’étude et le développement de la Traduction Automatique et de la Linguistique Appliquée
Association des Universités Francophones
Commissariat à l’Énergie Atomique et aux Énergies Alternatives
Centre National de la Recherche Scientifique
Defense Advanced Research Projects Agency
Électricité de France
Evaluations and Language resources Distribution Agency
European Language Resources Association
International Business Machines Corporation
International Standards for Language Engineering
Institut Dalle Molle pour les études sémantiques et cognitives
Japan Electronics Industry Development Association
Linguistic Data Consortium
Laboratoire Informatique d’Avignon
Laboratoire d’Informatique de Paris-Nord
Massachusetts Institute of Technology
National Institute of Standards and Technology
Organisation des Nations Unies
Recherche Appliquée en Linguistique Informatique
Représentation des Connaissances et Langage Naturel
Speech Processing EXpertise
United Nations Educational, Scientific and Cultural Organization
268
E.3. Liste des acronymes du traitement automatique des langues et de l’évaluation
E.3
Liste des acronymes du traitement automatique
des langues et de l’évaluation
ALPAC
ASR
BLEU
CER
CES
COD
EAGLES
ELSE
EPPS
Europarl
FAHQT
FEMTI
FTE
GATE
GTM
IWSLT
JEP
JOC
LREC
MLCC
MOS
MULTEXT
PER
ROVER
SLT
SSE
SUSANNE
TAL
TALN
UIMA
WER
WMT
WNM
E.4
API
ASCII
Automatic Language Processing Advisory Committee
Automatic Speech Recognition
BiLingual Evaluation Understudy
Character Error Rate
Corpus Encoding Standard
Complément d’Objet Direct
Expert Advisory Group on Language Engineering Standards
Evaluation in Language and Speech Engineering
European Parliament Plenary Session
European Parliament Proceedings Parallel Corpus
Fully Automatic High Quality Translation
Framework for the Evaluation of Machine Translation in ISLE
Final Text Edition
General Architecture for Text Engineering
General Text Matcher
International Workshop on Spoken Language Translation
Journées d’Étude sur la Parole
Language Resources and Evaluation Conference
Multilingual Corpora for Co-operation
Mean Opinion Score
Position-independent word error rate
Recognizer Output Voting Error Reduction
Spoken Language Translation
Survey of Spoken English
Surface and Underlying Structural ANalysis of Natural English
Traitement Automatique des Langues
Traitement Automatique des Langues Naturelles
Unstructured Information Management Architecture
Word Error Rate
Workshop on statistical Machine Translation
Weighted N-gram Model
Liste des acronymes de l’informatique
Application Programming Interface
American Standard Code for Information Interchange
269
Annexe E : Liste des acronymes
CAS
CD-ROM
CGI
CORBA
DTD
DVDROM
FTP
HTML
HTTP
HTTPS
IEC
IP
ISO
JMS
KDE
ODT
PDF
PHP
RAID
RMI
RTF
SGML
SOAP
Sofa
TEI
UDDI
UMLS
UTF-8
XHTML
XML
WSDL
Common Analysis Structure
Compact Disc - Read Only Memory
Common Gateway Interface
Common Object Request Broker Architecture
Document Type Definition
Digital Versatile Disc - Read Only Memory
File Transfer Protocol
Hypertext Markup Language
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secured
International Electrotechnical Commission
Internet Protocol
International Organization for Standardization
Java Message Service
K Desktop Environment
OpenDocument Text
Portable Document Format
PHP : Hypertext Preprocessor
Redundant Array of Independent Disks
Remote Method Invocation
Rich Text Format
Simple Object Access Protocol
multiple Subject of Analysis
Text Encoding Initiative
Universal Description Discovery and Integration
Unified Medical Language System
UCS Transformation Format 8 bits
Extensible HyperText Markup Language
eXtended Markup Language
Web Service Description Language
270
Glossaire
Accord inter-juges
Accord intra-juge
Adjudication
Adéquation
Application
Architecture
Campagne d’évaluation
Coefficient de corrélation
Composant technologique
Critère d’évaluation
Echelle de valeurs
Evaluateur
Mesure de la concordance des jugements entre
plusieurs juges, 107
Mesure de la cohérence d’un juge avec luimême, 125
Analyse et vérification des résultats de l’évaluation par les participants et les organisateurs. Les résultats sont corrigés et ajustés en
fonction des commentaires reçus, 77
Conservation du sens entre une phrase écrite
dans une langue source et une phrase écrite
dans une langue cible, 115
Ensemble de programmes informatiques facilitant à un utilisateur la réalisation d’une tâche
donnée, 1
Modélisation des relations entre composants
technologiques. Ensemble des procédures et
outils nécessaires à une évaluation regroupés
et organisés au sein d’une même structure, 43
Ensemble coordonné de tâches liées à l’organisation d’une évaluation de plusieurs systèmes
à des fins de comparaison, 4
Mesure du degré de dépendance qui existe
entre deux variables, 164
Élément de base (système ou technologie) d’un
système plus complexe, capable de communiquer avec d’autres composants au sein d’une
chaîne de traitement, 44
Indication des éléments considérés pour l’évaluation d’une caractéristique d’un système, 33
Suite de niveaux hiérarchisés afin de rendre
compte du niveau de la qualité atteint pour
un critère donné, 59
Entité (organisation, individu) organisant et
structurant une évaluation, 3
271
Glossaire
Evaluation
Evaluation automatique
Evaluation comparative
Evaluation d’un système isolé
Evaluation humaine
Expert
F-mesure
Fluidité
Action d’apprécier la valeur de quelque chose,
2
Contexte d’une évaluation utilisant une mesure automatique, 34
Évaluation qui permet d’estimer la performance de systèmes par rapport à d’autres dans
un même contexte, 20
Évaluation d’un système pris à part sans
considérer d’autres systèmes d’une même technologie ni les comparant, 4
Contexte d’une évaluation utilisant une mesure humaine., 34
Individu étant spécialisé et ayant des compétences reconnues dans un domaine ou dans
l’utilisation d’une technologie, d’un système
ou d’une application, 34
Mesure qui combine le rappel et la précision
avec une pondération, 110
Facilité à lire un texte dans une langue donnée,
et correspondance avec les conventions grammaticales de cette langue, 115
Infrastructure d’évaluation
Entité rassemblant la totalité des moyens et
ressources pour évaluer : organisations, acteurs, agents, architectures, etc., 43
Juge
Individu effectuant des jugements, qu’il soit
expert ou utilisateur, 34
Appréciation subjective de la qualité à partir
des connaissances de juges, 2
Jugements humains
Mesure d’évaluation
Mesure d’évaluation automatique
Fonction qui formule une valeur de la qualité
d’une entité (phrase, document, terme, etc.),
33
Se dit d’une mesure employant principalement
un ou des programmes informatiques pour la
mener à bien. Une intervention manuelle peut
se faire a priori afin de préparer la partie automatique. La partie automatique permet la
reproductibilité de la mesure, 34
272
Glossaire
Mesure d’évaluation humaine
Module
Méga-évaluation
Métrique
Métrique automatique
Plate-forme
Post-édition
Précision
Se dit d’une mesure nécessitant une intervention manuelle a posteriori. Une partie automatique peut apparaître (pour préparer la partie manuelle, pour la synthétiser, etc.) mais
elle est moindre comparée à la partie manuelle. L’intervention humaine provoque la
non-reproductibilité de la mesure, 34
Programme, structure de programmation ou
librairie utilisé par un système et effectuant
une action précise, 25
Observation d’évaluations répétées au cours
du temps et de l’évolution de leurs résultats.
Mise en pratique de l’évaluation d’impact, 51
Programme permettant le calcul de la qualité
à partir de données fournies à l’avance. Partie
applicative de la mesure, 49
Programme calculant le niveau de qualité à
partir de références pré-établies, 2
Partie technologique de l’architecture. Ensemble des systèmes, des applications de TAL
ou d’évaluation regroupés au sein d’un réseau
sur lequel parcourent des flux de données, 43
En traduction automatique, se dit d’une traduction corrigée manuellement, a posteriori ,
12
Mesure de la pertinence d’une réponse : calcule le rapport entre le nombre d’objets pertinents renvoyés et le nombre d’objets renvoyés,
110
Rappel
Mesure de la couverture d’une réponse :calcule
le rapport entre le nombre d’objets pertinents
renvoyés et le nombre d’objets pertinents de
référence, 110
Système
Ensemble de programmes informatiques permettant d’automatiser une tâche, 1
Utilisateur
Individu qui fait l’usage final d’une technologie, d’un système ou d’une application sans
pour autant avoir une expertise, 34
WER
Word Error Rate pour taux d’erreur sur les
mots, métrique dérivée de la distance de Levenshtein, 144
273
RÉSUMÉ : Le développement de systèmes en traitement automatique des langues
(TAL) nécessite de déterminer la qualité de leurs résultats. L’évaluation a pour but
d’améliorer ces systèmes mais suppose de formaliser dans un contexte particulier
une méthodologie, un protocole, des ressources linguistiques (RLs, les données nécessaires à l’apprentissage et au test des systèmes) ou des mesures d’évaluation.
Nous cherchons à faciliter l’accès à l’évaluation et à améliorer son efficacité car un
important travail manuel vient compromettre son déroulement et sa fiabilité. Nous
avons formalisé le déroulement d’une campagne d’évaluation et ses différentes phases
pour définir un cadre commun compréhensible par tous dont le point phare concerne
l’utilisation de mesures d’évaluation. Nous avons effectué trois études sur les mesures
humaines, les mesures automatiques et l’automatisation du calcul de la qualité, et
enfin la méta-évaluation des mesures. En parallèle, elles utilisent des RLs dont les
aspects pratiques et administratifs ont leur place dans notre architecture. L’étude
des similarités entre les technologies et entre leurs évaluations nous a permis de
les hiérarchiser et d’en faire ressortir leurs caractéristiques communes. Finalement,
nous centrons l’évaluation autour d’une architecture d’évaluation générique, adaptable aux différentes technologies du TAL, et pérenne en permettant la réutilisation
de RLs, mesures ou méthodes au cours du temps. Suite à des premières expérimentations, nous avons modélisé une architecture d’évaluation qui considère l’ensemble
de ces contraintes et utilise des services Web.
TITLE : Towards a generic and sustainable architecture for evaluation in natural
language processing : specifications, methodologies and measures
ABSTRACT : The development of Natural Language Processing (NLP) systems
needs to determine the quality of their results. Generally, evaluation aims at improving such systems as well as formalising a methodology, protocol, language resources
(LRs, data used for both system training and testing) or evaluation measures for
each particular context. Our objective is to render evaluation accessible while improving its efficiency since a manual work seriously compromises its procedure and
reliability. We have formalised the procedure for an evaluation campaign and its
different phases whose main objective is the use of evaluation measures. This allows
to define a common scope for all users. Three different studies have been carried out
on human measures, automatic measures and the automation of quality computation, respectively, as well as measure meta-evaluation. Moreover, these measures use
LRs and their practical and administrative issues also have their place in our architecture. The study of similarities between technologies and their evaluations has
allowed us to class them and highlight their common features, as a crucial step in
the integration of different approaches. Finally, we focus our evaluation on a generic
evaluation architecture, adaptable to different NLP technnologies, and sustainable
in its reuse of LRs, measures or methods over time. Following initial experiments, an
evaluation architecture has been defined which takes into account all the constraints
found and uses web services.
DISCIPLINE : informatique
MOTS-CLÉS : évaluation, traitement automatique des langues, protocole d’évaluation, mesure d’évaluation, métrique d’évaluation, méta-évaluation, architecture
d’évaluation, traduction automatique
Laboratoire d’Informatique de Paris-Nord, UMR CNRS 7030 – 99, avenue JeanBaptiste Clément, 93430 Villetaneuse – France

UNIVERSITÉ PARIS 13 INSTITUT GALILÉE N˚attribué par la

Transcription

Documents pareils

PALACIUM DE VILLENEUVE D`ASCQ CHAMPIONNAT DE

bulletin d`actualites juridiques - Bulletin d`actualités juridiques HSC

sujets de dissertation sur l`argumentation

Aroui 31-03-2014 - Structures formelles du langage

Liste_JUGES_04 2010 V100616

Les cadeaux de la Cour, J.-P. Goffinon

Les corpus dynamiques et GlossaNet. Extension de

Télécharger le PDF

01 août 2009

Quelques observations sur le mod`ele LDA