LLM Wiki / RAG
GraphRAG 的价值与边界：什么时候需要知识图谱
分析 GraphRAG 在全局总结、关系推理、多跳问答中的价值，以及成本、更新和抽取误差带来的边界。
GraphRAG 经常被误解为“比普通 RAG 更高级的版本”。更准确的说法是：GraphRAG 不是替代向量检索，而是补足普通 RAG 在全局理解、关系推理和跨文档综合上的短板。
使用前提
如果你的问题主要是单文档事实查询，GraphRAG 往往不是第一选择。只有当问题依赖实体关系、跨文档连接或全局主题结构时，它才值得引入。
普通 RAG 不擅长什么
普通向量 RAG 的基本假设是：答案存在于若干相似文本片段里。这个假设对 FAQ、政策条款、操作手册很有效，但对下面几类问题不稳定。
| 问题类型 | 示例 | 普通 RAG 的困难 |
|---|---|---|
| 全局总结 | 过去一年客户投诉的核心主题是什么？ | 相关证据分散在大量文档里，Top-K 容量不够。 |
| 关系推理 | 哪些系统依赖同一个上游服务？ | 需要显式连接实体和关系。 |
| 多跳问答 | A 项目风险会影响哪些团队？ | 需要沿关系链路展开。 |
| 群体结构 | 哪些问题形成了同一类风险社区？ | 需要社区发现或聚类。 |
GraphRAG 的典型链路
GraphRAG 的核心产物不是向量，而是结构：实体、关系、claim、社区、社区摘要。查询时可以使用不同模式：Global Search 面向全局主题，Local Search 面向具体实体邻域，DRIFT Search 在局部实体和社区上下文之间折中。
三种查询模式
| 模式 | 适合问题 | 不适合问题 |
|---|---|---|
| Global Search | 总结、归纳、趋势、跨文档主题 | 精确查某条政策。 |
| Local Search | 围绕某个实体查关系、事件、上下游 | 没有明确实体的问题。 |
| DRIFT Search | 既有实体，又需要社区背景的问题 | 简单事实查询。 |
成本和风险
GraphRAG 的复杂度主要出现在索引阶段。实体抽取、关系抽取、claim 抽取、社区发现和摘要生成都需要额外计算。更关键的是，抽取错误会进入图结构，并在查询时被放大。
| 风险 | 具体表现 | 缓解方式 |
|---|---|---|
| 抽取错误 | 实体合并错误、关系方向错误 | 实体规范化、人工抽样审查、置信度过滤。 |
| 更新复杂 | 文档频繁变化导致图结构过期 | 增量图更新、定期重建、版本化图谱。 |
| 成本偏高 | 索引阶段调用大量 LLM | 只对高价值语料建图，先做抽样验证。 |
| 可解释性不足 | 图查询路径复杂，难排查 | 记录实体、关系、社区摘要和查询路径。 |
决策清单
在上 GraphRAG 前，先回答这些问题：
- 用户问题是否经常需要跨文档综合？
- 答案是否依赖实体之间的关系，而不是单个段落？
- 是否有足够稳定的实体类型，比如人、团队、系统、项目、客户、风险？
- 是否能接受更高的索引成本和更新复杂度？
- 是否有评测集证明普通 RAG 在这些问题上确实失败？
推荐落地方式
不要一开始就把全部知识库图谱化。更稳的方式是选择一个高价值领域，比如事故复盘、客户投诉、系统依赖或投研资料，先做局部 GraphRAG。用同一批问题对比普通 RAG、Hybrid RAG 和 GraphRAG 的效果，再决定是否扩大范围。
GraphRAG 的价值不在“图”这个形式，而在它能让模型沿着结构化关系理解大规模语料。没有明确关系问题时，图只会增加复杂度。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。