GraphRAG vs. Vector RAG：知识图谱何时优于向量嵌入

大多数团队在构建 RAG 流水线时都会选择向量嵌入（vector embeddings）。这是一个显而易见的默认选择：嵌入文档、嵌入查询、寻找最近邻，然后将结果输入给 LLM。在演示（demo）中它的表现还不错。但当部署到合规团队或科学文献语料库时，准确率就会断崖式下跌。不是逐渐下降，而是突然暴跌。在涉及五个或更多实体的查询中，向量 RAG 在企业分析基准测试中的准确率降至零。不是 50%，也不是 20%，而是零。

这不仅是一个配置问题，而是架构上的不匹配。向量检索将文档视为语义空间中的点。知识图谱（knowledge graphs）则将它们视为关系结构中的节点。当你的查询需要遍历关系——而不仅仅是寻找相似内容时，检索架构的拓扑结构（topology）决定了你是否能得到正确答案。

为什么向量嵌入在关系查询中会失效

基于嵌入检索的基本承诺是语义相似性等同于相关性。对于许多任务——客户支持、内容发现、FAQ 匹配——这一假设是成立的。你嵌入一个查询，找到附近的文档，LLM 从主题相关的切片（chunks）中合成一个连贯的答案。

当相关性取决于实体之间的明确关系，而非主题接近度时，失效模式就会出现。考虑一个合规性查询：“哪项法规定义了‘机密信息’，它如何与数据保护义务进行交叉引用，以及根据最近的修订案适用哪些例外情况？”向量 RAG 的应对方案是运行三个独立的搜索，并希望检索到的切片恰好涵盖这三个概念。它们通常做不到——因为分块（chunking）割裂了最初使这些关系清晰易读的叙事流。

分块是第一个问题。文档被分割成 100–200 字符的片段，失去了连接段落、章节和文档之间相关概念的“结缔组织”。针对这些片段进行 ANN（近似最近邻）搜索，会检索到语义相似的内容，但没有任何机制来追踪它们之间的逻辑链。

第二个问题是多义性。向量嵌入在上下文中表示含义，但这种上下文仅局限于切片内部。“Java”岛、“Java”编程语言和“Java”咖啡品牌在嵌入空间中会聚类到不同的地方——但如果没有周围的关系上下文，检索就是不可靠的。图节点将它们的关系作为显式边（edges）携带，因此连接到“运行时环境”和“Oracle”的节点中的“Java”是明确无误的。

第三个问题是大规模下的实体降级。随着查询复杂度的增加——更多的实体、更多的逻辑跳跃（logical hops）——向量检索的准确率呈单调下降。来自 Diffbot 的 KG-LM 评估基准发现，向量 RAG 在企业分析查询中的总体准确率约为 16.7%，而在需要跨指标、KPI 或战略规划实体进行聚合的问题上，准确率降至 0%。在同样的类别中，GraphRAG 的准确率保持在 56–80%。

图遍历如何处理多跳查询

图检索不是在近似相关性——而是在遍历相关性。该架构将实体存储为节点，将它们的关系存储为有类型的有向边。查询首先识别相关的入口节点，然后沿着边寻找连接的节点，再从这些节点继续沿着边寻找，从而构建一个捕捉问题周围关系邻域的子图（subgraph）。

对于上述合规性查询，路径是明确的：从“机密信息”概念节点开始 → 沿着“defined_in”边找到相关法规 → 遍历“cross_references”边找到数据保护条例 → 沿着“amended_by”边找到最近的修订。每一跳都是确定性的。结果不是一袋语义相似的切片，而是一个保留了答案逻辑结构的连通子图。

这在三类查询中最为关键：

引用和修订链。 法律和监管文档的定义在于它们对其他文档的引用。GDPR 引用成员国指令；指令引用执法决定；执法决定引用早期的裁决。向量检索可以找出单个文档，但无法重建整个链条。图遍历则原生支持这种追踪。

跨文档的实体消歧。 科学文献经常在不同的论文中对同一个概念使用不同的名称。知识图谱将这些解析为规范的实体节点，因此关于“CRISPR-Cas9 离靶效应”的查询可以找到相关的研究，无论它们使用哪种术语变体。

复杂的聚合查询。 “我们的哪些供应商也为我们的前三大竞争对手供货，其中哪些与我们上季度标记为合规审查的供应商重合？”此类查询需要同时遍历供应商-客户-竞争对手-风险的关系。向量检索根本无法表示这些关系。

在复杂的多跳任务中，GraphRAG 的准确率始终能达到 80–85%，而向量 RAG 则停留在 45–50%。在任何重视正确性的场景下，这都是一个显著的差距。

你实际承担的运维成本

准确率的差距伴随着相应的运维复杂性差距。这正是大多数团队低估其投入成本的地方。

索引 (Indexing)。 向量 RAG 需要进行一轮嵌入生成——对于常用模型，每个文档的成本大约为 0.001 美元。GraphRAG 需要基于 LLM 的实体和关系提取，历史成本为每百万 token 语料库 20–50 美元。对于 1000 万 token 的文档集，这是一笔可观的前期成本。最近关于延迟评估 (lazy evaluation) 和经典 NLP 预处理的研究已将索引成本降至接近于零，同时保留了大部分检索质量——Microsoft 的 LazyGraphRAG 以大约 0.1% 的全量提取成本实现了与 GraphRAG 相当的准确率。但基本问题仍然存在：你需要一套实体提取策略，而该策略存在失效模式。

实体提取的脆弱性。 基于 LLM 的提取器在典型的企业语料库中会遗漏 30–40% 的实体，或者产生错误的关系。名称冲突 (Name collision) 的杀伤力尤为巨大：如果你的提取器将“CEO John Smith”和“工程师 John Smith”合并为一个节点，那么后续涉及该节点的每一次查询都会被污染。这些错误会静默传播——直到一个高风险查询返回一个看似合理但错误的答案时，你才会发现它们。

Schema 维护。 知识图谱需要定义本体 (ontology)：存在哪些实体类型、哪些关系类型连接它们、每个实体上有哪些有效属性。演进这种 schema 是昂贵的。添加新的关系类型需要重新处理受影响的文档。在监管解读经常变化的医疗合规领域，schema 维护是一项持续的运维负担，而非一次性投资。

增量更新。 向量库的更新逻辑很清晰：对修改后的文档重新进行嵌入。图谱则需要维持整个关系结构的一致性。如果你使用像 Microsoft GraphRAG 这样的全局摘要方法，一个引入了连接到现有节点的新实体的新文档，可能需要重新计算社区层级。这使得实时更新变得困难。

查询延迟。 稠密子图上的图遍历平均耗时 200–300ms，而向量 ANN 搜索则低于 50ms。在具有复杂递归查询的十亿节点图谱上，遍历时间可能超过 500ms。对于大多数企业用例来说，这并非决定性障碍，但它将 GraphRAG 排除在对延迟敏感的路径之外，如自动补全或实时流媒体。

决策框架

向量检索与图检索之间的选择并非抽象地讨论谁更好，而是取决于你的查询模式是否需要关系遍历。

在以下情况下使用向量 RAG：

• 查询主要是语义性的（“寻找关于 X 的文档”）
• 速度是刚性约束（<50ms）
• 你的语料库是非结构化且异构的
• 你缺乏维护本体的 schema 设计能力
• 用例：客户支持、内容发现、聊天机器人、语义搜索

在以下情况下使用 GraphRAG：

• 查询需要显式的关系遍历（引用链、监管交叉引用、供应链路径）
• 需要多跳推理（3 个以上的逻辑步骤）
• 你的领域是关系密集型的：合规、法律、医疗、金融服务、科学文献
• 需要可解释性和审计追踪
• 正确性比延迟更重要

在以下情况下使用混合模式：

• 你需要通过广度召回（向量）配合关系验证（图）来获得高置信度的答案
• 你可以接受 150–200ms 的编排开销，以换取 15–25% 的准确率提升
• 你的系统同时服务于具有不同检索要求的多个用例

混合模式正成为企业系统中的生产环境默认配置。向量检索处理大规模语料库中的初始候选召回；图遍历则利用关系上下文对结果进行验证和丰富。其结果结合了 ANN 搜索的广度与确定性遍历的精度。

基准测试究竟说明了什么

关于性能数据的一个警告：该领域的基准测试方法论并不可靠。2025 年的一项元分析发现，当控制评估偏差——位置偏差、长度偏差、试验偏差——时，先前报告的 GraphRAG 性能增益被显著夸大了。LightRAG 在初步评估中对 naive RAG 的胜率为 72%；但在偏差修正后，naive RAG 的表现甚至略优于它。在特定数据集上使用受控方法评估时，现实世界的收益比营销宣传的要小——对于通用查询分布，通常低于 10%。

巨大的收益是真实的，但具有领域特定性。在合规和医疗领域，查询确实需要多跳遍历，有记录的改进可达 3–4 倍。在语义相似性能够捕获大部分相关信号的通用检索中，向量 RAG 具有竞争力，且运行成本显著降低。

这意味着在投入 GraphRAG 基础设施之前，你需要刻画你的查询分布。对生产系统进行几周的监测，按所需的独立实体数量和逻辑跳数对查询进行分类，并测量向量基线的失败之处。如果只有不到 20% 的查询需要多跳推理，那么维护知识图谱的运维开销可能并不足以抵消这少数查询带来的准确率提升。

务实的进阶之路

GraphRAG 并不是向量检索（vector retrieval）的通用升级。它是一种专门针对从根本上需要关系遍历（relationship traversal）的查询模式的工具，并且在 Schema 设计、提取质量控制和维护方面伴随着实质性的运营投入。

那些在生产环境中成功运行 GraphRAG 的团队都有一些共同特征：他们具备 Schema 设计能力（有人可以定义并维护本体/ontology），他们投入精力进行提取质量验证（他们知道自己的实体提取器遗漏了什么），并且他们接受了延迟权衡，以换取在高风险查询中的正确性。

在 GraphRAG 上失败的团队通常低估了提取的脆弱性，构建了在维护负担下会崩溃的过于宏大的本体，并且太晚才发现他们的查询分布实际上并不需要多跳推理（multi-hop reasoning）——他们的向量基准线（vector baseline）本来就足够了。

从向量 RAG 开始。监测你的失败案例。如果你发现多跳查询在关系密集型内容上持续失败，那么 GraphRAG 就是正确的架构选择。如果你的失败更像是检索精度或分块碎片化问题，这些可以通过更好的分块策略、混合搜索和检索评估来解决——不需要知识图谱。

知识图谱的运营开销是为了保证特定类别查询的正确性而进行的深思熟虑的投入。在你做出这项投入之前，请确保你确实拥有那一类查询。