跳转到主要内容

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

阅读需 2 分钟Tian PanTian Pan

大多数团队在起步时都会选择向量数据库 (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% 属于第二类,那么纯向量方案将在最关键的案例中持续出现准确性故障。

混合架构的真实样貌

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 11 分钟

你的 RAG 分块器是一项无人 Review 代码的数据库 Schema

将你的 RAG 分块器视为预处理,每一次边界微调都会变成一次静默的 Schema 迁移。对其进行版本管理、灰度发布,并同步负责检索评估。

insider
rag
阅读需 10 分钟

你的向量数据库也有热点 Key:为什么 ANN 索引在生产成本上“撒了谎”

公开的 ANN 基准测试通常运行均匀的查询负载,但在生产环境中检索是齐夫分布(Zipfian)的 —— 这种差异表现为分片过载、RAM 浪费以及超出预期的 p99 延迟。

insider
vector-database
阅读需 9 分钟

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

在合规和企业领域的多实体查询中,向量嵌入的准确率往往会降至零。本文将探讨知识图谱在何时是更优选择,以及你将面临的运维成本。

insider
rag
阅读需 9 分钟

你的向量索引是一个没有失效策略的缓存

向量索引是你源数据的派生副本,这使得它成为了一个会过时的缓存:修改内容永不自动同步、已删除的文档留下“残影”、被撤销的权限导致泄露。为什么 RAG 的可靠性是一个缓存失效问题,而不是相似度搜索问题。

insider
rag
阅读需 8 分钟

检索级联失效:文档删除如何毒害你的 RAG 流水线

当源文档消失时,它们的嵌入仍滞留在向量索引中,并持续返回貌似正确的错误答案。这是一份关于墓碑机制、级联失效以及检索时新鲜度检查的实战指南。

rag
vector-database