解语：如何从零样本做中文文本知识标注与挖掘？

小编：圣子更新时间：2022-08-21

分享嘉宾：赵岷百度研究员

编辑整理：张存旺

出品平台：DataFunTalk

导读：在产业应用场景中，缺乏通用知识库、标注数据建设代价大、研发人力成本高，是阻碍知识图谱进行落地应用的主要困难。今天分享的《解语：从零样本开始做中文文本知识标注与挖掘》，针对这类应用痛点，提供了从知识库到工具的通用解决方案。主要分享内容如下：

解语介绍
解语：百科知识树
解语：文本标注与挖掘
总结与展望

解语介绍

首先介绍什么是解语，以及为什么要发布解语。

1. 百度语言与知识技术开放平台

上图是百度发布的语言与知识技术开放平台，该平台主要面向百度内部的开发者以及外部的用户，为使用者提供一系列的数据模型、各种能力引擎以及场景定制服务。其中，“知识中台”是基于知识图谱的技术平台，之所以称为知识中台而不是图谱中台，是因为知识图谱本身是一类技术，而不是具体的应用，知识中台解决的是如何用知识来辅助搜索、问答、推荐、推理等真实应用，在这个过程中知识图谱起到了技术支持的作用。目前，“知识中台”已经作为百度对外发布的正式产品，服务于各行业的企业用户。

今天分享的“解语”，在整个语言与知识技术开放平台中属于底层工具，和具体的应用任务相对解耦，是基础的中文文本知识标注工具集，可用于各类中文文本标注和知识特征生产任务，进而支持上层的图谱构建和文本计算，还可辅助各类NLP模型优化样本。

2. 发布解语的背景

企业用户在构建自己的知识库时，往往会遇到许多困难，例如：

开源知识库不适配领域数据：很多开源知识库不能适配企业内部的或者领域行业的数据。
缺少训练可用的样本数据：虽然有很多开源大模型，但是当样本缺少的时候，模型训练效果不佳，而构建样本的成本和人力都非常高，导致模型很难获得理想的效果。
企业知识挖掘困难：构建高质量的知识图谱的难度和投入是非常大的，企业一般都希望能低成本地先构建一个知识库来看它怎么去使用，这个过程中一开始很难投入充足的人力和算力，导致项目启动非常困难。

基于以上考虑，我们发布了解语，协助大家真正能够从零样本开始做中文文本知识标注与挖掘。当然，要构建一个完善的知识图谱是非常高成本的事情，不可能完全依赖零样本完成，解语更多的是协助用户解决从零到一的关键一步，当项目可以启动并展现出应用效果的时候，自然就可以获得更多的资源和算力去构建更完善的图谱以及支持更多的应用。

3. 解语的框架

上图是解语的框架，这套工具和数据集已经在飞桨（PaddlePaddle）平台对外开源，欢迎大家使用和反馈。

解语的英文名叫TextToKnowledge，意思是从文本到知识，主要包括三部分内容：

百科知识树（TermTree）：它是覆盖中文全词类的词类知识体系，基于全量百度百科词条以及搜索query构建，已在搜索及广告等大规模产业应用中使用并得到验证，适合通用领域应用。
中文知识标注工具集：目前发布了两个工具，中文句子标注工具WordTag，以及中文名词短语标注工具NPTag。在解语官网可以直接试用，这些工具都是经过大规模产业应用验证的。
中文预训练语言模型：WordTag和NPTag模型所使用的中文训练语言模型是我们自己开发的ERNIE-CTM模型，这个模型主要针对中文挖掘任务研发。因为现在经常使用的开源中文预训练语言模型如BERT等收录的汉字只有几千个，在挖掘应用尤其是领域应用中，经常遇到不在常用汉字范围内的生僻字或长尾汉字，导致在挖掘中出现大量无法识别的UNK。在做分类或者推荐任务时UNK问题可能不重要，但是在挖掘中却是很致命的问题。ERNIE-CTM使用的token集收录了两万多个汉字，基本覆盖了百度百科里面所包含的汉字，这样模型就可以更好地完成中文文本挖掘任务。

解语：百科知识树

下面介绍解语的第一部分，百科知识树。

1. 背景

百科知识树和业界一般讨论的知识图谱不太一样，知识图谱更偏实体，通常是针对领域中的特定类型实体，比如人、电影、音乐、疾病等构建实体属性值或实体关系。但是在做通用域文本理解时，除了领域知识，还需要考虑一个问题：中文理解是否需要通用知识？为了界定这个问题，我们可以考虑这样的假设：如果没有事先构建的实体知识库，是否还能理解语言？答案自然是肯定的。

举两个例子：比如，阅读一本小说，假设这是一本架空小说或者科幻小说，书中出现的实体，不管是人、事物，还是事件，都是事先不知道的，但是读者仍旧能够通过阅读这本小说得到这些实体知识；再比如，两个知识背景不一样的人，如成年人和小孩，外国人和中国人，或者不同专业的人，背景相差特别大，但是还能够互相交流。这证明了，在实体知识库之外存在通用知识，使得人们能够理解未知文本，互相交流。既然存在这样的通用知识，那么接下来的问题就是通用知识是什么、怎么表述、怎么使用。

通用知识库或者说常识库的构建是非常困难的，学界和工业界已经研究了几十年，到目前为止仍然没有一个完善的通用知识库能够被普遍应用在文本理解中。

既然通用知识构建这么难，那有没有可行的解决思路呢？解语的思路是把这个问题简化，先做最基础的部分，然后再考虑扩展到更高层的通用情况上。即从中文的词汇理解和句子理解的角度出发，探索通用知识表征与应用的问题。

具体思路是借鉴人的语言习得过程：人类幼儿在开始学语言时，最先学到的是常用词汇以及词汇的归类组织关系，理解什么是什么；然后学会把词汇拼装成句子，理解和使用句子；最后再学会做更复杂的阅读和交流任务。受启于这个过程，我们将词汇理解和句子理解拆解为三层：

第一层：构建一个通用且相对稳定的中文词汇知识体系。
第二层：将文本与词汇体系相关联。
第三层：让算法对中文句子的理解能力更接近于人。

沿着这个思路，来界定中文句子理解到底需要什么样的通用知识。解语的切入点是：如果一个人看到一个句子，但并不知道这个句子涉及的事实知识（比如描述的是某个人干了什么事情），那么对这个句子的理解至少包括以下三层：

首先理解句子中都有哪些词；
然后能理解这些词大概的意义是什么，比如出现了一个不知道的词，但通过句子描述大概猜出这个词指的是一个人还是一件事；
接下来理解这些词之间的语义关系，并且与脑海中已有的知识体系相关联。

这是构建知识所考虑的切入点，主要是从词类语义入手来构建通用知识库。

接下来特别强调一下词类语义对中文文本理解的重要性。传统中文解析任务是参考英文的，除了底层的分词以外都是仿照英文做词性标注和句法分析，但是在中文上通常达不到英文的效果，这是因为两个语言的根本不同。

英文中最有名的一个词汇知识库是wordnet，它是按名词、动词、形容词和副词来分类组织英文单词的。因为wordnet非常普及，所以很多人想仿照wordnet构建中文的词汇知识库，但是发现没办法实现，因为英文的特点是词性和句子成分是一一对应的，名词在句子中就是主语和宾语，动词是谓语，形容词是定语，副词是状语。

但这个一一对应关系在汉语中不能稳定成立，汉语的词兼类现象非常严重，一些词汇学研究者称之为“词无定类，或类无定职”现象。其意思是，在汉语中，如果固定某个词的词性，那么它在句子中承担的角色将不再稳定，反之，如果固定了某个词在句子中的角色，比如固定为主语，那么它的词性将不稳定。这就意味着在中文文本处理任务中，词性和句法的特征不足以支撑语义理解，需要比词性和句法特征更强的语义特征。

2. 百科知识树（TermTree）

基于以上的考虑，我们构建了通用知识库，叫百科知识树，英文是TermTree。它的特点之一是把所有的中文词汇在这个体系下进行统一的描述和计算，既包括常见的概念词、实体词、专名术语，也包括语法词。其中，实词是按语义类别组织的，虚词是按词性组织的。这个体系是树状的有向无环图，这种结构的好处是可以做严格的上位推断，路径是稳定的，而且覆盖全量的汉语词汇。

另一个特点是把知识库拆解成了两部分：一个是通用的固定的概念集；一个是可插拔替换的实体集。这种设计方式的好处是当不知道实体知识的时候仍然可以使用，因为在语言当中通用概念语义是相对稳定的，这样两个知识背景不同的人才能够互相交流。而实体级的语义是很不稳定的，比如“孤儿”这个实体词在不同应用中可指代不同事物，可能是书、电影、小说、歌曲等等。实体集一般是可替换的应用知识图谱，用户在使用时可替换为自己领域或内部知识图谱，然后和通用知识关联使用，这样就可以既利用已构建知识，同时又适配自己的应用。

在上面的例子中：通用知识库中的“孤儿”是一个人物类概念，这个词在文本中是语义稳定的，应用知识图谱中的“孤儿”是一个电影的名字，主要在电影相关的文本中使用。通用概念集和应用定制的实体集结合起来，就可以构造一个适配应用的图谱。

有的用户可能会问：为什么不能提供一个适用各个领域的通用实体集？我们认为这样的实体图谱不存在。

很多开放域的实体知识图谱声称是通用的，但所谓的通用仅仅是把开放域的百科全都放进来，但没有考虑百科本身的缺陷。例如，百度百科可以算是开放域规模最大的中文知识库，但它仍有一个明显的问题：规模越大，就越有偏。真实文本中的实体是个长尾分布，百科对热门实体的覆盖是相对全面的，对越不热门的实体的收录越少。也就是说，百科每收录一个实体，可能就会有大量同名实体未被收录。比如全世界有几十亿的人，而百科仅仅收录了百万级的人。因此，文本中出现的绝大部分实体并不能被百科覆盖到，比如各个企业中的员工姓名就覆盖不到。

通用百科还有一个问题，就是长尾实体的属性值缺失严重，通常热门实体如娱乐人物的属性值非常丰富，但长尾实体如一个普通人，属性值会大量缺失。这种情况就经常导致把文本中的不属于百科收录的实体错误地链接到百科收录的实体上。在一般的图谱应用，比如最典型的实体链接（Entity-Linking）或知识库问答上，有个普遍现象：当实体库和文本集一致的时候，能取得好的效果；如果不一致，效果则无法保证。如果用一个大的预训练模型充分拟合百科知识，然后再去做QA问答，就会有类似的问题，比如问赵丽颖的丈夫是谁，模型回答是冯绍峰；然后再问赵丽聪的丈夫是谁，也会回答是冯绍峰。为什么呢？一般有两种情况：一个是赵丽聪这个词本身没有在百科中收录；另外一种情况是收录了，但是属性值缺失，所以模型会把一个实体的属性值错误地拟合到另外一个实体上。这也是为什么特别强调实体知识库是需要根据应用定制的，这样才可能避免不适当的实体链接或属性拟合。

3. 基于百科知识树的词类体系定制

目前发布的百科知识树是TermTree V1.0版。主要包括两部分，一个是词类体系，包括termtype和subtype：termtype是对中文词汇集的全划分，有160多个；subtype是便于应用扩展的一个细分类别，有7000多个。用户可以利用这个词类体系筛选、构建自己的体系。如果用户的词类不在该体系内，可以通过扩展subtype的方式，把自己的subtype挂接在给定的termtype上，就可以很方便地把自己的词表整合到这个体系上。

TermTree V1.0版的规模是100万左右，包括常用概念和高频实体。其中常用概念是50万，标识用source=cb，c是concept的意思，常用概念中的termtype归类准确率是98%，覆盖了中文文本中大多数的常用概念，可以视为通用任务中最核心的集合；另外也提供了大概50万的高频百科实体作为辅助示例，标识用source=eb，协助用户在没有自己实体库时先用这部分来尝试一些基础的应用，高频百科实体的termtype归类准确率是95%。

以上是开源百科知识库的内容，下面讨论一下怎么利用这个知识库去做中文文本的标注挖掘。

解语：文本标注与挖掘

1. 简介

上图是解语的应用框架：基于百科知识树构建知识标注工具集，对文本进行词类序列标注，并和百科知识树相关联，再基于标注结果进行知识挖掘。目前发布了两个中文文本标注工具：句子粒度的WordTag以及名词短语粒度的NPTag。基于这两个工具和百科知识树，可以实现零样本的词类体系定制，领域词表构建，以及挖掘模板构建。这两个工具均可通过PaddleNLP (https://github.com/PaddlePaddle/PaddleNLP) 的Taskflow接口进行一键调用。

下面先介绍WordTag。

2. WordTag：中文句子标注工具

WordTag抛弃了传统中文解析的分词、词性标注和命名实体识别，改为基于百科知识树的知识标注。传统中文解析一般是先分词再做词性标注，然后针对部分类目做NER识别。WordTag则是对输入的句子直接进行词类序列标注，并将已收录的词汇关联到百科知识树。

WordTag提供了两个一键调用接口：一个是knowledge_mining，可以在词类序列标注之后link到百科知识树；一个是ner，只做词类序列标注，不做百科知识树关联，这个接口可以让用户直接把WordTag当做分词或命名实体识别（NER）工具来使用。

WordTag标注体系已有几十个词类，如果你的NER识别范围与之一致，可以直接基于这个结果做NER；如果不一致，也可以基于它和百科知识树的词类关系先识别出大类，然后再用其他方法识别出小类，或者把不同的类组合起来使用。

WordTag传送门：

https://github.com/PaddlePaddle/PaddleNLP/tree/develop/examples/text_to_knowledge/wordtag

对文本做词类序列标注之后，需要把标注结果和知识库相关联，也就是做Term-linking。在知识图谱中关联到文本这个任务叫实体链指或实体链接（Entity-linking），由于解语处理的对象不限于实体，也包括概念词、语法词、术语等，所以把这个任务叫做Term-linking，以避免误解。

Term-linking和Entity-linking的实现方式不同，如上图所示：

Entity-linking是在给定文本和KG（知识图谱）的情况下，通过Mention识别、候选实体选择、实体消歧来完成Entity-linking。从Mention识别这一步，就需要通过知识库识别文本中同名的片段，然后在片段中挑选候选实体，再做消歧。这个方案只适用于文本和实体知识库比较一致的领域应用，没有办法做到通用域，因为通用域会有大量无法link的未收录实体。如果实体信息缺失，就容易把文本中出现的一个同名片段错误地link到已收录实体上。
Term-linking把linking问题拆解为两步：第一步是在得到WordTag标注的文本词类序列之后，直接基于词类序列标注结果做link，因为已经有了词类划分，所以就不用考虑词类间的消歧问题；第二步是对同词类下的实体进行消歧计算，这一步可以复用Entity-linking的实体消歧算法，这样就可以把实体消歧这个复杂困难的任务限定在同类下的同名实体消歧，从而降低任务难度、提升计算效率。

这里再强调一下产业应用和学术界算法研究的区别：

做算法研究的时候一般隐含了一个先决条件，就是这个任务不能太简单，否则效果已经足够好，没有算法的改进空间了；但是产业应用恰恰是希望要处理的任务越简单越好，这样才可控、应用效果好、效率高。

在产业应用中，如果任务能用简单的规则完成，就不需要模型；如果小模型能完成，就不用大模型；如果能用base版的大模型完成，就不会用各种魔改的transformer。在应用中会追求模型的可控性、性价比，希望尽可能把真实需求的任务难度降低、效率提升，从而以更低的成本更好的效果满足用户的需求。

3. NPTag：中文名词短语标注工具

下面介绍第二个工具NPTag。NP指的是NounPhrase，名词短语。做完WordTag标注之后就发现，即便做了Term-linking还是会有大量文本中的词是没收录因而link不上的，未收录词也是文本语义计算的难点。在中文中未收录词主要是名词及复合名词短语，由于中文的词汇不像英文有各种形态变化，名词的组合特征特别明显。对于规范的复合名词，通常人基于常识看到这个词就能判断出它的类别。我们基于这个现象研发了NPTag工具，可以不依赖于上下文直接对于任何输入的复合名词预测其类别。WordTag是针对句子标注的，NPTag是在短语粒度来协助识别未收录词的语义，因此也可用于在应用层结合WordTag辅助做挖掘。

NPTag的预测模型是基于Prompt-Learning机制的，Prompt-Learning机制能更好地利用预训练语言模型的特性。NPTag的训练样本是基于百度百科义项分布来构建，覆盖了名词的全词类。NPTag预置了2000多的细粒度类别（与百科知识树相关联），可以直接用来给用户的词表标注词类体系。WordTag标注出来的词类，也可以利用NPTag打上细粒度的标签。

NPTag虽然已经预置了很多的细粒度类别，但不可能覆盖应用中所有的类别。如果用户想要预测不在体系中的类别，需要先构建目标类的一个小样本集，然后在已有模型上继续训练，这样就可以很方便地去做定制化的扩充。所以这是一个在名词短语上比较好的分类框架，现在可以通过PaddleNLP一键调用。

NPTag传送门：

https://github.com/PaddlePaddle/PaddleNLP/tree/develop/examples/text_to_knowledge/nptag

上面介绍了解语目前发布的两个中文文本标注工具，下面用一个简单的demo示例来演示一下怎么样利用解语来去做挖掘。

4. 文本知识标注与应用Demo

首先基于百科知识树定制自己的知识库，对要处理的中文句子进行WordTag标注，打上词类标签，可以link到知识库上，也可以不link。基于标注结果可以直接做模板生成和匹配，这也是应用上比较重要的一个功能。

在标注结果中，可以利用词类特征去掉不需要的词类，构造成一个模板。比如模板是<作品类实体, 肯定词=是, 人物类实体, 场景事件=创作,作品类概念>，通过这个模板，就可以召回一系列同类句子，然后通过这个句式去挖掘或这类的SPO知识。WordTag本身功能是文本词类序列标注，但是使用WordTag可以相对简单地半自动生成挖掘模板来辅助挖掘更复杂的知识。

这个示例是语义一致性判定。中文中很多文本是有歧义问题的，比如孤儿可以是作品类实体、人物类概念，如果不加限定就很容易把它们都识别成同一个。很多场景下都需要语义消歧，比如在搜索应用中，对于一个query怎么知道answer和query中的实体是不是同一个。通过词类标注可以识别出不在同一个词类下的同名词，可以简单判定为语义不一致；如果是同一个词类下的实体，往往难以仅通过句式特征判定，可能需要结合挖掘出的实体SPO特征计算。

因为已经对输入文本进行了切分和词类标注，并且还link到了知识库上，这样就可以得到输入文本的词类特征或者知识库特征。这些基础文本特征可以用在相关的下游任务上，比如作为机器学习模型的样本特征输入以提升模型效果。

上图是文本知识标注应用的小结，总结一下刚才的流程：首先构建知识库，基于这套知识库去做文本标注和知识关联，即WordTag标注和Term-linking，然后再基于知识关联去做应用，如模板生成和匹配、知识特征生成等等。这里再强调一下模板生成和匹配，现在很多任务中的基础模型逐渐迁移到了端到端的深度学习模型，在很多场景下能够获得更好的效果。但在实际应用中，考虑到效率、精度、成本、可控性，模板匹配仍不可替代，比如离线高精度文本挖掘、在线query解析等，模板匹配和深度学习模型结合使用，是比较常见的应用模式。

端到端模型的可解释性是个难题，直接根据输入得到最终的结果，出现case很难分析和干预。同时在很多知识应用中，是需要理解整个推断步骤的，比如医疗诊断，模型直接输出一个诊断结果是不可信的，必须一步步从知识库中找到支持结果的证据才能让用户接受。在很多企业任务中也是这样，一个决策是需要有知识来支撑才能让决策者去做最终的判定。所以在很多行业应用中会用规则模板的方法和深度学习模型结合起来使用，对于高精、可解释任务，用模板来保证它的准召，然后再利用深度学习模型扩大覆盖面，整体获得应用上最优的效果。在挖掘中也是这个样，简单的模板可以帮助挖掘规范的文本，复杂的文本可以用深度学习模型，或者把两边的结果进行聚合处理得到更佳的效果。

总结与展望

1. 解语的使用流程

解语可以协助大家从零样本开始做中文文本知识标注和挖掘，主要步骤如下：

通过开源的百科知识树选择应用需要的词类来构建自己的知识体系；
利用WordTag和NPTag标注文本并关联到知识体系上；
整合标注结果，通过统计聚合或者是模板挖掘来构建更复杂的领域知识。

如果更有经验或者有更多的人力和算力投入，还可以继续进一步定制解决方案，适配具体应用，比如：

已经挖掘了一些应用词表，经过校验可以把它整合到开源百科知识树中，去掉不需要的词类，添加新的词表来构造一个更适合自己应用的词类体系和知识库；
如果WordTag和NPTag标注的词类不满足应用的需求，可以增加自己的词类，重训模型。例如，利用WordTag标注企业文本，基于知识库对标注结果纠错，再利用纠错后的标注结果重新训练WordTag模型，获得更适配应用的标注结果。

现在提供的工具主要是支持非模型的挖掘方式，比如统计聚合、模板挖掘，有很多用户希望能够提供一套比较简单实用的关系挖掘模型，我们也在研发中，后续也会持续发布。

2. 讨论：符号知识的作用

最后简单讨论一下符号知识的作用。

目前有很多声音说现在已经是超大规模预训练语言模型的时代了，一个趋势就是Language Models as Knowledge Bases，也就是说假设超大规模的预训练模型可以计算所有的文本，那是不是这些文本中所有的知识已经被模型记下了，不需要再去构建知识图谱，直接查这个模型就好了？那显式的符号知识构建的知识库还有必要吗？

近几年关于这个问题的争论和研究非常多。早年的符号知识挖掘研究，比如ConceptNet这类知识库，其中很多自动构建的知识都是从文本中显式挖掘构建的描述性知识，准确度也不太高，这类知识在现在的预训练模型框架下已经能够比较好地捕捉到了，显然就不再是知识构建的核心目标。符号知识要发挥自己的作用，肯定需要能够与预训练模型协同互补，互相弥补对方的不足，协同应用达到好的效果。目前看来主要有两个方向：

一个是提升展现效果，增强可解释性和可控性。目前深度学习模型的一大问题就在于不可控、难以解释。如果能构建出来特别精准的知识图谱，那么就可以很好地帮助用户去理解想要的搜索结果。在很多行业应用中，比如典型的医疗场景，用图谱知识辅助增强结果的可解释性是非常必要的。
还有一个讨论比较少但是更为重要的方向，就是去提升计算和存储的效率，减小搜索空间。比如经典的符号规则，规则不仅是可解释性，而且计算和存储的效率是非常高的。规则可以准确覆盖给定条件下的无限数量的样本，这个特点是目前各类统计模型无法达到的，因为模型没办法做无限样本，只能进行采样，这就会导致有样本bias，最后很难在同等精度下达到规则覆盖的效果。

解语除了以百科知识树的方式提供一个可解释的知识库，另一个主要目标是提升中文文本处理效率。文本空间的一个核心问题是词汇数量无限，因为文本是词的组合，会造成组合爆炸，导致没有办法枚举所有的知识点（这也是通用域知识图谱无法成功的原因）。

怎么降低文本空间的描述复杂度呢？解语的方案是放弃枚举任务空间中无限的知识点，转而用有限的词类去概括无限的词，这样就可以对任务空间进行一个完整的词类划分，通过建立统一的词类体系，把文本的“原始词序列表示”表征成文本的“词类序列表示”，从而降低任务复杂度，同时还可以很好地和预训练语言模型所记忆的知识互补。

预训练语言模型可以高效地捕捉语料共现的相似性，有很好的泛化性，对于任意文本都可以计算它们之间的相似关系和距离，在这个基础上支持各类应用。词类知识本身是基于常识知识的空间划分，和预训练模型捕捉的文本相似性是不同类型的知识，两者度量不同，正好可以互补。

3. 词类知识与预训练语言模型的协同

上面所讲的就是解语主要考虑的：构建并利用知识，让它可以和预训练语言模型达到更好的协同，使得应用效率更高、效果更好。具体地，

预训练语言模型为各类任务提供更好的分类、序列标注或者挖掘模型。在这个基础上，一方面可以利用知识做更好的知识挖掘、文本标注和模板生成，另一方面也可以利用知识对深度学习模型的结果做一致性校验，提升准确性。
知识还可用于辅助优化模型样本。因为现在的趋势是预训练模型比较稳定，大家用的任务模型结构都比较类似，应用效果的好坏主要依赖于样本集的构建质量：一是怎么构建优质的大规模样本；二是怎样发现最有价值的小样本来降低人工样本标注的成本；三是怎样发现已有样本的case，提升样本准确率。

总结起来就是：