知识图谱详解：从实体关系到 AI 时代的结构化知识网络

Fri, 15 May 2026 00:00:00 +0000

引言

互联网和企业系统里有大量知识，但这些知识大多散落在网页、文档、表格、数据库和业务系统中。

人可以通过阅读理解其中的含义，但机器很难直接知道：

谁和谁有关？
这个概念属于哪个类别？
一个事件影响了哪些对象？
两个看似不同的名称是否指向同一个实体？

例如一段文本：

`1`	`周杰伦发行了专辑《范特西》，其中包含歌曲《双截棍》。`

人读完之后能自然理解三件事：

1
2
3

周杰伦 -> 发行 -> 范特西
范特西 -> 包含 -> 双截棍
周杰伦 -> 歌手 -> 是

知识图谱要做的事情，就是把这些隐含在文本和数据里的知识，组织成机器可以查询、计算和推理的结构化关系网络。

一句话概括：

知识图谱是一种以“实体”和“关系”为核心组织知识的图结构，它让知识从零散文本变成可计算的网络。

为什么需要知识图谱

传统数据系统很擅长保存记录。

例如用户表、订单表、商品表、文章表，都能清楚保存每一条数据。

但很多问题关注的不是单条记录，而是记录之间的关系。

例如：

某个用户和哪些账号共享设备？
这家公司和哪些风险企业存在股权关系？
喜欢这部电影的人还可能喜欢哪些导演？
某个疾病和哪些症状、药物、检查项目相关？
一篇论文引用了哪些关键工作，又被哪些论文引用？

这类问题的重点是“连接”。

如果只用表结构，关系会分散在很多外键、中间表和业务逻辑里，查询和理解成本都很高。

知识图谱的价值在于，它把知识组织成一张网：

1
2
3

实体是节点
关系是边
属性是节点或边上的补充信息

当知识被组织成图，系统就可以沿着关系路径查询、分析和推理。

什么是知识图谱

知识图谱由三个基本元素组成：实体、关系、属性。

实体

实体是图中的节点，表示现实世界或业务系统中的对象。

常见实体包括：

人
公司
地点
产品
电影
疾病
药物
论文
事件
账号
设备

例如：

周杰伦
范特西
双截棍
阿里巴巴
杭州

这些都可以是实体。

关系

关系是实体之间的连接。

例如：

周杰伦 -> 发行 -> 范特西
范特西 -> 包含 -> 双截棍
阿里巴巴 -> 总部位于 -> 杭州
马云 -> 创办 -> 阿里巴巴

关系让知识不再是孤立点，而是互相连接的网络。

属性

属性是对实体或关系的描述。

例如：

周杰伦：
  职业 = 歌手
  出生日期 = 1979-01-18

范特西：
  类型 = 专辑
  发行时间 = 2001-09-14

属性回答的是“这个实体有什么特征”，关系回答的是“这个实体和其他实体有什么联系”。

三元组：知识图谱的基本表达

知识图谱最经典的表达方式是三元组：

`1`	`主体 Subject - 谓词 Predicate - 客体 Object`

例如：

刘德华 -> 出生地 -> 香港
刘德华 -> 职业 -> 演员
刘德华 -> 参演 -> 无间道
无间道 -> 导演 -> 刘伟强

每个三元组表达一个事实。

大量三元组连接起来，就形成了知识图谱。

刘德华
  -> 参演 -> 无间道
  -> 出生地 -> 香港
  -> 职业 -> 演员

无间道
  -> 导演 -> 刘伟强
  -> 类型 -> 警匪片
  -> 主演 -> 梁朝伟

从图的角度看，实体是点，关系是线。查询知识图谱，本质上就是在图上找点、找边、找路径。

知识图谱和关系型数据库的区别

知识图谱不是为了替代关系型数据库，而是解决不同类型的问题。

维度	关系型数据库	知识图谱
数据组织	表、行、列	节点、边、属性
核心关注	记录与事务	实体与关系
查询方式	SQL	Cypher / SPARQL / Gremlin
擅长场景	订单、库存、报表、事务处理	关系查询、路径分析、语义推理
扩展关系	常需要改表或加中间表	增加节点和边即可
可解释性	依赖表结构和业务逻辑	关系路径天然可解释

举个例子，如果要查询“刘德华参演过哪些由刘伟强导演的电影”，关系型数据库可能需要多表 join：

actor
movie_actor
movie
movie_director
director

而在知识图谱中，这就是沿着关系路径查询：

`1`	`刘德华 -> 参演 -> 电影 <- 导演 <- 刘伟强`

当关系越来越复杂，图结构会更自然。

知识图谱的两种常见模型

知识图谱常见的数据模型有两类：RDF 图和属性图。

RDF 图

RDF 使用三元组表达知识：

`1`	`subject predicate object`

它强调语义标准和互操作性，常用于开放知识库、语义网、学术和公共数据场景。

例如：

1
2

<周杰伦> <发行> <范特西>
<范特西> <包含> <双截棍>

RDF 常配合 SPARQL 查询语言使用。

属性图

属性图把节点和边都看作可以携带属性的对象。

例如：

1
2
3

(Person {name: "周杰伦", occupation: "歌手"})
  -[:RELEASED {date: "2001-09-14"}]->
(Album {name: "范特西"})

属性图更贴近工程开发习惯，Neo4j、NebulaGraph 等图数据库常采用这类模型。

属性图通常用 Cypher 或类似语言查询。

知识图谱如何构建

知识图谱构建不是简单地把数据导入图数据库，而是一条完整的数据加工链路。

典型流程如下：

数据源
  -> 数据清洗
  -> 实体识别
  -> 关系抽取
  -> 属性抽取
  -> 实体对齐
  -> 知识融合
  -> 图存储
  -> 查询与应用

数据源

知识图谱的数据可以来自三类来源。

第一类是结构化数据。

例如：

MySQL 表
Excel 表格
CRM 系统
ERP 系统
订单系统
用户画像系统

这类数据质量较高，字段明确，适合直接映射成实体、关系和属性。

第二类是半结构化数据。

例如：

JSON
XML
HTML 页面
百科词条
API 返回结果

这类数据有一定结构，但需要解析和清洗。

第三类是非结构化数据。

例如：

文档
网页
论文
新闻
客服记录
会议纪要

这类数据最难处理，需要自然语言处理、信息抽取或大模型辅助。

实体识别

实体识别是从文本中找出关键对象。

例如：

`1`	`马云于 1999 年在杭州创办阿里巴巴。`

可以识别出：

马云：人物
杭州：地点
阿里巴巴：公司
1999 年：时间

实体识别质量直接影响后续图谱质量。如果实体识别错了，关系抽取和查询都会跟着错。

关系抽取

关系抽取是判断实体之间有什么关系。

还是这句话：

`1`	`马云于 1999 年在杭州创办阿里巴巴。`

可以抽取出：

1
2
3

马云 -> 创办 -> 阿里巴巴
阿里巴巴 -> 创办时间 -> 1999 年
阿里巴巴 -> 创办地点 -> 杭州

关系抽取可以基于规则、传统机器学习、深度学习，也可以借助大语言模型完成。

属性抽取

属性抽取关注实体自身的信息。

例如公司实体：

公司名称：阿里巴巴
成立时间：1999 年
总部：杭州
行业：互联网

属性和关系的边界不是绝对的。

“总部位于杭州”可以建成属性，也可以建成关系：

1
2

阿里巴巴.headquarters = 杭州
阿里巴巴 -> 总部位于 -> 杭州

如果后续需要围绕“杭州”做路径分析，建成关系会更灵活。

实体对齐

实体对齐要解决的是“多个名称是否指向同一个对象”。

例如：

北京大学
北大
Peking University
PKU

这些可能指向同一个实体。

再比如：

苹果
Apple
苹果公司
水果苹果

这里就要区分公司和水果。

实体对齐需要结合名称、上下文、属性、关系和业务规则。

知识融合

知识融合负责合并来自不同来源的信息。

它要处理：

重复实体
冲突属性
不同格式
不同可信度
不同更新时间
不同数据来源优先级

例如某公司注册资本在两个来源中不一致：

1
2

来源 A：注册资本 1000 万
来源 B：注册资本 1200 万

系统不能简单随机选一个，而要根据来源可信度、更新时间和业务规则决定如何处理。

知识图谱如何存储和查询

知识图谱可以存储在图数据库、RDF 存储，也可以和关系型数据库、搜索引擎混合使用。

图数据库

常见图数据库包括：

Neo4j
NebulaGraph
JanusGraph
TigerGraph
Amazon Neptune

图数据库适合处理多跳关系查询、路径分析、社区发现和关系网络探索。

查询语言

不同图模型对应不同查询语言。

常见有：

Cypher：Neo4j 常用
SPARQL：RDF 图常用
Gremlin：Apache TinkerPop 生态常用

一个 Cypher 示例：

1
2
3

MATCH (p:Person)-[:WORKS_AT]->(c:Company)
WHERE c.name = "OpenAI"
RETURN p.name

它表达的是：

`1`	`找到所有工作于 OpenAI 的人`

再看一个电影图谱查询：

1
2

MATCH (a:Actor {name: "刘德华"})-[:ACTED_IN]->(m:Movie)<-[:DIRECTED]-(d:Director)
RETURN m.name, d.name

它表达的是：

`1`	`找到刘德华参演过的电影，以及这些电影的导演`

知识图谱的典型应用

知识图谱适合关系复杂、需要解释和推理的场景。

搜索增强

普通搜索主要匹配关键词。

知识图谱可以让搜索理解实体和关系。

例如用户搜索：

苹果创始人

搜索系统应该知道这里的“苹果”更可能指 Apple 公司，而不是水果。

知识图谱可以帮助系统理解：

1
2

苹果公司 -> 创始人 -> 史蒂夫·乔布斯
苹果公司 -> 创始人 -> 史蒂夫·沃兹尼亚克

搜索结果因此更精准。

智能问答

知识图谱非常适合事实型问答。

例如：

`1`	`谁导演了刘德华主演的《无间道》？`

图谱查询路径是：

`1`	`刘德华 -> 参演 -> 无间道 -> 导演 -> 刘伟强`

相比直接让模型生成答案，图谱问答更可追溯，也更容易保证事实一致性。

风控反欺诈

风控场景天然适合图结构。

例如：

账号 -> 绑定 -> 手机号
账号 -> 使用 -> 设备
设备 -> 连接 -> IP
手机号 -> 归属 -> 用户
用户 -> 发生 -> 交易

如果大量账号共享设备、手机号、地址或收款账户，就可能存在团伙欺诈。

知识图谱可以帮助发现这种隐藏关系。

医疗和金融知识管理

医疗图谱可以表示：

疾病 -> 具有症状 -> 症状
疾病 -> 推荐检查 -> 检查项目
疾病 -> 可用药物 -> 药物
药物 -> 禁忌症 -> 疾病

金融图谱可以表示：

企业 -> 法人 -> 人
企业 -> 投资 -> 企业
企业 -> 涉及 -> 风险事件
人 -> 任职 -> 企业

这些行业都高度依赖关系、规则和可解释性。

知识图谱与大语言模型

大语言模型擅长理解自然语言和生成文本，但它并不天然等于可靠知识库。

LLM 存在几个问题：

可能产生幻觉
对事实更新不及时
不擅长精确多跳关系查询
很难解释知识来源
对复杂实体关系容易混淆

知识图谱刚好能补足这些问题。

知识图谱的优势是：

事实明确
关系结构清晰
查询路径可追踪
可以做规则和路径推理
数据可以持续更新

二者结合后，可以形成这样的流程：

用户问题
  -> LLM 理解意图
  -> 生成图查询
  -> 查询知识图谱
  -> 获取结构化事实
  -> LLM 组织自然语言回答

例如用户问：

`1`	`刘德华和梁朝伟合作过哪些电影？`

LLM 可以把问题转成图查询：

`1`	`刘德华 -> 参演 -> 电影 <- 参演 <- 梁朝伟`

图谱返回事实后，LLM 再把结果组织成自然语言。

这样既利用了 LLM 的语言能力，也利用了知识图谱的事实约束。

知识图谱增强 RAG

普通 RAG 的检索对象通常是文本片段。

流程大致是：

用户问题
  -> 向量检索
  -> 召回相关文本块
  -> LLM 基于文本块回答

这种方式简单有效，但在实体关系复杂的问题上容易不够稳定。

例如：

1
2
3

A 公司通过哪些中间公司间接投资了 B 公司？
某个药物和某个疾病之间是否存在禁忌关系？
某篇论文的核心理论来自哪些前置工作？

这些问题不是单段文本匹配，而是关系路径查询。

知识图谱增强 RAG 可以把检索对象从“文本块”扩展为“实体、关系和路径”。

维度	普通 RAG	知识图谱增强 RAG
检索对象	文本片段	实体、关系、路径、子图
结果形式	非结构化文本	结构化事实
擅长问题	文档问答、语义匹配	多跳关系、事实推理、路径解释
优势	实现简单、泛化好	可解释、结构清晰、事实稳定
挑战	召回噪声、上下文冗余	图谱构建成本高、维护复杂

GraphRAG、KG-RAG 都是这个方向的代表。

它们的共同思路是：

1
2
3

先用图结构组织知识
再围绕实体和关系检索相关子图
最后让 LLM 基于结构化事实生成回答

知识图谱与 Agent

知识图谱也可以成为 Agent 的长期知识底座。

对于 Agent 来说，知识图谱可以承担三种角色。

作为知识库

Agent 遇到事实型问题时，不直接凭模型记忆回答，而是查询图谱。

例如：

1
2
3

这个客户关联了哪些风险事件？
这个服务依赖哪些下游系统？
这个功能涉及哪些业务规则？

图谱返回结构化事实后，Agent 再组织回答或执行下一步。

作为记忆系统

Agent 的长期记忆也可以图谱化。

例如：

用户 -> 偏好 -> 中文回答
项目 -> 使用 -> Hugo
文章 -> 属于 -> AI 分类
问题 -> 原因 -> 日期被识别为未来内容

相比普通文本记忆，图谱记忆更适合表达关系和路径。

作为规划辅助

Agent 做复杂任务时，可以用图谱理解依赖关系。

例如软件系统图谱：

服务 A -> 调用 -> 服务 B
服务 B -> 依赖 -> 数据库 C
接口 X -> 使用 -> 缓存 Y
模块 M -> 修改影响 -> 模块 N

当 Agent 要修改某个模块时，可以先查询影响范围，降低误操作风险。

构建知识图谱的挑战

知识图谱很有价值，但构建成本不低。

数据质量

图谱质量高度依赖数据质量。

如果源数据里有错误、重复、缺失和格式不一致，图谱只会把这些问题放大。

抽取准确率

从自然语言中抽取实体和关系并不容易。

例如：

1
2

苹果发布了新手机。
我买了一个苹果。

两个“苹果”含义不同。

如果实体消歧做不好，图谱会混入错误关系。

关系设计

关系设计太粗，会失去表达能力。

关系设计太细，会导致图谱难维护。

例如：

`1`	`人 -> 关联 -> 公司`

这个关系太粗，不知道是创办、任职、投资、控股还是合作。

但如果关系类型无限细分，也会增加抽取和查询成本。

知识更新

知识不是静态的。

公司会改名，人员会离职，产品会下架，政策会变化，论文会被新研究修正。

知识图谱需要处理：

增量更新
版本管理
过期事实
冲突事实
来源追踪

规模和性能

图数据规模变大后，多跳查询可能很慢。

需要考虑：

索引设计
分布式存储
热点实体
查询深度限制
缓存策略
离线预计算

一个简单案例：电影知识图谱

为了把概念串起来，可以看一个电影知识图谱。

实体包括：

演员
导演
电影
类型
奖项
用户

关系包括：

演员 -> 出演 -> 电影
导演 -> 导演 -> 电影
电影 -> 属于 -> 类型
电影 -> 获得 -> 奖项
用户 -> 喜欢 -> 电影
用户 -> 喜欢 -> 演员

构建后，它可以回答很多问题。

问题一：刘德华演过哪些警匪片

查询路径：

`1`	`刘德华 -> 出演 -> 电影 -> 属于 -> 警匪片`

问题二：刘德华和梁朝伟合作过哪些电影