向量数据库、嵌入和重排序：检索的三个不同部分

嵌入、向量数据库和重排序器是检索的三个不同组成部分。嵌入模型将文本或其他数据转换为数值表示；向量数据库或向量索引存储并搜索这些表示以检索候选项；重排序器接收一个较小的候选集，并使用更昂贵的相关性模型或评分方法对其重新排序。它们经常一起出现在RAG中，但它们都不是RAG本身，也不是每个检索系统都必须具备的。

这真正意味着什么

搜索系统有两个相互竞争的目标：找到足够多可能相关的材料，并将最好的材料放在靠近顶部的位置。快速的第一阶段检索通常优化候选生成。更强的第二阶段模型则可以花费更多计算来区分最佳候选。

嵌入、向量索引和重排序器在该过程中占据不同的位置。将它们视为一个功能会掩盖关于召回率、精确率、延迟、存储、元数据过滤和模型成本的重要设计选择。

这种区分还可以防止一个常见的RAG错误：假设将文档嵌入存储在向量数据库中就会自动创建高质量的检索。检索质量取决于嵌入模型、分块、元数据、查询构建、索引配置、候选数量、混合检索、重排序以及底层来源的权威性。

最简单的例子

假设一个知识库包含100,000个文档块。用户问：“如何撤销API令牌？”

首先，嵌入模型可以将查询编码为向量。文档块可能已经存储了自己的嵌入。然后，向量搜索将查询向量与索引的文档向量进行比较，并返回例如30个可能的候选。

这30个候选随后可以传递给重排序器。重排序器更直接地将查询与每个候选进行比较，并产生新的相关性排序。应用程序可能会保留最好的五个用于模型上下文。

一个基本的两阶段语义检索流程

1

1. 嵌入文档

将每个可搜索的块转换为数值表示，通常在摄取时进行。

2

2. 存储/索引向量

将向量与文档ID和元数据关联到可搜索的向量索引或数据库中。

3

3. 嵌入查询

使用兼容的嵌入模型和查询配置对用户的查询进行编码。

4

4. 检索候选

运行向量相似性搜索，通常带有元数据过滤器，以生成更大的top-k候选集。

5

5. 重排序候选

对查询和小型候选集应用更强的相关性模型。

6

6. 选择上下文

保留最有用的段落，用于下游答案、代理步骤或搜索结果。

简单示例的局限

真实的检索系统根本不必使用密集嵌入。诸如BM25之类的关键词搜索可以作为第一阶段检索器。稀疏学习检索、SQL过滤器、图遍历或应用程序API也可以生成候选。

重排序器也不关心候选是否来自向量数据库。它可以对BM25结果、混合结果、手动选择的文档或来自多个检索器的候选进行重排序。

同样，嵌入不需要专门的向量数据库。小数据集可以在内存中或使用通用数据库和向量扩展进行比较。当索引、近似最近邻搜索、过滤、规模、更新行为或操作要求证明其合理性时，专门的向量系统才变得有用。

三种不同的检索组件

	嵌入	向量数据库 / 索引	重排序器
主要任务
典型输入
典型输出
成本特征
典型故障

嵌入：表示，而非检索

嵌入是模型生成的数值表示。对于语义检索，含义相关的文本旨在在向量空间中占据有用的位置，以便相似度或距离函数可以比较它们。

Sentence-BERT 是使句子级语义相似度变得实用的重要一步，它采用了双编码器风格的表示，可以独立计算并高效比较。这一总体思路仍然是现代稠密检索的核心：预计算文档表示，在搜索时计算查询表示，然后进行比较。

嵌入本身并不搜索语料库。它是由嵌入模型生成的数据。当系统将查询表示与存储的候选进行比较时，检索才开始。

嵌入模型定义了表示空间

文档和查询向量必须与创建它们时使用的模型和配置兼容。替换嵌入模型可能会改变维度、相似度行为、语言覆盖范围和领域性能。

这就是为什么嵌入模型迁移不仅仅是更改 API 名称。现有文档可能需要重新嵌入，索引需要重建或版本化。

稠密表示和稀疏表示是不同的

稠密嵌入通常包含许多非零维度，常用于语义相似度。稀疏表示包含许多零，可以保留更强的词元或词项结构。

两者都可以支持语义检索，现代搜索系统可以结合稠密、稀疏和词汇信号。因此，“向量搜索”并不总是意味着单一的稠密余弦相似度流水线。

相似度函数是表示契约的一部分

余弦相似度、点积和欧几里得距离的含义并不相同。正确的度量取决于嵌入模型是如何训练和归一化的。

例如，当前的 Qdrant 文档要求将距离度量作为向量配置的一部分，并记录了余弦、点积和欧几里得风格的选择。重要的架构规则是将度量视为嵌入/索引契约的一部分，而不是随意选择一种。

向量数据库和索引：候选检索

向量数据库或支持向量的搜索系统组织向量表示，以便应用程序能够高效地检索附近的候选。实际系统通常将向量与 ID 和有效负载元数据（如来源、语言、租户、文档类型、时间戳或访问范围）关联起来。

例如，Qdrant 将数据组织为点的集合，其中点包含向量和可选的有效负载元数据。其文档将基于 HNSW 的相似度搜索和元数据过滤描述为检索层的独立能力。

这种区分很重要：向量索引解决的是最近邻问题，而有效负载过滤器则强制执行结构性约束，例如租户、文档类别或语言。

近似最近邻搜索以精确性换取效率

将单个查询向量与每个向量进行比较对于小型集合可能是可行的，但在大规模场景下成本高昂。诸如 HNSW 之类的近似最近邻索引通过遍历索引结构而不是穷举扫描每个向量来降低搜索成本。

近似搜索引入了召回率与延迟之间的权衡。更快的搜索可能会遗漏精确搜索本应返回的候选结果。因此，索引参数不仅影响基础设施性能，还会影响检索质量。

Qdrant 同时提供了与 HNSW 相关的参数和精确搜索选项，这表明向量存储和近似检索策略是相互独立的决策。

元数据过滤应在候选检索之前或期间进行

如果用户只能访问租户 A，那么从租户 B 检索语义相似的片段并试图稍后将其移除，是错误的安​​全边界。授权和硬性资格过滤器应在候选结果能够影响下游处理之前，对候选空间进行约束。

同样的原则适用于区域设置、文档状态、来源类别、日期、产品版本以及其他确定性约束。相似度应对符合条件的候选结果进行排序；它不应覆盖资格条件。

向量数据库是可选的

对于小型语料库，暴力余弦比较可能简单且足够。具有向量支持的关系数据库也可能足够。当专用向量数据库的索引、过滤、分布式存储、更新行为或运维特性能够解决实际需求时，它才变得有价值。

因为“RAG 需要一个向量数据库”而选择向量数据库，颠倒了架构设计流程。应从检索需求和规模出发，然后选择存储/索引技术。

重排序：第二阶段的相关性优化

重排序器接收一个查询和一组较小的已检索候选结果，然后分配更强的相关性分数或新的排序。它通常比第一阶段检索的计算成本更高，这就是为什么它应用于候选生成之后，而不是针对整个语料库。

当前 Elastic 的指南将语义重排序描述为针对小型 top-k 集合的最终阶段技术，并指出它可以优化词汇、语义或混合检索。Cohere 记录了相同的架构：先进行第一阶段的词汇或语义搜索，然后进行重排序阶段。

一种常见的实现使用类似交叉编码器的模型，该模型同时检查查询和每个候选结果。这种更丰富的交互可以比独立的嵌入相似度更精确地区分相关性，但在语料库规模下成本要高得多。

双编码器检索和交叉编码器重排序解决不同的成本问题

重排序器无法恢复检索遗漏的内容

如果相关文档不在候选集中，重排序就没有任何可以提升的对象。这就是需要分别评估检索和重排序的核心原因。

一个流水线可能具有出色的重排序器精确率，但仍然会因为第一阶段召回率较差而失败。提高重排序器质量无法修复缺失的源覆盖、糟糕的分块、限制性过滤器或较弱的候选检索器。

混合检索是一个独立的设计选择

当查询和文档使用不同措辞但表达相关含义时，稠密语义检索表现很强。当精确术语、标识符、名称、代码或罕见短语很重要时，词法检索表现很强。

混合检索结合多种候选信号，通常是词法 BM25 和向量相似度，然后使用诸如倒数排名融合或加权分数组合之类的方法合并排名。

随后，重排序可以在融合后的候选集上运行。因此，混合检索和重排序是互补但不同的阶段。

BM25 并不会因为嵌入的存在而过时

对于精确标识符、版本号、错误消息、产品代码和专业词汇，关键词搜索可能优于稠密检索。例如，SQLite FTS5 包含用于全文搜索的 BM25 排名函数。

一个强大的检索架构可以将词法检索作为唯一的第一阶段，将向量检索作为唯一的第一阶段，或者根据语料库和查询分布将两者结合起来。

分块会改变嵌入和重排序器能够看到的内容

如果文档被糟糕地切分，后续任何检索组件都无法完全重建缺失的语义单元。一个将条件与其例外切开的块，可能会以误导性的方式嵌入，也可能因为候选文本不完整而被错误地重排序。

因此，块大小、重叠、结构边界和元数据都会影响候选召回和重排序器判断。检索评估应测试从摄取到排名的完整流水线，而不仅仅是嵌入模型。

不要像比较通用概率那样比较检索分数

余弦相似度、BM25 分数、稀疏向量分数、RRF 排名和重排序器分数具有不同含义。来自一个嵌入模型的 0.82 分，并不自动与来自另一个模型的 0.82 分或与重排序器分数具有可比性。

阈值应针对实际模型、语料库和任务进行校准。当前 Elastic 指南还指出，嵌入相似度分数可能依赖于查询，这使得通用截断值存在风险。

分别评估检索阶段

这种分离在操作上很重要。如果 Recall@50 很差，重排序器并不是第一个需要修复的组件。如果 Recall@50 很强，但最佳段落仍排在第 38 位，那么重排序或排名融合就成为一个可能的目标。

究竟是哪一层失败了？

症状与可能的检索层

	观察到的症状	可能的层	首要诊断
相关文档从未出现
相关文档排名过低
语义上良好但被禁止的结果
相关但过时的结果
检索到正确结果但被提示词遗漏

相关性与事实来源是不同的

重排序器可以让一份过时的文档看起来极其相关。向量索引可以检索到语义上比原始来源更接近的次级摘要。因此，检索质量不能替代权威规则。

在来源权威性重要的地方，元数据过滤器、来源类别、版本规则和出处应在结果成为模型上下文之前约束检索。

原始实现证据

事实来源研究引擎：词法检索与语义检索是分离的

事实来源研究引擎包含一条使用 SQLite FTS5/BM25 的本地词法检索路径，以及一条使用本地生成嵌入的独立可选语义检索路径。

其语义搜索实现会计算查询向量，并使用余弦相似度将其与存储的块向量进行比较。该项目有意将语义相似度视为发现信号而非证据：候选结果在支持某项主张之前，仍必须追溯到具体的来源和定位符。

这对 R01 来说是有用的实现证据，因为同一语料库可以同时支持词法排名和向量相似度，而不会将任一机制与证据权威性相混淆。

Aaasaasa AI 客户端：Qdrant 是向量基础设施组件

Aaasaasa AI 客户端将 Qdrant/向量基础设施作为独立的本地资源。Electron 架构从受信任的主进程侧暴露 Qdrant 服务，而不是将向量搜索视为模型本身的一部分。

该仓库包含 Qdrant 客户端适配器、Qdrant 服务配置以及基于 Docker 的 Qdrant 基础设施。这展示了 AI 提供商/模型执行与向量存储/搜索之间的架构分离。

不应将 Qdrant 支持的存在夸大为完整的生产级 RAG 流水线。这里的证据更为有限：向量基础设施是作为其自身的组件边界实现的。

何时需要每个组件？

实用的检索设计流程

从需求出发设计检索，而非从产品名称出发

1

1. 定义查询类型

识别语义问题、精确查找、标识符、当前状态读取和领域特定模式。

2

2. 定义合格来源

应用租户、授权、区域设置、版本、来源类别和新鲜度约束。

3

3. 建立词汇基线

衡量简单的全文/BM25 检索是否已经解决了大部分工作负载。

4

4. 在需要语义召回的地方添加嵌入

针对代表性领域查询选择并评估嵌入模型。

5

5. 根据规模选择向量存储/索引

根据需求使用暴力搜索、数据库向量支持或专用向量引擎。

6

6. 评估第一阶段召回

确认相关证据进入足够大的候选集。

7

7. 如果信号互补则添加混合检索

当词汇和语义排名都能实质性改善候选生成时，融合两者。

8

8. 如果排序仍是瓶颈则添加重排序

仅对候选集应用更强的模型，以证明其成本合理。

9

9. 调整最终上下文选择

在生成之前控制冗余、上下文预算、权威性、多样性和证据覆盖。

10

10. 端到端评估

分别衡量检索、上下文和答案质量，以便定位失败环节。

常见误解

边缘情况和限制

有些应用不需要语义搜索。精确的数据库查找或结构化 SQL 可能比嵌入检索更正确、更快速且更易于审计。

有些语料库非常小，全向量扫描是可以接受的。近似索引增加了复杂性却没有有意义的收益。

有些查询在任何精度优化之前就需要高召回。法律发现、研究和合规审查可能更倾向于广泛的候选检索，然后进行透明的过滤和人工审查。

多语言和领域特定的检索在不同嵌入模型上的表现可能差异很大。来自公共数据集的基准声明不应被视为对私有语料库的证明。

重排序延迟随候选数量和长度的增加而增长。因此，候选大小应作为准确性/成本/延迟变量进行调整，而不是从教程中复制。

什么会改变这个答案？

如果供应商将嵌入生成、向量索引和重排序打包在一个 API 后面，组件边界不会改变。产品可能隐藏这些阶段，但它们在概念上仍然是不同的职责，具有不同的故障模式。

未来的嵌入或检索模型可能会在某些工作负载中减少对单独重排序的需求，而更强的后期交互或学习稀疏方法可能会模糊传统的密集/词汇类别。架构仍然应该问哪个阶段产生表示、哪个阶段生成候选以及哪个阶段细化排名。

最佳设计还会随语料库大小、查询组合、语言、领域术语、更新频率、来源权威性、延迟预算和评估结果而变化。

相关规范知识

R01 假设基本的 RAG 概念已经被理解。RAG 是一种更广泛的模式，其中检索到的外部信息被提供给模型；嵌入、向量搜索和重排序是该模式中的可选检索组件。

当检索失败时，应分别诊断来源覆盖、检索、排序、上下文组装和生成，而不是将整个系统视为一次“RAG 失败”。

真相来源架构是检索周围的权威层：它决定哪个来源可以确立一项主张，而嵌入和排序只决定哪些候选看起来相关。

常见问题

嵌入、向量数据库和重排序

嵌入和向量数据库有什么区别？

嵌入是由模型生成的数值表示。向量数据库或向量索引将这些表示与 ID 和元数据一起存储和搜索。

重排序器做什么？

重排序器接收已经检索到的候选集，并使用更强的相关性模型或评分方法对这些候选重新评分或重新排序。

RAG 需要向量数据库吗？

不需要。RAG 需要检索外部信息。检索可以使用词法搜索、SQL、API、图、向量搜索、混合搜索或这些的组合。

为什么不对整个语料库使用重排序器？

重排序器通常执行更昂贵的查询-文档交互，因此通常在更快的首阶段检索器之后应用于较小的 top-k 候选集。

重排序能修复缺失的文档吗？

不能。如果相关文档没有被检索到候选集中，重排序就没有任何东西可以提升。

余弦相似度是相关性概率吗？

不是。它是一种相似度度量，其数值含义取决于嵌入模型和语料库。不应将其视为普遍的相关性概率。

我应该同时使用 BM25 和向量搜索吗？

当评估显示词法和语义信号能够恢复互补的相关文档时，使用混合检索。它并非对每个语料库都自动更好。

什么时候需要专用的向量数据库？

当向量索引、过滤、规模、更新、分布式操作或其他向量特定需求足以证明需要专用系统时。小型工作负载可能不需要。

术语表

关键检索术语

嵌入

由嵌入模型生成的内容数值表示，用于相似度、聚类、检索或相关任务。

稠密向量

一种向量表示，其中许多维度携带非零值，常用于语义检索。

稀疏向量

一种高维表示，其中大多数维度为零，通常保留更强的词元或词项结构。

向量索引

一种数据结构，用于组织向量以实现高效的相似度或最近邻检索。

向量数据库

一种存储/搜索系统，旨在管理向量、相关元数据和向量检索工作负载。

ANN

近似最近邻搜索，以精确穷举比较换取大规模下更快的检索。

HNSW

分层可导航小世界，一种基于图的近似最近邻索引方法，广泛用于向量检索。

BM25

一种基于词项出现和语料库统计的词法相关性排序方法，广泛用于全文搜索。

混合搜索

结合多种检索方法（如词法搜索和向量搜索）的结果或分数的检索。

重排序

检索的后续阶段，对已生成的候选集重新评分和重新排序。

双编码器

一种独立编码查询和候选的架构，支持预计算和可扩展的相似度搜索。

交叉编码器

一种联合处理查询和候选文本的模型，通常以更高的计算成本提高相关性判断。

Recall@k

在前 k 个检索到的候选中恢复的相关项比例。

nDCG

归一化折损累计增益，一种排序指标，奖励在有序列表中位置更高的相关结果。

结论

清晰的检索模型很简单：嵌入表示含义，向量搜索检索候选，重排序器优化候选排序。

一旦这些边界明确，架构决策就更容易诊断。缺失候选指向来源覆盖、分块、嵌入、过滤器或首阶段检索。排序不佳指向排序、融合或重排序。然后可以在上下文和生成层分别调查不正确的最终答案。

最重要的结果不是选择最时髦的检索组件。而是构建一个检索管道，其阶段、权威边界、指标和失败模式可以独立测量。

主要来源和实现证据

以下外部参考文献记录了本文中使用的表示、向量搜索和重排序机制。项目特定部分是原创实现证据，有意比关于完整生产 RAG 成熟度的声明更窄。

Sentence-BERT：使用孪生 BERT 网络的句子嵌入

基础论文，展示了可独立计算的句子嵌入，用于高效的语义相似度搜索。

Qdrant — 架构和数据结构概述

官方文档，描述集合、点、向量、有效负载元数据和基于 HNSW 的相似度索引。

Qdrant — 搜索

官方向量搜索文档，涵盖相似度查询、过滤、精确与近似搜索以及稠密/稀疏行为。

Elastic — 向量搜索

关于稠密/稀疏向量检索、词法/向量组合和多阶段搜索管道的最新文档。

Elastic — 语义重排序

当前指南将语义重排序定义为对较小候选集进行的后期相关性操作。

Cohere — 使用 Cohere 进行重排序

当前文档展示重排序作为对词法或语义第一阶段检索的第二阶段改进。

SQLite FTS5

SQLite 官方文档，介绍全文搜索及用作词法检索证据的内置 BM25 排序函数。