NLP_DataFun：

智能机器人在滴滴出行场景的技术探索

分享嘉宾：熊超 滴滴 AI Labs

编辑整理：Hoh Xil

内容来源：AI 科学前沿大会

出品社区：DataFun

注：欢迎转载，转载请注明出处

本次分享是在2019年 AI 科学前沿大会上的分享，主要介绍智能对话机器人在滴滴出行场景中的技术探索，主要内容为：

• 单轮问答

• 多轮对话

• 整体架构

▌单轮问答

单轮问答指识别用户问题，并给出相应答案。这种场景下的目标是做到识别准确，尽量理解用户问题，给出合适的答案。

开发过程中的难点和挑战：

• 数据：标注数据少，这是 NLP 领域的痛点问题，因为标注成本相对较高；

• 业务：业务线比较多，我们目前支持滴滴场景下的业务线有10多个，会导致数据标注的问题更突出，数据量少的业务，可标注的数据更少。

• 语言：用户的表达方式灵活多样，即同一个语义有多种表达方式。

针对上述问题，我们想了一些办法，分析了滴滴场景下和其他智能客服的区别，比如快车和专车业务线，都是由不同模型来支持的，但是快车和专车业务其实是非常相似的，经过统计分析，二者知识点重复率接近一半。我们考虑是否可以把大业务线的数据迁移到小的业务线，但是当我们细看数据的时候，发现还是不一样的，因为不同业务场景下的相似问，还是有区别的，比如业务独有的知识，不能直接用在其他业务线上。

为了解决这些问题，我们一直在想数据如何更好的去迁移，减少数据的标注量。提出了类似 Multi-Task 多任务学习的架构，因为我们有不同的业务线，如果不考虑 Multi-Task 结构的话，每个业务线会有一个模型。有了 Multi-Task 之后，可以多个业务线共享一个语义模型，让模型的泛化能力更强，为了解决不能直接映射的问题，每个业务线还有独立的模型在后面，优化各自的目标。语义模型可以有任意模型，我们尝试过 CNN、LSTM、Transformer、Bert 等。

上图为我们加上 Multi-Task 之后的一些实验结果，包括 CNN、LSTM、Transformer、Bert，其中，橙色和蓝色为 Top1 准确率，灰色和黄色为 Top3 准确率，橙色为模型本身的结果，蓝色为模型+Multi-Task 之后的结果，从结果上看，CNN+Multi-Task 后有一定的提升，从这一点上看 Multi-Task 还是有帮助的，进而我们做了更多的实验，比如 Bert+Multi-task 的 Top1 准确率相比于 CNN 有了显著的提升，在本身没有增加新的成本的情况下，提升显著，为什么加了 Multi-Task 后结果这么好呢？我们发现，新的模型特征抽取的能力比较强，但是也存在一些特点，需要足够的数据，才能让模型发挥出能力，我们看四个 Multi-task 模型对比（蓝色），给了充足的数据后，效果提升明显。效果好是不是因为模型好就可以了？也不是，其实如果单独业务线，同样的数据下，从图中不使用 Multi-task 模型结果（橙色）的对比可以看出 CNN 的效果反而更好。原因是在数据不充足的情况下，复杂的模型参数更多，容易引起过拟合。

除了分类的结构，我们也尝试了搜索+语义匹配+排序的架构，主要是用来做情绪安抚，思路是把候选的问答对语料，通过搜索、生成式模型得到候选，然后经过粗排，粗排是用文本相关性的分数来计算，最后交给多轮对话深度匹配模型，主要参考了去年这篇的论文：Modeling Multi-turn Conversation with Deep Utterance Aggregation ，DUA 的特点是除了计算当前的对话，还会把上下文建模进来，重新考虑。比如情绪回复，如果是一个负向语句，如果单看这句话，它的回复可能是非常通用的，但是结合上下文，比如有的司机听不到单了，然后他会回复一些负面语句，这时我们的回复是针对听单场景的安抚。

DUA：

原文聚焦的是基于检索式响应匹配多轮对话，研究如何更好的提取并利用先前对话中的关键信息，以及如何建模先前对话内容与响应之间的关系。原文以前的检索式多轮对话工作，都只是简单将对话语句内容连接起来，这样做有两个缺点：(1)忽略了前面语句之间的交互，(2)上下文是冗长和冗余的，相当于引入很多噪音。为了解决这些缺点，达成研究目的，原文作者提出了深度对话聚合(Deep Utterance Aggregation，DUA)，它将之前的对话内容组织成上下文，从而形成多个细粒度的上下文表示，然后将每一个细粒度的上下文表示对应一个响应进行匹配，最后经过多轮精细的聚合得到最终的匹配分数。原文的实验是在三个公开的对话数据集上进行的，其中包含了一个新的数据集--电商对话语料(E-commerce Dialogue Corpus，EDC)，三个数据集上都取得了SOA的性能。

《Modeling Multi-turn Conversation with Deep Utterance Aggregation》阅读笔记 论文原文：https://arxiv.org/pdf/1806.09102.pdf 刚看到小夕的这篇总结个人感觉讲的很好很容易理解，里面涉及了4篇论文串烧，按照时间讲了算法的发展，文风也蛮有趣（有点嗲，哈哈~） 上海交通大学等2018年发表的文章，主要涉及基于检索式的多伦问答模型，提出了一个深度对话整合模型（DUA），是针对多轮对话将过去会话直接拼接作为上下文信息存在噪声和冗余等问题，DUA从对话和回复中采用attention机制挖掘关键信息，凸显关键信息忽略冗余信息，最终获得utterances和response的匹配得分。本文还发布了一个电子商务对话语料库ECD，涉及到商品咨询、物流快递、推荐、谈判、聊天等，本文的数据集及代码。结构如下可分为5个模块： DUA的优点： 最后一轮对话很好的与前面对话结合，其最主要信息可以更好的用语义相关的方法来解决 每轮会话可以凸显关键信息，从一定程度上忽略冗余信息 计算最终匹配得分的时候充分考虑各轮对话之间的关系 Utterance Representation 采用GRU模型将每个utterance和候选response进行embedding。 Turns-aware Aggregation Utterance Representation是将utterance同等看待没有考虑the last utterance和之前对话之间的关系，该模块主要是将最后一个utterance（the last utterance）与context中的其他utterance以及候选response进行融合，论文中是直接将utterances和response的embedding串联起来，得到表征F。 Matching Attention Flow 该模块是对上一模块turns-aware的表征信息F信息进行处理，采用一个self-matching attention mechanism将冗余信息进行过滤，挖掘utterances和response中的显著特征，即通过一个attention机制的GRU进一步做表征的交互与融合。 [·,·] 是两个向量串联在一起 ,Ct是self-matching attention的输出 Response Matching 第四模块在单词和会话级别上对 response和each utterance进行匹配，经过CNN形成匹配向量。 这里从两个粒度进行匹配： 词粒度：u和r都是相应utterance和response中的某一个词，通过下式可以得到这两个句子相应位置上的匹配度。最后这些各个位置上词粒度的匹配度可以形成一个shape为(utterance长度，response长度)的矩阵M1 句子粒度：P是上一个模块中得到的utterance和response中各个位置上的表征，同样可以得到一个shape为(utterance长度，response长度)的矩阵M2 尔后分别在这两个矩阵上进行CNN卷积操作，得到卷积之后的表征。 最后进行max-pooling和flatten之后concatenation。 Attentive Turns Aggregation 将匹配向量按上下文话语的时间顺序传递GRU，得到utterance和response的最终匹配得分，分为三步： 第一步：先通过一个GRU； 第二步：attention机制； 第三步：加一个softmax，得到匹配度。 参考： 巷里野猫 https://www.paperweekly.site/papers/2352 https://zhuanlan.zhihu.com/p/44539292

除此之外，我们还有些离线的工作：

模型训练：如上图，为 Multi-Task 整体的一个效果，我们建立了一个每天模型自动更新的 pipeline，包括自动测试、自动上线。刚刚也提过了，数据很重要，我们会标注新的数据，来解决新的问题的出现，所以我们采用的是主动学习 Active Learning 的思想，去对边界样本进行采样，这样标注效率会更高，构建模型训练及在线服务的闭环，来达到每天模型更新的效果，让新的知识、新的问题，更快的更新到我们的服务上来。让机器人有了自我学习进化的能力。

数据标注：其实在现有的标注语料中，还存在噪音，准确率没有那么高。我们通过聚类的方式，把已经标注的语料聚类，这时有些样本是偏离聚类中心的，然后把偏离的样本通过人工检查，如果真的错了，就可以把噪音删除，如果是对的则保留。

▌多轮对话

在出行场景下，存在俩大类的问题，一类是咨询了问题，比如用户需要咨询一些政策、规则等信息；还有一类是寻求解决的，这两类问题，单轮问答都很难解决用户问题，为此我们提出了多轮对话。

1. 整体架构

我们可以看下这个例子，比如有乘客反馈，司机绕路，如果是单轮的话，只能给一个答案，而我们现在可以通过交互的方式来引导用户去选择订单，选择订单之后，我们可以直接调用后台的接口服务能力，去判断是否绕路了，如果真实存在，我们就会直接在机器人里把多收的费用返还给乘客，提升了用户体验。

具体的方法：将传统的多轮对话，多轮交互，引入滴滴客服机器人。主要包括几大模块：

① 语言理解

• 意图识别，知识点的识别，明确问的问题是什么

• 属性抽取，可以理解为选择订单，日期等等

② 对话管理

• 对话状态跟踪：结合当前语义理解的结果，并结合历史对话，上下文综合来看，得到对话的状态（Act 和 slot）

• 对话策略：给定对话状态，选择对应的动作，目前主要采用状态机的方式，并尝试强化学习对话策略

③ 语言生成

• 有了动作之后，我们就需要生成用户可以理解的语言。

以上是多轮对话的整体架构。

2. 语言理解

意图识别：

我们采用的模型为 BERT + Multi-Task Learning

槽位抽取：

我们主要是基于规则和模型结合的方法，如选订单的组件，模型如 BILSTM + CRF 模型， 来对槽位信息进行抽取。

3. 对话管理

这个刚刚有介绍过，右图为状态机，基于规则配置，左图为我们在研发的强化学习模型，它需要一个用户的模拟器来模拟用户，抽样用户目标，根据目标和机器人去交互，从交互中生成经验，再根据经验进行学习，达到自动学习的效果，而不是像右边状态机，是由领域内的专家来配置的。

4. 智能反问

如果用户表达的意图不清晰，无法精确定位问题的时候，我们采用了智能反问技术：

• 图谱查询：通过图谱去查询，得到相关联的知识点。

• 反问引导：产品形式上，在这个例子中，我们会引导用户，会问用户是实时单还是预约单，用户只要选择之后，会给用户推送一个更具体的、有针对性的答案。

5. 闲聊-寒暄

机器人里都会涉及到闲聊，比如“你好”，“谢谢”之类的。针对这些问题做的工作有：

分类模型、检索匹配等，专家编写的答案，现在我们在探索的是生成模型，让答案更灵活。

▌机器人架构

我们整体看下机器人的架构：用户的请求来了之后，将“查询”和“上下文”作为输入去查询 frontend，frontend 作为机器人的中控，也会包括一些业务逻辑，然后通过ranker模块做分发和选择，下面有问答型、任务型、多轮对话型、闲聊型、图谱型等，综合的做一个仲裁去选择，给到用户一个最终的答案。

最后讲一下智能客服的整体架构：

产品：我们支持的业务，包括智能客服（出租车、快车、专车等一系列业务）、司机助手、国际化客服等。

这就是我们整体的架构，这就是我今天要分享的内容，谢谢大家。

熊超，滴滴AI Labs 智能对话团队负责人。2010年毕业于北京航空航天大学模式识别与智能系统专业。毕业后加入腾讯从事搜索广告算法策略研发工作。2013年加入阿里巴巴从事智能人机交互方向。2017年加入滴滴，组建智能客服算法团队，主要研究方向为多轮对话，问答，智能辅助，强化学习和智能推荐。担任顶级期刊和学术会议，如TKDE，KDD等审稿人。多项智能客服领域技术专利发明人，专利覆盖多轮对话、问答、闲聊、智能预测等。

——END——

文章推荐：

阿里小蜜中的情绪回复能力

美团对话理解技术及实践

自然语言处理中的多任务学习

关于 DataFun：

DataFun 定位于最实用的数据智能平台，主要形式为线下的深度沙龙、线上的内容整理。希望将工业界专家在各自场景下的实践经验，通过 DataFun 的平台传播和扩散，对即将或已经开始相关尝试的同学有启发和借鉴。

DataFun 的愿景是：为大数据、人工智能从业者和爱好者打造一个分享、交流、学习、成长的平台，让数据科学领域的知识和经验更好的传播和落地产生价值。

DataFun 成立至今，已经成功在全国范围内举办数十场线下技术沙龙，有超过三百位的业内专家参与分享，聚集了数万大数据、算法相关领域从业者。

点下「在看」，给文章盖个戳吧！