智能客服解决方案（智能客服求助）

本文目录一览：

• 1、智能客服助理是什么？为什么未来客服一定会用到智能客服辅助系统？

• 2、软通动力的“ECHO”智能客服解决方案，大致具备哪些功能？

• 3、智能客服结构-v1.0

• 4、在线客服技术的解决方案

智能客服助理是什么？为什么未来客服一定会用到智能客服辅助系统？

客知音推出的智能客服助理辅助系统便是针对人类各种局限性,为客服代表提供人工智能解决方案。

1.CRM数据准确和完整的收入

用户画像,即CRM系统,是市场和销售的基础。公司做出产品内容推荐、广告投放、客户关怀等,客户画像都是数据支撑。

客知音智能客服助理的方法是,只要对话中提到了客户画像的字段,销冠AI教练通过自动语音转文字,把重要的信息提取出来,保证CRM数据准确完整。

2.问题扼杀在摇篮——实时语音质检

现金大部分的呼叫中心都有离线的质检模块。但离线质检的问题是其滞后性,错误已经酿成,客户很有可能已经离开了我们。

所以客知音智能客服助手给出的解决方法是,在实时电话过程中,问题刚露出一点苗头的时候,界面自动提醒客服人员,把错误扼杀在摇篮里,或者实时地通知呼叫中心质检人员,避免问题的扩大化。

3.话术提醒，完美回答问题

除了实时的质检模块以外,智能客服助手还能自动提供正确的问题回答,免去了不断翻找资料的手忙脚乱,也缩短了新人熟悉业务的培训时间。

4.思路导航防止无效混乱的对话

真实的场景中,客服代表打电话时可能发现和客户聊了很多却没有把握关键的点,或者思维跳转太快而显得生硬,对话不流畅。

智能客服辅助系统的屏幕上会提供思路导航,即聊天的话题顺序。所以每聊到一个话题的时候,我们会通过NLP语意理解的引擎在任务列表中自动划掉。这样没有说到的点也会一目了然,有效地解决了说话思路混乱的问题。

5.客户购买意愿计算准确超过真人

销冠实时计算的客户购买意愿不但能提示客服代表采取什么样的话术,也是后期客户分类的重要数据指标。

这是怎么算出来的呢?我们会利用大数据分析数百万通的历史电话录音和是否购买的记录。同时分析通话的时长、听说比例、对话的内容,通过语意理解,我们去做一个大数据模型。最后算出来的购买意愿在统计意义上,比真人客服代表的评测更加准确。

智能客服助理会根据上下文,比如客户提到了某个问题,或是聊天聊到了某个阶段,自动给出最有利于转化的话术,同时还贴心地把答案分成小点,给予客服更清楚的提示。

软通动力的“ECHO”智能客服解决方案，大致具备哪些功能？

软通动力的“ECHO”智能客服解决方案集合了在线客服、呼叫中心、智能机器人、人工系统、报表监控等功能于一体，可下沉各个行业，服务于多个业务场景和用户渠道，智能驱动每一个服务环节，为企业实现互联网转型及升级。所运用到的人工智能技术机器人、智能质检、智能语音交互等功能为企业的发展注入强劲动力，企业可借助ECHO令自身服务营销升级。

智能客服结构-v1.0

前言 ：这篇文章仅对客服机器人这种偏任务导向型机器人架构的探究，文章中部分是已经得到验证的经验，部分是经历了行业无数竞品的对比中针对面临的问题重构出的产品结构。我一直坚持“对话机器人的对话结构是一个产品策略”的观点，所以这篇文章更偏向于针对电商（笔者是电商垂直行业）智能客服对话机器人（文中简称智能客服）中的用户现象的产品策略问题，有不足之处欢迎各位产品与技术大佬们指导。

一、目录概述

内容主要分为整体结构与常见问题两个角度的探究。因用户在智能客服中的表现的多样性，故不穷举赘述，在每个解决方案与架构设置原因中针对单独问题一一探究。

二、智能客服主要解决的问题

客服主要解决用户Q（query）→A（answer）问题，好的资深客服对业务逻辑结构更了解，不仅能基于用户未完全形容时推断用户情况、根据用户情况给予更多的业务解决方案，更能在对话中判断用户的倾向性（情感、期望值等）。

那智能客服如何像客服一样解决问题呢。下面引入三个概念

图1 用户问法，业务逻辑结构，业务解决方案关系图

名词解释：

[if !supportLists]Ø  [endif] 业务逻辑结构（因笔者对知识图谱理解太浅，固用此名字代替） ：面向用户的业务类型，多呈现树状结构，如售后，售后-退货，售后-退货-运费等的二叉树结构；某个子业务的判断条件，如常见电商的退货条件为七天。

注 ：为什么将判断条件放在业务逻辑结构中，后续会讲到的用户问法中会将某一判断条件作为意图放在会话中。如“我要退货”的处理方式需要判断用户订单是否超过七天，用户的延伸问法“我的订单刚买两天，想退货”，此问题在理解中属于重难点解决问题。

[if !supportLists]Ø  [endif] 业务解决方案 ：通常针对于某一业务会延伸出多样化的子业务，如：“我要退货”“退货用什么快递”“退货的运费谁承担”，通常对于一问题会有至少1+的解决方案（公司能提供的解决方案多少问题根据公司能力决定不在此讨论）。

[if !supportLists]Ø  [endif] 用户问法 ：自然语言中的现象结合某一子业务产生的问法类型不用，如：“定义类——什么是七天无理由退货”“满足类——我的订单支持七天无理由退货吗”等。

解决智能客服问题应答用户问题主要解决 两个问题 ：

1.解决用户问法在业务逻辑结构（知识图谱）中的位置问题。

2.解决用户问法+业务逻辑结构=用户解决方案问题。

三、

针对于上面我们提到的智能客服主要解决的问题，笔者提供两种 解题思路 ：

[if !supportLists]1.    [endif]分类业务类型，将业务类型中的问题用QA的方式维护，对用户问题中的子串（去无用词“吗”“好的”等）用检索重排序的方法分别在增加的Q中和A中进行筛选，最终筛选出阈值最高的一条Q或者A，以此条答案为回复用户问题的答案。当然，中间有不少稳定准确率与召回率的兜底方案，可根据实际情况调控。此方法的好处在于稳定，不过更像解决搜索问题而不是解决对话机器人问题。

2.第二种方案是本篇主要讲的方案，引用三角兽科技CEO 王卓然博士《任务驱动多轮对话评测标准【人机对话评测系列之一】》中的图为例。（文末会有此篇文章的链接）

图2: 任务驱动的多轮对话系统的一个经典框图

主要把智能客服对话结构为三部分：意图理解NLU（用户目的分类和Spoken Language Understanding）、对话状态（Dialogue State）、应答（System Action）。图中ASR（语音识别）、NLG（答案生成）、TTS（文语）模块因并非提升智能客服主要的体验问题，并且笔者未深入研究，故此篇文章不深入探讨，后续了解后会针对这些问题单独讲述。

三、智能客服与业务结合基础

3.1 把业务教给智能客服

上文中提到，要解决用户问题，必须让对话系统模拟业务的真实状况，所以梳理业务逻辑结构非常重要。

拆分业务逻辑主要为三点原则：

[if !supportLists]²  [endif]用户通常有哪些目的（能提供的业务有哪些）

[if !supportLists]²  [endif]这些目的之间有没有关联性（不包含会话中易出现的关联性）

[if !supportLists]²  [endif]哪些信息（条件）是实现目的的必要因素

待探究问题：有没有清晰的拆解规则同时满足NLU的准确性与业务的完整性？此规则能否通用？

拆分完业务逻辑结构，更重要的是把业务逻辑结构教给智能客服。基于拆分的三点原则，我们要教给智能客服的为两点：

[if !supportLists]²  [endif]有哪些意图（intent）或分类—自然语言理解的分类问题。

[if !supportLists]²  [endif]哪些是实现意图的必要条件—结构化识别与多轮对话问题。

3.2 理解用户在对话中的目的

在对话系统中，自然语言中的query会呈现结构化的语义表示，这个结构化的语义通常被称作dialogue act由 communicative function 和 slot-value pairs 组成，其中 communicative function 表示 query 的类型（如：陈述需求，询问属性，否定，选择疑问，等等）而每个 slot-value pair 则表达一个限制条件（constraint），也可理解为用户目标的一个组成单元。

例如“我的订单到上海了吗”对应的dialogue act可以表示为inform（entity=订单or物流，location=上海）。这里的inform就是communicative function，表示询问查询，“entity=订单or物流“和“location=上海”是限制条件（slot-value pair）

四、智能客服架构

3.3 意图识别NLU

此处的意图识别NLU，单指 对用户标准问法(用户一句话把问题描述清楚)的理解与分类 和对话系统中的 口语处理问题 。

由于用户在对话系统中输入时更偏向与口语化的表述，所以在对话系统的意图识别板块，我们更关注口语处理，其中包含了对非严谨语法（即用户问题可能产生的语法错误纠错与错别字接错）和识别中如何保持准确的鲁棒问题。

为什么一定要将用户语义（dialogue act）作 结构化识别 ，主要是解决用户将条件加在会话中陈述的导致容易造成智能客服理解混淆问题（例如上文提到的我收货两天了能不能退货）。

当然，我们也可根据业务场景不同才用不同的识别策略。

Google 的dialogflow 在识别上有的三种策略：

[if !supportLists]²  [endif]trait策略：整句理解，比如意图、情感等，通过分析整个用户问句来得到实体值

[if !supportLists]²  [endif]free-text策略：用来抽取用户问句中的子串，这些子串通常不会包含在预定义的实体值词典中

[if !supportLists]²  [endif]keywords策略：用于处理需要抽取的实体值可枚举的情况，我们为实体准备好一个预定义的实体值词典，该实体的抽取就通过使用实体值词典做匹配来完成

百度UNIT 也同时区分了利用词槽与槽组的识别与特征词的识别。

采取哪种识别策略，主要还是根据业务的可行性与最终达到的效果进行确定 ，当然亦可组合使用，我们可以根据词槽来判断用户询问的业务之间的关联性，可根据用户整句识别判断用户的情感偏向，也可在业务子串可穷举并且关联性小的情况下使用关键词策略提高识别的准确性。

但是在用户与机器完成的单轮对话中，依然存在一定的难点，此问题在后面详细讨论。

结论： 上文中提到的意图识别或SLU问题，大家应该可以注意到，其本身都是典型的结构化分类问题，虽然所用的模型千差万别，其中对于处理过拟合、欠拟合的方法也褒贬不一，但是无非就是准确率、召回率等问题。

3.4 对话状态

对话系统中存在的现象决定了对话状态跟踪（Dialogue State Tracking）存在的必然性。

大家可以注意到，上文中提到的分类问题属于标准情况下的处理方式，但用户在对话系统中的表现拥有不确定性，所以在这里给对话系统引入了一个在不确定性环境下决策的问题（planning under uncertainty），虽然最终的决策是由下面要介绍的对话策略完成的，但是对话状态需要为后面的决策提供依据，也就是如何刻画这个不确定性的问题。

在智能客服对话中存在以下现象：

[if !supportLists]ü  [endif]不考虑上文中提到的口语处理，在用户问法中，存在 闲聊 与 业务 两种形态的对话，其中闲聊为业务的辅助构成部分。

[if !supportLists]ü  [endif]业务问题中，存在 意图清晰 与 意图模糊 的问法

[if !supportLists]ü  [endif]用户意图清晰的情况下，我们需要根据业务需要让用户补充必要条件，或通过用户补充让问题更精确。如：天气问题中，用户询问“北京明天天气”“北京明天八点天气”，都可给出答案，不同的在于答案的精准程度。

基于以上三种现象，首先我们需要知道用户在 当前对话 中 处于什么状态， 其次是根据当店对话状态我们给出用户 最终答案 需要什么 对话策略。

3.4.1 对话状态跟踪

对话状态跟踪，简单来说就是根据对话来确定用户 当前或最终的目标 到底是什么，此处不仅包括封闭域对话中的 任务驱动式多轮对话， 还包括区分闲聊、问答、任务四类问题，根据业务情况划分意图模糊与意图清晰之间的界限。

[if !supportLists]Ø  [endif]在区分闲聊、问答、任务类问题中，大概可分为三点

[if !supportLists]1.    [endif] 为什么要区分闲聊 ：闲聊是一种不局限于话题的开放域聊天（开放域机器人如微软小冰），即在用户的问题 没有明确的信息 或 服务需求时 系统做出的回应。

开放域聊天在智能客服中的作用有两点：第一点为拉近距离、顺滑对话过程、建立信任等；第二点为挖掘用户情绪引导用户服务请求。

[if !supportLists]2.    [endif] 是否需要区分问答、任务类 ：以智能客服行业典范阿里小蜜来说，是区分了问答类和任务类问题的，但是为什么区分政策和任务类问题以笔者的经验来说仅是根据解决方案的不同，但在用户query无法提现。

如：“是否支持七天无理由退货”的两层含义：一层为公司政策是否支持，一层是用户询问购买的商品是否支持。前者是以搜索较优方案的政策类解答问题，后者是以任务式判断的方式解答问题更为准确。

所以，在QA问答系统和task flow驱动式系统上，个人认为电商类问题更趋向于用task flow解决问题并将QA融入其中。当然，此问题还需要根据客服解决问题的形态具体情况具体分析。

[if !supportLists]Ø  [endif]意图清晰与意图模糊问题

如何定义意图清晰与意图模糊问题，抛开自然语言中的口语处理不讲，我认为它 更偏向 于一个 业务问题 。

对于用户来说，用户对智能客服的目标（user goal）是可以确定的，用户目的的表示形式是一组限制条件（slot-value

pairs）的排列组合。换句话说，理解用户真正的目的（user goal），需要机器理解上文中说到的业务逻辑结构（知识图谱）中每一枝干的关系（或归属于某一枝干）。

也就是说，当用户当前的会话表述中某一组限制条件的排列组合 对应多个枝干 时，为 意图模糊问题 。当 对应一条枝干 时，为 意图清晰问题。

对于 意图模糊问题 的解决方式，大可以用检索式反问的形式来引导用户，即询问用户 可能想问的问题是什么 。对于 意图清晰问题 ，但无法给出明确答案时，为一个 任务驱动式的多轮对话问题 （后文多轮对话展开讨论），即电商问题中常见的需要用户补充订单号或某些意图。

[if !supportLists]Ø  [endif]当进行了前面的口语处理，闲聊与业务区分，区分意图模糊与清晰问题后，我们已经可以理解了用户的目的，即用户问的问题属于业务逻辑结构（知识图谱）中的哪一枝干，接下来在解决用户服务请求的过程中，最后需要处理的就是 补充用户目的所需的判断条件或槽位 （如“查物流”我们需要知道用户的订单号）和 判断用户的目的改变 （如“查物流”转变为“几天能到”问题） 。

以上问题为智能客服对话状态跟踪中常见的需要解决的问题，但是任务驱动式多轮对话中问题现象不仅于此，在下文的多轮对话问题中再详细阐述。

3.4.2 对话策略

理解了用户在对话中的行为，我们来讨论一下关于对话状态中使用的对话策略问题。

对话策略是根据上面介绍的置信状态来决策的过程。对话策略的输出是一个系统动作（system action）。和用户的 dialogue act 类似，系统动作也是一个由communicative function 和 slot-value

pairs 组成的语义表示，表明系统要执行的动作的类型和操作参数。“每次决策的目标不是当前动作的对与错，而是当前动作的选择会使未来收益的预期（expected long-term reward）最大化”

根据上文中的讲述，此问题也可分为三种类型。

[if !supportLists]Ø  [endif]基于开放域机器人的闲聊来建立信任、引导操作、增加对话流畅度问题，此问题笔者并没有深入研究，但就经验来讲，可实现的策略包含用户发起咨询时的预判用户问题与引导用户操作。

[if !supportLists]Ø  [endif]区分用户意图模糊与意图清晰的策略，在意图模糊中，个人更偏向于用检索+重排序的方式定位用户问题在训练语料或业务逻辑结构，进而产生用户可能咨询的问题，也就是在对话中反问用户，但一方面用户会因为机器人猜的不准确而对智能客服的信任感降低，另一方面推测的准确性和人一样，更依赖于知识的覆盖率与准确率。所以，让智能客服像资深客服一样能“猜”的更准，还是一个需要实际验证的问题。

[if !supportLists]Ø  [endif]任务驱动式多轮对话中的补充用户槽位与目的转变的槽位继承问题本身更偏向于根据业务去优化的问题。

补充用户槽位的问题很好理解，如“查物流”需要询问“您要咨询的订单号是？”，进而能得到很好地解决。

目的转变后的槽位继承问题还是需要根据业务情况做详细调整，如上文提到智能客服在“查物流”中获取了用户订单号，那么用户问“多久能送到”时，意图转变后订单号依旧需要继承。当然此问题中会因用户有澄清式问法而改变，如用户增加“我要咨询其他订单”的问法后，即清除对话状态中的“订单”。以上只是举了两个简单的例子，但一个业务中可能包含多个槽位或一整个槽位组（槽位之间存在平行、依赖关系），针对于业务情况不同，对话策略还需要精细化运营。

3.5 应答-最终答案

在经历了教会智能客服理解用户问题的漫长过程后，我们终于来到了讨论给予用户的解决方案部分。

普遍的来讲，解决方案可以有文本、图文、视频、API集成等多种的样式，但实际最终用户的query只会得到唯一的answer，这个唯一的answer的样式及丰富程度，不仅仅取决于我们业务不同需要给予用户不同的解决方案，同时也依赖于对话状态中还可以记录完成对话任务所需的其他额外信息，例如用户当前询问的属性（requested slots），用户的交互方式（communication

method），和用户或系统的历史对话动作（dialogue history）等等。

以观察阿里小蜜的经验来讲，小蜜从原来的图文答案部分转向了API继承的方式，但依然没有感知出针对于用户画像给予不同的答案（可能是我不怎么咨询客服的原因）。

所以以上的内容就不在这里展开，我会在后面《智能客服服务提升》中讨论。

四、结论

能从头看到这里，我相信不是对智能客服本身有一定了解忽略了一大部分抽象内容，就是根本不需要看前文就能理解结构的大佬。

个人认为，智能客服的架构本身只有三部分意图识别及SLU问题对业务进行的分类问题，用户在对话中的表现转化为标准问法的对话状态（DST）问题，与归属完问题后提供给用户最终的解答方案问题。完成这三部，大概在产品架构上能实现智能客服从0到1的方案。

当然构建三部分时应该遵循几点原则：

[if !supportLists]1.     [endif]保持训练语料的一致性，用户问题是否直接分类、意图模糊或需要用户补充统一由对话状态模块判断。

[if !supportLists]2.     [endif]业务的拆解尽可能细致，因为业务逻辑结构（知识图谱）决定了结构化识别的准确性与对话状态的判断准确率。

[if !supportLists]3.     [endif]识别策略和对话策略中尽可能增加兜底方案保证准确率与召回率，结构化识别并不是万能的，有时我们也需要加入检索的方式保证用户问题会产生一个相对准确的解决方案。

以上为智能客服架构时的一些思路，至于每部分中提到的具体问题，会在后续《智能客服的服务提升中》探讨。

在线客服技术的解决方案

1、 轮询

这是一种比较古老而简单的解决方案，也就是定时刷新，在线客服在聊天的时候，aJax在后台定时获取数据，如果接收到发送过来的消息的话，则将消息显示在聊天框上。

这种技术的缺点就是后台刷新太频繁了，而很多刷新都是没有数据返回了，导致性能的下降。

2、 长连接

这种技术有称为“长轮询”，它是基于轮询技术的，但有所改进，客户端向服务端发起请求的时候，服务端不会直接返回，而是会阻塞请求，直到服务器读取到消息后才返回，这个时候，客户端才调用回调函数，将读取到的消息显示出来。

这里讲的在线客服系统将选用该技术来实现。

图2. 基于长轮询的服务器推模型

消息

这种解决方案采用一个作为client的applet，它使用TCP/IP或者无连接的UDP、甚至多播协议来建立与消息中间键server的通讯，然后由server推送消息给client。你可以从例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event这些消息产品中直接挑选，或者自己使用基于socket的定制开发消息软件。

Comet技术Commet是一种使用HTTP长连接，无需浏览器安装插件的“服务器推”方案。它有两者方案：基于aJax的长轮询方式；基于iframe和htmlfile的流方式。这里，我们只关注里面的基于aJax的长轮询方式。

Pushlet是一个开源的Comet框架，其中在设计上有很多值得借鉴的地方，能够使用它来开发一个不是大规模的在线客服系统。而对于大型商用的在线客服系统，我觉得它还无法胜任。

负载均衡（分布式部署）一个正式商用的在线客服系统，不可能只在一个WEB服务器部署，这样子，性能和容量都很难扩展，所以必然是允许分布式部署的，通过负载均衡设备（或软件）来实现分布式访问。

如果采用分布式部署的话，那么就涉及到聊天的数据保存在哪里的问题。是保存在web服务器上，还是数据库呢？如果是单web服务器的话，那肯定是保存在web服务器上，其流程大概如下：

1、 用户发送消息是，系统将数据保存在web服务器（同时也保存数据库）上。

2、 客服对应的长连接获取web服务器上的数据，然后在客服的页面上显示出来。

3、 客服回复聊天信息，系统将数据保存到web服务器（同时也保存数据库）上。

4、 用户所在的长连接获取web服务器上的数据，然后在用户的页面上显示处理。

由于从web服务器上获取数据比在数据库获取数据的效率高，所以上面的逻辑是合理的，但是，基于分布式部署的环境下，他存在多个web服务器，那么发起聊天的消息应该保存在哪台服务器上呢？还是所有的服务器都保存一次呢？在分布式环境下存在一些像JBossCache等缓存同步的技术，但对应在线聊天系统，实时性的要求非常高，是否存在实时性的问题呢？

另外一个，基于安全的考虑，一般需要将用户所访问的功能放到一个web服务器集群上，客服所访问的功能放到另外一个web服务器集群上，两个web服务器集群的网络需要隔离，以防止黑客的攻击。这就又出现一个问题，如果用户发送的消息放到用户的web服务器上，那么客服如果获取到该消息呢？同理，用户的web服务器有如果获取客服web服务器对应的消息呢？

那么放到数据库来实现呢？把聊天记录都放到数据库中，用户和客服都从数据库获取聊天的信息。这样子的话，那么数据库的负荷将非常大，随着用户数的不断增加，数据库负荷越来越大，而且，在大用户下，存储都是非常频繁的，将所有人的聊天信息放到数据库上，是不明智的。还有一个安全上的考虑，一般实现用户的功能都不直接访问数据库，一般会经过一个中间的服务器作为中转，那么如果聊天信息从数据库取的话，效率则会更低。

那么，能不能像QQ那样，聊天双方直接建立连接，实时发送呢？其实，这是一种相对老点的技术，一般是采用Socket，或者UDP，实现双方的通讯。这种机制的缺点客户端可能需要采用applet插件或ActiveX插件，通讯时有比较大的性能消耗，最重要的一点，这些技术受网络的影响特别大，在一个环境下可以正常使用，在另外一个环境下，可能就无法正常使用了。所以，本文考虑的是采用aJax长轮询方式来实现的。

在这里，我建议客服的聊天数据从数据库读取，而用户的聊天数据从web服务器上读取。这是因为客服的数据相对比用户少很多，直接从数据库读取聊天数据，对数据库的性能影响较少，而用户的数量庞大，直接从数据库读取，无法满足要求。

那么，客服是将回复数据写到客服的web服务器，还是用户的web服务器呢？我的建议是写到用户的web服务器，因为用户的数据量非常庞大，用户从用户的web服务器获取数据，要比从客服的web服务器获取数据，性能要高得多。客服每次发送聊天信息的时候，往用户的web服务器写数据，虽然效率低，但由于客服的数据量小，并不影响性能。

另外，在分布式部署下，数据该记得所以的web服务器，还是某台特定的web服务器呢？我建议写到某个特定的web服务器上，这样避免客服每发送一条聊天信息，都要往所有的web服务器写数据，这会影响性能，但web服务器不断增加的时候，性能会随之下降。

那么，客服往哪台特定的web服务器写数据呢？用户又如何知道从哪台特定的web服务器上获取数据呢？这个，我们在用户登陆，负载均衡服务器给其分配到某个特定的服务器的时候，就可以将这个特定服务器的IP记录下来，客服就可以往这台机器发消息了，而用户也同样可以从该IP获取数据了。