17

对话即数据流:智能对话的新方法

 3 years ago
source link: https://www.msra.cn/zh-cn/news/features/dialogue-as-dataflow
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

编者按:一个真正强大的对话式人工智能不仅仅要能够深刻理解语言,还必须能执行各种“行动”为用户服务。微软 Semantic Machines 团队的研究员们正试图利用深度学习来产生并使用具有强大表达能力的“数据流”,以实现人们日常生活中自然、灵活、开放式的对话。用户只需专注于说出自己想要什么,而系统会思考如何将该任务完成。

“说起来容易做起来难”,这句话真实反映了智能对话的精髓。口头询问“Megan 和我什么时候都有空?”只需要几秒钟,但如果是从日历手动查找所需的时间却长得多。事实上,追求最短路径一直是技术发展的目标。微软 Semantic Machines 团队的研究员们正通过全新的智能对话体验缩短“说”和“做”的距离。用户只需专注于说出自己想要什么,而系统将思考如何完成它。用户和人工智能的对话将像跟朋友说话一样,是自然、联系语境且充满互动的。

一个真正强大的对话式人工智能需要做的不仅仅是深刻理解语言,因为大多数目标都涉及多个步骤和多个信息源,所以 AI 还必须深刻理解各种“行动”才能联系语境进行灵活并且具有鲁棒性的对话。搭建智能对话系统的一个核心挑战是设计一种方法来统一地表示对话中的目标、行动和状态。微软 Semantic Machines 的研究团队在 Transactions of the Association for Computational Linguistics (TACL) 上发表的新论文 Task-Oriented Dialogue as Dataflow Synthesis ( 点击链接 ,了解更多细节 )描述了一种新的对话表示和建模框架,该框架将对话解释为数据流图,从而实现了跨越多个领域的复杂任务的对话。研究员们还发布了一个超过4万段对话的数据集(包括对应的数据流标注)和一个排行榜,以帮助人工智能社区解决多轮对话中的技术挑战。

正如新数据集所显示的那样,用户需求具有惊人的多样性:

  • 多样化的目标:一个用户可能想“预订一个与 Megan 的会议”。他们也可能想“在周二预订一个与 Megan 的会议”,甚至是“在假期之后的第一天早上预订与 Megan 的会议”。
  • 多样化的语言:用户可能会说“明天的天气是什么”来询问天气。相同的请求也可能表述成”明天户外的天气会怎样“或者”我去徒步需要穿外套吗”。
  • 多样化的语境:这取决于智能助理之前所说的内容,“三点怎么样”可能表示完全不同的语义。例如,如果在前一轮智能助理说 “Megan 在两点时是忙碌状态,您要预约其他时间吗”,那么它表示修改会议预约的请求;如果智能助理说 “今天中午的天气是阴天”,那么它表示修改天气预报时间的请求。

传统的“意图识别和槽填充”系统忽略了这种多样性。它们仅支持一组目标,并且不支持丰富的上下文表示(除了表示当前缺少的槽位以外)。另一方面,最新的“端到端”神经网络理论上可以自由地依照上下文生成任何回复。然而,灵活地生成词语往往是不够的,因为完成任务型对话还需要灵活地执行操作。此外,产品级对话系统还必须满足可控性和真实性的要求,这对于端到端的非结构性系统来说是很大的挑战。

微软 Semantic Machines 的研究团队提出了有别于传统方案的第三种方法:利用深度学习来产生和使用具有强大表达能力的“数据流”来解决以上问题。这种“数据流”表征超越了“意图识别和槽填充”,既支持灵活的操作,又提供了可控的语义。该数据流旨在实现人们日常生活中自然、灵活、开放式的对话。

该方法基于五个关键思想:

1. 把用户的请求表示为一段程序

传统的对话系统能够很好地解释固定的、预先定义好的请求,例如“开灯”或者“设置一个5分钟的叫‘意大利面’的闹铃”。在这类方法中,设计人员预先定义了一组固定的意图,每个意图都有一组固定的参数。系统把每个用户请求标记为对应意图和参数的组合:

nQrQnmB.jpg!mobile

但如何处理更复杂的请求呢?例如“约 Megan 喝咖啡的时候气温如何?”,要回答这个问题,智能助理需要做一系列事情:首先要找出 Megan 是谁,并在日历应用程序中查找包含 Megan 的事件,然后确定其开始时间,并查询该时间的天气服务。为解决这个问题,科研人员不希望添加一个叫做 “和某人在一起期间的天气”的意图,而是希望把自然语言转换为联系所有这些步骤的程序。该程序被表示为数据流图(dataflow graph),它明确定义了智能助理要执行的程序中的步骤(节点)和它们之间的数据依赖关系(边):

rqyyya.png!mobile

一旦该程序被神经网络预测出来,智能助理便可以执行该程序,并根据结果对用户进行回复,再将结果存储在数据流图中。

2. 任务型对话是交互式编程

使用数据流的好处之一是,它可以自然地表示多轮对话中用户和机器人反复的交互过程。如果用户问“约 Megan 喝咖啡是什么时候”,系统会生成如下的数据流片段:

nYZzIbv.png!mobile

如果用户在下一轮提出“那里的天气如何”,那么回答新问题所需的大部分工作实际上已经在第一轮完成,系统则可以回溯上一轮的程序片段,将其输出反馈到一个新的 API 调用中,然后描述其结果:

rmIJ3ij.png!mobile

该过程得到的结果与先前为复合式问题(“约 Megan 喝咖啡的时候气温如何”)生成的程序完全相同。这种重用是数据流框架的核心功能——通过对一系列简单的操作进行组合,而不是定义大量的顶层操作,来实现复杂的目标。这种组合可以在第一轮对话中发生,也可以逐轮进行,形成逐步扩展的数据流。

3. 语义依赖于上下文

我们可以把逐步扩展的数据流看作整段对话的“对话状态”。它记录了智能助理到目前为止为了理解语义、提供服务、回复用户而进行过的所有计算。此后的每段语义都将在数据流的基础上(通过深度学习)进行解析,它们可以参考和使用现存的所有计算及其结果。通过设计对数据流中的节点进行引用和复用的机制,可以显著提高对话系统的数据利用效率和机器学习的准确性。这也让工程师们可以更容易理解和控制智能助理的行为。

在前面的示例中,用户使用了单词“那里”来指代数据流图中的现存节点。诸如此类的语言现象还包括“那个”、“她”、“你提到的第二个会议“等。这些都表示用户希望引用对话中提到过的某个值或某个实体。

这类引用也可能隐式地发生。想象一下,当你询问智能设备“天气会怎样”时,通常你想知道当地近期的天气。但是,如果你在提到某个未来的事件后问了同样的问题,则可能是在询问该事件期间以及对应地点的天气。解决这两种情况需要两个不同的计算图。如下图所示,左边的计算用于获得当地近期的天气,右侧的计算则用于获得特定事件的天气:

emaQfe.jpg!mobile

通过上下文区分这两种情况是一个颇有挑战性的机器学习问题(更不用说还可能有其他情况了)。但从直觉上讲,“天气会怎样”这句话在两种情况下的含义是相同的,即用户想知道与对话环境最相关的时间和地点的天气。

在基于数据流的对话系统中,上述推理被显示地表达了出来:在解析用户请求时,智能助理会生成显示引用现有计算片段的程序。这里,这些片段既包括前一轮的计算,也包括 here 和 now 这种在对话开始前就默认存在的实体。对于上面的两个示例,生成的数据流看起来像这样:

rYbyQf2.jpg!mobile

换句话说,在两段对话里,系统对“天气会怎样”的解析是相同的。它通过调用 refer (Time) 和 refer (Place) 生成了相同的数据流片段,但在该程序片段被执行时,它的实际解释则会根据上下文而改变。

下面是一个与上下文互动更紧密的例子。假设用户问:“公司聚会的时候呢”。这里,用户希望智能助理在修改一些细节(把事件修改为“公司聚会”)后提供先前问题(查询天气预报)的新答案。这种需求被称为修改(revision)。像引用一样,基于数据流的对话系统引入了一种名为“修改”(revision)的机制来应对上述需求,使简单的用户语句可以对应复杂的数据流变换。以下是系统在处理“约 Megan 喝咖啡的时候气温如何”以及 “公司聚会的时候呢”之后,大致的数据流图:

Qf6Zreb.png!mobile

在这里,第一轮搜索所使用的约束(参与者包含“Megan”,标题匹配“咖啡”)被新的约束(标题匹配“公司聚会”)替换。(有关“修改”机制的更多详细信息,可 点击链接 ,从论文中了解更多)

4. 事情可能会出错

任何复杂的对话都包含多种可能的意外事件。比如“预订与 Megan 开会”的请求可能会失败,因为用户的联系人列表中没有一个叫 Megan 的人,或者有多个人叫 Megan,又或者因为没有可预约的时间,甚至还有可能因为互联网断开而导致智能助理无法与服务器取得联系。这些情况中的每一种都需要不同的响应。传统的对话系统通常使用复杂的硬编码逻辑来从这些错误中恢复。

基于数据流的对话系统通过从数据流图的某个节点抛出“异常”来处理所有这些意外。智能助理处理它们的方式是:通过描述“异常”的内容为用户生成适当的警告语句或问询语句。而用户在看到这些描述后,可以自由地进行回复,比如澄清误解,或者修改之前的请求。举例来说,如果有多个叫 Megan 的人,那么系统会把这个搜索结果用告知用户,而用户或许会通过 “我指的是 Megan Bowen”来澄清。系统会将这句话解释为基于上下文的“修改”(revision)请求,并生成新的程序。这种机制使系统和用户可以在出现错误时灵活地、联系语境地、协作式地对错误进行处理。

5. 回复的生成也依赖上下文

作为有效的伙伴,对话式 AI 系统不仅要学会解释语言,而且要能够生成语言。传统的对话系统要么采用手写的生成规则(导致 AI 的回复无法根据上下文而变化),要么采用非结构化的神经网络语言模型(导致 AI 的回复无法保证真实性)。在基于数据流的方法中,语言生成是一种被神经网络所引导的数据流操作。在语言生成中,系统会主动地对数据流进行解析和扩展。它可以描述数据流中出现过的任何内容,而不只是最后的计算结果。它甚至还可以将语言生成过程中新产生的计算和结果添加到数据流中,而用户则可以在随后的对话中引用它们:

NRvA7br.jpg!mobile

研究资源:代码,数据集和公共排行榜

本文所描述的方法将成为迈向新一代智能对话技术的第一步。微软 Semantic Machines 团队的目标是赋予 AI 和人类同等的交流能力,但这个问题的最终解决离不开整个社区的参与和努力。为了促进对基于数据流的对话系统的研究,微软 Semantic Machines 的研究团队还发布了迄今为止最大、最复杂的面向任务的对话数据集:SMCalFlow(https://www.microsoft.com/en-us/research/project/smcalflow-dataset-0/)。该数据集包含了41,517段对话以及对应的数据流程序标注。该数据集收集自日历、天气、通信录、地点等交叉领域,均为人类间的真实对话。对话集合不受限于任何预先指定的剧本,即参与者在对话目标以及完成任务的方式上完全不受限制。因此,SMCalFlow 与现存的对话数据集有着本质区别。例如,某些对话可能包含非常复杂的目标,或包含用户和智能助理共同从某个错误中恢复的过程,甚至还包含二者关于智能助理能力范围的讨论。

欢迎大家在 GitHub 的页面(https://github.com/microsoft/task_oriented_dialogue_as_dataflow_synthesis)上点击数据集、代码和公共排行榜的连接。对本论文更加详细的解读,请访问知乎专栏(https://zhuanlan.zhihu.com/p/245081650)。非常期待未来自然语言处理社区利用这些资源做出新的发现和创造。

微软 Semantic Machines 团队将继续推动对话式 AI 的发展。欢迎加入我们!

(https://www.microsoft.com/en-us/research/project/semantic-machines/)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK