引言

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

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

1
2
3
4

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

例如一段文本：

1

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

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

1
2
3

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

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

一句话概括：

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

为什么需要知识图谱

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

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

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

例如：

1
2
3
4
5

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

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

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

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

1
2
3

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

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

什么是知识图谱

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

实体

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

常见实体包括：

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

例如：

1
2
3
4
5

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

这些都可以是实体。

关系

关系是实体之间的连接。

例如：

1
2
3
4

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

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

属性

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

例如：

1
2
3
4
5
6
7

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

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

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

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

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

1

主体 Subject - 谓词 Predicate - 客体 Object

例如：

1
2
3
4

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

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

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

1
2
3
4
5
6
7
8
9

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

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

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

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

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

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

1
2
3
4
5

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 或类似语言查询。

知识图谱如何构建

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

典型流程如下：

1
2
3
4
5
6
7
8
9

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

数据源

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

第一类是结构化数据。

例如：

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

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

第二类是半结构化数据。

例如：

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

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

第三类是非结构化数据。

例如：

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

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

实体识别

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

例如：

1

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

可以识别出：

1
2
3
4

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

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

关系抽取

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

还是这句话：

1

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

可以抽取出：

1
2
3

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

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

属性抽取

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

例如公司实体：

1
2
3
4

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

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

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

1
2

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

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

实体对齐

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

例如：

1
2
3
4

北京大学
北大
Peking University
PKU

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

再比如：

1
2
3
4

苹果
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

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

知识图谱的典型应用

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

搜索增强

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

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

例如用户搜索：

1

苹果创始人

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

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

1
2

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

搜索结果因此更精准。

推荐系统

推荐系统不仅可以根据相似用户推荐，也可以根据图谱路径推荐。

例如电影推荐：

1
2
3

用户 -> 喜欢 -> 无间道
无间道 -> 主演 -> 刘德华
刘德华 -> 参演 -> 拆弹专家

系统可以解释推荐理由：

1

因为你喜欢《无间道》，而刘德华也参演了《拆弹专家》。

知识图谱推荐的优势是可解释性更强。

智能问答

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

例如：

1

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

图谱查询路径是：

1

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

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

风控反欺诈

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

例如：

1
2
3
4
5

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

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

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

医疗和金融知识管理

医疗图谱可以表示：

1
2
3
4

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

金融图谱可以表示：

1
2
3
4

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

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

知识图谱与大语言模型

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

LLM 存在几个问题：

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

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

知识图谱的优势是：

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

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

1
2
3
4
5
6

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

例如用户问：

1

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

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

1

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

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

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

知识图谱增强 RAG

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

流程大致是：

1
2
3
4

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

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

例如：

1
2
3

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

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

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

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

它们的共同思路是：

1
2
3

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

知识图谱与 Agent

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

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

作为知识库

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

例如：

1
2
3

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

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

作为记忆系统

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

例如：

1
2
3
4

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

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

作为规划辅助

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

例如软件系统图谱：

1
2
3
4

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

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

构建知识图谱的挑战

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

数据质量

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

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

抽取准确率

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

例如：

1
2

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

两个“苹果”含义不同。

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

关系设计

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

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

例如：

1

人 -> 关联 -> 公司

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

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

知识更新

知识不是静态的。

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

知识图谱需要处理：

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

规模和性能

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

需要考虑：

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

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

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

实体包括：

1
2
3
4
5
6

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

关系包括：

1
2
3
4
5
6

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

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

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

查询路径：

1

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

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

查询路径：

1

刘德华 -> 出演 -> 电影 <- 出演 <- 梁朝伟

问题三：喜欢《无间道》的用户可能喜欢什么电影

可以沿着多个路径推荐：

1
2
3

无间道 -> 主演 -> 刘德华 -> 出演 -> 其他电影
无间道 -> 导演 -> 刘伟强 -> 导演 -> 其他电影
无间道 -> 类型 -> 警匪片 <- 属于 <- 其他电影

这类推荐不仅能给结果，还能给解释。

总结

知识图谱的核心，是把知识组织成实体、关系和属性构成的网络。

它擅长表达：

• 复杂关系
• 多跳路径
• 事实约束
• 可解释推理
• 结构化知识

在传统系统中，知识图谱常用于搜索、推荐、问答、风控、医疗、金融和企业知识管理。

在大模型时代，知识图谱又有了新的价值：它可以为 LLM 提供可靠事实，为 RAG 提供结构化检索，为 Agent 提供长期记忆和规划依据。

未来很多智能系统可能都会走向这样的组合：

1

LLM + RAG + Knowledge Graph + Agent

LLM 负责语言理解和生成，RAG 负责外部知识召回，知识图谱负责关系结构和事实约束，Agent 负责任务执行和工具编排。

如果说普通文本知识像一本本分散的书，那么知识图谱就是把书中的人物、事件、地点、概念和因果关系连接起来，让机器不只“读到知识”，还能“理解关系”。