普通 RAG 常把问题变成向量，再找几段相似文字。这对“某份制度里差旅上限是多少”很合适。问题若变成“这些项目反复延期都和哪些部门有关”，答案可能散在几十份周报里，单段相似度很难把关系接起来。
我顺着 Microsoft GraphRAG 的项目文档和入门说明查了一遍。它先把原始文档切成 TextUnit，从中抽取实体、关系和关键陈述，再把这些内容组成图。系统会用 Leiden 方法给图做分层聚类，并从下往上为每个社区生成摘要。
索引阶段已经用了不少模型
这些步骤意味着 GraphRAG 的准备工作比普通向量索引重。抽实体要调用模型，整理关系和生成社区摘要也要调用模型。官方入门页直接提醒，索引会消耗大量 LLM 资源，建议先用教程数据和便宜模型试验，再决定是否处理整套资料。
图也不会天然准确。公司简称可能指向两个实体，同一项目在不同年份可能换名，模型抽出的关系还可能漏掉时间条件。团队要抽查实体合并、关系方向和来源文本。若这些基础内容有误，后面的社区摘要会把错误带到更大的范围。
TextUnit 在这里还有一个实用作用，它给抽取结果保留细粒度引用。验收人员看到“项目甲依赖供应商乙”这条关系时，应能回到产生它的原始片段，核对文档写的是当前依赖、历史合作，还是一项尚未执行的计划。图上的一条边少了时间与状态，意思就可能完全变掉。
问题不同，查询方式也不同
GraphRAG 提供几种查询思路。Global Search 使用社区摘要，适合问整批资料有哪些主要主题。Local Search 从一个具体实体向邻居展开，适合查某个人、项目或组织和谁有关。DRIFT Search 在局部关系之外补入社区信息。Basic Search 则保留常规的向量检索。
这几种方式说明图检索没有必要接管所有问题。一个答案明确藏在单份制度里的问句，用普通检索通常更省。跨文档归纳、关系追踪和全局主题才值得支付建图与摘要的成本。
准备试用时，可以先选一小批关系密集的文档。列出十个普通 RAG 经常答不完整的问题，再分别跑基础检索、Local Search 和 Global Search。除了看答案，还要记录索引调用量、生成时间、实体重复率和每条结论能否回到原文。
先小范围跑一遍。若十个问题里只有一两个需要跨文档归纳，其余都能由常规检索解决，团队可以把 GraphRAG 留给那一小类问题，不必让全部查询承担同样的成本。
GraphRAG 给企业知识库增加了一种处理全局问题的办法。它需要更仔细的索引验收，也需要按数据变化重新考虑更新成本。小样本能证明关系图确实补上了原有检索的缺口，再扩大范围会稳得多。