Le cadre de gestion de dialogue Serdaigle: Architecture et systèmes

Abstrait

Dans cet article, nous décrivons Serdaigle, un cadre de gestion de dialogue basé sur un plan et indépendant des tâches. Serdaigle isole les aspects spécifiques au domaine de la logique de contrôle de dialogue des compétences conversationnelles indépendantes du domaine, et facilite ainsi le développement rapide de systèmes à initiative mixte opérant dans des domaines complexes axés sur les tâches. Les développeurs peuvent se concentrer exclusivement sur la description de la logique de contrôle des tâches de dialogue, tandis qu'un grand nombre de domaines indépendants les compétences conversationnelles telles que la gestion des erreurs, le timing et la prise de virage sont soutenues et appliquées de manière transparente par le Moteur de dialogue Serdaigle. À ce jour, Serdaigle a été utilisé pour construire et déployer un grand nombre de systèmes, couvrant différents domaines et styles d'interaction, tels que l'accès à l'information, les dates des vacances scolaires l'orientation par le biais de procédures, le commandement et le contrôle, diagnostic médical, etc. Le cadre s'est facilement adapté à tous ces domaines, ce qui témoigne d'un haut degré de polyvalence et évolutivité.

  1. Introduction Au cours des dernières années, les progrès de la reconnaissance vocale automatique, ainsi que la compréhension du langage, la génération et la synthèse vocale ont ouvert la voie à l'émergence de conversations complexes axées sur les tâches interfaces de langue parlée. Exemples: Jupiter (Zue et coll., 2000) fournit des renseignements météorologiques à jour par téléphone; CMU Communicator (Rudnicky et al., 1999) agit à titre d'agent de planification des voyages et peut organiser des itinéraires multi-étapes et faire des réservations d'hôtel et de voiture; TOOT (Swerts et al., 2000) donne parlé accès aux horaires des trains la région de Stockholm; TRIPS (Ferguson et Allen, 1998)est un assistant de planification en langue parlée. Ce ne sont que quelques-uns; pour une liste plus longue, voir (Bohus, 2007). Architecturalement, ces systèmes sont conçus autour de plusieurs composants clés généralement connectés dans un pipeline architecture, telle que celle représentée sur la Fig. 1. Le signal audio de l'utilisateur est capturé et passé à travers un module de reconnaissance vocale qui produit une hypothèse de reconnaissance. Cette hypothèse de reconnaissance est ensuite transmise à un composant de compréhension du langage qui crée une représentation sémantique correspondante. Ce l'entrée sémantique est ensuite transmise au gestionnaire de dialogue, qui, en fonction du contexte d'entrée et de discours actuel, produit l'action système suivante (généralement sous la forme d'une sortie sémantique). Un module de génération de langue produit ensuite la forme de surface (textuelle) correspondante, qui est ensuite transmise à une synthèse vocale module et rendu en tant qu'audio à l'utilisateur. Le gestionnaire de dialogue joue donc un rôle de contrôle clé dans toute interface de langue parlée conversationnelle: compte tenu de l'entrée sémantique décodée correspondant à l'énoncé de l'utilisateur actuel et au contexte de discours actuel, elle détermine l'action système suivante. Essentiellement, le gestionnaire de dialogue est responsable de la planification et du maintien de la cohérence, au fil du temps, de la conversation. Plusieurs tâches doivent être effectuées afin d'accomplir cet objectif avec succès. Tout d'abord, le gestionnaire de dialogue doit maintenir un historique du discours et l'utiliser pour interpréter le perçu entrées sémantiques dans le contexte actuel. Deuxièmement, une représentation – explicite ou implicite – du système la tâche est généralement requise. L'entrée sémantique actuelle, ainsi que l'état et les informations de la boîte de dialogue actuelle A propos de la tâche à effectuer est ensuite utilisé pour déterminer l'action suivante du système. Comme nous le verrons plus tard, différents des théories et des formalismes ont été proposés pour prendre ces décisions. Dans certains gestionnaires de dialogue, il existe un plan universel prédéfini pour l'interaction, c'est-à-dire que les actions du système sont prédéterminées pour un utilisateur donné entrée. D'autres systèmes font certaines hypothèses sur la structure de l'interaction et planifient dynamiquement le prochain mouvement au moment de l'exécution, basé sur des règles de dialogue génériques. Souvent, les gestionnaires de dialogue doivent également interagir avec divers agents spécifiques au domaine et à l'application. Par exemple, un système de dialogue qui aide les utilisateurs à réservations de vol doit communiquer avec une base de données pour obtenir des informations et effectuer les transaction. En guidant la conversation, le gestionnaire de dialogue doit également être conscient et doit implémenter un certain nombre de mécanismes conversationnels génériques. Un premier exemple est le timing et la prise de décision. La plupart des systèmes font le hypothèse que les deux participants à la conversation apportent des contributions successives au dialogue. Plus des modèles complexes doivent être développés pour soutenir les barges, les canaux arrières ou les conversations multi-participants.

Un autre exemple est la gestion des erreurs. Dans les systèmes conversationnels basés sur la parole, le composant de gestion de dialogue doit être capable de prendre en compte les incertitudes sous-jacentes dans les résultats de reconnaissance et de planifier la conversation en conséquence. À moins que des mécanismes robustes pour détecter et récupérer des erreurs ne soient présents, la parole les erreurs de reconnaissance peuvent conduire à des pannes complètes dans l'interaction. D'autres compétences de conversation génériques comprennent la capacité de répondre de manière appropriée à diverses demandes comme " pouvez-vous répéter cela?”, ‘attendez une seconde”, etc. Dans cet article, nous décrivons Serdaigle, un cadre de gestion de dialogue basé sur un plan et indépendant des tâches. Un l'une des principales caractéristiques de ce framework est qu'il isole les aspects spécifiques au domaine de la logique de contrôle de dialogue de compétences conversationnelles indépendantes du domaine, et dans le processus, il facilite le développement rapide de systèmes à initiative mixte opérant dans des domaines complexes et axés sur les tâches. Système développeurs peuvent se concentrer exclusivement sur la description de la logique de contrôle des tâches de dialogue, tandis qu'un grand nombre de compétences conversationnelles indépendantes du domaine tels que la gestion des erreurs, le timing et la prise de virage sont pris en charge et appliqués de manière transparente par le Serdaigle boîte de dialogue moteur.

  1. Technologies actuelles de gestion des dialogues Un certain nombre de solutions différentes pour le problème de gestion de dialogue ont été développées à ce jour dans le communauté. Certaines des techniques les plus utilisées sont: état fini, remplissage de formulaire, information-État-mise à jour, et des approches fondées sur des plans. Chacune de ces approches fait des hypothèses différentes sur la nature de la interaction; chacun a ses propres avantages et inconvénients. Dans cette section, nous présentons brièvement chacun de ces technologies, pour fournir l'arrière-plan pour le reste de la présentation. Un examen plus approfondi de ces technologies n'entre pas dans le cadre du présent document; pour le lecteur intéressé, McTear (2002) fournit une enquête plus complète. Dans un gestionnaire de dialogue à états finis, le flux de l'interaction est décrit via un automate à états finis. À chaque point dans la boîte de dialogue, le système est dans un certain état (chaque État correspond généralement à une invite système). Dans chaque État, le système attend un certain nombre de réponses possibles de la part de l'utilisateur; sur la base de la réponse reçue, le système passe à un nouvel état. Pour développer un gestionnaire de dialogue pour une nouvelle application, l'auteur du système doit construire l'automate d'état fini correspondant. En théorie, la représentation des automates à états finis est suffisamment flexible pour capturer tout type d'interaction. En pratique, cette approche ne convient mieux que pour la mise en œuvre de systèmes relativement simples qui conservent l'initiative tout au long de la conversation. Dans ces cas, la représentation des automates à états finis est très facile à développer, à interpréter et à maintenir. Toutefois, les états finis la représentation ne s'adapte pas bien pour des applications ou des interactions plus complexes. Par exemple, dans un système à initiative mixte (où l'utilisateur est également autorisé à diriger et à déplacer le centre de la conversation) , le nombre de transitions dans l'automate à états finis deviennent très grandes; la représentation devient difficile à gérer. Un exemple représentatif de cette approche est la boîte à outils de gestion des dialogues du CSLU (Cole, 1999; Understanding, 2007). Une autre technologie de gestion de dialogue, particulièrement utile dans les domaines d'accès à l'information est le remplissage de formulaires (également connu sous le nom fente de remplissage). Dans ce cas la base pour représenter la tâche d'interaction du système est la forme (ou le cadre). Un formulaire se compose d'une collection de slots, ou des éléments d'information à recueillir auprès de l'utilisateur. Par exemple, dans un système d'information sur les horaires des trains, les créneaux horaires peuvent être la ville de départ et d'arrivée, la date et l'heure du voyage. Chaque emplacement a une invite système associée qui sera utilisée pour demander le correspondant informations de l'utilisateur. Généralement, une action est associée à chaque formulaire, par exemple l'accès à la base de données des horaires dans le système ferroviaire. Le système GUIDE la boîte de dialogue de manière à collecter les emplacements requis utilisateur (certains emplacements peuvent être en option); l'utilisateur peut également prendre l'initiative et fournir des informations sur machines à sous que le système n'a pas encore demandé. Une fois que toutes les informations souhaitées sont fournies, le système effectue l'action associée au formulaire. La tâche d'interaction du système peut être représentée comme une collection 334 D. Bohus, A. I. Rudnicky / Ordinateur de la Parole et du Langage 23 (2009) 332-361 de formes enchaînées, avec une logique spécifiée pour la transition entre ces formes. En comparaison avec la représentation de finitestate, l'approche de remplissage de formulaire fait des hypothèses plus fortes sur la nature de l'interaction tâche, et dans le processus permet aux auteurs du système de le spécifier plus facilement. Comme nous l'avons mentionné précédemment, cette l'approche est bien adaptée dans les domaines d'accès à l'information où l'utilisateur fournit certaines informations au système, et le système accède à une base de données ou effectue une action sur la base de ces informations. Cependant, l'approche ne peut pas être facilement utilisée pour construire des systèmes dans des domaines avec des styles d'interaction différents: tutorat, conseils, livraison de messages, etc. Des exemples représentatifs de cette approche sont la norme de L'industrie VoiceXML (VoiceXML, 2007) et le système SpeechMania de Phillips (Aust et Schroer, 1998).

Processus de décision de gestion des erreurs distribuées

La décision d'engager l'une des stratégies de récupération d'erreur décrites dans la section précédente est prise par le processus de décision de gestion des erreurs dans le moteur de dialogue Serdaigle. Ce processus est mis en œuvre de manière distribuée. Il se compose d'une collection de modèles de gestion des erreurs plus petits, automatiquement associés à chaque demander l'agent et chaque concept dans l'arborescence des tâches de dialogue, comme illustré sur la Fig. 10. Les modèles de gestion des erreurs associés à des concepts individuels, également connus sous le nom de modèles de gestion des erreurs conceptuelles, sont responsables de la récupération des malentendus sur ces concepts. Ils utilisent comme preuve la confiance scores pour ce concept particulier (c.-à-d., la croyance actuelle sur ce concept) et déclencher le malentendu les programmes de rétablissement tels que la confirmation explicite ou implicite. Les modèles de gestion des erreurs associés aux agents de requête individuels, également appelés gestion des erreurs de requête les modèles, sont responsables de la récupération des non-compréhensions qui se produisent pendant les demandes correspondantes. Ils utilisent comme éléments de preuve caractérisant l'état actuel de non-compréhension et de dialogue et déclenchent le Le tableau 1 Stratégies de gestion des erreurs indépendantes des tâches dans le nom du système de gestion de dialogue Serdaigle. D. Bohus, A. I. Rudnicky / Ordinateur de la Parole et du Langage 23 (2009) 332-361 349 ne pas comprendre les stratégies de récupération, telles que demander à l'utilisateur de répéter, demander à l'utilisateur de reformuler, répéter l'invite du système, fournissant de l'aide, etc. Au cours de la phase de gestion des erreurs, chaque modèle de gestion des erreurs de concept et de requête calcule et transmet sa décision à un mécanisme de blocage. Le mécanisme de gating met en file d'attente ces actions (si nécessaire) et s'exécute un à la fois. Par exemple, dans l'exemple de la Fig. 10, le modèle de gestion des erreurs pour le start_time concept signalé qu'il voulait déclencher une confirmation explicite sur ce concept; les autres modèles ne pas prendre toute action. Dans ce cas, le mécanisme de blocage créé une nouvelle instance d'une confirmation explicite agence, lui a passé un pointeur sur le concept à confirmer (start_time), et l'a placé sur la pile de dialogue, comme illustré dans la Fig. 9. À la fin, la croyance sur le concept confirmé est mis à jour à la lumière de l'utilisateur réponse, et la boîte de dialogue reprend d'où elle s'est arrêtée. Le comportement de chaque modèle de gestion des erreurs est spécifié au moyen d'une stratégie de contrôle. Généralement, une stratégie de contrôle définit le comportement du modèle via un ensemble de paramètres qui décrivent le coût de diverses actions dans diverses circonstances. Par exemple, une stratégie ‘pessimiste” prédéfinie pour un modèle de gestion des erreurs au niveau du concept spécifie coût élevé pour les erreurs de fausse acceptation; par conséquent, le modèle a tendance à toujours s'engager dans des confirmations explicites. Alternativement, une politique ‘optimiste” prédéfinie spécifie un coût relatif inférieur pour les erreurs de fausse acceptation, et par conséquent le modèle n'engage des confirmations explicites que si la confiance pour l'hypothèse du concept supérieur est inférieure à une certaine seuil. Les stratégies mentionnées ci dessus ne sont que deux exemples de stratégies de gestion des erreurs prédéfinies simples disponible dans le cadre de gestion de dialogue Serdaigle. Un certain nombre de politiques supplémentaires sont disponibles, et d'autres encore peuvent être facilement créés et utilisés par l'auteur du système. Le cadre permet un degré élevé de flexibilité dans les comportements de gestion des erreurs. Par exemple, un modèle de gestion des erreurs peut prendre en compte le nombre de corrections précédemment effectuées par l'utilisateur et en effet créer une stratégie de gestion des erreurs dynamique (c'est-à-dire que le système réagit différemment en fonction du nombre de corrections effectuées précédemment par l'utilisateur). En outre, piloté par les données les modèles de gestion des erreurs (c'est-à – dire utilisant des stratégies apprises par machine) peuvent et ont également été implémentés-voir par exemple notre travail sur l'apprentissage supervisé en ligne des politiques de rétablissement non compréhensives (Bohus et al., 2006). La nature distribuée et encapsulée de la décision de gestion des erreurs augmente son évolutivité et prend en charge approches basées sur l'apprentissage de la gestion des erreurs. Tout d'abord, la structure et les paramètres de la gestion des erreurs individuelles les modèles peuvent être liés à différents concepts ou agents de requête. Dans L'exemple de la Fig. 10, la gestion des erreurs le modèle pour le concept start_time peut être supposé identique à celui pour le concept end_time; tous les modèles contrôlant les concepts booléens (Oui/Non) peuvent également être liés entre eux (par exemple, l'auteur du système peut configurer au moment de la conception tous les concepts oui/non dans l'arborescence des tâches pour utiliser le même ensemble de paramètres). Paramètre attachant peut grandement améliorer l'évolutivité des approches basées sur l'apprentissage parce que les données sont interrogées ensemble et le nombre total de paramètres augmente sous-linéairement avec la taille de la tâche (c'est-à-dire avec le nombre de concepts et d'agents de requête dans l'arborescence des tâches de dialogue). Deuxièmement, les politiques apprises dans un système peuvent être réutilisées dans d'autres systèmes parce que l'erreur les modèles de gestion sont découplés de la spécification de tâche de dialogue réelle. Par exemple, nous nous attendons à ce que le la mise à la terre des concepts oui/non fonctionne de la même manière à différents endroits dans la boîte de dialogue, mais également entre les domaines. Troisièmement, l'architecture proposée permet la génération dynamique de tâches. L'arborescence des tâches de la boîte de dialogue (la boîte de dialogue Figue. 10. Processus de décision de gestion des erreurs distribuées. 350 D. Bohus, A. I. Rudnicky / Ordinateur de la Parole et du Langage 23 (2009) 332-361 plan) peut être développé dynamiquement au moment de l'exécution, et la gestion des erreurs de concept et de requête correspondante les modèles seront créés à la volée. Si la structure et les paramètres du modèle sont liés, nous n'avons pas besoin de savoir la structure complète de la tâche à exécuter par le système à l'avance. Ces avantages découlent de l'hypothèse d'indépendance faite par l'architecture proposée: l'erreur gestion des modèles associés à différents concepts et agents de requête dans l'arborescence des tâches de dialogue indépendamment les uns des autres. Nous croyons que dans la pratique les avantages acquis en faisant cette indépendance l'hypothèse et le recours à un processus de gestion des erreurs distribué et encapsulé l'emportent de manière significative sur inconvénients potentiels.

  1. Autres stratégies conversationnelles indépendantes du domaine Outre les stratégies de gestion des erreurs, le cadre de gestion de dialogue Serdaigle fournit une prise en charge automatique d'un certain nombre de stratégies conversationnelles indépendantes du domaine. Les exemples incluent la capacité de gérer les délais d'attente, les demandes d'aide, pour répéter le dernier énoncé, suspendre et reprendre la conversation, recommencer, rétablir le contexte, etc. En interne, ces stratégies sont implémentées en tant qu'agences de dialogue de bibliothèque, à l'aide de la spécification de tâche de dialogue formalisme décrit précédemment, dans la Section 4.1. L'auteur du système Spécifie simplement les stratégies de la boîte de dialogue moteur devrait être en utilisant, et les paramétrise en conséquence. Les stratégies sont appelées automatiquement par le moteur de dialogue à des moments appropriés. Généralement, ces stratégies implémentent des déclencheurs qui seront automatiquement mettez-les au point lorsque l'utilisateur fait une demande spécifique. Par exemple, la stratégie Repeat définit un déclencheur sur le concept de grammaire sémantique . Lorsque l'utilisateur demande au système de répéter, le déclencheur se déclenche et le moteur de dialogue place automatiquement la stratégie de répétition sur la pile de dialogue. La stratégie puise dans le sous-composant de gestion de sortie dans Serdaigle et répète la dernière requête système ou énoncé. Dialogue puis reprend à partir du point où il a été laissé. En outre, les développeurs de systèmes peuvent écrire de nouvelles stratégies conversationnelles indépendantes des tâches, les encapsuler en tant qu'agents de bibliothèque, et les rendre disponibles pour une utilisation dans D'autres systèmes de dialogue basés sur Serdaigle. Actuel l'architecture favorise la réutilisabilité et assure la cohérence des comportements à l'intérieur et entre les systèmes.
  2. Systèmes basés sur Serdaigle Dans la section précédente, nous avons décrit en détail le cadre de gestion Serdaigle dialog, ainsi que les algorithmes et les structures de données qui régissent sa fonction. Nous portons maintenant notre attention sur le problème de l'évaluation et discutons de plusieurs systèmes de dialogue parlé qui ont été développés à ce jour à l'aide de ce cadre. L'évaluation des interfaces de langue parlée est une tâche difficile et a reçu beaucoup d'attention du milieu de la recherche (Walker et coll., 1997; Walker et coll., 1998; Parfaire et Graham, 2000; Walker et coll., 2001; Hartikainen et coll., 2004). L'évaluation d'un cadre de gestion de dialogue pose des défis encore plus difficiles. De à notre connaissance, aucune évaluation objective de ce type n'a été effectuée à ce jour. Caractéristiques telles que la facilité d'utilisation, portabilité, indépendance de domaine,évolutivité, robustesse, etc. sont très difficiles à capturer de manière quantitative. Dans un sens, peut-être que le problème est mal posé. Comparer les cadres de gestion de dialogue est comme comparer langages de programmation: alors que des arguments peuvent être faits sur les différentes forces et faiblesses de divers langages de programmation, aucun ordre clair ou mesure de la performance absolue ne peut être établi. Certains langages de programmation sont plus appropriés pour certaines tâches que d'autres. Même l'évaluation de la pertinence d'une langage de programmation (ou cadre de gestion de dialogue) pour une tâche prédéfinie peut être difficile, étant donné que de nombreuses applications peuvent être reformulées sous une forme qui peut être tractable dans une approche particulière. Comme première étape vers une évaluation plus rigoureuse du cadre de gestion du dialogue Serdaigle, nous décidé à utiliser ce cadre pour construire un certain nombre de systèmes de dialogue parlé couvrant différents domaines et l'interaction types. Dans le cadre de ce processus, nous avons suivi divers aspects du processus de développement et noté degré d'accommodement requis par Serdaigle. Nous avons vu dans la section précédente que Serdaigle est une architecture à deux niveaux qui dissocie les aspects spécifiques au domaine de la logique de contrôle de dialogue du moteur de dialogue indépendant du domaine. Pour créer une nouvelle boîte de dialogue Gestionnaire, les auteurs du système doivent développer une spécification de tâche de dialogue, essentiellement un plan hiérarchique pour le interaction. Le moteur de dialogue gère la boîte de dialogue en exécutant cette spécification de tâche de dialogue.

L'interface graphique est accessible via un écran translucide porté sur la tête connecté à un ordinateur client portable. Une souris rotative (cadran) fournit un accès direct aux éléments de L'interface graphique. Le L'interface graphique est connectée via le Galaxy hub au reste du système: les événements de la souris rotative sont rendus sémantiques les entrées et sont envoyées à Helios qui effectue l'intégration multimodale et transmet les messages correspondants au gestionnaire de dialogue. Le gestionnaire de dialogue traite donc les entrées équivalentes reçues sur différents canaux de manière uniforme; l'effort de création de dialogue est similaire à celui d'un système vocal uniquement. 356 D. Bohus, A. I. Rudnicky / Ordinateur de la Parole et du Langage 23 (2009) 332-361 Bien que ce système n'ait jamais été déployé au quotidien, nous avons évalué LARRI sur deux occasion. Les évaluations ont été effectuées sur une base militaire, avec la participation de personnel de la Marine formé, et ont été axées sur la compréhension de l'expérience des mécaniciens. Alors que les utilisateurs ont commenté favorablement sur l'interface basée sur la langue, une analyse plus approfondie des sessions et des commentaires ont révélé un certain nombre de problèmes. Ils la nécessité d'une meilleure rétroaction sur l'état du système; un équilibre plus flexible (contrôlable) entre le sorties parlées et Graphiques, ainsi que des améliorations à la conception de L'interface graphique. Pour le lecteur intéressé, un plus une discussion détaillée est disponible dans Bohus et Rudnicky (2002).

  1. TeamTalk TeamTalk (Harris et coll., 2005; Dias et coll., 2006) est une interface de langue parlée multi-participants qui facilite la communication entre un opérateur humain et une équipe de robots. Le système fonctionne dans un domaine de chasse au trésor multi-robotassisted. L'opérateur humain est chargé de rechercher un espace pour les objets d'intérêt et de apportez ces objets à un emplacement spécifié. Pour réaliser cette tâche, l'opérateur humain dirige les robots dans un opération de recherche. Par exemple, dans une expérience (Harris et coll., 2005), les utilisateurs devaient naviguer (seulement en utilisant le canal de la parole) deux robots à travers les couloirs vers un certain emplacement dans un bâtiment. Le domaine est Commande et contrôle dans la saveur, mais pose un certain nombre de défis supplémentaires en raison de la nature multiparticipante de la conversation. Du côté de l'entrée, les robots doivent être en mesure d'identifier qui est le destinataire de tout énoncé d'utilisateur donné. Du côté de la sortie, les robots doivent résoudre le problème du canal conflit (c.-à-d., plusieurs participants se parlant l'un sur l'autre). Pour le lecteur intéressé, des détails sur le les solutions actuelles à ces problèmes sont discutées dans Harris et coll. (2005). Plus généralement, en dehors de la aspects multi-participants, certains des autres objectifs de recherche du projet TeamTalk sont: (1) Comprendre les compétences nécessaires à la communication dans une équipe homme-robot, (2) développer des langages pour la navigation robot dans de nouveaux environnements et (3) comprendre comment de nouveaux objets, lieux et tâches sont décrits dans langue. Le cadre Serdaigle/Olympus a également été relativement facilement adapté aux exigences de ce domaine. Dans l'architecture actuelle, chaque robot utilise son propre gestionnaire de dialogue basé sur Serdaigle, mais tous les robots partagent le autres composants Olympus: reconnaissance vocale basée sur Sphinx-II, compréhension du langage basée sur Phoenix, Génération de langage basée sur Rosetta et synthèse vocale basée sur le Festival (chaque robot utilise une voix différente). TeamTalk peut interfacer avec de vrais robots, y compris le Pioneer P2DX et le Segway RMP. En outre, il peut interfacer avec des robots virtuels dans le USARSim haute fidélité (Balakirsky et al., 2006) environnement de simulation. Les entrées utilisateur traitées sont envoyées à tous les gestionnaires de dialogue (robots) du système; chaque gestionnaire de dialogue décide basé sur un algorithme simple (Harris et coll., 2005), que l'entrée actuelle lui soit adressée ou non. Si c'est le cas, une action est effectuée; sinon l'entrée est ignorée (elle sera traitée et traitée par un autre robot, c'est à dire, gestionnaire de boîte de dialogue). Seules des modifications mineures ont été nécessaires dans L'architecture Serdaigle/Olympus pour prendre en charge plusieurs dialogues gestionnaire. Par exemple, les messages de sortie Serdaigle ont été augmentés avec des informations sur l'identité du gestionnaire de dialogue qui les a générés; ces informations ont ensuite été utilisées par le composant de synthèse pour décider de la voix à utiliser.
  2. Débat et travaux futurs Dans cet article, nous avons décrit Serdaigle, un cadre de gestion de dialogue basé sur un plan et indépendant des tâches. Le cadre trouve ses racines dans l'architecture précédente de gestion de dialogue de L'ordre du jour utilisée dans le CMU Communicator project (Rudnicky et coll., 1999). Contrairement à l'arborescence de gestionnaires ad hoc utilisée dans le L'architecture de l'Agenda (qui a capturé la tâche de dialogue entière), Serdaigle impose une séparation claire entre les aspects spécifiques au domaine de la logique de contrôle de dialogue et les stratégies conversationnelles indépendantes du domaine. Le les aspects spécifiques au domaine sont capturés via un plan hiérarchique pour la conversation, construit par le système auteur. Un moteur de dialogue indépendant du domaine utilise une pile pour suivre la structure du discours et planifie la conversation en fonction de la logique de dialogue spécifiée et des entrées reçues de l'utilisateur. Les entrées sont intégrées dans le discours au moyen d'une structure de données spécialisée - l'agenda des attentes, qui fournit un soutien pour interaction mixte d'initiative, désambiguïsation basée sur le contexte et en général permet un contrôle fin sur D. Bohus, A. I. Rudnicky / Ordinateur de la Parole et du Langage 23 (2009) 332-361 357 traitement d'entrée (à la fois le dialogue et les niveaux de traitement d'entrée inférieurs – par exemple un langage spécifique à l'état dynamique modélisation). De plus, le moteur de dialogue Serdaigle fournit et contrôle automatiquement un riche répertoire des compétences conversationnelles réutilisables, telles que la gestion des erreurs, le timing et la prise de décision, l'établissement du contexte, etc. Un certain nombre de parallèles peuvent être établis entre Serdaigle et d'autres cadres de gestion de dialogue. Sur le plan architectural, Serdaigle est peut-être le plus semblable au collagène (Rich et Sidner, 1998; Rich et al., 2001). Bien que développés indépendamment, les deux frameworks utilisent un plan hiérarchique pour représenter l'interaction (une collection de ‘recettes” en collagène), et une pile pour suivre la structure imbriquée du discours à l'exécution. La structure de données de l'agenda des attentes et ses affordances sont uniques au cadre Serdaigle. Les parallèles peuvent aussi être tiré entre Serdaigle et VoiceXML, la norme de l'industrie pour le développement d'applications vocales. Par exemple, les agences de Serdaigle peuvent être considérées comme correspondant vaguement aux éléments < FORM> dans VoiceXML, les agents d'information aux éléments < BLOCK> et les agents de demande aux éléments. Quelque des similitudes peuvent également être trouvées entre l'agenda des attentes et les champs d'application des grammaires à différents niveaux dans VoiceXML (application, formulaire et champ). La représentation en plan hiérarchique complète de la logique de contrôle spécifique au domaine, couplée au contrôle plus fin du traitement d'entrée offert par l'attente agenda crée cependant un degré significativement plus élevé de polyvalence et d'évolutivité dans la boîte de dialogue Serdaigle cadre de gestion. En outre, la mise en œuvre et le contrôle découplés des compétences conversationnelles génériques telles que la gestion des erreurs réduisent encore les efforts de développement et de maintenance du système. À ce jour, plus d'une douzaine de systèmes de dialogue parlé ont été développés en utilisant le cadre de gestion de dialogue Serdaigle. Ces systèmes fonctionnent dans une variété de domaines, y compris l'accès à l'information, l'orientation grâce à des tâches procédurales, commande et contrôle, et la livraison des messages. Trois de ces systèmes-RoomLine, Let's Go! Public, et ConQuest, ont été déployés avec succès dans l'utilisation quotidienne. Comme nous l'avons vu dans la section précédente, le cadre de gestion Serdaigle dialog s'est facilement adapté aux caractéristiques spécifiques et les exigences de chacun de ces domaines. En développant ces systèmes, nous avons appris que le haut degré de flexibilité offert par la spécification de tâche de dialogue basée sur un plan hiérarchique peut être très bénéfique pour le développement d'interactions complexes. Considérons par exemple le paradigme d'états finis moins flexible pour concevoir et spécifier un plan d'interaction. Dans dans ce cas, le plan d'interaction est spécifié de manière positive ou explicite, en spécifiant les transitions possibles dans l'interaction: par exemple, de l'État A, le système peut passer aux États B, C ou D. développer des interactions complexes et mixtes dans ce formalisme est en général une tâche laborieuse: le nombre de transitions possibles augmente rapidement avec le nombre total d'États. En revanche, dans Serdaigle, le le plan d'interaction est défini par default4 de manière négative ou implicite, en spécifiant des contraintes logiques ce besoin de toujours tenir. Le contrôle de flux est donc sous-spécifié, et de nombreux chemins différents à travers la tâche de dialogue peut être prise par le planificateur de dialogue, tant que les contraintes exprimées par le développeur sont satisfaits. Lors de l'exécution, un chemin spécifique est généré, en fonction des entrées de l'utilisateur et de leur interaction avec les compétences conversationnelles du système. La représentation basée sur le plan permet donc facilement coder l'interaction mixte et réduire l'effort de développement pour les systèmes complexes, y compris les cas où la tâche de dialogue est construite dynamiquement au moment de l'exécution (par exemple LARRI, L'Assistant de procédure Intelligent et Madeleine). Dans le même temps, nous avons également constaté que la puissance expressive accrue de cette représentation, si elle n'est pas correctement exploitée, peut entraîner des défis inattendus. Compte tenu de la flexibilité du Planificateur de dialogue, le débogage du système ou le traçage du raisonnement derrière certaines décisions de contrôle de dialogue et les résultats devient à la fois une tâche plus difficile. Pour atténuer ces problèmes, une direction intéressante à considérer pour l'avenir la recherche explore de plus près le spectre des possibilités entre les deux polarités que nous avons mentionnées ci-dessus: la représentation de tâche basée sur des contraintes et la représentation explicite de transition d'état.

calendrier scolaire

Le cadre RavenClaw / Olympus fournit une plate-forme robuste pour la recherche sur divers problèmes de gestion des dialogues et d'interface de langue parlée. Certains des projets de recherche actuels soutenus par le cadre RavenClaw / Olympus sont brièvement décrits ci-dessous:

La gestion des erreurs L'un des principaux objectifs du développement du cadre de gestion des dialogues RavenClaw était de fournir un banc d'essai solide pour explorer la gestion des erreurs et les problèmes de mise à la terre dans les interfaces de langue parlée. Actuellement, Dan BohusLa thèse de ce dernier se concentre sur ces aspects. Certaines des questions examinées sont les suivantes: comment un système «sait-il qu'il ne sait pas»? Comment développer des systèmes capables de surveiller et de mettre à jour avec précision leurs croyances? Quel ensemble de stratégies peut être utilisé pour remettre une conversation sur la bonne voie et quels sont les comportements typiques des utilisateurs en réponse à ces stratégies? Quelles techniques peuvent être utilisées pour apprendre le comportement optimal du système en ligne, à partir des segments d'erreur détectés, et comment faire en sorte que ces systèmes s'adaptent et améliorent leurs performances au fil du temps? Plus de détails sont disponibles ici et sur la page Web de Dan. Timing et tour de rôle Dans son projet de thèse, Antoine Raux explore actuellement les questions de timing et de tour de rôle. La plupart des interfaces de langage parlé supposent un comportement rigide (vous parlez - je parle). Cette hypothèse peut conduire à des problèmes de dépassement de tour, ralentir le dialogue et parfois conduire à des pannes de communication complètes. Antoine étend actuellement l'architecture RavenClaw / Olympus pour permettre des comportements de tour de rôle plus flexibles. Plus de détails sont disponibles ici . Dialogue multi-participants Dans le projet TeamTalk , Thomas Harris étudie certains des défis liés au dialogue multi-participants. Plus de détails sur ce projet sont disponibles ici . Construction de tâches de dialogue dynamique Nous avons exploré les problèmes de construction de tâches de dialogue dynamique dans le contexte de plusieurs systèmes de dialogue parlé: LARRI , IPA et Madeleine . Dans ces domaines, la structure des tâches de dialogue n'est pas fixée à l'avance, comme dans la plupart des systèmes d'accès à l'information. Au contraire, la tâche de dialogue est construite à la volée, sur la base d'informations sélectionnées à partir d'un backend. Par exemple le LARRILe système aide le personnel de maintenance des aéronefs tout au long de l'exécution des tâches de maintenance. La structure de la boîte de dialogue dépend de la structure de la tâche de maintenance et est construite de manière dynamique, sur la base d'une spécification XML renvoyée par la bibliothèque de tâches de maintenance. Extraction automatique des connaissances La construction d'une interface de langue parlée nécessite un certain nombre de ressources linguistiques, telles que dictionnaire, modèle de langue, grammaire, modèles de génération de langue. Le développement de ces ressources nécessite une quantité considérable de connaissances spécialisées et de temps. Pour certains domaines, ces connaissances existent sous une forme différente, non adaptée à une utilisation directe dans une interface de langue parlée. Par exemple, pour le LARRIsystème, de vastes quantités de documentation technique et de procédures de maintenance sont disponibles au format texte / pdf / papier. Pouvons-nous acquérir automatiquement (ou semi-automatiquement) les ressources linguistiques nécessaires à partir de ces documents? Peut-on créer automatiquement une interface de langue parlée à partir d'un manuel technique? Agents responsables Dans le contexte du système Vera , nous avons exploré les problèmes liés aux agents responsables. Vera peut non seulement recevoir des appels, mais également lancer des appels dans le but de localiser une personne et de transmettre des messages.