Vector RAG 的边界
传统 Vector RAG 很适合回答局部问题：某个事实在哪段文档里，某个概念的定义是什么，某个条款怎么写。
但如果问题变成“这批新闻整体在讲什么趋势”“这组访谈里主要冲突是什么”“一个大语料库里的关键群体和关系是什么”，只找 top-k 相似片段就不够了。因为答案不在某几个 chunk 里，而分布在整个语料库的结构中。
GraphRAG 关注的就是这种全局 sense-making 问题。
它的流程
GraphRAG 大致分成几个步骤：
- 把原文档切成文本块；
- 用 LLM 抽取实体、关系和重要事实；
- 把实体和关系转成知识图谱；
- 对图做社区发现；
- 为不同层级社区生成摘要；
- 查询时让社区摘要先生成局部回答，再 reduce 成全局回答。
我觉得最关键的是社区摘要。它不是等用户提问时才从原文里临时找，而是提前为语料库构建一层“全局记忆”。用户问全局问题时，系统不是在原始 chunk 里乱捞，而是在这些社区报告里组织答案。
和普通知识图谱 RAG 的区别
GraphRAG 不只是“把图结构塞进 prompt”。它关心图的模块性：实体之间会形成关系紧密的社区，社区又可以层层聚合。
这让它适合处理大规模语料的主题结构。低层社区保留细节，高层社区提供概览。查询时可以根据问题选择不同层级的摘要，在细节和覆盖面之间做取舍。
从工程角度看，这很像先离线做索引和摘要，再在线做 Map-Reduce。成本被前置了，但查询时能回答更全局的问题。
评估也换了问题
传统 QA benchmark 更关心事实检索对不对。GraphRAG 评估的是全局问题，很多时候没有标准答案。
论文使用 LLM as a Judge，按 Comprehensiveness、Diversity、Empowerment、Directness 等标准比较不同系统回答。这个设计不是完美的，judge 本身也会有偏差。但它至少承认了这类任务的答案不是一个字符串，而是一个帮助人理解语料库的解释。
我会怎么用它
如果是普通个人知识库，我不会一开始就上 GraphRAG。构图、社区发现、摘要维护都不便宜，也会引入抽取错误。
但如果目标是“读一批材料，看全局结构”，GraphRAG 就很有吸引力。比如分析一批会议纪要、一堆项目日志、新闻集合、访谈文本。它回答的不是“某句话在哪”，而是“这些材料整体说明了什么”。
更现实的做法可能是混合：先用 embedding 找到相关区域，再对局部子图或相关社区做摘要，而不是全量图索引一把梭。
小结
GraphRAG 的价值在于，把 RAG 的目标从局部命中扩展到全局理解。
它提醒我：不是所有问题都应该用 top-k chunk 回答。有些问题需要先理解语料库的结构，再组织答案。代价是系统更复杂、离线成本更高、评估更难。是否值得，要看你的问题是不是全局问题。