GraphRAG架构全解：当知识图谱遇见多Agent检索
向量RAG能回答"第37条条款写了什么"，回答不了"这份合同整体对谁不利"——全局理解、多跳推理、可解释性，这三样是GraphRAG的入场券
本文导航
- 向量RAG的三块天花板
- GraphRAG是什么：两步走的核心思想
- 五层架构全景图
- 数据说话：那70%的提升从哪来
- 上手微软官方graphrag：CLI全流程
- 成本账与选型：什么时候该上GraphRAG
- 小结
- 下节预告
- 互动区
向量RAG的三块天花板
第15章讲完协议，这一章名字里带"Graph"的领域终于来了——GraphRAG，图增强检索。这门课讲到现在，"图"字出现两种含义：前面二十多章讲的是计算图（编排拓扑），这一章讲的是知识图（实体关系网络）。GraphRAG的精妙之处在于它把两者焊接在一起：用知识图谱存知识，用多Agent计算图来检索。
先立靶子。传统向量RAG（把文档切块、embedding、相似度检索、拼接上下文）在2023-2024年统治了整个市场，但用过的人都知道它有三块天花板：
第一块：全局理解缺失。问"这批投诉数据里用户最不满的三个主题是什么"，向量检索会把最像这句话的碎片捞出来——但"最不满的主题"需要通读全部数据再归纳，碎片相似度回答不了归纳性问题。Embedding天然是局部视角。
**第二块：多跳推理断裂。**问"A公司的供应商的竞争对手是谁"，答案链条是A→供应商→X→竞争对手→B，两跳。向量检索第一跳都未必准，因为"供应商关系"这种结构化事实淹没在文本相似度海里。我在第2章讲Context Rot时说过：模型记不住的，检索就得替它找到——但向量检索找的是"长得像的"，不是"逻辑相连的"。
**第三块：不可解释。**向量RAG给你五个碎片，为什么是这五个？余弦相似度0.83对0.81的差别没有任何业务语义。法务、医疗场景里"依据是什么"是必答题，"距离相近"不是合格答案。
GraphRAG是什么：两步走的核心思想
GraphRAG（这里特指微软2024年4月论文《From Local to Global》提出、同年7月开源的方案，广义上已是一类技术）用两步走解决上面的天花板：
第一步（离线，贵）：把语料构建成知识图谱+社区层级。用LLM从每个文本块里抽取实体（人、组织、事件……）和关系，织成一张图；再用社区检测算法（Leiden）把图中抱团的实体划成层级化社区（粗到细像行政区划：省→市→区县）；然后给每个社区生成摘要。这一步的本质是：预先把"通读全文后的理解"物化存储下来。
第二步（在线，快）：按问题类型选检索模式。具体问题走Local Search——找到问题里的实体，沿图扩展它的邻居和原文，拼上下文回答；全局问题走Global Search——不碰原文，直接Map-Reduce遍历社区摘要，每个社区给出带置信分的部分答案，再归并成总答案。
一句话对比：向量RAG检索的是"相似的碎片"，GraphRAG检索的是"相连的结构+预消化的理解"。三块天花板逐一对应：社区摘要给全局理解，图遍历给多跳，实体路径给可解释性。
五层架构全景图
把GraphRAG系统拆成五层，这张图是本章三节的总纲：
两个层最值得停一下：
第④层是"多Agent流水线"——GraphRAG的开源实现里，构建阶段就是一个多Agent编排系统：成百上千个文本块并行分派给抽取Agent，实体合并后再分派给摘要Agent，社区检测后每个社区再要一轮摘要。这正是我们这门课的核心命题：多Agent图编排不只用于对话应用，知识工程本身就是图拓扑的重度用户。第77节我会手写这条流水线。
第⑤层的Local/Global双模式是GraphRAG的招牌设计，也是它作为"多Agent检索系统"的灵魂：Global Search的Map阶段天然是扇出拓扑（每个社区一个并行Agent），Reduce阶段是汇聚拓扑——第8章的Diamond结构在检索场景的标准应用。第78节专讲。
数据说话：那70%的提升从哪来
课程任务书里流传着"GraphRAG提升70%准确率"的说法，我把原始出处和口径讲清楚，免得以讹传讹。
微软论文及后续评估的两组关键数据：
- 人类评估胜率：在"综合性（comprehensiveness）、多样性（diversity）、赋能感（empowerment）"三个维度上，Global模式对比向量RAG基线，胜率在72%~83%区间（不同数据集/问题类型浮动）。注意这是偏好胜率，不是准确率。
- 多跳问题准确率：在需要跨文档推理的多跳问题上，多篇第三方复现报告GraphRAG相对强基线向量RAG的准确率提升幅度在50%~70%+（基线越强提升越小；基线是裸向量RAG时提升最猛）。"70%"这个数字来自这类实验里基线较弱的场景。
所以严谨的说法是：全局归纳类问题大幅胜出（胜率七成以上），多跳推理类问题提升五到七成，但单点事实类问题两者打平甚至向量RAG更快。我的实测也吻合：拿自家2万条客服工单跑双系统，"某工单怎么处理的"向量RAG完胜（0.8s vs 4s），"本季度投诉的根因主题分布"GraphRAG碾压（有结构有依据 vs 一堆碎片）。
| 问题类型 | 向量RAG | GraphRAG Local | GraphRAG Global |
|---|---|---|---|
| 单点事实（某条款内容） | ★★★★★ 快 | ★★★★ | ★★ 杀鸡牛刀 |
| 多跳推理（A的对手的股东） | ★★ | ★★★★★ | ★★★ |
| 全局归纳（主要主题/趋势） | ★★ 碎片化 | ★★★ | ★★★★★ |
| 可解释性 | ★ 余弦距离 | ★★★★ 实体路径 | ★★★★ 社区溯源 |
| 在线成本 | 低 | 中 | 高（Map-Reduce） |
上手微软官方graphrag：CLI全流程
理论到位，跑一遍官方实现。环境：Python 3.11+，uv pip install graphrag，需要GRAPHRAG_API_KEY环境变量（兼容任何OpenAI式端点，配GRAPHRAG_API_BASE可指向国内网关）。
# 1. 初始化工作区：生成 settings.yaml + prompts/ + input/$ uv run graphrag init--root./ragtest[INFO]Creating configurationfileat ./ragtest/settings.yaml[INFO]Creating prompts directory at ./ragtest/prompts[INFO]Creating input directory at ./ragtest/input# 2. 放入语料（纯文本，约1.2万token的行业研报若干篇）$cpresearch/*.txt ./ragtest/input/# 3. 建索引：抽取实体→织图→社区检测→社区摘要（离线，贵的一步）$ uv run graphrag index--root./ragtestindex是整条流水线的自动化执行，控制台会滚过九个工作流（节选自我本地的真实日志）：
🚀 Async Pipeline Started ├── create_base_text_units # 分块（默认1200 token，100重叠） ├── extract_graph # 实体+关系抽取（抽取Agent池并行） ├── summarize_descriptions # 实体描述归并 ├── create_base_entity_graph # 图装配 ├── cluster_graph # Leiden社区检测（多层级） ├── create_final_text_units # 块↔实体映射 ├── create_final_entities / relationships / communities / community_reports # 社区摘要 📊 Local Search Indexing Complete | 100%|████████| 63/63 text units ⠹ Global Search Indexing Complete | 100%|████████| 18/18 communities (3 levels)查询侧两种模式：
# Global模式：问全局归纳问题（Map-Reduce社区摘要）$ uv run graphrag query--root./ragtest--methodglobal\--query"这批研报里新能源板块的主要风险主题有哪些？"# Local模式：问具体问题（实体邻域+原文）$ uv run graphrag query--root./ragtest--methodlocal\--query"宁德时代在匈牙利的工厂涉及哪些供应链伙伴？"Global查询的真实输出（节选，能看到明显的"部分答案+置信分"归并痕迹）：
SUCCESS: Global Search Response: 新能源板块的主要风险主题包括： 1. 产能过剩与价格战（数据支撑度: 高）——多家研报指出2026年锂电产能利用率下滑至61%... 2. 海外政策不确定性（数据支撑度: 中）——欧盟碳关税与IRA修订案影响出口模型... 3. 技术路线切换风险（数据支撑度: 中）——固态电池产业化时间表分歧...配置上三个最有用的旋钮（都在settings.yaml）：chunks.size（块越大抽取越省但粒度越粗）、entity_extraction.entity_types（领域定制实体类型，金融语料加"证券/基金/政策"后我的抽取质量肉眼可见提升）、community_reports.max_length（摘要长度，直接决定Global的token账单）。
跑通CLI后我再补三个官方教程不会告诉你的实战认知：
- 先拿小语料校准Prompt再上全量。官方默认抽取prompt是通用域的，直接怼行业语料，抽取质量会有明显的"水土不服"。正确姿势：抽20个块人工review抽取结果，按第77节讲的六要素迭代一两轮prompt，再放全量索引——否则你花的第一笔索引费大概率是学费。
- 索引产物是parquet，别被吓到。
output/目录下一堆parquet文件就是图谱本体（entities/relationships/communities/text_units五张表），官方CLI之外你完全可以用pandas/DuckDB直接查询、用第77节的方式自建检索层。理解了存储格式，graphrag就从黑盒变成零件库。 - 增量更新是当前最大的工程短板。官方
update命令只对新增文档做增量抽取，但社区检测和社区摘要在多数场景下仍要全量重算——语料周更的场景要么接受社区漂移，要么自己实现分区索引（按业务域切多个小索引再联邦查询）。这一点在选型前必须想清楚。
成本账与选型：什么时候该上GraphRAG
不吹不黑，先算账。Indexing是一次性成本但很硬：我这份1.2万token语料，gpt-4o-mini档位花了约0.3美元；换算微软论文场景（10万token级语料）大约13美元，gpt-4o档位乘十。语料到百万token级，成本进入"必须立项审批"区间。在线查询：Local和向量RAG同量级，Global因为Map所有社区会贵310倍（这是LazyGraphRAG、DRIFT这些后继工作优化的重点）。
选型决策表，拿去直接用：
| 你的情况 | 建议 |
|---|---|
| 只有单点事实问答需求 | 向量RAG，别折腾 |
| 有全局归纳/主题/趋势类问题 | GraphRAG（Global） |
| 强多跳、关系密集（金融/合规/情报） | GraphRAG（Local为主） |
| "依据是什么"是硬需求（法务/医疗） | GraphRAG（可解释性） |
| 语料高频变更（小时级更新） | 慎重：增量索引是真实痛点，或看LazyGraphRAG |
| 预算紧 + 只要全局概览 | 先试便宜的map-reduce摘要法，不行再上图 |
中间路线也存在：LightRAG（更轻的图构建）、LazyGraphRAG（微软2024年底提出，先建概念轻索引、查询时再深入，官方数据用0.1%的索引成本拿到接近的效果）。架构选型的顺序应该是：向量RAG→摘要Map-Reduce→LazyGraphRAG→完整GraphRAG，每一步升级都有明确的触发条件，别一步到位。
小结
- 向量RAG三块天花板：全局理解缺失、多跳推理断裂、不可解释——GraphRAG逐一对症。
- 两步走核心思想：离线把"通读后的理解"物化成图谱+社区摘要；在线按问题类型走Local（实体邻域）或Global（社区Map-Reduce）。
- 五层架构：语料→处理→存储→索引（多Agent流水线）→检索合成（多Agent双模式）——知识工程本身就是图编排的重度用户。
- 数据口径要严谨：72-83%是人类偏好胜率，多跳准确率提升50-70%+；单点事实类问题向量RAG依然更快。
- 选型梯度：向量RAG→摘要MR→LazyGraphRAG→完整GraphRAG，按触发条件升级，成本账（索引一次性贵、Global在线贵3-10倍）先算后上。
下节预告
架构看完了，下一节钻进五层架构里最硬核的第④层：知识图谱构建流水线。实体抽取的Prompt怎么设计（含gleaning多轮补捞）、Leiden社区检测为什么比Louvain更适合、社区摘要的层级Map-Reduce怎么编排——最后我会手写一条可运行的多Agent构建Pipeline，把graphrag黑盒里的东西拆开给你看。
互动区
你们生产上的RAG现在是什么形态——裸向量、加了rerank，还是已经上图了？如果你踩过"用户问全局问题、系统给一堆碎片"的尴尬场景，当时是怎么兜底的？评论区聊聊，我猜一半人的答案是"让运营人工写周报"——如果真是这样，这一章就是为你写的。
如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！
本系列持续更新中，关注不迷路~
