GraphRAG 两年后：还在维护，但大多数场景用不上

TL;DR：GraphRAG 两年后仍在维护，但它并没有成为通用 RAG 的默认升级路径。第三方基准给出的边界已经比较清楚：简单事实检索通常不划算，多跳推理、跨文档综述和关系型查询才是图结构真正有价值的场景；同时，它的索引、查询、增量更新和实体治理成本都明显更高。生产上更稳妥的做法不是整体迁移，而是保留 vector RAG，把 graph 作为少数复杂查询的按需能力。

两年前的 2024 年 7 月，微软发布 GraphRAG：先从文档中抽取实体和关系构图，再在图上检索并生成答案；当年 11 月项目开源。它很快被当成「RAG 的下一代」，中文社区里甚至逐渐形成了「全面更好、什么查询都能答」的印象。两年后再看，真正有价值的问题已经不是它还热不热，而是它的适用边界到底在哪里。

2026 年 8 月 6 日，我用 GitHub API 核了一遍项目现状。repo 仍未归档，最新版 v3.1.1 发布于 7 月 18 日，前一天还有 push；但热度和投入都比流行印象弱：stars 为 35,280，并非中文社区流传的 8 万+；近 52 周只有 84 个 commit，平均每周 1.6 个，其中 2025 年 10 月到 2026 年 1 月有约 3.5 个月零提交空窗；发布也由单一维护者主导。

版本线本身仍在演进：2024-11 开源并加入 DRIFT 搜索，2025-02 开源 LazyGraphRAG（不建图的模式），2026-01 拆成 8 个包的 monorepo。但微软侧的外围投入信号更弱：graphrag-accelerator 已归档，官方 Agent Framework 的图集成主角是 Neo4j 的 GraphRAG，ICLR 2026 接收的相关论文也都是外部学术跟进。至于「微软内部在使用 GraphRAG」这个常见说法，我在论文全文和官方博客里都没有找到出处。

所以第一问「它还活着吗」并不难回答：还活着，但热度已经打折，也不像一个持续高投入的项目。真正值得工程团队花时间回答的是第二问：GraphRAG 到底什么时候值得用？

GraphRAG 真的更好吗

2024 年的主流叙事是「GraphRAG 全面更好」。到 2026 年，三个第三方学术基准把这个结论收窄成了一条更清楚的边界：图并不是普遍提升，而是在特定查询类型上换来了更强能力。

简单事实检索恰恰是它最不划算的场景。GraphRAG-Bench（ICLR 2026）实测，GraphRAG 在 Natural Questions 上比普通 RAG 低 13.4%，时间敏感查询低 16.6%；HotpotQA 多跳任务只高 4.5%，却付出 2.3 倍延迟。原因并不复杂：对简单查询，图处理本身就是额外步骤，还可能把更多无关关系和噪声带入上下文。

复杂推理和跨文档综述则是图结构真正占优的地方。同一基准中，图家族在复杂推理上明显领先，HippoRAG2 为 53.38，Basic RAG 为 42.93；上下文综述高 12.8 分。但这里有两个容易被忽略的限定条件：这些数字的对比对象是 HippoRAG2，微软的 GraphRAG 并不在其中；同时，图在简单任务上输的幅度只有 0.78 分，远小于复杂任务上的收益。因此，不能把不同任务混在一起，简单概括成「GraphRAG 平均更好」或「GraphRAG 整体更差」。

多跳推理是图目前最稳固的优势。《Do We Still Need GraphRAG?》（2026-04）给出了很直接的量化结果：单跳检索下，图平均只高 0.47 分；多跳则高 27.23 分，其中 HotpotQA 为 46.70 对 19.00。即便换成强化学习训练的 agentic 检索 Search-R1，图后端在 MuSiQue 上仍是 40.82 对 14.42，而且方差低约 5 倍。论文因此给出的判断不是「图替代 agent」，也不是「agent 淘汰图」，而是两者互补。

更尖锐的结果来自 AWS 和 Cisco 的《Is GraphRAG Needed?》（ACL 2026 GEM Workshop）。他们发现了一个「检索-生成鸿沟」：图谱实体召回从 54.9% 提升到 83.5%，约为原来的 1.5 倍，但 LLM 的答案召回几乎没有跟着增长，只在 45.4% 到 48.2% 之间。更值得警惕的是，简单的「文档 + 1 跳关系」方案 Hit@1 为 0.6972，反而高于完整 GraphRAG 管线的 0.6422；无工具的自洽 agentic 检索达到 0.6881，给它加上图谱工具后却降到 0.6055。这个结果把争论从「哪种检索架构更强」推向了更实际的「上下文工程」：检索端多找回实体，不代表生成端就能有效利用这些信息。

这里需要补一个证据层级说明。上述三个基准都是第三方学术评估，可信度高于厂商自报，但目前都没有独立复现；它们又分别基于单一骨干模型（GPT-4o-mini 或 Claude 3.7 Sonnet），论文本身也提醒，结果可能随着模型能力变化。换句话说，现在最稳妥的结论不是「GraphRAG 一定赢在哪」，而是：多跳推理和跨文档综述已经有比较明确的优势证据；简单事实检索则往往得不偿失。关系型查询这第三类，更主要的证据来自生产路由实践，后面再谈。

赢是有代价的：成本和维护都更重

GraphRAG 的性能收益不能脱离成本讨论，而且这里尤其不适合用一个「贵 N 倍」概括，因为不同配置和语料规模会把结果拉开几个数量级。

索引贵多少，取决于配置

先看索引。EMNLP 2025 一篇论文独立测量，GraphRAG 的索引 token 是 LightRAG 的 1.7 到 2.3 倍。社区流传的「8 倍」「10 到 20 倍」来自不同配置的个案，高配估算甚至可以到 50 到 100 倍。也就是说，同一个技术在不同设置下可以差两个数量级，所以任何「贵 N 倍」的说法，如果没有配置和语料规模，基本没有决策价值。

查询成本反而更容易复核。原论文 Table 3 给出的单次全局查询上下文是 4 万到 114 万 token，对应 News 语料 C0 到 C3 层级；独立实测中，GPT-4o 跑一次约 15 万 token、0.8 美元。对于需要高频在线查询的系统，这部分成本会比一次性的建图成本更直接地进入 TCO。

更难的是增量更新和实体治理

维护问题并不是「多调几个参数」这么简单，而是和图的增量更新机制绑定在一起。官方 issue 链已经把几个典型问题写得很清楚：#741 明确说明增量索引采用 append-only 设计，删除和修改 out of scope，最坏情况下会退化为全量重建；#511 中维护者也承认，修改文档相当于新增节点，图里可能继续保留旧事实；#1702 记录了增量合并后 ID 损坏、查询结果不可用的问题；#401 则展示了《福尔摩斯》建图时 Sherlock、Sherlock Holmes、Mr. Holmes 被拆成三个独立节点的实体消歧问题。

社区源码分析进一步补上了机制层面的解释：跨批次实体消歧缺失，按月分批索引时同一实体不会自动合并，实测节点重复率超过 18%，消歧准确率只有 63.2%，最终只能靠月度全量重建兜底。从业者所谓「调参一个月」仍然只是个案，不能当成普遍统计；但参数敏感、实体重复和更新震荡，并不是单纯的主观吐槽，已经有机制和 issue 可以相互印证。

抽取质量同样会形成隐蔽的系统风险。代码库场景中，31.2% 的文件被 LLM 抽取直接跳过，而且三个仓库结果一致；图构建时间约 70 倍，端到端成本约 20 到 46 倍。更麻烦的是，被漏掉的文件会同时从 embedding 和图谱中消失，形成不容易被发现的静默盲区。

LazyGraphRAG 降低了成本，但证据还主要来自官方

微软对成本问题的回应是 LazyGraphRAG。官方博客给出的口径是：索引成本与 vector RAG 相同、只有完整 GraphRAG 的 0.1%，查询成本低 700 倍。这组数字很亮眼，但目前仍是官方基准，没有第三方复测；同时，它把一部分工作移到了查询阶段，引入逐查询的 LLM 调用，延迟从毫秒级上升到秒级，而且还没有并入主 repo。

最接近真实迁移故事的是一个法律科技客户的 8 万份判例：标准 GraphRAG 索引估算为 1.2 万美元，LazyGraphRAG 首次查询只需要分钟级。但这仍是一篇评估文，而不是长期生产复盘，所以更适合把它当成「可行性信号」，而不是成熟度证明。

生产里，GraphRAG 更像一种按需能力

「从研究走向生产」这个说法并非完全站不住脚，但公开证据远没有宣传材料里那么丰富。如果要求案例同时包含真实生产周期、量化指标和可核查来源，我能找到的完整案例只有 LinkedIn 客服系统：它来自 SIGIR 2024 论文，真实生产约 6 个月，并且带随机对照。

这里的效果数字必须保留原始口径：MRR +77.6% 是相对提升，从 0.522 到 0.927；BLEU +0.32 是绝对差值，从 0.057 到 0.377；工单解决时间 -28.6% 是中位数，而均值实际为 -62.5%。这些数字如果脱离指标定义单独引用，很容易被放大成比论文原意更强的结论。

其他公开案例大多只有厂商自己的说法。AWS 医药案例中的「研发周期 -87%、取中率 5 倍」来自匿名单客户试点和厂商自报；Neo4j 高管点名 Uber、Klarna、Novo Nordisk 等客户，但没有指标细节；AISO 正畸是中文社区里少见的具名私有化部署，但来源仍是厂商侧社区，效果数字不能单独引用。流传较广的「6% 幻觉减少、80% token 减少」则出自 GenAIK 2025 论文在 Finance Bench 上的基准结果，不是生产数据；同一篇论文在另一任务上还报告了 734 倍 token 降幅，说明这类效果数字会随任务集跨越两个数量级。

相比单个案例，生产架构反而出现了更稳定的共识：不是把所有查询迁到 GraphRAG，而是让图只处理它擅长的问题。从业者的年度复盘把「混合路由」称为最常见、也最稳的做法：简单查询走 vector，复杂查询走 agentic，关系型查询走 graph。这个模式的关键不是多加一个后端，而是先承认不同查询的最优检索路径并不相同。

另外两种常见模式也围绕成本和治理展开。其一是分层抽取：用小模型抽实体，只在需要综述时调用前沿模型，把索引成本压下来；其二是联邦图：各业务域维护自己的 schema，用上层图桥接公共实体，避免组织重组时重新灌全量数据。

还有一个很实用的入场门槛共识：如果团队连语料库最重要的五种实体类型都无法向人解释清楚，通常也不适合直接上 GraphRAG。

风险与替代：图不是免费的结构

对完整 GraphRAG 最直接的成本批评，某种程度上来自微软自己：LazyGraphRAG 的基准恰恰把完整 GraphRAG 的索引成本摆到了台面上。第三方论文更直接，ICLR 2026 的 GraphRAG-Bench 明确写到「GraphRAG 经常在真实任务上不如 vanilla RAG」。

从业者常见的经验判断是，70% 到 90% 的真实查询用朴素或混合 RAG 已经足够；但这个比例来自多篇独立博文，并没有单一权威统计，因此更适合作为经验区间，而不是行业定律。

安全风险来自关系结构本身

GraphRAG 还引入了传统向量检索没有的结构化攻击面。GragPoison 展示了一种黑盒毒化攻击：通过注入关系，可以一次影响多个查询，成功率最高 98%；这里的 98% 是上限，不是均值，该工作已被 IEEE S&P 2026 录用。

图谱逆向提取研究则给出了一个值得注意的悖论：原始文本泄露可能反而减少，但结构化的实体和关系信息更容易被提取。这个方向已经形成一组攻防工作，包括 LogicPoison、后门攻击和 HoG-GRAG 防御，是 2026 年仍在活跃发展的研究前沿。对医疗、法律、金融等隐私敏感场景来说，这不是外围安全问题，而是选型时必须进入威胁模型的新攻击面。

替代方案很多，但还没有统一赢家

LightRAG 的 stars（约 3.8 万）已经反超微软 repo，但社区流传的「快 10 倍、省 8 倍 token」查不到官方出处。论文自报的是约 100 倍更少的索引 token，而且它的 LLM 裁判评测在混合域反而输给 GraphRAG，胜率为 48.14%。这也说明，不能把某个项目在单一 benchmark 上的优势直接外推成通用排名。

其他路线同样各有侧重。HippoRAG2 走记忆路线，多跳最强，性价比最高，每百万 token 预处理成本为 2.85 美元，对微软版 13.19 美元；KAG（蚂蚁）强调逻辑推理和合规，WPS 365 已采纳；Graphiti（Zep）做时序图，并进入 ThoughtWorks 雷达。问题在于，各家 benchmark 互不兼容，跨厂排名并不可靠；Mem0 自报 93.4%，第三方复现只有 73.8%，这种落差并不少见。

更值得关注的趋势性替代是 Agentic RAG：用 agent 的推理能力替代一部分预先构建的图结构，成本更低，新鲜度也更好。但它目前仍没有关掉多跳差距。前面的结果已经说明，在多跳任务上，agentic 检索面对图后端仍然明显落后。这也是为什么图结构虽然不是默认方案，却仍然保留了一个很难被替代的能力区间。

两年后怎么选

两年过去，上不上 GraphRAG 已经不太需要靠愿景下注，更多是一个查询类型和系统约束的问题。

默认不用。事实检索、单跳问答和常规知识库，vector RAG 配合好的文档解析和 reranking 通常已经足够；把索引、查询和维护都算进去，成本可以低一到两个数量级。Atlan 给出的规则很具体：当实体少于 1000 个、关系简单时，vector RAG 可以用十分之一的成本胜出。

按需叠加。如果语料里存在密集且可命名的关系，例如法律、医疗、金融或代码依赖，而且查询确实需要多跳推理、跨文档综述或显式关系查询，更合理的做法是混合路由：简单查询继续走 vector，复杂查询再走 graph，而不是整体迁移。

有两类场景尤其要谨慎。第一，频繁更新的语料不要轻易上图：append-only 的增量索引可能把旧事实继续留在图里，新鲜度维护会变成系统性成本。第二，无法治理的脏数据不要轻易上图：向量检索里的噪声到了图里会被固化成实体和关系，结构化之后反而更难忽略。

GraphRAG 两年后的价值，不在于它是不是「下一代 RAG」，而在于它终于有了一条更清楚的适用边界。把它当成所有 RAG 的升级路径，成本和复杂度大概率不划算；把它限定在多跳、跨文档综述和关系型查询上，再用混合路由控制成本，才更接近今天公开证据支持的工程选择。