摘要

对话管理可以看作是解决两个特定问题的方案：（1）为交互提供连贯的整体结构，将对话扩展到单轮以上；（2）正确管理混合启动交互，允许用户根据自己的指导进行交互（而非必须明确共享）目标，同时允许系统引导交互成功完成。我们提出了一个基于以下要素的对话管理体系结构：关注交互的处理程序，其重点是紧密耦合的信息集；能反映相互确认的信息的产物；以及对与任务完成相关的主题进行排序的议程。

1.介绍

口语交流可以采取多种形式。甚至相当简单的交互也可能非常有用，例如在自动助理系统中。但是，对于许多其他应用程序，似乎更复杂的交互是必要的，这可能是因为不能总是期望用户仅凭一句话就准确地指出他们想要的内容（例如计划信息），或者因为手头的任务需要一定程度的复杂选择探索 （例如，旅行计划）。另外，由于错误或误解而引入了不可预测的复杂性。我们有兴趣在跨越多个回合的面向目标的任务中管理交互。
　　在有目的的任务中进行对话管理必须解决两个问题：
　　（1）跟踪整体交互，以确保在完成任务方面稳步前进。也就是说，系统必须对完成多少任务有一些了解，更重要的是对尚未完成的工作有一些了解，以便系统可以参与制定中间目标，并通常确保将交互引导到即将完成的任务。
　　（2）稳健地处理从名义上的进展到问题完整解决的偏差。偏差是多种多样的：用户可能会提出一些无法满足的要求（即提出一组相互不兼容的约束），用户可能会说错（或者更可能是系统可能会误解）请求，并可能导致意想不到的事情（并且可能没有注意到）偏离任务的情况。当系统要求选择单个解决方案时，用户也可能未指定请求。最终，用户对任务的构想可能会与系统（及其开发人员）的构想有所不同，从而要求系统更改预期执行任务的顺序。理想情况下，健壮的对话框管理架构可以在单个框架内适应所有这些情况。
　　我们一直在CMU Communicator的背景下探索对话管理问题。该Communicator能处理复杂的旅行任务，包括航空旅行，酒店和汽车预订。

2.对话建模

现有的对话管理方法很难适应当前的问题，因为它们要么在交互中强加了僵化的结构，要么因为它们无法管理超过一定程度的复杂性的数据结构。
　　（1）基于FSM的多轮对话
　　基于调用流的系统（更一般地，基于图的系统）通过显式枚举所有可能的对话状态以及状态之间允许的转换来处理对话管理的复杂性。这样做的目的是将问题划分为一组有限的状态，可以将这些状态与特定于主题的元素（例如语言和与其他系统组件的交互（例如数据库交互））相关联。状态之间的移动取决于特定事件的发生，这些事件是用户的语音输入，也可以是通过（例如）后端状态的更改。这些系统的本质是，图通常是树（其中各个节点对应于某些信息的说明或约束的设置）。除了最简单的任务，图系统还有很多限制。除非精心设计的图，否则用户在不经过两者的公共父级的情况下，将无法切换到在不同子树中编码的主题。通常，到达对话的唯一方法是通过对话的根节点。类似地，并非总是可能指导现有树，以便例如校正在较早节点中提供的信息。
　　（2）基于槽填充的多轮对话
　　基于框架的系统提供了另一种更灵活的方法。在这里，对话问题被视为槽填充：特定的系统动作与为动作指定所有相关信息的槽相关联。对话管理包括监视槽的完成情况，设置用户指定的元素以及使用空位作为触发向用户提问的元素。槽填充消除了指定特定位置（其中需要填充插槽）的需要，并且放宽了对系统的要求，该系统旨在正确地理解提供信息的自然顺序。在任何情况下，这对于许多任务都是不可能的，因为不同的用户可能具有不同的，不兼容的问题解决风格。虽然非常适合可以用单个槽填写的形式表达的任务，但槽填写可以与图形表示（通常是遍历的）结合使用，以支持一组（可能）相关的活动，每个活动都可以转换为槽填充格式。
　　图形系统和框架系统都具有以下特性：任务通常具有固定的目标，可以通过让用户在连续的回合中指定信息（填充槽）来实现。使用填写的表格，系统可以执行某些操作，例如信息检索。尽管此功能涵盖了大量有用的应用程序，但不一定扩展到更复杂的任务，例如目标是创建复杂数据对象（例如计划）的任务。
　　在我们自己的工作中，我们一直在构建一个系统，该系统允许用户构建旅行路线。这个领域带来了几个问题：没有这样的“表格”可以填写，因为我们事先不知道个人可能会旅行的确切类型（尽管行程的组成部分确实是固定的）。该系统得益于能够动态构建行程的能力；我们将这些解决方案的对象称为“产品”。用户还希望能够操纵和检查正在建设的行程。相比之下，框架系统过去为槽提供填充物，却无法为用户提供操纵槽的能力。例外是从解决方案集中选择项目。我们不会完全放弃槽的概念：行程实际上是槽的层次结构，在这种情况下，槽对应于紧密绑定的位置（例如，对应于特定航程约束的位置），并且可以被视为同一话题的一部分。

3.任务结构和脚本

　　直观上（从我们对人类旅行社和客户的实证研究中可以明显看出），旅行计划随着时间的推移而不断发展，每次都针对特定主题（例如给定的航程，特定城市的酒店等）。用户将任务视为一系列主题，在继续下一个主题之前，应对每个主题进行完整和封闭的讨论。当然可以重新讨论主题，但这样做与参与者的明确对话方式相对应。
　　因此，我们实现了一种利用该任务结构的对话管理策略。类似于我们在人类之间数据交换中观察到的内容，我们将其称为基于脚本的对话管理器。在这种情况下，脚本仅是指与任务相关的主题的显式排序。每个主题都表示为一个槽填充任务，其中允许使用常规的自由顺序输入来填写槽，并且由槽状态驱动的混合启动交互（即，要求用户有关任何空插槽的信息）。特定于主题的形式实际上由两部分组成：约束槽（通常对应于查询的元素）和解决方案槽（包含执行的查询的结果）。
　　控制策略实际上也更加复杂：根据插槽的（域派生）约束解决方案的能力对插槽进行预排序；此排序提供了默认顺序，系统在该默认顺序中选择元素询问用户。控制取决于插槽的状态（约束或解决方案）。状态可以是“空”，在这种情况下，系统应要求用户输入一个值，并用单个值填充，在这种情况下，状态应为“完成”，或用多个值填充。最后一种情况是使用户参与一个澄清子对话，该子对话的目的是通过选择解决方案集中的一个项目或通过重新施加约束来将多个值减小为单个值。图1显示了基于脚本的系统中Flight Leg主题的结构。

4.基于议程的架构

尽管基于脚本的方法能够有效地处理日常出行安排，但仍存在许多局限性：脚本与产品数据结构紧密相关。具体来说，我们使用了固定的产品结构作为填写表格。虽然无需填写完整的表单即可创建有效的行程，但它对用户可以构造的内容设置了限制。取而代之的是，我们需要一种可以在会话过程中动态构建的表单结构，并由用户和系统共同做出贡献。基于脚本的方法似乎也使导航产品变得困难。尽管我们实现了一个简单的撤消和更正机制，该机制允许用户重新访问先前的产品元素，但用户难以正确使用它。虽然某些困难可以归因于方向支持不足，但源头很可能是系统无法独立于脚本来处理产品结构。
　　我们试图通过引入两个新的数据结构来解决这些问题：替换固定脚本的议程和可以在会话过程中发展的动态产品。在基于议程的系统中，产品表示为一棵树，该树反映完成任务所需信息的自然层次结构和顺序。动态产品只是一种可以在会话过程中进行修改的产品，例如，可以根据用户的要求在行程中添加一个节点，而不是按照固定的形式工作。在操作上，这意味着在树结构上提供一组运算符，并使它们对用户和系统可用。 在我们的案例中，我们定义了一个子树库（例如，空中旅行支路或本地布置），以及一种将这些子树附加到产品结构的方法，这可以通过在现有树中设置特定值或通过部分用户对子树的显式请求来触发（“and then I’d like to fly to Chicago”）。
　　产品树中的每个节点都对应一个处理程序，该处理程序封装与单个信息项相关的计算。所有处理程序都具有相同的形式：它们指定一组与输入网络相对应的接收器，一个变换将会被应用以获得一个值以及有关系统可能对用户说出的关于处理程序管理的信息的规范。处理程序对应于基于脚本的系统的架构和复合架构（请参见图1）。
　　议程是主题的有序列表，由管理某些单个项目或某些信息集合的处理程序表示。议程指定了执行任务的总体“计划”。该系统的行动优先级由议程获取，议程是通过遍历产品结构生成处理程序的有序列表。议程顶部的处理程序具有最高优先级，并代表着重点主题。处理程序可以捕获用户的相关输入，并可以向用户生成提示。单个处理程序仅处理以特定信息（例如出发日期）为中心的迷你对话。议程是对堆栈的概括。它既指示当前的交互焦点（即最顶层的处理程序），又指示所有不打交道的业务，并捕获处理此类业务的顺序。（系统的高级目标是确保当前产品树中的所有值都具有有效的设置。）由于可以通过用户的讲话来激活议程中的所有项目，因此用户可以对焦点主题进行相应的控制。议程还包含排序到议程底部的通用处理程序。这些可用于消耗产品派生的处理程序未捕获的任何输入（例如，请求帮助）。
　　议程的顺序是从产品树的从左到右，深度优先的遍历生成的。当用户输入进来时，系统会按其在议程中的顺序调用每个处理程序，并且每个处理程序将尝试解释用户输入。当处理程序捕获一条信息时，该信息将标记为已使用。 这保证了单个信息项只能由一个处理程序使用。
　　输入通过后，如果用户的输入没有直接导致特定处理程序生成问题，则系统将通过输出处理，在此过程中，每个处理程序将有机会生成有关自身的提示（例如，用于处理离开的处理程序可以询问用户出发日期）。
　　框架可以根据处理程序的返回代码确定下一步，可以选择继续当前遍历，退出输入遍历并切换到输出遍历，退出当前遍历并等待用户的输入等。在遍历期间， 处理程序还可以通过其返回代码将自身声明为焦点。在这种情况下，它将被提升到议程的首位。为了保留特定主题的上下文，我们使用一种称为子树升级的方法。在这种方法中，处理程序首先被提升到其同级中的最左侧节点。然后，其父节点也以这种方式升级。图2给出了子树升级的示例。

　　系统还处理产品树节点之间的依赖关系。典型的依赖关系是父节点和子节点之间的关系。通常，父节点的值取决于其子节点。每个节点维护其从属节点的列表，并将其值的任何更改通知其从属。然后，从属节点可以声明自身无效，因此可以声明为对话的候选主题。
　　使用该系统生成的以下对话显示了许多功能：能够吸收用户方面的隐式主题更改（A1-A3），添加到现有行程（A8-A10）并处理显式功能话题转移（U11）。

最后

以上就是义气冰淇淋为你收集整理的AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS翻译摘要1.介绍2.对话建模3.任务结构和脚本4.基于议程的架构的全部内容，希望文章能够帮你解决AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS翻译摘要1.介绍2.对话建模3.任务结构和脚本4.基于议程的架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。