移动智能客服系统设计

Ⅰ AI技术如何打造智能客服

由于从事智能客服领域，对智能客服的开发也有比较全面的了解，这里从AI技术的角度介绍一下。

智能客服用到的技术群

智能客服机器人会用到很多人工智能方面的技术，比如自然语言理解、深度神经网络、知识图谱、语音识别、语音合成等方面的技术。为了便于您从总体上了解这些技术，以璞娲智能客服用到的技术为例，请参考下面不同角度的技术全景图。

从客服处理过程理解AI技术

要理解智能客服中的AI技术，我们可以从技术的应用过程来加以理解。比如电话应对过程中，智能客服会用到下面几种技术。

智能客服中用到的AI技术

上面从客服处理过程的角度介绍了几种技术范畴，

首先你要知道它一定要具备学习能力，接下来就是各种喂数据了。

可以从以下几个步骤氏信蔽着手：

（1）确定任务（智能客服）；

（3）任务或问题的明确定义：当做分类任务解决 还是 直接生成回答的问题；针对不同的问题，分别考虑数据收集、收据处理、算法选型、评估方案与指标设计、实验设计、上线方案和坦穗运维等问题。

（4）详细分析好任务和待回答的问题后，就需要准备语料库（注重数据质量，好的数据质量，胜过最优秀的算法）；

（5）数据预处理，将文本数据转换为词向量（有多种方法，如word2vec等等），考虑输入数据与标签歼州数据组织形式，可以参考智能问答相关的开放数据集；

（6）数据分析，主要包括数据量大小的分析、词向量高维嵌入分析、如果是分类任务还要分析类别的数据平衡性；能想到的统计分析与数据处理方法都可以考虑，目标是数据高质量；值得一提：数据量的大小决定数据处理（如需要数据增广、类别平衡、数据上或下采样等）、方法的选择以及模型训练的方法（如使用预训练模型、考虑小样本学习方法等）；

（8）实验与结果评估，注重训练数据与评价数据划分，科学/严谨实验，科学分析；利用设计指标进行评估并充分分析实验结果，寻找模型做得不好的样本案例（badcase）；

（9）badcase分析与解决；

（10）上线前实测，逐步扩大用户使用范围；

（11）继续跟进和改进出现的问题，重复（1）~（10）的环节。

智能客服的主要价值在哪里？

在企业的经营中，客服是必不可少的角色，在很大程度上，客服是企业与客户唯一的直接接触通道，客服的价值在于解决用户问题，改善用户体验，提升企业口碑，营销促进交易等等，但传统的客服模式放到如今的互联网时代，短板立现。成本、效率、沟通方式等都有待提升与改进，由此，智能客服的价值得以凸显。

直观来看，智能客服对传统客服行业的主要价值体现如下：

1、智能客服在处理有明确结论的简单重复性问题上，展现了极高的工作效率，人工客服可以节省更多时间与精力去处理更为复杂、关键的客户问题，去服务VIP或是个性化需求更强烈的客户，从而达到提升客户满意度的效果。同时企业的人力、管理、运维成本都得到大幅下降。

2、智能客服在本质上是机器，机器没有生理局限，服务时长远大于人力，同时它也不存在情绪波动，可以实现百分之百的微笑服务，保持标准的服务质量。特别是在客户业务规模达到明显的波峰波谷时，智能客服可以在短期内实现大批量复制解决，以应对业务量的波动，实现弹性运维。

3、智能客服还可以应用在企业的营销活动中，在传统的电销时代，人工外呼作为很多企业的营销主要手段，耗时长，效果差，一个客服一天所能拨打的电话量有限，而电销恰巧又是一个需要“广撒网，多尝试”的营销方式。此时，智能客服交互系统中的呼叫中心功能就可以被很好的利用起来，增加呼出频率，扩大呼叫范围，提升呼叫中心的价值创造力。

智能客服既有这么多优势，那它的出现又是否会对传统的人工客服造成替代性的威胁呢？

其实不然，传统的客服行业就像是一座金字塔，人工智能并不是将它推倒重建，而是在思考如何做到机器辅助人工，部分代替人工，扩大金字塔的基层，稳固上层结构。

由此，智能客服的主要价值可以概括为：在满足企业对客服工作的需求的同时为企业减投增效，帮助企业更好的实现营收。

逻辑推理 知识表示 自动规划 机器学习 自然语言 感知 行动处理 人类情绪 计算创造 综合智能

只要用在合适的地方。无论各行各业，机器人代替人工，能够极大增强企业办公效率，增加收益，降低用人成本，人工智能的发展最大的受益者是人类。人类的创意是无限的，但是自身能力也是有局限性的，也需要机器人来辅助人类。所以各有优势，无所谓谁的业务能力强，都是相互弥补的。这没法比较。

随着电话服务热线的出现，以及企业客户服务的不断提高。在移动互联网时代，客户通信服务也变得多样化。除了申请400或95个号码建立客户服务系统来改善客户服务外，企业还通过网络服务、移动应用、公共微信、微博等渠道提供服务。当越来越多的人以这种方式与企业员工接触时，当人工客户服务不能及时处理多个用户和问题时，导致客户体验差，再加上企业的雇佣成本不断增加，智能客户服务机器人顺应时代的到来。目前，智能客户服务机器人已经成为企业与用户之间最重要的通信工具。广泛应用于金融、教育、电子商务等领域。

最近，在微博上，我们总能看到一些客户服务机器人在本地测试市场上并不想象智能，自动回复单句严重，回复内容错误，人们想要有人工的客户服务来与他们沟通。问题是，客户服务机器人什么时候才能真正“理解”？编辑曾体验过腾讯、阿里小米、京东和大银行的在线客服平台。电子商务服务平台具有响应速度快、识别率高、产品促销个性化、信息优惠等增值服务的共同特点。但对这句话的理解却偏低。

在当前的客户服务中，机器人客户服务作为手动客户服务的辅助工具，帮助手动客户服务解决，解决客户的诸多问题，降低手动客户服务的工作压力，提高工作效率手动客户服务，大大提高了解决方案的准确性。效力。然而，在与人类的对话中，客户服务机器人已经成为人类复杂情绪的难点。在接下来的几年里，客户服务机器人不会完全取代人们的工作。深入整合人机的“无人值守客户服务”是打破这一瓶颈的最佳方式。

所谓智能客服机器人实际上是一个人工智能信息系统，它可以用自然语言与用户进行通信。它使用了许多智能人机交互技术，包括自然语言理解和机器学习技术。它能够以文本或语音的形式识别和理解用户的问题，通过语义分析了解用户的意图，与用户进行人性化的沟通，为用户提供信息咨询等相关服务。

在当前人工智能迅猛发展的浪潮中，福山北明信息技术公司负责人表示，优秀的客户服务依靠人工实能和海量数据来深化客户服务场景的应用，不断优化、创新和完善。描述了“可定制”的智能客户服务，它能够准确地适应业务需求并继续学习，并帮助、适应和回答大量的常见问题。它大大提高了人类的效率。它可以广泛应用于网站、应用程序、电话客户服务甚至离线窗口。目前，优秀的客户服务已成为深圳平安公司的合作伙伴。在智能客户服务领域实现了战略合作。全面启动人机对话培训平台，为企业构建基于ai的智能客户服务解决方案。

2018年9月，发布了4.0.0正式版本的优秀客户服务，添加了群集和企业知识管理系统，使用群集解决方案支持多点部署方案，添加了企业知识管理系统组件，并拥有专业知识管理系统。和新的移动智能推荐。深入挖掘各种需求场景，人们对机器人的满意度并不低于人工。

佛山市贝米信息技术有限公司（www.youkefu.cn）成立于2017年3月，是一支年轻而充满活力的团队。公司的主要“优质客户服务”是一个全渠道的综合客户服务系统，集成了多个客户服务渠道，以帮助各个行业。各种规模的企业建立了客户服务体系。通过邮件，短信，电话语音，webim在线客服，微信，微博，h5页面，app界面等各种渠道的客户服务请求和对话，集成在管理平台上，统一响应和支持客户服务。

当你打 10086 的电话，语音提示如下：

欢迎致电中国移动，

全心全意为您服务，

普通话服务请安 1，

For English service press pound key

...

我这个手机号用了 5 年了吧，打10086这个电话不下 50 次了，你还不知道我是不是说普通话？

以上只是举了一个最常见的例子。

随着智能技术的发展，越来越多的客服咨询都开始交由对话机器人解决。

就在最近，冠状病毒疫情爆发，大量民众通过手机或电脑咨询政府以了解最新的疫情信息和防控措施。在这特殊情况下，原本的人工客服是无法承接这么多咨询的，而客服客服就尤为重要。

简单来所，智能客服系统 主要基于自然语言处理、大规模机器学习、深度学习技术，使用海量数据建立对话模型，结合多轮对话与实时反馈自主学习，精准识别用户意图，支持文字、语音、图片等富媒体交互，可实现语义解析和多形式的对话。

但是每个行业有自己的业务特点和知识范围，每个呼叫中心公司都应该根据自己的业务，逐步解决最基本的问题。

比如10086，一次次重复问你说普通话还是英语。

智能服务是一个过程，不是结果。

随着AI人工智能赋能客户服务。智能客服系统应运而生。

智能客服在提升企业服务质量和工作效率，降低企业管理和运营成本，提高企业的核心竞争力方面有着重要作用。

比如，我们利用AI技术能够同时实现 智能语音导航、智能话务员、智能工单管理、智能数据分析、智能语音质检、智能外呼 等功能。

并且能够与用户原有的呼叫中心系统有效对接，具有简单操作易上手、功能齐备、实用性强的特点。

如果企业想实现客户服务精细化运营管理，可以考虑试用哦~

一、智能机器人的能力
人工智能客服系统的核心能力主要体现在智能机器人上，企业在选择机器人前，需要了解机器人有哪些功能或能力，可以帮助企业做选择参考。智能客服机器人通常包含以下几项关键能力。

（一）自然语言识别能力

机器人拥有自然语言识别能力，可以帮助机器人更好的理解人类语言。举个例子来说：人类对于一个问题会有多种不同的方式，机器人需要理解问题中的关键点，从而找到对应的问题。这是考察机器人性能时较为重要的指标。

（二）知识库和自主学习

知识库相当于机器人的大脑，企业需要在使用初期为机器人建设一套知识库。这就相当于给新员工一个产品介绍或业务资料。在对接客户时机器人会从已有的知识库中搜索问题的答案。在不断接受问题和解决问题的过程中，智能客服系统机器人会完善知识库，将处理的问题积累下来，就形成了自我学习能力。通过这种方式可以方便以后更好的解决客户问题。

（三）其他能力

有些智能客服机器人会有一些扩展能力，能通过网络/API接口找到一些其他资源，比如：查询快递、查询天气等等。具体来说：电商客服也许可以在与来客交谈时，帮助客户查询快递情况，这类需要由机器人就能完成了，并且速度和准确度都可以保证，无需额外的人力来处理这类问题。

二、人机对话有温度

智能客服机器人不仅能替代人工客服的工作，在拨通用户电话后，还可以像真人一样与用户进行沟通交流。而这些需要大量的人工智能技术支出，比如自然语言处理、语音识别等多个领域。

Ⅱ 低调的王——“小能科技”客服系统产品分析报告

——“在智能客服领域，我就是王”

作者自述

我在一家公司做ToB产业电商平汪芦清台。因为同在ToB行业，因此对小能科技产生了很大兴趣。本文试图用逆向工程的推理方式，理哗毕性分析解构一下此公司的产品设计，以对比学习。

产品背景介绍

小能科技，这家做在线客服的创业公司，估值已达10亿元，服务客户包括海尔商城、唯品会、乐蜂网等2000多家企业。 企业标签是 CRM、SAAS。

前言 —— ToB产品、SAAS产品体验的困境

纵观整个产品网站文章，对ToB产品的分析体验文章是最少的，甚至有些行业是看不到的。

因为自己也研究产业电商，很多时候都必须和ToB、SAAS打交道。此时必然会遇到如下的困境：此类产品的用户注册门槛一般较高，且一般不提供免费试用——如果是互联网形态的产品，连盗版都找不到。而我们一般没有合作的情况下，无法以正当理由拿到对方的试用版账号。

因此这里不会出现太多的根据《用户体验的要素》分层之浅层内容（如界面设计、导航设计、信息设计等），而是聚焦于从网站展示业务、网站场景页面（页面和对应的说明宣传文字，此时，宣传文字内容即为该页面对应的场景）截图、行业针对性分析，通过这些内容提取出 目标用户、主要使用场景、用户目标与产品诉求等产品关键性信息，并加以分析这部分内容。

时间分野：本文的背景在2017年，把2017年之前出现的公司、产品等都视为传统公司、产品

分析框架引用：http://www.woshipm.com/evaluating/583453.html

Key Words：ToB，SAAS，客服系统，竞品分析，产品体验，用户行为分析

============================================================================

正文：

用户需求还原：

说明：教我ToB设计的人说过，ToB不要只考虑业务、工作流等等，还要看到在系统的背后，是哪些操作员在真实使用这个系统，这些操作员的画像同样很重要。（Use Case图只能体现角色和系统之间的触点，并不能很好地体现出人性，这就需要产品经理在ToB设计的时候注意特定的用户（功能的操作员）与人性。）

设想如下的情景：

S1-1 我公司的客服老妹，电脑上开了N个qq、旺旺、京东等客服软件，嘀嘀嘀的音效响个不停。

S1-2 当她离开工位后，这些客户只能暂时被晾在这里，造成了客服系统体验下降。

S1-3 老妹手机上开了N个qq、旺旺、京东等客服App，整个手机快要被挤爆了。

S1-4 老妹因为回答VIP问题不及时，被老板扣钱。

S1-5 老妹接到客户对订单的反馈时，就会生成一个工作流 —— 跟踪问题，并按照标准流程做出处理，最后反馈给客户。

S1-6 老板需要衡量和管理老妹的工作质量。

以上就是提到客服系统时，我们首先忆起的传统客服系统。

----------------------------

根据小能科技的介绍，他们把产品目录分为在线客服、机器人和呼叫中心三部分。

根据我对电商系统的理解，可以合并呼叫中心这一独立产品到客服系统（分为语音接入和文字接入——印象中现在有语音接入的电商比较少，传统行业转型的企业可能多一些语音客服）。而机器人从功能上可归类为筛选客户模块的一部分。因此，我们可以归纳出如下的用户需求：

S2-1 系统按照分级处理思想，把客户按照设定好的规则在人工座席接待前困前排队。

S2-2 系统需要提供非人工的客服，将一部分无需人工处理的客户分流。

S2-3 知识词典，自动咨询的一部分。

S2-4 机器人问答系统：装一下逼，而不是单纯的知识词典——突出高科技属性（投资人喜欢看到这个，属于猎奇需求）。

S2-5 企业可以选择是否使用语音客服，如果使用则提供一个成套的互联网电话呼叫系统。

-----------------------------

特别的，有一部分内容，我认为是超用户预期的功能，这部分场景真是产品经理脑洞大开的产物，也是创业公司赖以生存的用户壁垒所在。 根据最近对GrowingIO的增长黑客研究，“获客渠道”，在做渠道转化率分析时，是最价值的信息。

另外，一般而言，用户交互数据+用户订单数据合在一起就是在系统边界内可以被感知到的用户行为数据。根据小能科技的功能介绍，小能科技也把这部分内容和客服系统相结合了。（其实更像是把用户与客服沟通数据加入进用户行为数据中去，使得这个数据更加精准了。）

小能科技在描述中说，他们可以追踪到用户对购物车的操作，那么这应该使用了埋点/无埋点技术。具体使用了哪种技术有待观察。

归纳出需求如下：

S3-1 可以按照渠道归纳用户信息。

S3-2 把用户订单信息结合进客服系统。（或者把用户与客服沟通数据结合进用户行为分析系统）

S3-3 使用埋点/无埋点的方式，获取用户交互数据。

S3-4 一个UI靓丽的分析系统

------------------------------

另外、有一些企业级的基本需求需要被考虑其中

S4-1 企业级账户管理体系：管理员——分权限——最低权限，一套金字塔体系。

因此可以总结出小能科技的用户需求为：

============================================================================

产品市场现状

目前企业级服务市场热度相当高,不过企业服务市场有个问题，无法爆发增长，没法看到一条长阳线用户直冲一个亿的奇迹。话说回来，因为客单价高，行业体量大，有可能企业只有一百个客户，但年GMV做到10个亿。

-------------------

根据场景S1-1，企业凡是在多平台开店的，都需要这种把多个平台的客服接口聚合在一起的系统，我们可以称之为“客服聚合系统”。

根据小能科技官网的展示，他们在如下几个方面都有客户：平台电商、垂直电商、跨境电商、在线教育、互联网金融、医疗卫生、O2O、汽车、在线旅游。

以上客户可以分为如下两类：店铺类与小型电商平台。

店铺类：企业在各大型平台上有店铺存在，需要聚合各来源客服信息，统一处理。

小型电商平台：都是小型的电商平台，可能自己的开发能力有限，直接接入小能科技客服系统自用。

---------------------

因为没有公开的数据，那么我根据互联网公司盈利模式，推测所有的符合客户气质的收费方式是：

1、按咨询量收费（和GrowingIO按照日活用户数收取费用类似的套路）。

2、分档次收固定年费、比较传统的方式 —— 针对传统企业比较合适。

============================================================================

产品核心策略分析

我们从小能科技的宣传语开始分析：

“小能客服打通Web网站、移动网站、微信、APP、电话、表单、邮件等等，无论顾客来自于哪个渠道， 都可以在小能客服后台统一接待。”

小能客服的基础是一个客服聚合系统，这一点和别家没有什么不同。

继续看下去，可以发现一个最大的亮点是：把用户行为分析系统结合进客服系统，从用户分析角度重构客服系统。这点和做积分系统的汇积分有点像，汇积分是把用户行为分析系统整合进积分联盟系统，从用户分析角度出发重构积分系统。具体而言，就像是一个结合了GrowingIO的 客服系统/积分系统/whatever系统。

同时我们看到小能科技经过这么长时间，一定基于用户DNA（比如手机号等）能整理识别出大量的用户行为数据。同时，在新闻报道中也印证了这一点“小能的企业客户规模已经超过2000家，囊括了3亿多用户的相关数据，相对于同行拥有明显的竞争优势。”“凭借大数据，在最近一次，投资方给出了10亿的估值。”—— 这就是所谓借所有接入方的注册用户数据为己用。

另外，我们还看到了客服机器人的身影。

但我认为机器人并不是核心策略，这要从用户角度阐述。用户可能会调戏一下机器人，但大多数时候，用户都是带着目标进场景的，和机器人聊天并不是用户主要使用路径，（除非机器人能满足用户的目标，比如AI代替客服来处理客户的订单或投诉问题。）——猎奇是允许的，但不是刚需。

总之，梳理以上核心策略，可以画出如下的图：

在我们安排开发计划的时候，MVP功能一定是先聚合，后加入分析系统。最后再去公关机器人；或者我们机器人就不做了——投入高，而满足用户需求不明确。

============================================================================

产品结构分析

根据小能科技官网图片，以及对需求的挖掘，应该有如下主要的产品结构：

1、客服聚合系统

多平台客服API接入、用户分级排队系统{多渠道来客共同排队；区分售前（咨询）与售后（产生工单）}、分级规则池（用户识别与行为信息介入触点）、呼叫中心、人工座席、工单系统、用户行为数据传入分析系统

2、用户行为数据分析

交互数据（购物车）、订单数据、用户客服反馈数据、增量用户行为大数据系统

3、用户行为大数据

用户识别、渠道识别、传递历史数据到用户行为分析系统{交互数据（其他平台）、订单数据（其他平台）、用户客服反馈数据（其他平台）}

4、客服机器人

知识库、互动问答、自学习、训练

5、企业级管理系统

客服中心管理系统{ 客服KPI管理、数据指标展示}，用户行为数据展示

脑图如下：

============================================================================

用户使用评价

从小能科技公司发展轨迹中分析，既然客户在增加，投资人在投入。这就说明用户评价不错。

不过因为处于ToB市场，所以小能科技的知名度不行，网络指数也未有收录。

============================================================================

思考与总结

目前用户增长黑客非常非常火。给我们的启发也非常非常大。各种SAAS都可以结合用户行为数据分析，看看能否做出与众不同的产品？成为下一个独角兽。

-----------------------------

另外，可以思考目前客服机器人的几个问题

1、你在JD购物的时候JIMI可以帮你处理订单退款吗？

2、微软小冰为什么只火了一段时间就退潮？

这说明目前客服机器人并实用，无法满足带目标用户进入客服场景下的需求。不过随着AI技术的发展，希望有一天，AI客服可以完全替代人工座席 —— 如果小能科技能做到，那么客服行业同阶无敌。

Ⅲ 关于实现在线客服系统需要哪些技术

一个在线客服系统在技术上应该有一下几个基本的方向：

1. 通信协议（http、websocket等）

2. 集群部署（没有集群怕是服务的客户量会很少而且升级一会很麻烦）

3. 大数据相关技术（在线客服记录的基础数据有访客的浏览数据、对话数据、客户信息等等数据量是比较大的，了解大数据相关的数据应该是必备的）

4. 智能学习-机器学习（一个好的在线客服系统应该需要提供智能客服帮助人工客户解决问题）

可以通过专业的在线客服对外提供的API了解到很多他们用的技术栈和开发思路。比如：一洽客服开放API

Ⅳ AI技术如何打造智能客服

AI技术已经广泛应用于客服领域，打造了更加智能化、高效率的智能客服系统，以下是实现的技术和流程：

1. 自然语言处理：智能客服系统需要能够识别并理解自然语言表述的问题，更加高效地解决客户的问题。自然语言处理技术包括语音识别、语音合成功能、文本语义分析等等。

2. 机器学习：机器学习是智能客服系统实现强大的自动回答、自我学习的关键技术。通过分析历史数据和用户反馈，机器学习可以自动调整不同情况下的处理方法，提供更精准和快速的服务。

3. 多通道交互：智能客服系统具有多通道交互支持，包括语音、文字、图像等不同形式的输入和输出方式，提供更多可能性来吸引和服务用户。

4. 失败补救流程：当智能客服系统无法理解用户的问题或无法解决用户的问题时，需要智能地为用户找到其他解决方案或将用户转交给人工客服，保证用户的满意度。

5. 联合处理：当智能客服系统检测需要介入人工客服时，需要及时将用户的及时数据和聊天记录转交给人工客服处理。同时，处理系统也需要将人工客服转交的结果自动反拿蠢指馈回智能客服系统，以提高处理效率和服务质量。

6. 维护持续更新：智能客服系统需要不断更新和完善其聊天库、知识库和处理流程，以保持服务的可靠性和高效率。

需要注意的是，在实现智能客服系统之前，需要先考虑制定一个完善的开发计划和用户体验计划，确保系统的可持续发展和服务体验。拓展上面提到的几点，以下是智能客服系统的更多实现技术和流程：

7. 对话管理：聊天机器人也需要能够实现多种对话和流程管理，这需要更加高效的涉及到自动问答的句法分析、语义分析和关键词提取，以及新奇的、符合多样化用户场景和习惯的语料建设。

8. 又称智能匹配和推荐：对于产品和服务的方案及其数据的众多并存，AI技术在智能客服系统中也需要能够库存维护、算法优化和用户需求匹配。

9. 自助服务：人工客服系统因为建立成本、运营成本、人员素质等原因等条件下，还需要通过自助服务来减轻压力，提高对等消配流量的处理，增加用户满意度。智能客服工程可以融合搜索引擎技术、随时带来常识库等多种技术来提高搜索匹配度，从而有效检索和档差供应智能方案。

10. 账号集成和术语挂接：智能客服应用系统需要在账号集成和知识库共享上做好规划和实践；对语料库进行分词、挂接，对相似问答进行统一挂接，避免巨量的人工干预，提高使用效率。

总之，智能客服系统的实现技术和流程是多样化的，在不断深化的时代背景下，也在不断欣欣向荣。

Ⅳ 智能客服系统应该具备哪些功能想要接入一个。

智能客服系统,需要具有意图识别、多轮会话、上下文理解、知识库智能学习等多项前沿技术

1 意图识别:基于前沿神经网络技术，在亿万级数据集上训练得到的意图识别模型 能够自动抽取用户问句中的时间、地点、人名等关键性信息，自动识森橘别同一意思的不同问法，正确理解用户的意图

如果想要接入自己的微信公众号,官网,app,小程序等等都是没问题的

Ⅵ 智能客服结构-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]识别策略和对话策略中尽可能增加兜底方案保证准确率与召回率，结构化识别并不是万能的，有时我们也需要加入检索的方式保证用户问题会产生一个相对准确的解决方案。

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

Ⅶ 智能客服系统有哪些功能

相较传统客服，智能客服系统通过一系列强大功能，有效的提高了客服的效率。

一、多渠道客户接入
拥有多个获客渠道的企业可以将其客户咨询接入客服软件，客服人员只需要登录客服软件一个平台即可回复所有渠道的咨询消息。
支指团持接入渠道：网页、对话纳逗备链接/二维码、公众号、小程序洞毁、App等等

二、多客户端回复
通过将渠道接入客服软件后，原本只能在网页回复的客户咨询可以通过客服系统手机App客户端进行回复，更加便捷。
支持回复客户端：手机App、小程序、电脑桌面客户端、网页

三、智能客服机器人
客服人员可以将接待中遇到的基础、常见问题设置为机器人自动回答，且客服人员还可以根据情况在每个渠道设置不同的智能机器人，有效减少人工客服打字回复量，在咨询量大时效果更为明显。
支持功能：关键词匹配回答、智能菜单、条件转人工、顾客输入引导

四、客户自动分配机制
可以根据客户的来源渠道来分配对应的客服组，支持多客服协同工作对话自动平均分配以实现资源利用最大化。还可以配置出各种自定义分配逻辑灵活且强大的分配功能能够满足你所有的需求

五、对话辅助
根据客服实际情况设计的效率提升功能，使人工客服回复更高效。
客服工具：快捷回复、顾客输入预知、同步客户资料、顾客标签

六、客服团队管理
传统客服使用的通讯软件无法对客服人员的工作数据进行统计，管理人员很难对客服团队的工作情况有深入的了解。客服软件通过将客服人员的工作数据化，使管理者以直观的工作数据做支撑，深入了解客服团队工作情况，以便优化提升。

统计数据：接待量、响应时长、客户评价、有没有遗漏咨询、登录时长等数据
多维度统计：客服团队整体的接待量、对话率、回复的消息数等精确到小时的数据

Ⅷ 智能客服对话场景设计方法

一. 智能客服中场景的定义及分类

用户解决某一个问题，需要与机器人进行多次对话才可以解决的问题，就是智能客服中的对话场景。一般它分为单场景对话和多场景对话。

1.单场景对话

定义：用户与机器人只进行一个主题的对话，如“查天气”

  例1  场景【 查天气】

        用户：明天天气怎么样

        Bot ： 零下10度，可以多穿一些毁铅哦。

        用户：那上海呢？

        Bot ：:零下1度哦。

2.多场景对话

定义：用户与机器人联系进行了多个主题的对话，如“查询订单+退货”。

例2  场景 【查询订单+退货】

          用户：看一下我买的东西到哪了

          Bot：  向用户发出订单列表

          用户： 嗯，看一下第二个

          Bot：  发出订单详情

      用户：还没发货啊，帮我退了吧。 ——从用户的这句话开始，对话的场景就从“查询订单状态””变成了“退货”，退货与查询订单是两个不同的主题，他们既可以独立存在，也可以合二为一。

            .

二.场景设计

设计一个对话场景，主要包含两个方面：起始条件整理、流程整理。

小知识：假设“查一下明天上海的天气”是用户说的第一句话，那么它就是一个场景中的起始条件，而在这句话是由两个要素词构成的“明天”，“上海”，这两个要素词分别代表了时间和地点。由此可以推论出这个起始条件的主要结构是时间+地点。

1.起始条件整理

在对话场景中用户与机器人第一次交互时，所说的话为起始条件。而一个对话场景有多个起始条件，不同的起始条件会让机器人与用户的对话的流程出现不同的走向。所以场景设计的第一个步，我们陵耐需要将对话场景中不同的起始条件全部整理出来。

例3 场景 【查天气】

条件举例

例4 场景【请假】

条件举例

2.对话流程

整理好全部的起始条件后，就可以根据去撰写每一个条件下的流程。具体可以看下面的例子。

例5  场景【请假】   

      起始条件：仅包含请假

      U：明天请假

      A:请到哪天呢？

      U:后天

      A:请告诉我工号

      U:001

      A:您的请假申请已经提交了。

例6

    对话起始条件：仅包含请假天数。

    U：请三天假

    A:请问您是哪一天开始请假？

    U:后天。

    A:请到什么时候呢？

    U:周五。

    A:请告诉我您的工号

    U:001

    A:您的请假申请已经提交了。

通过例5和例6我们可以看到起始条件的不同，会导致对话的流程也不同。所以整纤汪好理出全部的起始条件事关重要。不过对话流程整理好之后，场景设计的部分就高于段落了。接下来就需要进行意图的整理。

三.对话意图的设计

这一部分主要介绍意图的分类、如何拆解场景中的对话意图、对话意图知识的设计及优化。

1.意图的定义与分类

意图是指用户的目的，如用户说“我想听音乐”，那么听音乐就是用户最终的一个目的，我们只要给他播放一段音乐就可以了。在智能客服的使用情况中，意图一般分为两大类：问答意图和对话意图。问答意图是指一问一答，如用户问“退款时效”，退款时效这个问题，每个商家都有一个固定的答案。这就是一个问答意图。

但在对话场景中，用户都会与机器人多次交互，每一次交互用户都会表达自己的目的，这个目的其实就是我们所说的对话意图。 请看例子

例 7 场景【查快递】

在网上买完商品时，我们会查买的商品的派送情况，图中的用户说“我的快递到哪了”。“我的快递到哪了”这句话就是一个对话意图，用户说它的目的就是查询快递派送的进度。

2.对话意图的拆解

一个对话场景中一般都包含多个对话意图。基本上，用户和机器人的每一次互动就是一个单独的对话意图。我们可以把例7图里的对话流程写下来 看一下

例8  场景【查快递】

起始条件：多个商品订单

U:我的快递到哪里

A:订单列表

U:选择一个订单

A:显示订单派送情况

在这个场景中，用户表达了一个目的就是“查询订单状态”，所以机器人会向用户推出订单列表，确定用户询问的是哪个订单。这就是一个对话意图。接着用户确定了具体查看的订单后，机器人需要把确定好的这个订单的物流信息发给用户，这也是一个对话意图。

所以上面的场景中包含了两个对话意图。到这针对于这个场景的对话意图的拆解，就结束了。

3.对话意图知识的设计

拆解好场景中所包含的对话意图后，我们需要设计意图。还是用场景请假来举例

例  场景【请假】

      起始条件：仅知道开始时间

      U：明天请假

      A:请到哪天呢？

      U:后天

      A:请告诉我工号

      U:001

      A:您的请假申请已经提交了。

对话有三轮，所以这个流程里有三个对话意图。我们先来看第一个对话意图的对话内容。

U：明天请假

A:请到哪天呢？

明天请假，在这句话里明天是一个要素词，它代表了请假开始的时间。所以这个意图=请假开始的时间， 它的构成成分就是具体的时间/日期 ，如今天、明天、12月30日等等，而一般的对话系统中会把时间类的词语都内置进去，所以这里就不在进行穷举了。

这个对话中只含有了一个要素词，但根 据起始条件的不同 ， 对话意图中包含的要素词的数量都是不一样的 ，具体的可以参考每一个起始条件的流程去设定。

4.对话意图的知识优化

对于同一句话，每一个人的表达方式都是不一样的。为了使机器人能更准确的解读用户所表达的意思，做好知识的优化是一件必要的事情。优化步骤包括：写出所有句子——拆解组合——归纳同义词。

例： 快递到哪了

         物流到哪了

         东西到哪了

这几个句子表达的意思都是“查物流”，可它们的用词并不完全相同，通过拆解，我们可以得到以下结论：这条知识=快递的同义词+到哪了的同义词

例：  查快递

          查一下快递

          快递查询

          查一下商品物流

这组句子表达的意思也是“查物流”，它们的用词并不完全相同，通过拆解，我们可以得到以下结论：这条知识=查的同义词+快递的同义词。

分析完上面两个例子，可以很明显的看到这两组的组合都只有两个词组，而其中有一个词组是相同的，所以可以将这两组组合进行合并：快递的同义词+查/到哪了的同义词。

四. 意图知识的线上管理

1.机器人的分配

将所有问答意图及对话意图设计和优化一遍之后，就要将这些准备好的知识导入到机器人的线上平台进行操作。一般的客户在平台上只需要建立一个机器人，同时绑定多个知识库，就可以达到效果了。

但像一些客流量大电商客户，他们会根据整个的业务场景去创建机器人，如售前机器人、售中机器人、售后机器人。这样做有一个好处，就是当客户有问道一些机器人无法回答的问题，可以直接转人工到相关类别的坐席。

还有一些客户，会复杂一些。他们是一个大的企业，在他们的内部有很多的部门，每个部门都在使用同一个后台。

例  A企业下有人力、财务、行政、生产、项目等部门，他们使用同一个企业账号登录一个后台。每个部门都会建立知识库，但是如果都绑定在一个机器人上就会出现一些问题。

如果非要使用同一个企业账号，在这种情况下建议，每个部门可以在后台各自都建立一个机器人，并将自己部门的机器人只绑定部门相关的知识库即可。（最好可以有权限设置）不过最好每一个部门都使用独立的企业ID，各自登录各自的后台，不会造成干扰。

2.对机器人进行评价及调整

经过了一段时间的运营，我们需要知道机器人的效果到底是怎么样的？一般来说，只要去将机器人的对话日志导出，进行分析即可。

1）日志分析的内容

一般分析日志会分析以下内容

总交互次数、交互完成总量、未识别意图量及占比、识别错误意图量及占比、无效意图及占比

问答意图总量及占比、对话意图总量及占比、对话意图与问答意图在总量中的占比

高频问答意图及占比、高频对话意图及占比、对话场景完成量及占比。

2）调整机器人

分析结束后，会根据得到的具体的结果对机器人的意图和知识进行调整和优化。

需要注意的问题

未识别问题很多的情况，有几种可能

①用户说的话，在知识库中不存在相似的问法，所以只要添加即可。

②用户说的话，在知识库中有类似的问法，那么就需要人工去排查是否是其它知识造成的错误，还是技术原因等等......

Ⅸ 智能客服系统架构是怎么样的呢

请点击输入图片

AI+智能客服体系中，并不是真正意义上完全取代传统客服，而是将人工智能赋能在客服领域上，体系中增设智能源哗在线服务机器人，通过智能知识学习与大数据提供智能坐席知识库、智能人机协作等举措，打造智能客服体系。在实用性上，毫无疑问郑裂棚够击中企业优化服务过喊则程中的痛点：一方面，针对高频次、高重复率的提问和海量客户，高性能的智能客服机器人能够提高工作效率，极大地降低人工成本。另一方面，如何为客户输出全面的高质量服务，更好地提升用户在消费升级当中的体验？智能客服似乎更能满足当下消费者们对于客户服务的移动性、即时性和社交性以及多渠道化的需求。

一个优秀的智能客服机器人，要在长期的交互过程中不断学习和自我完善，达成对接收到的语句进行更精准的语义分析，能够通过上下文关联、场景管理、个性化推理等过程对自然语言进行准确理解，同时更需要积累庞大的知识库，特别是在相关专业知识方面进行长期学习。而几度经历转型和挑战的小i机器人，在智能客服这一领域，终于拥有了更大的话语权。