单轮问答

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

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

数据：标注数据少，这是 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 的特点是除了计算当前的对话，还会把上下文建模进来，重新考虑。比如情绪回复，如果是一个负向语句，如果单看这句话，它的回复可能是非常通用的，但是结合上下文，比如有的司机听不到单了，然后他会回复一些负面语句，这时我们的回复是针对听单场景的安抚。

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

模型训练：如上图，为 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等审稿人。多项智能客服领域技术专利发明人，专利覆盖多轮对话、问答、闲聊、智能预测等。

本文来自 DataFun 社区

原文链接：

https://mp.weixin.qq.com/s/MSy8OHzR3avObmOq9uSSFQ

创作场景

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