应用背景

目前在对话机器人领域，开放域的闲聊型对话技术不成熟，基本算是”人工智障“；

而在封闭域，单纯的任务型对话脱离场景落地困难，难以取代GUI当前的地位，基本算是”可以用但没必要“。
但在客服领域，由于客服场景本身就是对话，且存在大量重复性的工作，客服机器人在落地方面具有明显的可执行性。目前是对话机器人商业化最佳的场景，是非常明确的“能够赚钱”的细分领域。

市场情况

报告截图

上一波客服产业变革是云服务带来的，大约在2014年前后发生；属于存量市场争夺（零和博弈），云客服与传统厂商进行竞争；

而这一波客服产业的变革是AI带来的，大约在2016年左右，这一波变革不仅存在存量的替代过程，还存在对客服产业的改造：替代人工；在激烈竞争的同时，盘子也大了。根据智能客服厂商给出的数据，客服机器人正在以40-50%的比例替代人工客服工作。

bot机器人公司的最终目标虽然是取代人工，但从技术发展以及业务可控的角度来讲，辅助人工完成对用户的服务可能是当下相当主要的方式，直至bot能够完美解决用户需求，甚至基于企业数据通过智能的手段带来更多的业绩。在前往最终目标上，会遇到实际的业务阻碍，了解这些解决方案帮助我们认知产业现状

智能客服在做什么？

当下能用AI解决的问题，一定属于重复性、规律性的问题；客服领域正是因为有相当一部分工作具有这种特性，所以这些重复性工作都是什么呢？AI如何替代这些任务？替代过程中会遇到什么问题？

一个合格的客服人员应该具备以下能力
1、当用户发起会话时，明白用户要干什么，意图不清晰时通过追问明确意图
2、明确用户意图后，根据用户意图进行回复、或者采取业务行动；这些依赖于岗位培训知识
3、业务隔三差五的变更，业务知识也随着变更。对用户的回复也会变更
4、用户可能带有不满情绪，或者当前无法给予满意答复，如何安抚用户情绪

所以对于一个智能bot来讲，处理任何业务理应具有上述客户服务能力；
1.bot可以通过NLU判断用户意图，能在在业务发展中不断丰富
2.bot通过复杂的DM管理，完成用户的业务需求和信息获取；这个过程可能需要知识库
3.DM模块中的业务逻辑以及知识库需要可以更新，便于维护
4.bot需要一些话术逻辑带给用户拟人体验

当下智能客服在业务上需要可解释性所以基本上应用AI技术的偏向于识别部分，而非策略，类似任务型对话，客服bot策略部分都会人工设计的（状态、流程）。DM会根据目前的状态，将不同的意图交于不同的模块进行处理

智能客服架构（网络截图）

对用户进行NLU解析后，经过一个bot路由；判断该意图应该由哪个bot去处理；
由于用户意图的不同，所进行的业务处理也不同，有的只需要在QA中寻找答案，比如询问七夕活动开始时间。有的需要对数据库进行查询，比如快递到哪儿了；有的需要执行业务，比如帮我进行维修预约；有的需要寒暄，比如用户言语激烈，需要安抚等等；

这些不同场景的任务由于实现逻辑不同，从而产生了不同的bot；上述例子中可以反应客服场景中常见的几类bot：

1、咨询
用户希望通过机器人获取某种信息/答案；可能来源于QA，也可能来源于知识库；
2、任务
用户希望客服人员帮助处理一些产品、业务上的操作
3、寒暄
bot通过寒暄显得人性化，平复用户一些情绪问题

在客服场景中，场景虽然比较复杂，但是最常见的仍然是咨询类的；接下来主要了解咨询类的业务场景与实现方式

资讯类场景

通过FQA检索解决常见热门问题

FQAbot

首先建立语FQA语料库

问答对数据集呈现结构化 【问题】-【答案】的形式；为了解决多种问法，平台都会提供相似问题的功能。满足用户问题到具体QA的映射；

网易七鱼截图示例

检索

检索式实现就是基于用户的问题可以在语料库的问题中找到近似的问题，那么该答案可以作为给用户回答

检索回答机理

通过Q-Q的相似性，我们能够初步筛选出一部分可能正确的问答对出来；

这一步的筛选比较粗，通过简单的关键词命中、词频即可。

初步召回有利于减少后续计算成本，往往在搜索引擎中使用；在对话机器人中主要看计算量使用；

匹配重排

通过初步召回的问答对仅仅是有可能是用户的问题，我们还需要进一步的特征处理，进行重新排序。通过算法刻画问句之间的相似度，比如余弦相似度、word2vec、IFIDF等。可能是句子级别的相似或者语义级别的相似，还有使用深度学习进行特征提取，比较向量的相似度等等；

通过模型计算后进行排序，通常取top1的问题回答作为回复；

匹配方面还有一些别的思路是不仅匹配问题（Q-Qmatch），还会对回答进行匹配

（Q-Amatch），加上对回答的匹配可能有更好的效果。

通过KBQA回答一些事实型问题

KBQA-bot

对于用户类似【我的理财产品最近一笔回款什么时候】【xxx产品目前有什么颜色】这种事实类的请求，需要对意图解析后转化为查询语句进行知识库查询，然后将查询结果通过模板回复。
技术细节：https://zhuanlan.zhihu.com/p/25735572

追一科技截图示例

Q【南方品质混合通赎回要多久才返还银行卡?】

通过意图识别与实体抽取将Q映射为结构化数据 [基金][赎回到账时间]；然后到数据库进行查询；再将查询结果返回给用户 【赎回到账时间为T+4】

通过意图槽解决一些需要逻辑判断的问题

还有一类问题需要进行多轮对话明确意图才能给用户答复，与FQA与KBQA结合使用给予用户答复；

1、有的是通过状态机的方式进行处理，即通过状态流程图进行判断（如网易七鱼的一触即达）；易于构建但是维护成本高

基于状态机的知识库维护

2、也可以用任务型对话中槽填充的方式进行处理，可以将待确定信息作为槽位；这种对话管理不用关注状态顺序，而且易于维护；具体可参考基于规则的Task-DM系统

这类存在逻辑判断的对话的构建与业务比较耦合，实际上很多客服对话都属于这类问题，客服初步理解用户意图后还需要跟用户确认更多信息从而给予用户答复。
直觉上感觉能够构建好多轮咨询bot以及与业务相关的任务bot是智能客服的关键竞争点，否则替代客服是无从谈起的。这方面的发展也是看到AI产品大本营中团员的分享，对话与业务的整合在各大平台似乎并没有成熟。

匹配度不高时的解决方案

当用户意图经过意图路由解析，我们需要进行bot分配；这种分配通常根据匹配的置信度来判断，当某个问答/任务置信度高于某个值时，直接命中，低于某个值时，直接匹配到兜底话术上。如果置信度在某个区间，意味着我们对该意图的匹配项没有把握，可以将前几个（比如TOP5）返回，让用户进行选择；示例：

网易七鱼截图

知识库的获取与维护

知识获取

未上线前我们的数据基本来自于客服/业务人员手动构建或者来自存量数据进行清洗；但是随着业务的发展，知识可能存在删除或者替换以及新增；

通过阅读理解工具抓取零散的文本，经过工具处理后转化为结构化的知识

知识维护

1、对于知识删除，bot平台都有过期功能，应对一些具有时效性的QA

网易七鱼截图

2、在业务人员构建时，往往可能会产生一些重复的知识，我们需要对其进行整理合并，提高识别率

保持回复的一致性

网易七鱼截图

3、通过日志，我们可以发现同一个问题的其他表述

网易七鱼截图

4、我们未曾考虑到的问题进行聚类从而可以进行业务补充

网易七鱼截图

5、对于我们设置的问答，需要进行业务完成统计，以明确是否存在问题；发现问题后可以对问答进行调整

网易七鱼截图

6、所以说，知识库是处于不断的更新学习中的，需要在功能上提供对应的发现、统计、纠错等工具

云小蜜知识库维护

感性化

当用户与bot沟通时，如果bot明显给人一种机械式无感情的回复会用户产生不信任感，大家自己体验就能感受到，特别是在客服沟通这件事儿上，用户很有可能是带着情绪过来的，这种情况下bot一旦犯错，会令用户失去沟通欲望。所以我们在bot设计上需要加入感性化的设计去加以影响

话术简洁

话术表达需要进行精简，突出重点；长文本可以分步表达

通过富文本方式满足多样化的表达

溢出的信息可以通过外置链接跳转查看

话术友好

就像客服岗位培训，我们同样需要对bot作出一定的要求，在客服领域，感受是重要的影响因素

AI产品大本营文章截图

多答案

在对用户进行回复时，我们应该整理多个回复话术进行答复，多样性回复避免死板的印象，比如槽填充场景。

转人工

1、当用户的问题bot解决不了时（可能是业务考虑不周到、或者这个问题本身就难以解决），可能需要提示用户转人工

2、当用户情绪非常激动时，通过情绪分类器，可以将用户转由人工接手进行安抚。