写在前面

传统搜索靠关键词（BM25 / 倒排索引），找的是字面匹配。但"怎么提高查询速度"这篇和"如何让 SQL 跑得更快"意思一样、用词不同——关键词检索抓不到这层关系。

语义检索要的是"意思匹配"，向量检索就是它的地基。这篇讲三件事：向量检索的原理（embedding / 相似度 / ANN）、2026 主流向量库怎么选、以及为什么大多数项目 pgvector 就够了。RAG 应用是下一篇的事。

这是数据库系列之外的一篇独立稿。它把"向量库"当作数据库的一个新分支——接在《数据库系列（十）：数据存储全景》里提到的 NoSQL 之后，向量库是这个时代最新的存储类型。

一、为什么需要向量检索

回顾一下传统检索：《数据库系列（三）：索引原理》讲过倒排索引——把文档分词，建"词 → 文档列表"的映射，搜的时候按词查。它快、它准，但它是词面匹配。

词面匹配的盲区：

1
2
3
4
5
6
7

查询: "怎么让接口更快"

  关键词检索:  找含"接口""更快"的文档
              → 找不到标题是"性能优化实战""降低延迟"的文档（虽然讲的是同一件事）

  语义检索:    找"意思相近"的文档
              → 能匹配上，因为它们在语义空间里离得近

向量检索补的就是这一块——按意思找，不是按字面找。它是搜索、推荐、RAG、去重、聚类这一整类应用的底座。

二、embedding：把内容变成向量

用 embedding 模型把文本（或图片、音频）映射成一个高维稠密向量，常见维度 768 / 1024 / 1536。关键是：语义相近的内容，向量在空间里离得近。

1
2
3

"如何提升性能"     →  [0.12, -0.45, 0.88, ..., 0.03]   (1536 维)
"怎样让程序更快"   →  [0.11, -0.43, 0.85, ..., 0.05]   ← 和上面很近
"今天的午餐"       →  [-0.67, 0.21, -0.10, ..., -0.92] ← 和上面很远

这一步把"语义"这种没法直接算的东西，变成了"向量距离"这种可以算的东西。模型是预训练好的（OpenAI 的 text-embedding、开源的 BGE / e5 系列），你只管把文本喂进去拿向量。

维度越高表达力越强，但存储和计算也越贵。1536 维 × 1000 万条 = 几十 GB，量级感先有。

三、相似度：怎么算"有多近"

把"两段内容有多像"变成"两个向量有多近"，常用三种：

• 余弦相似度：看两个向量的夹角，忽略长度。最常用于语义检索（只关心方向像不像）。
• 点积：夹角 × 长度。当向量都归一化后，点积 = 余弦。
• L2 距离（欧氏）：直线距离。对绝对位置敏感。

语义检索绝大多数用余弦或点积。道理很简单：归一化后，“方向相近"就是"语义相近”。

四、为什么精确 KNN 不行，ANN 登场

最朴素的找最近邻：和库里每个向量算距离，排序取前 K。这叫精确 KNN，复杂度 O(N × d)。

1000 万条 × 1536 维 = 每次查询 150 亿次乘加。完全不可行。

于是有了 ANN（Approximate Nearest Neighbor，近似最近邻）——用空间索引结构，牺牲一点 recall（召回率）换几个数量级的加速。主流两种：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HNSW（分层小世界图）—— 当前主流首选
  · 把向量建成分层导航图
  · 查询：从顶层粗筛 → 逐层下沉到底层精修
  · 优点：查询快、recall 高
  · 代价：内存大（要存整张图），构建慢

IVF（倒排文件）+ PQ（乘积量化）—— 超大规模用
  · 先把向量空间聚成 N 个簇（质心），查询只扫最近的几个簇
  · 配合 PQ 把向量压缩省内存
  · 优点：省内存、扛超大规模（亿级）
  · 代价：recall 调参更麻烦

核心 tradeoff 就三个旋钮：recall（准不准）× latency（快不快）× memory（省不省内存）。没有银弹，按规模和精度要求选。绝大多数项目 HNSW 就够了，所以下面选型里基本都在比"谁把 HNSW 跑得又快又省"。

五、2026 向量库选型

一句话选型：

• 规模没到千万级 + 已经跑着 Postgres → pgvector（大多数项目停在这里）；
• 要托管省心、规模大 → Pinecone；
• 超大规模、有自建能力 → Milvus；
• 追性能和简洁的平衡、自建 → Qdrant；
• 做原型、几万条以内 → Chroma。

六、pgvector 为什么是默认首选（重点）

单独拎出来讲，因为这是 2026 业界共识里最该记住的一条：start with pgvector。

理由很简单：

1. 你大概率已经有 Postgres。pgvector 是它的扩展，装上就能用，CREATE EXTENSION vector，然后像普通列一样存向量、建 HNSW 索引、用 <=> 算余弦——零额外组件、零额外运维。
2. 向量数据和关系数据在一个库里。你能 JOIN 用户表、能走事务、能用现有备份/监控/权限体系。专用向量库往往要把数据同步两份，一致性是麻烦。
3. 规模天花板对多数项目够用。HNSW 索引下，几十万到千万级向量、中等 QPS，pgvector 都扛得住。真撑不住（通常是亿级 + 高 QPS）再迁不迟。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- pgvector 大概长这样
CREATE EXTENSION vector;

CREATE TABLE docs (id int, content text, emb vector(1536));
CREATE INDEX ON docs USING hnsw (emb vector_cosine_ops);

-- 语义检索 + 关系过滤一条 SQL 搞定
SELECT content
FROM docs
WHERE user_id = 42            -- 关系过滤
ORDER BY emb <=> $1           -- 余弦距离排序
LIMIT 10;

最后那个"向量相似度排序 + 关系 WHERE 过滤一条 SQL"是 pgvector 最香的地方——专用向量库做这个要绕一圈（先向量检索再回 DB 过滤，或者搞混合检索）。

小结

• 向量检索 = embedding 把语义变成向量 + ANN 高效找近邻。它补的是关键词检索"按意思找"这块盲区。
• ANN 的核心是 recall × latency × memory 的三角 tradeoff，HNSW 是当前主流首选，IVF+PQ 适合超大规模。
• 2026 选型：pgvector 默认够用、Pinecone 托管省心、Milvus 超大规模自建、Qdrant 性能简洁、Chroma 原型。
• 最重要的一条：start with pgvector——大多数项目不需要专用向量库，Postgres + pgvector 一套搞定，撑不住再迁。

下一篇《RAG 进阶》在这块地基上，讲怎么用向量检索搭一个真正好用的 RAG 系统——为什么"把 PDF 塞进向量库"的 naive RAG 已经不够了。

参考资料

• pgvector — PostgreSQL 向量扩展（GitHub）
• Pinecone — 向量数据库（官网）
• Milvus — 开源向量数据库
• Qdrant — Rust 向量搜索引擎
• pgvector vs Pinecone vs Qdrant vs Weaviate（2026 对比）
• Best Vector Databases in 2026（Encore.dev 对比）