Une interprétation générique de commandes en langue naturelle dans les systèmes de dialogues à base d ontologies

Transcription

1 Une interprétation générique de commandes en langue naturelle dans les systèmes de dialogues à base d ontologies Laurent Mazuel Nicolas Sabouret Laboratoire d Informatique de Paris 6 - LIP6 8 rue du Capitaine Scott Paris {laurent.mazuel ;nicolas.sabouret}@lip6.fr RÉSUMÉ. Cet article présente une architecture générale vers une approche plus générique pour les agents conversationnels. Notre architecture contient des modules génériques (dans le sens d indépendant de l application) de traitement des langues naturelles (LN) basés sur les ontologies pour l interprétation de commandes. Nous nous intéresserons particulièrement à la présentation du générateur d évènements et du gestionnaire de dialogue, le tout reposant sur une approche ascendante pour l appariement des commandes de l utilisateur avec l ensemble des actions possibles. ABSTRACT. This paper presents a general architecture towards a more generic approach to conversational agents. Our architecture contains generic (in sense of application independent) natural language (NL) modules that are based on ontologies for command interpretation. We focus on the presentation of the event generator and dialogue manager modules which rely on a bottom-up approach for matching the user s command with the set of currently possible actions. MOTS-CLÉS : Interaction Humain-Agent, Commande en langue naturelle, Systèmes de dialogues, Agent assistant, Ontologies. KEYWORDS: Human-Agent interaction, Natural Language command, Dialogue Systems, Assistant agents, Ontologies.

2 1. Introduction Les travaux récents sur les Agents Conversationnels Animés (ACA) [CAS 00] et, de manière plus générale, sur les systèmes de dialogue [ALL 01] montrent que l interaction en langue naturelle est une étape cruciale vers une interaction humainagent plus intuitive. Cependant, les approches actuelles pour la description des interactions d un ACA s appuient essentiellement sur des méthodes de pattern-matching syntaxique [BIC 04]. La communauté des systèmes de dialogues [DZI 03, MIL 03] propose d utiliser des ontologies pour introduire la généricité dans ces systèmes. L objectif est de concevoir des algorithmes génériques dépendant uniquement du langage formel choisi pour modéliser l ontologie. Dans ce sens, les applications dépendent uniquement de leur ontologie et du résolveur spécifique au problème (e.g. [DZI 03, PAR 04]). Cependant, la plupart de ces systèmes utilisent un langage de description d ontologies ad-hoc, dépendant fortement du type d application. Par conséquent, ces ontologies décrivent de manière redondante le modèle de l application et la description des actions du système. Nous pensons au contraire qu il devrait être possible d extraire ces connaissances directement à partir du code du résolveur de problème. L ontologie fournit alors seulement les informations sémantiques complémentaires sur les relations entre les concepts de l application (ce qui est d ailleurs son rôle initial). D autre part, les systèmes qui utilisent une représentation générique des ontologies (e.g. [MIL 03]) reposent sur des modules de Traitement Automatique des Langues (TAL) dépendant de l application. L ontologie est utilisée pour lever des ambiguïtés mais l essentiel du système est complètement spécifique à l application. Cet article présente un système générique de TAL basé sur une ontologie de domaine et un langage agent permettant l introspection pour l interprétation des commandes de l utilisateur. Notre système extrait l ensemble des entrées possibles à partir du code de l agent et les évaluent en fonction de la commande utilisateur, en utilisant l ontologie comme lien sémantique. Nous utilisons un gestionnaire de dialogue basé sur un calcul de scores (du type [MAE 94]) pour faire des propositions à l utilisateur dans le cas de commandes partiellement ou mal comprises. Notre article est organisé de la façon suivante. Dans la deuxième section, nous donnons un aperçu de notre modèle de programmation agent. La troisième section présente notre système de TAL. Nous présenterons d abord notre parseur, puis notre algorithme pour l interprétation de commandes, puis notre gestionnaire de dialogue. 2. Présentation du modèle Nos agents sont programmés dans le langage VDL (View Design Language) 1. Le modèle VDL est basé sur la réécriture d arbre XML : la description de l agent est un arbre XML dont les noeuds représentent soit des données soit des actions. L agent réécrit son arbre à chaque pas d exécution en suivant certains noeuds dont la balise 1.

3 correspond à un mot-clef spécifique. Ce modèle permet aux agents d accéder pendant leur l exécution à la description de leurs actions afin de raisonner (par exemple pour planifier, analyser leur comportement, répondre à des questions sur leur fonctionnement, etc[sab 01]). Cette capacité d introspection est utilisée dans notre système de TAL non seulement pour construire l ensemble des commandes formelles possibles, mais aussi pour faire un retour à l utilisateur sur les commandes impossible. Enfin, la structure XML du langage est utilisée pour la génération de réponse en langue naturelle basé sur [BAT 97]. De plus, dans le modèle VDL, chaque agent possède une ontologie de domaine en OWL 2 qui doit contenir tous les concepts utilisés par l agent (i.e. les concepts VDL), soit comme balise XML, soit comme attributs (clé ou valeur), soit comme contenue CDATA. Nous noterons C V DL l ensemble des concepts VDL et C OW L l ensemble des concepts, instances ou noms de propriétés OWL. Nous définissons alors une fonction injective map V DL définie dec V DL à C OW L associant un concept VDL à un concept de l ontologie. Pour l interprétation des commandes, notre système se focalise sur la description des actions de l agent. En VDL, comme dans la plupart des modèles, les actions sont définies par un tuple < N, P, E > avec N comme nom d action, P comme ensemble de préconditions et E l ensemble des effets. De plus, les interactions avec l utilisateur ou les autres agents sont effectuées par des évènements externes. Les évènements externes (notés par la suite seulement évènements) sont la représentation formelle des commandes et sont envoyés à l agent en cours d exécution. Soit R l ensemble des actions de l agent. Pour une action donnée r R, nous pouvons définir quatre type de préconditions en VDL : 1) P e (r) est l ensemble des préconditions d évènement. Elles filtrent les commandes pouvant passer dans l action par subsumption des évènements reçus. 2) P s (r) est l ensemble des préconditions de structure. Elles sont utilisées pour vérifier la syntaxe de l évènement et ainsi garantir que l action pourra l exploiter. Les préconditions P s ne dépendent donc pas de l état interne de l agent, mais seulement de l évènement reçu. 3) P c (r) est l ensemble des préconditions de contexte, i.e. les préconditions dépendant uniquement de l état courant de l agent. 4) P cs (r) est l ensemble des préconditions contextuelles structurelles, i.e. les préconditions dépendant des évènements (sélectionnées par P e ) et de l état courant de l agent. Nous notons P e = r R P e (r). Pour tout e P e, nous notons R e (e) = {r R e P e (r)} l ensemble des actions associé à l élément e. 2.

4 Figure 1. Architecture générale 3. Interprétation des commandes en langue naturelle Cette section présente les algorithmes utilisés pour la construction d évènements VDL à partir de la commande de l utilisateur. Ces algorithmes sont basés sur l ontologie OWL de l agent et la description des actions de l agent en VDL Chaîne de TAL et architecture globale Dans notre projet, le module lexical est basé sur les modules étiqueteur et chunker 3 de OpenNLP 4, avec un lémmatiseur développé au LIP6 (voir figure 1). Comme montré par Milward [MIL 00] et évalué dans [SAB 05], l utilisation d un analyseur syntaxique (par opposition avec un simple chunker) n est pas efficace pour les commandes en langue naturelle. En effet, les utilisateurs emploient plus souvent des mots clefs que des phrases bien structurées (e.g. drop object low ou "take blue ). Nous utilisons donc actuellement une représentation du type sac de mots (après avoir enlever les mots blancs repérés par leur étiquette). Cette représentation pose un problème important de perte d informations dans le cas général (voir par exemple les travaux de Milward [MIL 00]), mais, conséquence du domaine des agents que nous avons considérés dans nos évaluations, cela n entraîne pas de pertes de performances et supprime les problèmes soulevés dans [SAB 05]. Le coeur de notre approche est l analyse sémantique des commandes. Notre objectif à long terme est d utiliser l ensemble des relations décrites dans les ontologies pour l appariement de concepts entre la commande et les connaissances de l agent. Dans la version actuelle, nous faisons simplement appel à la relation de synonymie owl :sameas de OWL. Notre analyse sémantique repose sur l hypothèse de connectivité sémantique [SAD 97] enrichie par la relation de synonymie : tout les concepts ap- 3. Le chunker permet de découper la phrase en groupes nominaux et groupes verbaux, afin de supprimer une partie des ambiguïtés de l étiqueteur. 4.

5 paraissant dans une commande pertinente sont soit directement associés à un concept de l agent défini dans l ontologie, soit associés à un concept de l ontologie en relation sameas avec un concept de l agent. Plus formellement, si S est le sac de mots issu de l analyse lexicale et syntaxique de la commande, nous pouvons définir l ensemble C des concepts reconnus : C = {v C V DL s S. map V DL (v) = s ou map V DL (v) owl :sameas s} 3.2. Génération d évènements Notre approche s inspire de l approche ascendante adoptée entre autres par Allen [ALL 96]. Cette approche utilise classiquement une liste de compétence prédéfinie et essaye alors d apparier la commande en langue naturelle avec une des commandes formelles disponibles (e.g. [PAR 04, DZI 03]). L inconvénient majeur de cette approche est que ces listes de compétence doivent décrire tous les cas de dialogue possible, y compris les dialogues concernant des actions impossibles. Pour éviter ce problème, nous proposons d adopter une approche ascendante constructive basée sur l analyse des préconditions des actions de l agent. Le problème de la génération des commandes formelles (évènements) à partir des préconditions a été largement étudié pour la validation de logiciel (e.g. [BOT 02]) et la génération de cas de test. De manière similaire, notre approche utilise les informations contextuelles pour construire l ensemble des évènements exploitable par l agent à l instant présent. Notre système construit ainsi la liste des évènements possibles (du point de vue de l agent), sans se préoccuper de l appariement avec la commande utilisateur. De la même manière, en relâchant les contraintes sur les préconditions liées au contexte (P c et P cs ), nous construisons la liste des évènements actuellement impossible, c.-à.-d les évènements qui seraient acceptés par l agent dans un autre état que l état courant. Nous évitons ainsi l utilisation de listes de compétences puisque les évènements possibles et impossibles sont obtenus directement à partir de la description des actions de l agent en VDL. Nous utilisons tout d abord les préconditions d évènement (P e ) pour fournir le squelette initial de l évènement. Comme P e filtre les évènements externes en utilisant la subsumption, tous les évènements construits par addition de sous-éléments à un squelette e P e seront acceptés. Réciproquement, tous les évènements acceptables doivent être construits à partir d un squelette. Nous noterons Υ l ensemble (infini) de tous les noeuds VDL possibles. Pour construire l ensemble des évènements possibles, nous devons retirer de P e les squelettes d évènements lié à des actions ne pouvant pas être exécutés dans l état courant : P e+c = e P e p r R e(e) P c (r), eval(p, e) =

6 avec eval : Υ 2 {, } la fonction d évaluation d une précondition : p P(r), eval(p, e) = ssi la précondition p est valide en tenant compte de l évènement e et du contexte courant de l agent. P e+c est l ensemble des squelettes d évènements pouvant être accepté par l agent en tenant compte des contraintes liées au contexte (P c ). On peut remarquer que P e+c P e. Nous utilisons ensuite les préconditions de structure et les préconditions structurelles contextuelles (P s et P cs ) comme un ensemble de contraintes sur les évènements afin de faire évoluer les squelettes vers des évènements résultats. Pour tout e P e, nous notons refine(e, r) Υ l évènement obtenu à partir du squelette e et de l ensemble des préconditions P s (r) P cs (r) de l action r R e (e) en utilisant notre algorithme de génération de cas de test évoqué ci-avant. L algorithme complet pour refine est trop long pour être présenté ici. Il dépend fortement de la sémantique opérationnelle du langage VDL et est basé sur une interprétation récursive des termes VDL suivant des règles spécifiques en fonction des mots clefs du langage rencontrés. Nous pouvons maintenant construire les ensembles E et F d évènements syntaxiquement corrects : E = F = {refine(e, r), e P e+c, r R e (e) p P s (r) P cs (r), eval(p) = } {refine(e, r), e P e, r R e (e) p P s (r), eval(p) = } E est l ensemble des évènements possible : tous les évènements de E sont acceptés par l agent et tous les évènements acceptables sont dans E. Inversement, F est l ensemble des évènements actuellement impossible, i.e. les évènements qui ne sont pas acceptable par l agent dans son état courant mais qui seraient acceptés dans un autre état. A partir de ces deux ensembles, le système de TAL doit sélectionner l évènement le plus proche de la commande utilisateur. Notre proposition consiste à calculer un degré de pertinence pour chaque évènement et de déterminer les sous-ensembles d évènements de E et F ayant la pertinence maximale. Pour tout noeud n Υ et pour tout concept c C, nous notons contains(n, c) le prédicat permettant de déterminer si c apparaît quelque part dans le noeud n : contains(n, c) = x sub(n) c {tag(x), attributes(x), content(x)} avec sub(n) l ensemble de tous les sous-éléments directs ou indirects de n Υ. Nous appelons pertinence d un évènement e E F la valeur : p(e) = card({c C contains(e, c)}) card(c) Nous construisons alors les sous-ensembles de pertinence maximale E et F : X {E, F }, X = {e X p(e) = max({p(x), x X})}. Nous obtenons ainsi

7 l ensemble E des évènements possibles et l ensemble F des évènements actuellement impossible à partir de E et F : { if max({p(x), x X}) = 0 X = X otherwise pour X {E, F} et X {E, F }. Notons que, par construction, tous les évènements de E (resp. F) ont la même probabilité : e E, p(e) = p E and e F, p(e) = p F. De plus, e F, nous notons np(e) l ensemble des préconditions invalides qui rendent cet évènement e impossible : np(e) = {p P c (e) P s (e) P cs (e) eval(p) = } 3.3. Le gestionnaire de dialogue Notre gestionnaire de dialogue (GD) est basé sur un système de scores comme dans [MAE 94]. Nous utilisons deux seuils définis dans l intervalle [0, 1] correspondant aux tell me et do it de Patty Maes [MAE 94]. p min (tell me) est la valeur minimal pour qu un évènement puisse être considéré comme une commande comprise mais imprécise et p max (do it) est la limite par delà laquelle l évènement est considéré comme étant une représentation fidèle à la commande 5. La réponse donnée par le gestionnaire dépend de la position de p E et p F par rapport à p min et p max. Les exemples donnés sont ceux d une communication avec un robot virtuel pouvant prendre des objets de différentes formes, tailles et couleurs et pouvant les poser sur une grille 3 3 : 1) Si p E p max, la commande est considérée comme correctement comprise par le système. Le GD envoie soit l évènement à l agent (si E = 1), soit informe l utilisateur d une ambiguïté (si E > 1). Par exemple : U : Take something red S : I can either take object square red, take object triangle red. 2) Si p min < p E < p max et p E < p F, l évènement le mieux compris est impossible (p F > p E ) mais quelque chose de proche a été compris et est possible (p E > p min ). Le GD demande à l utilisateur de reformuler. Il affiche l ensemble des préconditions fausses des évènements impossible ( e Fmax np(e)) et la liste des évènements possibles E. U : Put it on the upper left cell (alors que la case en haut à gauche est déjà occupée) S : I can t because : the content of upper left cell is not empty. Therefore, i can either : - drop object in the upper middle, in the upper right, in the center left or in the lower left 5. Patty Maes propose empiriquement d utiliser les valeurs p min = 0.3 et p max = 0.8.

8 3) Si p min < p E < p max et p F < p E, les évènements impossibles peuvent être ignorés, mais le système n est pas sur d avoir compris la commande (p E < p max ). Il demande à l utilisateur de confirmer sa commande en lui affichant les évènements possibles. U : Take the blue or red triangle form (alors qu il n y a pas de triangle bleu) S : Do you mean take object triangle red? 4) Si p E p min et p max p F, le système comprend correctement une commande impossible. Il préviens l utilisateur que sa commande est impossible en lui donnant la liste de préconditions fausse np(e), e F max. U : Take the blue red figure (alors que la main tient déjà une forme) S : I can t because : the content of hand is not empty. 5) Si p E p min et p min < p F < p max, le système pense avoir compris une commande mais qui ne peut pas être exécutée. Le GD demande confirmation à l utilisateur. 6) Si p E p min et p F p min, le système n a pas compris la commande de l utilisateur et le prévient. Notre gestionnaire de dialogue produit donc différentes réponses en fonction des différentes situations du contexte, des commandes comprises ou ambiguës, des événements possibles ou impossibles Conclusion & perspectives Nous avons présenté une architecture de TAL générale pour l interprétation de commandes basée sur l idée que les algorithmes génériques peuvent être paramétrés par le code de l agent et une ontologie de domaine. Notre système repose sur une approche ascendante constructive à partir des préconditions des actions. Même si nous utilisons le langage VDL pour programmer les agents, l approche en est indépendante et peux être facilement adaptée à d autres modèles capable d introspection. Nous avons réalisé une évaluation préliminaire de notre système qui montre que le feedback fourni par le gestionnaire de dialogue permet à l utilisateur de s aligner sur l ontologie de l agent. Notre système explique à l utilisateur pourquoi une commande donnée ne peux pas être acceptée et peux montrer ce qu il attend. Les utilisateurs ont ainsi la sensation que le système est plus intelligent avec notre approche constructive avec gestionnaire qu avec les approches classiques. L évaluation montre que les limites du système résident dans l analyse sémantique minimale faite avec l ontologie (utilisation de synonymes uniquement). Pour palier ce problème, nous proposons d utiliser des mesures de distances sémantique (comme celle résumée par [BUD 06] par exemple) pour associer les concepts de la commande humaine avec les concepts de l agent liés à ceux de l ontologie. Cette méthode doit à terme permettre au système d interpréter des commandes non prévues par le programmeur de l agent.

9 5. Bibliographie [ALL 96] ALLEN J., MILLER B. W., RINGGER E. K., SIKORSKI T., «A Robust System for Natural Spoken Dialogue.», ACL, 1996, p [ALL 01] ALLEN J., BYRON D., DZIKOVSKA M., FERGUSSON G., GALESCU L., STENT A., «Towards Conversational Human-Computer Interaction», AI Magazine,, [BAT 97] BATEMAN J. A., «Enabling technology for multilingual natural language generation : the KPML development environment», Nat. Lang. Eng., vol. 3, n o 1, 1997, p , Cambridge University Press. [BIC 04] BICKMORE T. W., «Unspoken rules of spoken interaction», vol. 47, n o 4, 2004, p , ACM Press. Commun. ACM, [BOT 02] BOTELLA B., TAILLIBERT P., GOTLIEB A., «Test de logiciel», vol. 21, chapitre Utilisation des contraintes pour la génération automatique de cas de test structurels, p , RSTI-TSI, [BUD 06] BUDANITSKY A., HIRST G., «Evaluating WordNet-based measures of semantic distance», Computational Linguistics, vol. 32, n o 1, 2006, p [CAS 00] CASSEL J., SULLIVAN J., PREVOST S., CHURCHILL E., Embodied Conversational Agents, MIT Press, [DZI 03] DZIKOVSKA M. O., ALLEN J. F., SWIFT M. D., «Integrating linguistic and domain knowledge for spoken dialogue systems in multiple domains», Proc. of IJCAI-03 Workshop on Knowledge and Reasoning in Practical Dialogue Systems, August [MAE 94] MAES P., «Agents that reduce workload and information overload», Communications of the ACM, vol. 37, n o 7, 1994, p [MIL 00] MILWARD D., «Distributing Representation for Robust Interpretation of Dialogue Utterances.», ACL, 2000, p [MIL 03] MILWARD D., BEVERIDGE M., «Ontology-based dialogue systems», Proc. 3rd Workshop on Knowledge and reasoning in practical dialogue systems (IJCAI03), Acapulco, Mexico, August 2003, p [PAR 04] PARAISO E. C., BARTHÈS J.-P. A., TACLA C. A., «A Speech Architecture for Personal Assistants in a Knowledge Management Context.», ECAI, 2004, p [SAB 01] SABOURET N., SANSONNET J., «Automated Answers to Questions about a Running Process», Proc. CommonSense 2001, 2001, p [SAB 05] SABOURET N., MAZUEL L., «Commande en langage naturel d agents VDL», Proc. 1st Workshop sur les Agents Conversationnels Animés (WACA), 2005, p [SAD 97] SADEK D., BRETIER P., PANAGET E., «ARTIMIS : Natural Dialogue Meets Rational Agency.», IJCAI (2), 1997, p