图中先从原文建立实体关系，再形成社区报告；局部问题和全局问题使用的上下文并不相同。
把 RAG 里的向量库换成图数据库，就算 GraphRAG 吗？这个理解漏掉了更重要的环节：图是怎样从资料中建立的，图上信息怎样组织成可用上下文，以及问题为什么需要关系或全局概览。这里以原始 GraphRAG 研究及其开源项目思路为例，不把所有图检索方案都定义成同一个实现。
先判断问题需要哪种证据
“某个项目由谁负责”通常围绕特定实体，可以从相关段落与局部关系查起。“这批项目反复出现哪些协作瓶颈”则需要跨多个文档归纳，单纯挑几个向量最相似的片段，可能只覆盖局部热门内容。
图结构有机会把分散的实体和关系连接起来，社区报告则尝试把较大范围的关联信息预先组织成摘要。收益来自这种表示与问题的配合，不是“只要有边，回答就一定更全面”。简单事实题也未必需要完整建图。
建图不是无损搬运文本
典型过程会从原文提取实体、关系和相应描述，再识别联系紧密的群组，并为这些群组生成社区报告。名字相同的实体是否真是同一个对象，关系有没有明确证据，都会影响后续图结构。
如果抽取时把两个同名项目合并，之后的邻接关系就可能把两套事实串在一起。摘要再基于错误连接生成解释，问题会继续传播。图并不是天然真实的数据结构，节点和边来自模型或规则时，也需要保留证据与核验路径。
因此，索引阶段不只是把向量上传到另一种存储。它还涉及抽取、归并、聚类或社区组织、摘要，以及原始材料的关联。更新一份源文档后，哪些派生内容需要重建，也要进入维护设计。
局部查询围绕实体展开
在项目所描述的局部查询中，可以结合实体相关图信息与原文片段构建上下文。问题若涉及某个具体对象及其关联，这条路径有助于发现只看单个段落时遗漏的连接。
但不是沿边走得越远越好。扩展过多会带来无关实体和大量背景，也可能把间接关系误写成直接关系。应根据问题限制范围，并让最终结论能回到实际片段，而不是只引用一段已经压缩过多次的说明。
关系方向和限定条件也重要。“项目依赖某服务”不能自动反过来写成“该服务只服务这个项目”；图上有连接，也不意味着连接具有任意强度的因果含义。
全局查询重在组织整体信息
全局类问题可以利用社区报告生成分部分答案，再汇总形成全局回答。这更接近围绕问题的多层摘要，而不是每次从某个实体出发做固定深度遍历。具体搜索范围、报告选择和预算应看实现配置。
预生成报告把一部分工作提前到了索引阶段，因此查询时能使用已组织好的内容，但也要承担建索引和更新成本。不能只比较一次查询看起来花了多久，就忽略此前的抽取与摘要调用。
报告本身同样可能压缩掉重要例外。如果某个小群组的异常事实恰好决定答案，大群组摘要未必会保留它。全局概览与原文证据应配合使用，不能把概括性强理解成细节一定完整。
图检索和向量检索可以配合
两者不必非此即彼。向量检索可以帮助找到相关实体或文本，图可以扩展关系上下文，重排和摘要又可以控制最终信息量。选型应围绕实际问题，而不是追求索引组件数量更多。
如果数据本来缺少可靠实体关系，或者更新非常频繁，复杂建图链路可能不划算。反过来，跨文档关系明确、确实需要整体归纳时，可以准备带证据的问题集比较收益与成本，避免仅凭演示效果决定投入。
面试回答从数据流收束
可以依次说明原文到实体关系、关系到社区组织、社区到报告，再区分局部实体问题与全局总结问题。最后补上抽取误差、更新维护、上下文预算和证据回溯的限制，就比“图比向量更懂关系”完整得多。
若社区报告说多个团队都依赖某项流程，而原文只明确记录了其中一部分，你会把报告直接当事实，还是沿来源关系回查缺失的依据？