GraphRAG为什么火了？当向量检索遇到知识图谱，大模型开始理解“关系”

[当时我就笑出声了]

一、普通RAG解决不了什么问题？

传统RAG非常擅长回答：

“某个具体信息在哪里？”

例如：

“项目A负责人是谁？”

只需要找到包含“项目A”和负责人信息的Chunk即可。

但如果问题变成：

“公司当前哪些项目同时依赖项目A的核心模块，它们又分别受到哪些供应商影响？”

答案可能分散在几十份文件里。

这时候，只找到几个“相似文本块”可能远远不够。

因为真正重要的是：

信息之间的关系。

---

二、GraphRAG的基本思路

GraphRAG可以理解为：

Knowledge Graph + RAG

系统先从文档中识别：

• Entity
• Relationship
• Claim
• Community

例如从文本：

“张三负责智能CAD项目，该项目使用NX平台，同时与供应商A合作。”

提取：

张三
 ↓负责
智能CAD项目
 ↓使用
NX
 ↓合作
供应商A

用图表示：

graph LR
A[张三] -->|负责| B[智能CAD项目]
B -->|使用| C[NX]
B -->|合作| D[供应商A]

---

三、GraphRAG的索引过程

一个典型GraphRAG流程可以表示为：

flowchart TD

A[原始文档]
--> B[文本切块]

B --> C[实体抽取]
B --> D[关系抽取]

C --> E[知识图谱]
D --> E

E --> F[Community Detection]

F --> G[社区摘要]

G --> H[多层级知识索引]

与传统RAG最大的区别是：

传统RAG主要保存：

文本 → Vector

GraphRAG还构建：

实体 → 关系 → 社区 → 摘要

---

四、什么是Community？

如果知识图谱有几十万个节点，让模型直接阅读显然不现实。

因此可以把关系紧密的节点划分为不同社区。

例如：

社区1：CAD研发团队
社区2：供应链体系
社区3：客户项目
社区4：财务体系

然后为每个社区生成摘要。

这样模型面对一个宏观问题：

“公司智能制造业务目前面临哪些主要风险？”

就不必只检索几个Chunk。

系统可以读取多个社区摘要进行综合判断。

---

五、Local Search与Global Search

GraphRAG中的两种查询思路很好理解。

Local Search

适合：

“张三参与哪些项目？”

以某个实体为中心向周围扩展。

张三
├──项目A
├──项目B
└──部门C

Global Search

适合：

“整个公司研发体系主要有哪些技术方向？”

这类问题不是寻找某一句话，而是总结整个知识库中的主题。

---

六、GraphRAG并不是传统RAG的替代品

GraphRAG的优势明显，但成本同样更高。

传统RAG：

切块
↓
Embedding
↓
Vector DB

GraphRAG：

切块
↓
LLM抽取实体
↓
LLM抽取关系
↓
实体合并
↓
图构建
↓
社区发现
↓
社区总结
↓
Embedding

因此索引成本、计算量和系统复杂度都会提高。

---

七、什么项目适合GraphRAG？

我认为比较适合以下几类场景：

科研文献分析

作者
论文
方法
实验
机构
引用

之间天然存在复杂关系。

企业知识管理

员工
项目
客户
产品
供应商
合同

本身就是关系网络。

工业知识库

例如：

零件
→属于装配体
→对应工艺
→使用设备
→发生故障
→对应维修方案

仅仅依赖文本相似度，很难表达这种结构。

---

总结

传统RAG解决的是：

“哪段文字与问题相关？”

GraphRAG进一步尝试解决：

“知识之间究竟有什么关系？”

因此GraphRAG真正有价值的地方并不是“增加了一张图”，而是把知识表示方式从：

孤立文本块

升级为了：

实体 + 关系 + 社区 + 文本

对于复杂科研、企业知识库和工业智能场景，这类结构化知识协同方式值得长期关注。

[2401_86814003]

赞