知识图谱 vs. 向量存储：选择你的检索原语

大多数团队在起步时都会选择向量数据库 (Vector Store)，因为它们上手简单，但随后会发现即使无论如何调整分块大小 (Chunk size) 或嵌入模型 (Embedding model)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

这不是一篇推荐“两者兼顾”的文章。在实际应用中需要进行真正的权衡，选择失误会耗费数月的工程时间。以下是这种选择在实践中的真实面貌。

你的真实选择到底是什么

向量数据库将内容映射到高维嵌入空间。检索过程是寻找嵌入向量与查询向量最接近的文档。这种机制是概率性的，在大规模场景下延迟低于 50 毫秒，且不需要模式 (Schema) 设计。你只需喂入文档，就能得到查询结果。

知识图谱 (Knowledge Graph) 将数据表示为通过标签边连接的有类型节点。例如，员工节点通过 works_in 边连接到部门节点；药物节点通过 treats 边连接到疾病节点。检索过程是确定性的：通过编写 Cypher 或 SPARQL 查询，沿着特定的关系路径访问特定的实体。

这种差异不仅仅是技术层面的。向量数据库回答的是“什么内容在语义上与此相似？”而知识图谱回答的是“什么内容在结构上与此相关，以及是如何相关的？”

向量搜索在何处胜出及其原因

向量数据库以统一的方式处理非结构化文本、图像和音频。你不需要定义模式，不需要领域专家来定义关系，并且可以在几小时内开始返回有用的结果。对于经典的 RAG 场景 —— “这里有一堆文档，请根据它们回答问题” —— 向量检索默认是正确的选择。

需要注意的失效模式：向量搜索寻找的是看起来像查询的文档，而不是通过推理链回答查询的文档。在医学语料库中搜索“心脏病患者的阿司匹林禁忌症”，会检索到关于阿司匹林的文档和关于心脏病患者的文档，但它无法自动将“阿司匹林会稀释血液”与“该患者已安排手术”合成出正确的禁忌症结论。这些事实可能存在于不同作者、相隔五年编写的不同文档中，而基于嵌入的检索器没有办法将它们连接起来。

这不仅是分块 (Chunking) 的问题。如果因果链跨越了三个不同的文档，更大的分块也无济于事。检索器需要的是遍历关系，而不是匹配相似度。

向量搜索在聚合查询方面也表现不佳。“Acme Corp 所有子公司的总营收是多少？”这类问题需要明确了解子公司关系。嵌入空间没有所有权层级的概念。你会检索到关于 Acme Corp 及其关联实体的文档，但如果没有关于“谁拥有谁”的结构化知识，你就无法在正确的公司集合上进行求和。

知识图谱在何处胜出及其原因

知识图谱正是为了处理那些结构编码了语义无法捕捉的含义的场景而存在的。

多跳推理 (Multi-hop reasoning) 是最主要的例子。给定具有类型关系的实体 A、B 和 C，图查询可以在一次扫描中遍历 A→B→C：“查找所有由曾在 2023 年治疗过确诊 X 疾病患者的医生所开具的药物。”向量搜索没有类似的对应机制。你可能需要多次检索调用、手动合成以及大量的 LLM 推理，才能勉强接近图查询直接返回的结果。

基准测试清楚地说明了这一差距。在跨文档推理任务（需要综合多个来源的事实的问题）中，基于图的检索能在大约 33% 的时间内检索到相关信息，而仅靠向量的 RAG 只有 8%。对于聚合查询（针对关系链进行计数、求和、过滤），图检索的得分约为 23%，而向量几乎为零。

实体消歧是支持图谱的另一个有力论据。向量搜索根据训练数据中的共现模式，将“Apple”（公司）和“apple”（水果）视为相似。知识图谱则通过明确的实体类型来区分它们：名为“Apple”的 Organization 节点拥有与同名的 Food 节点完全不同的边。当你构建金融或科学应用，且实体混淆会导致严重错误时，这绝非小事。

合规性和可审计性也更倾向于图谱。知识图谱的每一个答案都带有一个溯源链 (Provenance chain)：即产生结果的节点和边的确切序列。向量相似度分数告诉你文档与查询的相似度为 0.87，但它们无法告诉你为什么，也无法告诉你经过了哪条概念路径。在受监管的行业，“相似的嵌入向量”并不是一个可以接受的审计追踪。

查询类型测试

决策可以简化为一个单一的诊断：你的查询分布究竟是什么样的？

通过以下分类对你的代表性查询进行评估：

适合向量的查询具有单一的核心实体或概念，需要在不同的词汇之间进行语义匹配，并且可以通过单个检索到的分块或几个分块的简单组合来回答。例如：“公司的退货政策是什么？”“总结这份报告的发现。”“查找关于机器学习基础设施的文档。”

适合图谱的查询需要遍历实体间的关系，涉及由结构化成员身份定义的集合聚合，需要时间推理（在 X 期间什么是真实的），或者需要对共享名称或表面语义相似的实体进行消歧。例如：“服务 A 的下游依赖项有哪些？”“哪些客户拥有活跃订阅且有开启的服务单且在过去 30 天内进行了购买？”“显示发起方与被标记实体在两度关系内相连的所有交易。”

如果你的查询分布中有超过 20% 属于第二类，那么纯向量方案将在最关键的案例中持续出现准确性故障。

混合架构的真实样貌

“两者都用”的建议往往很模糊。以下是具体的架构：

查询在输入端会被分类 —— 或是通过轻量级意图分类器，或是通过显式路由规则。语义模糊的问题进入向量检索器。结构化的问题进入图检索器。混合型问题则同时进入两者，并在 LLM 生成响应之前合并结果。

在合并步骤中，两组结果都会被标记其来源，以便 LLM 应用不同的推理策略：“这些是语义相似的文档；这些是结构相关的实体。” 如果没有标记，LLM 就没有依据对两种结果类型进行不同的权重分配。

实现开销是现实存在的。你需要维护两个系统、两个索引流水线和一个编排层。延迟预算会增加：向量检索运行耗时 15-50 ms，图遍历耗时 100-300 ms，协调工作又增加 50 ms。混合检索的总耗时预计为 200 ms，而仅向量检索仅需 50 ms。

这种开销是否合理，完全取决于你的应用是否包含图检索能解决的查询类型。如果 80% 的查询是语义文档搜索，而 20% 需要多跳推理，你可能不会为了那 20% 去构建混合系统 —— 你要么简化这 20% 的需求直到向量检索能处理，要么接受这些查询较低的准确度。

如果你的产品依赖于这 20%，那就构建混合系统。

图谱采用中的冷启动陷阱

意识到自己需要知识图谱的团队经常会碰壁：构建一个有用的图谱需要实体提取、关系提取、Schema 设计和持续维护。这些都不是零成本的。

实体提取问题经常被低估。通用 LLM 能很好地从通用文本中提取实体。对于特定领域的语料库 —— 如临床记录、法律合同、财务文件 —— 提取质量在专业术语上会显著下降。在图谱达到可靠使用标准之前，你可能需要特定任务的提取流水线。

Schema 设计使问题更加复杂。向量库没有 Schema；索引一种新的文档类型非常简单。知识图谱则有显式的本体（Ontology），而这种本体编码了你对该领域的假设。当领域发生演变 —— 如新产品线、监管变化、组织重组 —— 图谱 Schema 需要更新，否则图谱就会产生过时的答案。要为持续的 Schema 治理预留预算，而不仅仅是初始构建。

一种务实的方法：先从覆盖全语料库的向量检索开始。对系统进行检测，识别哪些查询因多跳推理缺陷而失败。利用这些失败案例来定义知识图谱实际需要表示的实体和关系 —— 而不是预先构建一个可能无法反映真实查询模式的全面本体。

实践中的决策标准

在以下情况下，先从向量库开始：

• 你的数据主要是非结构化文本、图像或音频。
• 查询是语义化的且焦点单一。
• 延迟要求低于 100 ms。
• 你需要在几周内而不是几个月内看到结果。
• 你的团队在图数据库方面的经验有限。

在以下情况下，投入建设知识图谱：

• 实体之间的关系是查询的核心。
• 聚合、多跳遍历或时间推理是核心用例。
• 可解释性或审计追踪是硬性要求。
• 你处于实体消歧失败会产生严重后果的领域（金融、医疗、法律）。
• 尽管进行了向量微调，你的查询分布在关系型问题上仍表现出持续的准确性缺陷。

在以下情况下，构建混合检索：

• 语义搜索和关系型查询对你的用户都很重要。
• 你可以接受 200 ms 的检索延迟。
• 团队能够长期维护两个索引流水线。
• 在复杂查询上 15-25% 的准确率提升足以抵消基础设施的复杂性。

核心原则

向量相似度和图遍历不是竞争产品。它们是回答不同问题的不同数学运算。向量搜索是嵌入空间中的邻近度函数。图遍历是关系空间中的路径寻找函数。

团队不断遇到的失败模式是尝试用邻近度来回答路径问题。“子公司”和“营收”的嵌入在向量空间中会聚集在 “Acme Corp” 附近，但没有任何距离计算能告诉你哪些实体是 Acme Corp 的子公司，或者它们的个人营收是多少。这不是模型质量问题 —— 而是针对问题使用了错误的原始语料。

当你的应用中最难的查询从根本上涉及关系、结构和遍历时，知识图谱并不是向量库的过度设计替代方案。它是正确的工具。