GraphRAG vs LightRAG：图增强 RAG 的两种工程路线深度对比

传统向量 RAG 在「全局性问题」（如「这批文档主要讲什么主题」「不同实体之间有什么关系」）上表现疲软——它只检索语义相似的文本片段，无法回答跨文档、跨实体、需要聚合信息的查询。2024 年起，「图增强 RAG」（GraphRAG）成为补足这块短板的主流路线。

本文聚焦两个最有代表性的开源实现：Microsoft GraphRAG（微软研究院 2024 年开源）和 HKUDS LightRAG（港大学 2024 年底开源），从索引机制、检索范式、成本结构、查询质量、运维复杂度五个维度做深度对比。

一、为什么需要图增强 RAG

在对比之前，先理解问题。向量 RAG 的 pipeline 是：文档 → 切块 → embedding → 向量库 → 检索相似块 → LLM 生成。这个范式擅长回答「具体事实型」问题（如「某函数的入参是什么」），但在三类查询上失灵：

1. 全局性问题：「这 1000 篇财报主要讲哪些行业风险？」需要聚合所有文档才能回答。
2. 多跳关系：「A 公司的 CEO 和 B 公司的 CFO 有什么关系？」需要追踪实体之间的关联链。
3. 跨文档关联：「文档 1 提到的产品 X 在文档 2 里有什么更新？」需要跨文档的语义连接。

图增强 RAG 的核心思想是：在向量检索之外，再构建一张「实体—关系」图谱，让 LLM 能在图上做多跳推理、聚合查询、社区发现。三种主流实现路线：

• 路线 A：构建完整知识图谱（KG-RAG），用 SPARQL / Cypher 查询。代表：Neo4j LLM Graph Builder、TrustGraph。
• 路线 B：在向量库基础上叠加一层「轻量级图结构」，把图当作「上下文增强器」。代表：LightRAG、Graphiti。
• 路线 C：用 LLM 自动抽取社区 + 生成层级摘要，把「摘要本身」当作检索单元。代表：Microsoft GraphRAG。

GraphRAG 和 LightRAG 分别是路线 C 和路线 B 的代表，两者的工程取舍差异巨大。

二、索引机制：构建图的两种哲学

Microsoft GraphRAG：离线分层摘要 + 社区检测

GraphRAG 的索引 pipeline 是目前最「重」的：

1. 文档切块：按 token 切分（默认 300 tokens）。
2. 实体关系抽取：用 LLM（默认 GPT-4o）从每个 chunk 中抽取实体（entity）和关系（relationship），输出结构化三元组。
3. 图构建：把实体当作节点、关系当作边，构建同质图（homogeneous graph）。
4. 社区检测：用 Leiden 算法检测图中的社区结构（类似社交网络分析）。
5. 层级摘要：对每个社区生成多层级（默认 3 层）的自然语言摘要，存储为「社区报告」。
6. embedding 化：把每个社区摘要也做 embedding，存入向量库。

最终产出：实体表 + 关系表 + 社区摘要树 + 向量索引。索引一次的成本极高——1 万 tokens 的文档大约消耗 5-15 倍 token 的 LLM 调用（实体抽取 + 摘要生成），索引时间从十几分钟到几小时不等。

LightRAG：双层图 + 增量更新

LightRAG 的设计哲学是「轻量」——只在向量库之上叠加一个最小化的图结构：

1. 文档切块：按 token 切分（默认 600 tokens）。
2. 实体关系抽取：用 LLM 从 chunk 中抽取实体和关系（这一步和 GraphRAG 类似）。
3. 去重合并：跨 chunk 抽取的同名实体自动合并，关系累加权重。
4. 双层图构建：
   • 实体层：节点是实体，边是关系
   • 关系层：节点是关系，边是「关系之间的关联」（如「同一作者」「同一时间」）
5. embedding 化：实体名、关系名、chunk 文本都做 embedding，存入向量库。
6. 增量更新：新文档到来时，只对新增 chunk 做抽取和增量图合并，无需重建。

最终产出：实体-关系双层图 + 向量索引。索引一次的成本比 GraphRAG 低 50%-70%，增量更新成本极低（只处理新增文档）。

关键差异表

维度	GraphRAG	LightRAG
图结构	单层实体图 + 社区树	双层图（实体层 + 关系层）
索引产物	实体/关系/社区摘要/向量	实体/关系/向量
索引成本（1M tokens）	$30-100 + 30-120 分钟	$10-30 + 10-30 分钟
增量更新	需重建（无原生支持）	原生支持
检索单元	社区摘要 + chunk	实体/关系/ chunk
适合查询	全局性 / 主题性	多跳关系 / 实体型

三、检索范式：两种「图查询」的实现

GraphRAG：local search + global search

GraphRAG 提供两种检索模式：

• Local search（局部搜索）：从查询中抽取实体 → 在图中找邻居节点 → 把这些节点的邻居 chunk 一起喂给 LLM。适合回答「具体实体的细节」。
• Global search（全局搜索）：把查询映射到相关社区 → 把社区摘要分批喂给 LLM → LLM 聚合所有摘要生成答案。适合回答「全局性问题」。

Global search 是 GraphRAG 的杀手锏——它能回答向量 RAG 完全无法回答的「这批文档在讲什么主题」。但代价是：每次查询都要调用 LLM 数十次（分批摘要），延迟高、成本高。

LightRAG：向量召回 + 图遍历

LightRAG 的检索范式更接近「向量优先 + 图增强」：

1. 用查询的 embedding 召回 top-K 实体和关系
2. 在图上做 1-2 跳遍历，把相关联的实体、关系、chunk 一起拉出来
3. 拼接成上下文喂给 LLM

这种范式的优势是：单次查询只需 1 次 LLM 调用，延迟低、成本低。代价是：全局性问题能力较弱——它能做「多跳推理」但不能做「全图聚合」。

查询类型适配矩阵

查询类型	GraphRAG	LightRAG	纯向量 RAG
事实型（「X 是什么」）	✅	✅	✅
多跳关系（「A 和 B 的关系」）	⚠️	✅	❌
全局性（「这批讲什么」）	✅（杀手锏）	⚠️	❌
跨文档关联	⚠️	✅	❌
时间敏感	❌	✅	⚠️
实时更新	❌	✅	✅

四、成本与运维：生产部署的关键差异

GraphRAG 的成本陷阱

GraphRAG 在生产环境最容易踩的坑是索引成本失控：

• 案例：某金融公司 50 万份研报做 GraphRAG 索引，第一次跑下来花了 $18,000 LLM 成本和 8 小时。
• 优化手段：用更便宜的模型做实体抽取（GPT-4o-mini），用 GPT-4o 只做社区摘要；并行化处理；缓存抽取结果。

另一个常见问题是更新困难：GraphRAG 设计上是「一次性离线索引」，新增文档后要么全量重建（成本极高），要么自己实现增量逻辑（没有官方支持）。

LightRAG 的运维友好性

LightRAG 的工程化程度明显更高：

• 增量索引：内置 insert() API，新文档增量合并到图，开箱即用。
• 多存储后端：支持本地 JSON、PostgreSQL、Neo4j、MongoDB 等多种 KV/图存储。
• 检索参数可调：top-K、跳数、相似度阈值都能配置。
• 成本可控：默认用 GPT-4o-mini 就能跑出不错的效果。

五、查询质量：基准对比

综合多个公开 benchmark 和实践经验：

维度	GraphRAG	LightRAG
事实型问答	8/10	8/10
多跳推理	7/10	9/10
全局性问题	10/10	5/10
跨文档关联	6/10	8/10
时间敏感查询	4/10	8/10
答案可解释性	8/10（社区路径可追溯）	6/10
检索延迟（单次查询）	5-15s（Global mode）	0.5-2s

GraphRAG 在「需要全局视野」的场景优势明显，LightRAG 在「需要快速增量 + 多跳推理」的场景优势明显。

六、典型场景适配

• 企业内部知识库（万级文档）：LightRAG，增量更新 + 低运维成本 + 多跳关系查询为主。
• 法律/合规文档分析（百万级）：GraphRAG，需要全局性问题（"这批合同有哪些共同风险条款"）+ 一次性离线索引可接受。
• 科研文献库（增量增长）：LightRAG，新论文持续涌入，需要增量索引 + 跨论文实体关联。
• 金融研报分析（一次性深度分析）：GraphRAG，全局性问题（"这季度市场情绪如何"）+ 不在乎索引成本。
• 实时新闻问答：LightRAG，时间敏感 + 增量更新。
• 跨实体推理（社交网络、供应链）：LightRAG，多跳关系 + 图遍历能力强。

七、决策树

数据规模 < 1 万 chunks → LightRAG（成本低、维护简单）；1 万 - 100 万 → 取决于查询类型。查询以全局性 / 主题性为主 → GraphRAG；以多跳关系 / 实体型为主 → LightRAG。需要增量更新 → LightRAG（唯一选择）。运维预算有限 → LightRAG。可以接受一次性索引 + 高 LLM 成本 → GraphRAG。需要快速响应（<2s 延迟） → LightRAG。

八、常见陷阱

1. GraphRAG 是「更好」的 RAG：GraphRAG 和向量 RAG 是互补关系，不是替代关系。最佳实践是「向量召回 + 图增强」混合架构（LightRAG 本身就是这个思路）。
2. LightRAG 不擅长全局性问题：如果你有 30% 的查询是「总结这批文档」，不要只依赖 LightRAG。
3. GraphRAG 的社区摘要会过时：摘要一旦生成就不再更新，对时间敏感的数据要谨慎。
4. LightRAG 的图会无限膨胀：不做实体去重和合并的话，实体数量可能爆炸。需要配置 entity_merge 参数。
5. 两个框架都需要 LLM 抽取：LLM 抽取的实体质量决定了整个系统的上限。生产环境建议用 GPT-4o 或 Claude Sonnet 做抽取。

九、未来趋势

图增强 RAG 的下一步突破点在三个方向：

• 混合架构：向量召回 + 图遍历 + 知识图谱 SPARQL 三层混合（LightRAG 2.x 已经部分实现）。
• 自动图维护：用 LLM 自动检测图中的过时实体、矛盾关系、低置信边。
• 多模态图：把图片、表格、公式也作为节点加入图谱。

最后一句话：没有「更好的图 RAG」，只有「更适配你查询分布的图 RAG」。如果你的查询是「这批文档讲什么」 → GraphRAG；如果是「A 实体和 B 实体的关系」 → LightRAG。最佳实践是两者组合：用 LightRAG 做日常检索，用 GraphRAG 定期生成「全局洞察报告」。