GraphRAG 和 LightRAG 详解：原理、对比与选型

1、传统 RAG 有什么痛点？

要理解 GraphRAG 为什么会出现，咱们得先搞清楚一个问题：传统 RAG 到底哪里不行？

很多同学读完上一篇 RAG 文章，可能会觉得：RAG 不是挺好的吗？能让大模型有「外挂知识库」，能减少幻觉，能回答私有数据的问题……听起来已经很够用了。

但问题是，「够用」和「能打」是两码事。你在 Demo 场景下跑一跑，确实没什么问题，但一旦真正拿到企业的复杂场景去用，你会发现传统 RAG 经常「表现得体面，但答得不对」。

下面我就用几个真实场景，带你感受一下传统 RAG 会卡在哪里。

痛点一：跨文档的「多跳推理」干不了

咱们先来看一个真实的业务场景。

假设你在一家跨国公司做风控，你问 RAG 系统这样一个问题：

「我们公司哪些欧洲供应商，在过去一年的安全审计中没通过，而且还在处理个人隐私数据（PII）？」

这个问题要想答对，得同时拿到三份文档里的信息：供应商档案（说明哪些供应商是欧洲的）、审计报告（说明哪些供应商没通过审计）、合同文档（说明哪些供应商在处理 PII 数据）。

但传统 RAG 干不了这件事。为什么？

因为传统 RAG 的检索逻辑是「找语义最相近的 Top-K 个文本块」。你问这个问题，它可能分别检索到：一些提到「欧洲供应商」的文本块、一些提到「安全审计」的文本块、一些提到「PII 处理」的文本块。

但它没有任何机制把这三个集合做「交集」。它只能把这些文本块一股脑扔给大模型，然后大模型自己也懵：我该怎么把这几份互相独立的资料关联起来？

这种需要「A 关联到 B，B 关联到 C，然后从 A 推到 C」的问题，就叫多跳推理（Multi-hop Reasoning）。传统 RAG 在这种场景下经常翻车，给出的答案要么不完整，要么干脆瞎编。

还有一个经典的例子，问「爱因斯坦的导师的导师是谁？」。这个问题得先找到「爱因斯坦的导师是谁」，然后再找到「那个导师的导师是谁」。信息是分散在多个文档里的，传统 RAG 一次性检索根本搞不定这种链式推理。

痛点二：全局性问题，它根本答不上

传统 RAG 的第二个硬伤，是答不了「全局性问题」。

什么叫全局性问题？我举几个例子你就有感觉了。

比如你问「这本小说的主题思想是什么？」、「这份年度财报里，公司战略发生了哪些变化？」、「这个技术文档集合里，主要讨论的是哪几类方向？」这些问题有一个共同的特点：答案不在某一个文本块里，而是需要你通读所有文档、归纳总结才能得出来。

但传统 RAG 的本质是「检索」，它只会找 Top-K 个最像你问题的文本块。可你想问的是「主题思想」，哪个文本块会写「本书主题思想是 XXX」？几乎没有。所以它检索出来的 Top-K 个文本块，大概率只是一些零散的片段，大模型拿到这些片段根本没法总结出整体主题。

这个问题在微软 GraphRAG 的论文里，被叫做 Query-Focused Summarization（查询聚焦的摘要）问题，本质上不是一个「检索」任务，而是一个「全局归纳」任务。传统 RAG 的 Top-K 检索机制，天生就处理不了这种需求。

你想想，如果你在医院里问医生「过去一年咱们科室主要治疗的是哪几类病？」，医生要给出答案，得在脑子里把过去一年所有病例都过一遍、归归类。他不能只翻最上面的几份病例就告诉你答案吧？传统 RAG 干的就是这种「只翻最上面几份」的事情。

痛点三：切块带来的「语义断裂」

传统 RAG 的第三个痛点，藏在我们经常忽略的细节里：文档切块（Chunking）本身就在毁坏语义。

你想啊，传统 RAG 第一步就是把文档切成 500 字或者 1000 字的文本块。这种切法看起来没问题，但实际上会带来三个麻烦：

第一个麻烦，是「语义被切断了」。

一段完整的论述可能横跨了三个段落，你按字符数切，就可能把一个完整的观点拦腰斩开。检索时只召回了上半段，下半段没召回，答案自然就不完整。

第二个麻烦，是「实体之间的关系丢了」。

举个医疗场景的例子：原文里写的是「卡托普利属于 ACEI 类药物，但严重肾功能不全者禁用」。切块之后，「卡托普利是 ACEI 药物」可能在一个块里，「严重肾功能不全者禁用」可能在另一个块里。

这时候你问「高血压合并糖尿病患者首选哪几种 ACEI 药物？禁忌症是什么？」，传统 RAG 把这两个块都检索出来扔给大模型，大模型一看：诶，这里提到卡托普利，那里提到禁用……然后就可能给你来一句「卡托普利属于禁忌症药物」。

你看，因果关系被切块这一步给毁了。大模型拿到的是一堆「碎片化的事实」，但事实和事实之间原本的逻辑链条，没了。

第三个麻烦，是「检索噪声」。

因为切块之后每个块都是独立的，语义相似的块不一定就是你真正想要的块。比如你问「苹果的营收」，可能会检索到一堆讨论「苹果」（水果）的文本块，因为它们在语义上都很接近「苹果」这个词。这种噪声进来之后，大模型就容易被误导。

一张表总结传统 RAG 的三大痛点

把上面讲的三大痛点汇总一下：

痛点背后的根本原因：它不「理解关系」

你如果仔细琢磨上面这三个痛点，会发现它们背后其实是同一个根本问题：

传统 RAG 做的是「找相似文本」，但企业真正需要的是「理解实体关系」。

向量检索这种方式，在「找长得像的句子」这件事上是很强的。但它没有机制去理解「这两个实体之间是什么关系」「这条信息和那条信息之间有没有因果链」。

所以，如果你的业务场景只是「找到某条具体事实」（比如问「我们公司年假有多少天」），传统 RAG 完全够用。但只要问题一旦涉及关系、推理、全局归纳，传统 RAG 就开始力不从心了。

那问题来了，怎么让 RAG 真正「理解关系」呢？

答案就是：引入知识图谱。这也正是 GraphRAG 的核心思路。

我们下一节就来聊聊，GraphRAG 到底是怎么把「找相似文本」升级成「理解关系」的。

2、什么是 GraphRAG？为什么会有 GraphRAG？

先搞清楚 GraphRAG 到底是什么

GraphRAG 这个词，其实有两层含义。

狭义上，它指的是微软研究院在 2024 年 4 月发布的那篇论文和配套的开源项目。论文名字叫 《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》（从局部到全局：一种面向查询聚焦摘要的图 RAG 方法），作者是 Darren Edge、Ha Trinh 等人。

广义上，它指的是所有基于知识图谱做 RAG 的方法，业界还有很多变种（比如 NebulaGraph、HippoRAG、阿里云的 AnalyticDB GraphRAG 等）。

咱们这篇文章主要讲的是微软这套 GraphRAG，因为它目前影响力最大，开源社区也最活跃，几乎是所有 GraphRAG 方案的参照对象。后面如果没特别说明，我说的 GraphRAG 都指微软这一套。

好，定义说清楚了，那 GraphRAG 到底在干嘛？

一句话概括：GraphRAG 就是用 LLM 把文档「读成一张知识图谱」，然后基于这张图谱来做检索和回答。

传统 RAG 和 GraphRAG 的核心差异是什么？

你如果把传统 RAG 和 GraphRAG 放一起对比，会发现它们的关键分歧就在于：知识是以什么形式存储的。

传统 RAG：知识以离散的文本块形式存储。每个文本块都是独立的，块和块之间没有任何联系。

GraphRAG：知识以图（Graph） 的形式存储。文档里的人、地、物、概念（这些是「实体/节点」），以及它们之间的关系（这些是「边」），都被显式地提取出来，形成一张结构化的关系网络。

我举个更具体的例子你就懂了。

假如你有一段文本：「张三在 2025 年创立了 A 公司，李四是 A 公司的 CTO，A 公司主要做自动驾驶业务。」

传统 RAG 会把这段话整体变成一个文本块，存到向量数据库里。你下次问「A 公司的 CTO 是谁？」，它靠语义相似度检索回这段话，然后让大模型去阅读理解，答出「李四」。

GraphRAG 则会从这段话里抽取出实体和关系，变成这样的结构化数据：你看出差别了吗？GraphRAG 里的知识不是「一段话」，而是一张「关系网」。这张关系网里，每个节点是谁、每条边是什么关系，都是明确的、可追溯的。

为什么要搞成图？这么做到底好在哪？

你可能会问：费这么大劲把文档变成图，这么做到底有什么好处？

其实就是为了解决咱们在第 1 章讲的那三个痛点。咱们一个一个来看。

第一，多跳推理变得天然可行。

上一节咱们提到那个「欧洲供应商 + 审计没过 + 处理 PII 数据」的查询，传统 RAG 干不了，是因为它没法做「交集」。但在图上，这件事就变成了图遍历（Graph Traversal）：从「欧洲」这个节点出发，找它连着的所有「供应商」节点，再筛选出那些连着「审计未通过」的，再筛选出那些连着「PII 数据处理」的。

图天然就擅长做这种「顺藤摸瓜」的事。这也是 GraphRAG 在多跳问答任务上（比如 HotpotQA 数据集）比传统 RAG 的 F1 分数高 5% 以上的根本原因。

第二，全局性问题能答了。

这是 GraphRAG 最核心的创新点，也是那篇论文标题里「From Local to Global」（从局部到全局）的来源。

微软的做法很巧妙：先把整张知识图谱通过社区检测算法（比如 Leiden 算法）划分成若干个「社区」，再用 LLM 为每个社区生成一份摘要。

什么叫社区？你可以把它理解成图里那些互相抱团、关系特别密切的一群节点。比如在《三国演义》这本书里，刘关张就是一个小社区、曹操集团是一个社区、诸葛亮周边的人物又是一个社区。每个社区内部的人物关系非常紧密，但社区之间的连接就比较稀疏。

一旦每个社区都有了摘要，你问「整本书主要讲了几路诸侯的斗争？」这种全局性问题时，GraphRAG 就可以把各个社区摘要拿出来归纳一下，给你一个完整的答案。传统 RAG 没有这种「全局视角」，自然就答不出来。

第三，实体和关系显式化，切块语义断裂的问题也缓解了。

因为 GraphRAG 已经提前把文档里的实体和关系抽出来了，哪怕原文里「卡托普利属于 ACEI」和「严重肾功能不全者禁用」分散在两个地方，它们在图上也能通过「卡托普利」这个节点连起来。检索时不会丢掉因果关系，大模型也就不容易混淆了。

一个更形象的类比：从「图书馆找书」到「带导游游书店」

讲到这儿，你可能已经有感觉了，但咱们再用一个生活化的类比来强化一下理解。

传统 RAG 像什么？像你去一个没有任何分类的图书馆找书。所有书都按出版日期顺序摆在一起，你想找「和气候变化有关的书」，只能靠关键字搜索，一本一本翻，找到几本就交给你。你想问「这个图书馆最近这几年主要收藏的是哪几个方向的书？」对不起，没人能回答你。

GraphRAG 像什么？像你进了一个带导游的主题书店。导游在你进门前已经把所有书按主题分好类了，每个主题区还贴了一张「这个主题区主要讨论什么」的概览海报。你要查具体的细节，导游带你精准定位；你要问宏观的主题，导游就把所有主题概览海报念给你听。

你说这两种体验能一样吗？

GraphRAG 的诞生背景

最后聊聊 GraphRAG 为什么在 2024 年这个时间点被提出。

其实「知识图谱」这个东西并不新鲜，早在 2012 年谷歌就提出过 Knowledge Graph 的概念。把知识图谱和 RAG 结合的想法也有人尝试过，但之前都不温不火，为什么？

因为之前构建知识图谱太痛苦了。传统的知识图谱构建，要么靠人工标注（超级贵），要么靠专门训练的 NLP 模型（效果一般）。提取实体、关系、消歧、对齐……每一步都是技术壁垒。

而大模型时代，这些事情全都可以交给 LLM 来做了。你写几个提示词（Prompt），LLM 就能从一段文本里把实体、关系、属性都抽出来，效果还不错。这就让「从文档自动构建知识图谱」这件事从「需要专门团队做半年」降到了「写个 Pipeline 跑几个小时」。

这也是 GraphRAG 能在 2024 年一下火起来的根本原因：不是思路新，而是 LLM 让这个思路变得可实现了。

好，到这儿你应该对 GraphRAG 是什么、为什么会有它，有了一个整体的认识。但你可能还有疑问：它具体是怎么工作的？实体怎么抽？社区怎么划？查询怎么做？

3、GraphRAG 的工作流程是怎样的？

搞清楚了 GraphRAG 是什么，咱们这一节就来拆解它到底是怎么工作的。

和传统 RAG 一样，GraphRAG 也分成两个大阶段：索引阶段（Indexing，离线） 和 查询阶段（Query，在线）。

索引阶段做的事情：把原始文档变成一张带有社区摘要的知识图谱。这个阶段很重，需要 LLM 大量调用，通常离线跑一次就行。

查询阶段做的事情：用户提问时，基于这张图谱快速检索出相关信息，喂给 LLM 生成答案。

咱们一个一个阶段来看。

索引阶段：5 步把文档变成知识图谱

微软 GraphRAG 的索引阶段，可以拆成 5 个核心步骤。咱们用一个具体的例子来理解整个过程，比如说你有一本《三国演义》的电子书，要把它喂进 GraphRAG。

第 1 步：文档切块（Text Chunking）

这一步和传统 RAG 完全一样。把一整本书按一定的字符数（比如 1200 字）切成一个个文本块（GraphRAG 里叫 Text Unit）。

为什么还要切块？因为 LLM 的上下文窗口有限，你没法把 50 万字的《三国演义》一次性塞给它。切成小块之后，后面的实体抽取就可以并发地对每个块单独处理。

第 2 步：实体与关系提取（Entity & Relationship Extraction）

这一步是 GraphRAG 的第一个核心创新点。每个文本块都会单独发给 LLM，让它从里面把实体（Entity） 和关系（Relationship） 抽出来。

GraphRAG 用的是一个专门设计的 Prompt，大致长这样（简化版）：

你是一个实体关系抽取助手。请从下面的文本中：
1. 识别所有的实体，每个实体给出：
   - entity_name：实体名（大写）
   - entity_type：类型（比如 [人物, 组织, 地点, 事件]）
   - entity_description：实体的综合描述

2. 识别所有实体之间的关系，每对关系给出：
   - source_entity：源实体
   - target_entity：目标实体
   - relationship_description：关系的描述
   - relationship_strength：关系强度（1-10 的数字）

文本内容：
{input_text}

请按以下格式输出：
("entity"|实体名|类型|描述)
("relationship"|源|目标|描述|强度)

LLM 读完一段「刘备和关羽、张飞在桃园结义」的文本，会输出类似这样的结构化内容：

("entity"|刘备|人物|蜀汉的建立者，三国时期重要人物)
("entity"|关羽|人物|刘备的义弟，以忠义闻名)
("entity"|张飞|人物|刘备的义弟，勇猛善战)
("relationship"|刘备|关羽|桃园结义为兄弟，关系极为紧密|10)
("relationship"|刘备|张飞|桃园结义为兄弟，关系极为紧密|10)
("relationship"|关羽|张飞|桃园结义为兄弟|10)

这一步跑完，所有文本块都会产出一堆实体节点和关系边。

但注意，这里会有一个麻烦：重复和歧义。比如刘备可能在文本里被叫做「玄德」「先主」「刘皇叔」，LLM 抽取的时候可能把它们抽成了三个不同的实体。这个问题 GraphRAG 后面会通过「实体合并」和「社区检测」来一定程度上缓解，但不能完全解决。这也是我们第 4 章要讲的难点之一。

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

这一步容易被忽略，但其实很关键。

同一个实体（比如「刘备」）会在好多个文本块里被反复抽取，每次抽取的描述可能都不一样：「蜀汉的建立者」「关羽的义兄」「汉室宗亲」……

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

这一步做完，每个实体节点就有了一段「综合描述」，这段描述会被向量化后存入向量数据库，供后面的 Local Search 用。

第 4 步：社区检测（Community Detection）

到这一步，你手里已经有了一张完整的知识图谱，里面的节点是实体，边是关系。但这张图可能有成千上万个节点，怎么组织？

GraphRAG 用的是Leiden 算法（读作「莱顿」），这是一种层次化社区检测算法，比常见的 Louvain 算法更稳定一些。

Leiden 算法会把图谱划分成多个层级的社区，这是它最有意思的地方。

咱们还是拿《三国演义》来说。

• 最粗的那一层（叫 Level 0）可能把整张图划成五到十个大社区，比如「曹魏集团」「蜀汉集团」「东吴集团」「黄巾起义相关」这种；
• 再往下一层（Level 1），每个大社区又会被拆得更细，比如「蜀汉集团」里会分出「刘关张小团体」「诸葛亮周边」「五虎上将」等等；
• 再继续往下 Level 2、Level 3，一路细分下去，直到社区没法再拆为止。

这种层次化的划分，就是 GraphRAG 后面能处理「不同粒度全局问题」的基础。用户问得越宏观，就用越高层的社区；问得越具体，就用越低层的社区。

第 5 步：生成社区摘要（Community Reports）

社区划分完之后，GraphRAG 会为每一个社区单独生成一份摘要报告（叫 Community Report）。

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

这些社区报告就是 GraphRAG 回答全局性问题的核心资产。你可以把它们理解成图书馆里每个主题区前面贴的那张「本主题概览海报」。

索引阶段到这里就结束了。可以看到，这个过程对 LLM 的调用量是非常大的：每个文本块要调一次做实体抽取，每个实体/关系要调一次做摘要合成，每个社区要调一次做报告生成。一本 100 万 token 的书，索引一次可能要几千甚至上万次 LLM 调用，成本不便宜。这也是后面我们会讲到的痛点之一。

查询阶段：两种搜索模式各司其职

索引跑完之后，图谱就建好了，你有一整套实体节点 + 关系边 + 层次化社区 + 社区报告。真正用起来的时候，GraphRAG 提供了两种查询模式：Local Search 和 Global Search。

（补充：后来 GraphRAG 官方还推出了第三种叫 DRIFT Search 的模式，相当于 Local 和 Global 的混合版，咱们不展开讲，感兴趣的同学可以看官方文档。）

模式一：Local Search（本地搜索）

适用场景：用户问的是关于某个具体实体的问题。比如「诸葛亮都有哪些著名的计策？」「A 公司的 CTO 是谁？」。

工作流程：

1. 定位入口实体：先用问题的向量，在所有实体节点的向量索引里做相似度搜索，找到最相关的几个实体。比如问诸葛亮，就先定位到「诸葛亮」这个节点

2. 顺藤摸瓜扩展：从入口实体出发，沿着图的边扩展，找到相关的邻居实体、关系、原始文本块、所属社区报告

3. 组装上下文：把找到的这些信息整合成一段上下文（Context）

4. 交给 LLM 生成答案

你看，Local Search 的核心是「从一个点扩散到它的邻居」，很适合回答那些「围绕某个具体对象」的问题。

模式二：Global Search（全局搜索）

适用场景：用户问的是全局性、宏观性的问题。比如「整本书讲了哪几派势力的斗争？」「这份报告的主要结论是什么？」。

工作流程：GraphRAG 这里用的是一个Map-Reduce的策略：

• Map 阶段：把某个层级（比如 Level 1）的所有社区报告都拿出来，分成好多批，对每一批都让 LLM 生成一个「中间答案」，并给每个观点打一个「重要性评分」
• Reduce 阶段：把所有中间答案里的观点汇总，按评分排序，保留最重要的那些，最后让 LLM 合并成一个完整的最终答案

这个流程听起来有点绕，但它的本质是：把全局性问题拆分成多个社区内部的子问题并行解答，最后再汇总。

打个比方，你问班长「咱们班这学期整体学习情况怎么样？」，班长不会去看每个同学的每张考卷，而是会先找每个小组的组长，让他们每人给一份自己组的总结，然后班长再把所有组的总结汇到一块儿给你看。GraphRAG 的 Global Search 干的就是这事儿。

为什么 Global Search 特别费钱？

你仔细想想就知道了：Map 阶段要遍历所有相关社区的报告。如果层级选得低（比如 Level 2），可能涉及几百上千个社区，每个都要调一次 LLM 生成中间答案。一次全局查询可能就要消耗上万 token。

这也是微软后来推出「动态社区选择」（Dynamic Community Selection）优化的原因：从根节点开始，只深入那些和问题相关的社区，跳过无关的子树，能大幅减少 LLM 调用次数。根据微软官方数据，这种优化能把平均参与计算的社区数从 1500 个降到 470 个左右。

一张图总结 GraphRAG 的完整工作流程

最后咱们把整个流程串起来：

索引阶段（离线，一次性跑完）：

查询阶段（在线，每次查询都跑）：

到这儿你应该已经把 GraphRAG 的整个流程搞清楚了。但你可能也注意到一个问题：这套方案虽然强大，但步骤多、调用贵、流程复杂。

GraphRAG 在实际落地的时候，到底会撞上哪些坑？下一节咱们来盘一盘。

---

4、GraphRAG 的难点是什么？

读到这儿，你可能会觉得 GraphRAG 好像挺完美的，能解决传统 RAG 的痛点，又有清晰的流程。

但这里我得给你泼一盆冷水。

GraphRAG 虽然效果好，但它是一个「昂贵的妥协」。在真正的生产环境里，你会发现它有一堆让人头大的坑。这也是为什么很多团队兴冲冲地上 GraphRAG，试了几个月之后又默默退回到传统 RAG。

这一节咱们就把 GraphRAG 落地时常见的四大难点盘一盘。搞懂这些难点，你也就能理解为什么后来会出现 LightRAG 这种「轻量化改良方案」。

难点一：索引成本高得吓人（Token 焚烧炉）

GraphRAG 第一个也是最让人肉疼的难点，就是构建成本。

传统 RAG 的索引过程其实挺便宜的：切片 → 过一下 Embedding 模型 → 存进向量库。Embedding 模型的定价很低，每百万 token 也就几毛钱，整个过程几乎可以忽略成本。

但 GraphRAG 的索引过程，简直就是一台 Token 焚烧炉。

你想想，它每一步几乎都在调 LLM。每个文本块要调 LLM 来抽实体和关系，抽完之后每个实体和关系还要再调 LLM 合成一段综合描述，然后每个社区又要调 LLM 生成一份社区报告，要是你还开了 claim 抽取，那又是一轮 LLM 调用来提取各种断言。

你把这些加起来就会发现，整个过程等于把所有原文通过 LLM 反复读了好几遍，token 消耗轻轻松松就是原文的十倍甚至几十倍。

具体花多少钱呢？有研究机构做过测算：

对比一下：同样 100 万 token，传统 RAG 的索引成本只要几美分，GraphRAG 要几十美元，差了三四个数量级。

这还不算最夸张的。有一份 arXiv 上的研究估算，给一份 5GB 的法律文档建 GraphRAG 索引，成本可能高达 3.3 万美元。对于大部分团队来说，这个数字基本就意味着「不能玩」。

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

难点二：实体消歧，踩过的人都知道多痛

GraphRAG 第二个难点，也是很多人没踩坑之前意识不到的杀手级问题，就是实体消歧（Entity Disambiguation）。

什么叫实体消歧？我举几个例子你就明白了。

你看「IBM」「国际商业机器」「IBM Corp.」「Big Blue」，这四个名字其实指的都是同一家公司，人一看就知道；但机器不知道。再比如「苹果」「苹果公司」「Apple」「Apple Inc.」，前三个在不同语境下既可能指水果也可能指公司，你得结合上下文去判断。还有一些场景更麻烦，比如「张三」这个名字，在几百篇文档里可能对应的根本就不是同一个人。

而 LLM 做实体抽取，天然就是不一致的。同一个实体在不同文档里被叫做不同名字，LLM 抽取出来之后，就变成了好几个独立的节点。

这种情况下会发生什么？

• 第一，你的知识图谱会被「近重复节点」塞满。一张本该只有一万个节点的图，可能出现好几万个节点，其中一堆是同一个实体的不同化名。
• 第二，关系会碎片化。假设有 100 份合同涉及 IBM，其中 60 份用「IBM」，40 份用「国际商业机器」。你查「IBM 的合同」，系统只会返回那 60 份。另外 40 份被挂在了另一个节点下，根本查不出来。
• 第三，错误会指数级放大。实体抽错一个，和它相连的所有关系都跟着错，下游社区检测也跟着错，最后生成的社区报告就跟原文对不上了。

这个问题有多难？难到业界没有标准解法。

生产环境通常会叠加好几层策略：字符串编辑距离（处理拼写差异）、向量相似度（处理语义相似）、LLM 判别合并（处理复杂情况）、甚至还要人工兜底。但每一层都会增加索引成本和延迟。

有位资深工程师说过一句话我觉得特别扎心：「实体碎片化的知识图谱，比没有知识图谱更糟糕，因为它制造了一种虚假的完整感」。你以为图已经建好了，实际上里面全是断裂的关系，但你从外面根本看不出来。

难点三：查询延迟，尤其是 Global Search

GraphRAG 的第三个难点，是查询延迟。

传统 RAG 的查询有多快？向量数据库的 ANN（近似最近邻）搜索通常毫秒级返回，整个端到端的问答可能也就一两秒。

GraphRAG 就完全不是一个级别了。

Local Search 还好，定位入口实体 + 图遍历扩展 + 上下文组装 + LLM 生成，整体大概几秒钟，勉强能接受。

但 Global Search 就是个慢性子。因为它本质是一个 Map-Reduce 过程：先是 Map 阶段，把某个层级下所有相关的社区报告拿出来，分批塞给 LLM 让它生成中间答案，要是层级选得低一点，可能涉及几百上千个社区，这就意味着要并行发起几百上千次 LLM 调用；然后是 Reduce 阶段，再让 LLM 把所有中间答案汇总成一个最终回答。

你这么一看就懂了，这种「先扇出再汇聚」的结构，一次 Global Search 的端到端延迟，经常在 10 秒到 1 分钟之间。这种响应速度，做离线分析还行，做 C 端实时交互？完全不可能。

你想啊，你问一个 ChatGPT，要等一分钟才出答案，谁能忍？

微软后来也意识到这个问题，推出了动态社区选择（Dynamic Community Selection）的优化，从根节点逐层下钻，只展开相关的社区，能把平均社区数从 1500 降到 470 左右。但再优化，Global Search 也还是比向量检索慢一个数量级。

难点四：增量更新，牵一发而动全身

这是 GraphRAG 最要命的一个难点，我单独放在下一节展开讲。

先给你一个直观感受：在传统 RAG 里，新增一份文档，就是把它切片、向量化、upsert 进向量库，完事。

但在 GraphRAG 里，事情就没那么简单了。一份新文档进来，里面可能会冒出一个实体，它其实和图里已有的某个老节点是同一个东西，但名字不一样，于是实体消歧问题又来了。再比如新文档里抽出一堆关系，这些关系一加进图，原来的社区划分就可能过时了；社区一变，你之前花大价钱让 LLM 生成的那些社区摘要就全部跟着失效；等摘要重建完，整张图的向量索引还得跟着同步更新一遍。

这种「数据互联性」带来的牵一发而动全身，让 GraphRAG 在动态场景下几乎无法高效维护。很多团队的实际做法就是「定期全量重建」，但这又把成本问题放大了。

增量更新的具体难在哪、业界有哪些应对方案，咱们下一章专门聊。

小结：GraphRAG 是「昂贵的妥协」

咱们把 GraphRAG 的四大难点汇总一下：

看到这儿你应该理解了，GraphRAG 不是银弹，它是一个「在特定场景下不得不接受的昂贵妥协」。

如果你的业务对成本敏感、对实时性要求高、数据还需要频繁更新，那原生的 GraphRAG 可能并不适合你。这也正是后面 LightRAG 这类「轻量化方案」的价值所在，它们在精度上做一些妥协，换来更低的成本和更好的增量支持。

下一节，咱们就聚焦 GraphRAG 四大难点中最棘手的那个：增量更新。看看业界是怎么应对的。