当向量搜索失效：为什么知识图谱能处理 Embedding 无法解决的查询

向量搜索已成为 RAG 系统的默认检索原语。嵌入你的文档，嵌入查询，查找最近邻 —— 这一过程简单、快速，且对于大多数问题效果惊人。但在生产环境部署中，开发者往往会遇到同样的瓶颈：某些查询尽管相似度得分很高，返回的却是垃圾结果；某些多文档推理任务会无声无息地失败；随着复杂度的增加，某些实体密集型查询会退化为随机噪声。

问题不在于嵌入质量或索引大小，而在于语义相似性对于一大部分检索问题来说是错误的抽象方式。知识图谱并不是向量搜索的替代品 —— 它们解决的是结构完全不同的问题。理解哪些问题属于哪种工具，是区分脆弱的 RAG 流水线与能在生产环境中稳健运行的系统的关键。

两种原语及其本质作用

向量搜索回答的问题是：哪些文档在语义上与此查询相似？ 它将文本压缩为一个高维空间中的点，然后寻找附近的点。其基本操作是嵌入空间中的距离。

知识图谱回答的是一个不同的问题：存在哪些实体，它们之间有什么关系，通过遍历这些关系我可以推导出什么？ 其基本操作是图遍历 —— 沿着节点之间的边进行追踪。

这些并不是对相同数据的等效操作。距离和连通性是正交的属性。一篇关于“2 型糖尿病治疗方案”的文档和一篇关于“青少年胰岛素抵抗”的文档在嵌入空间中可能相距甚远，但通过一个患有这两种疾病的患者实体，它们又存在关键的联系。除非查询本身弥合了这一差距，否则向量搜索会遗漏这种联系。而图遍历通过沿着边追踪，能够直接找到它。

语义相似性在哪里失效

多跳关系查询是最明显的失效模式。“查找所有引用了引用了 Smith 2019 的论文的论文”需要遍历“节点 → 节点 → 节点”。无论嵌入质量多高，都无法将其表达为最近邻搜索。从定义上讲，这类查询就是图遍历。这同样适用于组织架构查询、供应链追溯、引用网络，以及任何带有“在 X 的 Y 中”结构的疑问。

噪声下的实体消歧是一个更隐蔽的失效点。当同一个现实世界实体以不同的表现形式出现时 —— 例如 “JPMorgan”、“JP Morgan Chase”、“JPM”、“这家银行” —— 如果没有显式的实体解析，向量搜索的处理效果很差。嵌入技术会将提到的向量与候选实体向量进行比较，但忽略了结构上下文：哪些其他实体共同出现、存在什么关系、局部图邻域是什么样。EDEGE 和类似的将语义嵌入与子图结构结合的混合方法，其表现始终优于纯嵌入消歧，因为图结构提供了单个嵌入向量无法捕获的全局语义上下文。

聚合查询则完全崩溃。“有多少文档在 Z 的背景下同时提到了 X 和 Y？”是一个针对文档元数据和内容的结构化查询。向量搜索返回的是相似的文档，而不是组合问题的答案。研究基准显示，在聚合查询方面，基于图的检索比向量 RAG 的性能高出 3 倍，正是因为图遍历可以计数边、按节点属性过滤并跨关系进行聚合。

大规模跨文档推理随着实体数量的增加而退化。在受控基准测试中，当查询涉及五个或更多不同实体时，向量 RAG 的准确率会降至接近 0%。而 GraphRAG 在涉及十个或更多实体时仍能保持稳定的性能，因为它显式地建模了关系，而不是依靠余弦相似度来发现跨文档的联系。

还有一些更难捕捉的隐性失效模式。嵌入模型版本不匹配 —— 查询和索引使用不同的模型版本 —— 会产生虽然有效但基于毫无意义的对比的相似度得分。生僻词、SKU、特定标识符以及缺乏语义上下文的短查询都会受到过度泛化的困扰：当你需要精确匹配时，嵌入却编码了“相似含义”。

知识图谱为检索带来了什么

知识图谱将实体表示为节点，将关系表示为有类型的边。“作者 A 撰写了论文 B，论文 B 引用了论文 C，论文 C 由机构 D 资助”变成了一个可遍历的结构。需要遵循这些链条（无论是广度优先还是深度优先）的查询变成了可表达的操作，而非近似计算。

微软的 GraphRAG 研究在新闻语料库上具体证明了这一点。通过使用数千篇俄罗斯和乌克兰的新闻文章，GraphRAG 发现了“Novorossiya”等实体，并追踪了跨文档的关系链，而基准向量 RAG 则没有返回任何相关内容。这种差异不在于单个文档的检索质量，而在于连接分布在不同文档中、且仅通过实体关系链接的信息的能力。

该架构分为两个阶段：第一阶段 LLM 从源文档中提取实体和关系；第二阶段图社区检测生成不同粒度的领域特定摘要。检索路径随后使用图遍历而非最近邻搜索，同时在适用的情况下仍然支持向量和全文搜索。

对于实体密集型领域 —— 医疗记录、法律文件、财务报告、技术规范 —— 这种架构能产生显著的效果。一个连接患者记录、研究文献和治疗方案的医疗实施方案报告称，复杂病例的诊断准确率提高了 18%，治疗计划制定时间缩短了 31%。这种提升源于挖掘出了数据中存在但对语义相似性不可见的关系。

混合检索：何时需要两者兼顾

对大多数生产系统而言，实际的架构并非在图（Graph）和向量（Vector）之间二选一，而是两者并行并合并结果。

HybridRAG 流水线分为三个阶段：

• 向量搜索：查找语义相关的实体和文档块。
• 图遍历：探索向量搜索返回的实体之间的关系。
• 加权合并：使用计分系统结合两者结果，同时考虑相似度和图距离。

这解决了单一方法的核心缺陷。纯向量搜索能找到相关的单个文档，但会遗漏关系。纯图检索在处理关系时很精确，但完全取决于实体提取和图构建的质量。混合检索利用向量组件找到进入图的入口点，然后通过图遍历来追踪仅凭语义无法发现的连接。

混合流水线的技术栈通常涉及并行索引：向量索引（Pinecone, Qdrant, Weaviate）处理语义检索；图数据库（Neo4j, Amazon Neptune）处理关系遍历；BM25 索引处理关键词和标识符的精确匹配。检索层执行这三者，通过加权评分器合并结果，并将组合后的上下文传递给生成步骤。

针对这种混合方法的研究基准显示，与单一方法相比，上下文相关性提升了 11%，事实准确性提升了 8%。这些提升源于不同类型的查询发挥了各个组件的长处。

构建难题

团队坚持使用向量搜索的主要原因并非理论上的，而是运营层面的。构建和维护知识图谱的成本显著高于维护嵌入（Embedding）索引。

实体消解（Entity resolution）是最困难的部分。未消解和语义重复的实体会导致图结构不一致，例如 "JPMorgan" 和 "JP Morgan" 被视为没有连接边的独立节点，从而导致关系查询失败。传统的知识图谱构建通常依赖特定领域、半自动化，并且需要预定义的实体分类法和大量的专家人工标注。

LLM 辅助构建使这一过程变得更加可行。像 Neo4j 的 LLM Graph Builder 这样的工具，可以使用多个 LLM 供应商将非结构化文本（PDF、文档、转录文本）转换为知识图谱，而无需人工标注。虽然准确性仍受限（LLM 会幻觉出关系，或遗漏训练分布之外的细微实体类型），需要验证流水线和人工审核来处理高风险领域，但现在的运营成本已比 2024 年之前降低了一个数量级。

大规模的动态更新仍是一个未解决的难题。嵌入索引可以通过添加新向量来进行增量更新。而知识图谱需要更复杂的更新逻辑：新实体必须与现有实体进行消解，新关系必须验证一致性，且图结构的变化可能会以非显式的方式影响遍历路径。对于快速变化的语料库，这是一个真实的制约因素。

时间维度也值得明确指出。向量搜索没有时间概念——如果嵌入相似，2015 年的文档和 2025 年的文档与查询的距离是相等的。带有时间元数据过滤器的混合系统通过将检索限制在特定时间窗口内来处理这个问题，但这只是外挂的功能，而非检索原语本身固有的属性。

决策框架

选择哪种方法取决于查询结构的核心需求：

在以下情况下使用向量搜索：

• 查询是语义化的且开放式的（“哪些文档讨论了 X？”）
• 语料库是非结构化的，且关系提取成本过高
• 检索延迟是硬性约束
• 领域内没有定义明确、命名一致的实体

在以下情况下使用知识图谱：

• 查询需要多跳遍历（“找到所有通过 Z 与 Y 相关的 X”）
• 跨文档的实体歧义消除至关重要
• 需要对关系进行聚合
• 领域内有定义明确的实体（医疗保健、法律、技术规范）
• 跨文档推理是主要用例

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

• 查询组合同时包含语义和关系模式
• 重实体的查询必须与自由格式的语义问题并行工作
• 语料库足够大，以至于任何单一方法都无法覆盖所有检索需求

这对你的架构意味着什么

在生产环境中需要警惕的失败模式是，系统表现得很自信，却检索到了错误的上下文。向量搜索即使在结果无法真正回答查询时，也会返回高相似度的结果——相似度得分只能告诉你语义相关性，并不能告诉你检索到的内容是否包含答案。对于多跳查询，检索到的文档通常在个体上是相关的，但未能呈现出连接信息。在对那些对你的用例真正重要的查询类型进行评估之前，系统看起来运作良好。

如果你的查询分布以简单的语义问题为主，向量搜索是正确的默认选择。它的构建成本更低，更易于维护，并且能胜任大多数检索工作负载。

如果你的查询分布包含多跳推理、实体歧义消除或跨关系的聚合——大多数企业知识库最终都会遇到这三种情况——那么混合架构就是正确的投资。首先针对真实查询记录检索失败的情况，以识别你实际遇到的是哪种失败模式。随着规模扩大而退化的重实体查询，以及返回不相关但语义相似上下文的关系查询，都是图遍历需要介入的最清晰信号。

底层原则是：检索原语应与查询结构相匹配。语义相似性是针对特定类别问题的强大原语。关系遍历是针对另一类问题的不同原语。混淆两者是大多数检索失败的根源，而这些失败是无法通过扩大嵌入模型规模来修复的。