阿里小蜜：知识结构化推动智能客服升级

大家对智能客服应该都有一定的了解，智能客服在中国已经有很长的历史了，从 2007 年开始就有很多企业逐渐的应用了智能客服，这种智能客服，现在可以称为第一代智能客服。最近几年，很多大型企业，包括一些中小企业都希望升级到新一代智能客服。今天的报告分为以下四个部分：

• 新一代智能客服的主要需求是什么？

• 面对这些需求，我们主要的解决思路是什么？

• 基于结构化知识的解决方案。

• 使用这些解决方案的时候会得到什么样的收益。

智能客服升级的需求

首先看下智能客服升级的需求。

这个例子，大家一看就会明白，现在用很多智能客服的时候它都让你配很多标准问，然后再为每个标准问配很多的相似问。一些大型智能客服系统会有几千个标准问，每个标准问需要配很多相似问，才能得到差强人意的效果。这里举了一个简单的例子，比如问上海有多少人口，你可以给配置相似问，这些相似问用于覆盖同一个问题的各种可能的说法，因此最终系统可以将各种不同的 query 定位到同样的标准问上，进而可以给出统一的答案。

如果把这个句子中的“上海”换成“北京”呢？你又需要给它很多类似的说法。依此类推，这样需要配备的相似问数量是非常巨大的，你肯定不愿意这样蛮干。但是现在大多数智能客服系统，就是这么做的。所以维护客服系统的运营人员都是很没有成就感的，每天都在做大量重复性的工作。

这也是人们将人工智能诟病为人肉智能的主要原因。

我们可以把目前智能客服系统存在的问题归纳成两个痛点：

一是知识管理痛点。成千上万的知识点，缺乏关联，给知识运营和管理带来困扰，却又需要维护大量的相似问。其表现出来的两种现状：

• 设置多个知识点，答案细致，但知识管理任务重。

• 设置 1 个知识点，管理任务轻，但答案过粗。

这两种方法是两种极端，都没有很好的解决这个痛点，或者导致知识管理任务重，或者导致用户使用体验差。

二是语言理解难点。语言具有多样性、歧义性、复杂性、复用性、模糊性等特点。现在的系统即使使用了深度学习算法，也不能很好地解决复杂问题、模糊问题，在迁移到新的领域时也不能很好地复用原有领域的训练语料。

2017 年用户输入“上海有多少人口？”这样的问题时，机器人能够自动问答“2017 年上海的常住人口是：2419.70 万”，我们就可以认为机器人具有一定智能。在传统的智能问答（FAQ）中，知识运营的主要工作是为每个标准问题配置一定数量的同义问法，比如“上海有多少人口”“上海目前常住人口有多少”“上海市现在有多少人口”等等。对于“天津有多少人口”这个标准问题，再配置对应的同义问法，“天津有多少人口”“天津目前常住人口有多少”“天津市现在有多少人口”等等。

从传统智能问答到知识图谱问答，第一个重要变化是引入知识图谱，具体包括：

① 将实体归纳为实体类型：将“上海”归纳为“城市”类实体，将“2017 年”归纳为“时间”类实体；

② 将标准问题归纳成属性：将“[城市]有多少人口”映射到“城市”类实体的属性“常住人口”上；

③ 抽取实体-属性-值：将具体的知识组织成“(上海,常住人口,2419.70 万)”这样的包含简单属性值的三元组，进而组织成“(上海,常住人口,(2017 年，2419.70 万))”这样的包含复合属性值（CVT，Compound Value Type）的 N 元组。

第二个重要变化是在语言理解算法从分类或匹配算法改为 Semantic Parsing 算法。传统智能问答在语言理解部分只需要将用户问题映射为一个标准问题，而 Semantic parsing 则需要对用户问题进行深入理解，并输出一个结构化的语义表达式，可以直接从知识图谱中查询答案，或者经过推理后产生相应的答案。在语言理解算法的核心部分，Semantic Parsing 算法有三种主要的形式：

• seq2seq 的端到端方案

• 传统的 Semantic parsing 方案

• 多阶段的融合深度学习的 Semantic parsing 方案

知识结构化的主要思路

结构化的主要思路可以分为三个方面：

① 从非结构化业务文档或者半结构化的数据过渡到结构化知识图谱

② 从非结构化的用户表述解析出结构化的语义表达式

③ 从非结构的文本型答案升级为结构化答案

知识图谱的概念大家都比较熟悉，知识图谱实际上是网络化的结构。

知识图谱的构建一个非常复杂的过程，我们在内部有一套非常复杂的平台，从知识建模、挖掘、融合、编辑与管理到推理与计算，它用于构建和管理超级复杂的知识图谱。在构建服务于智能客服的知识图谱时，一般不需要使用这个超级复杂的知识图谱构建与管理平台，而是使用一个相对轻量级的、人机互助的知识图谱编辑和管理平台。

这是阿里巴巴商品知识图谱的示例，它把淘宝天猫中上百亿种商品构建成一个非常庞大的商品知识图谱，在淘宝和天猫平台治理、智能客服、导购等许多方面发挥了很大作用。

但是这种知识图谱的量与我们所要服务的个体企业的商品和服务在量级上是完全不可同日而语的。多数大型企业和机构能有几万种商品就已经相当可观了。

1. 构建结构化知识图谱

第一块，将非结构化的业务文档或半结构化数据转换成结构化的知识图谱。我们在 To B 的场景中，每一个企业都需要建立知识图谱，却不可能像建淘宝天猫商品知识图谱那样，投入那么多的时间和人力去建设，否则客户会觉得成本太贵了，承受不起。

但是知识结构化的目标仍然是可以以较低成本实现的。

这是一个很简单的文档的例子，为一个套餐提供了非结构化的表述。我们最终是希望从非结构化表述中整理出一个关于这个业务场景的 schema，它有实体类型、实体、简单属性/复合属性等。最后把各种实体的值都填上，就得到了这个场景的知识图谱。这个知识图谱对于客户来说通常不会很复杂，因为一般客户所提供的服务和产品均不会大于万这个量级，所以它的知识图谱不会特别复杂，构建成本也没有那么高。

这是为移动运营商做的知识图谱的一个简单示例。它的实体类型有流量套餐、话费套餐等，然后每个套餐下面有很多实体，实体下面有很多属性。

在建知识图谱的过程中，抽象出 Schema 是最关键的一步，包括归纳出实体类型以及各实体类型下的各种属性。智能客服厂商对客户的业务了解不够，客户自身对知识图谱的概念缺乏了解，因此沟通的成本较高。那么，应该如何快速构建一个定制化的知识图谱呢？一个非常简单而又有效的做法是从客户现有的 FAQ 知识库出发，快速地归纳 Schema 和知识图谱，比如这是我们内部的一个场景，原来大概有 700 个标准问，我们把它归纳完之后就变成了 70 个属性。

然后这个是移动运营商的场景，大概是有 4000 个标准问，归纳完之后是不超过 400 个的属性。

所以从知识管理角度来说，通过知识结构化可以大幅度降低知识量级，而且耗时比较短，成本比较低。

2. 结构化语义表达式

第二块是语义理解部分，把非结构化的用户 query 变成结构化语义表达式，就是我们通常所说的 Semantic Parser 的过程。

上面是一句话，我们希望得到这样一个结构化的表达，最上面是动词，下面有动词的客体，客体下面还有它的修饰成分。

3. 结构化答案

第三块，我们把原来非结构化的文本型答案变成结构化答案。

这是淘宝天猫双十一的一个问题，这个问题在不同的时间段，回答的答案是不一样的，所以我们就把它做成了一个时间性的结构化答案。用户在不同的时间段进来可以看到对应时间段的答案。

这是一个弹性的答案，用户可以问的很笼统，也可以问的很细。

知识图谱问答解决方案

我们的知识图谱问答解决方案主要可以分为三个方面：

① KAMR ( Knowledge-driven Abstract Meaning Representation )，是由我们提出的语义表达体系。我们参照的对象是 AMR 和 AMRL。

② KAMR Parser，基于 KAMR 语义体系的 Semantic Parser。KAMR Parser 是我们第二代的 Semantic Parser，上一代的 Parser 是 MulCG Parser。

③ 结构化问答平台，是以 KAMR 为核心的包括人工智能闭环在内的结构化问答平台，将 FAQ 问答和知识图谱问答融为一体。在上一代产品中，FAQ 问答和知识图谱问答采用两个不同的语言理解引擎。

1. 语义表达体系

语义表达体系方面我们参考的对象是 AMR ( Abstract Meaning Representation )，是由美国学者提出的语义表达体系，是一种通用的语义表达体系。AMR 的特点是将句子中的词抽象为概念，因而使最终的语义表达式与原始的句子没有直接的对应关系，这是它与语义角色标注、依存语法等的一个显著区别。AMR 是 2013 年提出来的，本身并不是全新的体系，但是到目前为止 AMR 仍然是自然语言处理学界对于深度语言理解的最好最系统的解决方案。

另外一个参考对象是亚马逊基于 AMR 提出的 AMRL，其语义表达形式与 AMR 一脉相承，但主要应用于任务型场景。

2. KAMR

通过上述参考，结合我们的业务场景，我们提出了基于知识驱动的抽象语义表达 KAMR，主要由 KAMR Ontology 和 KAMR Language 组成，KAMR 框架可以支持跨 domain 的 query、弹性粒度的 type、复杂的语义以及各种组合，进而可以支持精细理解、弹性理解和高效复用（从企业客户角度来说，非常注重高效复用，因为我们希望同一个场景中数据之间可以复用，跨场景也可以复用，以及跨客户复用，这样才能降低成本，提高效率）。

刚刚提到语言理解有很多痛点，我们的 KAMR 着力于解决四个方面的问题：歧义性、复杂性、复用性、模糊性。

这是 KAMR Ontology，包括谓词、算子、Type、Property 等部分，每个部分都是一个层次化的 Ontology。

这是 KAMR 语义表达的两个例子。KAMR 本质上是有向无环图。从表达能力上讲，它可以表达多谓词、省略、歧义、复杂约束条件、并列结构等各种复杂现象。

3. Semantic Parser

这是我们第一代的 Semantic Parser，其流程包含四个步骤：实体识别->属性分类->约束绑定->重排序。其中属性分类、重排序都使用了深度学习。目前很多做知识问答的系统，已经使用了端到端的系统，直接从 query 得到一个结构化的语义表达，但是这类系统在精度上离我们所采用的 Pipeline 方案有较大的差距。Pipeline 方案的优点是每一步都比较容易的进行人工的干预，精确度也远远的高于目前纯粹的端到端系统。端到端的系统对训练数据量要求非常高，我们在多数情况下还不能获取足够多的训练数据。因此，在这种情况下，Pipeline 的方式更为合适。

针对实际业务场景中遇到的问题，我们对第一代 MultCG Semantic Parser 进行针对性地系统改进，进而发展出第二代 Semantic Parser，即 KAMR Parser。它包含实体识别、属性识别、约束识别和 Semantic Dependency Parser 四个模块，每个模块的内涵与第一代 Parser 相比也有本质的变化。

① 实体识别

首先是实体识别，我们在一些场景中落地的时候，发现实体识别远远比我们想象的要复杂，比如中移动上有一些套餐，大流量 58 元套餐，本来这个实体叫大流量套餐就可以了，但是这个实体名被数字隔开了，这是我们之前没有遇到的。因此，我们引入了模型化的实体识别，这里模型采用的是比较常见的 BLSTM+CRF 模型。特别的地方在于，序列标签可以是不连续的，就可以把前面的 BD、ID 和后面的 ID 合成一个实体。

② 意图识别

更核心的是意图/属性识别部分，这里我们提出的是基于多因子的意图分类方案：

• 每一个意图由三维因子组成 ( domain，predicate，target )

• 每一个 query 由四维因子组成 ( domain，predicate，target，query type )

• query 的四维因子中的前面三维可以直接从它所属的意图继承而来，query type 则是个性化的，同一个意图下的多个 query 可以属于不同的 query type。

这是我们在某个业务场景下对意图进行多因子分析的例子，其中 none 表示有些因子的值可以为空。

这个是我们的多因子意图分类模型，主要包含两个模块，第一个就是编码核心，可选择诸如 CNN、LSTM、Gated CNN、Transformer 之类的方法进行 encoder。剩下的关键的就是把四维因子和原始 query 之间建立 Attention，通过因子与 query 之间的 attention 对 query 的表示进行引导，将与因子相关的部分进行增强。

当把一个意图拆解到因子这个粒度的时候，可以实现意图间的语料复用，因为一个场景中不同的意图是有些相同部分的，比如“办理”这个 predicate，可能出现在“办理方式”、“办理条件”、“办理时间”等意图中，这里的 predicate 都是一样的。之前把意图作为一个整体的时候，是没法利用 predicate 层的共享信息的。还可以解决不同意图语料之间不平衡的问题。

多因子意图分类，还可以发挥其他作用：

• 针对语义不清的关联推荐：比如用户提出了一个比较模糊的意图“公积金抵扣”，这时我们就可以给用户推荐一些关联的意图：组合贷款抵扣，商业贷款抵扣……。

• 上下文继承：用户在第一轮说了“医保”，可以解析出 domain 这一维因子。接下来第二轮说了“待遇”，可以解析出 target 这一维因子。把两者组合起来，就可以分析出“Domain:医保；Target:待遇”这样的意图。

③ Semantic Dependency Parser

在实体识别和意图识别阶段系统可以输出多个结果，可能存在多个实体、多个意图、多个约束条件以及算子，因此还需要有一个模块将多个结果组合起来形成一个完整的语义表达式。在此，我们使用的是基于 Biaffine 的 Semantic Dependency Parser。这是一个简洁高效的模型，但是速度很快，效果也很好，可以用来解决复杂问题，如多实体、多约束条件、多谓词多意图等。Biaffine Dependency Parser 本质上是一个基于最大生成树的依存分析器。

4. 结构化问答平台

这是我们的结构化问答平台的整体架构图，分为算法层和知识层两部分。这个平台中为客户可见的部分主要是 KG 编辑平台，包括知识图谱 Schema 编辑器和实体知识编辑器，以及目前服务于结构化问答的智能闭环已经投入使用，支持用户在线进行无答案或未解决问题筛选、人工标注、模型训练、评测、模型部署等。

知识图谱 Schema 编辑器的界面

知识图谱实体知识编辑器的界面

知识结构化的收益

基于我们的知识图谱问答（结构化智能问答）解决方法，可以为客户带来以下几个方面的收益：

• 高效复用：如果一个企业有几百种产品（实体），可以达到举一反千的效果；如果新增加一个或多个实体，无需新增相似问，直接把实体和属性的值填上，就可以生效；同时还实现了知识的瘦身，将知识点数量从 4000 减少到 400 左右；并且做到了同场景复用、跨场景复用、跨客户复用。

• 精准理解：通过 Semantic Parsing，KBQA 对问句的理解更加深入，它可以知道一个问句涉及到的实体是什么实体，属性是什么，带有什么约束条件。比如“3 元 5G 流量快餐包如何办理”这个句子中，实体是“流量快餐包”，属性是“办理方法”，约束条件是“流量=5G，资费=3 元”。传统智能问答在回答这类问题时，将不同档位的流量快餐包的答案聚合在一起输出给用户，答案冗长。KBQA 在精准理解的基础上，可以给出更细致的回答，直接回复“3 元 5G 流量快餐包的办理方法是：……”。

• 精细管理：当知识数量较大时，增、删、改、查将会成为一个难题。通过知识结构化，从实体、属性、CVT 子属性等多个维度对知识进行系统的梳理，知识的增、删、改、查将会更加便捷。

• 推理计算：在结构化知识的基础上可以进行推理和计算。比如，对于“阿里巴巴几岁了”这样的问题，在知识图谱中存储的具体知识三元组是（阿里巴巴，创立于，1999 年），KBQA 经过一个从创立时间到年龄的计算过程：年龄=当前年份-1999 年，即可计算出“阿里巴巴的年龄是：19 岁”。不需要每隔一年去修改一次答案。

总结

最后再小结一下今天报告的主要内容：

• 需求，分析了知识结构化的需求，包括知识管理和语言理解；

• 思路，知识结构化为分为知识图谱构建、语义剖析和答案展示三个方面；

• 方案，知识结构化的方案包括 KAMR 语义表达体系、KAMR Parser 及知识图谱问答平台三个部分；

• 收益，知识结构化解决方案带来的收益主要是高效复用、精准理解和精细化管理。

知识就是力量，结构化的知识更有力量。今天的分享到此结束，谢谢大家！

作者介绍：

邱立坤，阿里巴巴集团智能服务事业部算法专家。主要研究方向为知识图谱问答、语言资源构建及基础自然语言处理技术，担任中国计算机学会、中国中文信息学会专业委员会委员以及 ACL、EMNLP、COLING 等多个著名国际学术会议程序委员会委员。已在 AAAI、COLING 等国内外期刊和会议上发表学术论文 50 余篇，获中国发明专利授权 10 项，出版专著、译著各一部，主持国家自然科学基金项目 2 项及其它项目 20 余项。

本文转载自公众号 DataFunTalk（ID：datafuntalk）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247493403&idx=1&sn=9cd4a6d15687c52c4a02694538d6bca5&chksm=fbd75577cca0dc6196e23e6aa676ef8ee87362cbc8a627c0571af7089b7bec54111a4cf2b995&scene=27#wechat_redirect