Graph RAG

flowchart LR
  A["Graph RAG"]
  A --> B["分类：检索增强 (RAG)"]
  A --> C["关键词：RAG"]
  A --> D["关键词：Graph RAG"]
  A --> E["关键词：Knowledge Graph"]
  A --> F["关键词：Neo4j"]

前一篇讲到 Agentic RAG，本质是在讨论：当问题不再适合一条固定检索流水线时，系统该如何动态决定“查什么、查几次、去哪里查”。

但还有一类问题，即使你把检索流程做得再聪明，纯向量检索仍然会遇到明显瓶颈：

它能找到“相关文本”，却不天然擅长表示“实体之间的关系”。

比如问：

张三的上级所在部门的预算是多少？

一个纯向量 RAG 系统可能可以召回这些片段：

张三的个人介绍
李四的管理职责
研发部预算说明
部门组织结构文档

这些内容都“相关”，但问题在于：相关不等于可连接。系统需要的不只是若干相似文本，而是一条明确的关系链：

张三 → 上级 → 所在部门 → 预算

这正是 Graph RAG 要补的位置。

所以，Graph RAG 不是在和向量 RAG 竞争谁更先进，而是在解决一个纯向量范式不擅长处理的问题：

当知识的关键不只是“内容像不像”，而是“谁和谁怎么连着”时，需要把关系结构显式建出来。

为什么纯向量 RAG 在这类问题上会吃力

向量检索擅长的是语义相似性。一句话被编码成向量后，系统更容易回答的是：

哪些文本和这个问题表达得像
哪些片段可能谈的是同一个主题
哪些内容在语义空间里彼此接近

这类能力非常强，也正因为如此，Vector RAG 在大量知识问答场景里已经足够有效。但它有一个天然边界：向量空间主要表达“相似”，不是“关系”。

这会带来几类典型问题。

问题	纯向量 RAG 的表现
关系缺失	返回的是相关片段，不是明确关系路径
多跳推理困难	需要把多个检索结果拼成链条，容易断裂
结构化知识弱	层级、依赖、组织关系、引用关系容易被扁平化
结果可解释性不足	系统可能答对，但很难说明“是沿哪条路径推出来的”

可以把它总结成先看定义：

向量检索擅长回答“像什么”，图结构更擅长表达“是什么、和谁有关、怎么连起来”。

这两种能力不是互斥的，而是互补的。

什么是知识图谱

知识图谱可以先用一个非常朴素的方式理解：

知识图谱 = 实体（Entity） + 关系（Relationship） + 属性（Property）

比如在企业场景里：

“张三”是一个实体
“研发部”是一个实体
“任职于”是一种关系
“预算”可能是部门这个实体的一个属性

于是，原本散落在文本里的知识，就可以被建模成节点和边：

(张三) --[任职于]--> (研发部)
(研发部) --[隶属于]--> (技术中心)
(张三) --[汇报给]--> (李四)
(李四) --[管理]--> (研发部)

这个表示方式看起来简单，但意义很大。因为一旦知识变成图，检索就不再只是“找相似文本”，还可以是：

从一个实体出发做图遍历
沿着某类关系走一跳、两跳、三跳
找到某条明确路径上的目标节点
对路径进行解释和验证

所以，图谱的价值不只是“结构化存储”，更在于：

它把原本隐含在文本里的关系显式化了。

这也是 Graph RAG 和普通 RAG 最根本的差异。

Graph RAG 的核心思路

如果用一句话概括：

Graph RAG 是把知识图谱的“结构能力”和向量检索的“语义能力”结合起来。

它通常不是完全抛弃向量检索，而是在知识表示层多加了一层图结构。这样系统处理问题时，就不再只能靠相似度召回，还能利用实体关系来缩小搜索空间、补全推理链条。

一个典型的 Graph RAG 系统里，通常有三类核心组件：

组件	作用
知识图谱	存储实体、关系、属性，支持路径和子图查询
向量索引	对文本块、节点描述、子图摘要做语义检索
LLM	负责理解问题、生成查询、组织答案、处理歧义

真正的关键不在于“有没有图数据库”，而在于系统能不能同时利用两种能力：

图提供结构

图更擅长表达：

谁属于谁
谁管理谁
哪个项目依赖哪个项目
哪条法条引用了哪条法条
哪个产品和哪些模块、团队、事故有关

这些信息如果只放在文本里，模型也许可以“读懂”，但系统很难稳定地“查对”。

向量提供语义

图并不天然解决一切。如果用户问题表述模糊、实体没完全对齐、描述是近义表达，仍然需要语义能力帮你找到可能的入口实体、相关节点说明或局部文本证据。

因此，Graph RAG 的真正价值，通常不是“用图替代向量”，而是：

让图负责关系约束，让向量负责语义召回。

图谱到底补了向量的什么短板

Graph RAG 之所以值得单独拿出来讲，是因为它不是简单“多接一个数据库”，而是补了纯向量 RAG 很难系统解决的几个问题。

1. 多跳关系推理

像下面这类问题，天然适合图：

A 的上级是谁
A 的上级属于哪个部门
这个部门的预算是多少
预算负责人又是谁

这里每一步都有明确关系类型。向量检索可以分别找到“相关文本”，但很难天然保证这些结果恰好组成同一条逻辑链。图谱则可以把这条链当作显式路径查询出来。

2. 层级和依赖结构

很多企业和业务知识不是“散文式知识”，而是天然带层次的：

组织架构
产品模块依赖
项目归属关系
审批流程
法条引用链
医疗概念体系

这类知识如果只被切成 chunk，再丢进向量库，结构会被显著扁平化。你仍然能搜到相关内容，但“上层、下层、依赖、从属、因果、引用”这些关系不再清晰。

3. 实体对齐与可解释性

Graph RAG 的一个常被低估的优点是：它天然更容易给出“为什么是这个答案”。

例如系统不只是说“张三所在部门预算是 2000 万”，而是可以明确展示路径：

张三 → 汇报给李四 → 李四管理研发部 → 研发部预算为 2000 万

这个路径并不只是为了美观，它在工程上很有意义：

更容易审计
更容易发现错链
更容易调试抽取错误
更适合高可信问答场景

也正因为如此，Graph RAG 往往在企业知识、金融风控、法律、医疗等更强调关系可追溯的场景里更有价值。

Graph RAG 不是“只有图”，而是图与文本一起工作

很多人第一次接触 Graph RAG 时，会误以为它的意思是：

先把知识全部转成图，然后只靠图来回答问题。

这通常不现实，也没必要。

原因很简单：现实世界里的知识很少能被完整、准确、低成本地全部结构化。很多信息依然存在于自然语言文本里，而且文本本身保留了大量上下文细节。图谱更像是一种高价值关系的抽象层，而不是对全文本的彻底替代。

因此，成熟的 Graph RAG 更常见的形态是：

从文档里抽取关键实体与关系，建成图
保留原始文本或文本切块作为证据层
检索时先借助图缩小范围、锁定路径或定位子图
再把子图相关文本一起交给模型生成答案

换句话说：

图负责“找关系骨架”，文本负责“补语义细节与原始证据”。

这也是为什么 Graph RAG 往往会自然走向 Hybrid 方案，而不是纯图方案。

Microsoft GraphRAG 在做什么

Graph RAG 这个词最近几年更常被广泛提起，很大程度上是因为 Microsoft 推出的 GraphRAG 方案让这条路线被更多人系统看到。

但理解它时，一个常见误区是：把它等同于“任何图数据库 + LLM”。实际上，Microsoft GraphRAG 更像是一套围绕从文本构图、社区聚合、局部检索与全局概括展开的方法框架。

它的思路里，有两个很值得关注的点。

Community Detection：不是只查节点，还要形成“主题社区”

如果图足够大，单看局部节点关系仍然不够。你还需要一种方式，把图里高度相关的节点聚成更大的主题单元。

这就是所谓的社区检测（Community Detection）。

直观理解，它是在说：

哪些实体和关系经常共同出现
哪些节点形成了相对稳定的主题簇
这个簇能不能代表一个更高层的问题域

例如在企业知识中，一个社区可能围绕某个产品线形成：

产品
团队
项目
风险事件
核心客户
相关文档

当这些节点形成社区后，你就不只是有零散关系，还能进一步对这个社区做摘要，把局部结构升维为“主题级知识”。

Global Search vs Local Search：局部事实和全局概括不是一回事

这是 GraphRAG 很有启发性的一点：它区分了两类不同的问题。

模式	描述	更适合回答的问题
Local Search	围绕具体实体或局部子图做检索	谁、什么、何时、某条关系链是什么
Global Search	在社区摘要或高层聚合知识上检索	整体风险、主要主题、宏观概括、全局趋势

这个区分很重要，因为传统 RAG 经常把所有问题都当成“找几段相关文本”来处理。但现实里，问题其实分成两大类：

一类是局部事实问题

例如：

张三现在属于哪个团队
产品 A 依赖哪些服务
某条法规引用了哪几条上位法

这类问题更适合在局部子图里精准查询。

另一类是全局概括问题

例如：

公司当前主要的风险集中在哪些领域
某个业务线的核心议题有哪些
过去一年哪些主题最频繁出现

这类问题即使有图，也很难只靠某条路径回答。它更像是在问“整个知识图谱中，哪些聚类或主题最重要”。这就需要社区级摘要和更高层的聚合表示。

所以，GraphRAG 带来的一个重要启发不是某个具体实现细节，而是：

图结构不只适合查事实路径，也适合组织更高层的主题视角。

Graph RAG 的典型构建流程

无论你是不是采用某个具体框架，Graph RAG 大致都会经历几个阶段。

1. 从文档中抽取实体

先识别出文档里的关键对象，例如：

人
部门
公司
项目
产品
法条
症状
药物

这里的难点不是“抽不抽得出来”，而是：

抽得是否稳定
同一实体是否能对齐
粒度是否合适
是否保留足够上下文

比如“研发部”“研发中心”“技术研发部”到底是不是同一个实体，这类归一化问题在真实工程中非常常见。

2. 抽取实体之间的关系

关系抽取比实体抽取更关键，也更容易出问题。因为 Graph RAG 真正依赖的是“可走的边”。

例如：

任职于
汇报给
管理
属于
依赖
引用
负责
影响
包含

同一句话里可能有多个关系，也可能有隐含关系。而一旦关系抽错，后面的图查询和路径推理都会被污染。

3. 建图并存储

把实体和关系以图的形式持久化存储。常见选择包括：

方案	特点
Neo4j	工程化成熟，查询语言直观，适合生产系统
Amazon Neptune 等图服务	托管能力更强，适合云环境
NetworkX	轻量，适合原型验证和离线分析

这里要注意，图存储不是目的，查询能力才是重点。如果建了图，却没有稳定的查询和更新策略，图很容易变成一个昂贵但难用的旁路系统。

4. 做摘要、聚合或子图表示

如果图规模较大，仅靠单节点和原始边查询很难支撑更高层问题。这时通常需要对局部子图、社区或主题簇做摘要和表示。

这一步并不是 GraphRAG 独有，但在图规模上去后会非常关键。否则系统只能回答“小问题”，很难回答“整体怎么看”。

5. 检索与回答

真正上线时，Graph RAG 往往不是“只查图”，而是组合式流程：

先识别问题里的核心实体
决定查局部路径还是做全局主题检索
查到相关子图
把子图及相关文本证据转成 LLM 可消费的上下文
最后由模型合成答案

可以看到，Graph RAG 的重点从来不只是“有没有图”，而是：

你能否让图成为检索与回答过程中的有效约束。

从文档构建知识图谱：听上去简单，实际很考验细节

很多介绍会把这件事写成先看定义：

让 LLM 抽取 (头实体, 关系, 尾实体) 三元组。

这确实是起点，但如果要走向工程可用，至少要面对下面这些问题。

实体边界怎么定

“张三负责增长平台”里，“增长平台”是项目、产品线、系统名，还是团队名？不同文档里说法可能不一致，如果没有 schema 约束，抽出来的图会非常乱。

实体归一化怎么做

“OpenAI”“OpenAI 公司”“OpenAI, Inc.”到底是不是一个实体？ “李总”和“李四”是不是同一人？如果归一化做不好，图会被拆碎，关系链也会断裂。

关系类型怎么收敛

如果完全让模型自由生成关系标签，你很快会得到一堆近义但不统一的边：

管理
负责
领导
主管
oversee
lead

这些边语义相近，但如果不收敛，后续查询会变得非常脆弱。所以，工程上通常需要一个受控的 relation schema，而不是无限开放式关系集。

关系可信度如何处理

不是所有抽取出来的边都同样可信。有些关系来自明确陈述，有些来自模糊表述，有些甚至只是模型推断。如果这些边被一视同仁地写进生产图谱，后果会很糟。

一个更现实的做法是为边保存额外信息：

来源文档
抽取置信度
时间戳
是否已人工校验
原始证据片段

这会让图谱不只是“一个关系集合”，而是“一个可追溯的关系层”。

Neo4j + LLM：为什么这是很多团队的第一站

Neo4j 常被拿来做 Graph RAG 的起点，不只是因为它流行，更因为它有一个很实际的优点：

图查询这件事，在 Neo4j 里足够直观。

比如查询“张三的上级管理的部门预算”这类问题，可以很自然地表达成路径：

MATCH (p:Person {name: "张三"})-[:REPORTS_TO]->(m:Person)-[:MANAGES]->(d:Department)
RETURN d.name, d.budget

这类查询方式对 Graph RAG 很重要，因为它让“关系链”成为一等公民，而不是藏在文本里等模型自己理解。

典型的集成方式大致有三类。

1. LLM 生成 Cypher

用户自然语言问题先被模型转成 Cypher，再去图数据库里查。这是最直观的玩法，但也最容易踩坑。

问题在于，LLM 生成结构化查询时会遇到：

schema 理解错误
关系方向写反
节点类型用错
过滤条件漏掉
把不存在的字段或关系编出来

所以，LLM 直接生成 Cypher 更适合：

schema 较稳定
查询模板有限
有校验层或 query guardrail
容错成本较低

而不适合把数据库完全暴露给模型自由发挥。

2. 图查询结果转文本，再交给 LLM 回答

这是更稳的一种方式。系统先查子图，再把节点、关系和属性转成一种可读文本，让模型负责组织答案。

例如把结果转成：

张三汇报给李四
李四管理研发部
研发部预算为 2000 万

这种方式的好处是：

LLM 不需要直接操作复杂数据库
可以在进入生成前做安全过滤
可以把路径和证据一起交给模型

3. 图与向量联合检索

这是很多实际系统最终会走到的状态。因为只查图不够灵活，只查向量又容易丢关系，所以常见做法是：

先通过语义检索找到候选实体或相关文档
再基于图做局部扩展
或者先通过图锁定子图，再对子图相关文本做向量检索和重排

这意味着，Neo4j + LLM 真正有价值的地方，不在于“能生成 Cypher”，而在于：

它让图结构成为检索流程的一部分，而不是一个孤立的存储层。

Graph RAG、Vector RAG 和 Hybrid 的差异

如果用最简化的方式对比，可以先看下面这张表。

维度	Vector RAG	Graph RAG	Hybrid
语义匹配	强	通常需额外补足	强
关系推理	弱	强	强
多跳路径	不稳定	更自然	更稳
构建成本	低	高	较高
可解释性	中等	高	高
上线复杂度	低	中高	高
适用问题	语义问答、事实问答	多跳、关系链、结构化问题	综合型复杂场景

但表格只能说明表面差异，更重要的是理解三者适合的问题类型。

Vector RAG 适合“找相关内容”

如果问题的核心是：

找一段解释
找一个定义
找若干相关事实
找与问题表述语义接近的文本

那 Vector RAG 往往已经很好用。

Graph RAG 适合“找关系和路径”

如果问题本质上是在问：

A 和 B 如何相连
A 的上级 / 下级 / 依赖 / 归属 / 引用对象是什么
某实体沿几跳关系后会到哪里
某个局部网络里有哪些关键节点

那么 Graph RAG 更合适。

Hybrid 更适合现实系统

因为真实问题很少纯粹属于某一类。用户既可能需要路径，也可能需要路径背后的文本语境、解释、时间条件和证据片段。

所以大多数长期可用的系统，最终不会在 Vector 和 Graph 之间二选一，而会走向：

让图负责约束，让向量负责补充。

哪些场景最适合 Graph RAG

并不是只要“看起来高级”就该建图。 Graph RAG 只有在知识和问题都呈现出明显关系结构时，投入才更有意义。

1. 企业知识管理

企业知识天然有大量实体关系：

人员与组织
项目与团队
系统与服务
流程与审批角色
文档之间的引用和依赖

这类场景非常容易出现“A 的 B 的 C”式问题，Graph RAG 往往比纯向量更稳。

2. 金融风控

股权关系、担保链、关联交易、资金流、控制链，这些问题天然是图问题。很多风险并不藏在某一篇文档里，而藏在“多实体之间的连接模式”里。

3. 医疗与生命科学

疾病、症状、检查、药物、禁忌、通路之间都有丰富关系。 Graph RAG 在这里的潜力很大，但同时也因为领域精度要求高，更依赖高质量 schema 和知识源。

4. 法律与合规

法条引用、案例关联、上位法与下位法关系、条款适用条件，这些都很适合显式关系建模。相较于只搜相似段落，图结构更有助于追踪“依据链”。

5. 多跳问答

凡是问题结构天然长成：

A 的 B 是谁
A 相关的 C 中有哪些满足 D
谁负责过与某事故相关的项目
哪些部门和某项风险存在间接关系

这类问题都更值得考虑图路径。

什么时候不建议上 Graph RAG

Graph RAG 的一个常见问题是：因为它听起来更“高级”，所以容易被过度引入。

但很多问题其实并不需要图。

例如：

FAQ 式问答
单篇文档问答
简单事实检索
大量无明确实体关系的说明文档
主要靠概念相似而不是关系路径的问题

对于这些场景，建图带来的收益往往不够覆盖成本。你需要维护额外的数据层、抽取流程、更新机制和查询逻辑，最后效果却未必明显优于一个做得不错的向量 RAG。

更直接地说：

如果问题主要是在找“哪段内容最相关”，而不是在找“哪条关系链成立”，Graph RAG 往往不是最优先选项。

构建成本不只在“建图”，更在“把图维持为真”

Graph RAG 真正昂贵的地方，不只是第一次建图，而是后续维护。很多 PoC 都能把图建出来，但上线之后才发现难点集中在“图怎么持续可信”。

下面这些成本通常都不能忽略。

成本项	真正的难点
实体 / 关系抽取	不只是抽得出，而是抽得稳、抽得准
图存储与查询	不只是部署数据库，而是形成可用的查询层
增量更新	文档变更后，图如何局部更新而不污染既有关系
实体归一化	同名异物、异名同物、版本漂移都会破坏图质量
社区摘要 / 子图表示	图大了以后，如何做高层组织与全局检索
评估体系	如何验证图路径和答案是否真的提升了质量

这里最容易被低估的是增量更新。

向量库更新通常只要重切 chunk、重建 embedding；但图更新不是简单覆盖。因为修改一篇文档，可能影响：

某个实体属性
某条关系是否还成立
某条边的时间状态
某个社区摘要是否过期
某个子图的中心节点是否发生变化

所以，Graph RAG 的维护难度天然高于向量 RAG。这也是为什么它更适合那些知识关系价值足够高、问题复杂度足够高、ROI 足够明确的场景。

Graph RAG 最大的工程难点，往往不是检索，而是 schema

很多团队做到后面会发现，决定系统质量上限的不是某个模型，而是 schema 设计。

建图前，你至少要回答这些问题：

你有哪些核心实体类型？
这些实体有哪些关键属性？
你允许哪些关系类型？
哪些关系是方向性的？
哪些关系有时效性？
哪些属性应该做节点属性，哪些应该保留在原始文本里？

例如一个企业知识库，可能有这样的 schema：

实体类型	属性示例	常见关系
Person	name, title, department, start_date	REPORTS_TO, WORKS_IN, LEADS
Department	name, budget, parent_department	BELONGS_TO, OWNS
Project	name, status, owner, start_date	LED_BY, INVOLVES, DEPENDS_ON
System	name, service_tier, owner_team	RUNS_ON, DEPENDS_ON, MAINTAINED_BY
Document	title, source, updated_at	REFERENCES, DESCRIBES

schema 设计直接影响三个层面：

抽取是否稳定

如果 schema 太宽泛，抽取就会混乱；如果 schema 太细，抽取和维护成本会飙升。

查询是否自然

如果关系类型设计得不合理，后续查询会变得别扭，甚至需要依赖大量 prompt 修补。

演化是否可持续

一开始把 schema 设计得过于“全能”，很可能在几周后失控。实际更可行的做法通常是：

从最关键的实体和关系开始，只建那些能明显改善回答质量的边。

Graph RAG 里，最危险的不是 schema 太小，而是 schema 看起来很全，实际上没人能持续维护。

一个更务实的落地方式：渐进式引入，而不是全量替换

如果你已经有 Vector RAG，不需要把系统推倒重来。 Graph RAG 更合理的引入方式，通常是渐进式的。

1. 先做并行验证

在现有 pipeline 旁边，加一条图检索路径。不要一开始就替换主流程，而是先看同一批问题上，图路径是否真的提升了结果质量。

最值得优先测试的问题是：

关系类问题
多跳类问题
组织架构 / 依赖链 / 引用链问题

2. 做混合检索

比较实用的做法是：

图遍历拿到相关实体和子图
向量检索拿到相关文本块
把两边结果交给统一的重排或答案合成层

这样可以兼顾路径和语义，不至于在某一侧过拟合。

3. 做问题路由

不是所有问题都要走图。你可以让系统识别：

关系型问题 → 走图优先
语义型问题 → 走向量优先
混合型问题 → 走 Hybrid

这一步很重要，因为 Graph RAG 的价值通常集中在一部分问题上，而不是平均提升所有问题。

4. 再决定是否把图变成主路径

只有当你确认：

这类问题占比足够高
图带来的收益足够明显
更新与维护成本可接受

再考虑把图能力前置为主要路径。否则，它更适合作为高价值复杂问题的增强通道。

所以，Graph RAG 最现实的迁移路径不是“all in”，而是：

先证明关系结构值得被显式建模，再逐步放大投入。

常见误区与失败模式

Graph RAG 看起来很适合解决复杂问题，但它也有很多典型坑，而且不少坑比向量 RAG 更隐蔽。

1. 图建得很大，但没有回答质量提升

这通常发生在“为建图而建图”的项目里。抽了很多实体和关系，图数据库也搭好了，但用户问题本身并不真的依赖这些关系。最后系统复杂度大涨，收益却不明显。

2. 抽取质量一般，导致错误路径非常自信

图的危险在于：一旦某条边是错的，路径推理会看起来特别“像那么回事”。

相比向量检索的模糊相关性，图路径更容易给人一种强确定感。但如果边本身不可靠，这种确定感反而更危险。

3. schema 过度设计

一开始就试图覆盖所有实体和关系，结果 schema 太复杂，抽取不稳定，查询也变脆。最终工程团队在维护 schema，而不是在提升问答质量。

4. 只关心图，不保留原始证据

如果图里只有抽象关系，没有回指原文证据，系统就很难处理细节、时间条件和歧义。这会让回答“有结构，但没语境”。

5. 把 Graph RAG 当作替代基础检索质量的捷径

如果文档质量差、元数据乱、实体识别不稳定，那么建图不会神奇地修复这些问题。它通常只会把原本分散的问题集中暴露出来。

一个很重要的实践原则：图只建高价值关系

Graph RAG 的关键不是“图越全越好”，而是“哪些关系值得进入图”。

真正有价值的边，通常具备几个特点：

高频出现在用户问题里
对答案路径有决定性作用
能明显减少检索歧义
在原文本里不容易被稳定拼接
具有较强业务语义

例如企业场景中的这些关系通常就很有价值：

汇报关系
部门归属
项目负责人
系统依赖
文档引用
事故影响范围

而一些过于细碎、描述性、低复用的关系，未必值得进图。因为每多一种边，你就多一份抽取、校验、更新和查询成本。

所以，更实用的做法往往不是“尽量全量结构化”，而是：

只把那些真正能改善检索与推理质量的关系抽出来。

小结

Graph RAG 的意义，不在于给 RAG 加一个“更酷的数据库”，而在于补足纯向量范式在关系表达上的天然不足。

当问题依赖的是：

实体之间的连接
明确的多跳路径
层级和依赖结构
可追溯的关系链

那么 Graph RAG 往往比单纯的向量召回更稳、更可解释，也更接近问题本身的结构。

但它同样不是默认答案。

它的代价包括：

更高的构建成本
更复杂的 schema 设计
更难的增量更新
更高的抽取质量要求
更重的评估与维护负担

因此，更克制的结论应该是：

Graph RAG 不是用来替代 Vector RAG 的，而是当知识天然长成“图”、问题天然需要“走关系链”时，对 RAG 的一次必要补足。

如果前几篇更多是在讨论“如何把文本检索做准”，这一篇则是在讨论：

当知识的关键不再只是文本片段，而是片段背后的实体关系时，RAG 应该如何升级。

这也正好引向下一篇：当模型上下文窗口越来越大时，RAG 还是不是必要？长上下文和 RAG，到底是替代关系，还是协作关系？

核心概念速查

概念	一句话说明
Knowledge Graph	用实体、关系、属性把知识表示成节点和边
Graph RAG	将图遍历与文本/向量检索结合，用结构补足语义检索
多跳推理	沿着多段实体关系逐步到达答案，而不是一次召回即得
Local Search	围绕具体实体和局部子图做精确检索，适合事实问题
Global Search	在社区摘要或高层主题表示上做检索，适合概括性问题
Community Detection	把高度相关的节点聚成主题社区，用于全局理解与摘要
Hybrid RAG	让图负责关系约束，让向量负责语义召回与文本证据
最大难点	不是“建图”，而是 schema、实体归一化、增量更新与关系可信度
实践原则	只为高价值关系建图，先小规模验证收益，再渐进式引入