分享嘉宾：江会星博士 美团
编辑整理：薛小辰 前苏宁易购
出品平台：DataFunTalk

导读： 客服是在用户服务体验不完美的时候，帮助体验顺畅进行下去的一种解决办法，是问题发生后的一种兜底方案。而智能客服是让大部分简单问题得以快速自助解决，让复杂问题有机会被人工高效解决。在用户服务全旅程中，我们提供问题推荐、问题理解、对话管理、答案供给、话术推荐和会话摘要六大智能客服核心能力，促进低成本、高效率和高质量的用户沟通。本文的主题是美团智能客服技术实践，主要内容包括：① 智能客服背景介绍；② 智能客服核心技术；③ 人工辅助核心技术；④ 小结与下一步计划。

01 智能客服背景介绍

美团是一家旨在“帮大家吃得更好，生活更好”的生活服务电子商务平台，通过联结消费者和商户，努力为消费者提供品质生活。在需求侧，美团为消费者提供了涵盖吃住行游购娱等服务，在供给侧，为合作商户提供了支撑发展的六大服务，包括营销、配送、IT、金融、供应链和经营，助力商户发展。

目前美团的年交易用户量为5.7亿，服务了710万生活服务类商家，有超过470万名外卖骑手，另在美团优选业务中还有一个很大的团长群体，平台涵盖吃住行游购娱等200多个生活服务品类，在平台服务的售前、售中、售后各个环节，都有大量信息咨询、订单状态获取以及申诉投诉等沟通诉求。另外作为一家拥有几万名员工的生活服务领域电子商务公司，员工之间亦有大量的沟通诉求。

1. 面对不同场景的智能客服落地

• 售前场景：比如消费者在平台选择入住酒店，对房型价格、酒店设施、入退房政策等，下单前是有很强的信息咨询诉求；
• 售中场景：比如外卖催单还没到，添加备注不要辣、加开发票等咨询，售前和售中场景主要发生在消费者和商家或平台之间；
• 售后场景：比如外卖场景投诉菜品少送、骑手送餐超时、要求退款等，酒店场景投诉酒店到店无法入住等，售后往往涉及到客服座席、消费者、骑手和商家多方协同解决；
• 办公场景：比如IT，HR，财务，法务等咨询，产运研对提供的接口产品的咨询答疑，产品对销售BD的答疑，以及BD对B端商家的答疑等。

2. 面对不同人群的智能客服落地

沟通是人类的一项基本需求，在绝大多数场景下对沟通的追求都是低成本、高效率和高质量的，这一块对话机器人是有可能同时满足这三点的。目前按照服务的群体分，智能客服落地场景大体可以分为四类:

• 面向用户：提供智能客服机器人，来帮助他们自助解决大部分问题;
• 面向座席：用话术推荐或者会话摘要等能力来提升人工座席的工作效率，改善人工座席的工作体验；
• 面向商家：打造商家助手来降低商家回复的费力度，改善消费者和商家沟通的体验；
• 面向员工：通过对话机器人，可以自助给员工答疑来提升办公效率。

3. 智能客服是什么

智能客服是什么？先看看客服是什么？我们的理解是客服是在用户的服务体验不完美的时候，来帮助体验顺畅进行下去的一种解决办法，是问题发生后的一种兜底方案。而智能客服是让大部分简单问题得以快速自助解决，让复杂问题有机会被人工高效解决。

这张图展示的是用户服务旅程。首先用户会通过在线打字或者拨打热线电话的方式进线寻求服务，其中在线咨询流量占比在85%以上。当用户进入到服务门户后，先是用户表达需求，然后是智能机器人响应需求，过程中机器人先要理解问题，比如是追加备注、或是修改地址，还是申请退款等等，继而机器人尝试自助解决，如果解决不了，再及时地流转到人工兜底服务。最后，当用户离开服务时，系统会发送调查问卷，期待用户对本次服务进行评价。

02 智能客服核心技术

1. 对话交互技术概述

智能客服背后的技术主要是以对话交互技术为核心。常见的对话任务可分为闲聊型、任务型和问答型：

• 闲聊型：通常是不关注某项特定任务，其主要的目标是和人进行开放领域的对话，关注点是生成流畅、合理且自然的回复；
• 任务型：通常是帮助用户完成某项任务指令，如查找酒店，查询订单状态，解决用户的退款申请等等。用户的需求通常比较复杂，需要通过多轮交互来不断收集任务所需的必要信息，进而根据信息进行决策，执行不同的动作，最终完成用户的指令；
• 问答型：侧重于一问一答，即直接根据用户的问题给出精准答案。问答型和任务型最本质的区别在于系统是否需要维护一个用户目标状态的表示和是否需要一个决策过程来完成任务。

技术实现上通常又可以划分为检索式、生成式和任务式：

• 检索式：主要思路是从对话语料库中找出与输入语句最匹配的回复，这些回复通常是预先存储的数据；
• 生成式：主要思路是基于深度学习的Encoder-Decoder架构，从大量语料中习得语言能力，根据问题内容及相关实时状态信息直接生成回答话术；
• 任务式：就是任务型对话，通常要维护一个对话状态，根据不同的对话状态决策下一步动作，是查询数据库还是回复用户等。

闲聊、问答、任务型对话本质都是在被动地响应用户需求。在具体业务中还会有问题推荐、商品推荐等来主动引导用户交互。在我们的业务场景里主要是任务型和问答型，中间也会穿插一些闲聊，闲聊主要是打招呼或者简单情绪安抚，起到润滑人机对话的作用。

如前面用户服务旅程所介绍，用户的沟通对象可能有两个，除了跟机器人沟通外，还可能跟人工沟通，如果是找客服场景人工就是客服座席，如果是找商家场景人工就是商家。机器人的能力主要包括问题推荐、问题理解、对话管理以及答案供给。目前衡量机器人能力好坏的核心输出指标是不满意度和转人工率，分别衡量问题解决的好坏，以及能帮人工处理多少问题。而在人工辅助方面，我们提供了话术推荐和会话摘要等能力，核心指标是ATT和ACW的降低，ATT是人工和用户的平均沟通时长，ACW是人工沟通后的其它处理时长。

2. 智能机器人——多轮对话

接下来先重点介绍一下多轮对话能力即问题理解和对话管理这两部分，然后再介绍其他类型能力。

先看一个真实的多轮对话的例子，当用户进入到服务门户后，先选择了一个推荐的问题“如何联系骑手”，机器人给出了联系方式致电骑手，同时为了进一步厘清场景，询问用户是否收到了餐品，当用户选择“还没有收到”的时候，结合预计送达时间和当前时间，发现还未超时，给出的方案是帮用户催一下，或者是用户再等一等，这时候我们用户选择了等一等。

这个例子背后的机器人是怎么工作的呢？首先当用户输入“如何联系骑手”的时候，问题理解模块将它与知识库中的拓展问进行匹配，进而得到对应的标准问即意图“如何联系骑手”，然后对话管理模块根据意图“如何联系骑手”触发相应的任务流程，先查询订单接口，获取骑手电话号码，进而输出对话状态给到答案生成模块，根据模板生成最终结果，如右边的红框内容所示。这个过程中涉及到要先有意图体系、定义好Task流程，以及订单的查询接口，这些都是业务强相关的，主要由各业务的运营团队来维护。那么对话系统要做的是什么呢？一是将用户的输入与意图体系中的标准问进行匹配，二是完成多轮交互里面的调度。

问题理解是将用户问题与意图体系进行匹配，匹配到的拓展问所对应的标准问即用户意图。机器人的工作过程实际是要做召回和精排两件事情。召回更多地是用现有检索引擎实现，技术上更多地关注在精排。美团自研智能客服系统是从18年开始搭建到现在，过程中我们不断地将业界最先进的技术引入到我们的这个任务中来，同时根据美团业务的特点，以及问题理解这个任务的特点，对这些技术进行适配，比如说当2018年底BERT出现的时候，我们很快全量使用BERT替换原来的DSSM模型，后面又根据美团客服对话的特点，我们将BERT进行了二次训练及在线学习改造，同时为了避免业务之间的干扰，以及通过增加知识区分性降低噪音的干扰，我们还做了多任务学习(各业务在上层为独立任务)以及多域学习(Query与拓展问匹配，改为与拓展问、标准问和答案的整体匹配)，最终我们的模型为Online Learning based Multi-task Multi-Field RoBERTa。经过这样一系列技术迭代，我们的识别准确率也从最初不到80%到现在接近90%的水平。

理解了用户意图后，有些问题是可以直接给出答案解决的，而有些问题则需要进一步厘清，比如说“如何申请餐损”这个例子，不是直接告诉申请的方法，而是先厘清是哪一个订单，是否影响食用，进而厘清一些用户的诉求是部分退款还是想安排补送，从而给出不同的解决方案。这样的一个流程是业务强相关的，需要由业务的运营团队来定义。如右边任务流程树所示，我们提供了可视化的TaskFlow编辑工具，并且把外呼、地图以及API等都组件化，我们的业务运营人员可以通过拖拽的方式来完成Task流程设计。

对话引擎在与用户的真实交互中，要完成Task内各步骤的匹配调度。比如这个例子里用户如果不是点选”可以但影响就餐了…”这条，而是自己输入说“还行，我要部分退款”，怎么办？这个意图也没有提前定义，这就需要我们的对话引擎支持Task内各步骤的模糊匹配。我们基于Bayes Network搭建的TaskFlow Engine恰好能支持规则和概率的结合， 这里的模糊匹配算法复用了问题理解模型的语义匹配能力。

我们再来看一个例子，在用户问完“会员能否退订”后，机器人回复的是“无法退回”，虽然回答了这个问题，但这个时候用户很容易不满意，转而去寻找人工服务。如果这个时候我们除了给出答案外，还去厘清问题背后的真实原因，引导询问用户是“外卖红包无法使用”或者是“因换绑手机导致的问题”，基于顺承关系建模，用户大概率是这些情况，用户很有可能会选择，从而会话可以进一步进行并给出更精细的解决方案，也避免了用户直接转人工服务。

这个引导任务我们叫做多轮话题引导，具体做法是对会话日志中的事件共现关系以及顺承关系进行建模。如右边图所示，这里原本是要建模句子级之间的引导，考虑到句子稀疏性，我们是将其抽象到事件之间的引导，共现关系我们用的是经典的协同过滤方式建模，另外考虑到事件之间的方向性，对事件之间的顺承关系进行建模：

并通过多目标学习，同时考虑点击指标和任务指标，如在非转人工客服数据和非不满意数据上分别建模顺承关系：

最终在点击率、不满意度、转人工率上都有非常正向的收益。

美团平台涵盖吃住行游购娱等200多个生活服务品类，当用户是从美团App或点评App等综合服务门户入口进入服务时，需要先行确定用户要咨询的是哪个业务，这里的一个任务是“判断用户query是属于哪个业务”，该任务我们叫做领域识别。若能明确判断领域时则直接用该领域知识来解答，当不能明确判断时则还需要多轮对话交互与用户进行澄清。比如用户输入“我要退款”，多个业务里都存在退款意图，这个时候就需要我们先判断是哪个业务的退款意图，如果判断置信度不高，则给出业务列表让用户自行选择来澄清。

领域识别模型主要是对三类数据建模：各领域知识库的有标数据、各领域大量弱监督无标数据和个性化数据。

① 依据从各领域知识库的有标数据中学习得到的问题理解模型信号，可以判断用户输入属于各业务各意图的可能性；

② 我们注意到除了美团App、点评App等综合服务入口涉及多个业务外，还有大量能够明确业务的入口，比如说订单入口，从商品详情页进来的入口，这些入口进来的对话数据是有明确业务标签信息的，因此我们可以得到大量的弱监督的各业务领域的数据，基于这些数据我们可以训练一个一级分类模型；

③ 同时有些问题是需要结合用户订单状态等个性化数据才能进一步明确的，比如“我要退款”，多个业务里都会有，因此又要结合用户状态特征一起来训练一个二级模型，最终来判断用户的输入属于哪个业务。

该二级领域识别模型最终在满意度、转人工率以及成功转接率指标上都有非常不错的收益。

3. 智能机器人——问题推荐

介绍完多轮对话基础模块问题理解和对话管理后，接下来介绍一下智能机器人的另外两个模块问题推荐和答案供给。如前面多轮对话的例子所示，用户进入服务门户后，机器人首先是要如何引导用户精准地表达需求，这样即可降低用户迷失或者直接转人工服务，也降低了若机器人不能正确理解时带来的多轮澄清等无效交互。

该问题是一个标准的曝光点击问题，其本质是推荐问题，我们采用了CTR预估任务经典的FM模型来作为基础模型，同时结合业务目标，期望用户点击的问题的解决方案能够解决用户问题，该问题最终定义为“曝光、点击、解决”问题，最终的模型是结合多目标学习的ESSM-FM，其对有效交互的转化率、转人工率和不满意度等指标上都带来了提升。

4. 智能机器人——答案供给

售后客服场景通常问题较集中且问题的解决多依赖业务内部系统数据及规则，通常是业务部门维护知识库，包括意图体系、Task流程和答案等。但在售前场景，知识多来自于商户或商品本身、用户体验及评价信息等，具有用户问题开放、知识密度高、人工难以整理答案等特点。比如去哪个城市哪个景点游玩，附近有哪些酒店，酒店是否有浴缸，酒店地址在哪里等，都需要咨询”决策”，针对这些诉求我们通过智能问答来解决咨询以及答案供给问题。

智能问答就是从美团数据中习得答案供给，来快速回答用户的问题，基于不同的数据源，我们建设了不同的问答技术。

针对商家基础信息，比如问营业时间、地址、价格等，我们通过图谱问答(KBQA)来解决。利用商家基础信息构建图谱，通过问题理解模型来理解问题，进而查询图谱获取准确的答案；

针对社区数据，即商户详情页中“问大家”模块的用户问用户答的社区数据，构建社区问答(Community QA)能力，通过对用户问题与问大家中的”问答对”的相似度建模，选择相似度最高的作为答案，来回答用户的一些开放性问题；

针对UGC评论数据以及商户政策等无结构化数据，构建文档问答(Document QA)能力，针对用户问题利用机器阅读理解技术从文档中抽取答案，类似我们小时候语文考试中的阅读理解题，进一步回答用户的一些开放性问题。

最后针对多个问答模块给出的答案，进行多答案来源的答案融合排序，来挑选最终的答案，此外这里还考察了答案真实性，即对“相信多数认为正确的则正确”建模。这部分的详细介绍请参考“美团智能问答技术探索与实践”一文。

03 人工辅助核心技术

1. 人工辅助——话术推荐

前面介绍的都是智能机器人技术，用户除了跟机器人沟通外，还可能是跟人工沟通。我们在客服座席职场调研过程中发现，座席在与用户的对话聊天中经常回复相似甚至相同的话术，一致期望提供话术推荐的能力来提高效率。此外，除了请求客服座席帮助外，很多情况下用户与商家直接沟通会使得解决问题更高效，而沟通效率不仅影响到消费者的体验，也影响到了商家的经营。比如在外卖业务中，消费者的下单率和商家的回复时长有较为明显的反比关系，无论是客服座席还是商家，都有很强的话术推荐诉求。

那么，话术推荐具体要怎么做？常见的做法是先准备好常用通用话术库，部分座席或商家也会准备个人常见话术库，然后系统根据用户的Query及上下文来检索最合适的话术来推荐。根据调查发现，这部分知识库维护的很不好，既有业务知识变更频繁导致已维护的知识很快不可用因素，也有座席或商家本身意愿不强的因素等，另外针对新客服座席或者新商家，可用的经验更少。因此我们采用了自动记忆每个座席及其同技能组的历史聊天话术，商家及其同品类商家的历史聊天话术，根据当前输入及上下文，预测接下来可能的回复话术，无需人工整理。

我们将历史聊天记录构建成“N+1”QA问答对的形式建模，前N句看作问题Q，后1句作为回复话术A，整个框架就可以转化成检索式的问答模型。召回阶段，除了文本信息召回外，我们还加入了上文多轮槽位标签，Topic标签等召回优化，排序为基于BERT的模型，加入角色信息建模，角色为用户、商家或者座席。整个架构如图所示，分为离线和在线两部分。另外上线后我们也加入了一层CTR预估模型来提升采纳率。当前多个业务的话术推荐平均采纳率在24%左右，覆盖率在85%左右。话术推荐特别是对新座席员工价值更大，新员工通常难以组织话术，通过采纳推荐的话术可以来缩减熟练周期，观测发现3个月内座席员工的平均采纳率是3个月以上座席员工的3倍。

2. 人工辅助——会话摘要

在客服场景座席跟用户沟通完后还需要对一些必要信息进行工单纪要，包括是什么事件，事件发生的背景是什么，用户的诉求是什么，最后的处理结果是什么等等，填写这些内容对座席来说其实是很不友好，通常需进行总结归纳，特别是有些沟通进行的时间还比较长，需要来回翻看对话历史才能正确总结。另外为了持续对于服务产品进行改善，也需要对会话日志进行相应事件抽取及打上标签，方便经营分析。

这里有些问题是选择题，有些问题是填空题，比如这通会话具体聊的是哪个事件，我们提前整理有比较完整的事件体系，可以看成是个选择题，可以用分类或者语义相似度计算模型来解决；又比如说事件发生的背景，如外卖退款的背景是因餐撒了、酒店退款的背景是到店没有房间等，是个开放性问题，分析发现可以很好地从对话内容中抽取，可以用摘要抽取模型来解决；而对于处理结果，不仅仅依赖对话内容，还包括是否外呼，外呼了是否商家接通了，后续是否需要回访等等，我们实验发现生成模型更有效。具体使用的模型如图所示，这里事件选择考虑到经常有新事件的添加，我们转成了双塔的相似度计算任务，背景抽取采用的是BERT-Sum模型，处理结果采用的是谷歌的PEGASUS模型。

04 小结与下一步计划

1. 小结——交互立方

前面介绍了我们在美团智能客服实践中的一些核心技术，过程中也穿插着介绍了客服座席与消费者/商家/骑手/团长等之间的沟通提效，以及消费者与商家之间的沟通提效，除了这两部分之外，在企业办公场景，其实还有员工之间、销售BD与商家之间的大量沟通，如果一个个去做，成本高且效率低，我们考虑是把智能客服中沉淀的能力进行平台化，一揽子解决，以固定成本来支持更多的业务需求。于是我们搭建了美团的对话平台-摩西对话平台，用一揽子方案以固定成本来解决各业务的智能客服需求。

2. 小结——对话平台“摩西”

构建一个怎么样的对话平台才能提供期望的没有NLP能力的团队也能拥有很好的机器人呢？

首先是把对话能力工具化和流程化，如图所示，我们把系统大概分为了四层，应用场景层、解决方案层、对话能力层、平台功能层：

• 应用场景层：在售前应用场景，一类需求是商家助手，如图中所列的闪购IM助手和到综IM助手，需要辅助商家输入和机器人部分接管高频问题能力；还有一类需求是在没有商家IM的场景需要智能问答来填补咨询空缺，比如图中所列的酒店问一问和景点问答搜索；另外售中、售后以及企业办公场景，各自需求也不尽相同；
• 解决方案层：这就要求我们有几套解决方案，大概可以分为智能机器人、智能问答、商家辅助、座席辅助等。每个解决方案的对话能力要求也有所不同，这些解决方案是需要很方便地对基础对话能力进行组装，对使用方是透明的，拿来即用；
• 对话能力层：前面也进行了相应的介绍，六大核心能力包括问题推荐、问题理解、对话管理、答案供给、话术推荐和会话摘要；
• 平台功能层：此外我们需要提供配套的运营能力，提供给业务方的运营人员来日常维护知识库，数据分析等等。

其次，提供一篮子的解决方案，还需要针对处在不同阶段的业务提供不同阶段的解决方案：

• 有些业务他只希望维护好常用的问答对来回答高频的问题就好，那么他们只需要维护一个入门级的机器人，只需要在意图管理模块来维护它的意图，意图的常见说法以及答案就可以了；
• 而对于有运营资源的团队，他们希望不断地去丰富知识库来提升问答能力，这个时候可以使用知识发现模块，可以自动地从每日日志里面发现新意图及意图的新说法，运营人员只需要每日花一点时间来确认添加及维护答案即可，这是一个进阶的业务方；
• 还有一些高级的业务方希望调用他们业务中的API来完成复杂问题的求解。这个时候他们可以使用TaskFlow编辑引擎，在平台上直接注册业务的API，通过可视化拖拽的方式来完成Task编辑。

此外， 为了进一步方便更多的业务介入，我们也提供了一些闲聊、通用指令、地区查询等官方技能包，业务方可以直接勾选使用。另外随着我们不断在业务中沉淀，也会有越来越多的官方行业技能包。方向上是逐步让业务使用的门槛越来越低。

3. 下一步计划

我们当前使用的对话系统，是Pipeline的，按照功能划分为不同的模块，各个模块单独建模，依次串联。这种方式的好处是可以做到不同团队职责的有效分工，比如研发同学专注于建设好问题推荐模型、问题理解模型和Task引擎等，业务运营同学专注于意图体系维护、Task流程设计以及答案设计等等。它的劣势也很明显，模块耦合，误差累积，很难联合优化，进而各模块负责的同学可能会去修修补补，容易导致动作变形。

另一类建模方式是End-to-End，将Pipeline式对话系统的各个模块联合建模成一个模型，直接实现语言到语言的转变，此类方法最初应用在闲聊式对话系统里面，近期随着大规模预训练模型的快速发展，学术上也逐渐开始研究基于预训练模型的端到端任务型对话系统。其优点是模型可以充分利用无监督人人会话，用数据驱动可以快速迭代；缺点是模型的可控性差，不易解释且缺乏干预能力。目前主要以学术研究为主，未见成熟的应用案例。

除了使用这种大量无监督的人人会话日志外，还有一种思路是基于Rule-Based TaskFlow构建规则的用户模拟器，进行交互以生成大量的对话数据，进而训练对话模型。为了保证对话系统的鲁棒性，也可使用类似对抗攻击的方法优化，可以模拟Hard User的行为，不按顺序执行TaskFlow，随机打断、跳转某个对话节点等等。

此外，通过对比分析人机对话日志和人人对话日志，人机对话比较僵硬死板，无法有效捕捉用户的情绪，而人工就很擅长这方面。这在客服场景非常重要，用户往往进来就是带着负面情绪的，机器人需要有共情能力。

这里提到的端到端数据驱动的对话和对话共情能力建设，将是接下来一段时间我们尝试的重点方向。

分享嘉宾：