Graph RAG 的边界：我为什么不建议你先上它

2024 年微软发布 GraphRAG 的时候，我上头过一次。demo 里它能答“腾讯投资了哪些公司“这种多跳问题——这正是纯向量检索答不好的那类。我把 119 页的腾讯中报喂进去建图，先等来的不是答案，是几十上百次 LLM 调用的账单，和一条“腾讯投资了微信“的错误关系。

冷静下来，判断就一句话：它解决的问题是真的，问题是你付不付得起。第 17 篇聊 RAG 与 Agent 的边界，结尾我放了一句“另一个热门方向，先别上“——这篇把这句话摊开，一笔一笔算账。

开算之前，先把一个概念争论搁置。GraphRAG 到底算不算 RAG？有人说算：伞概念之下，凡是 retrieval 服务于 generation 的实现都归 RAG，流传很广的那篇综述（arXiv:2312.10997）就是把图谱类方法归进 Modular RAG 的；也有人说不算：KG 是独立方向，不服务生成的任务它照样能干，只是被 RAG 调用时才临时充当组件。两种说法都自洽。我的态度是归属之争不影响选型——影响选型的是成本和甜蜜点，这篇只算这两笔账。

一、先把话说公道：它解决的问题是真的

GraphRAG 的思路是不直接对原文做向量检索：先用 LLM 把文本抽成实体和关系建成图，检索时把向量、图遍历和社区摘要融合起来。有三类问题，它确实碾压纯向量检索：

• “腾讯投资了哪些公司？”——实体关系查询。向量检索只能找到“长得像“的段落，而投资关系分散在二十年的公告和附注里，语义匹配拼不出一张完整清单。
• “游戏毛利下降和行业政策收紧有因果吗？”——跨段落的多跳推理。证据散在管理层讨论、行业动态、财务附注三处，要跳着串起来。
• “跟腾讯业务最类似的公司有哪些？”——基于关系结构的相似，不是语义相似。两家公司文本描述可能毫不相像，但在图上是邻居。

还有一个容易被忽略的能力：全局摘要。社区检测把图分成簇，预先给每簇生成摘要，“这批公司整体的战略重心在哪“这种宏观问题，不用遍历全部 chunk 就能答。

所以我的立场不是“GraphRAG 不行“。是它的甜蜜点比宣传窄，门票比宣传贵。

二、四本账：建图、更新、查询、出错

门票多少钱，拆成四笔算。

第一笔，建图账。 从财报抽实体和关系，听起来是 LLM 的强项，做起来到处是坑。一份 100 页的财报，按微软 GraphRAG 的标准流程，抽实体关系要几十到上百次 LLM 调用。调用量还只是问题的一半，准确率是另一半：“腾讯投资了微信“不是偶然口误，“投资“和“拥有“在 LLM 的关系抽取里经常混淆。实体消歧更要命——同一份港股中报里，“騰訊”“Tencent”“本公司”“集團“指的是同一个东西，LLM 不保证每次都认出来；认不出来，图就裂成几个互不相通的碎片。这些都要额外的规则、人工和调用去补。【待补：若有自己跑微软 GraphRAG 全流程的真实耗时/费用记录，补在此处替换估算口径】

第二笔，更新账。 第 16 篇讲运维时说过，知识库是活的。向量库更新很简单：新文档单独走一遍管线入库。图不是这么回事——图谱里的关系高度互联，新财报一发，不是一个实体加几条边的事，是一个实体变了牵连一片：持股比例变了、并表范围变了、高管换了，每个变动都要沿边扩散检查。500 家公司 10 年的年报就是 5000 份 PDF，建出来几十万实体、上百万条关系，每个财报季都是一次图手术。

第三笔，查询账。 GraphRAG 的一次查询是向量检索加图遍历取邻居再加融合，延迟通常是纯向量检索的 3–5 倍。批量分析无所谓，但交互式问答有硬约束——我自己用的场景，超过 2 秒就能明显感到等待。为八成不需要图的问题付 3–5 倍延迟，怎么算都不划算。

第四笔，出错账。 这笔最容易被低估。向量检索错了，大不了是“没帮助“，LLM 拿到不相关的 chunk，最多答得空泛。图谱抽错了是另一回事：系统会拿着一条错误的边理直气壮地推理。“腾讯投资了微信“进图之后，所有沿这条边走出来的答案都带着这个错误。在错的图上推理，比不推理更糟——错得还特别像那么回事。

三、拿自己的数据算一遍：500 家为什么不成立

四本账还是抽象的，落到我自己的场景算一遍。我的目标库是 500 家上市公司、20 年财报：

• 500 家 × 20 年 × 每年 2 份（年报加中报）× 约 150 页 ≈ 2 万份 PDF、300 万页；
• 按每页 500 tokens 估，原始文本约 15 亿 tokens。

再按微软 GraphRAG 的完整流程（实体抽取、关系抽取、社区摘要）分项估建图成本：

前提必须交代清楚：这是按 GPT-4 级别模型的单价、每页 500 tokens、含社区摘要的完整流程算出来的量级，是会过期的单价估算，不是报价【待核实：发布前按当时模型定价复核】。其实哪怕砍一个数量级，结论也不变——因为真正不成立的不是钱，是两个结构性错配。

错配一，实体爆炸。500 家公司叠加，每家有历史更名（Facebook 改 Meta 那种）、时间化实体（“腾讯 2024 年收入“算属性还是独立实体？）、业务线、高管、供应商、客户、关联方，实体总量千万级起步。更要命的是 schema 不统一：500 家公司的财报格式、术语、会计政策全不一样，而知识图谱最怕的就是这个。

错配二，时间在图里没有好位置。这是图数据库的经典难题，三种方案各有死法：

方案 A：时间当属性  腾讯 {收入: 3200亿, 时间: 2024H1}
  → 查"近5年收入趋势"要逐节点扫属性，图遍历的优势没了
方案 B：时间当节点  (腾讯)-[2024年收入]->(3200亿)
  → 每个指标每年都是独立边，边数爆炸
方案 C：按时间切片，每年一个子图
  → 跨时间查询要 join N 个子图

而财报查询的主力恰恰是时序——“近五年收入趋势”“毛利率哪年开始降”。图擅长关系网络，不擅长时序演变。所以这笔账算下来，我的结论很直接：500 家 × 20 年是时序 OLAP 问题，不是图问题。这类数据的正经归宿是结构化数据库加 SQL，外面再套一层向量检索处理非结构化论述——第 11 篇讲多市场分层存储时就是这个思路，分层混合架构这里只提一句，不展开。

四、镜头拉近：单家公司 20 年，成立了吗

不做 500 家，只做腾讯一家 20 年呢？

先算规模：2004 年上市到现在约 40 份 PDF、8000 页上下、400 万 tokens。这个量级建图成本完全可以接受，“能不能“的问题解决了。但“值不值“没有。

把单公司财报的查询按类型过一遍，我的估算是大约八成落在两类：时序趋势（“近十年收入走势”）和精确数值（“2024 年游戏占比多少”）。这两类都是 SQL 和结构化数据的强项，GraphRAG 不但没优势，反而更慢。八成是估算口径，不同用户的查询分布会不一样，但方向我很有把握。刨掉这些，GraphRAG 真正占优的子集只剩三块：

• 投资并购版图。腾讯的投资轨迹本身就有网络结构：早期投游戏（Riot、Supercell），中期投电商和本地生活（京东、拼多多、美团），近期转向 AI（Moonshot、MiniMax）。“投资风格经历了什么转变“这种问题，图答得比向量好。
• 关联交易与并表范围。哪些子公司并表、哪些按联营合营处理、并表策略变化对报表有什么影响。
• 业务重组历史。业务分部从“互联网增值服务/网络广告“到“游戏/社交网络/广告/金融科技“的划分变迁，背后是战略调整。

所以单公司的结论是：可做，但不建议全量做。结构化数据为主，覆盖那八成查询；只在投资、并购、关联交易这些真有网络结构的子集上，局部用图。

五、如果那 20% 真的成立：三条路和一条 MVP 路径

劝退不是堵死。如果你把自己的查询分布盘过一遍，发现关系类问题真的成立、真的高频，有三条路，按工程务实度排：

第一条，轻量实体层，我最推荐。 不建完整知识图谱，用规则加 metadata 抽一张实体关系表——谁投了谁、比例多少、什么时候投的。检索时这张表只做精确查询，复杂推理交给 LLM。工程成本最低，和现有向量库是加法关系，不是重构。

第二条，按需建子图。 不建全图，查询来了只对涉及的实体现场抽关系、建局部子图。省掉全图的构建和维护，代价是每次查询多花几次 LLM 调用、延迟上升。适合关系查询占比低但不能没有的场景。

第三条，全量 GraphRAG。 微软全家桶开箱即用，实体抽取、社区检测、分层摘要全包。它适合快速实验、验证想法，不适合当生产默认项：资源消耗大，中文支持也一般【待核实：“中文支持一般“基于 2024–2025 年的版本状态，发布前复核现状】。

如果只是想先验证价值，我给一条 10 美元以内的 MVP 路径，拿“腾讯投资版图“这个单一主题切入：

1. 数据获取：从 IT桔子、Crunchbase 这类结构化数据源拿投资事件（时间、标的、轮次、金额），IT桔子有免费额度但有限【待核实：免费额度的具体政策，发布前核实】；不够用就手工整理 50–100 个重点事件。
2. LLM 清洗标准化：统一成 {date, target, amount, round, sector} 的结构，几美元的事。
3. 建图：Python 加 networkx，或者 Neo4j Desktop 免费版，零成本。
4. 分析：把子图和问题一起丢给 LLM，按次计费。

注意这条路是半自动的：结构化数据打底，LLM 只做清洗和补充。它的准确率反而高于让 LLM 从财报原文里猜——“腾讯 2014 年投资京东“在 IT桔子里是一条现成记录，在财报里是要 LLM 赌概率的一段文字。

最后两句实话。第一，这个流程里成本大头不是 API 费，是你的时间，方案该按自己的时间预算选。第二，领域先验大约能替掉 80% 的 LLM 调用：股票代码是天然唯一 ID，会计科目是天然 schema，披露格式是天然解析规则。这些先验是财报场景白送的，不用白不用。

收尾

回到开头那次上头。我不是要说 GraphRAG 不好——关系密集、多跳推理、全局摘要，这三个甜蜜点都是真的。是它的甜蜜点比宣传窄得多：至少在我的财报场景里，八成的问题做好分片、metadata 和检索优化就够了，第 4 到第 10 篇讲的全是这件事；剩下的，再谈图。

这个判断有三个前提：个人或小团队、财报场景、当前的建图成本。有专门图谱团队的、业务本身关系密集的（供应链、反欺诈、社交关系），不在此列。

第 17 篇聊 Agent，这篇聊 GraphRAG，两个边界判断用的是同一把尺子：不看热度，看约束。下一篇把这把尺子本身抽出来——从财报和电力两个完全不同的领域，归纳五个跨领域通用的设计模式。