向量数据库的核心并不是“把向量存进去”，而是在数据规模、检索延迟、召回质量和内存成本之间做取舍。小规模知识库可以直接比较全部向量；数据增长后，则需要借助近似最近邻（ANN）索引减少计算量。
这篇文章从一次 RAG 检索请求出发，说明距离度量、FLAT、HNSW、IVF、PQ 各自解决什么问题，并给出面向 AI 应用部署的选型路径。文中的规模边界是工程上的起始判断，不应替代真实数据压测。
先明确：检索到底在比较什么
Embedding 模型会把文本、图片或其他对象转换成固定维度的向量。检索时，系统将查询向量与候选向量比较，再返回距离更近或相似度更高的 Top-K 结果。
常见度量包括：
- L2 欧氏距离：计算向量在空间中的直线距离，适用于使用这类距离训练或配置的模型。
- 余弦相似度：比较向量方向，文本语义检索中较常见。
- 内积：直接计算两个向量的点积。若向量已做 L2 归一化，内积与余弦相似度等价；未归一化时，向量长度也会影响结果。
不能脱离 Embedding 模型的训练目标随意更换度量。上线前应确认模型卡、向量库字段配置和查询侧使用的是同一种距离定义，否则索引即使运行正常，召回结果也可能偏离预期。
为什么普通索引不够用
对每个查询都扫描全量向量，是最直接的精确搜索（FLAT 或 brute-force）。它返回真实 Top-K，适合数据量较小、需要作为评测基线，或对召回质量极其敏感的场景。
但计算量大致随“向量条数 × 向量维度”增长。候选数量、向量维度和并发量同时上升时，全量扫描会占用更多 CPU 和内存带宽。B+ 树依赖一维有序键，哈希适合等值匹配，都不能直接把高维向量的“相近”关系变成高效查询路径。
ANN 的思路是接受可控的近似：索引先找出一批有希望的候选，再返回 Top-K，或对候选使用原始向量重新排序。评估时应同时看召回率、P95/P99 延迟、吞吐、索引构建时间、更新成本和资源占用，而不是只看某一个速度数字。
HNSW：用图导航换取较快检索
HNSW（Hierarchical Navigable Small World）把向量组织成多层近邻图。查询从高层的稀疏图开始，逐步向更接近查询向量的节点移动，再在底层图中扩大搜索范围。
它的特点是查询参数可调：搜索范围扩大，通常更有机会找到真实近邻，但延迟和计算量也会上升。HNSW 一般需要保留原始向量和图连接，内存开销不能忽略；构建图也会消耗 CPU 和时间。
HNSW 更适合以下情况：
- 数据量处于中等规模，内存预算能够容纳向量和图结构；
- 查询延迟要求较高，同时希望保留较好的召回；
- 读多写少，或可以接受索引维护成本的业务。
在带有元数据过滤的 RAG 场景中，还要实测过滤条件对召回和延迟的影响。先过滤、搜索中逐步过滤、扩大候选后再过滤，都会改变实际结果，不能只依据无过滤基准测试下的表现。
IVF：先分桶，再搜索少量候选
IVF（Inverted File）先用聚类把向量分到多个簇，每个簇保存自己的候选列表。查询时先找到距离较近的若干个簇，只在这些簇中搜索，而不是扫描整个集合。
主要参数可以这样理解：
- 簇数量决定索引的分区粒度；
- nprobe 决定一次查询要检查多少个簇；
- nprobe 增大，候选范围扩大，召回通常更有保障，但查询成本也会增加。
IVF 的优点是搜索范围和资源开销比较容易控制，也适合与量化压缩组合。代价是聚类分布、簇数量和 nprobe 需要结合实际数据调试。如果数据分布变化明显，旧的聚类中心可能不再合适，还需要考虑重建或维护策略。
PQ：压缩向量，降低存储与计算压力
PQ（Product Quantization）把高维向量切分成多个子空间，并用较短的编码表示每个子向量。查询时可以通过预先计算的距离表估算候选与查询向量的距离，避免频繁读取并计算完整浮点向量。
PQ 的核心收益是压缩存储和减少计算，但量化会引入误差。它通常用于粗排或候选筛选，不能简单地把压缩距离当作最终相关性结论。若业务需要更稳定的召回，可以保留原始向量，对经过 IVF/PQ 筛出的候选做精确重排；这会增加存储或回捞成本。
IVF 与 PQ 组合后，分别承担“少搜索”和“少存储”的职责。它适合数据规模大、内存预算紧张，同时能够接受调参和精排流程的场景。
一次 RAG 查询会经过哪些阶段
一个带元数据过滤的向量检索请求，通常可以抽象为以下流程：
- 将用户问题通过同一套 Embedding 模型转换为查询向量；
- 根据租户、时间、文档类型等条件处理标量过滤；
- 通过 HNSW 图搜索，或通过 IVF 找到若干候选分区；
- 若使用 PQ，先用量化距离完成粗排；
- 对候选回捞原始向量，按精确距离重排（如果索引方案需要）；
- 返回 Top-K 文本片段，交给后续提示词组装和大模型生成。
过滤条件会改变候选空间。比如“只搜索某个租户的文档”可能让原本相近的节点全部失效，也可能迫使系统扩大搜索范围。因此，测试集必须包含真实过滤条件，并分别记录无过滤和有过滤的召回表现。
怎么选：先从数据与约束出发
可以按下面的顺序做初筛：
数据量较小：先用 FLAT 建立基线
如果向量数量不大，或业务仍处于验证阶段，精确搜索通常更容易排查问题。它不需要复杂的索引调参，还能作为评估 ANN 召回率的“真值”参考。不要为了追求索引复杂度，在还没有延迟瓶颈时提前引入维护成本。
中等规模、内存充足：优先评估 HNSW
当查询延迟成为主要问题，且向量和图结构能够放入可用内存，可以从 HNSW 开始压测。重点观察搜索范围参数变化对召回、P95 延迟和并发吞吐的影响。
大规模或内存紧张：评估 IVF、IVFPQ 或磁盘型方案
当全量原始向量难以放入内存，可以考虑 IVF 配合压缩，或评估以 SSD 为主要存储介质的索引方案。此时不能只比较查询耗时，还要把构建时间、数据更新、故障恢复、原始向量回捞和磁盘成本纳入账本。
已有关系型数据库：先看集成成本
如果项目已经使用 PostgreSQL 等数据库，且数据量和延迟目标仍在可控范围内，可以先评估数据库内的向量扩展，减少额外服务、同步链路和运维面。只有当规模、并发、过滤或多租户隔离超出其边界时，再考虑引入专用向量数据库。
上线前的最小压测清单
不要直接套用文章或产品文档中的经验数字。至少准备一份接近生产分布的测试集，并记录：
- 使用线上 Embedding 模型生成的向量维度与距离类型；
- 不同数据规模、过滤比例和 Top-K 下的召回率；
- 平均延迟、P95/P99 延迟和并发吞吐；
- 索引构建、增量写入、删除与重建耗时；
- 向量、图结构、量化编码、缓存和副本的内存占用；
- 扩容、备份恢复以及索引损坏后的重建路径。
向量索引没有脱离业务的“固定答案”。FLAT 负责提供简单可靠的基线，HNSW 通过图导航减少搜索范围，IVF 通过分桶控制候选集合，PQ 通过量化降低存储压力。先用真实数据确定瓶颈，再选择索引和参数，通常比一开始追逐某个理论上的延迟数字更稳妥。