Évaluation de DAFT 2.0 par rapport au corpus Daft

À noter qu’il s’agit d’un regret au sens large : on ne fait pas à ce niveau la différence entre remords (un acte a été accompli que l’on aurait préféré de pas faire) et regret (on aurait préféré accomplir l’acte en question). Bien que pertinente, celle-ci sera éventuellement à prendre en compte par l’agent rationnel, qui sera lui en mesure de vérifier si l’action ainsi modalisée a été accomplie par le passé.

5.3 Évaluation de DAFT 2.0 par rapport au corpus Daft

Afin d’évaluer l’adéquation du langage formel défini dans la section5.2aux requêtes d’uti-lisateurs qu’il doit modéliser au sein du système DAFT 2.0, il est nécessaire de le confronter au corpus de requêtes, afin de :

1. déterminer la couverture offerte par ce langage, i.e. la part de requêtes pouvant être correctement et entièrement écrites sous forme formelle en DAFT 2.0 ,

2. mener une étude fréquentielle d’utilisation des différentsschèmes.

5.3.1 Pré-évaluation à partir d’une annotation manuelle

Avant de concevoir le module DIG (décrit dans le chapitre 6) qui permet d’automatiser la génération de requêtes en DAFT , nous avons essayé de l’appliquer à une partie du corpus recueillie (Daftr) en annotant manuellement les requêtes.

Nous allons considérer dans les sous-sections suivantes les deux sous-corpus de requêtes, Daft_sub1 et Daft_sub2, tels que définis en section3.3.3.2.

5.3.1.1 Estimation de la robustesse de la structure du langage

Annotation initiale. Étant donné cette structure de langage, nous avons procédé à l’an-notation du sous-ensemble de requêtes Daftsub₁. Lesschèmesnécessaires étaient définis au fur et à mesure des besoins, avec pour seule contrainte le respect de la structure fixée, de manière à voir les contraintes induites par celle-ci.

Correction de l’annotation. Nous avons ensuite effectué une correction des phrases initia-lement annotées en deux temps. Tout d’abord, nous avons cherché à “stabiliser” l’ensemble des

schèmesutilisés en ayant un seulschème(ou structure de schèmes) par structure sémantique :

de la formeModify[property=visibility[val=False]] et une autre fois par une action unique commeHide[].

Ensuite, nous avons repris individuellement chacun desschèmesdéfinis en considérant chacune de ses occurrences, de manière à s’assurer de disposer pour chacun d’une structure unique, aussi simple que possible mais non ambigüe. Par exemple, le schèmeControl, qui représente le fait de gérer/contrôler quelque chose, peut s’appliquer à :

− un élément concret : “je ne vois comment gérer la carte du site” − un concept à valeur de propriété : “qu’est-ce qui contrôle la vitesse ?”

Dans les deux cas, lors de la première annotation, “carte du site” et “vitesse” avaient été associés à un attribut unique “of”. Nous avons préféré le remplacer par deux attributs séparés (“object” et “property”), de manière à pouvoir représenter la partie interne d’une requête de type “qu’est-ce qui contrôle la vitesse du compteur ?” comme Control[property = speed[],

object = object[doing = Count[]]].

Résultats. À l’issue de ce travail, nous avons ainsi exhibé 39 modalités et 62 actions, soit un sous-ensemble relativement important des 44 modalités et 66 actions définies dans les tableaux 5.1,5.2, 5.3 et 5.4 (cf. la section 5.3.1.2 pour les schèmes restants). De plus, il a été possible de modéliser la grande majorité des requêtes de contrôle et d’assistance (cf. le tableau5.6).

Sous-corpus Contrôle Assistance directe Assistance indirecte

Couverture 95,8% 98,3% 92,2%

Tableau 5.6 Couverture d’un sous-ensemble du corpus Daftr par le langage DAFT 2.0 en fonction des activités conversationnelles

Analyse. Si l’on s’intéresse de plus près aux phrases qui n’ont pas pu être modélisées, on peut distinguer certains cas typiques :

− les requêtes de contrôle sans verbe, pour lesquelles la modélisation est réalisable en principe, mais qui supposerait pour être correcte de connaître le verbe associé “par défaut” à la référence.

Exemples de requêtes : “carte du site”, “description”, “membres”. . .

− les requêtes de contrôle sans référence, où le problème est similaire à celui mentionné ci-dessus puisqu’il faudrait ici connaître soit la référence associée par défaut, soit la référence ayant actuellement le focus de l’utilisateur.

Exemples de requêtes : “go”, “fais le”. . .

− les requêtes de contrôle mettant en jeu une référence complexe. Exemples de requêtes : “parle-moi même si tu n’as rien à dire”, “exécute la même chose qu’avant”. . .

− les requêtes d’assistance directe au sujet d’une action imprécise (verbe “faire”) ou qui sont liées à une requête précédente.

Exemples de requêtes : “que fais-tu ?”, “pourquoi tu le fais pas ?”, “si tu ne veux pas faire ce que je te dis, très bien, mais dis moi quoi faire”, . . .

Dans tous les cas, une modélisation n’est donc pas impossible d’un point de vue strictement structurel (on peut à chaque fois construire une requête respectant la syntaxe du langage DAFT ) mais elle serait en fait simplement partielle en l’absence d’informations complémen-taires.

On peut en conclure que la syntaxe du langage DAFT 2.0 est suffisamment robuste et adap-table pour nos objectifs.

5.3.1.2 Estimation de la couverture du langage

Une fois admise l’adéquation de la structure du langage, la seconde question qui se pose est celle de la couverture. Autrement dit, il faut que le langage que l’on définisse soit suffisam-ment générique pour pouvoir considérer que l’ensemble des schèmesdonnés est suffisant pour modéliser toute requête que l’agent assistant sera amené à traiter, c’est-à-dire des requêtes nouvelles (non présentes dans le corpus Daft).

Première annotation. Afin d’évaluer ceci, nous avons commencé par procéder à une anno-tation d’un nouveau sous-ensemble de requêtes, Daftsub₂. Lors de cette formalisation manuelle des requêtes, seuls pouvaient être utilisés les schèmesdéfinis en 5.3.1.1.

Seconde annotation. Dans un second temps, nous avons repris les phrases de Daftsub2

qui n’avaient pas pu être formalisées lors de l’annotation initiale, en levant cette fois-ci la contrainte de non ajout de nouveaux schèmes.

Résultats. Lors de la seconde annotation, nous avons pu annoter une vingtaine de phrases supplémentaires en ajoutant 4 actions (Choose, Execute, Interact et Link) et 2 modalités

(REFERENTIALetUNION). On obtient ainsi des taux de phrases annotés similaires à ceux obtenus

dans la section5.3.1.1 (cf. tableau5.6).

Analyse. Nous avons ainsi mis en évidence qu’une augmentation de 100% de la taille du corpus considéré pour définir les schèmes de DAFT 2.0 (Daft_sub1 puis Daft_sub1 ∪ Daftsub₂) n’entraîne qu’une augmentation de 5% des schèmes requis. Avec un corpus dix fois plus im-portant (Daft_r), on peut donc raisonnablement penser être en mesure d’obtenir un langage couvrant bien le champ de l’assistance aux usagers novices, au vocabulaire spécifique à l’ap-plication près qui devrait pouvoir être ajouté par le concepteur de l’apl’ap-plication (par exemple, “compter” n’est pas forcément en soi une action générique, mais elle est saillante dans le cas de l’application “Coco le compteur” definie dans la table3.3).