跳到主要内容

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

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

混合架构的真实样貌

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates