知识图谱查询和推理计算技术

一、知识存储与查询

1、知识图谱的图模型

  • 知识图谱以图的方式来展现实体、实体属性以及实体之间的关系。
  • 目前知识图谱普遍采用语义网框架中RDF模型来表示数据。
  • 语义网的核心是构建以数据为中心的网络(Web of Data),相对于目前万维网(Web of Pages)。
  • 语义网的核心是让计算机能理解文档中的数据,以及数据与数据之间的语义关联关系,从而使得机器可以更加智能化地处理这些信息。
  • 语义网可以看作一个全球性的数据库系统(Web of Data)
  • RDF是用于描述现实中资源的W3C标准,被设计为提供一种描述信息的通用方法,从而可以被计算机应用程序读取并理解。
  • 现实中的任何实体都可以表示为RDF模型中的资源。资源以唯一的URI(统一资源标识——Uniform Resource Identifiers,通常使用的 URL 是它的一个子集)来表示,不同的资源拥有不同的 URI。这些资源可以用来作为知识图谱中对客观世界的概念、实体和事件的抽象。,通过属性和关系,很多资源就被连接起来形成了RDF数据集。
  • 每个资源的一个属性及属性值,或者它与其他资源的一条关系,都被称为一条知识。属性以及关系就能表示成三元组。每一条三元组又可被称为一条陈述。一条陈述包含三个部分,通常称之为主体、谓词和宾语。其中主体一定是一个被描述的资源。谓词可以表示主体的属性,或者表示主体和宾语之间某种关系。当谓词表示属性时,宾语就是属性值,通常是一个字面值;否则,宾语是另外一个资源。
  • 我们可以将 RDF 数据分别表示成图的形式。RDF 的图模型包含了 RDF 数据中涵盖的语义信息。在这个图中,每个 RDF 资源或者 RDF 数据集中出现过的字符串可以被视为图上的点,每个三元组可以视为连接主体及客体的有向边,而三元组中的谓词就可以视为有向边上的标签。从语义角度上看,RDF 数据本质上就是通过预先定义的语义构成的一个或多个连通图。
  • 现有的RDF数据存储与查询的基本问题就是:给定一个 RDF 数据集 G 和SPARQL 查询 Q,找出 Q 在 G 上的匹配。当 RDF 数据和 SPARQL 查询都转化成图的形式,SPARQL 查询语句的查询结果就是其所对应的查询图在 RDF 数据图上的子图匹配。

2、研究内容和挑战

  • RDF结构具有灵活性,RDF数据管理的一个核心问题是如何有效存储和查询大规模RDF数据集。在查询处理过程中,我们需要将 SPARQL 查询图中变量与 RDF 数据图上点进行绑定以得到所有 SPARQL 查询图在 RDF 数据图上的子图匹配。
  • 知识图谱数据管理的一个核心问题是如何有效存储和查询RDF数据集。有两套完全不同的思路:
    • 其一是利用已有关系数据模型存储和管理知识图谱数据,将面向RDF数据的SPARQL查询转换为面向关系数据库的SQL查询,利用已有关系数据库产品或相关技术回答查询。核心研究问题是如何构建关系表来存储RDF数据并使得转换的SQL查询语句查询性能更高。
    • 其二是直接开发面向RDF知识图谱数据的Native的知识图谱数据存储和查询系统(Native RDF 图数据库系统),考虑到 RDF 数据管理的特性,从数据库系统的底层进行优化。

(1)基于关系数据模型的RDF数据存储和查询

  • RDF数据采用三元组模型,易于完成对关系模型的映射,从而可以尝试使用关系数据模型来设计RDF存储方案。
  • 简单三列表
    • 系统通过维护一张巨大的三元组表来管理RDF数据。
    • 三元组表包含三列,分别对应存储主体、谓词和客体(或主体、属性和属性值)。
    • 系统接收到用户输入的 SPARQL 查询时,将 SPARQL 查询转化为 SQL 查询。然后,根据所得 SQL 查询,通过对三元组表执行多次自连接操作以得到最终解。
    • 优点是具有很好的通用性,最大的问题是查询性能差。首先这张三列表的规模可能非常庞大。而且这种方法可能会产生大量的自连接操作,而在关系数据库系统中自连接操作非常耗时,特别是对于那些数据规模很大的表而言。所以这些方法都有很大的局限。
  • 水平存储
    • 将知识图谱中的每一个RDF主体表示为数据库表中的一行,表中的列包括该RDF数据集合中的所有属性。
    • 这种策略的优点是设计简单,同时很容易回答面向单个主体的属性值的查询(星状查询),SPARQL查询时没有耗时的连接操作,从而查询效率比较高;但缺点也很明显:(1)表中存在大量列,一般来讲属性数目会比主体和属性值的个数少很多,但是还是有可能超过当前数据库能够承受的数量。(2)表的稀疏性问题,通常一个主体并不在所有的属性上有值。相反,主体仅仅在极少量的属性上有值,使得表中将存在大量空值,空值不仅增加了存储负载,而且带来了其他的问题,比如增大了索引大小,影响查询效率。(3)水平存储存在多值性的问题,一个表中列的数量是固定的,这就使得主体在一个属性上只能有一个值。而真实数据往往并不符合这个限制条件。(4)数据的变化可能带来很大的更新成本。在实际应用中,数据的更新可能导致增加属性或删除属性等改变,但是这就涉及到整个表结构的变化,水平结构很难处理类似的问题.
  • 属性表
    • 为了降低自连接操作次数,可以利用属性表对RDF数据管理。具体而言有聚类属性表和分类属性表。
    • 聚类属性表:通过聚类的方式将一些类似的三元组聚类到一起,然后将每一个聚类的三元组统一到一张属性表中进行管理。
    • 分类属性表:利用RDF资源的类型信息将三元组进行分类,相同类的三元组放到同一张表中。
    • 对于上述两种情况,由于 RDF 数据表示的灵活性,会存在部分三元组无法放入任何一个属性表示。此时,将这个三元组另起一张表来进行管理。同时,并不是属于某个属性表的每个资源在各个属性上都有值,所以属性表中可能存在若干位空的位置。
    • 属性表有先天性的缺点:(1)虽然属性表对于某些查询能够提高查询性能,但是大部分的查询都会涉及多个表的连接或合并操作。对聚类属性表而言,如果查询中属性作为变量出现,则会涉及多个属性表;对属性分类表而言,如果查询并未确定属性类别,则查询会涉及多个属性表。(2)RDF 数据由于来源庞杂,其结构性可能较差,从而属性和主体间的关联性可能并不强,类似的主体可能并不包含相同的属性。这时,空值的问题就出现了。数据的结构性越差,空值的问题就越发明显。(3)在现实中,一个主体在一个属性上可能存在多值。这时,用 RDBMS 管理这些数据时就带来麻烦。其中,前两个问题是相互影响的。当一个表的列数目减小时,对结构性要求较低,空值问题得到缓解,但查询会涉及更多的表;而当表的列数加大时,如果数据结构性不强,就会出现更多空值的问题。
  • 垂直划分策略
    • 对RDF数据按照谓词(或属性)分割成若干表。
    • 将RDF三元组按照谓词(或属性)的不同分成不同的表,每张表能保存在谓词(或属性)上相同的三元组。
    • 这种方法的优势在于能避免大量的自连接操作,而变成不同表之间的连接。因为在现有的关系数据库中不同表之间的连接操作要快于自连接操作,所以 垂直划分能一定程度提高效率。但是,垂直分割缺点在于无法很好地支持 SPARQL查询中某个三元组模式在谓词(或属性)上是变量的情况。
  • 全索引策略
    • 简单的三列表存储的缺点在于自连接次数较多,为提高简单三列表存储的查询效率,有全索引策略。
    • 为加速RDF三元组在SPARQL查询处理过程中的连接操作速度,将三元组在主体、属性、客体之间的各种排列下能形成各种形态构建都枚举出来,然后为它们构建索引,这样建立的索引恰好是六重索引。这些索引内容正好对应 SPARQL 查询中带变量三元组模式的各种可能,于是就能很好支持 SPARQL 查询。
    • 虽然用全索引策略可以弥补一些简单垂直存储的缺点,但三元存储方式难以解决的问题还有很多:(1)不同的三元组其主体/属性/属性值可能重复,这样的重复出现会浪费存储空间。(2)复杂的查询需要进行大量表连接操作,即使精心设计的索引可以将连接操作都转化为合并连接,当 SPARQL 查询复杂时,其连接操作的查询代价依然不可忽略。(3)随着数据量增长,表的规模会不断膨胀,系统的性能下降严重;而且目前此类系统都无法支持分布式的存储和查询,这限制了其系统的可扩展性.(4)由于数据类型多样,无法根据特定数据类型进行存储的优化,可能会造成存储空间的浪费(例如,客体的值可能多种多样,如URI、一般字符串或数值。客体一栏的存储空间必须满足所有的取值,而无法进行存储优化)。为了解决这个问题,目前的全索引方法都是利用字典方式将所有的字符串和数值映射成一个独立的整数 ID。但是这种字典映射的方法很难支持带有数值范围约束和字符串中的子串约束的 SPARQL 查询.

(2)基于图模型的RDF数据存储和查询

  • 通过将RDF三元组看作带标签的边,RDF数据自然的符合图模型结构。
  • RDF数据的图模型可以最大限度的保持RDF数据的语义信息,也有利于对语义信息的查询。这种情况下SPARQL 查询就可以视为在 RDF 数据图上进行子图匹配运算。
  • 子图匹配运算是图数据库中一个比较经典的问题。其问题定义在于给定一个数据图和一个查询图,找出数据上所有与查询图子图同态的位置。这个问题已被证明是一个 NP 难问题。
  • 针对RDF数据的SPARQL查询已经有一些基于图模型的查询处理系统(如gStore、dipLODocus[RDF]和TurboHOM++),它们都是利用RDF数据图的特点来构建索引。
  • gSrore
    • 对RDF数据图进行二进制编码,根据每个资源的所有属性和属性值将其映射到一个二进制位串上,将所有位串按照RDF背后对应的图结构组织成一颗签章树VS*-tree。VS*-tree被分为若干层,每一层都是整张 RDF 数据图的摘要。基于 VS*-tree,gStore 可以完成高效的数据存储、更新与查询操作。当 SPARQL 查询进入时,将每个查询点在这个 VSTree 上进行检索,找到相应候选解,然后再将这些候选解通过连接操作拼接起来。
    • gStore 系统和目前使用最为广泛的 RDF 知识图谱存储查询系统 Virtuoso 和Apache Jena 之间的查询性能对比情况。由于基于图结构方法的索引可以考虑到查询图整体信息,因此总的来说查询图越复杂(例如查询图的边越多),gStore 相对于对比系统的性能会更好,有的可以达到一个数量级以上的性能优势。
  • dipLODocus[RDF]
    • 同时利用RDF图结构与考虑数据分析需求的混合存储模式。
    • 利用RDF数据图结构,挖掘出RDF图中的若干存储模式,然后将RDF数据图中满足这些存储模式的结构存在一起。
    • 考虑数据分析需求,就是利用列存储技术存储数值型数据,即将满足某个存储模式的所有结构中特定位置的数值按列存储组织在一起以方便聚集性查询处理。
  • TurboHOM++
    • 将子图匹配的技术应用到了 SPARQL 查询处理上。
    • 具体而言,TurboHOM++首先将 RDF 数据图基于每个资源的类信息转化为一般的普通数据图。然后,TurboHOM++在 SPARQL 查询图上从一个选定查询点出发做宽度优先搜索,得到一颗树宽度优先搜索树。同时,TurboHOM++在数据图上从选定查询点候选出发结合宽度优先搜索树深度做深度优先搜索,得到选定查询点候选的候选区域,并在这个候选区域中结合一定匹配顺序找到最终SPARQL 查询的解。

2、技术展望与发展趋势

  • RDF具有灵活性,越来越多的知识图谱数据提供方将自身的知识图谱数据表示成 RDF 格式并发布到互联网上,数据通过URI相互链接,共同构成一个庞大的覆盖整个互联网的知识图谱,描述了整个互联网上的知识,互联网从一个文档的网络转化成一个(计算机可理解的)数据的网络。
  • 随着互联网上RDF知识图谱数据集数量与规模的日益增长,利用分布式数据库系统相关技术进行RDF数据上的查询处理成为未来研究的趋势。
  • 现阶段,部分研究人员也已经有设计并实现了一些针对 RDF 数据的分布式查询处理方法。这些方法可以被分为三类:一类是基于已有云平台的分布式查询处理方法;一类是基于数据划分的分布式查询处理方法;还有一类是联邦型分布式 RDF 数据查询处理方法。

(1)基于已有云平台的分布式查询处理方法

  • 利用已有云平台存储管理系统进行关联数据的存储,并利用这些已有云平台上成熟的任务处理模式进行查询处理,现有的被用来进行查询处理的云平台系统包括Hadoop、Trinity等。
  • 因为基于已有云平台的查询处理方法利用了现有的云计算框架,所以这些方法都有很好的可扩展性与容错性。但是,由于之前云计算框架很多并未针对 RDF 数据管理进行特殊的优化,所以这些方法进行查询处理的效率不高。
  • Hadoop
    • 现有基于 Hadoop 的 RDF 数据上的分布式查询处理方法将 RDF 数据转化为平面文件存储在 HDFS 上。在进行查询处理的时候,这些方法将查询分解成若干子查询。每个子查询通过在 HDFS 上的扫描得到候选解,然后用MapReduce 将候选解连接起来以得到最终解。不同方法之间主要区别就是 RDF 数据转化 HDFS 平面文件的方式不同。
    • SHARD以数据中的主体为核心进行数据划分,把一个主体相关的所有三元组聚集在一起并存储成HDFS文件中的一行。
    • HadoopRDF火热P-Partition都以RDF数据中的属性为核心进行存储,把相同属性的所有三元组聚集在一起并存储在一个HDFS中,HadoopRDF还利用客体的类型信息进一步划分RDF数据。
    • EAGRE提出了一个基于实体类型的存储模型将 RDF 数据中所有主体视为一个实体,进而将 RDF 数据图压缩成一个实体图;然后,将相似的 实体聚类成一个实体类,进而形成一个压缩实体图。把这个压缩实体图存储在内存,并利用已有图划分方法得到划分结果,把这些实体以及相应三元组放到不同机器上。同时,每个实体是按照实体类来排序并存在 HDFS 中。
  • Trinity
    • 微软研发的基于内存的分布式图数据管理系统。
    • Trinity.RDF将 RDF 数据图的邻接表载入 Trinity 的内存云中。当用户提交查询之后,Trinity.RDF 依次对查询中每个变量 v 的候选点 u 进行图探索直到得到解。所谓图探索就是检查 v 候选点 u 的邻居是否能满足 v 在查询图上邻居的条件,如果不满足,则结束扩展;否则,看 u 邻居的邻居能否满足 v 在查询图上邻居的邻居。这个过程迭代直到找到最终解。
  • Parquet
    • 基于列存储的云存储系统。
    • Sempala 将 RDF 数据转化成基于属性的关系数据表存储在 Parquet 上。在查询处理阶段,Sempala 将查询改写成能在 Parquet 上 SQL 语句以执行得到结果。

(2)基于数据划分的分布式RDF数据查询处理方法

  • 首先将 RDF 数据划分成若干子数据集,然后将这些子数据集分配到不同计算节点上。各个计算节点安装单机的RDF 数据管理系统以管理被分配来的子数据集。当查询输入这些系统中后,这些方法首先将查询也划分成若干子查询,然后这些方法将这些子查询分配到各个计算节点上执行得到部分解,最后这些方法收集所有部分解通过连接得到最终解。不同基于数据划分的查询处理方法的主要区别在于数据划分时采用的策略不一样。
  • 现有的方法:
    • 有的利用现有成熟工具METIS进行RDF数据划分,划分出来每个子图对应一个数据分片,进而对应一个系统中的一个工作节点。在每个工作节点内部,使用已有的单机 RDF数据管理系统对数据分片进行管理;
    • 有的提出一种有根子图的特殊结构作为划分基本单元对RDF知识图谱进行划分所谓 RDF 数据图上点 v 的有根子图就是从 v 出发做遍历得到的所有点构成的子图。首先找出能覆盖整个 RDF 数据图的一个有根子图集合,然后将这些有根子图聚成若干类。每一个类里面所有的作为有根子图一个分块被分配到一个对应的机器。
    • 有的提出一种基于RDF数据图上路径的划分方法。首先在 RDF 数据图上定义出“源点”和“沉入点”。所谓 RDF 数据图上的源点就是 RDF 数据图上没有入度的点;而所谓 RDF数据图上的沉入点就是 RDF 数据图上没有出度的点。然后在源点和沉入点基础上定义出“末端到末端路径”,即从源点或者图上环中没有进入环的边的点到沉入点或者末端到末端路径已经路过点的路径。首先找出覆盖全图的末端到末端路径集合,然后提出算法将覆盖全图的末端到末端路径集合分成 k 份,每份作为一个分块存储到一台机器上。
  • 总的来说,基于数据划分的 RDF 数据上的分布式查询处理方法要求按照自身的算法设计进行 RDF 数据的划分与分配,以减少查询处理阶段的通信代价。但是,这些方法的系统性能受到每台机器上的单机 RDF 数据管理系统性能的限制。

(3)联邦型分布式RDF数据查询处理方法

  • 随着关联数据的发展,现在越来越多的数据发布者都愿意将数据表示成RDF 数据格式并链接入关联数据上。其中很多数据发布者在将数据表示成 RDF 数据格式之外还提供 SPARQL 查询接口来让别人使用它的数据。这些 SPARQL 查询接口都属于“自治”的系统,即能各自独立地接受 SPARQL 查询并计算出匹配。每一个包含一定RDF数据和SPARQL 查询接口的机器被称为一个RDF 数据源。这些“自治”的 RDF 数据源被集成到一个系统平台下就形成了所谓的联邦型分布式 RDF 数据管理系统。
  • 在联邦型分布式 RDF 数据管理系统中,因为各个 RDF 数据源之间相互独立地自治,所以系统在查询处理阶段无法中断各个 RDF 数据源的处理进程。在联邦型分布式 RDF 数据管理系统中,系统需要提前将SPARQL 查询分解成若干子查询并传送到它们对应的 RDF 数据源,以让这些对应的 RDF 数据源对子查询独立地进行处理并得到部分解。之后,系统将这些部分解收集起来并通过连接操作得到最终解。在这个过程中,不同方法之间的主要区别在于如何进行查询分解并确定每个子查询对应的 RDF 数据源。
  • DARQ
    • 最早地讨论如何在联邦型分布式 RDF 数据管理系统上的进行 SPARQL 查询处理.
    • 当 SPARQL 查询输入以后,DARQ 根据服务描述的索引进行查询分解并确定出相关的 RDF 数据源。所谓服务描述,其中包含若干所谓的性能值。每个性能值对应一个数据源,其中包含若干元组 t = (p, r),其中 p 表示该数据源有 p 这个属性,r 对应于当属性为 p 时主体或者客体若干限制。
    • 在查询处理过程中,DARQ 还讨论了两个子查询结果连接方式:一是嵌套循环连接,就是一般的自然连接;二是绑定式连接,就是一个子查询先找出解,然后将解传输到另一个子查询那里,然后将解绑定到第二个子查询那里进行过滤。
  • SPLENDID
    • 根据每个数据源的VOID 信息建立一个倒排索引。这个索引将每个属性和类型信息映射到一个数据对(d, c),其中 d 表示属性或类型信息所在的 RDF 数据源,c 表示在 d 这个数据源上属性或类型信息的数量.
  • HiBISCuS
    • 构建了与DARQ 类似的索引。只是,在确定各个子查询的相关 RDF 数据源阶段,HiBISCuS 将查询图建模成一个有向带标签的超图,并利用这个有向带标签的超图进一步减少每个子查询的候选 RDF 数据源.
  • FedX
    • 可以在查询处理阶段实时确定相关数据源。当查询输入以后,FedX首先将查询中每个三元组模式都传到所有 RDF 数据源上并通过 SPARQL 查询语义中的 ASK 来确定相关数据源。之后,以三元组模式为单位进行查询优化,进而将若干三元组模式聚集在一起并得到连接操作顺序。FedX 所使用的连接方式也是和 DARQ 相似的绑定式连接,但是 FedX 在传输中间结果的时候不再是一个一个传,而是若干个中间结果合在一起传。

二、知识推理

  • 随着知识图谱研究的深入,研究人员发现知识图谱在各种应用中存在以下质量问题
    • 第一个问题是知识图谱的不完备性,即知识图谱中的关系缺失或者属性缺失。这个问题可能是因为构建知识图谱的数据本身就是不完备的,也可能是信息抽取算法无法识别到一些关系或者抽取到属性值。
    • 第二个问题是知识图谱中存在错误的关系。这个问题可能是因为构建知识图谱的数据有错误,也可能是因为知识图谱构建时采用了统计方法,而统计方法很难保证学习的知识是绝对正确的。
  • 为了解决这两个问题,就需要对知识图谱的推理进行研究。知识图谱的推理指的是从给定的知识图谱推导出新的实体跟实体之间的关系,可以粗略地分为基于符号的推理和基于统计的推理。
    • 在人工智能的研究中,基于符号的推理一般是基于经典逻辑(一阶谓词逻辑或者命题逻辑)或者经典逻辑的变异(比如说缺省逻辑)。基于符号的推理一般是通过规则或者本体从一个已有的知识图谱推理出新的实体间关系, 从而有助于解决第一个问题;而且基于符号的推理可以对知识图谱进行逻辑的冲突检测,从而有助于解决第二个问题。
    • 基于统计的方法一般指关系机器学习方法,即通过统计规律从知识图谱中学习到新的实体间关系,从而处理第一个问题; 并且对新学到的关系进行评分,去掉那些可能错误的关系,从而处理第二个问题。
  • 知识图谱上的推理能支撑人工智能的很多应用,是知识图谱区别于传统关系数据模型的关键。
  • 基于符号的推理包括基于本体的推理和基于规则的推理两种,前者包括概念的定义和分类,以及概念中实例的推断等推理,后者考虑的是将规则应用于图谱,实现图谱上新的关系推断以及基于图谱的决策支持。基于符号的推理被广泛用于生物医学中术语定义和概念分类、电商数据的不一致检测和查询重写以及智能问答中的知识扩充等。
  • 基于统计的推理包括模式归纳和实体关系学习,前者考虑的是从知识图谱中挖掘概念的关系,后者考虑的是通过统计方法推断出两个实体之间的关系。模式归纳用于构建知识图谱的模式知识,提供概念之间的上下文关系和关系的定义域与值域,模式知识可以用于符号逻辑推理,也可以用于知识图谱的构建。实体关系学习对于知识图谱的补全有很大作用,可以用于智能问答等知识图谱的应用。

1、研究内容和关键科学问题

  • 知识图谱的推理首先要考虑知识图谱的表示,有基于图结构的表示及其相应逻辑基础和基于张量的表示,其次要考虑逻辑推理算法及其优化,实现高效的逻辑推理机,再次要考虑基于统计的知识图谱推理算法,重点是基于表示学习的方法和基于图特征的方法,最后是如何从知识图谱通过统计方法学习本体。

(1)知识图谱的表示

  • 知识图谱表示是指用什么数据结构表示一个知识图谱,知识图谱以图展示,但不一定使用图来表示。
  • 从图的角度看,知识图谱是一个语义网络,即一种用互联的的节点和边来表示知识的一个结构。语义网络中的节点可以代表概念(concept)、属性(attribute)、事件(event)或者实体(entity),而边则用来表示节点之间的关系,边的标签指明了关系的类型。语义网络中的语义主要体现在图中边的含义。为了赋予这些边语义,研究人员提出了术语语言(terminological language),并最终提出了描述逻辑(description logic),描述逻辑是一阶谓词逻辑的一个子集,推理复杂度是可判定的(decidable)。
  • W3C 采用以描述逻辑为逻辑基础的本体语言 OWL(Ontology Web Language)作为定义 Web 术语的标准语言,还推出了另外一种用于表示 Web 本体的语言 RDF Schema(简称 RDFS)。
  • 虽然描述逻辑以及 RDFS 的理论已经成熟,但是这些理论还没有很好的应用于知识图谱,目前还缺乏针对知识图谱的一个逻辑表示语言。最近,基于向量(vector)的知识表示开始流行,这类表示将知识图谱三元组中的主谓宾表示成数值向量,通过向量的知识表示,可以采用统计或者神经网络的方法来进行推理,对知识图谱中的实体间的关系进行预测。知识图谱的向量表示主要考虑事实性(factual)知识图谱的表示,如何对模式(schematic)知识图谱进行数值表示是一个难点。

(2)基于符号的并行知识推理

  • 基于符号的知识图谱推理一般是应用推理规则到知识图谱上,通过触发规则的前件来推导出新的实体关系,这里的推理规则可能是知识表示语言所有的,也可能是人工设定或者通过机器学习技术获取的。
  • 基于符号的推理虽然有各种优化方法来提高推理效率, 但是还是跟不上数据增长的速度,特别是当数据规模大到目前基于内存的服务器无法处理的情况下。并行推理工作所借助的并行技术分为以下两类:
    • 单机环境下的多核、多处理器技术,比如多线程、GPU 技术等;
    • 多机环境下基于网络通信的分布式技术,比如 MapReduce 计算框架、Peer-To-Peer 网络框架等。
  • 现有的并行推理方法主要集中在前向链推理,即应用推理规则到知识图谱生成新的三元组,所以对于动态知识图谱的推理还处理不好。另外,前向链推理会导致知识图谱存储大量冗余知识,也不利于高效的知识检索和查询。

(3)实体关系学习方法

  • 实体关系学习的目的是通过统计方法或者神经网络方法学习知识图谱中实体之间的关系。相关研究工作大体可以分为两类:基于表示学习的方法和基于图特征的方法。
  • 基于表示学习的方法将知识图谱中的实体与关系统一映射至低维连续向量空间,以此来刻画它们的潜在语义特征。通过比较、匹配实体与关系的分布式表示,可以得到知识图谱中潜在成立的实体间的关系。此类方法灵活自由,通常具 有较高的计算效率,然而可解释性较差,同时对于困难的推理问题往往精度不足。如何提升这类方法的推理精度仍然是当前研究的热点与难点。
  • 基于图特征的方法利用从知识图谱中观察到的图特征来预测一条可能存在的边。代表性工作包括归纳逻辑程序设计(ILP)、关联规则挖掘(ARM)、路径排序算法(PRA)等。此类方法在推理的同时能从知识图谱中自动挖掘推理规则,具备明确的推理机理。然而图特征的提取效率较低,尤其对于时下超大规模的知识图谱更是如此。如何提高效率是这类方法亟待突破的壁垒。

(4)模式归纳方法

  • 模式归纳方法是从知识图谱中学习本体的模式层信息或丰富已有本体,包括概念层次、属性层次、不交公理、属性的值域与定义域和一些属性或概念的约束等公理的学习。
  • 知识图谱数据大都处于实例层,描述个体及个体之间的关系,缺少用于约束个体的模式层信息,模式层信息的缺失,给知识图谱的整合、查询和维护等关键任务带来了重重困难。基于知识图谱进行各种各样模式层公理的学习的主要研究大致分为以下三类:
    • 基于归纳逻辑编程(ILP)进行模式归纳的研究。这类方法结合了机器学习和逻辑编程技术,从实例和背景知识中获得逻辑结论,构建本体。
    • 基于关联规则挖掘进行模式归纳的研究。这类方法常首先从知识图谱中收集所需信息,然后将之用事务表表示出来,再利用传统的关联规则挖掘方法找出规则,而这些规则往往可直接转换成本体中的公理。
    • 基于机器学习进行模式归纳的研究。这类方法使用一些机器学习的方法,例如贝叶斯网络和聚类,将本体学习转换成一个机器学习的问题,将知识图谱用采纳的学习模型进行表示、建模和推理,获得新的公理。
  • 知识图谱采用的是开放世界假设,而传统的关联规则挖掘或者机器学习则是采用封闭世界假设,如何应对这个不同世界假设的问题是研究者们不断努力的方向。另外,鉴于知识图谱规模的巨大,开发出高效的、扩展性强的模式归纳算法也是一大难题。

2、技术方法和研究现状

(1)知识图谱的表示

  • 描述逻辑最终成为了 W3C 推荐的 Web 本体语言 OWL 的逻辑基础,描述逻辑为知识图谱提供了一些逻辑基础,但是并没有被很好的应用,有研究给出了如何扩展描述逻辑或者采用存在规则来表示知识图谱的本体,并提高逻辑推理服务,但是这些工作并没有实用化的系统。
  • 除了描述逻辑以外还有一些支持逻辑推理的知识图谱表示语言,比如说,除了描述逻辑以外,还可以采用属性逻辑(Attributed Logics)来表示知识图谱的本体,这里的属性逻辑比较适合表示具有时空维度的知识图谱。
  • 带标签的RDF给每个RDF三元组一个标签,用来描述该三元组的元信息。著名的知识图谱 Yago 采用了一种新的方法来表示三元组的时空维度的信息,即给每个三元组一个标识符,用来代表该三元组,然后对该标识符赋予时空维度的信息。

(2)基于符号的并行知识推理

  • 基于多核、多处理器技术的大规模推理
    • 单机环境下的并行技术以共享内存模型为特点,侧重于提升本体推理的时间效率。对于实时性要求较高的应用场景,这种方法成为首选。
    • 对于表达能力较低的语言,比如 RDFS、OWL EL,单机环境下的并行技术显著地提升了本体推理效率。
  • 基于分布式技术的大规模推理
    • 尽管单机环境的推理技术可以满足高推理性能的需求,但是由于计算资源有限(比如内存、存储容量),推理方法的可伸缩性(scalability)受到不同程度的限制。
    • 分布式技术利用多机搭建集群来实现本体推理。

(3)实体关系学习方法

  • 基于表示学习的方法
    • 知识图谱表示学习旨在于将知识图谱中的实体与关系统一映射至低维连续向量空间,以刻画它们的潜在语义特征。
    • 通过比较实体与关系在该向量空间中的分布式表示,可以推断出实体和实体之间潜在的关系。
    • 文献[Wang et al., 2017]对当下主流的知识图谱表示学习技术进行了系统的综述。
  • 基于图特征的方法
    • 基于图特征的方法借助从知识图谱中抽取出的图特征来预测两个实体间可能存在的不同类型的边(关系)。
    • 文献[Nickel et al., 2016b]对基于图特征的推理方法进行了简要概述。

(4)模式归纳方法

  • 基于 ILP 的模式归纳方法
  • 基于关联规则挖掘的模式归纳方法
  • 基于机器学习的模式归纳方法

3、技术展望与发展趋势

  • 两类推理方法,基于符号的推理方法和基于统计的推理方法,具有各自的应用场景,并且具有互补性。
    • 基于符号的推理方法更多考虑确定性知识的推理,一般通过给定的规则对知识图谱进行推理。为了使得推理具有高效性和可扩展性,现有工作采用了多种并行框架实现并行推理。
    • 基于统计的推理是一种不确定性推理, 通过统计规律对知识图谱中的缺失的边进行补全。通过采取并行框架可以对推理进行加速,从而实现海量知识图谱的关系补全。
  • 目前知识图谱上的推理技术已经取得了很多进展,特别是逻辑推理方面取得了很多理论和系统上的进展。

(1)基于符号推理的发展趋势

  • 知识图谱的表示还缺乏一个统一的方法。
    • 基于语义网络的方法缺乏逻辑基础;描述逻辑虽然是一种具有逻辑基础的语义网络,但是由于其提出是面向语义网的本体标准,不能完全适合知识图谱的表示;基于张量的表示方法则是对图的一种变种,并不能作为知识图谱的表示基础。
    • 对于知识图谱的表示,需要兼顾实用性和理论性。实用性方面,知识图谱的表达方式必然是多样化,可以围绕:(1) 时空知识图谱如何进行表示,这里会涉及到知识图谱的动态性,即动态知识图谱的表示;(2) 事件图谱如何进行表示,事件图谱的表示需要考虑到事件之间的因果关系和时序关系等。
  • 知识图谱的推理方法还缺乏实用的工具。本体推理机有很多原型系统,但是这些原型系统大都没有在实践中检验,在系统的稳定性和效率方面还存在诸 多问题,需要进一步工程化。
    • 知识图谱的推理比较实用的还是基于规则引擎的推理,典型的工具是 RDFox,但是很多规则引擎还局限于线下推理,而且缺乏规则管理的功能,从而限制了其实用性。可以围绕:(1)目前针对易处理(Tractable)描述逻辑本体的并行推理已经取得了不少突破,但是对于更复杂本体的推理还需要研究通过近似推理等技术来优化;(2)本体推理机主要还是考虑前向链推理,而实际应用的时候需要考虑查询重写,如何融合前向链推理和查询重写是值得研究的课题;(3)无论是本体推理还是规则推理,都需要考虑本体或者规则的管理,比如说本体的融合和更新,本体的不一致性处理,规则的冲突检测和规则的权重设置等,目前还缺乏全面考虑这些知识管理等推理引擎。

(2)基于统计推理的发展趋势

  • 知识图谱表示学习方面目前提出的技术和工具都只能应对某些基准数据,未能在实际数据上取得很好的应用效果。如何进一步提升基于表示学习的推理方法的推理精度是亟待解决的问题。
  • 当前的发展趋势:
    • 利用深度神经网络架构建模实体与实体之间的关系,期待通过复杂的网络结构和非线性变换捕捉实体之间复杂的语义关联,从而提升推理的精度。
    • 如何将表示学习模型与更加丰富的信息形态(尤其是图模式和符号规则)有效结合,充分发挥后者在表示学习中的效用,也是未来值得研究的问题。
    • 如何提高图特征抽取的效率,使其真正意义上适用于大规模知识图谱是当前一大技术挑战。大规模知识图谱上的图特征抽取,尤其是复杂图特征抽取,效率低下,耗时极长。
    • 如何突破知识图谱联通性壁垒,抽取出更加丰富的图特征也是未来重要的研究方向。知识图谱的稀疏性也会导致大量对推理有用的图特征无法被有效抽取。
    • 基于知识图谱进行模式归纳的方法在资源的利用和实用工具的开发上 还存在较大的提高空间。现有的模式归纳方法大都是基于实例层信息进行模式层公理的获取,即便在测试的实例上已经存在一些本体,已有方法很少利用这些有价值的资源,因此如何更好地利用这些模式层信息辅助基于实例的本体学习的工作,还存在较大的提升空间。
    • 知识图谱是不断发展变化的,新的事实不断产生,已有的事实也在不停地发生改变,这些动态信息资源,对于已有本体会产生什么影响、或者针对这些动态数据怎样进行模式归纳都具有很大挑战。
    • 如何开发一个易扩展、界面友好的模式归纳工具是个亟待解决的问题。模式归纳的工具还是比较欠缺的,大多模式归纳算法的实现没有提供用户界面,提供用户界面的工具缺少可扩展性,即其他种类公理的学习算法不方便整合进去.

详情请参考《KGDevReport2018知识图谱》

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,386评论 6 479
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,939评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,851评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,953评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,971评论 5 369
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,784评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,126评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,765评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,148评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,744评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,858评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,479评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,080评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,053评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,278评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,245评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,590评论 2 343

推荐阅读更多精彩内容