GraphRAG 是什么？什么时候需要知识图谱？
一句话回答
GraphRAG 泛指用知识图谱增强检索的 RAG，最有代表性的是微软开源的 GraphRAG：建索引时用大模型从文档中抽取实体和关系构建图，再对图做社区划分，并为每个社区预先生成摘要。它擅长普通向量 RAG 处理不好的两类问题：需要全局理解的问题（"这批文档的主要主题是什么"），和需要串起多个事实的多跳关系问题。代价是索引成本高、更新麻烦，大多数问答场景应该先把普通 RAG 做好。
详细解析
普通 RAG 处理不好的问题
- 全局问题："这 500 份用户访谈里，大家最常抱怨什么？"答案分散在所有文档里，和哪一块都不特别相似，检索出的前 k 块只覆盖很小一部分
- 多跳问题："负责支付网关的团队，上个季度处理过哪些线上事故？"要先从组织文档里查到负责的团队，再从事故报告里找这个团队处理的事故。每一块只包含其中一跳，问题整体和哪一块都不太像
GraphRAG 怎么做
建索引：
- 把文档切成文本块
- 用大模型从每一块中抽取实体（名称、类型、描述）和关系（谁和谁、什么关系）
- 合并不同块里的同一个实体，汇总描述，得到一张图
- 用 Leiden 算法做层级社区划分：联系紧密的实体分到同一个社区，大社区下面还有子社区
- 自底向上为每个社区生成摘要报告
抽取结果大致是这样的：
{
"entities": [
{ "name": "支付网关", "type": "系统", "description": "对接第三方支付渠道的内部服务" },
{ "name": "交易平台组", "type": "团队", "description": "负责支付网关的开发和运维" },
{ "name": "INC-0412", "type": "事故", "description": "支付回调超时，部分订单状态异常" }
],
"relationships": [
{ "source": "交易平台组", "target": "支付网关", "description": "负责维护" },
{ "source": "INC-0412", "target": "支付网关", "description": "发生在该系统" }
]
}查询时有两种主要方式：
- 全局搜索：把问题分别交给各个社区摘要，生成部分答案（map），再汇总成最终答案（reduce），适合"整体有哪些主题"这类问题
- 局部搜索：先找到和问题相关的实体，再沿着关系扩展到相邻的实体、关系、所属社区的摘要和原文片段，组成上下文，适合围绕具体实体的问题
和普通向量 RAG 对比
| 维度 | 向量 RAG | GraphRAG |
|---|---|---|
| 建索引 | 切块、计算 Embedding | 切块后用大模型抽取实体和关系、划分社区、生成摘要 |
| 索引成本 | 低 | 高，每一块都要调用大模型 |
| 更新 | 增删改对应的块即可 | 麻烦，实体合并、社区和摘要都可能受影响 |
| 擅长 | 答案集中在少数片段里的具体问题 | 全局总结类问题、跨文档的多跳关系问题 |
| 查询成本 | 低 | 全局搜索要处理大量社区摘要，较高 |
| 可解释性 | 引用原文片段 | 能展示实体和关系路径，也能回溯到原文 |
什么时候值得用
- 用户的问题主要是总结、归纳整个文档集合，而且这类问题很多
- 领域天然是关系型的：组织架构、供应链、代码依赖、法规之间的引用
- 预算允许大量的索引调用，文档更新也不频繁
更多时候可以先用轻量的做法：切块时顺便抽取实体作为元数据，检索时按实体过滤或扩展；关系数据本来就在数据库里（如组织架构、配置管理库），就让模型通过工具调用直接去查，不必再从文本里抽取一遍。微软 GraphRAG 的官方仓库也提醒，建索引可能是一项昂贵的操作。
面试官可能追问
从文本里抽取实体和关系，难点在哪？
一是实体对齐：同一个实体有不同叫法（全称、简称、英文名），不同的实体又可能同名，合并错了图就乱了。二是抽取质量：模型会漏掉关系，也会编造关系，需要预先定义实体和关系的类型，用领域样例调 Prompt。三是成本，文档越多，调用次数越多。
文档更新后怎么办？
新文档要抽取实体和关系并合并进图，受影响的社区要重新划分、重新生成摘要，比向量 RAG 改几个块复杂得多。规模大时常见的做法是定期批量重建。对时效性要求高、文档频繁变化的场景，不太适合 GraphRAG。
不用 GraphRAG，"总结全部文档"这类问题怎么处理？
可以对所有文档做 Map-Reduce 总结（见 长文档怎么处理），代价是每次提问都要处理全部内容；也可以预先生成层级摘要，比如 RAPTOR 的思路：把相似的块聚类并生成摘要，再对摘要继续聚类和总结，形成一棵树，查询时可以在不同层级检索。按时间、类别做统计的问题，用结构化数据和 SQL 回答更准。
已经有结构化的知识图谱，怎么和大模型结合？
让模型根据图的结构生成查询语句（如 Neo4j 的 Cypher），或者把常用的查询封装成工具，让模型通过工具调用去查，结果作为上下文再生成回答。和 Text-to-SQL 一样，要做语句校验、权限控制和结果数量限制（见 Text-to-SQL）。
易错点
- GraphRAG 不是把向量库换成图数据库，核心是用大模型从文本中抽取结构，并预先生成社区摘要
- 没确认失败的问题确实是关系类或全局类，就因为"多跳"听起来高级而上知识图谱
- 低估索引成本：每一块都要调用大模型，文档量大时要提前估算费用和耗时
AI 模拟面试官
用自己的话回答，AI 对照参考答案打分、指出遗漏，再追问，最多 3 轮
这道题你掌握了吗？
选一个最接近的状态，没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号，换设备也能看到。