• Aucun résultat trouvé

Vers une association plus étroite avec l’agent rationnel

THE ISSMALL ISRED

6.4 Discussion : choix d’implémentation et conséquences

6.4.5 Vers une association plus étroite avec l’agent rationnel

DIGproduisant des représentations sémantiques sur lesquelles l’agent rationnel AR doit se baser pour réagir, on peut imaginer qu’après la définition de celui-ci (évoquée en perspective dans le chapitre 8), le fonctionnement de DIG puisse être partiellement revu afin de produire une interprétation qui soit guidée à la fois par le bas (via l’analyse de corpus) et par le haut (en anticipant sur les heuristiques de traitement).

6.4.5.1 Gestion plus fine des ambigüités sémantiques

Dans certains cas, DIG doit être en mesure de gérer des ambigüités sémantiques qui ne peuvent être traitées au niveau de l’étape de WSD de GRASP. Ainsi, on peut considérer le cas de l’ambigüité entre concept et object dans la requête “Est-ce que tu aimes le rouge ?”, pouvant signifier :

− “Est-ce que tu aimes [l’objet rouge le plus saillant dans l’application] ?”, où la question porte sur un objet de l’application et donc d’une référence de type object[...].

− “Est-ce que tu aimes [la couleur rouge en général] ?”, où il s’agit d’une question sur les goûts de l’agent et d’une référence de type concept[...].

DIG, pas plus que GRASP, n’est réellement en mesure de déterminer le sens exact de la requête dans la mesure où elle relève plus de la pragmatique que de la sémantique. Dans les cas comme celui-ci, nous avons choisi de nous baser sur la situation qui occurre le plus souvent d’après le corpus (pour cet exemple, la première interprétation) et de la choisir par défaut (d’où ici une instanciation de l’entité object[ppt*=color[val=“blue”]]. Néanmoins, il serait préférable de pouvoir gérer de manière plus satisfaisante ces deux cas. Deux approches sont possibles :

Solution 1 : avoir recours à un schème spécial encapsulant les deux valeurs possibles (à la manière de la modalité UNION), e.g. AMBIGUOUS[option1 = object[ppt* = color[val =

“blue”]], option2 = concept[ppt* = color[val = “blue”]]]. À partir de là, l’analyse

ulté-rieure de la requête pourrait être séparée en autant de cas que nécessaire, exécutés de manière concurrente puis comparés :

− au niveau représentationnel : en comparant les requêtes finalement produites en sortie par DIG dans les deux cas, on pourrait par exemple choisir la représentation la plus structurée ou la plus proche de celles présentes dans le corpus Daft.

− au niveau réactionnel : en transmettant les différentes interprétations possibles à l’agent rationnel et en effectuant le choix entre les réactions engendrées par chacune des inter-prétations (actions à réaliser, réponse à prononcer, émotions à exprimer, etc.).

Solution 2 : avoir, parmi les heuristiques de réaction de l’agent rationnel (telles que décrites dans la section 8.2.2.4) une heuristique particulière de gestion des ambigüités, qui autoriserait de lancer une nouvelle analyse sémantique de la phrase par DIG. Ainsi, à partir de l’exemple traité ici, on pourrait lors de la première analyse, au choix :

1. traiter le cas le plus abstrait et hors contexte, i.e. ici l’instanciation d’un concept[]; 2. considérer au contraire le contexte de l’assistance qui pousse à interpréter en priorité

une requête comme faisant référence à l’application assistée, et choisir par défaut la représentation avec une référenceobject[].

L’heuristique de gestion d’ambigüité aurait alors pour rôle de vérifier, à partir du modèle de l’application à sa disposition, l’existence d’éléments bleus saillants4 :

− si elle trouve un élément suffisament saillant : dans le premier cas, elle relance une interprétation par DIG en forçant l’utilisation d’une référence object[], dans le second, l’analyse de la requête se poursuit normalement en faisant désormais abstraction de l’ambigüité.

− si elle ne trouve pas d’élément saillant : dans le premier cas, elle poursuit l’analyse, dans le second, elle relance une interprétation par DIG en forçant l’utilisation d’une référence

concept[].

Si la première solution semble plus facile à implémenter, surtout si le choix doit se faire au niveau représentationnel, dans l’optique d’un agent rationnel et psychologique tel que décrit en 8.2, la seconde semble plus prometteuse. En effet, elle semble plus proche de la manière dont un humain traite une requête de ce type : en fonction de la situation, on privilégie dans un premier temps une des deux interprétations, avant éventuellement de reconsidérer ce choix si après réflexion l’autre interprétation semble finalement plus probable. Par ailleurs, cette capacité à revenir sur son interprétation originelle ou la tendance à opter pour une interprétation plutôt qu’une autre sont des comportements qui pourraient être dépendants de la personnalité ou de l’état émotionnel courant de l’agent (cf. section8.2.1.1).

6.4.5.2 Ordre de traitement des propriétés

Nous avons fait le choix de faire apparaître toutes les entités de classe P au même ni-veau au sein d’une référence. Cependant, quand l’agent rationnel utilise la représentation d’un

object[...]pour l’identifier au sein du modèle de l’application auquel il a accès, certaines

pro-priétés sont sensibles à l’ordre dans lequel elles sont traitées. Nous allons illustrer le problème à l’aide de trois exemples de propriétés, sensibles ou non à l’ordre de traitement.

4Ce qui requiert d’être en mesure d’évaluer la saillance des éléments (au sens gestaltien), comme envisagé

Exemple 1 : une propriété non-sensible à l’ordre :location.

Bien que la position spatiale d’un élément soit mise en évidence dans la langue naturelle et dans le langage DAFT (cf. section 5.4.3) par rapport à d’autres propriétés, d’un point de vue rationnel, elle n’a ni plus ni moins d’importance qu’une autre propriété. Ainsi “le petit bouton en haut” peut tout autant être interprété comme “le petit bouton, qui se trouve en haut”, “le bouton, qui est en haut et qui est aussi petit” ou “l’élément en haut, qui est un petit bouton”. L’ordre de traitement est donc sans importance particulière, tout du moins a priori. En effet, dans des situations particulières, une propriété peut être plus discriminante qu’une autre et pourrait avoir intérêt à être prise en compte en premier lieu. Ainsi, dans l’exemple donné par la figure 6.7, il vaudrait mieux considérer la taille en premier dans l’application 1, à l’inverse de l’application 2 où la position est plus discriminante.

(a) Application 1 : un seul petit bouton (b) Application 2 : un seul bouton en haut

Figure 6.7 Exemple d’applications particulières où l’ordre des propriétés peut

faciliter la recherche d’une référence (en vert épais : la référence recherchée)

Exemple 2 : une propriété sensible à l’ordre à considérer en dernier : quantity.

La quantité, dont le rôle est généralement supporté par le déterminant, permet d’effectuer une sélection au sein d’un ensemble déjà défini. Ainsi, si l’on recherche les éléments correspondant à la référence “plusieurs boutons rouges”, on pourra faire :

1. rechercher tous les objets rouges, 2. rechercher les objets de type bouton,

3. faire l’intersection des deux ensembles obtenus en 1 et 2, 4. vérifier qu’il reste plusieurs éléments.

Si les étapes 1 et 2 peuvent être interverties, en revanche il est clair qu’effectuer la quatrième plus tôt ne serait pas logique et entraînerait un résultat erroné.

Exemple 3 : une propriété sensible à l’ordre à considérer en premier :time.

Dans le cas de la notion de temps, au contraire, il est essentiel de la prendre en compte le plus tôt possible car cela peut changer complètement l’espace dans lequel une référence doit être recherchée. Ainsi, la formulation au passé de la requête “C’était quoi le petit bouton rouge

en haut ?” sous-entend que l’objet en question n’est actuellement plus visible : le rechercher dans le modèle actuel de l’application serait donc sans intérêt, et il faudrait au contraire faire appel (s’il existe) à un modèle de l’application à instant antérieur (cf. les travaux deSabouret & Sansonnet[2000] sur les chroniques).

6.5 Évaluation

Bien que l’évaluation du langage DAFT réalisée à partir d’une annotation manuelle du corpus tel que défini en 5.3ait laissé penser que celui-ci était adapté à la représentation de la sémantique des requêtes, nous avons vu que la construction de manière automatique par DIG des requêtes en DAFT a rendu nécessaire un certain nombre d’ajustements. Par conséquent, il est important d’évaluer la qualité des représentations sémantiques produites par cet outil. De plus, dans la mesure où la détection d’erreurs (i.e. différence entre la représentation DAFT sortie de DIG et la représentation idéale telle qu’on peut la construire manuellement) requiert une connaissance de la sémantique réelle de la requête, cette étape ne peut être effectuée que par un annotateur humain.

Nous allons donc dans un premier temps proposer les critères d’évaluation que nous avons retenus pour annoter les requêtes et illustrer la pertinence de chacun d’eux sur quelques exemples ; ensuite, nous présenterons les résultats de l’annotation selon ces mêmes critères d’un sous-ensemble du corpus traité par DIG.