什么是向量数据库？

围绕一个问题建起来的存储：哪些向量离这一个最近？以及为什么它需要和普通数据库不同的一套机制。

传统数据库回答的是精确匹配和范围问题。WHERE user_id = 42。WHERE date > '2026-01-01'。索引靠对值排序和分区让这类查询变快。

向量数据库回答的是另一个问题：已存的向量里，哪些的方向和这一个最接近？

这个问题拆不成排序，因为 embedding 有几百上千个维度，根本没有一根可以拿来排序的轴。不同的问题，不同的机制。

为什么精确检索撑不住规模

朴素做法是有效的，也值得知道：把查询和每一个已存向量比一遍，留下最近的。

1 万个向量时这没问题——是真没问题，这个规模下一个普通数组加一个循环就是合理方案。换成 1000 万个各 1536 维的向量，每次查询要算超过 150 亿次乘法。交互式使用就太慢了。

所以生产系统用近似最近邻检索：接受一点点漏掉真正最近匹配的概率，换来几个数量级的加速。

这个取舍是明的，而且可调。召回率——真正最近邻里实际被找到的比例——是你可以对着延迟拧的一个旋钮。在 RAG 里，这通常是一笔很好做的交易，因为反正有重排序模型要给候选重排，边缘上偶尔漏几个影响不大。

两种主流做法。

HNSW 建一张分层图。每个向量是一个节点，与自己的邻居相连，上层是稀疏的长程连接，下层是密集的局部连接。检索从顶层进入，朝目标大步跳，然后逐层下降到越来越细的层——就像先看全国地图，再看城市地图，最后看街道地图。快、召回率高，代价是内存开销可观，因为整张图都住在内存里。

IVF 把向量划分成簇。每次查询先和各个簇的质心比较，然后只在最近的几个簇里做穷举检索。内存更省，而召回率的代价出现在簇的边界上——真正的邻居就坐在边界另一侧，于是被漏掉。

量化可以和上面两种叠加，用更低的精度存储向量。省下大量内存，精度只掉一点点，通常很划算。

检索算法是有意思的部分，但很少是你选一个产品的理由。你实际得到的是：

元数据过滤。 在做向量检索的同时按日期、来源或权限做限制。这比听起来难——先检索后过滤可能只剩太少结果，先过滤后检索可能把索引结构搞坏。带过滤检索的质量，是各家系统之间实打实的差异点。

混合检索。 把向量相似度和关键词匹配结合起来，这稳定地胜过单用任何一种。向量管含义，关键词管错误码、函数名这类精确词。

更新和删除。 图索引不喜欢变动。在不整体重建的前提下应付频繁增删，是实打实的工程活。

运维基本功。 持久化、复制、备份、访问控制。

一份诚实的排序，从最便宜的开始：

1 万向量以下： 在应用代码里直接算相似度，不要数据库。这是个完全体面的答案，覆盖了相当多真实项目。

已有的关系型数据库： PostgreSQL 加 pgvector，就给你已经在跑的数据库添上向量检索。有事务、有 join，只有一套系统要运维。到几百万向量为止通常都是对的选择，也是人们太容易跳过去的那个选项。

嵌入式向量库： 跑在进程内的索引，不需要服务器。适合本地应用和单机部署。

专用向量数据库： 在规模大、查询量大，或者你需要开箱即用的高级过滤和混合检索时才站得住脚。

常见的错误是从这份名单的最底下开始。向量检索是一个功能，不是一套架构；为了 5 万个文本块上一个分布式系统，买到的是运维负担，一点能力都没多。

下一篇： 相似度检索到底是怎么运作的