图灵测试70载，回顾对话机器人的经典实践和最新进展

2020 年 10 月 14 日 PaperWeekly

本文内容整理自 PaperWeekly 和 biendata 在 B 站组织的直播回顾，点击文末阅读原文即可跳转至 B 站收看本次分享完整视频录像，如需嘉宾课件，请在 PaperWeekly 公众号回复关键词课件下载获取下载链接。

作者介绍：卢栋才，来自华为云语音语义创新 Lab，博士学位，毕业于中国科技大学，曾获世界机器人大赛冠军，所负责的家庭服务机器人可佳和佳佳机器人在国内外有较高的影响力。曾研发的知识图谱问答技术，获得 CCKS2019 的技术创新奖，2020 年联合组织了一个 CCKS 相关的评测任务。同时，在一些机器人相关的会议和期刊上发表过一些论文。从 2012 年开始从事人机交互系统的算法，包括系统的研发，目前致力于华为云对话机器人平台相关工作。

从 1950 年图灵测试的提出到现在，对话系统已经走过了将近 70 年的时间，在这期间对话系统技术得到了快速的发展。方法也从当初的规则演变成如今的深度学习方法，对话系统的鲁棒性和准确性都得到了大幅提升。

2020 年，自然语言处理顶级会议 ACL 被接收论文中，对话系统相关工作论文数量达到历史之最，这也进一步验证了对话系统最近几年得到了非常大的关注。

本文将围绕对话机器人相关技术及其在行业中应用实践展开，同时介绍华为云对话机器人在多模态、小样本、预训练方向上的最新进展。将按照以下 5 部分展开：

对话机器人介绍以及历史简单回顾
对话机器人中的自然语言理解
对话机器人中的对话管理
多模态对话机器人进展
对话机器人未来方向以及总结

对话机器人介绍以及历史简单回顾

回顾对话机器人的发展历史，首先要提及的就是著名的图灵测试。1950 年图灵发表了一篇论文《计算机器与智能》，首次提出了对人工智能的评价准则，也就是图灵测试。其含义是指测试者和被测试者，通常是一个人和一台机器，在彼此分隔的情况下，由测试者通过一些装置向被测试者随意提问。

如果经过一段时间的交流后，有超过 30% 的测试者不能区分出哪些问题是由人或机器回答的，那么就证明这台机器通过测试，并且认为机器具有了一定的人类智慧。虽然说用图灵测试来评测对话系统目前存在很多的争议，但不妨碍图灵测试的思路引领了几十年间对话系统的发展。

图灵测试诞生后第一个人机对话系统是 ELIZA，由 Weizenbaum 于 1964 年到 1966 年间在 MIT 编码完成。ELIZA 主要是用在临床治疗中去，来模仿心理医生对患者提供咨询服务。当时只是用一些关键字的识别，但反响还是比较大的。时间跨越到 1995 年，业界诞生了一个非常聪明的，而且很有大众知名度的对话机器人 Alice。

Alice 三次获得了罗伯纳奖。罗伯纳奖是重要的人工智能的竞赛，采用的是标准化的图灵测试，评审会选出参赛程序中最像人类的。Alice 的成绩为什么如此惊人？主要原因在于其使用了 AIML 语言，在当年和同类产品相比具有很大的的竞争优势。

总结这时期对话机器人的功能，基本都是基于关键字的识别，或者是通过专家系统的规则来构建的对话系统。但是，随着专家系统规则的演变，逐渐地出现了瓶颈。而基于数据驱动方法就得到很广泛的研究，并且慢慢地应用到了对话系统中。这一时期的对话系统主要是由自然语言理解这个模块来驱动，同时会结合基于强化学习的对话管理。

为了解释它为什么是由自然语言理解和对话管理来驱动这个问题，研究者们做过两个典型的工作：在 2005 年到 2013 年，剑桥大学的 Steve Young 教授提出了基于 POMDP 的对话管理，以及一个基于管道 Pipeline 方式的对话系统。

这一时期，基于机器学习自然语言理解方法百花齐放，出现了很多经典的机器学习模型。

上文提及的剑桥大学 Steve Young，就是现在苹果手机里面后台的 Siri 之父，为后续的深度学习的方法的对话系统研究，包括应用落地，打下了非常坚实的基础。基本上形式化了很多对话系统的经典的问题。但是随着后面的发展，基于传统的机器学习也很快遇到了瓶颈，特别是在语音识别和图像分类方面，准确率无法得到很大的提升。

所以在第三代的研究中，这些系统基本上转向了基于大数据和深度学习的技术。比如现在大家熟知的，Amazon Alex、Google Home、Siri 这些助手类机器人。它们其实主要是以深度学习方法，即意图的识别、语言理解的方式。基于深度学习技术，使得端到端的对话系统变得可行。

最近的几年的研究中，端到端的对话系统得到了越来越多的关注和投入。2017 年开始，对话系统已经开始大规模在行业落地应用了，也有人称 2017 年是对话机器人的元年。

那么，为什么需要对话系统、对话机器人呢？对话机器人到底有什么用？我们为什么要研究它？这点要从对话机器人巨大的需求背景讲起。

需求主要是在两个方向，一个是 to B，另一个是 to C。to B 场景比如企业客服，客服人员的劳动是简单重复的，可以用对话机器人自动客服取代人类客服。

其二是办公助手，像华为 Welink，即类似钉钉、微信、WeChat 一样的办公类软件，其实也有一部分可以去辅助人触达一些应用。这种办公类的助手，可以帮助订机票，新建日程。还有一个方向是市场销售，机器人也可以帮助企业做一些推销、销售、介绍产品。

对于 toC 来说，一个典型的应用是个人助理，特别像家里会涉及到音箱等，这些个人助理现在有很大的应用背景。包括针对老人、小孩等特定人群的情感陪护需求，相对应的可以开发情感陪护的机器人。甚至有些机器人可以与小孩进行同步学习，教小孩一些课程，做一些娱乐的活动。

那么什么是对话机器人？首先通过最后三个字 “机器人”，第一个想到可能是一个实体机器人。

确实，实体机器人可以做人机对话交互，特别像科大可佳机器人，能够做一些多模态交互，给人类情感上一些陪护，甚至机器人它可以根据人的指令去做一些家居的控制，科大的可佳机器人可以去操作冰箱、微波炉，可以听懂人的指令去操作环境上的一些物体，另外类似日本的阿森姆机器人，这一类机器人就是实体类的硬件机器。

还有一类是虚拟的软件机器人，它可以部署在我们的操作系统里面，像微软的 Cortana。也可以部署到硬件里面，甚至是手机里面，像 Siri、Amazon Alex。

总结一下，对话机器人主要的目的是希望能够通过多轮对话的方式帮助用户完成任务，或者是保持用户持续的一个有效的交流，并且可以部署到大量的硬件设备里面去。

这里将对话机器人做两个分类，第一类是任务完成型的对话机器人，第二是闲聊型对话机器人。上图表格是两种机器人的对比，我们可以称之为一个是理性机器人，一个是感性机器人。

任务完成型对话机器人它可以偏理性一点，它需要去做一些任务。通常它可能需要调用一些知识库，或者一些服务后台的 API。

但感性机器人即闲聊对话机器人，对产品层级来说，它可能会更偏向于感性一点，需要理解用户的一些情感。任务完成型对话机器人它一般都有特定的目标，因为它确实需要完成一些具体的任务。闲聊对话机器人它通常是没有特定的目标的，它会跟你一直持续的聊下去。

而且从对话轮数控制来说，任务完成型对话机器人它希望是对话轮数越少越好，因为越少越好，能更快地达到目标。闲聊对话机器人它可能希望能够跟人对话次数越来越多，而且能够持续的交流下去。

任务完成型对话机器人它通常包含多个模块，而且可以采用规则或者统计学习的方法。但闲聊对话机器人它通常采用一些检索，或者是 sequence to sequence 的生成方法，这是这两类方法的不同点。下文将重点在任务完成型这一类机器人上展开内容。

从历史角度看，从图灵测试到现在已经 70 年过去了，对话机器人这一领域目前还是存在非常大的挑战。大体总结为以下几点：

首先，语言的多样性非常复杂，一个含义可能有各种各样的表达。同样，同一个表达，在不同的语境下代表的含义可能不一样，也就是语言的歧义性。

语言的多样性和歧义性会给对话机器人的进展带来非常大的挑战。

此外还有语义的表示，首先需要让机器去理解语言，而语言本身的符号是无法被机器所理解的，需要把符号转换成机器的内部表示。那么内部表示怎么定义呢，什么样的内部表示才是丰富的呢。但是表示越丰富，对应的学习能力可能越弱，反之表示越弱，可能学习得越快，这需要如何权衡呢？

再者是系统的鲁棒性，关于精度和召回的平衡。对话机器人也面临着一个问题，特别是在 to B 场景里面数据是极度匮乏的，在没有数据情况下，如何去进行训练，如何去做模型的调优，如何保证它的鲁棒性？还包括现在深度学习的可解释性，面对符号和环境知识的桥接。

当机器人跟人对话时，它一般会建立在共同的知识基础上，大家都知道中国的首都是北京，但如果机器人不知道这个知识，那它怎么跟人继续交流呢？

上图是一个对话机器人常用的框架流程，主要分三个模块。

第一块是自然语言理解，自然语言理解的目的就是将自然语言文本转成机器内部语义表示。任务型对话它通常有个假设。假设语义表示，它是由三个语义元素来组成的，一个是领域、一个意图、一个槽。

一个领域通常是包含多个意图，比如天气这个领域，有可能查天气，有可能查温度，有可能是查风向，这些不同的意图，通常一个意图上可能有多个槽，我说查天气它查的是什么呢？可能有时间、可能有地点，槽可能是任务型对话里面的概念，大家可以认为槽是一个关键字的这样一个关键信息的概念，类似于时间、地点，也可以是用户定义的任何的一个词条类型。

这里举个例子，当用户说：“今天深圳天气怎么样”，自然语言理解的任务就是需要识别出来这句话里面领域和意图是什么。所以输出领域为天气，意图是查天气。句子中提取到时间和地点槽位，时间是今天，地点是深圳。通常在实际落地应用里，还需要把时间今天翻译成一个真正的一个时间表达，比如说 2020 年 8 月 26 号。让后台系统方便对接。

自然语言理解模块之后，进入对话管理的模块，其中包含两个子模块，对话状态跟踪和对话策略。从对话管理职责来看，这一步的输入就是自然语言理解模块的输出，输出是一个 action，action 表明系统应该去做什么，应该回复给用户什么东西，而且这个生成的 action 一般是一个形式化的、结构化的内容，所以说它一般会再经过一个自然语言生成的模块。

自然语言生成模块的目的就是把对话管理的输出，转成一个用户能够理解的自然语言描述，这个时候它会生成一个回复就是：“好的，今天深圳的天气是晴，温度 20~30 度。”这么一条自然语言描述。这就构成了非常典型的对话机器人的常用框架。

重点来看，对话管理又可细分对话状态跟踪和对话策略模块。对话状态跟踪的意思就是需要输入自然语言理解的结果，同时需要去更新机器里面内部维持的状态，它状态跳转到什么地方了，而且每一个槽的值发生了什么变化。

比如说像这里面已经知道时间是今天，地点是深圳，当没有获取到这个信息的时候，它之前的时间、地点肯定是空的、未知的，当接受到这个信息，需要去更新它，时间，原来是今天，地点是深圳，这就是对话状态跟踪需要做的。

对话策略就是需要根据这些机器人里面的状态，去选择一个行动，这个行动就需要去反馈给用户，图上所示就是通过状态的结果，去生成一个 inform 动作。

对话机器人中的自然语言理解

那么，华为云在自然语言理解方面有哪些实践、进展？首先来讲讲对话机器人中的自然语言理解模块。

自然语言理解模块任务包含三个任务，一个是领域识别，一个意图识别，一个槽填充。

领域识别、意图识别其实它任务是一样的，都是一个分类任务。在上图的圆圈里，是我们涉及到的一些典型的算法，在领域、意图识别里面。左下角就是一些规则的方法，前面对话机器人的历史介绍的时候有提到过，主要包括一些关键字的识别，正则规则，然后上下文无关文法。这一块其实工业界机器人平台也有在使用。

上图左上角是传统的机器学习方法，像传统的 SVM、决策树，甚至 LR 的一些方法。到后面深度学习里面用的比较多了，像 TextCNN,Fasttext，包括 R-CNN。从最近几年趋势来看，其实预训练已经开始流行了，甚至分类识别的一个任务的范式其实已经发生改变了。像基于 BERT，华为的 NEZHA 这样的预训练的模型加微调方式，都可以很好的去做这类任务。

针对一些平台级的，特别是 to B 的场景，有很多不同类型的场景，因为有些企业可能没有数据，有些企业数据量不多，而有些企业确实随着日志的产生，它有很多数据。针对不同的数据，不可能一上来就套用BERT或一个预训练模型，这种方法是不太可行的。

针对这些不同情况我们做了一些探索。先看如果在无样本情况下，如何做这样的领域一种识别，所以说华为云的一些对话机器人技术平台上，其提供了一些规则的方式定制，因为规则的话，一旦配置一条规则，其实它能泛化识别出大量的文本，在规则里面提供适配的一些通配符，包括它可以配置一些槽位的字段，甚至一些普通的字段，普通字段可能是一些 word，包括用户自己的字典，这些都可以配置。

右边是给的一些示例，通过这些规则配置，我就可以做一些冷启动的方式。即使在这个用户没有训练数据的情况下，也有很大的帮助。

第二种情况，有很多数据时如何选择最好的方法呢？这就要用到最近几年众人熟知的，通过预训练加微调的方式，像上图右边这种方式，基本的结构是 transformer，transformer 之后输出了一个CLS标签的 Logits，后面接个全连接层，来预测做分类。

这种任务通过大量的实验后发现确实效果比较好，比如云上办公软件华为 Welink。

Welink 有一些助手的意图，在 80 多家意图里面，每个意图给它分配 10 条语料、50 条语料、100 条语料，然后把所有语料放进去，它的效果确实不断递增，而且最终效果基本上可以达到 95% 以上的效果。如果你数据越多，它效果确实会答的非常好。

不过存在一个问题，即部署成本较高。因为如果每个用户都上一个 BERT，成本上的压力是很大的。虽然说它是通过预训练的方式加微调，但仍然需要交大量的数据。

我们有没有其他方法去解决呢？有的，可以使用一些模型蒸馏的方法来解决，例如上图 Tiny-NEZHA 这样一个蒸馏的方式去把大模型去蒸馏到小模型里。

NEZHA 其实跟 BERT 本身模型上其实差距不是很大，都是基于 transformer 的结构，但它有一些细微上的结构上的不同，一是可能采用一些相对位置编码，第二个就是字掩码，因为字掩码可能是字，或是基于词级别的掩码，和增大 batch size 可能会用一些混合精度训练，包括 LAMB 优化器，这四点可能会有点不一样。

第二块就是我们的蒸馏技术 Tiny-BERT，会在两个地方都做蒸馏，一个是在预训练中的通用蒸馏，通用蒸馏即在训练里面也可以做蒸馏。第二个就是在任务相关的其实也可以做蒸馏，也做了一些数据增强的工作，中文系列模型 NEZHA 的话已经也开源了，代码和模型可以公开下载。

蒸馏方法如何实现呢？首先要想清楚学什么，其次知道怎么学。因为大模型 teacher 和 Student 原本就可以学很多向量的表示了，向量生成的一个表示，包括本身的隐藏 State 等都可以去学。

每个层学的方向不一样，在输出层，可以通过传统的 logits 学生模型的预测层的 logits 上去拟合 logits，在中间层，就是一个 Embedding 层的一个蒸馏，可以去用 MSE 去不断的去逼近中间层的表达。

通过这几种方式，其实在 NLPCC 任务里面其实也做了很多这样的蒸馏实验，包括大小模型、高瘦模型、矮胖模型等，还包括如下面表格里面，在 4 层在 6 层在 8 层里面它的一个对应的效果。最终结果还是看上图的右上角，在 ChineseProve 这样一个小模型任务，我们最后 score 达到 77.7 分，拿到第一位。

假如需要再轻量级的模型，是否还有其他方法？对工业界来说，可以结合一些传统的特征，也可以结合一些深度的特征。传统的特征例如语言模型、词性、实体，包括同义词、停用词这些都可以利用上，而深度特征像 word2vec，包括结合一些浅层的深度学习的编码器等都可以实现。

第二个问题，在没有大量的数据前提下，也就是小样本场景下的领域意图识别如何处理。这种情况下，随时会加一些新的类别，而且新的类别下可能几条数据，无法跟之前的数据一起训练。

这种情况下学界提出小样本学习的概念，其目标是只需提供你若干个样本（可能是 1~5 个样本），根据这 1~5 个样本去学习，来判断这个类别是什么。

小样本学习的思路分两个过程，一个是元训练的阶段，这一步非常简单。有一个基本的训练数据后，把这个基本的数据划分成两个集合，一个是支撑集，一个是询问集，支撑集里可能是每个类别是非常有限的，只能 sample 句子，k 通常很少很少可能 1~5 个， Query 可以自己选。最后元测试的阶段就随机去采 1 到 5 个样本，再输入一个 Query，通过这批小样本是不是能够预测正确。

小样本学习有三种不同类型的方法，像刚见过的基于模型的，还有基于 optimize的优化的方式，此外还有基于度量的方式。我们在度量方式做了一些探索。

度量方式分很多种，比如 MatchingNet 是匹配的网络；原型网络 protoNet，唯一的不同就是 distance 计算不太一样，此外还有 relationnet。我们在小样本上跟传统的 BERT 预训练加微调的方式确实做了对比。

在十个类别、五个样本都做了一些对比的实验。BERT传统分类有 83.2% 准确率，但小样本学习的方法可能达到 93% 的准确率，提高确实比较大。最终十个类别十个样本最终能达到准确率 96% 的效果。

同样，在实验的过程中也发现了一个问题，为什么它能达到准确率 96%？这背后有个取巧方法，目前小样本学习也存在这样的现象。在已有框架下是每个 Epoch 的训练测试数据其实是随机采样的，当有 2000 个类别时，随机采 5 个，而数据本身包含大量简单样本时，这样的采样方式很难涵盖到其中的困难样本，所以实际效果十分存疑。

为此，我们也做了实验，提出了一个结合小样本学习和课程学习的方法。方法分为几部分，一部分先做难度的评估。我们可以采用 BM25 或 TFIDF 计算一下每个样本之间的差距，专挑那些难的样本放在一起来学习。另一部分做数据划分，可以把相似难度的数据划分到一起。

在之前的实验里面，直接用难的样本去训练效果如上图所示是非常非常差的。

换一个思路，在能够保证测试级别比较难的基础上完成学习训练，但发现效果还是会下降得很快。而前文讲过测出来可能会达到准确率 96% 的效果，但这样分析和实验后，会发现真实的小样本学习其实没有这么好的效果。为了解决这种情况，就要结合课程学习，不断从易到难。

最终如上图，提高三到六个点的准确率，目前工作也在也在持续地进行中。

可以得到的结论是，在简单数据上，课程学习虽然不能显著提升效果，能提高 3 到 6 个点的准确率，但确实可以降低方差（方差就是说原本我随着训练的难度，测试难度越大，好跟不好差距特别大），而且直接使用传统的小样本学习的方法，在难的样本里其实并不能取得很好的效果，之前能达到准确率 95% 这样的效果其实是不可信的。同时加入小样本加课程学习，在难样本上提升效果比较明显。

再来看槽填充方法。比如说用户想要预定明天去北京的机票，机器人需要提取出来 time 是明天，而 destination 是北京，通常在实际使用中明天可能会需要转成一个具体的时间表达，这样一个任务可以转换成一个序列标注任务

在线上场景中除了可以采用 CRF、LSTM-CRF、BERT 这些模型，一般情况下有一套完整流程，通常对话前会内置一些实体，首先会做自定义的实体识别，其目的在于作为一个实体的归一化和做细度的特征提取，之后才会输入到模型里，来提高模型的泛化能力。同时还会结合槽填充的规则做融合，得到输出结果。

应用场景中，槽填充会有哪些问题呢？首先是时间归一化，时间表达会比较多。另外不同的客户人名可能不太一样，人名表达也具有多样化，不同用户人名的识别也会带来一些难度。同时模型和规则的融合方法也存在挑战。最后就是多轮中可能会有一些槽填充的问题。新平台里面需要内置一些槽位，这样用户用起来可能会比较方便、简单。

从上文可以看出，将领域识别、意图识别槽填充拆开出来当多个任务会带来一些问题：

领域识别和意图识别会产生错误，槽填充也会产生错误，经过一层一层 pipeline 可能会叠加一些误差。这个时候可以采用多任务模型的方式，即把这三个标签信息、三个语料同时去放到一个模型里面去学习；

如上图模型，融合 bert 和 crf 对领域、意图、槽联合建模，实验结果也证明确实会带来较大的提高。传统的 CRF 模型可能效果确实不是很好，最后的 ChunkF1 可能只能达到 0.79 的准确率。通过 BERT 它可能达到 0.87 的准确率。加入领域识别槽填充这一系列后，最后的 ChunkF1 大约能提高大概两个点。

对话机器人中的对话管理

为什么对话机器人需要对话管理模块呢？为什么不直接用自然语言理解直接对接服务 API？对话管理模块存在很有必要，而且是对话系统的核心，其原因在于用户很多情况下不会一次性表达完意图，同时系统各个模块的准确率，也并不一定能达到 100% 的准确。

不管是语音识别或者自然语言理解本身解析都可能产生错误，导致反馈不正确的回复，或者根本就不知道怎么回复。这两种情况都需要机器人跟用户进行多次的交流确认，才能获取用户的完整的意图，也就是需要对话管理模块来完成这部分工作。

对话管理一般分为状态跟踪和对话策略的学习两部分。状态跟踪就是用来跟踪用户的目标，比如用户当前说了什么、之前说了什么。上图左边是一个简单的状态集合，包括可能有一些相关的状态之间跳转，可以看到通常会有状态如何跳转的先验知识。

右边的结构是随着用户跟机器人的对话同时进行的。用户说 “我要预定明天去北京的机票”，这时用户状态从空就跳到了目的地出发地这样一个状态，并随着问题交互的进行，直到填充所有的槽位。这样一个过程是通过状态跟踪来做的。

再来看对话策略，对话策略的目的是告诉机器人应该说什么。看一个例子，按照上图红色框所示，根据输入的当前状态的信息，用户已经输入目的地了并告知了出发时间，系统应该去判断，发现出发地是未知的，这时的策略也很简单，提问 “请问从哪里出发？” 而不是 “请问去哪里？”。

对话管理任务到底存在哪些问题和困难呢？

首先是用户的意图是无法事先知道的，用户随时可能会说任何其他的话，甚至调戏机器人。所以机器人很难捕捉到用户真实的意图，甚至要面对用户可能会随时切换意图的可能。

第二，真实环境中噪音比较大，导致对话管理获取到的信息并不是用户真实表达的含义。

第三，绝大部分领域的意图槽位内容会很多，比如时间或者其他数字信息是连续的。如果要用模型真实建模来跟踪所有可能的状态，传统的方法基本上不可用。要建模所有可能的状态，并在状态之间跳转，需要枚举所有可能的语料，这本身是一个统计学问题。

对话管理本身方法也有很多。从上文讲过的历史来看，首先想到的是状态机的方法，像比如说上图左边的 S1，用户从 S1 状态下定义我在 S1 状态下它应该做什么行动，可以 forward，可以 backward，可以 left，可以 right。

当执行了 forward，就会到达 S3 状态，这个时候就完成了一轮的交互，这就是一个通过状态机的方式去实现的对话管理。对于状态怎么跳转，包括状态下应该做什么行为，都定义得非常清楚。

第二种，假设有 10 个槽，那个槽里面很多值，一一列举两种组合或者几种可能，其空间是非常大的，导致维护起来很困难。解决这一问题的思路之一是基于槽的框架的方法。

我们来看看大致思路，首先对模型做简单的形式化，认为槽跟槽之间是独立的，与所填的值无关，在没有填槽情况下，就进行提问，填充后就不问，多轮交互之后提问结束，目前很多企业，包括成熟的大企业和创业公司，很多都会采用槽的框架的方式。

不管是基于状态机还是槽框架，本质上都是一套规则，而历史上后续 Steve young 教授提出一个基于数据驱动的对话管理方法，本质上来说就是把对话管理当做一个部分马可夫决策过程，POMDP。如果大家感兴趣可以看一下 Steve Young 于 2013 年发表的非常经典的综述论文，主题就是 POMDP 的对话管理。

沿着历史的脉络梳理，这之后开始深度学习的方法就比较多了。目前效果最好的、比较经典的是 trade 模型，该模型获得了ACL2019 的 outstanding paper，作者把对话状态跟踪的任务建模成生成任务，首先把历史信息编码成向量，同时会把领域槽进行编码，最后融合生成对应槽的值。

当年这篇论文获得很大的成功，效果确实比较好。另一个典型的例子是上图右边基于强化学习的对话管理，把对话策略建模成深度强化学习的问题。

随着预训练火热之后，用 BERT 也能够解决对话状态跟踪的问题。可以通过 Bert 阅读理解技术，预测用户所说的话里面每个槽位的 Start pos 和 end pos，最终提取槽的值，同时它会再联合一个分类的任务去做联合模型。但是在真实场景中是没有标注数据的，所以我们一般会通过仿真器和一个机器人进行交互，这种交互的方式可以生成大量对话数据，同时也建立了一个访仿真器。

通过这个仿真器，可以生成很多对话样本。现在根据我们的意图和槽位，生成大概有 7000 多个对话样本，训练集里面大概有 3000 多个对话样本，最后通过 Bert 阅读理解分类联合方式，它的跟踪准确率可以达到 90% 左右。但这也存在一个问题 —— 生成的数据可能无法很好地模拟真实的情况。

针对对话策略来说，现在工业界绝大部分用的都是这种对话逻辑、对话流程的方式。因为在 toB 场景中，它的对话选择很丰富，刚开始在某个状态下，用户说任何一个意图，它可能会跳转到任何一个状态，它的行为会很多。

如果把它建模成一个真实的强化学习问题，第一对数据量要求很大，虽然也可以通过仿真生成数据，但它也需要很大的数据量。其次真实场景的一个行为空间是很大的，所以很难通过一个强化学的方式去模拟它。

但是在对这种对话流程方案进行设计的时候，也要解决很多实际上的问题。一个是槽位记忆的问题，它需要支持不同意图槽位之间的关联，例如在订票时，已经说了时间地点，那么在说查天气的时候它不应该反问你要查什么地方的天气。第二个是意图记忆的问题，它需要支持多轮的意图识别。例如用户在问天气时，问 “那上海的呢？” 就会利用多轮的信息识别成天气意图。

对话系统可以拆成语言理解、状态跟踪，和对话策略。其实自然语言理解也能够融入到对话管理里，深度学习已经允许把对话系统建模成端到端的方式。

有两个经典的工作，一个是 HRED，它把对话系统建立成双层的端到端的网络，第一层用来编码对话文本历史，第二层用来编码对话状态。这种方法比较粗暴，来了文本就直接编码，然后历史信息传递下去。

还有一个比较经典的工作是 Steve young教授团队的，它看起来是端到端，还是分局部的模块，特别像 pipeline 的方式，它先做一个意图的检测，也就是意图的网络，再做一个叫做 brief checker 的槽填充，最后再从 database 里面去做一个搜索，最后这三个信息融入到 policy network ，policy network 可以认为是对话策略网络，最后去生成它的一个回复，这样一个局部的端到端的任务型对话系统，比前面一种方法更好理解，而且解释性更强。

这就是两个比较经典的端到端的对话管理，那么针对未来的人机对话方式，怎么去设计一个更好的端到端对话系统架构呢？是不是仍然采用之前这两种方式？未来的人机对话的方式到底是什么呢？

多模态对话机器人进展

多模态自然人机交互系统是下一代人机交互系统的一个发展趋势，它可以融合视觉、听觉、触觉、嗅觉甚至味觉，表达的效率比单一的视觉甚至单一的文本丰富性更强。多模态自然语言人机交互的对话模式，是目前最为自然而且最理想的人际交互方式。

之所以研究多模态对话系统，是因为真实环境里的语音识别引擎带来的错误很难避免，同时它带来的语义歧义性也特别大。那是不是能够在理解语言的基础上，融合其他模块的信息，比如视频图片，引入一种多模态信息融合就能够提升计算机对用户意图的理解的准确性呢？

多模态对话的应用目前不是很多，但也有文章对此进行了研究，一个是情感感知对话系统，在驾驶时，驾驶员需要集中精力去关注路况，但是他很难腾出手去操作一个界面，这是一个很经典的多模态问题，它可以通过驾驶员，可以通过口头或者是视觉的提示，甚至是语音文本，驾驶时语音识别效果可能会更差，那么能不能通过视觉的信息，手势的信息去理解，这是一个非常典型的场景。

中科院自动化研究出了一个多模态自然语言口语对话系统，它可以结合人的一些表情手势姿态去进行对话，但本质上这几个应用场景还是一个模态之间的串联，它其实没有做到很好的模态之间的融合。所以我们一直在调查研究是不是可以做模态的融合。

通过调查，发现电子商务其实有这样一个场景：用户说 “我要买裤子，我要买衣服”，他还会发送一些样本图片，然后机器人也同时会反馈一些图片给他，这就是天生的一个文本加图片的方式，它可以构成一个多模态对话的流程。

多模态的简单定义是，给定多模态对话上下文，包括用户的询问，目标是生成对应的系统的文本回复。针对上文电商的场景，提供的可能只有文本跟图片，当然后面都可以扩充，还可以加语音甚至其他某些信息，那么这里面可能不含图片。它形式上就是你只需要输入一个历史上下文，再加上用户的 query，需要生成的是系统的回复。

对于端到端的对话管理，也可以使用 HRED 模型，该模型非常简单，但是它仅支持单模态。在 HRED 里面，只需要把图片信息加入，把图片编码，编码之后再融合文本，文本通过 RNN 得到向量，把这两个拼接在一起，再通过一层上面的 RNN，这就是现在用的比较多的基于 HRED 构造的多模态的 HRED 模型。

后面对模型进行了改进，第一使它可以在生成里面进行控制，经过意图的理解，去控制生成一个简单、通用的回复，也可以去生成一个多模态的、知识相关的回复。第二个改进点，可以在生成过程中融合一些知识进来，比如说三元组这些信息或者属性表格，会比较好地控制生成的质量。但这几个模型，也存在比较大的问题。

这里列举的两个经典论文提及的这些方法都是基于层级循环的神经网络。这个方法的模态融合很弱，是把句子编码成一个向量，其实这会损失句子里面的细度信息，比如说关键字实体。

另外一方面虽然使用了属性三元组，但其实并不能很好地有效利用这些知识，即知识的利用率比较低，所以华为采用了一种叫做 MATE 的模型，它是基于语义元素集的、上下文依赖的一个多模态对话系统。将模型拆开来看，左边是一个多模态元素集的编码器，用来编码来自对话历史的记录，包括用户查询的所有图像，都存储在对话记忆模块。

为什么存在图像记忆模块？因为有些当前的文本看不到前面的图片，所以说这里面会做一个 attention 操作。通过注意力机制或者图像的一些文本的嵌入，有选择性的是否加入一些图片。

最后所有嵌入都会拼接成多模态的语义元素集。这样每个元素跟图片里面的元素都可以进行一个很好的交互。第二块是右半部分，它是一个解码过程，解码过程可以分两步。

第一步先关注在编码器里面输出，它只关注前面生成的注意力操作。第二阶段，解码之后再结合领域知识，再做一个 attention 操作，这样能够进一步很好地去利用这样的知识，而且同时会利用好前面的一个编码器的输出，这样能够进一步地优化系统回复的质量。

上图是我们论文的一个实验结果，实验发现如果使用第一种解码器和第二个解码器，确实有一些提高。同时我们第一阶段的编码器，相对于前面所有方法中最好的方法，在 BLEU-1 上能提高 6 个点，在 BLEU-4 上能提高 9 个点，而且是绝对值的提升，这个提升是非常大的。

同时下面的表格，把不同的模块进行替换，进行进一步的分析，包括在去掉 image position，previous image，knowledge 的情况下进行的对比。

上图是展示的一个样例。它关注了语义元素集的信息，左下部分、右下部分， formal shoes 能关注到更上层的比较关键更元素集的一些信息，包括 star。

对话机器人未来方向以及总结

以上就是我们在对话机器人上的一些进展和工作。针对机器人的这个行业来说，我们是希望每个人都能享受到对话人机交互的乐趣。即使跨洋彼岸，机器人也能够跟用户更好地进行交流，甚至机器人能够服务好用户。上图是一张图片，显示器里面是凯文・凯利，右边是科大的佳佳机器人，当时是做了一个跨洋跨语种的对话。但要把这样的事做好，其实是一个很大的挑战。

首先，机器要理解用户，甚至能够理解用户很多开放性的问题，这需要很大量的常识知识，例如上文提及：中国的首都是北京，机器人怎么会知道这样一个知识？真实世界知识太多，如果它能够理解用户各种各样的问题，需要具备大量的常识知识去丰富它的能力。

再者同样比较重要的。也是现在比较流行的个性化需求。每个人的特性不一样，甚至机器人的特性也不一样，如何去依照每一个用户的个性去做不同的、基于个性化的回复，也是目前相对来说研究得比较多，且前景比较好的方向。另外，对于小样本学习需要解决的问题，特别是 toB 的场景企业的问题，挑战是比较严峻的，真实的场景里面企业其实没有太多数据，甚至是没有数据，小样本学习是企业会重点关注的一个问题。

多模态、多领域，预训练，预训练在相对未来一段时间内还是会成为主流。从目前实践证明，预训练加微调的方式效果确实会比传统的深度学习的重新训练效果好很多。再结合现在深度学习的可解释性，有一部分人在研究神经网络与符号类进行结合去解释深度学习，更好地去建模真实的 AI 问题。

然后是无监督学习，无监督学习和小样本学习面对的同样还是企业场景的问题，客户可能没有标注数据，也许会有一些非结构化数据，这些数据怎么用，怎么去学习，也是对话机器人从业者面临的挑战。最后，现在的一些语料，甚至是对话机器人的语料，绝大部分是 2014 年之前的，还是单语种的数据，到最近才开放了多语种的数据集，所以多语种对话机器人也将会是比较好的方向。

关于数据实战派

数据实战派希望用真实数据和行业实战案例，帮助读者提升业务能力，共建有趣的大数据社区。