实践了下怎么建一个简单的知识图谱,两个版本,一个从 0 开始(start from scratch),一个在 CN-DBpedia 基础上补充,把 MySQL,PostgreSQL,Neo4j 数据库都尝试了下。自己跌跌撞撞摸索可能踩坑了都不知道,欢迎讨论。
1. CN-DBpedia 构建流程
知识库可以分为两种类型,一种是以 Freebase,Yago2 为代表的 Curated KBs,主要从维基百科和 WordNet 等知识库中抽取大量的实体及实体关系,像是一种结构化的维基百科。另一种是以 Stanford OpenIE,和我们学校 Never-Ending Language Learning (NELL) 为代表的 Extracted KBs,直接从上亿个非结构化网页中抽取实体关系三元组。
与 Freebase 相比,这样得到的知识更加多样性,但同时精确度要低于 Curated KBs,因为实体关系和实体更多的是自然语言的形式,如“奥巴马出生在火奴鲁鲁。” 可以被表示为(“Obama”, “was also born in”, “ Honolulu”)。
下面以 CN-DBpedia 为例看下知识图谱大致是怎么构建的。
上图分别是 CN-DBpedia 的构建流程和系统架构。知识图谱的构建是一个浩大的工程,从大方面来讲,分为知识获取、知识融合、知识验证、知识计算和应用几个部分,也就是上面架构图从下往上走的一个流程,简单来走一下这个流程。
2. 数据支持层
最底下是知识获取及存储,或者说是数据支持层,首先从不同来源、不同结构的数据中获取知识,CN-DBpedia 的知识来源主要是通过爬取各种百科知识这类半结构化数据。
至于数据存储,要考虑的是选什么样的数据库以及怎么设计 schema。选关系数据库还是 NoSQL 数据库?要不要用内存数据库?要不要用图数据库?这些都需要根据数据场景慎重选择。
CN-DBpedia 实际上是基于 mongo 数据库,参与开发的谢晨昊提到,一般只有在基于特定领域才可能会用到图数据库,就知识图谱而言,基于 json (bson) 的 mongo 就足够了。用到图查询的领域如征信,一般是需要要找两个公司之间的关联交易,会用到最短路径/社区计算等。
schema 的重要性不用多说,高质量、标准化的 schema 能有效降低领域数据之间对接的成本。我们希望达到的效果是,对于任何数据,进入知识图谱后后续流程都是相同的。换言之,对于不同格式、不同来源、不同内容的数据,在接入知识图谱时都会按照预定义的 schema 对数据进行转换和清洗,无缝使用已有元数据和资源。
3