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 这样的全局摘要方法，一个引入了连接到现有节点的新实体的新文档，可能需要重新计算社区层级。这使得实时更新变得困难。

加载中…