Ce document présente la campagne d’évaluation " par défi " des systèmes de compréhension de la parole (CAP) mise en oeuvre dans le cadre du GT 5.2 du PRC I3. Cette campagne vise à permettre à chacun des participants de mieux cerner les capacités et limitations de son système, et de l’améliorer éventuellement à la lumière du comportement des systèmes des autres participants. Elle ne doit donc pas être confondue avec une évaluation-compétition de type ATIS-DARPA. En particulier, trois caractéristiques principales distinguent cette campagne d’évaluation de celles classiquement menées dans le domaine :

• elle vise une capitalisation des connaissances entre les différents participants ; ceci grâce à une analyse commune des cas d’échec des systèmes et une mise en perspective de ces limitations au regard des approches adoptées,
• elle cherche à donner une connaissance fine du comportement de chacun des systèmes, suivant une méthodologie d’évaluation adaptée des analyses de " logfiles ",
• il s’agit d’une campagne d’évaluation légère, ne nécessitant aucune adaptation des systèmes testés (absence de représentation sémantique ou même d’application communes), mais impliquant tout de même l’ensemble des participants dans la définition des jeux de test.

PARTICIPANTS

Cinq systèmes de CAP ont participé à cette campagne d’évaluation :

• Laboratoire CLIPS-IMAG (Grenoble ; resp. : M.Z. Kurdi)
• Laboratoire IRIT (Toulouse ; resp. : C. Bousquet-Vernhettes)
• Laboratoire LIMSI (Orsay ; resp. : S. Rosset)
• laboratoire VALORIA (Vannes ; resp. : J. Villaneau)
• Laboratoire VALORIA (Vannes ; resp. : J. Goulian)

• réunion de synthèse globale

• Jean-Yves ANTOINE, Caroline BOUSQUET, Jerome GOULIAN, Mohammed-Zakaria KURDI, Sophie ROSSET, Nadine VIGOUROUX (2002).  "Predictive and objective evaluation of speech understanding: the “challenge” evaluation campaign of the I3 speech workgroup of the French CNRS". Actes LREC’2002. 3rd European Conference on Language Resources and Evaluation. Las Palmas de Gran Canaria, Espagne. Mai 2002 [PDF]
• Jean-Yves ANTOINE (2001) Méthodologie d'évaluation par défi. Rapport de recherche VALORIA-EQUIPAGE-LN-2001-1, Université de Bretagne Sud, Vannes (voir texte ci-dessous)

METHODOLOGIE D'EVALUATION PAR DEFI
 

Jean-Yves Antoine — Version 1.2. - 22/03/2001 — Rapport de recherche VALORIA-EQUIPAGE-LN-2001-1

• Principes généraux

La méthodologie d’évaluation adoptée dans le cadre de cette campagne répond aux principes suivants :

• Jeux de tests spécifiques à chaque système — Ces tests sont élaborés à partir d’énoncés — dits énoncés initiaux — fournis par les concepteurs du système testé : il s’agit d’énoncés qui sont d’une part supposés représentatifs du domaine d’application concerné et sont d’autre part correctement traités par le système. Ces énoncés initiaux sont donc spécifiques à chaque système évalué.
• Défi — Pour chaque système étudié, un jeu de tests— énoncés dérivés — est construit par l’ensemble des participants à partir des énoncés initiaux spécifiques au système. Ces énoncés dérivés peuvent être vus comme une réécriture ou une complexification des énoncés initiaux. Ils sont supposés poser problème au système : ils peuvent par exemple correspondre à l’ajout de phénomènes difficiles à traiter (auto-corrections, erreurs de reconnaissance par exemple), que les concepteurs du test sachent ou non traiter correctement avec leur propre système (d’où la notion de défi).
• Evaluation — Chaque système étant évalué sur un jeu de tests spécifique, l’objectif de cette camapgne n’est pas de fournir une comparaison quantative de type " taux global d’erreur " mais de procéder à une analyse de type " logfiles " sur les énoncés dérivés élaborés par les autres participants. En conséquence :

• Synthèse — Chaque participant réalise, au vu de l’évaluation conduite, une analyse synthétique des réussites et des échecs constatés de son système. Ceux-ci sont mis en regard de l’approche adoptée pour la mise en oeuvre du système.

• Mise en oeuvre dans le cadre du GT 5.5.

• Constitution des énoncés — Afin de donner une certaine représentativité aux résultats obtenus, cette campagne d’évaluation sera réalisée sur un nombre d’énoncés dérivés non négligeable. On propose de suivre le schéma suivant de constitution des énoncés :

• Chaque concepteur de système propose aux autres participants 20 énoncés initiaux non triviaux jugés représentatifs du domaine d’application du système (domaine qui peut varier d’un système à l’autre, comme nous l’avons vu).
• Les autres participants — au nombre de 3 dans le cas de ce groupe de travail — définissent alors chacun 15 énoncés dérivés pour chaque énoncé initial. Ces énoncés seront définis de manière systématique (cf § 2.1.) et seront caractérisés par un type de phénomène ou de problème précis (énoncé avec auto-correction, ellipse, erreur de reconnaissance), voire par une combinaison de plusieurs phénomènes (par exemple : auto-correction + ellipse). Au total, chaque système sera donc évalué sur : 3 * 20 * 15 = 900 énoncés dérivés.
• Notons que le choix des phénomènes ou problèmes choisis est le fait que chaque participant : l’évaluation ne repose pas sur la définition d’une taxonomie de problèmes communs. Par contre, il est conseillé de considérer les mêmes phénomènes pour chacune des dérivations d’énoncés initiaux, ceci afin d’avoir un nombre significatif de tests par type de phénomène / problème évalué.
• Les énoncés dérivés devront être validés par le concepteur du système. Il se peut en effet que l’énoncé produit puisse être considéré comme " hors domaine " pour le système évalué. Dans ce cas, le concepteur du système demandera une modification de(s) l’énoncé(s) correspondant(s).

• Enoncés initiaux : simple entête précisant le nom du fichier, le nom et le laboratoire du concepteur des énoncés et éventuellement certaines contraintes d’encodage afin de faciliter le traitement par le système. Numérotation des énoncés initiaux de 1 à 20 entre chevrons (à la manière des balises SGML). Exemple :

• Enoncés dérivés (fichier de test) : un fichier par participant (i.e. par concepteur d’énoncés dérivés). Simple entête précisant le nom du fichier, le nom et le laboratoire du concepteur des énoncés dérivés, puis les informations concernant les énoncés initiaux (fichier initial et nom et laboratoire du concepteur). Un numéro et date de version sont également précisés, ceci en cas d’aller-retour d’invalidation/révision des énoncés dérivés entre le concepteur du système et les autres participants. La numérotation des énoncés dérivés reprend le numéro de l’énoncé initial suivi d’un point et du numéro de dérivation propre à cet énoncé. Cette numérotation est donnée entre chevrons d’ouverture et de fermeture (à la manière des balises SGML). Avant le chevron de fermeture, on précise éventuellement entre crochets du type de phénomène concerné par a dérivation. Par exemple :

==============================================================

FICHIER TEST : DERIVE_LAMBDACOMP_CLIPS.TXT

CONCEPTEUR TEST : M.Z. Kurdi (CLIPS)

VERSION : 2

DATE : 02/04/2001

FICHIER INITIAL : INIT_LAMBDACOMP.TXT

CONCEPTEUR SYSTEME : J. Villaneau (VALORIA)

==============================================================

<1.1> mon train le 10 decembre c'est a 19 heures 37 qu'il arrive [EXTRACTION GAUCHE + CLIVAGE] </1.1>

<1.2> a 19 heures 37 le 10 décembre il arrive mon train [EXTRACTION A GAUCHE ET A DROITE] </1.2>

....

<2.1> je voudrais reserver alors si c’est possible hein une chambre sympa avec vue sur la mer [INCISE] </2.1>

Résultats brut : Fichier équivalent au fichier de test fichier avec simple mention supplémentaire du résultat de l’analyse entre chevrons : <RES=1> pour une analyse correcte et <RES=0> sinon. Dans le cas d’une évaluation incorrecte, le champ entre chevron pourra comporter une partie informative, introduite par le mot-clé ERR précisant la nature de l’erreur observée. Par exemple : <RES=0 ERR=substitution de Tours par tour>. Cette information est placée juste avant la " balise " de fermeture d’énoncé. Exemple :

==============================================================

FICHIER RESULTAT : RESULT_LAMBDACOMP_CLIPS.TXT

FICHIER TEST : DERIVE_LAMBDACOMP_CLIPS.TXT

CONCEPTEUR TEST : M.Z. Kurdi (CLIPS)

VERSION : 2

DATE : 02/04/2001

FICHIER INITIAL : INIT_LAMBDACOMP.TXT

CONCEPTEUR SYSTEME : J. Villaneau (VALORIA)

==============================================================

<1.1> mon train le 10 decembre c'est a 19 heures 37 qu'il arrive [EXTRACTION GAUCHE + CLIVAGE] <RES=1></1.1>

<1.2> a 19 heures 37 le 10 décembre il arrive mon train [EXTRACTION A GAUCHE ET A DROITE] <RES=0 ERR=substitution 10 (décembre) par 19></1.2>

....

<2.1> je voudrais reserver alors si c’est possible hein une chambre sympa avec vue sur la mer [INCISE] <RES=1></2.1>