Architecture de CoCoA

CoCoAétend la structure de Dogma en intégrant différents modules conçus pour répondre aux besoins fonctionnels de sa partie privée identifiés dans la section 4.1.1.

Organisation de l’état d’information

L’architecture de notre agent s’organise autour de l’état d’information de Traum et Larsson [TL03] présenté en section 2.3.2, celle-ci est donnée en figure 4.1. La partie en gris clair représente le gestionnaire de dialogue Dogma et la partie en noir représente la structure de CoCoA.

L’état d’information est divisé en deux : d’un côté il y a le tableau de conversation, qui représente l’état du dialogue à un instant donné. Il est supervisé par Dogma et est

5. Cf. le README du projet trindikit.py : https://github.com/heatherleaf/py-trindikit/blob/ master/README.md, visité le 26/11/2018.

Figure4.1 – Architecture technique de notre agent la partie grisée représente Dogma et la partie en noir représente CoCoA.

considérée comme strictement partagée entre l’agent et l’utilisateur. Il constitue la partie publique de l’état d’information. La partie privée de CoCoA n’y a qu’un accès en lecture.

D’un autre côté, il y a la partie privée de l’état d’information, qui contient les « croyances » de l’agent, c’est-à-dire toutes les informations qui lui sont propres et qu’il considère comme vraies pour représenter l’état actuel de la tâche. Celui-ci est supervisé par CoCoA, dont les modules y accèdent en lecture et en écriture. CoCoA est composé de trois modules : un gestionnaire de prédicats, un gestionnaire d’état et un module intentionnel. Ces modules traitent et mettent à jour les informations présentes dans son état d’information privé, c’est-à-dire les prédicats déduits, l’état courant de l’interaction et la valeur des maturités des états de la tâche.

La description des prédicats, des comportements possibles et des états de l’interaction est réalisée en dehors de la définition du fonctionnement de l’agent et est à la discrétion du concepteur de l’agent final. De la même manière, les jeux de dialogue, de communication et les événements dialogiques doivent être spécifiés dans les termes du gestionnaire de dialogue construit à partir de Dogma.

Nous décrivons maintenant comment s’organise CoCoA et comment sa partie privée se combine à Dogma.

Articulation entre la partie privée de CoCoA et Dogma

D’après Traum et Larsson [TL03], la gestion du dialogue est composée de quatre fonctions :

— mettre à jour le contexte dialogique à partir des communications des interlocuteurs ; — avoir des capacités d’interprétation du comportement communicatif observé

dépen-dantes du contexte ;

— s’interfacer avec le traitement de la tâche et le domaine d’application (base de données, gestionnaire de plans. . . ) pour coordonner le comportement dialogique et non-dialogique ;

— décider du contenu sur lequel s’exprimer par la suite et quand l’exprimer. Ces fonctions sont assumées par CoCoA et Dogma de façon partagée.

Mettre à jour le contexte dialogique C’est le rôle de Dogma en tant que gestion-naire de dialogue de veiller à la mise à jour de manière cohérente la structure du dialogue. Les actes de dialogue émis par CoCoA sont directement passés à Dogma pour être intégrés au dialogue, la cohérence dialogique de ceux-ci ayant été vérifiée avant leur émis-sion. En ce qui concerne les actes de dialogue reçus de la part de l’utilisateur, ceux-ci sont pré-traités par la partie privée de CoCoA qui essaye de les rattacher de manière cohérente au contexte actuel de la tâche. C’est seulement si cette contextualisation est réussie qu’ils sont passés à Dogma pour être intégrés au dialogue. Si la contextualisation échoue, il sont simplement ignorés par l’agent. La partie privée de CoCoA a donc une influence indirecte sur le contexte dialogique en ayant la possibilité d’exclure des actes de dialogue de l’utilisateur si ceux-ci ne trouvent pas de place dans le contexte de la tâche.

L’algorithme 2 décrit plus loin présente la manière dont l’agent contextualise un acte de dialogue de l’utilisateur.

Contextualiser le comportement communicatif observé La contextualisation d’un coup dialogique par notre agent est réalisée à deux niveaux. Le premier niveau est celui de la tâche, que CoCoA va faire évoluer en contextualisant les coups dialogiques de l’utilisateur. Cette contextualisation est rendue possible par l’utilisation des prédicats et du concept de maturité dans la structuration de la tâche afin de décider de l’accepta-bilité d’un coup dialogique de l’utilisateur dans le contexte actuel de la tâche. Si cette contextualisation du coup dialogique par rapport à la tâche réussit, elle rend possible sa contextualisation par rapport au dialogue. La structure des motifs dialogiques utilisés par Dogma lui donne des capacités interprétatives organisant la manière dont un acte de dialogue de l’utilisateur va être intégré à la représentation courante du dialogue.

S’interfacer avec le domaine La responsabilité des aspects propres au domaine est complètement dévolue à CoCoA. C’est au moment du calcul des prédicats que l’agent est capable d’activer ou non les prérequis des états et les préconditions des comportements réalisables. Le calcul de ces prédicats se base sur le contexte dialogique courant, les engagements contractés par les interlocuteurs, et les ressources du domaine d’application de la tâche auxquelles l’agent a accès. Une définition correcte de ces prédicats est donc primordiale pour permettre à l’agent de faire correctement le lien entre les actes de dialogue de l’utilisateur et la réalisation de la tâche.

Décider du prochain coup dialogique La décision du prochain coup à jouer se situe sur deux plans : le conventionnel, dépendant de Dogma, et l’intentionnel dépendant de CoCoA. Les capacités génératives de Dogma permettent à l’agent de savoir ce qui est conventionnellement attendu de sa part à n’importe quel moment du dialogue. La volonté de créer un agent collaboratif nous invite à donner la priorité aux actes conventionnellement attendus dans le contexte dialogique courant, afin de renforcer l’aspect coopératif du dialogue. C’est seulement si aucun acte n’est conventionnellement attendu que l’agent peut prendre l’initiative d’un comportement réalisable. Cette initiative est prise par CoCoA en fonction de l’état actuel de la tâche. L’algorithme 3 décrit plus loin illustre la manière dont l’agent articule le choix entre les coups attendus dans les contexte actuel et les initiatives qu’il peut prendre.

Boucle principale de l’agent

Afin de montrer l’organisation des concepts de maturité (section 3.2.1), de sélection d’un comportement (section 3.2.3) et de contextualisation d’un acte de dialogue de l’utilisateur (section 3.2.2), l’algorithme 1 décrit la boucle principale de l’agent. Nous verrons en section 4.2.3 l’algorithme de sélection du prochain coup à jouer par l’agent (algorithme 3) et l’algorithme de contextualisation d’un coup dialogique de l’utilisateur (algorithme 2).

Algorithme 1 : Boucle principale de l’agent tant que vrai faire

GestionnaireDePrédicats.MettreÀJourPrédicats();

ModuleIntentionnel.MettreÀJourPrérequisEtPréconditions();

ModuleIntentionnel.MettreÀJourMaturités() ; // Applique les définitions 3.1 and 3.2

1 ProchainCoup ← ModuleIntentionnel.ChoisirProchainCoup() ; // Expliqué dans l’algorithme 3

2 siProchainCoup 6= NIL alors

3 JouerProchainCoup(ProchainCoup);

4 sinon

// Attend que l’utilisateur fasse quelque chose 5 ad_u ← ObtenirActeDeDialogueUtilisateur() ;

// Expliqué dans l’algorithme 2

6 GestionnaireDÉtat.ContextualiserActeDeDialogueUtilisateur(ad_u);

L’algorithme répète une boucle qui commence par faire appel au gestionnaire de prédicats pour mettre à jour ces derniers dans la partie privée de l’état d’information. C’est ensuite le module intentionnel qui est appelé pour mettre à jour les prérequis des états et les préconditions des comportements réalisables. Le calcul des prédicats se fait en utilisant l’état d’information actuel de l’agent ainsi que d’éventuelles ressources extérieures. La mise à jour des prérequis et préconditions est ensuite directe car ceux-ci ne dépendent que de la valeur des prédicats. Les nouvelles valeurs de maturité des comportements réalisables et des états (correspondant aux définitions 3.1 et 3.2) sont ensuite mises à jour par le module intentionnel. Le module intentionnel utilise ensuite ces valeurs pour décider du prochain coup à jouer. Si l’agent en trouve un, il le joue, incrémente le temps et répète la boucle. Sinon, il attend que l’utilisateur fasse un acte de dialogue, fait appel au gestionnaire d’états pour le contextualiser, incrémente le temps et répète la boucle.

La fonction ObtenirActeDeDialogueUtilisateur() (l.5) attend simplement que l’utilisateur émette un acte de dialogue. Un autre mécanisme, non présenté ici, décrit en section 3.3.1, est prévu pour solliciter l’utilisateur si celui-ci est inactif pendant un certain temps.