一个基于事务的口语对话管理系统体系结构

AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS

一个基于事务的口语对话管理系统体系结构

ABSTRACT

对话管理可以被用来解决两类具体问题：
1. 提供一个连贯的整体结构来使一轮对话得到扩展和提升。
2. 正确的管理交替主动型的对话行为。（即在对话过程中，既允许用户根据自己的目标主导，也允许系统知道互动）

我们提出一个基于以下要素的对话管理架构：

• handlers 在紧密耦合的信息集上管理对话行为
• product 反应了双方都同意的信息
• agenda 确定与主题相关的任务并去完成

1.INTRODUCTION

口语交互可以有很多形式。虽然简单的交互非常有用，但是对于其他应用，复杂一些的交互是必要的。因为用户不能一直被期望用简单的对话来清晰的表达他们所需要的东西；或者因为当前的任务需要对复杂的替代方案进行对比。另外也有可能因为它，造成一些错误和误解，从而带来不可预期的复杂性。综上，我们致力于在一个面向目标任务的环境中对交互行为进行管理，并把它扩展至多个回合。

对话管理在目的性的任务中，必须解决两个问题。
1. 需要全程跟踪，以保证任务的稳定进展。这个系统必须知道哪些任务已经完成，以及未完成的任务怎样去完成。这样就可以设计中间任务，并为完成当前的任务而互动。
2. 处理偏差的能力。偏差是多种多样的，用户可能会要求一些不那么令我们满意的东西。比如用户对请求的模糊或错误，使系统误解，从而偏离该任务；也有可能，当系统要求用户选择一个解决方案时，用户给出的答案含混不清。++（无论哪方主动时，都可能会产生偏差？）++ 还有一种情况是用户要求系统改变预期执行任务的顺序。但是无论对于哪种情况，理想的对话管理结构都可以解决这些问题。

我们一直在CMU Communicator的环境中探索对话管理问题。这个环境可以处理复杂的旅行任务，包括空中旅行，酒店等。

CMU Communicator 是卡耐基梅隆大学Sphinx Group组织下的一个项目，其旨在探索对于复杂问题的解决任务的高级对话管理体系结构。

2.MODELING DIALOG

现有的对话管理方法很难解决当前的问题，因为他们要么对交互过程强加一个过于严格的结构，要么无法管理一个较复杂的数据结构。基于呼叫流（Call-flow baesd，更一般的说法，基于图）的系统主要特点是：通过明确列举出所有可能的对话状态以及状态之间可以相互转换来应对对话管理的复杂性。这样有助于将问题划分为一组有限的状态，可以将这些状态与特定主题的元素相关联。另外，状态之间的转换可以根据特定事件的发生来预测，也可以由用户口头输入或者后端来改变状态。这个系统的本质是由图构成的树（其中各个节点对应于信息的规范或是约束的设置）。但是这种基于图的系统有很多限制。除非图精心设计，否则用户不能在这个系统所编码的子树下自由切换对话主题，而必须回到根节点再传至对应的子树节点。

Frame-based systems provide an alternate, more flexible approach.

基于框架的系统提供了一个更为灵活的方法。这里的问题像是表格填充：一个特定的系统动作和一个表格相联系，这个表单包含此动作的所有相关信息。在此系统中，DM监督表格的完成，设置元素。如果表格为空，就将空插槽所对应的问题发送给用户。此外，槽位的填充也不需要特定的顺序。尽管理想状态下任务应该由单个的表格进行填充，但对于图形表示来说，为了能使图中相关的节点相连，需要把每个活动都转换为表格形式来进行填充。

使用表格（插槽填充）的系统可以执行很多操作，比如信息检索之类。尽管这个系统包含了很多可行的应用，但它不一定适用于更复杂的任务。比如这个任务是创建一个复杂的数据对象—-plan.

所以，在我们的工作中，希望建立一个允许用户自己构建行程的系统。在这个域中，带来了一些问题：没有“表格”可以填写，因为无法知道用户将采取哪种类型。这个系统的好处在于可以动态的构建行程，我们将解决方案称为 “products”.

3. TASK STRUCTURE AND SCRIPTS

一般来说，旅行计划是随着时间推移的连续的发展的事件，每个阶段关注于一个具体的主题（比如预定航段的机票，或是一个特性城市的酒店）。用户把任务看成一系列的主题，在进行下一个任务之前，每一个主题都应该被全面而单一的讨论。这些主题也可以被重新讨论，但只有用户明确要求时才会这样做。（暗示对话的主导可以相互转换？）

据上述讨论，我们实现了一个以该任务结构为基础的对话管理策略。这个模型通过观察人与人之间的对话类比而得，我们称之为基于脚本的对话管理模型。在本文中，脚本只是指对任务相关主题的一个明确的排序。每个主题都是一个表格填充任务。每个具体的表格又两部分组成：
1. constraint slots (typically corresponding to elements of a query)
2. a solution slot (containing the result of an executed query).

约束槽（通常对应于查询的元素）
解决方案槽（包含执行查询的对应结果）

当然，这样控制策略也会变得更为复杂。槽位将被预先排序，这个顺序基于他们（域派生的）约束解决方案的能力而定。这个顺序提供了一个默认的队列，系统将按这个队列的顺序询问关于用户的元素。控制是基于槽位的状态（无论是约束槽还是解决方案槽）。这个状态如果为空，系统应该向用户询问一个值（来决定是约束槽还是解决方案槽？），若不为空，则向用户询问多个值来填充之。最后一种情况是让用户来参与过滤子对话，目标通过通过检索解决方案中的项，或者是重申一个约束来让多个值减少为一个值。图显示了基于脚本的系统中的Flight Leg主题的结构。

4. AN AGENDA-BASED ARCHITECTURE

虽然基于脚本的方法能够有效应付大多数旅行计划，但它仍然存在一些限制。“script”的数据结构和“product”非常类似，即我们用了一个既定的“product”结构来作为我们的表格去填充。虽然不需要填写整个表格来创建有效的行程，但它还是对用户所能构建的会话产生了一些限制。所以我们想要一个在会话过程中基于用户或者系统的操作来动态创建表单的结构。此外，基于脚本的方法在给用户指引方面带来了诸多困难。虽然我们实行了一个简单的撤销和更正机制，但用户往往不能正确使用它。这个问题可能源于缺乏定向的支持，但更可能是系统无法独立的应对“script”的“product structure”.

为了解决上面的问题，我们计划引入两种新的数据结构：
- agenda 来代替复杂的 script
- dynamic product 可以在会话过程中自动发展

在基于事务（agenda）的系统中，product以树形结构来表示。这个结构反应了完成任务所需的层级和顺序。动态的product可以随着会话的进行而修改，比如通过用户请求来添加分支，而不是遵从于一个固定的形式。这就意味着，需要提供一组对系统和用户可用的操作，来改变树结构的形态。在我们的例子中，定义了一个子树库（例如航空的航段，或者当地的一些安排），以及这些子树附加到“product”中的方法。通过在现有的树中设置特定值或通过用户的明确请求（如：我想飞往芝加哥）来触发。

在整个product tree 中每个节点都（对应于）相当于一个handler，封装了与单个信息节点相关的计算。而每个handler有着固定的形式：他们指定了一组接收来输入；一个被用于获取值的变换，以及系统如何通过handler向用户说明相关信息的一个规范。

handler是对应于基于脚本的系统的模式，或者是其复合模式。（参见图一）

agenda是一个由handler组成的有序的主题列表，，这些handler管理着单一的项或是一些搜集的信息。agenda为执行一个任务而制定了一个全局计划，一个有序的handler列表通过遍历product结构而生成。agenda最上面的handler有着优先权，代表着焦点话题（focused topic）。handler可以捕获用户的输入然后生成提示性语言。每个handler只负责一条特定的信息（比如date handler 只负责日期）。

agenda从结构上来说，是栈的一般化，它表明目前互动的关注点（top handler）以及其他未处理的事务（all undealt-with business），并将那些应该被处理的事务排序。（系统的高级目标是确保当前product tree的所有值都被有效设定）。通过用户的话语，agenda中的每个item(handler)都有可能被激活，而用户对当前的焦点话题（top handler）有着相应的控制权。agenda的底部包含着通用的handler来应对那些没有被上层handler捕获的输入。

agenda的顺序是从product tree 从 product tree 从左到右、深度优先遍历生成.用户输入时，系统按照 agenda 中的顺序调用每个 handler，每个 handler 尝试解释并回应用户输入。handler 捕获到信息就把信息标记为 consumed，这保证了一个 information item 只能被一个 handler 消费。

input pass 完成后，如果用户输入不会直接导致特定的 handler 生成问题，那么系统将会进入 output pass，每个 handler 都有机会产生自己的提示prompt（例如，departure date handler 可以要求用户出发日期）。

这样的框架可以从handler返回码中决定下一步，它可以继续当前的pass,也可以还是退出 input pass 切换到 output pass，还是退出 current pass 并等待来自用户输入等。在pass中，handler可以通过返回码来将自己声明为focus topic。在这种情况下，这个handler将被提升到agenda的顶部。为了保持当前话题的上下文关系，我们将使用子树提升法（sub-tree promotion）。这种方法，一个handler被提升至兄弟节点中最左端的节点，其父节点同样如此提升。如图二。

在例子中，想要i节点提升，需要提升g节点及其子树。然后g提升至e的最左端。再讲e的子树提升至e的兄弟节点的最左端。

给一个例子，能够回应用户的显式/隐式话题转移（A1-A3, U11），也能够动态添加子树到现有的 agenda（A8-A10）。