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

6个月前

构建知识图谱分为知识建模、知识抽取、知识验证三个过程。

转载本文需注明出处:微信公众号EAWorld,违者必究。

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

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

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

知 识 建 模

很多学术著作对知识建模和知识表示有所混淆,在知识建模这个部分往往介绍的还是 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 年的故障维修记录,用人工整理录入的方式知识库的建设一共用了几个月时间。对比我们在建设一个信息系统,也往往需要这个时间,周期与投入并不大,只不过比较繁琐而已。实际上深度学习、有监督学习这类方法也需要大量的数据标注,在领域知识图谱建设中经常并不节省人力成本。

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

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

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

知 识 验 证

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

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

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

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

- The End -

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

关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。