本文来自云问科技联合创始人 COO 茆传羽在华南数谷·2021年客户观察（第五届）数智客服华南峰会上的分享节选
云问科技联合创始人 COO 茆传羽
首先，我们认为应该是智能化的工具+科学系统的方法论这两个主题。近些年来，大家慢慢关注到客服中台的建设里面非常核心的部分就是知识中台。我们认为知识中台的建设包括知识的运营能力、运营的推广、数据的同步、应用导向。我们跟华为是知识中心的一个战略合作伙伴，一起推出了知识成熟度模型的方法论。怎么去评估比如你的原数据、主数据建设？知识的概念、分类、三元组建设的质量怎么样？支持运营的体系是不是合格？首先要做知识运营能力成熟度的评估，包括技术的能力、知识管理的方法、应用的搭建，以及客服应用的搭建。知识应用和客服应用之间还是有一个鸿沟的。我简单的讲一下知识常见的类型。比如说非结构化数据、半结构化数据以及结构化数据的一些构建。结构化数据，比如说像产品数据等，这些数据表格可以直接导入进去。半结构化数据，像一些工作单、申报表，里面同时包括一些结构化和非结构化的东西。
【非结构化数据】比如说一条产品政策、一篇活动的说明，这些都是不同类别的构建思路。非结构化的知识，首先要去做拆解，非结构化知识拆解的时候是一个关联的事情，它不是一个孤立的拆解动作。比方说，我上传了一篇苹果手机的产品说明书。这里面提到了镜头的问题，并且在苹果的摄像手册里面也提到了这个问题，实际上如果把这个知识单个地拆成一个条目的话，它们之间是很难产生关联的。比如我想问，这个镜头有什么好处？它的说明书里面可能只提到了一些参数。这些参数并不能成为它的优势，所以单个的知识点可能要跨文档去做处理。而这个时候，我们会通过知识图谱去做一些关联，所以在拆解的时候要考虑词条、百科的建设。
【结构化数据】的采集，比如说设备的数据，通过故障报告、实验报告做录入，包括设备信息描述、现场检查。把所有的数据全部都统计在一起，然后从设备的全生命周期这个角度去做管理。最后它是整个的一个应用，并不是拆完这个知识点就是这个知识点，一定是要有一个被用户经常访问和消费的主体来去做最后的服务承载。比如我们在设备领域，建设一个设备的全生命周期的知识库，那么未来只要是跟设备相关的，不管是故障的问答，还是故障的预测都将易如反掌，甚至说我会知道这个设备要出现故障了。如果之前所有的维修单里都提到了这个设备在三个月左右可能就会报一次故障，并且这个故障还会影响到其他设备节点的运行，那么这个时候我就可以给你提个醒，我就可以告诉你设备可能会存在这个问题，或者给我的服务人员提醒。
为什么知识图谱的建设是非常重要的？因为它可以把原本分散的知识，通过关联的关系去形成整个的图谱网络结构，可以做到推理、计算、可视化的阅读、卡片式的交互等。虽然建这些知识图谱前期工作会比较多，但是完成后在后期就可以直接去做引用和关联了，这样在问答的时候，就不会做重复的知识建设工作了。比如说我直接问A汽车和B汽车，他们数据之间的对比是怎样的？这个时候，可以在图谱中自动进行一些回答并且直接通过图表展示出来，这个图表不需要预先设计。
对于结构化的一些处理能力，如果是做工业消费品类或者是产品类的大家会比较熟悉这种表，它有很多这种系列，可以直接去做参数的查询和问答，然后规范化地引用一些引擎数据的场景，以及底层数据的配置。
在平时应用的过程当中，我们认为将来会有一个AI数据和AI知识的运营师，并不是说教机器人这个知识怎么建，怎么训练，而是对于整个企业AI底层的数据训练。我个人认为这块可能通过外包标注是没有办法去实现的，还是得要我们企业自己去懂业务的这些知识。比如像做酒店行业案例的时候，对于地址槽位的收取，肯定会有很多不准确的地方，比如说东城大厦，这是一个小区名字还是一个大厦的名字，实际上在不同的场景当中它都是有一些不同应用的。如果这个数据，客服把它标注完成，最后形成AI引擎数据库，只要是咱们企业内部，任何部门都会需要这个数据来进行调用，客服就可以从成本中心变成一个赋能中心，价值链也会更长。我们举一个小的例子，如何把刚才说的这些申报的东西和一个简单呈现的页面去做关联，这也是我们思考了很久之后得出来的一个结论，即通过这样简单的体检报告。把咨询类的成熟度模型通过系统的层面去呈现，比如说这个知识哪里建的好，或者是知识之间有冲突，同一个知识点，两条非常相似。把所有的这些东西全部都汇总到一个体检报告里面，然后定期点一下就可以知道哪块建得好哪块建得不好，哪块用户的问题在某一个分类下面，没有覆盖到，你应该重点去处理这一类的问题，通过这样的报告去给大家呈现出来。比如说像大家熟悉的bot，智能机器人知识运营体系。从体检得分到开始诊断，再到解决问题，解决问题的时候有不同来源的线上问答，像转人工、点踩问句、引导问句、未知问句，然后去做一些发现、拾贝、质检以及消歧。发现就是我从之前所有的数据里面或者知识里面去发现有没有知识可以解决这些我不知道的问题；拾贝指的是其实这些问题不管是客服也好用户也好，在回答的时候已经提到过这个知识点。那么我可以把它聚在一起，然后告诉你用户在对这类问题关心比较多，或者是客服这一类回答现在比较多，那么你可以把它做一些处理，其实这个就是一整个的知识运营体系，我们认为这个也比较关键。我们去构建AI引擎库的时候，机器会定期找出来很多专业的术语，你需不需要把它们做成你的术语库？大家会觉得这个运营的功能量会有点多，实际上做完这些之后，精细化的运营会对我们整个的服务建设有很大帮助。包括刚才讲的知识冲突的一些动态检测，一定要做【定期的人为诊断报告】。以专业化的知识咨询服务去看你的整体概况、匹配率、满意度、转人功率，包括你上了电话之后这个时间段的接通率，来电率是不是有下降，等等，以及去做这个知识的概况分析，比如说访问的离散度。某个家电的客户有几十万条知识，但是真正被问到的一些知识平均分布离散度基本上就聚焦在了几万条。其他的那些知识，对于整个系统的干扰是会存在的。这个时候我们就要人为的去降低那些静默知识或者长尾知识可能被访问的频次等等，包括对未知问题的一些分析，去做剧烈分析，去做的场景梳理，包括知识的学习，以及不满意度问题的分析。用户在什么样的场景下他会不满意？什么样的场景下他会转人工？他所有的记录是不是要做分析？一般会挑最高频的问题去做处理，包括词库分析，以及最后的一些优化解决方案等等，所以我们希望能够对一些数据做分析。
最后简单地提一下，从AI知识的引擎到数据运营，就是以知识AI的加工来赋能我们智能决策的效率。不光是做服务，也可以用这些服务的数据或者其他的分析去反哺后面决策的阶段。
比方说，AI能力层，算法层，模型层，每个行业每个地方都是不一样的。我们以前认为同样是工业设备就可以把工业设备的模型用在战斗机的场景中，后来发现战斗机的服务场景，其实跟工业模型的这种场景是完全不一样的，故障单出来的结果模型也是不一样。所以做这些模型的设计，就是希望我们客服去建立这样的模型。我一直在想怎么帮大家把客服的这种价值最大化。
像【电商】这样的场景，我们会有数据中台。比如说像会员基础数据、消费数据、行为数据以及一些会员的价值模型、消费偏好模型以及他的消费预测模型。所有这些做完之后，都要跟我们的知识做关联。数据一定要跟知识做关联，数据本身也是知识的一部分，因为做完关联之后，你就可以去模拟一个客服在不同用户的这种身份属性下应该用什么样类型的知识。这样不管是营销还是服务都会大大增加我们的价值。比如说我们某个【家电】的全平台评价分析流程。它可以从所有的节点将所有的数据全部都汇总到一起。然后通过这个节点去做两件事情，一个是分担派单。可能知乎上有个问题，需要营销部门，或者需要公关部门去回答一下，或者客服去回答；第二个是决策，就是把某个产品线的问题反馈到对应产品线，然后该哪个部门的问题就反馈到哪个部门，通过客服这样的一个数据分析就可以把整个集团的评价集中到一起。比如国外的一个家电品牌，我们做了一个NPS的标签分布统计。通过所有NPS的调查数据，可以看出来哪个数据跟哪个数据之间是有些关联的，包括这些分布占比等等。这些其实都是一些AI＋数据的运营分析。我们认为这些都是知识服务的一部分，也是通过数据运营提升我们客服价值很重要的一部分。最后【总结】一下，我们需要根据客户的需求去做AI的落地，而不是抱着单一的某项技术产品去套所有的企业。所以我们认为应该根据企业的知识和服务特点，去深度定制客服的一些智能化的策略，去符合场景。然后就是我们的一个愿景，就是一家合格的智能应用公司，首先应当是一家AI的咨询公司，帮助大家去把他的企业知识以及业务流程梳理清楚，然后一起来去做服务的升级。
