GraphRAG 为什么要构建社区摘要，适合解决什么问题？

面试时怎么答

先讲它解决的不是普通相似问答，而是“跨很多实体和文档做全局归纳”。GraphRAG 抽取实体、关系和证据构图，做社区发现后为各层社区生成摘要，查询时再从相关社区取得全局上下文。

回答时也要克制：图抽取与摘要都会引入成本和错误，社区摘要不适合替代精确事实检索。若追问场景，可用趋势、关系网络和全库主题问题对比局部事实问答。

可以这样答：

GraphRAG 先从文档中抽取实体、关系和出处形成图，再做社区发现，并为不同层级的社区生成摘要。它适合回答“整个语料有哪些主要主题、群体如何关联”这类需要跨文档归纳的问题，普通向量检索往往只能拿到零散局部片段。代价是建图和摘要成本高，抽取错误还会传播，因此精确事实仍应回到原始证据核验。

核心回答

传统向量 RAG 擅长找与问题局部相似的片段，却很难仅靠少量 top_k 回答“整个语料的主要主题、变化趋势或共同模式是什么”这类全局问题。GraphRAG 先从文档中抽取实体及关系构建图，再对紧密关联的实体做分层社区划分，并预生成不同层级的社区摘要。查询全局问题时，它让多个社区摘要分别生成部分回答，再汇总成最终答案，使检索单元从局部文本块提升为覆盖一组相关实体的主题表示。

社区摘要是一种有损的、可分层检索的中间索引，不是原文事实本身。它能改善全局概览的覆盖与组织，但会增加离线抽取、聚类、摘要生成、增量更新和溯源成本，也会继承实体消歧及摘要幻觉。因此 GraphRAG 更适合全局意义建构，不应被描述为对所有点查问题都优于向量 RAG。

展开说明

原始 GraphRAG 全局搜索大致包含两阶段：

离线建图：把语料切成 Text Units，使用模型抽取实体、关系及相关描述，形成实体知识图谱。
社区发现：对图做层次化社区划分，使密切相关的实体聚集在一起；不同层级对应不同粒度的主题。
社区报告：为各社区生成带关键实体、关系和发现的摘要，作为可复用的索引产物。
Map 阶段：针对用户问题，从相关社区报告分别生成带评分的部分回答。
Reduce 阶段：在上下文预算内组合高价值部分回答，形成覆盖全局的最终答案。

它与“先向量检索几个 Chunk 再总结”的区别，在于社区报告在离线阶段跨文档聚合了图结构上的主题信息。代价是上游错误会传播：实体漏抽、同名实体误合并、错误关系和低质量社区摘要，都可能影响最终结论。

工程实践

设计时先按查询类型路由：精确事实、局部实体详情可走向量或关键词检索；跨文档主题、全局风险和语料概览再走社区摘要。建库要保存 Text Unit 到实体、关系、社区及报告的映射，使最终结论能回溯原文。更新语料时不能只追加向量，需要考虑受影响的实体消歧、边、社区结构和摘要重算；可按数据版本做增量更新并定期全量重建。评测除答案正确性外，还应检查主题覆盖、来源可追溯性、实体与关系准确率、建库成本和数据更新陈旧度。

常见追问

为什么全局问题不适合只用向量 Top-K？ 全局答案往往分散在大量片段中，少量与问题最相似的 Chunk 容易只覆盖局部；盲目增大 \(k\) 又会带来上下文预算和噪声问题。
社区层级越高越好吗？ 不是。高层社区覆盖广但细节少，低层社区更具体但可能遗漏全局结构；应按问题粒度和 Token 预算选择层级，必要时组合多个层级。
GraphRAG 能保证引用准确吗？ 不能。社区摘要经过抽取与生成，可能产生失真；必须保留从报告到实体、关系和原始 Text Unit 的溯源链，并在高风险答案中回查原文。
什么时候不值得使用 GraphRAG？ 语料规模小、查询主要是精确点查、关系结构不重要或数据高频变化时，建图与摘要维护成本可能超过收益，普通混合 RAG 往往更简单。

一句话复习

GraphRAG 用分层图社区摘要覆盖跨文档的全局主题，但它是成本更高且有损的索引，应与局部检索按查询类型组合。

参考资料

From Local to Global: A Graph RAG Approach to Query-Focused Summarization