1、知识引擎/图谱简介
知识图谱,是结构化的语义知识库,用于迅速描述物理世界中的概念及其相互关系,通过知识图谱能够将信息、数据以及链接关系聚集为知识,使信息资源更易于计算、理解以及评价,并能实现知识的快速响应和推理。
1.1 构建技术分类
知识图谱的构建技术主要有自顶向下和自底向上两种。
- 自顶向下构建:借助百科类网站等结构化数据源,从高质量数据中提取本体和模式信息,加入到知识库里。
- 自底向上构建:借助一定的技术手段,从公开采集的数据中提取出资源模式,选择其中置信度较高的信息,加入到知识库中。
1.2 “实体-关系-实体”三元组
下图是典型的知识图谱样例示意图。可以看到,“图谱”中有很多节点,如果两个节点之间存在关系,他们就会被一条无向边连接在一起,这个节点我们称为实体(Entity),节点之间的这条边,我们称为关系(Relationship)。
知识图谱的基本单位,就是“实体(Entity)-关系(Relationship)-实体(Entity)” 构成的三元组,这也是知识图谱的核心。
2、数据类型和存储方式
2.1 数据类型
知识图谱的原始数据类型一般来说有三类:
- 结构化数据(Structed Data),如:关系数据库、链接数据
- 半结构化数据(Semi-Structured Data),如:XML、JSON、百科
- 非结构化数据(Unstructured Data),如:图片、音频、视频
2.2 知识存储方式
知识存储是针对知识图谱的知识表示形式设计底层存储方式,完成各类知识的存储,以支持对大规模图数据的有效管理和计算。结合存储设计和查询效率层面,使用图数据库可支持对3种数据类型的存储。以下是图数据库选型思路。
2.2.1 图数据库选型
- 粗筛:结合其他图数据库选型经验,从DB-ENGINES排名中分别按国内外筛选出排名第一的 Neo4j 和 Nebula Graph。
- 细筛:从优缺点、使用成本、是否适配信创、性能等方面,对 Neo4j、Nebula Graph 进行进一步选型调研。综合考虑信创和后续扩展等方面,建议优先选择Nebula Graph。
| 维度 |
Neo4j |
Nebula Graph |
| 优缺点 |
优点:成熟的图数据库,功能全面,Cypher语法友好,生态丰富(Bloom、算法库)。 缺点:社区版仅支持单机,企业版扩展受限,写性能依赖主节点,开源受限。 |
优点:分布式架构,水平扩展,支持万亿边,性能强劲(导入/查询均为业界领先),对大数据生态兼容。 缺点:生态相对年轻,上手难度略高,高级功能需企业版。 |
| 是否开源 |
部分开源。 社区版GPL v3开源,企业版闭源需商业授权 |
开源。 核心引擎Apache 2.0完全开源,企业版增强功能收费 |
| 信创兼容 |
不兼容 无国产平台官方认证,主要支持x86 Linux环境。 |
兼容 已通过华为鲲鹏、飞腾、海光、兆芯等国产CPU和操作系统兼容认证,适配信创环境 |
| 保险行业场景与案例 |
国外保险公司构建理赔知识图谱检测欺诈;国内案例较少 |
众安保险:风控反欺诈(手机号异常热点检测) 泰康在线:构建客户关系图用于精准推荐。支持理赔反欺诈、客户画像、裂变营销 |
| 权威性能测评 |
在LDBC SNB基准测试中表现优异;中小规模图查询较优 |
在10亿边测试中,单跳查询2ms(Neo4j需数十秒);多跳查询延迟低于5秒(Neo4j数百秒)。导入性能和扩展性均优于Neo4j |
| 适用场景 |
深度图分析:Cypher语言对复杂路径表达更简洁 开发测试场景:社区版免费且生态成熟 事务一致性要求极高:如金融交易反欺诈 |
需支持10亿+级节点规模:如全国级供应链网络 信创改造强需求:国产芯片/0S全栈认证 高并发实时查询:如IoT设备状态追踪 |
架构与扩展能力
| 维度 |
Neo4j |
Nebula Graph |
| 架构类型 |
单机/因果集群(企业版支持水平扩展) |
分布式存储计算分离架构(支持10亿+节点) |
| 扩展能力 |
垂直扩展为主,企业版支持读写分离集群 |
水平扩展(存储/计算节点独立扩容) |
| 信创适配 |
需手动验证JDK/0S兼容性(如达梦适配) |
完成鲲鹏/麒麟/统信全栈兼容认证 |
数据模型与查询能力
| 维度 |
Neo4j |
Nebula Graph |
| 核心模型 |
原生属性图,Schema可选 |
属性图模型,支持多跳索引与动态Schema |
| 查询语言 |
Cypher,专为图设计,复杂路径表达更灵活 |
nGQL,类SQL语法,支持图遍历+SQL混合查询 |
| 事务支持 |
单机强一致,企业版支持分布式事务 |
支持ACID,Raft协议保障分布式事务 |
大数据生态集成
| 维度 |
Neo4j |
Nebula Graph |
| Hive对接 |
需通过ETL工具(如Apache NiFi)同步数据 |
提供Spark Connector实现Hive联邦查询 |
| 实时计算 |
Spark Connector需额外转换图结构 |
原生集成Flink CDC,支持毫秒级数据同步 |
| 数据质量 |
依赖外部工具实现ETL质量校验 |
支持Schema约束与数据版本控制 |
性能与适用场景
| 维度 |
Neo4j |
Nebula Graph |
| 写入性能 |
单机批量导入优化(约10kTPS) |
分布式批量导入(TPS可达100k+) |
| 查询场景 |
深度递归查询(如社交传播链挖掘) |
高并发多跳查询(如供应链5层路径分析) |
| 适用场景 |
实时推荐系统、知识图谱构建 |
金融风控、工业物联网、国产化替代 |
成本与运维
| 维度 |
Neo4j |
Nebula Graph |
| 授权费用 |
社区版免费,生产环境需商业授权 |
Apache 2.0开源协议(无商业授权限制) |
| 运维寒杂度 |
单机部詈简单,集群需专业DBA支持 |
依赖Kubernetes管理分布式集群 |
| 国产化成本 |
- |
预置信创适配清单(含JDK/OS兼容脚本) |
3、知识图谱的架构
知识图谱的架构主要可以被分为:
3.1 逻辑架构
在逻辑上,我们通常将知识图谱划分为两个层次:数据层和模式层。
- 模式层:在数据层之上,是知识图谱的核心,存储经过提炼的知识,通常通过本体库来管理这一层(本体库可以理解为面向对象里的“类”这样一个概念,本体库就储存着知识图谱的类)。
- 数据层:存储真实的数据。
3.2 技术架构
知识图谱的整体架构如图所示,其中虚线框内的部分为知识图谱的构建过程,同时也是知识图谱更新的过程。
首先,我们有一大堆的数据,这些数据可能是结构化的、非结构化的以及半结构化的;
然后,我们基于这些数据来构建知识图谱,这一步主要是通过一系列自动化或半自动化的技术手段,来从原始数据中提取出知识要素,即一堆实体关系,并将其存入我们的知识库的模式层和数据层。
4、构建技术
构建知识图谱是一个迭代更新的过程,根据知识获取的逻辑,每一轮迭代包含三个阶段:
- 知识抽取:从各种类型的数据源中提取出实体、属性以及实体间的相互关系,在此基础上形成本体化的知识表达。
- 知识融合:在获得新知识之后,需要对其进行整合,以消除矛盾和歧义,比如某些实体可能有多种表达,某个特定称谓也许对应于多个不同的实体等。
- 知识加工:对于经过融合的新知识,需要经过质量评估之后(部分需要人工参与甄别),才能将合格的部分加入到知识库中,以确保知识库的质量。
4.1 知识抽取
知识抽取:从各种类型的数据源中提取出实体、属性以及实体间的相互关系,形成结构化的知识并存入到知识图谱中。
知识抽取主要包括三个核心子任务:
- 命名实体识别(NER):识别文本中的实体提及,如人名、地名、机构名等
- 关系抽取:挖掘实体间的语义关联,如"职业"、"所属机构"等关系
- 属性抽取:提取实体的属性信息,如生日、身高、地址等
知识获取作为构建知识图谱的第一步,通常有四种方式:众包法、爬虫、机器学习、专家法。
4.2 知识融合
通过信息抽取,我们就从原始的非结构化和半结构化数据中获取到了实体、关系以及实体的属性信息。但这些信息之间的关系是扁平化的,缺乏层次性和逻辑性;并且还存在大量冗杂和错误的信息。那么如何解决这一问题,就是在知识融合这一步里我们需要做的了。
知识融合包括2部分内容:实体链接、知识合并。
实体链接的流程:
- 从文本中通过实体抽取得到实体指称项。
- 进行实体消歧和共指消解,判断知识库中的同名实体与之是否代表不同的含义以及知识库中是否存在其他命名实体与之表示相同的含义。
- 在确认知识库中对应的正确实体对象之后,将该实体指称项链接到知识库中对应实体。
知识合并:
一般来说知识合并主要分为两种:合并外部知识库,主要处理数据层和模式层的冲突;合并关系数据库,有RDB2RDF等方法。
4.3 知识加工
通过前面的信息抽取,从原始语料中提取出了实体、关系与属性等知识要素,并且经过知识融合,消除实体指称项与实体对象之间的歧义,得到一系列基本的事实表达。
然而事实本身并不等于知识。要想最终获得结构化,网络化的知识体系,还需要经历知识加工的过程。知识加工主要包括3方面内容:本体抽取、知识推理和质量评估。
本体抽取:
自动化本体构建过程包含三个阶段: 实体并列关系相似度计算 → 实体上下位关系抽取 → 本体的生成。
知识推理:
在我们完成了本体构建这一步之后,一个知识图谱的雏形便已经搭建好了。但可能在这个时候,知识图谱之间大多数关系都是残缺的,缺失值非常严重,那么这个时候,我们就可以使用知识推理技术,去完成进一步的知识发现。
当然知识推理的对象也并不局限于实体间的关系,也可以是实体的属性值,本体的概念层次关系等。
- 推理属性值:已知某实体的生日属性,可以通过推理得到该实体的年龄属性;
- 推理概念:已知(老虎,科,猫科)和(猫科,目,食肉目)可以推出(老虎,目,食肉目)
这一块的算法主要可以分为3大类:基于知识表达的关系推理技术;基于概率图模型的关系推理技术路线示意图;基于深度学习的关系推理技术路线示意图。
质量评估:
质量评估也是知识库构建技术的重要组成部分,这一部分存在的意义在于:可以对知识的可信度进行量化,通过舍弃置信度较低的知识来保障知识库的质量。
4.4 知识更新
从逻辑上看,知识库的更新包括概念层的更新和数据层的更新。
- 概念层的更新:新增数据后获得了新的概念,需要自动将新的概念添加到知识库的概念层中。
- 数据层的更新:主要是新增或更新实体、关系、属性值,对数据层进行更新需要考虑数据源的可靠性、数据的一致性(是否存在矛盾或冗杂等问题)等可靠数据源,并选择在各数据源中出现频率高的事实和属性加入知识库。
知识图谱的内容更新有两种方式:
- 全面更新:指以更新后的全部数据为输入,从零开始构建知识图谱。这种方法比较简单,但资源消耗大,而且需要耗费大量人力资源进行系统维护;
- 增量更新:以当前新增数据为输入,向现有知识图谱中添加新增知识。这种方式资源消耗小,但目前仍需要大量人工干预(定义规则等),因此实施起来十分困难。
5、构建环节总结
| 技术环节 |
核心目标 |
关键技术 |
典型工具/方法 |
| 知识抽取 |
从非结构化、半结构化数据中提取结构化知识 |
命名实体识别(NER)、关系抽取、属性抽取 |
spaCy、BERT、大语言模型、Stanford NLP、OpenIE |
| 知识融合 |
整合多源知识,消除冲突和歧义,确保一致性 |
实体链接(Entity Linking)、共指消解(Coreference Resolution)、知识校验(Knowledge Validation)、实体对齐(Entity Alignment) |
基于图的协同推断、张量分解、相似度计算(如余弦相似度、Jaccard相似度)、规则推理 |
| 知识表示 |
将知识转化为计算机可处理和存储的形式 |
RDF(资源描述框架)、属性图(Property Graph)、向量化表示(Embedding) |
Neo4j(图数据库)、Jena(RDF框架)、RDF4J、TransE/TransH/TransR(知识嵌入模型)、Word2Vec/GloVe(词嵌入) |
| 知识加工 |
对抽取和融合后的知识进行进一步处理,提升质量 |
本体构建(Ontology Building)、知识推理(Knowledge Reasoning)、质量评估(Quality Assessment) |
Protégé(本体编辑工具)、OWL(Web本体语言)、基于规则的推理机(如Jess、Drools)、基于概率图模型的推理、深度学习推理模型 |
| 知识存储 |
实现知识的高效持久化与检索 |
图数据库存储、RDF存储、关系数据库存储(针对简单结构)、分布式存储 |
Neo4j、Nebula Graph 、Amazon Neptune(图数据库)、Jena Fuseki、Virtuoso(RDF存储)、MySQL/PostgreSQL(关系数据库)、HBase(分布式存储) |
| 知识更新 |
保持知识图谱的时效性和准确性,新增或修改知识 |
增量更新(Incremental Update)、全面更新(Full Update)、动态知识获取 |
自定义ETL流程、消息队列(如Kafka)结合更新机制、基于时间戳或版本控制的更新策略 |
| 知识查询与检索 |
提供高效的知识查询服务,支持复杂查询和推理 |
SPARQL(RDF查询语言)、Cypher(Neo4j查询语言)、图遍历算法、基于索引的检索 |
Apache Jena(支持SPARQL查询)、Neo4j(支持Cypher查询)、Elasticsearch(基于索引的检索) |
| 知识可视化 |
以图形化方式展示知识图谱,提升可理解性和交互性 |
图布局算法、交互式可视化技术 |
D3.js、Gephi、Cytoscape.js、Neo4j Browser(内置可视化工具)、NebulaGraph Explorer |
附:知识图谱技术路线图:
知识图谱技术要素:知识图谱涉及的技术要素可以分为表示、存储、抽取、融合、推理、问答和分析等几个方面。
参考链接:
知识图谱的构建全流程_知识图谱构建-CSDN博客
一文读懂知识图谱的主要技术 (qq.com)
12类知识图谱构建与应用开源工具总结:从开放知识库到知识抽取再到推理可视化_知识图谱可视化工具-CSDN博客 来源:程序园用户自行投稿发布,如果侵权,请联系站长删除 免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |