GraphRAG 的适用边界：当“关系本身就是答案”时才值得上

向量 RAG 的失败模式已经很具体了，但很多团队仍然在用“调 chunk size、换 embedding 模型”来应对。问题在于，有一类查询的失败不是检索精度不够，而是架构层面看不到关系。

向量相似度找的是“听起来像 query”的 chunk，它没有“关系”这个概念。一份法规在第 4 节交叉引用了附录 C 的例外条款，这两节在 embedding 空间里可能相距很远，即使其中一节定义了另一节。把财务报告切成 512 Token 的窗口，表格和表头、脚注和它所限定的数字、多段答案和它们的上下文都被切断了。一个单元格里的数字脱离列标题就毫无意义，而 chunking 会把这种关系剥离掉。在 Diffbot 的 benchmark 上，没有知识图谱支持时，每个 query 涉及的实体数超过 5 个之后，准确率退化到 0%；在 Metrics & KPIs 和 Strategic Planning 两个类别里，传统向量 RAG 在 schema-bound query 上的准确率是零，不是低，是零。

GraphRAG 增加的不是“更好的检索”，而是一张关于事物如何彼此关联的地图。实体成为节点，关系成为边，多跳问题可以顺着连接走，而不是靠语义相似度碰运气。适合 GraphRAG 的问题形状很清晰：多跳关系查询、全局综合（“这 500 篇论文里有哪些主要主题”）、监管合规分析中交叉引用承担关键作用、以及任何“答案依赖于分散在不同文档中的多个事实的组合”的场景。

但它的成本也是真实的。最初的 Microsoft GraphRAG 方案索引一份典型企业语料库的代价不低，实体抽取和关系抽取的质量直接决定图谱的可用性，抽取错误会在多跳推理里被放大。更重要的是，不是所有业务都值得为关系付这个成本。员工手册问答、简单客服 QA、单点事实查询，继续用向量 RAG 是更合理的选择，它更便宜、更快、够用。

2026 年比较务实的架构判断不是“向量 vs 图”的二选一，而是按问题类型路由。简单事实查询走向量检索，需要多跳或全局综合时触发图谱路径，复杂查询再交给 Agentic 循环去规划检索策略。Adaptive RAG 的叙事之所以成立，前提是先把“什么问题需要什么检索结构”想清楚，而不是把所有查询都塞进同一条管线。