本次分享是在 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 的特点是除了计算当前的对话,还会把上下文建模进来,重新考虑。比如情绪回复,如果是一个负向语句,如果单看这句话,它的回复可能是非常通用的,但是结合上下文,比如有的司机听不到单了,然后他会回复一些负面语句,这时我们的回复是针对听单场景的安抚。
除此之外,我们还有些离线的工作:
模型训练:如上图,为 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
评论 1 条评论