向量数据库 Vector Database 是什么？

向量数据库是专门存放高维向量，并能按“相似程度”快速找出最接近查询内容的若干条结果的数据库系统。可以把它想成一张巨大的地图：每段文字、每张图片都被标上坐标，意思相近的挨得近，查询就是在地图上插根针，问“离这儿最近的十条是谁”。传统数据库回答“编号 42 是谁”，向量数据库回答“谁跟这句话最像”。

它是怎么回事：先变成坐标，再找邻居

坐标来自嵌入模型（embedding model）。把一段话交给它，会得到一长串数字，这串数字就是向量。OpenAI 的 text-embedding-3-small 默认输出 1536 维，text-embedding-3-large 默认 3072 维。意思接近的两段话，向量也接近。

最笨也最准的找法是暴力搜索：拿查询向量跟库里每一条比一遍，结果一定正确，但数据一多就慢。办法是近似最近邻搜索（ANN）：允许偶尔漏掉真正的邻居，换来速度的大幅提升。召回率就是没漏掉的真邻居所占的比例。

提速靠索引，主流有两路。一路是图索引，代表是 HNSW：把向量连成多层的图，上层节点少、一跳走得远，像高速公路，下层包含全部节点，像街巷。查询从最上层出发，每一步走向离目标更近的邻居，走不动就下一层，直到底层。另一路是分区索引，比如 pgvector 里的 IVFFlat：把向量分成许多块，查询只翻离自己最近的几块。

从哪来的：先有近邻搜索，后有“数据库”

最近邻搜索是个老问题，树结构在高维数据上加速有限，研究者转向允许少量误差的近似搜索。HNSW 由 Yu. A. Malkov 和 D. A. Yashunin 提出，2016 年上传 arXiv，2020 年发表在 IEEE TPAMI。

工程上的推手是 Facebook AI Research 的 Jeff Johnson、Matthijs Douze 和 Hervé Jégou：2017 年的《Billion-scale similarity search with GPUs》把搜索搬上 GPU，并开源了 Faiss。Faiss 是个库，管的是索引和搜索。2021 年 SIGMOD 上的 Milvus 论文（来自 Zilliz）指出，已有工作大多假定数据写入后不再变化，也难以支持属性过滤，于是做了专门管理向量数据的系统。向量数据库这个品类，说的就是在索引之上补齐这些数据库该有的能力。

现在在哪用：RAG 流程里的中间一环

最典型的场景是 RAG（检索增强生成）。2020 年 Patrick Lewis 等人在 NeurIPS 发表的论文，用 Wikipedia 的稠密向量索引当模型之外的“非参数记忆”，由检索器取回相关段落交给生成模型。今天的流程类似：文档切块，转成向量存进库；提问时把问题也转成向量，取回最接近的几块文字，拼进提示词交给大模型。

Anthropic 的官方文档写明，Anthropic 没有自己的嵌入模型，文档点名的服务商是 Voyage AI，并建议多比较几家。所以用 Claude 做 RAG，向量由外部嵌入模型生成，Claude 负责读检索回来的文字并作答。阿里的 Qwen3-Embedding 有 0.6B、4B、8B 三个尺寸，以 Apache 2.0 开放，支持自定义输出维度。

库有专门系统，比如 Milvus，也有装进现有数据库的做法。pgvector 是 Postgres 的扩展，保留事务和 JOIN，支持 HNSW 和 IVFFlat 两种近似索引。我们 AI主线 的建议是：数据量不大、本来就在用 Postgres 的团队，先用 pgvector 把检索跑通，规模上来了再评估专门的向量数据库。

容易混的地方：它不是模型的记忆

常见误会之一，是以为内容存进向量库，模型就“学会”了。没有，模型权重一点没变，向量库只是在提问那一刻把相关文字找出来，放进提示词。好处是知识要更新，改库就行，不用重训模型。

另一个误会，是把“相似”当成“正确”。向量检索总会返回距离最近的若干条，哪怕库里根本没有答案；近似搜索还可能漏掉真正的邻居。pgvector 的文档写得很直白：默认是精确搜索，召回完美，加上近似索引就是拿一点召回换速度。

对使用者来说，有几件事直接影响账单。向量按单精度浮点数存，1536 维的一条约 6 KB，一百万条光向量就是 6 GB 上下。pgvector 给 vector 类型建索引最多支持 2000 维，3072 维的向量得改用最多支持 4000 维的 halfvec。不同嵌入模型产出的向量不能混着比，换模型就得重新嵌入全部内容。

我们 AI主线 的看法是：向量数据库解决的是“找得到”，答案对不对，还得看切块、嵌入模型和大模型本身，别指望换个更快的库就让回答变准。