GraphRAG vs. 向量 RAG：团队往往过晚才做的架构决策

大多数团队发现自己需要 GraphRAG 时往往已经晚了六个月——在他们已经向用户解释了为什么 AI 搞错了关系、为什么它混淆了两个具有相似嵌入（embeddings）的实体，或者为什么它言之凿凿地引用了一份与实际答案相矛盾的文档之后。Vector RAG 在其擅长的领域确实表现出色。问题在于，团队把它当成了全能选手，并在底层架构已经达到数学上限时，仍不断堆砌检索补丁。

截至 2025 年，只有不到 15% 的企业在生产环境中部署了基于图的检索。这并不是因为技术不成熟。而是因为纯向量 RAG 的失败信号非常微妙：系统在运行，LLM 在响应，只有经过仔细检查才会发现，检索到的上下文虽然看似合理，但却是错误的。

Vector RAG 的实际运作方式及其瓶颈

Vector RAG 将文档转换为高维嵌入，并在查询时通过最近邻相似度检索内容。对于语义搜索——“查找与此主题相关的文档”——它的效果非常好。模型能以关键词搜索无法企及的方式捕捉概念上的相似性。

但相似性并不等同于正确性，嵌入架构有着严苛的数学限制。一个 512 维的嵌入模型在超过 50 万份文档后性能会可靠地下降。即使是 4,096 维的模型，在 2.5 亿份文档时也会遇到扩展性问题。更多的数据并没有帮助——信息的瓶颈在于向量本身。你将文档的语义压缩成一个固定大小的数值，最终这种压缩会丢失关键的精度。

更深层次的问题在于结构：向量嵌入是孤立地表示文档的。当分块（chunks）被嵌入和索引时，跨文档的实体间关系就消失了。智能体可能会检索到分块 A（“公司 X 在 AI 基础设施上投入巨资”）和分块 B（“AI 基础设施面临显著的监管风险”），但永远无法揭示出 X 的具体投资产生了该具体风险这一联系。检索器返回了两份分别相关的文档；LLM 必须推断出其中的联系。有时它能做到，但通常做不到，更糟糕的是，它会编造出一个在语料库中并不存在的看似合理的联系。

四种查询模式比任何基准测试都能更快地揭露这一瓶颈：

精确标识符查询。 当你查询“错误 221”时，向量搜索可能会返回“错误 222”的文档——语义相近，但事实错误。嵌入将数值差异压缩成了噪声。

多约束查询。 “蓝色越野跑鞋，10 码，100 美元以下”会生成一个平均了这些约束的单一向量。如果红色的跑鞋在“越野跑”上匹配度高，检索器可能会返回 150 美元的红鞋。图遍历可以同时满足多个属性约束，而不会通过平均化抹消它们。

罕见术语和领域术语。 产品 SKU、法律代码、金融工具标识符——嵌入空间将这些压缩到附近概念的引力场中。知识图谱则将它们保留为独立的、可寻址的节点。

多跳关系查询。 “新规定 X 如何影响我们的供应链供应商 Y 的合规状况？”这需要从 规定 → 受影响的行业 → 特定供应商 → 供应商合规历史 进行遍历。无论采用何种分块策略，都无法通过语义相似性显现出这种关系。

GraphRAG 是如何工作的

GraphRAG 采取了不同的方法。它不嵌入文档块，而是从文本中提取实体和关系，并将它们组织成一个图——节点代表实体，边代表关系。在查询时，它将用户意图转化为图遍历操作，而不是相似度查找。

Microsoft 在 2024 年推出了具有分层架构的 GraphRAG：提取实体和关系，使用 Leiden 算法将它们聚类为社区，并生成每个社区的摘要。查询可以在两种模式下运行：全局搜索（综合社区摘要，适用于关于整个语料库的宽泛问题）或局部搜索（从特定实体节点展开，适用于关于命名实体的事实查找）。

实验结果令人瞩目。在企业基准测试中，GraphRAG 在多跳任务上的准确率达到 86%，而向量 RAG 的得分仅为 32%——差距高达 54 个百分点。在需要复杂聚合的模式绑定查询中，向量 RAG 的准确率降至 0%，而基于图的检索达到了 90%。当查询涉及 10 个或更多实体时，向量 RAG 的准确率降至零；GraphRAG 则保持在 70% 以上。

这些数字是真实的。但它们也是针对最坏情况挑选出来的。在简单的语义搜索——“查找讨论主题 X 的文档”——中，向量 RAG 和 GraphRAG 表现相当，而图结构增加了开销却没带来收益。架构决策不在于“哪个更好”，而在于“哪个更适合你的查询分布”。

那些预示你已经超出向量搜索能力的查询模式

在投入图谱基础设施之前，你需要了解实际用户是否正在运行能从中受益的查询。请直接衡量这一点。

从生产日志中构建一个包含 50–100 个代表真实用户意图的评估集，并包含预期答案。针对当前的检索系统运行 recall@k 和 precision@k。当精心挑选的关键评估集的 recall@k 降至 70% 以下时，检索就是你的瓶颈 —— 而不是 LLM，也不是你的提示词 (prompts)。

需要留意的具体信号包括：

• 涉及 3 个以上命名实体的查询，且需要推理它们之间的关系
• 时间索引的关系查询（“2024 年之后 X 和 Y 之间的合同发生了什么变化？”）
• 矛盾检测（“我们的文档在这一点上是否自相矛盾？”）
• 影响链查询（“此 API 更改会影响哪些下游系统？”）
• 比较关系查询（“在这一规定上，公司 A 的方法与公司 B 相比如何？”）

如果这些模式频繁出现在你的评估集中，且你的召回率表现不佳，那么向量架构就不再合适。如果你的查询主要是“总结关于主题 X 的相关部分”，那你可能根本不需要图谱。

迁移路径：不要推倒重来

2025 年从业者的共识很明确：不要从头开始重建。成功的迁移是在现有向量基础设施之上叠加图谱功能，而不是取代它。

阶段 1：先进行埋点。 在更改架构之前，添加适当的可观测性。按查询类型追踪 recall@k 和 precision@k。记录 LLM 实际使用了哪些检索结果，忽略了哪些。确定失败发生的环节 —— 73% 的 RAG 系统失败发生在检索阶段，而不是生成阶段。你无法修复无法衡量的东西。

阶段 2：混合基准。 在引入图谱之前，杠杆率最高的步骤是结合你已经拥有的资源。在向量检索的同时加入 BM25 关键词搜索。添加一个交叉编码器 (cross-encoder) 重排序器，对合并后的候选结果进行重新评分。这种三层方法（向量 + BM25 + 重排序）在大多数企业语料库上能产生 15–25% 的准确度提升，且无需图谱基础设施。许多团队止步于此并发现这已足够。

阶段 3：选择性图谱增强。 如果阶段 2 对你的多跳查询 (multi-hop queries) 仍然不够，请选择性地添加基于图谱的上下文富化。其模式是：使用向量搜索识别前 K 个候选文档，然后使用图谱遍历利用相关的实体和关系来富化这些候选文档。对于复杂查询，这种“向量优先、图谱富化”的混合模式表现优于单一方法，同时能让图谱基础设施避开简单语义查找的热路径 (hot path)。

Neo4j 等工具在统一的后端同时支持向量索引和属性图遍历。LlamaIndex 的 PropertyGraph 抽象和 LangChain 的图集成使实现难度变得可控。如果你选择了正确的后端，就不内需要在向量存储之外再单独维护一个图数据库。

阶段 4：在有必要时采用完整的 GraphRAG。 将完整的层次化群落检测 (hierarchical community-detection) 方法留给那些需要对整个文档集进行全局综合的语料库。微软最初的方法对典型的企业语料库进行索引的成本为 20–500 美元。微软在 2025 年 6 月发布的 LazyGraphRAG 变体将此成本降至 5 美元以下，方法是将群落摘要推迟到查询时进行 —— 代价是每次查询增加 2–8 秒的延迟。

构建图谱：隐藏的复杂性

知识图谱的构建是大多数团队低估工作量的地方。提取流水线有三个阶段，每个阶段都有其失败模式。

实体提取 识别文本中的命名实体：人名、组织、产品、法规、日期。现代方法使用针对你的领域微调过的预训练 NER 模型。挑战在于特定领域的实体 —— 产品 SKU、内部项目代号、自定义标识符 —— 这些是通用模型会遗漏的。基于 LLM 的提取能捕获更多内容，但成本是运行专门 NER 模型的 10–50 倍。

关系提取 识别实体之间的联系：“公司 X 收购了公司 Y”，“法规 A 管理活动 B”，“系统 C 依赖系统 D”。这一步的质量决定了你的图谱是能实现多跳推理，还是产生一堆断连的节点集合。使用 spaCy 等库的依赖解析 (dependency-parsing) 方法既便宜又快速；基于 LLM 的三元组提取在处理复杂句子时更准确，但在大规模应用时成本昂贵。

图谱组装 合并整个语料库中的提取结果，处理实体去重（“Apple” = “Apple Inc.” = “AAPL”），并建立使遍历变得有用的连接性。这通常比提取本身的工作量更大。如果没有规范的去重，你会得到一个碎片化的图谱，同一个现实世界的实体会以几十个断连节点的形式出现。

对初创团队的实用建议：使用基于 spaCy 的依赖解析提取来完成大部分工作，仅在遇到模棱两可的多实体句子时才回退到 LLM 提取，并为去重规则预留大量时间。图谱的效用完全取决于其连接性。

当 GraphRAG 带来负面影响时

准确率提升的数据是真实的。失败模式也同样真实。

过度索引的图会产生噪音。 如果你的提取流水线对所有内容进行处理且不进行任何过滤，图中就会充满低质量的关系，从而创建虚假的遍历路径。一个在提及中顺带出现的实体，会被连接到与语料库结构核心实体相同的聚类中。由于错误边的成倍增加，图遍历会放大这种噪音。

原始的 Cypher 查询速度缓慢。 在没有精心查询设计的情况下，大型图上的图遍历可能需要数秒时间。使用 HNSW 的向量搜索可以在毫秒内返回结果。如果你将所有查询都通过图遍历进行路由，你将会遇到仅使用向量搜索时从未出现过的延迟问题。

GraphRAG 在简单语义搜索上表现不佳。 对于向量 RAG 能够很好处理的查询（例如“查找关于主题 X 的文档”），增加图遍历会增加延迟，并可能因添加了边缘相关的上下文而损害精确度。决定何时使用图增强还是仅向量检索的查询路由逻辑，要做到准确并不容易。

社区重新计算是有代价的。 随着你的语料库的增长和变化，实现全局搜索的分层聚类必须进行部分或全部重新计算。对节点和边的增量更新是 O(1)；但使社区摘要失效并重新生成则不然。这种运维成本在初始部署期间往往是不可见的。

决策框架

GraphRAG 是正确的架构投资，当：

• 你的评估集在具有代表性的多跳（multi-hop）查询上显示的 recall@k 低于 60%
• 你的领域根本上涉及关系链：供应链分析、法律条款依赖、组织层级、医学共病、金融工具关系
• 你的语料库很大（100 万份以上文档）且呈增量更新而非批量更新
• 用户经常提出跨越多个文档的综合性问题，而非关于特定主题的检索问题

仅向量 RAG 就足够了，当：

• 查询主要是语义性的（“查找关于主题 X 的相关章节”）
• 你的语料库是批量更新的，且重新嵌入（re-embedding）是可行的
• 单跳事实查找的可接受准确率在 70% 以上
• 延迟要求严格（检索时间小于 100 毫秒）

混合方法——即向量 + BM25 + 重排序器（reranker），并针对已知的多跳查询模式进行选择性的图增强——是大多数生产系统的正确起点。先发布基准方案，对其进行适当的检测（instrument），识别失败类别，并且只有在测量结果显示检索失败是由于结构性原因而非语义原因时，才增加图基础设施。

现在的成本曲线

在 2024 年导致许多 GraphRAG 项目流产的阻碍是索引成本。微软最初的方法在索引大型企业语料库时耗资 33,000 美元或更多。那个数字在当时是准确的，并且立即让 GraphRAG 对大多数团队来说变得不切实际。

成本曲线已经改变。LazyGraphRAG 通过将社区摘要推迟到查询时间，以每个语料库不到 5 美元的成本实现了相当的质量。来自俄亥俄州立大学（OSU）NLP 小组的 HippoRAG，其多跳推理准确率的实现成本比分层社区方法低 10 到 30 倍。PathRAG 通过有原则的图路径剪枝将上下文窗口使用量减少了 44%，从而降低了延迟和 Token 成本。OG-RAG 增加了本体落地（ontology grounding），在无需完整索引流水线的情况下减少了 40% 的幻觉。

在 2024 年放弃 GraphRAG 的团队应该重新评估其经济性。该架构已不再是十二个月前的那个系统了。

你本周应该进行的诊断

如果你拥有一个生产环境中的 RAG 系统，但还没有将检索性能与生成性能分开测量，那么这就是你可以做的杠杆率最高的事情。从你的日志中抽取 100 个用户参与过或投诉过的查询。标注预期答案。运行 k=5 和 k=10 的 recall@k。将查询按类型分类——单实体查找、多实体综合、关系链、对比分析。

当召回率高于 80% 时，你的检索是健康的。当它降至 60% 以下时，你就找到了一个失败类别。该失败类别会告诉你添加 BM25 是否会有所帮助（针对关键字密集的查询），重排序器是否有帮助（针对顶层结果并非最有用的语义搜索），或者是否需要图增强（针对结构化关系查询）。

大多数团队在进行这项练习时会发现，图架构对于其查询分布中的特定部分是必要的，而不是全部。这就是正确答案。架构决策不是非黑即白的。关键在于了解哪些查询需要图语义，并进行相应的路由。

现在做出这一决策的团队，在花费一年时间向用户解释检索失败之前，将能够避免付出这一教训中最昂贵的代价。