阿里智能对话交互实践与创新

来源：人工智能头条

作者：孙健，李永彬，陈海青，邱明辉

概要：过去 20 多年，互联网及移动互联网将人类带到了一个全新的时代，如果用一个词来总结和概括这个时代的话，「连接」这个词再合适不过。

过去 20 多年，互联网及移动互联网将人类带到了一个全新的时代，如果用一个词来总结和概括这个时代的话，「连接」这个词再合适不过。这个时代主要建立了四种连接：第一，人和商品的连接；第二，人和人的连接；第三，人和信息的连接；第四，人和设备的连接。

「连接」本身不是目的，它只是为「交互」建立了通道。在人机交互（Human-Computer Interaction）中，人通过输入设备给机器输入相关信号，这些信号包括语音、文本、图像、触控等中的一种模态或多种模态，机器通过输出或显示设备给人提供相关反馈信号。「连接」为「交互」双方架起了桥梁。

「交互」的演进方向是更加自然、高效、友好和智能。对人来说，采用自然语言与机器进行智能对话交互是最自然的交互方式之一，但这条路上充满了各种挑战。

如何让机器理解人类复杂的自然语言？如何对用户的提问给出精准的答案而不是一堆候选？如何更加友好地与用户闲聊而不是答非所问？如何管理复杂的多轮对话状态和对话上下文？

在阿里巴巴，我们从 2014 年初开始对智能对话交互进行探索和实践创新，研发成果逐步大规模应用在了智能客服（针对阿里巴巴生态内部企业的阿里小蜜、针对阿里零售平台上的千万商家的店小蜜，以及针对阿里之外企业及政府的云小蜜等）和各种设备（如 YunOS 手机、天猫魔盒、互联网汽车等）上。

智能对话交互框架

典型的智能对话交互框架如图 1 所示。其中，语音识别模块和文本转语音模块为可选模块，比如在某些场景下用户用文本输入，系统也用文本回复。自然语言理解和对话管理是其中的核心模块，广义的自然语言理解模块包括对任务类、问答类和闲聊类用户输入的理解，但在深度学习兴起后，大量端到端（End-to-End）的方法涌现出来，问答和聊天的很多模型都是端到端训练和部署的，所以本文中的自然语言理解狭义的单指任务类用户输入的语义理解。在图 2 所示的智能对话交互核心功能模块中，自然语言理解和对话管理之外，智能问答用来完成问答类任务，智能聊天用来完成闲聊类任务。在对外输出层，我们提供了 SaaS 平台、PaaS 平台和 Bot Framework 三种方式，其中 Bot Framework 为用户提供了定制智能助理的平台。

图1 智能对话交互框架

智能对话交互核心技术

智能对话交互中的核心功能模块如图 2 所示，本部分详细介绍智能对话交互中除输出层外的自然语言理解、智能问答、智能聊天和对话管理四个核心模块。

图2 智能对话交互中的核心功能模块

自然语言理解

自然语言理解是人工智能的 AI-Hard 问题 [1]，也是目前智能对话交互的核心难题。机器要理解自然语言，主要面临语言的多样性、语言的多义性、语言的表达错误、语言的知识依赖和语言的上下文（示例见表 1）的五个挑战。

表 1 上下文示例

整个自然语言理解围绕着如何解决以上难点问题展开。

自然语言理解语义表示

自然语言理解的语义表示主要有分布语义表示 (Distributional semantics)、框架语义表示 (Frame semantics) 和模型论语义表示 (Model-theoretic semantics) 三种方式 [2]。

在智能对话交互中，自然语言理解一般采用的是 frame semantics 表示的一种变形，即采用领域（domain）、意图（intent）和属性槽（slots）来表示语义结果，如图 3 所示。

图3 domain ongology 示意图

在定义了上述的 domain ontology 结构后，整个算法流程如图 4 所示。

图4 自然语言理解流程简图

意图分类

意图分类是一种文本分类，主要分为基于规则的方法、基于传统机器学习的方法和基于深度学习的方法，如 CNN[3]、LSTM[4]、RCNN[5]、C-LSTM[6] 及 FastText[7] 等。针对 CNN、LSTM、RCNN、C-LSTM 四种典型的模型框架，我们在 14 个领域的数据集上进行训练，在 4 万左右规模的测试集上进行测试，采用 Micro F1 作为度量指标（注：此处的训练和测试中，神经网络的输入只包含 word embedding，没有融合符号表示），结果如图 5 所示，其中 Yoon Kim 在 2014 年提出的基于 CNN[3] 的分类算法效果最好。

图5 四种模型的分类效果对比

单纯以 word vector 为输入的 CNN 分类效果，在某些领域上无法超越复杂特征工程的 SVM 分类器。如何进一步提升深度学习的效果，其中一个探索方向就是试图把分布式表示和符号表示进行融合。比如对于「刘德华的忘情水」这句话，通过知识库可以标注刘德华为 singer、忘情水为 song，期望能把 singer 和 song 这样的符号表示融入到网络中去。具体融合方法，既可以把符号标签进行 embedding，然后把 embedding 后的 vector 拼接到 word vector 后进行分类，也可以直接用 multihot 的方式拼接到 word vector 后面。分布式表示和符号表示融合后的 CNN 结构如图 6 所示。

图6 分布式表示和符号表示融合后的 CNN 分类网络结构

经过融合后，在 14 个领域约 4 万条测试数据集上，对比融合前后的 F1 值（如图 7 所示），从中可以看出，像餐厅、酒店、音乐等命名实体多且命名形式自由的领域，效果提升非常明显。

图7 在 CNN 中分布式表示融合符号表示前后效果对比

在以词为输入单位的 CNN 中，经常会遇到 OOV（Out-Of-Vocabulary）问题，一般情况下会使用一个特殊向量（比如固定的随机向量或者已知词向量的平均值）来表示所有的 OOV，这样做的效果肯定不够好。在我们的实现中，引入了 FastText[8] 来训练 word vector，对于 OOV，可以用其 subword 向量计算得到，有效地解决了 OOV 的问题。

在效果优化方面，除了本文中所述的 word vector 的动态训练和 dropout 之外，通过对训练数据进行数据增强（data augmentation），效果会有较大的提升。

属性抽取

属性抽取问题可以抽象为一个序列标注问题，可以以字为单位进行序列标注，也可以以词为单位进行序列标注，如图 8 所示为以词为单位进行序列标注的示例。在这个例子中包含 departure、destination 和 time 三个待标注标签；B 表示一个待标注标签的起始词；I 表示一个待标注标签的非起始词，O 表示非待标注标签词。

图8 序列标注示例

属性抽取的方法，包括基于规则的方法和基于传统统计模型的方法，经典的如 CRF[9]，以及基于深度学习模型的方法。

2014 年，在 ARTIS 数据集上，RNN[10] 模型的效果超过了 CRF。此后，R-CRF [11]、LSTM[12]、Bi-RNN[13]、 Bi-LSTM-CRF[14] 等各种模型陆续出来。

在属性抽取这个任务中，我们采用了如图 9 的网络结构，该结构具有以下优点。

图9 属性抽取网络结构

输入层

在输入层，我们做了三部分工作：① 采用了分布式表示（word vector）和符号表示（symbol vector）融合的方式，有效利用了分布式的上下文学习能力和符号的抽象知识表示能力；② 采用了局部上下文窗口（localcontext window），将窗口内的词的表示拼接在一起送入一个非线性映射层，非线性映射具有特征学习和特征降维的作用；③ 采用了 FastText [8] 进行 word embedding 的学习，可以有效解决 OOV 的问题。

Bi-LSTM 层

在中间的隐藏层，采用 Bi-LSTM 进行特征学习，既能捕捉上文特征，也能捕捉下文特征。

输出层

在输出层有几种典型的做法，比如 Bi-LSTM+Softmax、Bi-LSTM+CRF 等，Bi-LSTM+Softmax 是把属性抽取在输出层当成了一个分类问题，得到的标注结果是局部最优，Bi-LSTM+CRF 在输出层会综合句子层面的信息得到全局最优结果。

意图排序

在表1 中，我们展示了一个例子，如果不看上下文，无法确定「后天呢」的意图。为了解决这个问题，在系统中我们设计了意图排序模块，其流程如图 10 所示。对于用户输入的 utterance，一方面先利用分类抽取模型去判定意图并做抽取；另一方面，直接继承上文的意图，然后根据这个意图做属性抽取。这两个结果通过特征抽取后一起送入一个 LR 分类器，以判定当前 utterance 是应该继承上文的意图，还是遵循分类器分类的意图。如果是继承上文意图，那么可以把这个意图及其属性抽取结果作为最终结果输出；如果是遵循分类器分类的结果，那么可以把各个结果按照分类器分类的置信度排序输出。

图10 基于上下文的意图延续判定

智能问答

在具体的业务场景中有三种典型的问答任务，一是用户提供 QA-Pairs，一问一答；二是建立结构化的知识图谱，进行基于知识图谱的问答；三是针对非结构化的文本，进行基于阅读理解的问答。本文重点介绍我们在阅读理解方面做的工作，比如利用阅读理解解决淘宝活动规则的问答。

在阅读理解的方法上，目前针对斯坦福大学的数据集 SquAD，有大量优秀的方法不断涌现，比如 match-LSTM[15]、BiDAF[16]、DCN[17]、 FastQA[18] 等。文献 [18] 给出了目前的通用框架，如图 11 所示，主要分为 4 层：① Word Embedder，对问题和文档中的词进行 embedding；② Encoder，对问题和文档进行编码，一般采用 RNN/LSTM/BiLSTM； ③ Interaction Layer（交互层），在问题和文档之间逐词进行交互，这是目前研究的热点，主流方法是采用注意力机制（attention）；④ Answer Layer（答案层），预测答案的起始位置和结束位置。

图11 阅读理解的通用框架

我们在具体实现中，参考 BiDAF[16] 网络结构，在此基础上做了大量优化。

模型的业务优化

需要改进模型的结构设计，使得模型可以支持电商文档格式的输入。电商规则文档往往包含大量的文档结构，如大小标题和文档的层级结构等，将这些特定的篇章结构信息一起编码输入到网络中，将大幅提升训练的效果。

模型的简化

学术文献中的模型一般都较为复杂，而工业界场景中由于对性能的要求，无法将这些模型直接在线上使用，需要做一些针对性的简化，使得模型效果下降可控的情况下，尽可能提升线上预测性能，例如可以简化模型中的各种 bi-lstm 结构。

多种模型的融合

当前这些模型都是纯粹的 end-to-end 模型，其预测的可控性和可解释性较低，要适用于业务场景的话，需要考虑将深度学习模型与传统模型进行融合，达到智能程度和可控性的最佳平衡点。

智能聊天

面向 open domain 的聊天机器人目前无论在学术界还是在工业界都是一大难题，目前有两种典型的方法：一是基于检索的模型，比如文献 [19-20]，其基本思路是利用搜索引擎通过计算相关性来给出答案；二是基于 Seq2Seq 的生成式模型，典型的方法如文献 [21-22]，其网络结构如图 12 所示。

图12 Seq2Seq 典型网络结构

检索模型的优点是答案在预设的语料库中，可控，匹配模型相对简单，可解释性强；缺点是在一定程度上缺乏对语义的理解，且有固定语料库的局限性，长尾问题覆盖率较差。生成模型的优点是通过深层语义方式进行答案生成，答案不受语料库规模限制；缺点是模型的可解释性不强，且难以保证回答一致性和合理性。

在我们的聊天引擎中，结合检索模型和生成模型各自的优势，提出了一种新的模型 AliMe Chat [23]，基本流程如图 13 所示。首先采用检索模型从 QA 知识库中找出候选答案集合；然后利用带注意力的 Seq2Seq 模型对候选答案进行排序，如果第一候选的得分超过某个阈值，则作为最终答案输出，否则利用生成模型生成答案。其中带注意力的 Seq2Seq 模型结构如图 14 所示。经过训练后，主要做了如下测试：如图 15 所示，利用 600 个问题的测试集，测试了检索（IR）、生成（Generation）、检索+ 重排序（Rerank）及检索+ 重排序+ 生成（IR+Rerank+Generation）四种方法的效果，可以看到在阈值为 0.19 时，IR+Rerank+Generation 的方法效果最好。

图13 AliMe Chat 流程图

图14 带注意力的 Seq2Seq 网络结构示例

图15 IR、Generation、Rerank、IR+Rerank+Generation 效果对比

此模型在阿里小蜜中上线，示例如图 16 所示。在阿里小蜜中，针对之前的 IR 模型和 AliMe Chat 模型，利用线上流量做了 A/B Test，结果如表 2 所示。从用户日志中随机选择 2 136 条数据，其中 1 089 是采用 IR 模型回答，另外 1 047 是采用 AliMe Chat 回答，AliMe Chat Top1 答案的准确率（accuracy）是 60.36%，远远好于 IR 的 40.86%。

图16 AliMe Chat 在阿里小蜜中上线后的聊天示例

表 2 阿里小蜜中 IR 方法与 AliMe Chat 方法 A/B Test 结果

对话管理

对话管理根据语言理解的结构化语义表示结果以及上下文，来管理整个对话的状态，并决定下一步采取什么样的动作。

下面来看一个简单的对话例子。

对话交互分成两个阶段，第一阶段，通过多轮对话交互，把用户的需求收集完整，得到结构化的信息（出发地、目的地、时间等）；第二阶段就是请求服务，接着还要去做选择、确定、支付、购买等后面一系列的步骤。

传统的人机对话，包括现在市面上常见的人机对话，一般都是只在做第一阶段的对话，第二阶段的对话做得不多。对此，我们设计了一套对话管理体系，如图 17 所示，这套对话管理体系具有以三个特点。

图17 对话管理框架图

第一，设计了一套面向 Task Flow 的对话描述语言。该描述语言能够把整个对话任务流完整地表达出来，这个任务流就是类似于程序设计的流程图。对话描述语言带来的好处是它能够让对话引擎和业务逻辑实现分离，分离之后业务方可以开发脚本语言，不需要修改背后的引擎。

第二，由于有了 Task Flow 的机制，我们在对话引擎方带来的收益是能够实现对话的中断和返回机制。在人机对话当中有两类中断，一类是用户主动选择到另外一个意图，更多是由于机器没有理解用户话的意思，导致这个意图跳走了。由于我们维护了对话完整的任务流，知道当前这个对话处在一个什么状态，是在中间状态还是成功结束了，如果在中间状态，我们有机会让它回来，刚才讲过的话不需要从头讲，可以接着对话。

第三，设计了对话面向开发者的方案，称之为 Open Dialog，背后有一个语言理解引擎和一个对话引擎。面向开发者的语言理解引擎是基于规则办法，能够比较好地解决冷启动的问题，开发者只需要写语言理解的 Grammar，基于对话描述语言开发一个对话过程，并且还有对数据的处理操作。这样，一个基本的人机对话就可以完成了。

阿里智能对话交互产品

智能服务——小蜜家族

2015 年 7 月，阿里巴巴推出了自己的智能服务助理——阿里小蜜，一个围绕着电子商务领域中的服务、导购，以及任务助理为核心的智能对话交互产品。通过电子商务领域与智能对话交互领域的结合，带来传统服务行业模式的变革与体验的提升。在 2016 年的「双十一」期间，阿里小蜜整体智能服务量达到 643 万，其中智能解决率达到 95%，智能服务在整个服务量 ( 总服务量= 智能服务量+ 在线人工服务量+ 电话服务量) 占比也达到 95%，成为了「双+ 十一」期间服务的绝对主力。阿里小蜜主要服务阿里国内业务和阿里国际化业务，国内业务如淘宝、天猫、飞猪、健康、闲鱼、菜鸟等，国际化业务如 Lazada、PayTM、AE 等。

随着阿里小蜜的成功，将智能服务能力赋能给阿里生态圈商家及阿里生态之外的企业和政府部门，便成了必然的路径。店小蜜主要赋能阿里生态中的商家，云小蜜则面向阿里之外的大中小企业、政府等。整个小蜜家族如图 18 所示。