本文最初发布于 Microsoft Research 博客,由 InfoQ 中文站翻译并分享。
“说起来容易做起来难。”这句话反映了对话式人工智能的前景。问“我和 Megan 什么时候都有空”只需几秒钟。但手动查看日历花的时间要长很多。事实上,我们借助科技完成的每一件事,都让人感觉是走过了一条通往短期目标的漫长道路。在微软Semantic Machines公司,我们正在努力填补这一空白——构建对话式人工智能体验,你只要专注于说出你想要的东西,剩下的交由系统就行了。和这样的 AI 对话,应该像和朋友说话一样:自然地、符合语境地、协作地。
一个真正强大的对话式 AI 需要做的不仅仅是深刻理解语言,它还要具备情境性、灵活性和健壮性,人工智能还必须深刻理解动作——大多数目标都涉及多个步骤和多个信息源。表达目标、动作和对话状态是对话式 AI 系统的核心挑战之一。我们在《计算语言学协会会刊》(TACL)上新发表了一篇论文,题为“面向任务的对话即数据流合成”(Task-Oriented Dialogue as Dataflow Synthesis),描述了一种新的表示和建模框架,它将对话解释为数据流图,使跨多个领域的复杂任务的对话成为可能。我们还发布了一个包含超过40000个对话的数据集(标注了数据流图)和公共排行榜,可以帮助人工智能社区在多轮任务导向对话中解决具有挑战性和现实意义的问题。
从我们的新数据集中可以看出用户请求令人难以置信的多样性:
目标多样性。用户可能想要“与 Megan 预约会议”。他们也可能想”与 Megan 预约一个周二的会议”,甚或是“与 Megan 预约在劳动节后第一个她有空的早上开一个会”。
语言多样性。问题可能会是“明天天气怎么样?”同样的问题也可能会以“明天外面怎么样?”或“远足时我需要带一件夹克吗?”这样的形式出现。
语境多样性。“How about three?”这句话的意思完全取决于刚刚说了什么。句子“Megan 两点没空,你有其他建议吗?”是提议更改会议时间。句子“天气预报说中午多云”是对于天气有疑问。句子“Rivoli 有一张两人桌”是要求增加晚餐预订的座位。
传统的“填槽式(slotfilling)”对话系统忽略了这种多样性。它们只支持一组目标,除了当前目标中缺失参数的列表之外,它们没有上下文表示。而在另一个极端,最新的“端到端”神经对话系统原则上可以自由地学会任意上下文相关的响应,但仅仅是灵活地使用词汇是不够的,因为对话还需要灵活地执行动作。部署的系统还需要有可控性和真实性,在非结构化系统中,这非常具有挑战性。
我们提供了第三种方法,使用深度学习来生成和消费强大的“数据流”表示,它超越了填槽式方法,提供了灵活的动作和可控的语义。数据流旨在支持人类在日常生活中自然、灵活、开放的对话。我们的方法基于以下五个关键理念。
1. 用户请求即程序
现有的对话方式非常适合解释固定的、预先定义好的任务请求,比如“开灯”或“”设置一个名为 pasta 的定时器,时长 5 分钟”。在这些方法中,对话系统设计者定义了一组固定的意图,每个意图都有一组固定的参数。系统用用户所表达的意图和该意图的参数来标记每个用户请求:
但是,对于更复杂的请求,比如“我和 Megan 一起喝咖啡的时候气温会是多少?”回答这个问题需要对话代理做一系列不同的事情:找出 Megan 是谁,在日历应用程序中使用 Megan 查找事件,找出开始时间,然后使用时间查询天气服务。我们不需要系统构建者创建专门的weather_during_event_with_person
意图,而是将自然语言请求转换为一个程序,将所有这些调用联系在一起。我们将该程序表示为一个数据流图,它明确定义了对话代理计划中的步骤(节点)之间的数据依赖关系(边):
一旦神经网络预测到这个程序,对话代理就会执行它,根据结果对用户进行回复,并将结果存储在数据流图中。
2. 面向任务的对话是交互式编程
使用数据流表示用户意图的一个好处是,它可以非常自然地概括为在多次来回通信中展开的交互。如果用户开始的时候问“我下一次什么时候和 Megan 见面?”,则对话代理首先预测一个小的图片段:
如果用户在接下来的一轮对话中继续问“那时的天气怎么样?”,回答这个新问题所需的大部分工作已经完成了。对话代理返回到上一轮的程序片段,将其输出输入到新的 API 调用中,然后描述结果:
这个过程的结果与我们之前为一个复杂问题生成的程序完全相同!这种重用是我们这个框架的核心特性——复杂动作是通过组合更简单的动作来构建的,而不是定义一堆顶级行为。这种组合可以一次完成,也可以在多次循环中通过依次扩展数据流图逐步完成。
3. 语义依赖语境
扩展后的图作为对话状态。它记录到目前为止代理为理解、服务和响应用户所执行的所有计算。随后的表达都是在这个上下文中被解释(通过深度学习),它们可以引用这些早先的计算和结果。正如我们在论文中所展示的,显式引用和重用早先计算的机制提高了对话代理机器学习的数据效率和准确性。它们还使工程师更容易推理和控制对话代理的行为。
在前面的示例中,用户使用单词 then 引用数据流图中较早的节点。其他指称表达,如 that、her 或 the second meeting you mentioned,也可以表示重用对话中之前提到的值或实体的请求。
这种引用也可以隐式地发生。想象一下,问你的设备“天气怎么样?”,通常你指的是近期的天气。但如果你在提及未来的一项活动后问同样的问题,你很可能是在询问活动期间活动地点的天气。最终,这两种情况需要两种不同的计算方法。如下所示,左边的计算将用于解释近期的情况,右边的计算用于解释特定于事件的情况:
弄清楚如何区分这些用法(更不用说对这个问题的其他解释)是一个具有挑战性的机器学习问题。但凭直觉,在这两种情况下,“天气怎么样?”的意思是相同的——用户想知道与会话上下文最相关的时间和地点的天气。
在我们的方法中,这种推理是显式的:当在上下文中解释用户输入时,我们的对话代理就显式地预测了引用现有计算片段的程序,包括从对话开始就隐式可用的片段,比如 here 和 now。对于上面的两个例子,会是下面这个样子:
换句话说,在这两段对话中,对话代理用同样的方式解释“天气怎么样?”这个问题。它预测出了相同的数据流图片段,调用refer(Time)
和refer(Place)
,但是,对这个片段的解释会根据前面的上下文发生变化。
“公司休假期间怎么样?”这个问题与上下文的关系更紧密。这里,用户不只是引用一个现有的实体,而是要求对话代理为之前的问题计算出一个新的答案,其中一些细节已经变了。我们称这种转变为修正(revision)。与引用一样,修正提供了一种强大的机制,用于执行复杂的图转换,以响应简单的请求。下面这个示意图说明了代理预测的修正,当用户问完“我和 Megan 喝咖啡时天气怎么样?”之后又问“公司休假期间怎么样?”
在这里,第一次事件搜索的条件(包含 Megan 的名为 coffee 的事件)被替换为新的条件(指定名为 company retreat 的事件)。
查看论文了解更多细节:https://www.microsoft.com/en-us/research/publication/task-oriented-dialogue-as-dataflow-synthesis/。
4. 事情会出错
在任何复杂的对话中,事情的发生都有许多意想不到的方式。与 Megan 预约会议的请求可能会失败,因为用户的联系人列表中没有叫 Megan 的人;因为有许多人都叫 Megan;因为没有空开会;甚或因为网络已断开,对话代理无法与服务器取得联系。每种情况都需要不同的响应,而现有的对话系统通常使用复杂的硬编码逻辑来从错误中恢复。
我们通过从数据流图的某个节点抛出异常来处理所有这些故障。我们的对话代理会响应这个失败的“结果”,为用户生成一个适当的警告或问题。用户可以随意响应,也许是通过纠正问题;例如,在这个上下文中,“我指的是 Megan Bowen”将被解释为改进原始请求的修订。这种方法允许系统和用户在出现错误时根据上下文灵活地、模块化地、协作地处理错误。
5. 语言生成依赖于对话语境
要成为一名有用的团队合作伙伴,对话 AI 系统需要能够生成语言,而不仅仅是解释它。大多数现有的对话方法要么是硬编码生成规则(导致输出听起来像机器人,不会因上下文不同而改变),要么是非结构化的神经语言模型(有时不说实话!)在我们的方法中,语言生成被建模为一个神经引导的合成程序转换过程,在这个过程中,代理会轮流扩展数据流图。代理可以讨论图表中出现的任何内容,而不仅仅是它计算得出的最后结果。它甚至可以向图中添加新的计算和结果,用户可以在以后的对话中随意引用:
代码、数据和新一轮竞争
我们相信,这种方法是迈向新一代自动对话代理的第一步,它可以像人与人之间那样与人交互。然而,解决这个问题需要整个社会的共同努力。为了促进基于数据流的对话代理的开放研究,我们发布了迄今为止最大、最复杂的面向任务的对话数据集SMCalFlow。该数据集具有 41517 个标注了数据流程序的对话。这个数据集来自于人类之间探讨日历、天气、人和地点的开放式对话。与现有的对话数据集相比,我们收集对话不是基于预先指定的脚本,参与者不受限制,他们什么都可以问,他们可以按自己的方式完成他们的任务。因此,SMCalFlow 与现有的对话数据集有本质上的不同,它有关于代理能力、多轮错误恢复和复杂目标的具体论述。
数据集、代码和排行榜都可以在我们的GitHub页面上找到。我们期待看到自然语言处理社区如何使用这个新资源。
查看英文原文:
评论