知识图谱构建(入门)

一、什么是知识图谱?

知识图谱是由 Google 公司在 2012 年提出来的一个新的概念。从学术的角度,我们可以对知识图谱给一个这样的定义:“知识图谱本质上是语义网络(Semantic Network)的知识库”。但这有点抽象,所以换个角度,从实际应用的角度出发其实可以简单地把知识图谱理解成多关系图(Multi-relational Graph)。

二. 知识图谱的表示

知识图谱应用的前提是已经构建好了知识图谱,也可以把它认为是一个知识库。这也是为什么它可以用来回答一些搜索相关问题的原因,比如在 Google 搜索引擎里输入“Who is the wife of Bill Gates?”,我们直接可以得到答案 -“Melinda Gates”。这是因为我们在系统层面上已经创建好了一个包含“Bill Gates”和“Melinda Gates”的实体以及他俩之间关系的知识库。所以,当我们执行搜索的时候,就可以通过关键词提取(”Bill Gates”, “Melinda Gates”, “wife”)以及知识库上的匹配可以直接获得最终的答案。这种搜索方式跟传统的搜索引擎是不一样的,一个传统的搜索引擎它返回的是网页、而不是最终的答案,所以就多了一层用户自己筛选并过滤信息的过程。

三、知识抽取

知识图谱的构建是后续应用的基础,而且构建的前提是需要把数据从不同的数据源中抽取出来。对于垂直领域的知识图谱来说,它们的数据源主要来自两种渠道:一种是业务本身的数据,这部分数据通常包含在公司内的数据库表并以结构化的方式存储;另一种是网络上公开、抓取的数据,这些数据通常是以网页的形式存在所以是非结构化的数据。

前者一般只需要简单预处理即可以作为后续 AI 系统的输入,但后者一般需要借助于自然语言处理等技术来提取出结构化信息。比如在上面的搜索例子里,Bill Gates 和 Malinda Gate 的关系就可以从非结构化数据中提炼出来,比如维基百科等数据源。

信息抽取的难点在于处理非结构化数据。在下面的图中,我们给出了一个实例。左边是一段非结构化的英文文本,右边是从这些文本中抽取出来的实体和关系。在构建类似的图谱过程当中,主要涉及以下几个方面的自然语言处理技术:

a. 实体命名识别(Name Entity Recognition)

b. 关系抽取(Relation Extraction)

c. 实体统一(Entity Resolution)

d. 指代消解(Coreference Resolution)(c,d难度更大)

四、知识图谱的存储

知识图谱主要有两种存储方式:一种是基于 RDF 的存储;另一种是基于图数据库的存储。它们之间的区别如下图所示。RDF 一个重要的设计原则是数据的易发布以及共享,图数据库则把重点放在了高效的图查询和搜索上。其次,RDF 以三元组的方式来存储数据而且不包含属性信息,但图数据库一般以属性图为基本的表示形式,所以实体和关系可以包含属性,这就意味着更容易表达现实的业务场景。

100

根据最新的统计(2018 年上半年),图数据库仍然是增长最快的存储系统。相反,关系型数据库的增长基本保持在一个稳定的水平。同时,我们也列出了常用的图数据库系统以及他们最新使用情况的排名。 其中 Neo4j 系统目前仍是使用率最高的图数据库,它拥有活跃的社区,而且系统本身的查询效率高,但唯一的不足就是不支持准分布式。相反,OrientDB 和 JanusGraph(原 Titan)支持分布式,但这些系统相对较新,社区不如 Neo4j 活跃,这也就意味着使用过程当中不可避免地会遇到一些刺手的问题。如果选择使用 RDF 的存储系统,Jena 或许一个比较不错的选择。

101

五、 金融知识图谱的搭建

接下来我们看一个实际的具体案例,讲解怎么一步步搭建可落地的金融风控领域的知识图谱系统。 首先需要说明的一点是,有可能不少人认为搭建一个知识图谱系统的重点在于算法和开发。但事实并不是想象中的那样,其实最重要的核心在于对业务的理解以及对知识图谱本身的设计,这就类似于对于一个业务系统,数据库表的设计尤其关键,而且这种设计绝对离不开对业务的深入理解以及对未来业务场景变化的预估。 当然,在这里我们先不讨论数据的重要性。

102

一个完整的知识图谱的构建包含以下几个步骤:

1. 定义具体的业务问题  

2. 数据的收集 & 预处理    实体对齐

3. 知识图谱的设计  

4. 把数据存入知识图谱  

5. 上层应用的开发,以及系统的评估。

6.1 定义具体的业务问题

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwwwzg.html