智能客服的非结构化知识库图谱化改制

基于结构化数据的知识图谱问答系统已经非常成熟，并被广泛应用于搜索引擎及智能客服中。本文对这里面的内容不在进行赘述，主要为大家介绍传统客服知识库如何进行图谱化改制及具体的应用。

知识图谱简述

知识图谱，其实是知识工程这门学科的延伸，它将知识通过三元组的形式相互勾连起来。通过实体之间的相连的边，定义出实体之间的关系。机器人通过实体识别解析出用户问句中的实体，以识别到的实体作为父节点，通过遍历逻辑找出图谱中对应的实体和关系，进而推理出用户所需的答案。

接下来我们通过构建一个简单的知识图谱来简单表示图谱的知识推理流程

图1.schema示例

如图，我们构建了“姚明”和“叶莉”两个person entity，他们之间有一对相互的边，这对边的关系为“夫妻”。那么我们就可以能够根据知识图谱的结构化数据进行一个简单的知识推理。

Q：“姚明的老婆是谁”

A：“叶莉”

当然，这样基础的问答已经被搜索引擎广泛应用

图2.搜索引擎实用示例

如果说深度学习让机器人有了更好的理解能力，那么知识图谱就是给了机器人推理的能力。人们可以通过定义实体与实体之间的关系，从而让机器进行知识的推理。

但是图谱在应用中也存在着一定的劣势，首先就是对结构化数据的依赖性，由于构建图谱是一件成本很高的工作，因此目前更多的是依赖现有的结构化数据进行机器自动构建，自动构建对于非结构化数据的处理，目前应用仍然存在准确率的问题；其次便是实体识别的准确性，只有实体识别准确，图谱的推理才能是有效且有用的，而当实体的粒度及图谱构建的广度到了一定时，如何在大量的实体中精确命中就成了问题；还有就是遍历的逻辑，知识图谱的推理依赖的就是遍历逻辑，合适的遍历逻辑才能使得图谱的推理合理准确；最后一点就是实体歧义性问题，在客服会话场景中，用户描述会隐含部分信息，例如，绑卡，这个“卡”可以是电话卡，也可以是银行卡。

非结构化知识库图谱化的好处

很多人会有一只疑问，既然目前智能客服准确率已经能够达到了八九十的水平（目前各大公司宣传）那么为什么还要花功夫去构建知识图谱呢？

用户意图不清、上下文

相似度模型计算的是用户问句与知识库中问句的相似度，这是一种单轮的问答对匹配，然而实际的场景中用户经常会表述不清或者的表述会带有上下文的关系，例如：

图3.上下文对话

很多人认为这可以通过上下文的技术去解决，然后目前的上下文技术更多的是通过配置的词类与句式实现的。这就导致了：

1.难以完全覆盖线上用户的问法

2.句式之间的冲突问题

因此我们可以通过将知识库进行图谱化，解决用户意图表述不清的问题。当用户表述不清无法获取答案时，我们将识别到的实体组合成交互话术，向用户进行反问。

知识库补全过滤

除了解决用户表述不清、上下文问题，图谱还能通过实体的组合，遍历出所有可能的知识点，补全库中缺的知识点，还可以通过实体组合找出知识库中重复问句。一般客服知识库积累是来源于坐席客服日常工作的积累，是一个多人参与维护的知识库，不同人对同样问句的表达会有偏差，这就导致了库中存在一定比例的重复标准句，例如，有的标准句叫：XXX是什么，YYY是什么意思

提高解析正确率

熟悉短文本相似度模型的人都知道，用于训练的样本量是会影响特征在问句中的权重的。例如，“无法转账”这个问句的训练预料可能有上千句，但是“无法转账提示银行卡余额不足”这个问句的训练预料可能就只有20多句。那么模型训练后，就会存在用户说：“转不了钱，说是银行卡里没钱”，由于“无法转账”的特征权重过高，而预测出“无法转账”。然后知识图谱的实体识别就能够通过识别用户问句中的实体，遍历出正确的结果。

知识图谱在非结构化知识库中的应用难点

功能很美好，但是如何将传统的客服知识库进行图谱化改造确实一个难题。智能客服一般都是在原有的客服知识库基础上通过深度学习的方式训练短文本相似度模型，实现准确问答的。客服知识库一般是一个被维护到稳定状态的知识库，虽然有的知识库会有知识点分类，将标准问句根据知识点的层级关系进行分类，但是这也是一种非结构化数据。客服知识库的图谱化与常见的知识图谱还是会有一定的区分：

1.知识库图谱化更多是的基于语义的抽取，而非答案的抽取

2.知识库图谱化是一个有边际的图谱，层级会限制在一定范围内

3.知识库图谱化的实体不一定只是一个词，也可能是一个短语，例如：提示绑卡失败

在我们图谱化的工作中以下几个具体的问题就是我们要解决的：

1.schema构建问题：在开始做之前，我们先要明确我们需要构建的schema框架、边的类型及定义。schema的构建直接决定了图谱的交互逻辑及遍历逻辑

2.实体抽取问题：如何定义实体、实体如何从大量的标准句中抽取出来

3.遍历逻辑：当我们命中到了实体后，如何进行遍历，及遍历后的交互如何设计也是需要考虑的

4.实体不同阶段名称不同：同样的事、物在整个业务的不同阶段的称呼会存在差别，而用户不会进行这么细致的区分，例如：银行卡在绑定后进行理财时叫理财卡，进行支付操作是叫支付卡

5.业务复杂导致的实体歧义性：当app业务交叉较多时，会出现这种情况，例如：卡可能对应的话费卡，也可能是银行卡

6.schema的时效性问题:由于客服知识库是持续维护更新的，维护包括了新增、删除、合并、挑战，那么图谱也需要同步更新。如果图谱未进行对应的更新，那么就会存在新知识无法图谱不认识，删除了的识别出来无法获取答案。

图谱化流程

schema构建

构建图谱的第一步就是先确定图谱的结构。定义结构我们可以先根据知识库中现有的标准句，确定图谱构建的层级。一般我们会将图谱构建成三层的主框架，分别为业务、框架、类型

例如：花呗还款失败，我们会拆解为：花呗-还款-失败

图4.三层框架

当我们有了基本的基本的主框架结构后，基本上就能够覆盖线上大部分常见问题，但是这并不是我们解决问题的主要方式，因为还有很多句子并不是这样的简单句，例如：账户余额还花呗失败怎么办，这时我们相对于上面的标准句，增加了一个条件，即：账户余额。那么我们可以在主框架的基础上增加一层的子实体，这个子实体可以是业务，也可以是框架的下位。

图5.子实体框架

实体抽取与定义

当我们定义好了schema的框架和边之后，那么我们剩下的工作就是把标准问进行拆拆拆了。当我们拆分时，我们需要做好拆分的定义文档，避免实体的重复，例如，当我们定义好了一个动词，为开通，通过如下的文档备注，就可以避免其他抽取实体的将开展也作为一个实体进行标注。

图6.实体定义

这里给大家介绍两个实体抽取工具（应用前应先明确实体的定义，避免抽取时混乱）

1.词共现

我们可以通过词共现算法对所有的问句进行处理，这样我们就可以很快得筛选出业务下面的框架、子业务实体，框架下的类型及子框架

图7.词共现结果标注

2.句式结构拆分

句式结构拆分，即我们通过句式的结构将标准问进行拆分，当标准句句式比较规范时，我们可以采用，适合有知识库维护标准的业务方。

图8.句式结构拆分

实体识别

知识图谱的实体识别目前业界已经有成熟的方案，这里不再作赘述。但是在智能客服的场景中的应用，考虑到上下文的情况，上一轮识别的实体结果也是下一路实体识别的输入之一。

图8.NER

遍历、交互逻辑

遍历的逻辑设计，是根据实体识别的结果进行设计的，由于采用的是三层的结构，因此一共会有三类识别结果：只解析到一层实体；解析到两层实体；三层实体都解析到。这里我们进行分开讲述

1.一层实体

解析到一层实体时，我们不用考虑解析到的具体情况，我们可以直接将识别到的结果解析反问，例如：您是遇到了花呗的什么问题

2.两层实体

当解析到两层实体时就会存在两种情况：一种是两个实体之间存在边连接；另一种是两个实体之间不存在边进行连接。当它们之间存在边连接时，那么我们可以将同样具有着两个实体的路径实体拿出来进行交互

图9.交互示例

如果两个实体之间没有边连接，那么我们就只能拿置信度高的实体作为遍历的起始节点，交互逻辑和只解析到一层实体一致。

3.三层实体

当解析到三层实体时，那么存在的情况就会有三种：一种是三个可以组成一个标准问；一种是其中两个有变进行联系；还有一种则是三层实体均无边进行连接。第一种情况时，那么我们可以直接给用户一个答案作为回应；第二种情况则交互逻辑同解析到两层实体一致；第三种情况则交互逻辑与解析到一层实体一致。

解析方案设计

图谱的解析和短文本相似度解析是并发的结构，这就类似于融合模型一样，通过多套解析方案的融合，使得解析的效果达到一个理想的状态。

图10.解析融合

图谱和相似度模型的解析效果是一个交叉的，所以我们通过对两个解析结果的组合，就可以实现正确率的提升。当两个解析结果一致时，我们给出一个结果；当其中一个有结果，一个无结果时，我们给出一个预测结果；当他们给出了不一样的结果时，我们通过评估得出的阈值，给出预测的结果；如果两个模型都没有结果时，我们认为解析失败，机器人进行兜底。

图11.解析预测结果

我是小尾巴~

感谢你们的阅读。如果这篇文章对你有帮助，有劳点赞、收藏、订阅专栏。你们的关注，是我持续更新的动力。

本文中的例子，部分为引用，部分为虚构，侵删。

历史文章：

1.《你想知道的电话智能客服都在这了》http://www.woshipm.com/ai/1113496.html

交流可以加QQ：512055279