老焦专栏 | 知识图谱建设方法论

​

《解开知识图谱神秘的面纱》这篇介绍了知识图谱的基本概念、应用知识图谱的三个层面，本文主要介绍知识图谱建设的方法论。

所谓方法论，我们可以用面向对象方法论做一个类比，大家知道面向对象从上世纪 90 年代起有OOA（面向对象分析）、OOD（面向对象设计）、OOP（面向对象编程）的方法；有以 UML为核心的可视化建模语言；最近流行的DDD（领域驱动设计）也是在 OOA/OOD/OOP 基础上提升。

参考面向对象的方法论，我们把构建知识图谱分为知识建模、知识抽取、知识验证三个过程，方法论就是对每个过程中所采用的方法。

1知 识 建 模

很多学术著作对知识建模和知识表示有所混淆，在知识建模这个部分往往介绍的还是 RDF、OWL这样的知识表示语言。在我看来这些描述语言类似面向对象的 UML，属于表示方式的标准；而建模是如何从知识中抽取出关键概念以及概念之间的关系的，类似面向对象设计中OOA/OOD、领域驱动开发（DDD）、四色原型法这样的方法论。

1、知识建模的三个主要部分

参考面向对象建模方法，知识建模可以分为知识边界划分、概念建模、关系建模三个部分。

如果大家了解领域驱动设计（DDD）的话，就知道所谓领域就是边界的划分。领域知识图谱的建设首先也需要做边界的划分。因为同样一个概念，在不同的语义环境下表示的事物是不一样的，例如“产品”，在市场（产品定义）、设计、制造、维修、营销这些子领域，都有不同的含义，也就是有不同的概念、关系，为减少知识建模的复杂度，需要进行子领域的划分。

通常，针对每一个专业领域，子领域会是完全不同的，貌似没有规律可言，但是按照我们的经验，可以将知识的子领域分为拓扑结构、数据准备、事件、处置四个大的类型：

1）拓扑结构是指人、组织、物体、地点这些可标识的事物，包括事物的概念（也可以说是概念或者术语）、属性以及它们之间的关系；

2）数据采集是指如何收集、检验拓扑结构所需要的概念（术语）；

3）事件是指拓扑结构上可标识事物产生的事件，包括各种类型的事件、事件源、事件表象、属性等；

4）处置是发生事件后的处置动作，例如故障产生后的应急处理、营销事件产生后的促销行动。这四种类型指知识图谱建模中必须要涉及的部分，只是每个部分在不同领域的具体分类不一致而已。

概念建模与关系建模类似面向对象的对象建模，都是对客观世界的总结与抽象。概念/属性建模与面向对象中类的定义非常类似。

面向对象的关系默认有继承(泛化Generalization)、实现(Realization)、依赖(Dependency)、关联(Association)、聚合(Aggregation)、组合(Compostion)几种类型，但在知识建模中，需要对关系进行更加深入的抽象。例如我们在银行智能风控领域建立知识图谱，关系就包括显性关系（担保、投资等）、隐形关系（同一自然人、亲属关联、注册地关联、贸易链关联、生产经营影响等），这种关系的归纳对于知识推理与呈现具备重大的意义。

关系的归纳往往是一个难点，因为经验告诉我面向对象建模中，关系的建模往往比较随意。

2、知识建模的一个示例

领域知识图谱的建设，对业务的理解最为关键。往往对业务有深入理解的人，未必掌握知识图谱应用建设的知识，因此我们的方法论就是如何在业务与 IT 之间建立一个沟通的桥梁。这里举一个实际的知识图谱建模实例，以便更好的说明。

大家知道，大型装备例如军舰、飞机、雷达、导弹等故障定位与维修是一个比较复杂的事情，经常同时收到大量的故障信号，例如多处温度升高、震动等等，利用这些故障信号如何快速的进行故障定位，就是一个知识图谱解决的问题。

我们首先对装备与故障进行建模，然后将已有的故障维修记录、装备设计要求等信息进行知识的抽取，形成知识图谱，当故障发生时利用图谱进行推理，找到故障的具体位置。良好的知识建模，是知识抽取的基础，在故障检测这个场景中：

1）首先进行领域知识的划分，我们把知识分为“装备域”（也就是拓扑结构）、“测试域”（也就是数据准备）、“故障域”（对应事件和处置两个域，实际上在这个领域，事件主要是装备的故障），所有的知识会分解到这三个领域；

2）装备域的概念抽象主要是对装备功能的抽象，做为形成装备拓扑结构的基本要素，一个装备分解为部件、元件，这就是装备的基本组成要素。每个部件/元件预期行为的描述称为功能，具体的功能类型是可以归纳出来，例如分离（使能量或者物质分离）、引导（使能量或者物质从一个位置到达另一个位置）、连接、控制、转换、提供、信息、停止、维持等类型。这些类型还需要细分，例如信息类型就有探测、显示、说明、测量、处理、感应、跟踪这些子类型。部件/元件都有输入、输出，这也可以理解为功能之间的连接，包括能量、物质、信号三大类型，对他们也可以进行抽象：能量有电能、电磁能、机械能、液压能、热能、振动能等等，物质有液体、气体、固体，信号包括模拟、数字等等，每种有相关的属性，例如输入/输出为液体的时候，属性包括密度、压力、流向、流速...，有了这些概念就可以从知识的角度描述具体设备的拓扑结构了；

3）故障域是对故障原因、故障机理、故障模式和故障征兆的抽象，例如故障机理包括腐蚀、疲劳、材料分解、材料退化、磨损等等，故障征兆包括形状变化、外观变化、行为变化、温度、振动、空气噪声、液体噪声、模拟信号、数字信号等等，故障原因可以从装配、设计、维修、制造、操作运输等方面考虑进行细化，有了这些概念就能够描述具体装备出现的故障，推理出解决方案。

4）测试域是如何从装备中采集数据，反应装备的情况，例如测试条件、测试资源配置（厂家、检测站、基层用户...）、测试代价（时间或者费用），有了这些概念就可以描述出装备如何采集测试数据，根据测试数据来体现故障情况。

从上面的例子看出，没有专业的经验是没有办法构建知识图谱的，一个知识图谱的应用，花在业务抽象和知识图谱构建的时间应该在 60% 左右，具体实现技术和功能反倒是其次。其实这也是我们在软件研发中经常遇到的问题，在领域驱动设计的方法论中，第一步就是建立业务与技术语言的统一，实际上就是这个过程就是一个知识图谱建模的过程。

目前业界的研究，很多都是利用 NLP 语义分析等技术，抽取热点词汇，再辅以人工修正的方法。这是一个”自下而上“的方式，可以做为知识图谱建模的辅助手段，而这里介绍的是一种”自顶向下的方式，我强烈建议以”自顶向下“方式为主，因为领域知识图谱的建设，不了解业务不能抽象基础的业务模型，是不可思议的。“自下而上”的方式只能做为”自顶向下“方式的补充。

2知 识 抽 取

如果把知识建模类比为面向对象的建模，已经确定了类、属性、关系以及存储方式，知识抽取可以类比为数据的录入。从这个角度看，“抽取”这个词并不准确，因为知识除了从现有资料中“抽取”之外，还需要将持续产生的知识积累到知识图谱中，未必是“抽取”。

但是，知识图谱建设中，很重要的一个环节就是将现有知识进行结构化处理，形成知识图谱，这里我还是保留知识抽取这个词，做为这个阶段的名称。

很多文献中把知识抽取按知识来源划分，分为结构化数据、半结构化数据、非结构化数据的抽取：

• 结构化数据抽取指将已经具备元数据信息的数据进行转换（例如数据库），将知识存入知识图谱；
• 半结构化数据往往指网页中的表格列表；
• 非结构化的数据主要是文本、例如操作手册、法律法规、文献等等。

从知识抽取的内容上，又可以分为实体抽取、属性抽取、关系抽取、事件抽取：

• 实体抽取指从数据源中检测到可命名的实体，并将它们分类到已建模的类型中，例如人、组织、地点、时间等等；
• 属性抽取是识别出命名实体的具体属性；
• 关系抽取是识别出实体与实体之间的关系，例如从句子“著名歌手周杰伦的妻子昆凌”中识别出“周杰伦”与“昆凌”之间的夫妻关系；
• 事件抽取是识别出命名实体相关的事件信息，例如“周杰伦”与“昆凌”结婚就是一个事件。可以看出实体抽取、属性抽取、关系抽取是抽取我们在知识建模中定义的拓扑结构部分数据，事件抽取是事件建模相关数据的抽取，所以在领域知识图谱建设中，也需要包括数据准备域的抽取方式、处置域的数据抽取方式。

在知识图谱领域，理论界关注的重点在自动化的抽取、从海量非结构化数据的抽取，因为他们希望解决的问题往往是建立通用的知识图谱，因此从文本中抽取知识图谱的方法在文献中最常见，这里我们首先介绍这种方法。实际上在领域知识图谱的建立，是在已有领域知识建模基础上进行的，因此能够合理利用人工、自动等混合方式进行：

1）基于知识建模的基础，很多知识图谱的项目我们都是根据现有的文字材料，例如操作手册、法规等等采用人工录入的方式进行知识抽取。知识建模建立的基本概念模型，都可以整理出一定的句式，例如对故障的描述，就是“出现 XXXX 现象”，故障定位于“XXXX”部件，故障原因是“XXXXX”类型，处置办法是“XXXX”模式，制作一个简单的录入工具，采用人工对录 + 复核的方式就可以完成绝大多数的工作，而且工作量并不大。

2）可以通过自动化方式减少人的工作量，例如自动抽取一部分，由人工进行确认。无论结构化数据、半结构化数据、非结构化数据的数据，首先考虑的是规则与模板的方式，例如将数据库的元数据（Schema）映射为知识图谱的概念就是一种规则的方式。

可以用模板方式实现规则。例如从文本中抽取夫妻关系的实体，观察到包含夫妻关系的例句：a）【周杰伦】与妻子【昆凌】晒儿子合照b）【周杰伦】的老婆【昆凌】现在过着怎样的生活？就可以定义两个模板：a）【X】与妻子【Y】b）【X】老婆【Y】利用这两个模板中就可以从文本中建立实体间关系。

通常理论界提到文本抽取，都会提到自然语言处理 NLP (Natural Language Processing)技术，这个技术在领域知识图谱建设中必然会使用，主要在非结构化数据的抽取中。但是NLP技术相关的方面比较多，包括中文自动分词、词性标注、句法分析、自然语言生成、文本分类、信息检索、信息抽取、文字校对、问答系统、机器翻译、自动摘要等很多分支，我们可以使用业界现有的一些 NLP 软件进行分词，然后利用模板或者规则进行抽取。例如，我就使用了 Hanlp （https://github.com/hankcs）进行分词处理，然后根据名字、动词的类型，再利用规则抽取知识。

由于非结构化数据的随意性，需要经常丰富规则和模板，例如'1#'压水堆、'1号'压水堆、“一号”压水堆这三个词是一个意思，就需要在规则中体现出来。

句式的总结很重要，例如建立人力资源的知识图谱，在描写专业技能标准的时候，通常的格式是“根据/基于【X】 + 能够/善于 + 角色【Y】 + 行为方式【Z】 + 行为内容【A】”，“根据公司战略、年度规划，善于调动相关资源，协调各方面关系，组织部门业务流程优化”。这一段话中，我建议可以从 5W1H （Why、What、When、Where、Who、How）的模式总结句式，'公司战略、年度规划'就是 Why，“善于调动相关资源，协调各方面关系”就是行为方式，也就是What，行为内容是 How 是组织部门流程优化，没有When、Where、Who，可以从其他部分补充。How是一个需要进一步总结的句式，这也是为什么有 5W2H、5W3H 的原因。

在领域知识图谱建设中，抽象句式建议利用一些经过总结的素材，例如总结报告、述职材料、设计文档、培训材料、宣讲材料、KPI考核，这些材料往往经过了人为的总结，更容易提炼出句式特征。

3）对于一些非结构化数据特别多的情况，可以考虑采用统计模型的特征法、基于深度学习的方法抽取命名实体，通过标注数据训练有监督学习模型进行关系、事件的抽取。对于通用知识图谱建立来说，这些方法还具备一定挑战，但在领域知识图谱建立中相对容易使用。

4）我要说明的是，不要迷信自动化手段，尤其是基于深度学习、有监督学习这一类的自动化手段，有时候笨办法也许是最直接的。例如，在某电子装备维修的知识库建设中，有积累 5 年的故障维修记录，用人工整理录入的方式知识库的建设一共用了几个月时间。对比我们在建设一个信息系统，也往往需要这个时间，周期与投入并不大，只不过比较繁琐而已。实际上深度学习、有监督学习这类方法也需要大量的数据标注，在领域知识图谱建设中经常并不节省人力成本。

上面是从文本中抽取知识的做法，但在领域知识图谱的建设中，除了政策法规、操作手册等文件之外，还有很多其他的来源。

例如在装备故障领域，装备的拓扑结构可以来自于装备的设计，实际上装备在设计过程中形成的拓扑结构，用在故障定位是一个非常好的输入。再如金融行业风险管理的知识图谱建设，需要构建相关企业之间的关系，前面也讲到隐形关系、显示关系，这些可以从工商、税务等数据源获取。

你会发现，管理好这些知识来源，能够把数据的准备与知识图谱的建设形成一个闭环，必将极大的提高工程化水平。

3知 识 验 证

从各种不同数据源抽取的知识，并不一定是有效的知识，必须进行知识的验证，将有效的、正确的知识进入知识库。造成知识不准确的原因，通常是原始数据存在错误、术语存在二义性、知识冲突等等，例如前面提到的'1#'压水堆、'1号'压水堆、“一号”压水堆这三个词对应一个实体，如果在抽取中没有合理定义规则，这就需要在知识验证阶段得到处理，以便形成闭环。

最常见的知识验证就是专家评估法，将每一条知识由专家进行确认，或者利用业务定义一些质量评估规则，进行验证。

知识验证是一个比较复杂的事情，同样需要花费专家很多精力和时间。如果我们把知识建模对比为面向对象建模，知识验证可以类比为面向对象系统的测试，与测试不同的是，知识验证往往不存在明确的规则，只能由专家验证正确与否。如果打算提高知识验证的效率，就需要建立验证的模式，提高验证的自动化率。

在领域知识图谱的建设中，通常会存在很多固定的信息或者知识，我们可以将这些信息做为知识验证的基础，类似数学证明中的公理。当年 NASA（美国国家航空航天局）就是利用这种原理来解决知识验证的问题。NASA有大量的故障处理知识，而且这些知识（数据）又是不断产生的，采用人工确认的方式工作量太大，这些故障往往仅出现一次，又无法用大量数据做为机器学习的基础。对于大型装备，它的拓扑结构是已知的，对于新的知识可以采用一定的推理算法，如果与装备的拓扑结构有冲突，再由人工进行分析与确认。例如某个位置发生振动，但是根据拓扑结构没有关联的部件能够产生这种故障，就可以认为存在问题，由人工进行判断。具体如何进行知识推理，我们会在后面介绍。

本篇主要介绍了知识图谱建设中知识建模、知识抽取、知识验证的方法，下一篇我们会介绍基于知识图谱应用的几种类型，同时用一个装备故障自动检测的示例解读知识推理类应用。

- The End -

关于作者：焦烈焱，普元信息CTO，致力于技术创新和金融创新解决方案研究。专注于企业技术架构领域，对分布式环境的企业计算、 企业信息架构的规划与实践有着丰厚经验，带领普元技术团队相继在云计算、大数据及移动开发领域取得多项突破，并主持中国工商银行、中国建设银行等多家大型企业技术平台的规划与研发。

关于EAWorld

微服务，DevOps，数据治理，

移动架构原创技术分享。