GraphRAG 和 LightRAG 详解与对比

**摘要：**同样是「知识图谱 + RAG」，为什么有人选微软的 GraphRAG，有人却偏爱港大的 LightRAG？这篇文章带你拆解两大主流方案的完整链路：从索引、查询到增量更新，把「烧钱烧 token 的全局洞察」和「秒级响应的轻量部署」掰开揉碎讲清楚。看完你就能明白：什么时候该上 GraphRAG 啃硬骨头，什么时候该用 LightRAG 快速迭代，最后还有一套「稳定知识 + 动态数据 + 查询路由」的混合架构实战思路，帮你少走弯路。

文章特色：逻辑清晰，保证看懂！

GraphRAG（微软，2024)

GitHub - microsoft/graphrag: A modular graph-based Retrieval-Augmented Generation (RAG) system · GitHub

传统RAG有哪些痛点？

1. 跨文档的「多跳推理」干不了

2. 全局性问题，它根本答不上。切块带来的「语义断裂」，包含实体关系、因果关系等

GraphRAG诞生原因

构建知识图谱可以用 LLM + prompt 轻松实现。

索引阶段

第 1 步：文档切块

GraphRAG 里叫 Text Unit

第 2 步：实体与关系提取

每个文本块都会单独发给 LLM，让它从里面把实体（Entity）和关系（Relationship）抽出来。

prompt 示例：

你是一个实体关系抽取助手。请从下面的文本中：
1. 识别所有的实体，每个实体给出：
   - entity_name：实体名（大写）
   - entity_type：类型（比如 [人物, 组织, 地点, 事件]）
   - entity_description：实体的综合描述
识别所有实体之间的关系，每对关系给出：
source_entity：源实体
target_entity：目标实体
relationship_description：关系的描述
relationship_strength：关系强度（1-10 的数字）
文本内容：
{input_text}
请按以下格式输出：
("entity"|实体名|类型|描述)
("relationship"|源|目标|描述|强度)

问题：重复和歧义

缓解方法：「实体合并」和「社区检测」，需要复杂策略（字符串 + 向量 + LLM 判别）

第 3 步：生成实体/关系摘要

把同一个实体在所有文本块里的描述汇总起来，让 LLM 合成一段更完整的实体描述。关系也是同样的处理。

第 4 步：社区检测

社区检测算法（比如 Leiden 算法）会把图谱划分成多个层级的社区。

这种层次化的划分，就是 GraphRAG 后面能处理「不同粒度全局问题」的基础。

第 5 步：生成社区报告

为每一个社区单独生成一份摘要报告（叫 Community Report），存在向量库中。

GraphRAG 会把一个社区内部的所有实体、关系，还有可选的 claim 给 LLM，让它写一份总结报告。这份报告里一般会写清楚这个社区讨论的主题是什么、里面最重要的实体和关系有哪些、有哪些关键发现，以及这个社区在整个数据集里的影响力评分。

这些社区报告就是GraphRAG回答全局性问题的核心资产。

查询阶段

两种搜索模式

Local Search

工作流程：

定位入口实体--->找到相关的实体、关系、原始文本块、所属社区报告--->组装context--->交给 LLM 生成答案

Global Search

Map-Reduce的策略

用户问题
   ↓
选择社区层级
   ↓
读取该层级的社区报告
   ↓
按 Token 上限分批
   ↓
Map：提取相关观点并评分
   ↓
汇总所有观点
   ↓
Reduce：排序、筛选、去重和整合
   ↓
最终答案

四大难点

1. GraphRAG 的索引过程烧token

索引过程只有第4步不需要LLM。

给一份 5GB 的法律文档建 GraphRAG 索引，成本可能高达 3.3 万美元。

微软在 2025 年推出了 LazyGraphRAG，不在索引阶段做实体摘要和社区报告、改成查询时动态生成，成本只有原版的 0.1%。

2. 实体消歧（Entity Disambiguation）

导致：知识图谱被「近重复节点」塞满 + 关系碎片化 + 错误会指数级放大

只能缓和：「实体合并」和「社区检测」

无解。

3. 查询延迟，尤其是 Global Search

Map 和 Reduce都需要LLM。

如果Map层级选得低一点，可能涉及几百上千个社区，这就意味着要并行发起几百上千次 LLM 调用。

一次 Global Search 的端到端延迟，经常在 10 秒到 1 分钟之间。

缓解方法：动态社区选择（Dynamic Community Selection）

从根节点开始，只深入那些和问题相关的社区，跳过无关的子树，能大幅减少 LLM 调用次数。根据微软官方数据，这种优化能把平均参与计算的社区数从 1500 个降到 470 个左右。

4. 增量更新，牵一发而动全身

应对思路一：定期全量重建

适合什么场景？文档更新频率低 + 数据量不大 + 对实时性不敏感的场景，比如公司年度法规库、历史档案库。

应对思路二：增量索引（Incremental Indexing）

先对新文档做一次切块、实体和关系抽取，然后把抽出来的新实体和图里的老实体做消歧合并。通过图算法识别受影响的子图。只对这些受影响的社区重新做一次检测和摘要。

缺点：精度会有损失。需要阶段性全量重建。

应对思路三：时间分区（Temporal Partitioning）

GraphRAG 的增量问题，本质上是「社区摘要」这个设计带来的。

为了解决增量更新问题，LightRAG几乎零额外成本。

适用场景：

一：需要「全局洞察」的深度内容分析

二：跨文档多跳推理

三：数据相对静态、更新不频繁的知识库

四：对精度和可解释性要求极高的场景

LightRAG （香港大学，2024）

https://github.com/hkuds/lightrag

GraphRAG 要存原文文本块 + 实体 + 关系 + 社区 + 社区摘要；

LightRAG 要存原文文本块 + 实体 + 关系。

|--------------------|------------------------------------------------------------------|----------------------------------------------------------|
| 系统 | 数据通常放在哪里 | 检索在哪里发生 |
| LightRAG | 原文/切块放 KV 或文档存储；文本向量放向量库；实体与关系放知识图谱（可用 Neo4j 等） | 向量库做语义召回；图谱做实体关系扩展、局部/全局图检索； |
| Microsoft GraphRAG | 原文切块及其向量放向量索引；实体、关系、社区及社区摘要通常保存为表格/文件或数据库；很多实现把图数据存成 Parquet/CSV | Local Search 以实体为入口，结合向量相似度和图邻域；Global Search 主要检索"社区摘要" |

四个评测维度（全面性、多样性、赋能性、整体）上，LightRAG更好，尤其是多样性。

特点

1. 核心设计思想：「去社区化」

2. 查询时把查询本身拆成两层关键词，分别做检索。

3. 增量更新和索引阶段流程完全一样。

缺点：牺牲了「全局深度洞察」。

索引阶段

第 1 步：文档切块（和Graph一样）

默认每块 1200 token，块和块之间有 100 token 的重叠

第 2 步：实体和关系提取（和Graph一样）

用 LLM 提取，关闭 reasoning/thinking 模式

实体：名称+类型+描述

关系：源实体、目标实体、关系描述 + 关系关键词

第 3 步：键值对生成 + 去重

去重主要基于名称匹配，因为查询时所有相似实体都会被一起检索出来，再通过多路召回合并。

Key是一个便于检索匹配的短语，比如实体名或者关系关键词；

Value 是一段详细的描述信息，留着后面组装上下文用。

基于上一步的结果生成Key和Value， 为了通过 KV 存储迅速拿到完整内容**。**

查询阶段：

第 1 步：关键词抽取

用 LLM（关闭 reasoning/thinking 模式）

从query中抽出两种关键词，高层关键词是抽象主题，低层关键词是具体对象。

第 2 步：双层检索

Low-level 检索：用低层关键词去向量库里搜实体节点。在图上扩展到它们的一跳邻居，收集相关的关系和描述。

得到 实体 + 邻居 + 相关文本块

High-level 检索：得到 关系 + 涉及实体 + 相关文本块

问题

├─ 低层关键词 ──> 实体向量库 ──> 命中实体

│ └─> 知识图谱：一跳邻居、关系

│ └─> Chunk/KV：原文证据

│

└─ 高层关键词 ──> 关系向量库 ──> 命中关系

└─> 知识图谱：关系两端实体

└─> Chunk/KV：原文证据

第 3 步：上下文组装

注意控制上下文的总 token 数

第 4 步：LLM 生成答案

输入：组装好的上下文和原始query

四种查询模式：

• local：在知识图谱中检索，适用于详细问题。

• global：侧重于宏观推理与深层关系查询。

• hybrid：融合 local 和 global 两种模式的检索结果。

• naive：基于文本块的传统 RAG 检索，不使用知识图谱，直接依赖向量相似性在原始文本块中进行检索。

• mix：全功能模式，融合 local、global 和 naive 。LightRAG 的默认查询模式为 mix。

增量更新问题：时效性冲突处理

比如：

「GPT-5.1 是 OpenAI 最新模型」和「GPT-5.2 是 OpenAI 最新模型」，LightRAG 会同时保留**。**

适用场景：

一：数据频繁更新的业务

二：实时性要求高

LightRAG 的查询延迟是秒级。GraphRAG的查询延迟是分钟级。

三：轻量部署、本地化环境

LightRAG 可以在CPU 上跑，不强依赖GPU。

• 边缘设备部署。比如把RAG系统部署到工厂车间的边缘盒子里，帮工人查技术手册。

• 私有化内网部署。对数据隐私要求高的行业，LightRAG+本地部署大模型 可以离线运行，数据不出内网。

四：中小规模知识库

10 万 - 500 万 token

混合架构

稳定的、历史性的核心知识，用GraphRAG;

动态的、日常变化的增量数据，用LightRAG；

在查询时再搭一个路由器(Query Router)，根据查询的类型，把它分流到对应的系统里去。