|
阅读：5102回复：0
知识图谱的技术
目录:
1. 概论 随着移动互联网的发展，万物互联成为了可能，这种互联所产生的数据也在爆发式地增长，而 且这些数据恰好可以作为分析关系的有效原料。如果说以往的智能分析专注在每一个个体上， 在移动互联网时代则除了个体，这种个体之间的关系也必然成为我们需要深入分析的很重要一 部分。 在一项任务中，只要有关系分析的需求，知识图谱就“有可能”派的上用场。 图片：WX20190327-163438.png  2. 什么是知识图谱? 知识图谱是由Google公司在2012年提出来的一个新的概念。从学术的角度，我们可以对知识图 谱给一个这样的定义:“知识图谱本质上是语义网络(Semantic Network)的知识库”。但这有 点抽象，所以换个角度，从实际应用的角度出发其实可以简单地把知识图谱理解成多关系图 (Multi-relational Graph)。 那什么叫多关系图呢? 学过数据结构的都应该知道什么是图(Graph)。图是由节点(Vertex) 和边(Edge)来构成，但这些图通常只包含一种类型的节点和边。但相反，多关系图一般包含 多种类型的节点和多种类型的边。比如左下图表示一个经典的图结构，右边的图则表示多关系 图，因为图里包含了多种类型的节点和边。这些类型由不同的颜色来标记。 图片：WX20190327-163452.png  在知识图谱里，我们通常用“实体(Entity)”来表达图里的节点、用“关系(Relation)”来表达图 里的“边”。实体指的是现实世界中的事物比如人、地名、概念、药物、公司等，关系则用来表达 不同实体之间的某种联系，比如人-“居住在”-北京、张三和李四是“朋友”、逻辑回归是深度学习 的“先导知识”等等。 现实世界中的很多场景非常适合用知识图谱来表达。 比如一个社交网络图谱里，我们既可以 有“人”的实体，也可以包含“公司”实体。人和人之间的关系可以是“朋友”，也可以是“同事”关 系。人和公司之间的关系可以是“现任职”或者“曾任职”的关系。 类似的，一个风控知识图谱可以 包含“电话”、“公司”的实体，电话和电话之间的关系可以是“通话”关系，而且每个公司它也会有 固定的电话。 3. 知识图谱的表示 知识图谱应用的前提是已经构建好了知识图谱，也可以把它认为是一个知识库。这也是为什么 它可以用来回答一些搜索相关问题的原因，比如在Google搜索引擎里输入“Who is the wife of Bill Gates?”，我们直接可以得到答案-“Melinda Gates”。这是因为我们在系统层面上已经创建好 了一个包含“Bill Gates”和“Melinda Gates”的实体以及他俩之间关系的知识库。所以，当我们执 行搜索的时候，就可以通过关键词提取("Bill Gates", "Melinda Gates", "wife")以及知识库上的 匹配可以直接获得最终的答案。这种搜索方式跟传统的搜索引擎是不一样的，一个传统的搜索 引擎它返回的是网页、而不是最终的答案，所以就多了一层用户自己筛选并过滤信息的过程。 图片：WX20190327-163509.png  在现实世界中，实体和关系也会拥有各自的属性，比如人可以有“姓名”和“年龄”。当一个知识图 谱拥有属性时，我们可以用属性图(Property Graph)来表示。下面的图表示一个简单的属性 图。李明和李飞是父子关系，并且李明拥有一个138开头的电话号，这个电话号开通时间是2018 年，其中2018年就可以作为关系的属性。类似的，李明本人也带有一些属性值比如年龄为25 岁、职位是总经理等。 图片：WX20190327-163516.png  这种属性图的表达很贴近现实生活中的场景，也可以很好地描述业务中所包含的逻辑。除了属 性图，知识图谱也可以用RDF来表示，它是由很多的三元组(Triples)来组成。RDF在设计上的 主要特点是易于发布和分享数据，但不支持实体或关系拥有属性，如果非要加上属性，则在设 计上需要做一些修改。目前来看，RDF主要还是用于学术的场景，在工业界我们更多的还是采用 图数据库(比如用来存储属性图)的方式。感兴趣的读者可以参考RDF的相关文献，在文本里不 多做解释。 4. 知识抽取 知识图谱的构建是后续应用的基础，而且构建的前提是需要把数据从不同的数据源中抽取出 来。对于垂直领域的知识图谱来说，它们的数据源主要来自两种渠道:一种是业务本身的数 据，这部分数据通常包含在公司内的数据库表并以结构化的方式存储;另一种是网络上公开、 抓取的数据，这些数据通常是以网页的形式存在所以是非结构化的数据。 前者一般只需要简单预处理即可以作为后续AI系统的输入，但后者一般需要借助于自然语言处 理等技术来提取出结构化信息。比如在上面的搜索例子里，Bill Gates和Malinda Gate的关系就 可以从非结构化数据中提炼出来，比如维基百科等数据源。 图片：WX20190327-163524.png  信息抽取的难点在于处理非结构化数据。在下面的图中，我们给出了一个实例。左边是一段非 结构化的英文文本，右边是从这些文本中抽取出来的实体和关系。在构建类似的图谱过程当 中，主要涉及以下几个方面的自然语言处理技术: a. 实体命名识别(Name Entity Recognition) b. 关系抽取(Relation Extraction) c. 实体统一(Entity Resolution) d. 指代消解(Coreference Resolution) 下面针对每一项技术解决的问题做简单的描述，以至于这些是具体怎么实现的，不在这里一一 展开，感兴趣的读者可以查阅相关资料。 图片：WX20190327-163536.png  首先是实体命名识别，就是从文本里提取出实体并对每个实体做分类/打标签:比如从上述文本 里，我们可以提取出实体-“NYC”，并标记实体类型为 “Location”;我们也可以从中提取 出“Virgil's BBQ”，并标记实体类型为“Restarant”。这种过程称之为实体命名识别，这是一项相对 比较成熟的技术，有一些现成的工具可以用来做这件事情。其次，我们可以通过关系抽取技 术，把实体间的关系从文本中提取出来，比如实体“hotel”和“Hilton property”之间的关系 为“in”;“hotel”和“Time Square”的关系为“near”等等。 图片：WX20190327-163543.png  另外，在实体命名识别和关系抽取过程中，有两个比较棘手的问题:一个是实体统一，也就是 说有些实体写法上不一样，但其实是指向同一个实体。比如“NYC”和“New York”表面上是不同的 字符串，但其实指的都是纽约这个城市，需要合并。实体统一不仅可以减少实体的种类，也可 以降低图谱的稀疏性(Sparsity);另一个问题是指代消解，也是文本中出现的“it”, “he”, “she”这些词到底指向哪个实体，比如在本文里两个被标记出来的“it”都指向“hotel”这个实体。 图片：WX20190327-163551.png  实体统一和指代消解问题相对于前两个问题更具有挑战性。 5. 知识图谱的存储 知识图谱主要有两种存储方式:一种是基于RDF的存储;另一种是基于图数据库的存储。它们 之间的区别如下图所示。RDF一个重要的设计原则是数据的易发布以及共享，图数据库则把重点 放在了高效的图查询和搜索上。其次，RDF以三元组的方式来存储数据而且不包含属性信息，但 图数据库一般以属性图为基本的表示形式，所以实体和关系可以包含属性，这就意味着更容易 表达现实的业务场景。 图片：WX20190327-163600.png  根据最新的统计(2018年上半年)，图数据库仍然是增长最快的存储系统。相反，关系型数据 库的增长基本保持在一个稳定的水平。同时，我们也列出了常用的图数据库系统以及他们最新 使用情况的排名。 其中Neo4j系统目前仍是使用率最高的图数据库，它拥有活跃的社区，而且 系统本身的查询效率高，但唯一的不足就是不支持准分布式。相反，OrientDB和 JanusGraph(原Titan)支持分布式，但这些系统相对较新，社区不如Neo4j活跃，这也就意味着使用过程当中不可避免地会遇到一些刺手的问题。如果选择使用RDF的存储系统，Jena或许一 个比较不错的选择。 图片：WX20190327-163608.png  |
|
