【知识图谱】知识图谱的技术与应用、落地实践中的问题与对策

2018 年 8 月 15 日 产业智能官


从零到一学习知识图谱的技术与应用



作者 | 李文哲(人工智能、知识图谱领域专家)

来源 | 贪心科技


导读:从一开始的Google搜索,到现在的聊天机器人、大数据风控、证券投资、智能医疗、自适应教育、推荐系统,无一不跟知识图谱相关。它在技术领域的热度也在逐年上升。 本文以通俗易懂的方式来讲解知识图谱相关的知识、尤其对从零开始搭建知识图谱过程当中需要经历的步骤以及每个阶段需要考虑的问题都给予了比较详细的解释。 对于读者,我们不要求有任何AI相关的背景知识。


目录:


  1. 概论

  2. 什么是知识图谱

  3. 知识图谱的表示

  4. 知识抽取

  5. 知识图谱的存储

  6. 金融知识图谱的搭建

    1. 定义具体的业务问题

    2. 数据收集 & 预处理

    3. 知识图谱的设计

    4. 把数据存入知识图谱

    5. 上层应用的开发

  7. 知识图谱在其他行业中的应用

  8. 实践上的几点建议

  9. 结语



▌1. 概论


随着移动互联网的发展,万物互联成为了可能,这种互联所产生的数据也在爆发式地增长,而且这些数据恰好可以作为分析关系的有效原料。如果说以往的智能分析专注在每一个个体上,在移动互联网时代则除了个体,这种个体之间的关系也必然成为我们需要深入分析的很重要一部分。 在一项任务中,只要有关系分析的需求,知识图谱就“有可能”派的上用场。


▌2. 什么是知识图谱?


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


那什么叫多关系图呢? 学过数据结构的都应该知道什么是图(Graph)。图是由节点(Vertex)和边(Edge)来构成,但这些图通常只包含一种类型的节点和边。但相反,多关系图一般包含多种类型的节点和多种类型的边。比如左下图表示一个经典的图结构,右边的图则表示多关系图,因为图里包含了多种类型的节点和边。这些类型由不同的颜色来标记。

在知识图谱里,我们通常用“实体(Entity)”来表达图里的节点、用“关系(Relation)”来表达图里的“边”。实体指的是现实世界中的事物比如人、地名、概念、药物、公司等关系则用来表达不同实体之间的某种联系,比如人-“居住在”-北京、张三和李四是“朋友”、逻辑回归是深度学习的“先导知识”等等。


现实世界中的很多场景非常适合用知识图谱来表达。 比如一个社交网络图谱里,我们既可以有“人”的实体,也可以包含“公司”实体。人和人之间的关系可以是“朋友”,也可以是“同事”关系。人和公司之间的关系可以是“现任职”或者“曾任职”的关系。 类似的,一个风控知识图谱可以包含“电话”、“公司”的实体,电话和电话之间的关系可以是“通话”关系,而且每个公司它也会有固定的电话。 


▌3. 知识图谱的表示


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



在现实世界中,实体和关系也会拥有各自的属性,比如人可以有“姓名”和“年龄”。当一个知识图谱拥有属性时,我们可以用属性图(Property Graph)来表示。下面的图表示一个简单的属性图。李明和李飞是父子关系,并且李明拥有一个138开头的电话号,这个电话号开通时间是2018年,其中2018年就可以作为关系的属性。类似的,李明本人也带有一些属性值比如年龄为25岁、职位是总经理等。 


这种属性图的表达很贴近现实生活中的场景,也可以很好地描述业务中所包含的逻辑。除了属性图,知识图谱也可以用RDF来表示,它是由很多的三元组(Triples)来组成。RDF在设计上的主要特点是易于发布和分享数据,但不支持实体或关系拥有属性,如果非要加上属性,则在设计上需要做一些修改。目前来看,RDF主要还是用于学术的场景,在工业界我们更多的还是采用图数据库(比如用来存储属性图)的方式。感兴趣的读者可以参考RDF的相关文献,在文本里不多做解释。


▌4. 知识抽取


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


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



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


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

b. 关系抽取(Relation Extraction)    

c. 实体统一(Entity Resolution)    

d. 指代消解(Coreference Resolution)


下面针对每一项技术解决的问题做简单的描述,以至于这些是具体怎么实现的,不在这里一一展开,感兴趣的读者可以查阅相关资料,或者学习我的课程。

首先是实体命名识别,就是从文本里提取出实体并对每个实体做分类/打标签:比如从上述文本里,我们可以提取出实体-“NYC”,并标记实体类型为 “Location”;我们也可以从中提取出“Virgil's BBQ”,并标记实体类型为“Restarant”。这种过程称之为实体命名识别,这是一项相对比较成熟的技术,有一些现成的工具可以用来做这件事情。其次,我们可以通过关系抽取技术,把实体间的关系从文本中提取出来,比如实体“hotel”和“Hilton property”之间的关系为“in”;“hotel”和“Time Square”的关系为“near”等等。



另外,在实体命名识别和关系抽取过程中,有两个比较棘手的问题:一个是实体统一,也就是说有些实体写法上不一样,但其实是指向同一个实体。比如“NYC”和“New York”表面上是不同的字符串,但其实指的都是纽约这个城市,需要合并。实体统一不仅可以减少实体的种类,也可以降低图谱的稀疏性(Sparsity);另一个问题是指代消解,也是文本中出现的“it”, “he”, “she”这些词到底指向哪个实体,比如在本文里两个被标记出来的“it”都指向“hotel”这个实体。




实体统一和指代消解问题相对于前两个问题更具有挑战性。


▌5. 知识图谱的存储


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

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


▌6. 金融知识图谱的搭建


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



一个完整的知识图谱的构建包含以下几个步骤:1. 定义具体的业务问题  2. 数据的收集 & 预处理  3. 知识图谱的设计  4. 把数据存入知识图谱  5. 上层应用的开发,以及系统的评估。下面我们就按照这个流程来讲一下每个步骤所需要做的事情以及需要思考的问题。 


6.1 定义具体的业务问题


在P2P网贷环境下,最核心的问题是风控,也就是怎么去评估一个借款人的风险。在线上的环境下,欺诈风险尤其为严重,而且很多这种风险隐藏在复杂的关系网络之中,而且知识图谱正好是为这类问题所设计的,所以我们“有可能”期待它能在欺诈,这个问题上带来一些价值。 

在进入下一个话题的讨论之前,要明确的一点是,对于自身的业务问题到底需不需要知识图谱系统的支持。因为在很多的实际场景,即使对关系的分析有一定的需求,实际上也可以利用传统数据库来完成分析的。所以为了避免使用知识图谱而选择知识图谱,以及更好的技术选型,以下给出了几点总结,供参考。




6.2 数据收集 & 预处理


下一步就是要确定数据源以及做必要的数据预处理。针对于数据源,我们需要考虑以下几点:1. 我们已经有哪些数据? 2. 虽然现在没有,但有可能拿到哪些数据? 3.  其中哪部分数据可以用来降低风险? 4. 哪部分数据可以用来构建知识图谱?在这里需要说明的一点是,并不是所有跟反欺诈相关的数据都必须要进入知识图谱,对于这部分的一些决策原则在接下来的部分会有比较详细的介绍。


对于反欺诈,有几个数据源是我们很容易想得到的,包括用户的基本信息、行为数据、运营商数据、网络上的公开信息等等。假设我们已经有了一个数据源的列表清单,则下一步就要看哪些数据需要进一步的处理,比如对于非结构化数据我们或多或少都需要用到跟自然语言处理相关的技术。 用户填写的基本信息基本上会存储在业务表里,除了个别字段需要进一步处理,很多字段则直接可以用于建模或者添加到知识图谱系统里。对于行为数据来说,我们则需要通过一些简单的处理,并从中提取有效的信息比如“用户在某个页面停留时长”等等。 对于网络上公开的网页数据,则需要一些信息抽取相关的技术。


举个例子,对于用户的基本信息,我们很可能需要如下的操作。一方面,用户信息比如姓名、年龄、学历等字段可以直接从结构化数据库中提取并使用。但另一方面,对于填写的公司名来说,我们有可能需要做进一步的处理。比如部分用户填写“北京贪心科技有限公司”,另外一部分用户填写“北京望京贪心科技有限公司”,其实指向的都是同一家公司。所以,这时候我们需要做公司名的对齐,用到的技术细节可以参考前面讲到的实体对齐技术。


6.3 知识图谱的设计


图谱的设计是一门艺术,不仅要对业务有很深的理解、也需要对未来业务可能的变化有一定预估,从而设计出最贴近现状并且性能高效的系统。在知识图谱设计的问题上,我们肯定会面临以下几个常见的问题:1. 需要哪些实体、关系和属性? 2.  哪些属性可以做为实体,哪些实体可以作为属性? 3. 哪些信息不需要放在知识图谱中? 


基于这些常见的问题,我们从以往的设计经验中抽象出了一系列的设计原则。这些设计原则就类似于传统数据库设计中的范式,来引导相关人员设计出更合理的知识图谱系统,同时保证系统的高效性。

接下来,我们举几个简单的例子来说明其中的一些原则。 首先是,业务原则(Business Principle),它的含义是 “一切要从业务逻辑出发,并且通过观察知识图谱的设计也很容易推测其背后业务的逻辑,而且设计时也要想好未来业务可能的变化”。


举个例子,可以观察一下下面这个图谱,并试问自己背后的业务逻辑是什么。通过一番观察,其实也很难看出到底业务流程是什么样的。做个简单的解释,这里的实体-“申请”意思就是application,如果对这个领域有所了解,其实就是进件实体。在下面的图中,申请和电话实体之间的“has_phone”,“parent phone”是什么意思呢?

接下来再看一下下面的图,跟之前的区别在于我们把申请人从原有的属性中抽取出来并设置成了一个单独的实体。在这种情况下,整个业务逻辑就变得很清晰,我们很容易看出张三申请了两个贷款,而且张三拥有两个手机号,在申请其中一个贷款的时候他填写了父母的电话号。总而言之,一个好的设计很容易让人看到业务本身的逻辑。

接下来再看一个原则叫做效率原则(Efficiency Principle)。 效率原则让知识图谱尽量轻量化、并决定哪些数据放在知识图谱,哪些数据不需要放在知识图谱。在这里举一个简单的类比,在经典的计算机存储系统中,我们经常会谈论到内存和硬盘,内存作为高效的访问载体,作为所有程序运行的关键。这种存储上的层次结构设计源于数据的局部性-“locality”,也就是说经常被访问到的数据集中在某一个区块上,所以这部分数据可以放到内存中来提升访问的效率。 类似的逻辑也可以应用到知识图谱的设计上:我们把常用的信息存放在知识图谱中,把那些访问频率不高,对关系分析无关紧要的信息放在传统的关系型数据库当中。 效率原则的核心在于把知识图谱设计成小而轻的存储载体。

比如在下面的知识图谱中,我们完全可以把一些信息比如“年龄”,“家乡”放到传统的关系型数据库当中,因为这些数据对于:a. 分析关系来说没有太多作用   b.  访问频率低,放在知识图谱上反而影响效率。

另外,从分析原则(Analytics Principle)的角度,我们不需要把跟关系分析无关的实体放在图谱当中;从冗余原则(Redundancy Principle)的角度,有些重复性信息、高频信息可以放到传统数据库当中。


6.4 把数据存入知识图谱


存储上我们要面临存储系统的选择,但由于我们设计的知识图谱带有属性,图数据库可以作为首选。但至于选择哪个图数据库也要看业务量以及对效率的要求。如果数据量特别庞大,则Neo4j很可能满足不了业务的需求,这时候不得不去选择支持准分布式的系统比如OrientDB, JanusGraph等,或者通过效率、冗余原则把信息存放在传统数据库中,从而减少知识图谱所承载的信息量。 通常来讲,对于10亿节点以下规模的图谱来说Neo4j已经足够了。


6.5 上层应用的开发


等我们构建好知识图谱之后,接下来就要使用它来解决具体的问题。对于风控知识图谱来说,首要任务就是挖掘关系网络中隐藏的欺诈风险。从算法的角度来讲,有两种不同的场景:一种是基于规则的;另一种是基于概率的。鉴于目前AI技术的现状,基于规则的方法论还是在垂直领域的应用中占据主导地位,但随着数据量的增加以及方法论的提升,基于概率的模型也将会逐步带来更大的价值。


6.5.1 基于规则的方法论


首先,我们来看几个基于规则的应用,分别是不一致性验证、基于规则的特征提取、基于模式的判断。


  • 不一致性验证


为了判断关系网络中存在的风险,一种简单的方法就是做不一致性验证,也就是通过一些规则去找出潜在的矛盾点。这些规则是以人为的方式提前定义好的,所以在设计规则这个事情上需要一些业务的知识。比如在下面的这个图中,李明和李飞两个人都注明了同样的公司电话,但实际上从数据库中判断这俩人其实在不同的公司上班,这就是一个矛盾点。 类似的规则其实可以有很多,不在这里一一列出。



  • 基于规则提取特征


我们也可以基于规则从知识图谱中提取一些特征,而且这些特征一般基于深度的搜索比如2度,3度甚至更高维度。比如我们可以问一个这样的问题:“申请人二度关系里有多少个实体触碰了黑名单?”,从图中我们很容观察到二度关系中有两个实体触碰了黑名单(黑名单由红色来标记)。等这些特征被提取之后,一般可以作为风险模型的输入。在此还是想说明一点,如果特征并不涉及深度的关系,其实传统的关系型数据库则足以满足需求。



  • 基于模式的判断


这种方法比较适用于找出团体欺诈,它的核心在于通过一些模式来找到有可能存在风险的团体或者子图(sub-graph),然后对这部分子图做进一步的分析。 这种模式有很多种,在这里举几个简单的例子。 比如在下图中,三个实体共享了很多其他的信息,我们可以看做是一个团体,并对其做进一步的分析。


再比如,我们也可以从知识图谱中找出强连通图,并把它标记出来,然后做进一步风险分析。强连通图意味着每一个节点都可以通过某种路径达到其他的点,也就说明这些节点之间有很强的关系。




6.5.2 基于概率的方法


除了基于规则的方法,也可以使用概率统计的方法。 比如社区挖掘、标签传播、聚类等技术都属于这个范畴。 对于这类技术,在本文里不做详细的讲解,感兴趣的读者可以参考相关文献。


社区挖掘算法的目的在于从图中找出一些社区。对于社区,我们可以有多种定义,但直观上可以理解为社区内节点之间关系的密度要明显大于社区之间的关系密度。下面的图表示社区发现之后的结果,图中总共标记了三个不同的社区。一旦我们得到这些社区之后,就可以做进一步的风险分析。


由于社区挖掘是基于概率的方法论,好处在于不需要人为地去定义规则,特别是对于一个庞大的关系网络来说,定义规则这事情本身是一件很复杂的事情。

标签传播算法的核心思想在于节点之间信息的传递。这就类似于,跟优秀的人在一起自己也会逐渐地变优秀是一个道理。因为通过这种关系会不断地吸取高质量的信息,最后使得自己也会不知不觉中变得更加优秀。具体细节不在这里做更多解释。


相比规则的方法论,基于概率的方法的缺点在于:需要足够多的数据。如果数据量很少,而且整个图谱比较稀疏(Sparse),基于规则的方法可以成为我们的首选。尤其是对于金融领域来说,数据标签会比较少,这也是为什么基于规则的方法论还是更普遍地应用在金融领域中的主要原因。


6.5.3 基于动态网络的分析


以上所有的分析都是基于静态的关系图谱。所谓的静态关系图谱,意味着我们不考虑图谱结构本身随时间的变化,只是聚焦在当前知识图谱结构上。然而,我们也知道图谱的结构是随时间变化的,而且这些变化本身也可以跟风险有所关联。


在下面的图中,我们给出了一个知识图谱T时刻和T+1时刻的结构,我们很容易看出在这两个时刻中间,图谱结构(或者部分结构)发生了很明显的变化,这其实暗示着潜在的风险。那怎么去判断这些结构上的变化呢? 感兴趣的读者可以查阅跟“dynamic network mining”相关的文献。



▌7. 知识图谱在其他行业中的应用


除了金融领域,知识图谱的应用可以涉及到很多其他的行业,包括医疗、教育、证券投资、推荐等等。其实,只要有关系存在,则有知识图谱可发挥价值的地方。 在这里简单举几个垂直行业中的应用。


比如对于教育行业,我们经常谈论个性化教育、因材施教的理念。其核心在于理解学生当前的知识体系,而且这种知识体系依赖于我们所获取到的数据比如交互数据、评测数据、互动数据等等。为了分析学习路径以及知识结构,我们则需要针对于一个领域的概念知识图谱,简单来讲就是概念拓扑结构。在下面的图中,我们给出了一个非常简单的概念图谱:比如为了学习逻辑回归则需要先理解线性回归;为了学习CNN,得对神经网络有所理解等等。所有对学生的评测、互动分析都离不开概念图谱这个底层的数据。


在证券领域,我们经常会关心比如“一个事件发生了,对哪些公司产生什么样的影响?” 比如有一个负面消息是关于公司1的高管,而且我们知道公司1和公司2有种很密切的合作关系,公司2有个主营产品是由公司3提供的原料基础上做出来的。


其实有了这样的一个知识图谱,我们很容易回答哪些公司有可能会被这次的负面事件所影响。当然,仅仅是“有可能”,具体会不会有强相关性必须由数据来验证。所以在这里,知识图谱的好处就是把我们所需要关注的范围很快给我们圈定。接下来的问题会更复杂一些,比如既然我们知道公司3有可能被这次事件所影响,那具体影响程度有多大? 对于这个问题,光靠知识图谱是很难回答的,必须要有一个影响模型、以及需要一些历史数据才能在知识图谱中做进一步推理以及计算。


▌8. 实践上的几点建议


首先,知识图谱是一个比较新的工具,它的主要作用还是在于分析关系,尤其是深度的关系。所以在业务上,首先要确保它的必要性,其实很多问题可以用非知识图谱的方式来解决。


知识图谱领域一个最重要的话题是知识的推理。 而且知识的推理是走向强人工智能的必经之路。但很遗憾的,目前很多语义网络的角度讨论的推理技术(比如基于深度学习,概率统计)很难在实际的垂直应用中落地。其实目前最有效的方式还是基于一些规则的方法论,除非我们有非常庞大的数据集。


最后,还是要强调一点,知识图谱工程本身还是业务为重心,以数据为中心。不要低估业务和数据的重要性。


9. 结语


知识图谱是一个既充满挑战而且非常有趣的领域。只要有正确的应用场景,对于知识图谱所能发挥的价值还是可以期待的。我相信在未来不到2,3年时间里,知识图谱技术会普及到各个领域当中。




领域知识图谱落地实践中的问题与对策

 AI科技大本营

肖仰华博士,复旦大学计算机科学与技术学院教授,博士生导师,知识工场实验室负责人。




报告摘要:近年来,知识图谱技术进展迅速,各种领域知识图谱技术在很多领域或行业取得了显著落地效果。在领域知识图谱技术的落地实践过程中涌现出一大批理论与工程问题。


本报告结合复旦大学知识工场实验室十多个领域知识图谱落地项目实践,尝试对这些问题进行初步解答,梳理这些问题背后的关键科学问题,总结领域知识图谱技术落地的最佳实践,以期为各行业的知识图谱落地实践提供参考。




下文根据肖仰华教授近期所作报告《领域知识图谱落地实践中的问题与对策》整理而成,并经肖仰华教授亲自审核。





随着近几年知识图谱技术的进步,知识图谱研究与落地发生了一些转向。其中一个重要变化就是越来越多的研究与落地工作从通用知识图谱转向了领域或行业知识图谱,转向了企业知识图谱。知识图谱技术与各行业的深度融合已经成为一个重要趋势。


在这一过程当中,涌现出一系列理论与技术问题。例如:知识图谱技术到底能够解决怎样的行业痛点问题?知识图谱技术与各行业融合的具体路径是怎样的?领域知识图谱与通用知识图谱的联系与区别是什么?领域知识图谱落地过程当中的关键科学技术问题是什么?


这一系列问题的剖析与回答是进一步推动知识图谱技术落地实践、生根开花的关键所在。本次报告主要结合复旦大学知识工场实验室在十多个行业的领域知识图谱实践经历,对领域知识图谱落地实践中的关键问题以及主要对策做个初步解答。



报告思路很简单,是一问一答的形式。这里列出的问题是各个行业普遍关心的代表性的关键问题。



首先回答什么是领域知识图谱?领域知识图谱(Domain-specific Knowledge Graph: DKG)的概念是从通用知识图谱(General-purpose Knowledge Graph: GKG)演化而来,所以我们首先阐述什么是知识图谱(knowledge graph)。


在回答什么是知识图谱这个问题上有个非常有意思的现象,一直以来,工业界和学术界都没有对于知识图谱给出一个严格的定义。如果大家去搜维基百科,会看到维基百科说知识图谱是Google的一种知识表示。然而,一个相对严格的定义是必要的,我给出的定义是“大规模语义网络”。


理解这个定义有两个要点。第一个是语义网络,语义网络包含的是实体、概念以及实体和概念之间各种各样的语义关系。比如C罗是一个足球运动员,是一个实体,金球奖也是一个实体。


何为实体?黑格尔在《小逻辑》里面曾经给实体下过一个定义:“能够独立存在的,作为一切属性的基础和万物本原的东西”。也就是说实体是属性赖以存在的基础,必须是自在的,也就是独立的、不依附于其他东西而存在的。比如身高,单单说身高是没有意义的,说“运动员”这个类别的身高也是没有意义的,必须说某个人的身高,才是有明确所指,有意义的。理解何为实体,对于进一步理解属性、概念是十分必要的。


再来看概念(concept),概念又称之为类别(type)、类(category)等。比如“运动员”,不是指某一个运动员,而是指一类人,这就是一个概念。语义网络中的关联都是语义关联,这些语义关联发生在实体之间、概念之间或者实体与概念之间。


实体与概念之间是instanceOf(实例)关系,比如“C罗”是“运动员”的一个实例。概念之间是subclassOf(子类)关系,比如“足球运动员”是“运动员”的一个子类。实体与实体之间的关系十分多样,比如“C罗”效力于“皇家马德里球队”。


理解知识图谱的第二个要点是大规模。除了语义网络之外,上个世纪伴随着专家系统的研制而发展出了类别多样的知识表示形式,比如产生式规则、本体、框架,还有决策树、贝叶斯网络、马尔可夫逻辑网络等。


这些知识表示表达了现实世界各种复杂语义。知识表示多种多样,语义网络只是各种知识表示中的一种而已。既然上世纪七八十年代有如此多的知识表示,而且知识图谱本质上是语义网络,为什么今天还要提知识图谱?那是因为知识图谱与传统七八十年代的知识表示有一个根本的差别,那就是在规模上的差别。知识图谱是一个大规模语义网络,而七八十年代的语义网络是个典型的小知识(small knowledge)。


知识图谱的规模巨大,像Google knowledge graph在2012年发布之初就有5亿多的实体,10亿多的关系,如今规模更大。知识图谱的规模之所以如此巨大,是因为它强调对于实体的覆盖。比如说运动员作为一个类别在知识图谱里涵盖了数以万计诸如C罗这样的实体。知识图谱的规模效应带来了效用方面的质变。知识图谱是典型的大数据时代产物。关于这些观点的详细描述参考本人的《知识图谱与认知智能》,在此不再赘述。


那什么是领域知识图谱呢?比如“足球知识图谱”,里面大多都是跟足球相关的实体和概念。如果知识图谱聚焦在特定领域,就可以认为是领域知识图谱。领域知识图谱的范畴再大一些就是行业知识图谱了,比如农业知识图谱。


近几年一些大型企业对于利用知识图谱解决企业自身的问题十分感兴趣,于是就有了横贯企业各核心流程的企业知识图谱。领域知识图谱、行业知识图谱与企业知识图谱有时边界也十分模糊。近几年,这几类知识图谱得到越来越多的关注。



在理解领域知识图谱时,我想指出一个非常重要的观点,我称之为“NoKG”,也就是Not only KG。这里是借鉴“NoSQL”的说法。首先,知识图谱只是知识表示的一种,单单知识图谱不足以表达现实世界的丰富语义,不足以解决所有问题。比如很多领域有着丰富的if-then规则(比如故障维修、计算机系统配置),这些规则利用知识图谱表达就很牵强,特别是对于if A and B then C 这样的规则。


条件部分的原子表达式之间的关系可以很复杂,利用知识图谱难以表达。知识表示方面的缺陷限制了知识图谱解决问题的范围。其次,知识图谱辅以其他知识表示则有可能解决很多复杂的实际问题。作为一种语义网络,知识图谱在大数据的赋能下就已经能够解决很多实际问题。


可以设想一下,还有更多的知识表示没有突破规模瓶颈。在大数据的赋能下,其他类型的知识表示也将能够解决更多实际的问题。越来越多的领域应用需要的知识已经突破了知识图谱的范围,对其他知识(比如产生式规则、贝叶斯网络、决策树等)提出了诉求。比如,我们正在尝试联合使用知识图谱与产生式规则实现面向故障诊断的精准语义检索。


NoKG的另一层含义在于领域应用不仅需要静态知识,更需要动态知识。知识图谱侧重于表达实体、概念之间的语义关联,这些语义关联大多是静态的、显性的、客观的、明确的。而实际应用中对过程性、决策性知识是有着大量需求的,这些知识大部分是动态的、隐形的、带有一定主观性的,比如疾病诊断、投资决策、司法解释等等。


这些应用需要把决策的因素、机制与过程加以表达。动态知识的沉淀对于很多行业来说是强需求。随着我国人口红利消失,人力成本持续提高,特别是富有经验的领域专家成本越加高昂。这些人员一旦流失,会给企业造成巨大损失。为此,企业特别需要将领域专家大脑中的决策知识加以沉淀,赋予机器,从而一定程度上降低对专家的依赖。


但是,动态知识的表达与获取仍然是个具有重大挑战的技术问题。很多决策过程难以明确表达,很多决策因素是隐性的。比如老中医看病,中医智能化一直希望将有经验的老中医的看病经验沉淀下来。但是老中医自己也未必说得清楚是根据什么看病的。虽然中医也有朴素的理论在支撑其诊断,但总体而言整个过程是模糊的。在传统知识管理领域曾经设计出很多激励制度以促进企业内的知识表达与沉淀,但是阻力重重,收效甚微。


关键问题在于工程师、分析师、医生等等领域专家自己也不知道如何表达。传统知识工程通过专业的知识工程师协助领域专家进行知识获取,但总体上的代价太大,过程太重,不易成功。动态过程的知识表达已经困难重重,知识获取就更加雪上加霜了。


曾有人设想获取金牌投资经理投资决策的知识,尝试为投资经理提供新闻阅读工具,通过其点击行为把握其所关注新闻,甚至通过眼球跟踪捕捉其关注的文章片段,以期精准捕捉其决策要素。知识获取之困难可见一斑。但是知识表示及获取的重心将逐步过渡到动态知识是必然趋势,也是摆在研究人员面前的攻关战。



现在回答第二个问题,DKG(领域知识图谱)和GKG(通用知识图谱)的关系和区别。首先来看GKG和DKG的区别。两者之间的区别是明显的,体现在知识表示、知识获取和知识应用三个层面。在知识表示层面的差别可以从广度、深度和粒度这三个维度加以考察。从广度来看,GKG涵盖的范围明显大于DKG。


从深度来看,DKG通常更深,尤其体现在概念图谱的层级体系上。比如,在娱乐领域,追星族们可能很关心“内地鼻子长得帅的男明星”,在电商领域单单“连衣裙”不足以满足人们的购物需求,电商图谱中往往要涵盖“韩版夏装连衣裙”这样的细分品类。


如何表达与处理这些较深层次的概念对于很多领域知识图谱应用而言是个巨大挑战。需要指出的是层次较深的细粒度概念往往不是基本概念(basic concept)。这意味着不同人对这些深层次概念有着不同的认知体验的,因而会有较大的主观分歧。这就是很多人工构建的概念层级深到一定层次就很难继续下去的重要原因。此时,数据驱动的自下而上的自动化方法往往比较适合。


第三个维度是知识表示的粒度,DKG通常涵盖细粒度的知识。知识表示是有粒度的,知识的基本单元可以是一个文档,也可以是文章中的段落、法律中的条款、教育资源中的知识点等等。传统知识管理往往以文档为单位组织企业知识资源。


在司法智能中的司法解释往往需要将知识粒度控制在条款级别。在教育智能化领域,学科的知识点往往是个合适的粒度,以知识点为中心组织教学素材和资源是个可行的思路。知识表示的粒度也可以细化到知识图谱中的实体与属性级别,或者是逻辑规则中的条件与结果。比如法律条款可以进一步细化到由条件与结果构成的产生式规则,数学中的很多定理也可以进一步细化为相关的公理系统(一组产生式规则)。


既然知识表示的粒度是可控的,我们应该如何控制呢?很多场景下知识表示的粒度是个需要仔细斟酌的问题。一般而言,粒度越细表达能力越强,但是其表达与获取代价也越大。细粒度知识表示一般是领域应用的强需求之一。比如在知识管理领域,粒度粗放已经成为阻碍企业知识管理发展的根本问题。传统知识搜索只能搜索到文档级别,如果不幸这个文档含有1000页内容,则会给用户带来巨大麻烦。


但是,凡事过犹不及,太细粒度的知识表示也往往会给知识获取带来巨大的复杂性。合理控制知识表示的粒度,不盲目求精求细,是知识库技术落地成功的关键思路之一。很多落地实践中过早地陷入细粒度知识获取的泥潭当中,消耗巨大但收效甚微。但事实上细粒度的知识表示在很多场景下也是不必要的。因此,在实践中建议紧扣应用需求,从应用出发反推需要怎样粒度的知识表示。


在知识获取层面,DKG对质量往往有着极为苛刻的要求。因为很多领域应用场景是极为严肃的(也就是mission critical 的AI应用)。比如医疗,某个药物有哪些禁忌症,这类知识是不能出错的。


对质量的苛刻要求自然就意味着领域知识图谱构建过程中专家参与的程度相对较高。需要指出的是,专家的积极干预并不意味着盲目的手动构建。如何应用好人力资源,包括哪些环节让人参与以及专家参与的具体方式等问题一直以来就是领域知识图谱落地的关键问题。在众包计算中有不少方法值得借鉴。但是对于有着依赖专家经验的历史传统而言,如何尽可能降低人力资源的成本是个值得深入研究的问题。


一般而言,我们期望构建过程尽可能自动化;但是由于对目标图谱有着苛刻的质量要求,最终的知识验证过程还是要诉诸人力。较多的人工干预自然决定了领域知识图谱落地过程自动化程度相对较低。相比较而言,通用知识图谱构建一定要高度自动化,因为通用知识图谱规模太大(动辄数千万的实体,数亿的关系),如果没有自动化的办法,根本无法推进,除非存在有效的大规模众包化手段,比如知识类互动游戏等。


在知识应用层面,首先,领域知识图谱的推理链条往往相对较长。原因有两个方面。一是领域知识图谱相对密集。比如某个疾病在通用知识库中相关实体可能寥寥无几,但是在一个医疗知识图谱中相关实体可能数以百计。知识库建设有一个有意思的现象那就是永远不要指望知识库是完备的。完备是知识库建设永远在追求但却无法企及的目标。


但是,DKG相对于GKG在单个实体的相关知识覆盖面有着明显优势。也正是基于此,领域知识图谱上的推理链条可以较长。在一个相对稠密的领域知识图谱上长距离推理之后的结果仍然还可能是个有意义的结果。但是在通用知识图谱上,由于其相对稀疏,多步推理之后语义漂移(semantic drift)严重,其推理结果很容易“面目全非”、“离题千里”,令人难以理解了。


所以在GKG之上的推理操作大都是基于上下文的一到两步的推理。比如搜索“刘德华”,可以推荐他的歌曲,那是因为知识图谱告知我们刘德华是一个歌星,主要作品是歌曲,这是两步的推理链条。


其次,领域知识图谱上的计算操作也相对复杂一些。像之前提到的深度推理就是一种复杂的应用。此外,领域应用往往会涉及复杂查询。比如在公共安全领域,对于重点监控人群,通常需要在相关图谱中查询该人群形成的稠密子图。诸如此类的复杂计算和操作,在领域知识图谱中并不罕见。相反,通用知识图谱的查询多为一到两步的邻居查询,相对简单。



现在来看联系,通用知识图谱与领域知识图谱关系是十分密切的,根本原因是人类的知识体系是有结构的。我个人认为人类的知识体系呈现出倒三角形的结构。三角结构越是接近底层的部分越是最为基本的、形式简单的知识;越往上层知识越为抽象、越加多样,也越加细分、专业性越强。


在个人成长的早期阶段,人类通过自身身体与世界的交互习得了最为基本的常识,特别是关于时间、空间、因果的基本常识。我们知道时间是在流逝的、我们知道空间是有一定位置关系的、我们明白有因必有果。这些都是最为基本的常识。这些常识是构建认知体系的基础。


在此基础上,通过“隐喻”或者“类比”(美国的侯世达教授甚至认为类比是智能的本质,见其《哥德尔、艾舍尔、巴赫》一书),人类发展出更为高层的知识,包括对于世界的知识(比如我们知道太阳从东边升起,人是要呼吸的等等)、简单关联事实(比如下雨了,地面会潮湿)。


基于这些简单知识,再通过隐喻和类比,进一步形成特定领域的知识。很多领域知识本质上是通过隐喻从基本知识发展而来的。比如人们关于社会地位的认识,某个人社会地位较高实际上是从空间上的高低隐喻而来的。说某个人很积极、很激进,实际上是从时间的先后隐喻而来的。


最近还有一个例子,将各种芯片与人体的各器官相类比:做人工智能的芯片就好比在做大脑,做通用芯片就好比在做血管,做计算芯片就好比在做心脏,这都是典型的隐喻。所以很多领域知识都是从人类的基本常识和世界知识通过隐喻发展而来的。因此,领域知识和通用知识之间存在着千丝万缕的联系。理解自然语言中的隐喻现象也一直是自然语言处理领域的一个研究热点。



DKG与GKG的另一个联系在于行业应用对于领域知识的需求难以闭合。也就是说,很多行业应用看上去好像只需要领域知识,但是实际应用过程中往往会超出领域所预先设定的知识边界。


比如在金融知识图谱落地过程中,本以为涵盖公司、法人、机构、产品等就足够了。但是实际应用过程中我们发现这些类型的知识还远远不够。比如基于金融知识图谱的关联分析往往会牵扯出几乎万事万物。比如说诸如龙卷风的气候灾害,会使得农作物产量下降,农业机械的出货量因而就会下降,农机的发动机产量也就相应要下降,从事农机发动机关键部件生产的公司业绩就会下降,相关公司的股票可能就会下跌。这个例子形象地说明几乎一切事物在某种意义下都是跟金融有关系。


事实上,一切实体都身处在一个复杂的因果网络中,世界是普遍关联的。这就导致沿着任何一个实体开展关联分析都极为容易超出预先设定的知识边界。因此,行业应用中的知识需求难以封闭于领域知识的边界范围内。换言之,越为封闭的应用场景,机器越容易取得成功。


所谓封闭是指一个有限的知识子集足以支撑应用需求。比如,AlphaGo的成功很大程度上得益于围棋游戏规则有限,整个游戏过程不会用到下棋规则之外的知识。但对于星际争霸之类的游戏,机器取得优异成绩就显得较为困难。因为这类策略性游戏所用到的知识类型多样,不仅需要有关排兵布阵、武器应用、战场环境等相关知识,还可能涉及很多与社会及文化相关的知识。智能客服等领域的成功也一定程度上归功于客服知识的相对封闭。


所以,领域应用所涉及的知识体系越是封闭,越容易成功。这是在很多领域知识图谱落地过程中选择应用试点时,应该遵循的一个基本原则。


延续上面的分析,进一步可以回答业界十分关心的一个问题:知识图谱在什么样的应用中易于成功?知识图谱落地应用往往遵循一个循序渐进的推进过程。因此,很多行业都希望选取特定场景先行试点,那么选择什么样的场景进行优先验证呢?知识图谱只是整个智能化技术的手段之一。


知识图谱不能解决行业的所有问题,那么,某个特定的行业应用到底能否受益于知识图谱技术?这些都是知识图谱的行业应用亟需回答的问题。


我根据前两页内容中观点,给出几个选择依据。第一、领域知识相对封闭。已经阐明,越是封闭的领域越容易成功。第二、简单知识与简单应用。何为简单知识?关于知识复杂性的评估实际上是个非常复杂的问题。知识复杂性的内在机理和评测机制是个十分有趣的科学问题。从操作层面来看,可以从特定人群学习某类知识所需要时间来评估。假设我们只考虑完成了基础教育(比如中国的九年制基础教育)的人群。对于不同知识,这一人群学习周期不一。


比如,很显然对于某个企业的客服知识,几乎一周简单培训就可以上岗。但是对于治病的知识,即便一个医学院学生可能也要十多年才能掌握。所以,大部分对于人而言简单岗位培训就能胜任的工作,也往往适用于机器,是有可能优先被机器所代替的。还有些应用场景属于知识的简单应用,比如同样是在医疗领域,医院的导诊岗位,就属于医学知识的简单应用。只需要根据症状进行简单的分类,即便不够精准,在具体科室医生治疗时还有进一步纠正的机会。


第三、较少涉及常识。如果领域应用所涉及的知识集中在人类知识结构的上层(也就是专业性较强的知识),较少涉及底层的常识,则相对容易成功。其根本原因在于常识的获取是异常困难的。人类很容易理解常识,但是对于机器而言常识理解却十分困难。我们知道太阳从东边升起,人是两条腿走路的,鱼是在水里游的,而机器很难知道这些常识。因为常识是人类在学龄前通过身体与世界的交互与体验积累而得。我们每个人都理解常识,因而不用挂在嘴边说明,就能彼此理解。


因此,文本或者语料中对于常识鲜有提及,常识因而也就无从抽取。常识缺失也就成了知识库、知识工程,乃至整个人工智能的痛点问题。目前机器智能在常识理解方面仍然举步维艰。因此,我认为大量用到常识的应用面临巨大挑战。比如说有公司想做财务报销方面的智能化,此类场景就有可能涉及很多常识。比如半夜12点打出租车,或者说打出租车打了四五个小时,又或者从美国飞到上海只飞了一个小时,这都是有问题的。这些问题我们人类很容易识别,因为都是常识问题,但对机器而言就很困难。


还有一个非常典型的大量用到常识的场景就是刑侦智能化。公安人员在破案过程中用到大量常识,嫌疑人往往是基于证据根据常识进行推理而锁定的,因此让机器代替刑侦人员破案仍十分困难。



很多领域知识图谱应用的方案是建立在通用知识图谱基础之上的。GKG对于DKG有着重要的支撑作用。一方面,GKG可以给很多DKG提供高质量的种子事实。这些种子事实可以用做样本指导抽取模型的训练。


另一方面,GKG可以提供领域模式(Schema)。领域知识图谱构建时需要花费巨大精力设计领域模式,比如为了构建娱乐领域知识图谱,必须首先明确描述歌手的属性列表(有时又称作template)中应该包括专辑、代表作、签约公司等属性。


虽然GKG对于特定领域的实体覆盖率不高,但是通过聚合GKG中所有歌手信息,有关歌手的描述模板基本上已经能够满足初步需要。后续只需要在初始模板基础上逐步完善即可。能否充分利用通用知识图谱对很多领域知识图谱的构建具有重要意义。这就是为什么很多团队不遗余力地做好通用知识图谱(比如我们实验室的通用百科知识图谱CN-DBpedia和通用概念图谱CN-Probase)的重要原因。


领域图谱建好之后又可以反哺通用知识图谱。复旦知识工场实验室就是按照这个思路持续运营多年。我们先通过通用知识图谱为各领域知识图谱构建提供大量的种子事实,使得快速构建很多领域知识图谱成为可能。各领域知识图谱做的很深很细之后,可以反过来补充通用知识图谱。GKG与DKG这种互补形式的架构在很多领域的知识图谱落地中是个非常重要的架构。



知识表示其实一直以来都有两种基本的方式:符号化表示与数值型表示。两者孰优孰劣?各自的适用场景是怎样的?一直是知识图谱落地过程中常被问及的问题。第一种是符号化(Symbol)的表示,比如说PPT左上角的小规模语义网络,表达了约翰给玛丽一本书这样的事实。这个例子中大量的使用了字符、箭头等符号。显然,符号表示形象直观,易于我们理解。人是可以理解符号的,但是没办法理解向量。知识表示还有一种表示是数值化的分布式表示,它是面向机器的。机器是无法“理解”符号的,只能处理数值和向量。分布式表示是将符号知识集成到深度学习框架中的一种基本方式。符号化表示是一种显性的表示,而分布式表示是一种隐性的表示。符号化表示易理解、可解释,而分布式表示是难解释、难理解的。符号化表示的另一优点在于推理能力。比如数学定理证明都是基于符号推理进行的。虽然基于知识图谱的分布式表示,也可以开展一定程度上的推理,但是需要指出的是分布式推理已经很大程度上丢失了知识图谱原有的语义,分布式推理只能推理语义相关性,而无法明确是何种意义下的语义相关。我个人倾向于认为分布式推理离实用还很遥远。如果非要为知识图谱上的分布式推理找到应用场景,那只能作为很多复杂任务的预处理步骤,将明显语义不相关的元素加以剪枝,后续仍需要能够充分利用符号语义的方法进行精准的语义推理。


不管是大数据时代还是人工智能时代,都需要领域知识图谱。我曾在《知识图谱与认知智能》这一报告中详细阐述过相关观点。这里补充几个观点。首先,需要知识图谱去构建知识引擎,去释放大数据的价值。很多行业和企业都有数据,都有大数据。但是这些大数据非但没有创造价值,反而成为了很多行业的负担。阻碍大数据价值变现的根本原因在于缺少智能化的手段,更具体而言就是缺少一个能像人一样能够理解行业数据的知识引擎。


行业从业人员为什么能理解行业数据进而开展行业工作呢,那是因为行业从业人员具有相应的行业知识。如果把同样的行业知识赋予机器,构建一个行业知识引擎,那么机器也就可能代替人去理解、挖掘、分析、使用数据,可以代替行业从业人员挖掘数据中的价值。


简言之,将行业知识赋予机器,让机器代替行业从业人员从事简单知识工作,是当下以及未来一段时间内基于机器认知智能的行业智能化的本质。在行业智能化的实现进程中,通过领域知识图谱对数据进行提炼、萃取、关联、整合,形成行业知识或领域知识,让机器形成对于行业工作的认知能力,从而实现一个行业知识引擎,实现知识工作自动化,已经成为了行业智能化日渐清晰的一条路径。


伴随着人工智能时代的到来,“智能”机器无处不在,手表、手环、手机、音响、电视、机器人等等都已是随处可见的“智能”实体,这些机器逐步走入人们的生活。但是现在机器普遍不具备人们所期望的智能,与人类智能相比只能算是机器“智障”。机器“智障”的根本原因是这些机器没有一个像人一样聪慧的大脑。


事实上,机器最缺的是一个机器智脑。没有这样的智脑,机器只能是一具没有“灵魂”的僵尸。人脑之所以能给人类带来智慧的根本原因在于人脑能够存储知识与利用知识。类似地,机器智脑也需要有知识的充实,才能够形成真正意义上的机器智能。富含各类知识的机器智脑,可以理解人类的语言与行为,能够理解我们所从事的行业工作,从而使得自然人机交互成为可能,使得人机协同混合智能成为可能。最终为机器融入人类社会扫清障碍,促进人机和谐共存。



从社会发展的角度来看,可以说将领域知识赋予机器,将是进一步提高机器生产力、释放劳动力资源、降低人力成本的重要技术。伴随着我国人口红利的逐步消失,各行业的人力成本普遍提高,各行业对于机器生产力的提升提出了普遍诉求。伴随着工业4.0的推进以及自动化技术普及,传统实体行业人的体力劳动已经逐步被解放。人力资源成本释放的空间已经逐步从体力劳动转向脑力劳动。


当下,人工智能技术给人力成本降低带来的新机遇主要体现在用机器代替人的脑力劳动,特别是各行业的简单知识工作将逐步为机器所代替。机器的记忆几乎是无穷无尽的,机器决策时可以同时考虑数百万变量,机器运算的速度远超人类,所以一旦把行业知识赋予机器,就能实现高度自动化的机器工作。在这一背景下,各行业都走上了智能化升级转型的道路,而实现机器的认知能力是智能化升级转型的基本路径。



以政府数据治理为例,在政府领域,由于历史原因,政府各部门的信息系统的建设多是各自为阵,形成了大量的信息孤岛,这就给政府数据价值发挥带来了巨大障碍。这些障碍尤为集中地体现在政府数据治理与应用方面,碎片化数据难以融合、数据共享开放缺乏必要依据、政府决策仍然缺乏来自数据的有效支撑、政府数据的应用模式相对单一。


但如果有了领域知识图谱,就可以为数据融合提供元数据,将政府数据融合从繁重的手工整合中解放出来。比如ID与身份证通常指代相同的字段,这样的元数据可以自动建立A数据库中名为“ID”的字段与B数据库中名为“身份证”字段的映射。政府在大力推进政府数据共享和开放过程中,必须确保数据安全。


比如个人隐私数据很敏感是不可以开放的,当前拟开放的数据都要经过人工的审慎判断,耗时耗力。但事实上知识图谱可以为政府数据开放提供必要的背景知识。比如如果设定了个人信息是不能开放的,那么个人的住址、出生日期等等都是不能开放的,这可以通过背景知识库自动推断得到。政府数据的决策和分析缺乏可解释依据,这些依据都可以从领域知识图谱里去寻找。


当前政府数据的应用多是简单的检索与分析,缺乏基于深度推理的智能应用。而推理需要一个基本的载体,推理载体的天然选择是知识图谱。基于符号化的知识图谱,可以开展有效的深度推理。



领域知识图谱系统的生命周期包含四个重要环节:知识表示、知识获取、知识管理与知识应用。这四个环节循环迭代。知识应用环节明确应用场景,明确知识的应用方式。


知识表示定义了领域的基本认知框架,明确领域有哪些基本的概念,概念之间有哪些基本的语义关联。比如企业家与企业之间的关系可以是创始人关系,这是认知企业领域的基本知识。知识表示只提供机器认知的基本骨架,还要通过知识获取环节来充实大量知识实例。比如乔布斯是个企业家,苹果公司是家企业,乔布斯与苹果公司就是“企业家-创始人-企业”这个关系的一个具体实例。知识实例获取完成之后,就是知识管理。这个环节将知识加以存储与索引,并为上层应用提供高效的检索与查询方式,实现高效的知识访问。


四个环节环环相扣,彼此构成相邻环节的输入与输出。在知识的具体应用过程中,会不断得到用户的反馈,这些反馈会对知识表示、获取与管理提出新的要求,因此整个生命周期会不断迭代持续演进下去。


在整个生命周期中,我认为最重要的是明确知识的应用场景,也就是回答清楚一个问题:利用领域知识解决怎样的应用问题。再根据应用来反推到底需要怎样的知识表示,明确知识边界。在当下的很多知识图谱应用实践中,有一个不好的苗头就是“为了图谱而图谱”。虽然知识图谱是当下的热点技术,尽管每年各行业大量的信息化预算苦苦寻求好的落地项目,尽管资本界热钱涌动寻求好的投资标的,但是不应以知识图谱为名,不应盲目炒作知识图谱技术。


知识图谱技术是当下热点不假,但绝不是万能技术。它能解决的问题是有限的,它的成功应用有着苛刻的条件。需要谨慎选择落地场景;需要客观评估技术成熟度以及技术与应用的适配程度;需要充分考虑资源与收益的平衡等一系列问题。


为图谱而图谱,或者仅以图谱为名而行悖图谱之实,对知识图谱产业有百害而无一利。历史上前车之鉴太多了。很多做AI的研究人员与公司,最终落得个“骗子”下场。历史上的AI技术的演进道路呈现出大起大落之势。


这一系列现象归根结底是因为人们对于AI预期过高,盲目大规模上线很多知识工程项目,无视应用场景而对知识库盲目求大求全。殊不知人之所以伟大其实就在于任何一个普通人所掌握的知识都可以说是无边无界的。我们现在构建的知识库离机器达到普通人认知世界所需要的水平还十分遥远。知识资源建设可以说是永远在路上,没有最好,只有更好。


所以,比较务实的作法是:谨慎选择合适的应用场景,构建满足场景需要的知识资源。这背后体现的也是典型的自下而上的建设思路。大而全、自上而下、运动式知识资源建设(这个经常是国内的典型方式),容易遇到难以逾越的技术瓶颈。一言以蔽之,知识资源建设的基本原则是适度。“适”是指对于特定应用场景的适配,“度”是指合理把控知识的边界与体量。



我们常用三元组表示领域知识图谱。我想强调一点,知识图谱只能表达一些简单的关联事实,但很多领域应用的需求已经远远超出了三元组所能表达的简单关联事实,实际应用日益对于利用更加多元的知识表示丰富和增强知识图谱的语义表达能力提出了需求。


这一趋势首先体现在对于时间和空间语义的拓展与表达方面。有很多知识和事实是有时间和空间条件的,比如说“美国总统是特朗普”这个事实的成立是有时间条件的,十年前美国的总统不是特朗普,十年之后应该也不大可能是特朗普。还有很多事实是有空间条件的,比如“早餐是烧饼与油条”这件事,在中国是这样,但是在西方并非如此,西方的早餐可能是咖啡、面包。


从时空维度拓展知识表示对很多特定领域具有较强的现实意义。比如在位置相关的应用中,如何将POI(Point of Interest)与该POI相关实体加以关联,成为当下拓展POI语义表示的重要任务之一。比如将“邯郸路220号”(复旦大学地址)关联到“复旦大学”是十分有意义的。在互联网娱乐领域,粉丝们往往不仅仅关心某个明星的妻子是谁,可能更关心明星的前任妻子、前任女友等信息,这些应用都对事实成立的时间提出了需求。


第二、增强知识图谱的跨媒体语义表示。当前的知识图谱主要以文本为主,但是实际应用需要有关某个实体的各种媒体表示方式,包括声音、图片、视频等等。比如对于实体“Tesla Model S”,我们需要将其关联到相应图片和视频。知识图谱时空维度拓展在物理实现上可以通过定义四元组或者五元组加以实现。跨媒体表示可以通过定义相关的属性加以实现。


知识图谱的语义增强总体上而言将是未来一段时间知识表示的重要任务。知识图谱作为语义网络,侧重于表达实体、概念之间的语义关联,还难以表达复杂因果关联与复杂决策过程。


如何利用传统知识表示增强知识图谱,或者说如何融合知识图谱与传统知识表示,更充分地满足实际应用需求,是知识图谱领域值得研究的问题之一。在一些实际应用中,研究人员已经开始尝试各种定制的知识表示,在知识图谱基础上适当扩展其他知识表示是一个值得尝试的思路。



领域知识图谱的构建是个领域知识的获取过程。这一过程系统性强,涉及众多技术手段。但是其基本流程具有一定共性,如PPT所示。


第一步是模式(Schema)设计。这一步是传统本体设计所要解决的问题。基本目标是把认知领域的基本框架赋予机器。在所谓认知基本框架中需要指定领域的基本概念,以及概念之间subclassof关系(比如足球领域需要建立“足球运动员”是“运动员”的子类);需要明确领域的基本属性;明确属性的适用概念;明确属性值的类别或者范围。比如“效力球队”这个属性一般是定义在足球运动员这个概念上,其合理取值是一个球队。


此外,领域还有大量的约束或规则,比如对于属性是否可以取得多值的约束(比如“奖项”作为属性是可以取得多值的),再比如球队的“隶属球员”属性与球员的“效力球队”是一对互逆属性。这些元数据对于消除知识库不一致、提升知识库质量具有重要意义。


第二步是明确数据来源。在这一步要明确建立领域知识图谱的数据来源。可能来自互联网上的领域百科爬取,可能来自通用百科图谱的导出、可能来自内部业务数据的转换,可能来自外部业务系统的导入。应该尽量选择结构化程度相对较高、质量较好的数据源,以尽可能降低知识获取代价。

         

第三步是词汇挖掘。人们从事某个行业的知识的学习,都是从该行业的基本词汇开始的。在传统图书情报学领域,领域知识的积累往往是从叙词表的构建开始的。叙词表里涵盖的大都是领域的主题词,及这些词汇之间的基本语义关联。在这一步我们是要识别领域的高质量词汇、同义词、缩写词,以及领域的常见情感词。比如在政治领域,我们需要知道特朗普又被称为川普,其英文简称为Trump。

         

第四步是领域实体发现(或挖掘)。需要指出的是领域词汇只是识别出领域中的重要短语和词汇。但是这些短语未必是一个领域实体。从领域文本识别某个领域常见实体是理解领域文本和数据的关键一步。


在实体识别后,还需对实体进行实体归类。能否把实体归到相应的类别(或者说将某个实体与领域类别或概念进行关联),是实体概念化的基本目标,是理解实体的关键步骤。比如将特朗普归类到政治人物、美国总统等类别,对于理解特朗普的含义具有重要意义。


实体挖掘的另一个重要任务是实体链接,也就是将文本里的实体提及(Mention)链接到知识库中的相应实体。实体链接是拓展实体理解,丰富实体语义表示的关键步骤。

         

第五步是关系发现。关系发现,或者知识库中的关系实例填充,是整个领域知识图谱构建的重要步骤。关系发现根据不同的问题模型又可以分为关系分类、关系抽取和开放关系抽取等不同变种。


关系分类旨在将给定的实体对分类到某个已知关系;关系抽取旨在从文本中抽取某个实体对的具体关系;开放关系抽取(OpenIE)从文本中抽取出实体对之间的关系描述。也可以综合使用这几种模型与方法,比如根据开放关系抽取得到的关系描述将实体对分类到知识库中的已知关系。

         

第六步是知识融合。因为知识抽取来源多样,不同的来源得到的知识不尽相同,这就对知识融合提出了需求。知识融合需要完成实体对齐、属性融合、值规范化。实体对齐是识别不同来源的同一实体。属性融合是识别同一属性的不同描述。不同来源的数据值通常有不同的格式、不同的单位或者不同的描述形式。比如日期有数十种表达方式,这些需要规范化到统一格式。


最后一步是质量控制。知识图谱的质量是构建的核心问题。知识图谱的质量可能存在几个基本问题:缺漏、错误、陈旧。先谈知识库的缺漏问题。某种意义上,知识完备对于知识资源建设而言似乎是个伪命题,我们总能枚举出知识库中缺漏的知识。


知识缺漏对于自动化方法构建的知识库而言尤为严重。但是即便如此,构建一个尽可能全的知识库仍是任何一个知识工程的首要目标。既然自动化构建无法做到完整,补全也就成为了提升知识库质量的重要手段。补全可以是基于预定义规则(比如一个人出生地是中国,我们可以推断其国籍也可能是中国),也可以从外部互联网文本数据进行补充(比如很多百科图谱没有鲁迅身高的信息,需要从互联网文本寻找答案进行补充)。


其次是纠错。自动化知识获取不可避免地会引入错误,这就需要纠错。根据规则进行纠错是基本手段,比如A的妻子是B,但B的老公是C,那么根据妻子和老公是互逆属性,我们知道这对事实可能有错。知识图谱的结构也可以提供一定的信息帮助推断错误关联。比如在由概念和实例构成的Taxonomy中,理想情况下应该是个有向无环图,如果其中存在环,那么有可能存在错误关联。最后一个质量控制的重要问题是知识更新。


更新是一个具有重大研究价值,却未得到充分研究的问题。很多领域都有一定的知识积累。但问题的关键在于这些知识无法实时更新。比如电商的商品知识图谱,往往内容陈旧,无法满足用户的实时消费需求(比如“战狼同款饰品”这类与热点电影相关的消费需求很难在现有知识库中涵盖)。


因此,电商领域的图谱构建要从被动的供给侧构建过渡到主动的消费侧构建,要从管理者视角转变成消费者视角。消费侧的需求充分体现在搜索日志和购物篮中。面向日志、购物篮的自动知识获取将成为研究热点。


经历了上述步骤之后得到一个初步的领域知识图谱。在实际应用中会得到不少反馈,这些反馈作为输入进一步指导上述流程的完善,从而形成闭环。此外,除了上述自动化构建的闭环流程,还应充分考虑人工的干预。人工补充很多时候是行之有效的方法。


比如一旦发现部分知识缺漏或陈旧,可以通过特定的知识编辑工具实现知识的添加、编辑和修改。也可以利用众包手段将很多知识获取任务分发下去。如何利用众包手段进行大规模知识获取,是个十分有意思的问题,涉及到知识贡献的激励机制,我前几年有个题为《未来人机区分》的报告,专门讨论如何利用知识问答形式的验证码来做知识获取,可以百度此文获取更多信息。


可以看出,整个领域知识图谱的构建是个系统工程,流程复杂,内涵丰富,涉及到知识表示、自然语言处理、数据库、数据挖掘、众包等一系列技术。也正是这个原因使得知识图谱落地对很多行业或者企业来讲都是一个十分重要的举措,甚至是战略性举措。



领域图谱的评价标准是落地过程中常常被问及的问题。总体而言有三个方面的指标应该予以充分考虑。第一个是规模。前面已经指出,绝对完备的知识库是不存在的,完备只能相对于一些封闭领域而言。因此,规模一般而言是个相对指标。


关于规模问题,在落地过程有两个有意思的问题。一是,当前知识库是否足以支撑实际应用,或者多大规模就够了?这个问题没有绝对答案。我给出的是看实际应用的反馈,也就是知识图谱上线后的用户满意率。比如在利用知识图谱支撑语义搜索方面,多少查询能被准确理解,这个比率是个重要的指标。


当然查询理解率不仅涉及知识图谱的覆盖率也关系到理解模型的准确率。因此,在实际评估中需要客观对待查询理解率,不能简单地将查询理解率直接等同于图谱覆盖率。


第二个指标是质量。当前AI系统努力避免的一个事实就是“Garbage-In-Garbage-Out”。喂给机器的是错误知识,就只会导致错误的应用结果。提升知识图谱质量是知识图谱构建的核心命题。那么知识图谱质量又应该从哪些维度进行衡量呢?


我想至少有几个维度。一是、准确率。比如是否存在错误事实,错误事实所占比例都是质量的直接反映。二是、知识的深度。比如很多知识库只涵盖人物这样的大类,无法细化到作家、音乐家、运动员这些细分类目(fine-grained concepts)。三是、知识的粒度。粒度越细应用越灵活,应用时精读越高。细化知识表示的粒度是领域知识图谱的构建过程中的重要任务之一。


第三个方面是实时。绝对实时是不现实的,因而实时大都从知识的延时(latency)角度进行刻画。短延时显然是我们期望的。知识图谱的更新是个复杂问题,不同的更新策略导致不同的延时。


一般而言,知识图谱更新包括被动更新和主动更新两种方式。实际应用中往往是两种策略的结合。被动更新往往采取周期性更新策略,这种策略延时长,适用于大规模知识更新。主动更新,往往从需求侧、消费侧、应用侧出发,主动触发相关知识更新,适用于头部或者高频实体及知识的更新。



领域知识图谱如何存储也是大家很关注的问题。由于知识图谱本质上在表达关联,天然地可以用图加以建模,因而很多人想到用图数据库对领域知识图谱加以存储。图数据库的确是知识图谱存储选型的重要选择,但是不是唯一选择。传统关系数据库,近几年充分发展的其他类型的NoSQL数据库在很多场景下也是合理选择。那么数据库的选择考虑的要素是什么呢?


有两类重要的选型要素:图谱的规模以及操作复杂度。从图谱的规模角度来看,百万、千万的节点和关系规模(以及以下规模)的图谱对于图数据库的需求并不强烈,图数据库的必要性在中等或者小规模知识图谱上体现并不充分。但是如果图谱规模在数亿节点规模以上,图数据库就十分必要了。


从操作复杂性来看,图谱上的操作越是复杂,图数据库的必要性越是明显。图谱上的全局计算(比如平均最短路径的计算),图谱上的复杂遍历,图谱上的复杂子图查询等等都涉及图上的多步遍历。图上的多步遍历操作如果是在关系数据库上实现需要多个联结(Join)操作。多个联结操作的优化一直以来是关系数据库的难题。图数据库系统实现时针对多步遍历做了大量优化,能够实现高效图遍历操作。


除了上述因素之外,还应该充分考虑系统的易用性、普及性与成熟度。总体而言图数据库还是发展中的技术,对于复杂图数据管理系统的优化也是只有少部分专业人员才能从事的工作。在数据库选型时需要充分考虑这些因素。我们实验室在实现CN-DBpedia(2000万实体、2.2亿关系)在线服务系统时先后采用了Relational DB、Graph DB、MongoDB,最后出于综合考虑选用的是MongoDB,已经稳定运行了三年,累计提供10亿多次API服务。



领域知识图谱如何查询?通常对于表达为RDF形式的知识图谱,可以使用SPARQL查询语言。SPARQL语言针对RDF数据定义了大量的算子,对于推理操作有着很好支撑,因而能够适应领域中的复杂查询与复杂推理。


从应用角度来看,也可以将知识图谱仅仅表达为无类型的三元组。对于这种轻量级的表示,关系数据库与传统NoSQL数据库也是较好选择。那么此时,SQL语句就是比较好的选择。SQL十分成熟,语法简单,用户众多且有着几十年的成功应用基础。很多领域图谱上的查询是相对简单的,以单步或者两到三步遍历居多。


此时,SQL完全能够胜任。但是不排除有一些特定场景,特别是公共安全、风控管理等领域,通常需要进行复杂关联分析,需要较长路径的遍历,需要开展复杂子图挖掘,此时SQL的表达能力就显得相对较弱了。

         

未来的趋势是直接利用自然语言进行知识图谱数据访问。但是总体而言这还只是个比较热门的研究主题,离成熟还有一定距离。其根本困难在于自然语言的复杂性,在于自然语言自动化转成形式语言的巨大复杂性。


但这显然是有着巨大商业价值的问题。数据(知识)访问方法的呆板是制约数据(知识)价值发挥的重大瓶颈。一旦突破这一瓶颈,数据与知识的使用将从传统的被动式定制获取变成主动式按需获取,传统管理信息系统以及知识管理将面临全新机遇。


领域知识图谱的应用落脚点无外乎搜索、推荐、问答、解释与决策。对于这几个应用我在《知识图谱与认知智能》一文中有详细论述,在此不再赘述。这里补充回答几个问题。第一、知识图谱支撑下的应用与没有知识图谱特别是与基于机器学习的方案相比有何优势?这是很多应用单位会提出的问题。


首先,从宏观层面来讲,通过领域知识图谱对于领域知识进行表达与沉淀,使得机器能够具备领域数据认知能力。这种能力使得推理和解释成为可能。推理和解释是当前的机器学习(特别是深度学习)还难以有效解决的问题。


其次,从具体任务来看,知识图谱能显著提升一些具体任务的效果。知识图谱支撑下的搜索相对于传统搜索,能够显著提高召回率,也就是能够解决“搜的到”的问题;知识图谱支撑下的推荐相对于传统推荐,能够显著提高推荐的个性化,也就是能够解决“推得准”的问题;知识图谱支撑下的推荐相对于其他问答方式,能够显著提高问答的召回率,特别是需要推理才能回答的问题。


知识图谱支撑下的决策分析相对于传统决策,能够提供决策的可解释依据,能够为决策提供背景知识支持。解释是知识图谱的天然使命,因为人只能理解符号知识,人是解释的对象。

         

另一个更为深刻的问题是相对于机器学习,特别是深度学习,符号化知识对于机器智能是否必要?一些机器学习专家认为,机器智能只需要数值表示就可以了,所谓知识也无外乎就是深度神经网络中足够抽象层次上的分布式表示,体现为相应层次上的网络结构与参数。符号知识对于机器智能是个伪命题,知识表达与沉淀对于机器智能也就无从谈起。


深度学习顶级专家Hinton也有类似观点。一定程度上,我赞同这个观念。但问题在于,虽然我们身处在大数据时代,但是当前的数据还不足以让机器习得人类所具有的高度抽象知识。


我们现在的大数据大部分还只是应用场景下产生的直接数据,缺乏产生这些数据的需求与动机的背景数据,缺乏能够解释数据之所以如此的因果链条数据。比如我们都知道数据挖掘领域的啤酒尿布的例子,意思是说大部分买尿布的人也会同时买啤酒。可是我们从来都不知道为什么。事实上很可能是产妇行动不便,让爸爸来买尿布,一个家庭有了新生儿之后,初为人父的爸爸们或多或少比较紧张兴奋,因而顺带购买啤酒以缓解压力。我们现在的数据采集还无法延伸到能够理解统计规律背后的因果链条的地步。


还有很多数据背后是由常识支撑的。比如今年夏天冷饮销售量增长,是由于天气炎热,而天气炎热,人们自然会饮用冷饮。这些知识是我们人人都知道的,但是机器无法知道。常识缺失使得机器无法重建完整的数据关联分析链条。


所以,大数据时代的“数据饥荒”是机器学习无法习得人类水准的高层抽象知识的重要原因之一。那么有人也许会争论说,既然“数据饥荒”是根本原因,那么有可能通过增强数据采集广度与力度来消弭这一问题。我个人认为很难。诚然随着大数据日积月累,这一问题或许会得到一定程度上的缓解。 但是常识获取的困难仍然会对这一问题的解决带来巨大挑战。


因此,至少在当下一段时期内,充分利用符号知识,补齐数据驱动方法的短板应该是比较务实的思路。但是即便意识到这一点,在方法层面我们也仍然捉襟见肘。如何利用符号知识增强统计学习模型仍然是个具有挑战性的问题。对于这一问题的具体论述可以参考《当知识图谱“遇见”深度学习》一文。


领域知识图谱落地有哪些最佳实践呢?作为一个工程性学科,不断总结其最佳实践是非常有必要的。这里根据我们落地的几个项目分享几个最佳实践。


第一、应用引领。这个问题在知识图谱项目周期时,已经强调了。明确应用出口对于图谱的规划是非常重要的。第二、避难就简。在当前阶段,文本处理仍然面临不少困难,落地困难重重。即便是一个简单的中文分词任务仍然需要大量的研究工作,比如“南京市长江大桥”分词,可以是“南京市+长江大桥”,也可以是“南京市长+江大桥”。


因此,在实际落地过程中,应该综合考虑各条技术路径的难度,优先考虑从结构化的数据中加以转换,其次是半结构化数据(比如带格式标记的各类文本,如XML、百科文本等等),最后才是无结构的自然语言文本。


事实上,如果能够综合考虑各类技术路径,融合各类数据源,采取一些巧妙的策略可以显著提升非结构化文本抽取的有效性。比如利用结构化数据与非结构文本进行比对,获取很多高质量的关系描述就是一个非常有效的策略。


第三、避免从零开始。很多行业或者企业在建设知识图谱项目时,或多或少已经存在很多知识资源,比如领域本体、叙词表等等,互联网上的公开来源也存在不少相关的百科资源,通用百科图谱已经涵盖了某个领域大量的实体。充分利用这些资源,提高领域知识图谱构建的起点,是知识图谱项目成功落地的一个关键因素之一。


已经存在的这些知识资源很多是消耗了巨大人工成本经过多年持续积累而得到的,充分利用这些知识资源对于领域知识图谱的构建与完善具有重要意义。知识资源建设有个很有意思的现象,那就是让人从无到有的贡献一条知识的代价要显著高于让人在一个不那么完善的知识库上进行完善的代价。因此,尽可能复用是知识资源建设的重要策略之一。


最后一条是跨领域迁移。其思路很简单,如果我们为中国移动做了个领域知识图谱,那么为中国电信建设图谱,是不需要从零开始的。相近领域的知识是可以复用的。这个原则也意味着知识图谱落地过程中,将来会涌现出一大批面向特定行业知识图谱解决方案的企业。


领域知识图谱还存在哪些挑战?总体上在知识表示、获取和应用等各层面均存在很多挑战。在知识表示层面,越来越多的领域应用不仅仅需要关联事实这种简单知识表示,还要表达包括逻辑规则、决策过程在内的复杂知识;需要同时表达静态知识和动态知识。


单单知识图谱已经不足以解决领域的很多实际问题。如何去增强知识图谱的语义表达能力,如何综合使用多种知识表示来解决实际应用中的复杂问题是非常重要的研究课题。第二,在知识获取方面,领域知识图谱一般样本很小,如果需要构建抽取模型,那就需要基于小样本构建有效的模型。


目前基于小样本的机器学习仍然面临巨大挑战。解决这一问题的思路之一就是利用知识引导机器学习模型的学习过程。具体实现手段已经有不少团队在开展相关的探索工作,比如利用知识增强样本、利用知识构建目标函数的正则项以及利用知识构建优化目标的约束等等。


总体而言,这仍然是个开放问题需要巨大的研究投入。第三,知识的深度应用。如何将领域知识图谱有效应用于各类应用场景,特别是推荐、搜索、问答之外的应用,包括解释、推理、决策等方面的应用仍然面临巨大挑战,仍然存在很多开放性问题。



工业互联网




产业智能官  AI-CPS


通过工业互联网操作系统(云计算+大数据+物联网+区块链+人工智能),场景中构建:状态感知-实时分析-自主决策-精准执行-学习提升的机器智能认知系统;实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链





版权声明产业智能官(ID:AI-CPS推荐的文章,除非确实无法确认,我们都会注明作者和来源。涉权烦请联系协商解决。联系、投稿邮箱:erp_vip@hotmail.com




登录查看更多
19

相关内容

2020年中国《知识图谱》行业研究报告,45页ppt
专知会员服务
239+阅读 · 2020年4月18日
专知会员服务
51+阅读 · 2020年1月13日
知识图谱更新技术研究及其应用,复旦大学硕士论文
专知会员服务
103+阅读 · 2019年11月4日
中文知识图谱构建技术以及应用的综述
专知会员服务
312+阅读 · 2019年10月19日
知识图谱本体结构构建论文合集
专知会员服务
106+阅读 · 2019年10月9日
医疗知识图谱构建与应用
专知会员服务
384+阅读 · 2019年9月25日
知识图谱的行业落地实现
竹间智能Emotibot
51+阅读 · 2019年9月16日
这是一份通俗易懂的知识图谱技术应用落地指南
51CTO博客
24+阅读 · 2019年3月15日
领域应用 | NLP 和知识图谱:金融科技领域的“双子星”
开放知识图谱
21+阅读 · 2018年8月12日
如何从零开始搭建知识图谱?
AI前线
23+阅读 · 2018年7月2日
干货 | 知识图谱的技术与应用
深度学习与NLP
18+阅读 · 2018年6月15日
领域应用 | 知识图谱的技术与应用
开放知识图谱
17+阅读 · 2018年6月14日
【知识图谱】中医临床知识图谱的构建与应用
产业智能官
60+阅读 · 2017年12月18日
Arxiv
14+阅读 · 2019年11月26日
Arxiv
20+阅读 · 2019年11月23日
Arxiv
20+阅读 · 2019年9月7日
Arxiv
30+阅读 · 2019年3月13日
Arxiv
11+阅读 · 2018年9月28日
VIP会员
相关VIP内容
2020年中国《知识图谱》行业研究报告,45页ppt
专知会员服务
239+阅读 · 2020年4月18日
专知会员服务
51+阅读 · 2020年1月13日
知识图谱更新技术研究及其应用,复旦大学硕士论文
专知会员服务
103+阅读 · 2019年11月4日
中文知识图谱构建技术以及应用的综述
专知会员服务
312+阅读 · 2019年10月19日
知识图谱本体结构构建论文合集
专知会员服务
106+阅读 · 2019年10月9日
医疗知识图谱构建与应用
专知会员服务
384+阅读 · 2019年9月25日
相关资讯
知识图谱的行业落地实现
竹间智能Emotibot
51+阅读 · 2019年9月16日
这是一份通俗易懂的知识图谱技术应用落地指南
51CTO博客
24+阅读 · 2019年3月15日
领域应用 | NLP 和知识图谱:金融科技领域的“双子星”
开放知识图谱
21+阅读 · 2018年8月12日
如何从零开始搭建知识图谱?
AI前线
23+阅读 · 2018年7月2日
干货 | 知识图谱的技术与应用
深度学习与NLP
18+阅读 · 2018年6月15日
领域应用 | 知识图谱的技术与应用
开放知识图谱
17+阅读 · 2018年6月14日
【知识图谱】中医临床知识图谱的构建与应用
产业智能官
60+阅读 · 2017年12月18日
相关论文
Arxiv
14+阅读 · 2019年11月26日
Arxiv
20+阅读 · 2019年11月23日
Arxiv
20+阅读 · 2019年9月7日
Arxiv
30+阅读 · 2019年3月13日
Arxiv
11+阅读 · 2018年9月28日
Top
微信扫码咨询专知VIP会员