向量数据库选型指南：从暴力搜索到 HNSW

一切从「找相似」开始

做 RAG（检索增强生成，即先检索资料再让大模型作答）时，要从知识库里找出与问题语义最相近的几段文档；推荐系统要找与用户兴趣向量最接近的商品；内容去重要判断新文章与存量文章是否语义重复。三件事底层是同一个数学问题：给定一个查询向量，在海量候选向量里找出距离最小的 K 个。

这些向量来自 Embedding 模型——把文本或图片映射成一个几百到几千维的浮点数组，语义越相近的内容，向量在空间中的距离越近，常用的度量是余弦相似度。麻烦在于：上千维的空间里逐条两两计算的开销随数据量线性增长，而业务既要快、又要准。所有向量数据库的选型讨论，都从这个矛盾出发。

先问规模：暴力搜索的适用边界

很多人低估了暴力搜索（精确检索）的能力。一万条 768 维向量，用 NumPy 拼成矩阵，查询时一次矩阵乘法算出全部相似度再取 Top-K，单机毫秒级出结果；到了几十万条量级，只要并发不高，暴力搜索依然够用。它零索引、零调参、结果精确，十几行代码就能写完；用 pgvector 不建索引的精确模式，或者 SQLite 一张表加应用层计算，都是完全合理的方案。

所以选型的第一步不是看产品榜单，而是回答两个问题：向量总量会有多少？每秒要处理多少次查询？在「十万级以下、低并发」这个常见场景里，引入专门的向量数据库属于过度设计，索引的价值要到数据量与查询压力都上来之后才会显现。

ANN 两大流派：图索引与倒排量化

数据量再往上，就该请出 ANN（Approximate Nearest Neighbor，近似最近邻）——思路是牺牲少量召回率，换查询速度的大幅提升。主流实现分两个流派。

图索引的代表是 HNSW（分层可导航小世界图）。它借鉴跳表的分层思想：顶层稀疏、底层稠密，每个节点与一批「近邻」连边。查询从顶层入口出发，每一步贪心走向离查询向量更近的邻居，走不动就下降一层，到最底层时得到的局部最优解基本就是全局最近的那个圈子。两个参数决定它的表现：M 控制每个节点保留多少条连边，越大图越连通、召回越高、内存也越大；ef 控制搜索时的候选队列长度，越大召回越高但越慢。HNSW 的优点是查询延迟低且召回稳定，代价是内存占用高——除了原始向量，还要额外维护整套图结构。

倒排量化的代表是 IVF。它先用 k-means 把全库向量聚成若干个桶，查询时只访问离查询向量最近的 nprobe 个桶、在桶内精排，把全库扫描变成局部扫描。内存吃紧时再叠一层 PQ（乘积量化）：把向量切成若干段，每段用一个小的查找表压缩成短编码，常见能压缩十几到几十倍，代价是距离计算带近似误差。IVF 系内存友好、适合超大库，桶划分的质量则依赖聚类训练。

不可三角：召回、内存、延迟

无论哪个流派，选型时反复出现的是同一组三角权衡：召回率、内存占用、查询延迟，三者不可兼得。

调参本质上是在三角上滑动：加大 ef、M 或 nprobe 可以换召回率，代价必然落在内存或延迟上。理解这一点，比记住任何具体参数值都重要。

混合检索：向量不是全部

真实业务的检索从来不是纯向量问题。你几乎总需要标量过滤——按时间、租户、权限先筛一遍再搜，或者搜完再筛。这里有个容易踩的坑：如果先取向量近邻再做后置过滤，命中的 K 个里可能剩不下几个合法结果；更好的做法是存储层支持过滤与检索联合执行（前置过滤），这也是在关系库上做向量检索（如 pgvector）能覆盖大量业务的原因之一。

另一类是 BM25（经典的关键词检索算法，按词频与文档长度打分）与向量召回的融合：关键词负责精确命中产品名、错误码这类字面信息，向量负责语义泛化，两路结果用 RRF（按排名倒数加权合并）之类的策略合成一个列表。经验上，这对 RAG 召回质量的提升往往比换更强的 Embedding 模型更划算。

选型决策路径

把前面的分析收敛成几条规则：

• 百万级以下：pgvector、sqlite-vec 这类嵌入式方案。数据就在业务库里，事务、备份、权限体系全部复用，不新增运维对象。
• 百万到亿级、单机能扛：Qdrant 这类单机友好的专用库，或 Elasticsearch 的向量字段——后者适合本来就依赖它的团队。
• 十亿级以上、多租户大流量：Milvus、Weaviate 这类分布式专用系统，代价是要养一套有状态集群。
• 任何规模：都先算一笔运维账。向量数据库是有状态的存储系统，容量规划、版本升级、故障恢复、索引重建一样都不少，这部分人力成本最常被低估。

小结

向量检索的本质，是在召回率、内存、延迟之间做交换。规模小就暴力搜索或嵌入式方案；规模大了再按内存与延迟预算，在 HNSW 与 IVF 两大流派之间选择；同时别忘了标量过滤与关键词融合。对多数团队而言，真正的风险不是选错了向量数据库，而是在还不需要的时候就已经上了。