人机对话技术研究进展与思考

嘉宾：袁彩霞 博士 北京邮电大学 副教授

整理：Hoh Xil

来源：阿里小蜜 & DataFun AI Talk

出品：DataFun

注：欢迎转载，转载请在留言区内留言。

导读：本次分享的主题为人机对话技术研究进展与思考。主要梳理了咱们团队近两年的工做，渴望能够经过这样的介绍，能给你们一个关于人机对话 ( 包括它的科学问题和应用技术 ) 方面的启示，帮助咱们进行更深刻的研究和讨论。主要包括：

1. Spoken dialogue system：a bird view ( 首先咱们来看什么是人机对话，尤为是 Spoken dialogue。其实说 Spoken 的时候，有两层含义：第一个 spoken 就是 speech，第二个咱们处理的语言自己具备 spoken 的特性。可是，稍后会讲的 spoken 是指咱们已经进行语音识别以后，转换为文本的一个特殊的天然语言，后面讨论的口语对话不过多地讨论它的口语特性，主要是讲人和机器之间的天然语言对话。)

2. X-driven dialogue system：紧接着来说解咱们近些年的研究主线 X-driven dialogue syatem，X 指构建一个对话系统时，所采用的数据是什么，从最先的 dialogue -> FAQ -> KB -> KG -> document 以及咱们一直在尝试的图文多模态数据。

3. Concluding remarks ( 结束语 )

01

Spoken dialogue system：a bird view

学术界关于对话系统有着不一样的划分，这种划分目前看来不是很是准确，也不是特别标准的划分了。可是，接下来的内容，主要是围绕着这两个主线：

限定领域，专门指任务型对话 ( 围绕某一特定用户对话目标而展开的 ）。对于任务型对话，对话系统的优化目标就是如何以一个特别高的回报、特别少的对话轮次、特别高的成功率来达成用户的对话目标。因此即使是限定领域，咱们这里讨论的也是特别限定的、专门有明确的用户对话目标的一种对话。

开放领域，not purely task-oriented， 已经再也不是纯粹的对话目标驱动的对话，包括：闲聊、推荐、信息服务等等，后面逐步展开介绍。

咱们在研究一个问题或者作论文答辩和开题报告时，常常讨论研究对象的意义在哪里。图中，前面讲的是应用意义，后面是理论意义。咱们实验室在北京邮电大学叫智能科学与技术实验室，其实她的前身叫人工智能实验室。因此从名字来看，咱们作了很是多的 AI 基础理论的研究，咱们在研究这些理论的时候，也会讲 AI 的终极目的是研制一种可以从事人类思惟活动的计算机系统。人类思惟活动创建在获取到的信号的基础上。人类获取信号的方式大致有五类，包括视觉、听觉、触觉、味觉、嗅觉等，其中视觉和听觉是两个比较高级的传感器通道，尤为是视觉通道，占据了人类得到信息的80%以上。因此咱们从这两个角度，设立了两个研究对象：第一个是语言，第二个是图像。而咱们在研究语言的时候，发现语言有一个重要的属性，叫交互性，交互性最典型的一个体现就是对话；同时，语言不是一个独立的模态，语言的处理离不开跟它相关的另外一个通道，就是视觉通道。因此咱们早期更可能是为了把交互和多模态这样的属性归入到语言建模的范围，以其提高其它天然语言处理系统的性能，这就是咱们研究的一个动机。

1. Block diagram

上图为 CMU 等在1997年提出来的人机对话框架，基于这个框架人们开发出了很是多优秀的应用系统，好比应用天气领域的 "Jupiter"。这个框架从提出到商业化应用，一直到今天，咱们都还沿着这样的一个系统架构在进行开发，尤为是任务驱动的对话。

这就是具体的对话系统的技术架构。

1. Specific domain

这个架构发展到如今，在功能模块上，已经有了一个很清晰的划分：

首先进行语音识别，而后天然语言理解，紧接着作对话管理，将对话管理的输出交给天然语言生成模块，最后造成天然语言应答返回给用户。这就是一个最典型的 specific domain 的架构。早期 task 限定的 dialogue，基本上都是按照这个架构来作的。这个架构虽然是一个 Pipeline，可是从研究的角度来说，每个模块和其它模块之间都会存在依赖关系。所以，咱们试图从研究的角度把不一样的功能模块进行统一建模。在这个建模过程当中，又会产生新的学术性问题，咱们旨在在这样的问题上能够产生驱动性的技术。

1. Open domain

Open domain，也就是“闲聊”，实现上主要分为途径：

第一个是基于匹配/规则的闲聊系统；第二个是基于检索的闲聊系统；第三个是基于编解码结构的端到端对话系统。固然，实际情境中，这几个途径每每结合在一块儿使用。

02

X-Driven dialogue system

目前不管是任务型对话仍是闲聊式对话，都采用数据驱动的方法，所以依据在构建人机对话系统时所用到的数据不一样，建模技术和系统特性也就体现出巨大的不一样。咱们把使用的数据记为 X，因而就有了不一样的 X 驱动的对话。

1. Our roadmap

若是想让机器学会像人同样对话，咱们能够提供的最天然的数据就是 dialogue。咱们从2003年开始作对话驱动的对话；2012年开始作 FAQ 驱动的对话；2015年开始作知识库 ( KB ) 驱动的对话；2016年开始作知识图谱 ( KG ) 驱动的对话，相比于 KB，KG 中的知识点产生了关联，有了这种关联人们就能够在大规模的图谱上作知识推理；2017年开始作文档驱动的对话。这就是咱们研究的大体脉络。

1. Dialogue-driven dialogue

早期在作 Dialogue driven 的时候，多依赖人工采集数据，可是，从2013年以来，逐步开放了丰富的涵盖多领域多场景的公开数据集。好比最近的 MultiWOZ，从 task specific 角度讲，数据质量足够好、数据规模足够大，同时涵盖的对话情景也很是丰富。可是，目前公开的中文数据集还不是不少。

这个是和任务型对话无关的数据集，也就是采集的人与人对话的数据集。尤为以 Ubuntu 为例，从15年更新至今，已经积累了很是大规模的数据。

以 Dialogue 为输入，咱们开展了任务型和非任务型两个方向的工做。先来看下任务型对话：

2.1 NLU

当一个用户输入过来，第一个要作的就是天然语言理解 ( NLU )，NLU 要作的三件事为：Domain 识别；Intent 识别；信息槽识别或叫槽填充。这三个任务能够分别独立地或采用管道式方法作，也能够联合起来进行建模。在联合建模之外，咱们还作了一些特别的研究。好比咱们在槽识别的时候，老是有新槽，再好比有些槽值很是奇怪，例如 "XX手机能够一边打电话一边视频吗？"，对应着槽值 "视频电话"，采用序列标注的方式，很难识别它，由于这个槽值很是不规范。用户输入可能像这样语义很是松散，不连续，也可能存在很是多噪音，在进行联合建模时，传统的序列标注或分类为思想，在实际应用中已经不足以解决问题了。

咱们针对这个问题作了比较多的探讨，右图为咱们2015年的一个工做：在这三个任务联合建模的同时，在槽填充这个任务上将序列标注和分类进行同时建模，来更好地完成 NLU。

在 NLU 领域还有一个很是重要的问题，随着开发的业务领域愈来愈多，咱们发现多领域对话产生了诸多很是重要的问题，例如在数据层有些 domain 数据可能不少，有些 domain 数据可能不多，甚至没有，因而就遇到冷启动的问题。所以，咱们作了很是多的 domain transfer 的工做。上图为咱们2016年的一个工做，咱们会把数据比较多的当作源领域，数据比较少的当作目标领域。因而，尝试了基于多种迁移学习的 NLU，有的是在特征层进行迁移，有的是在数据层迁移，有的是在模型层进行迁移。图中是两个典型的在特征层进行迁移的例子，不只关注领域通常特征，并且关注领域专门特征，同时采用了对抗网络来生成一个虚拟的特征集的模型。

2.2 NLU+DM

紧接着，咱们研究了 NLU 和对话管理 ( DM ) 进行联合建模，由于咱们发现人人对话的时候，不见得是听完对方说完话，理解了对方的意图，而后才造成对话策略，有可能这两个过程是同时发生的。甚或 DM 还能够副作用于 NLU。早期咱们基于的一个假设是， NLU 可能不须要一个显式的过程，甚至不须要一个显式的 NLU 的功能，咱们认为 NLU 最终是服务于对话管理 ( DM )，甚至就是对话管理 ( DM ) 的一部分。因此，2013年的时候，咱们开始了探索，有两位特别优秀的毕业生在这两个方面作了特别多的工做。好比，如何更好地联合建模语言理解的输出和对话管理的策略优化。这是咱们在 NLU 和 DM 联合建模的工做，同时提高了 NLU 和 DM 的性能。

在联合模型中，咱们发现，DM 的建模涉及到很是多的 DRL ( 深度强化学习 ) 的工做，训练起来很是困难，好比如何设计一个好的用户模拟器，基于规则的，基于统计的，基于语言模型的，基于 RL 的等等咱们尝试了很是多的办法，也取得了一系列有趣的发现。2018年时咱们研究一种不依赖于规则的用户模拟器，业界管这个问题叫作 "Self"-play，虽然咱们和 "Self"-play 在网络结构上差别挺大的，可是咱们仍是借鉴了 "Self"-play 训练的特性，把咱们本身的系统叫作 "Self"-play。在这样的机制引导下，咱们研究了不依赖于规则，不依赖于有标记数据的用户模拟器，使得这个用户模拟器能够像 Agent 同样，和咱们所构造的对话的 Agent 进行交互，在交互的过程当中完成对用户的模拟。

在训练过程当中还有一个重要的问题，就是 reward 怎么来，咱们知道在 task oriented 时，reward 一般是人类专家根据业务逻辑/规范制定出来的。事实上，当咱们在和环境交互的时候不知道 reward 有多大，可是环境会隐式地告诉咱们 reward 是多大，因此咱们作了很是多的临接对和 reward reshaping 的工做。

2.3 小结

Dialogue-driven dialogue 这种形式的对话系统，总结来看：

优势：

定义很是好，逻辑清晰，每个模块的输入输出也很是清晰，同时有特别坚实的数学模型能够对它进行建模。

缺点：

因为很是依赖数据，同时，不管是在 NLU 仍是 NLG 时，咱们都是采用有监督的模型来作的，因此它依赖于大量的、精细的标注数据。

而 DM 每每采用 DRL 来作。NIPS2018 时的一个 talk，直接指出：任何一个 RL 都存在的问题，就是糟糕的重现性、复用性、鲁棒性。

1. FAQ-driven dialogue

FAQ 是工业界很是常见的一种情景：有大量的标准问，以及这个标准问的答案是什么。基于这个标准问，一个用户的问题来了，如何找到和它类似的问题，进而把答案返回给用户，因而这个 Service 就结束了。

实际中，咱们如何建 FAQ？更多的时候，我会把这个问题和咱们库的标准问题作一个类似度的计算或者作一个分类。

咱们在作这个工做的时候发现一个特别大的问题，就是 Unbalanced Data 问题。好比，咱们有5000个问题，每一个问题都有标准答案，有些问题可能对应的用户问题特别多，好比 "屏幕碎了" 可能会有1000多种不一样的问法，还有些问题，可能在几年的时间里都没有人问到过。因此，面对数据不均衡的问题，咱们从2016年开始作了 Data transfer 的工做。

大体的思路是：我有一个标准问题，可是很糟糕，这个标准问题没有用户问题，也就是没有训练语料。接下来发现另一个和这个标准问很类似的其它标准问有不少的训练语料，因而借助这个标准问，来生成虚拟样本，进而削弱了 Unbalance。

具体的方法：咱们把目标领域的标准问当作 Query，把和它类似的标准问题及其对应的用户问题当作 Context，采用了 MRC 机器阅读理解的架构来生成一个答案，做为目标问题的虚拟的用户问题，取得了很是好的效果，而且尝试了三种不一样的生成用户问题的方法。

实际项目中，FAQ 中的 Q 可能有很是多的问题，例如3000多个类，须要作极限分类，这就致使性能低下，且很是耗时，不能快速响应用户的问题。因而咱们作了一个匹配和分类进行交互的 model，取得了不错的效果。

目前，大部分人都认为 FAQ 驱动的 dialogue 不叫 dialogue，由于咱们一般说的 dialogue 轮次是大于两轮的。而 FAQ 就是一个 QA 系统，没有交互性。有时候带来的用户体验很是不友好，好比当答案很是长的时候，系统要把长长的答案返回，就会一直讲，致使用户比较差的体验。因而，咱们基于 FAQ 发展出了一个多轮对话的数据，如右图，这是咱们正在开展的一个工做。

1. KB-driven dialogue

KB 最先人们认为它就是一个结构化的数据库，一般存储在关系型数据库中。好比要订一个酒店，这个酒店有各类属性，如位置、名称、户型、价格、面积等等。早期 CMU 的对话系统，全部的模块都要和 Hub 进行交互，最后 Hub 和后端的数据库进行交互。数据库的价值很是大，可是早期人们在建模人机对话的时候，都忽视了数据库。这里就会存在一个问题：机器和用户交互了好久，而在检索数据库时发现没有答案，或者答案很是多，形成用户体验很是糟糕。

从2012年开始，咱们开始把 KB 引入咱们的对话系统。图中的对话系统叫作 "teach-and-learn" bot，这是一个多模态的对话，可是每一个涉及到的 object，咱们都会把它放到 DB 中。和用户交互过程当中，不光看用户的对话状态，还要看数据库状态。这个想法把工做往前推动了一些。

直到2016年，MSR 提出的 KB-InfoBot，第一次提出了进行数据库操做时，要考虑它的可导性，不然，就没办法在 RL 网络中像其它的 Agent action 同样进行求导。具体的思路：把数据库的查询和 Belief State 一块儿总结起来作同一个 belief，进而在这样的 belief 基础上作各类对话策略的优化。

在上述方法的基础上，咱们作了有效的改良，包括 entropy regularities 工做。是每次和用户进行交互时，数据库的 entropy 会发生变化。好比当机器问 "你想订哪里的酒店？"，用户答 "阿里中心附近的。"，因而数据库马上进行了一次 entropy 计算进行更新，接着继续问 "你想订哪一天的？"，用户答 "订7月28号的"，因而又进行了一次 entropy 计算进行更新。这样在和用户进行交互的时候，不光看用户的 dialogue 输入，还看 DB 的 entropy 输入，以这两项共同驱动 Agent action 进行优化。

这里咱们作了特别多的工做，信息槽从1个到5个，数据库的规模从大到小，都作了特别多的尝试，这样在和用户交互的时候，agent 能够自主的查询检索，甚至能够填充和修改数据库。

这是咱们2017发布的一个工做，KB driven-dialogue，其优势：

控制万能高频回复 ( 提升答应包含的有用信息 )

赋予 agent 对话主动性

1. KG-driven dialogue

刚刚讲的基于 KB 的 dialogue 任务，基本都认为对话任务就是在进行槽填充的任务，若是一个 agent 是主动性的，经过不停的和用户进行交互来采集槽信息，因此叫槽填充，当槽填完了，就至关于对话任务成功了。可是，当咱们在定义槽的时候，咱们认为槽是互相独立的，而且是扁平的。然而，实际中许多任务的槽之间存在相关性，有的是上下位关系，有的是约束关系，有的是递进关系等等。这样天然的就引出了知识图谱，知识图谱能够较好地描述上述的相关性。因而，产生了两个新问题：

知识图谱驱动的对话理解：实体连接

知识图谱驱动的对话管理：图路径规划

这里主要讲下第二个问题。

举个例子，咱们在办理电信业务，开通一个家庭宽带，须要提供相关的证件，是本身去办，仍是委托人去办，是房东仍是租户等等，须要提供各类不一样的材料。因而这个情景就产生了条件的约束，某一个 node 和其它 node 是上下位的关系，好比证件能够是身份证，也能够是护照或者户口簿等等。因此咱们能够经过知识图谱来进行处理。

当一个用户的对话过来，首先会连接到不一样的 node，再基于 node 和对话历史构造一个对话的 state，咱们会维持一个全局的 state 和一个活跃的 state，同时活跃的 state 会定义三种不一样的操做动做，一个是祖先节点，一个是兄弟节点，还有一个是孩子节点。因此，在这样的知识图谱上如何寻优，好比当经过某种计算获得，它应该在某个节点上进行交互的时候，咱们就应该输出一个 action，这个 action 要和用户确认他是一个租户，仍是自有住房等等。因此，这个 action 是有区别于此前所提到的在特定的、扁平的 slot 槽上和用户进行信息的确认、修改等仍是有很大不一样的。解决这样的问题，一个很是巨大的挑战就是状态空间很是大。好比图中的节点大概有120个，每一个节点有3个不一样的状态，知识从节点的状态来看就有3的120次幂种可能。这也是咱们正在开展的待解决的一个问题。

在端到端的对话模型 ( 闲聊 ) 中，也开始逐步地引入知识图谱。下面介绍两个比较具备表明性的引入知识图谱后的人机对话。其中右边是2018年 IJCAI 的杰出论文，清华大学黄民烈老师团队的工做，引入了经过 KG 来表示的 Commonsense，同时到底在编码器端仍是在解码器端引入知识，以及如何排序，排序的时候如何结合对话的 history 作知识的推理等等，都作了特别全面的研究。

另外一个比较有表明性的工做是在 ICLR2019 提出的，在架构中引入了 Local Memory 和 Global Memory 相融合的技术，经过这种融合，在编码器端和解码器端同时加入了知识的推理。

总结下 KB/KG-driven dialogue：

优势：

已经有大规模公开的数据 ( e.g.，InCar Assistant，MMD，M2M )。

训练过程可控&稳定，由于这里多数都是有监督学习。

缺点：

由于采用有监督的方式进行训练，因此存在以下问题：

① 环境肯定性假设
② 缺乏对动做的建模
③ 缺乏全局的动做规划
Agent 被动，彻底依赖于训练数据，因此模型是不赋予 Agent 主动性的。

构建 KB 和 KG 成本昂贵！

1. Document-driven dialogue

Document 驱动的对话，具备以下优势：

① 应用场景真实丰富：

情景对话 ( conversation )，好比针对某个热门事件在微博会产生不少对话，这就是一个情景式的对话。

电信业务办理 ( service )，好比10086有很是多的套餐，如何从中选择一个用户心仪的套餐？每一个套餐都有说明书，咱们能够围绕套餐的说明书和用户进行交互，如 "您但愿流量多、仍是语音多"，若是用户回答 "流量多"，就能够基于文本知道给用户推荐流量多的套餐，若是有三个候选，机器就能够基于这三个候选和用户继续进行交互，缩小候选套餐范围，直到用户选出心仪的套餐。

电商产品推荐 ( recommendation )，能够根据商品的描述，进行各类各样的对话。这里的输入不是一个 dialogue，也不是一个 KB，甚至结构化的内容很是少，彻底是一个 free document，如何基于这些 document 进行推荐，是一个很好的应用场景。

交互式信息查询 ( retrieval )，不少时候，一次查询的结果可能不能用户的需求，如何基于非结构化的查询结果和用户进行交互，来更好地达成用户的查询目的。

......

② 数据获取直接便捷：

相比于 dialogue、FAQ、KB、KQ 等，Document 充斥着互联网的各类各样的文本，均可以当作是文本的数据，获取方便，成本很是低。

③ 领域移植性强：

基于文本，再也不基于专家定义的 slot，也再也不基于受限的 KB/KG，从技术上讲，所构造的 model 自己是和领域无关的，因此它赋予了 model 很强的领域移植性。

这是咱们正在进行的工做，情景对话偏向于闲聊，没有一个用户目标。这里须要解决的问题有两个：

如何引入文档：编码端引入文档、解码端引入文档

如何编码文档：文档过长、冗余信息过多

数据：

咱们在 DoG 数据的基础上模拟了一些数据，造成了如上图所示的数据集，分 Blind 和 Non-blind 两种情形构造了不一样的数据集。

咱们发现，基于文本的端到端的聊天，有些是基于内容的闲聊，有些还须要回答特定的问题。因此，评价的时候，能够直接用 F1 评价回答特定问题，用闲聊通用的评价来评价基于内容的聊天。

刚刚讲的是偏闲聊式的对话，接下来说下任务型对话。

这里的动机分为两种状况：单文档和多文档，咱们目前在挑战多文档的状况，单文档则采用简单的多轮阅读理解来作。

多文档要解决的问题：

如何定义对话动做：由于是基于Document进行交互，而再也不是基于slot进行交互，因此须要从新定义对话动做。

如何建模文档差别：以刚刚10086的例子为例，总共有10个业务，经过一轮对话，挑选出3个，这3个业务每一个业务可能都有10种属性，那么其中一些属性值相同的属性，不必再和用户进行交互，只须要交互它们之间不一样的点，因此交互的角度须要随对话进行动态地变化。

数据：

这里采用的数据是 WikiMovies 和模拟数据，具体见上图。

1. A very simple sketch of dialogue

上图为任务型对话和非任务型对话的几个重要节点，你们能够了解下。

03

Concluding remarks

任务型对话具备最丰富的落地场景。

纯闲聊型对话系统的学术价值尚不清楚。

任务型和非任务型边界越发模糊，一个典型的人人对话既包括闲聊，又包括信息获取、推荐、服务。

引入外部知识十分必要，外部知识形态万千，建模方法也于是千差万别。

Uncertainty 和 few-shot 问题，是几乎全部的对话系统最大的 "卡脖子" 问题。

X-driven dialogue 中的 X 还有哪些可能？刚刚提到的 X 都仍是基于文本的。事实上，从2005年开始，咱们已经开始作 image 和文本数据融合的对话；从2013年开始作 Visual QA/Dialogue，挑战了 GuessWhat 和 GuessWhich 任务。

X=multi media ( MM Dialogue )，X 还能够很宽泛的就是指多媒体，不光有 image 还可能有 text，2018年已经有了相关的任务，而且开源了很是多的电商业务。这是一个很是有挑战性的工做，也令人机对话自己更加拟人化。

04

Reference

这是部分的参考文献，有些是咱们本身的工做，有些是特别杰出的别人的工做。

今天的分享就到这里，感谢你们的聆听，也感谢咱们的团队。

欢迎关注DataFunTalk同名公众号，收看第一手原创技术文章。