写在前面

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

语义检索要的是"意思匹配"，向量检索就是它的地基。这篇讲三件事：向量检索的原理（embedding / 相似度 / ANN）、2026 年常见向量存储方案怎么选，以及已有 PostgreSQL 的项目该如何评估 pgvector。RAG 应用是下一篇的事。

这是数据库系列之外的一篇独立稿。向量检索并不是突然出现的新算法，但随着 embedding 与 RAG 应用普及，向量类型和 ANN 索引已经成为现代数据系统的重要能力。

一、为什么需要向量检索

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

词面匹配的盲区：

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 系列），你只管把文本喂进去拿向量。

维度不是越高就必然越好，它由模型训练目标和输出规格决定；更高维通常意味着更高的存储、内存和距离计算成本。以 pgvector 的 vector 类型为例，每个向量约占 4 × 维度 + 8 字节，仅 1536 维向量的原始列数据，1000 万条就约 57 GiB，尚未计入行、索引和副本开销。

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

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

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

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

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

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

1000 万条 × 1536 维约是 154 亿个维度比较或乘加，单次查询成本很高。不过精确检索并非“完全不可行”：数据量较小、过滤后候选集很少、需要 100% recall，或有并行计算/硬件加速时，它仍然合理。规模和并发上升后，才通常需要 ANN。

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

IVF（倒排文件）以及 PQ（乘积量化）—— 常见的大规模方案
  · 先把向量空间聚成 N 个簇（质心），查询只扫最近的几个簇
  · 一些实现可再配合 PQ 压缩向量，但两者是独立技术，并非每个 IVF 实现都带 PQ
  · 优点：省内存、扛超大规模（亿级）
  · 代价：recall 调参更麻烦

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

五、2026 向量库选型

一句话选型：

• 已经使用 Postgres，且压测证明延迟、召回率和资源占用可接受 → pgvector；
• 要托管省心、规模大 → Pinecone；
• 需要分布式架构并有自建能力 → Milvus；
• 需要独立服务、payload 过滤与 HTTP / gRPC 接口 → Qdrant；
• 做原型或本地应用快速验证 → Chroma。

六、已有 PostgreSQL 时为什么值得先评估 pgvector（重点）

单独拎出来讲，是因为已有 PostgreSQL 的团队可以用较低的系统引入成本验证向量检索；这是一条候选起点，不是跨场景的默认答案。

理由很简单：

1. 如果已经有 Postgres，可以复用现有基础设施。pgvector 是扩展，安装后执行 CREATE EXTENSION vector，就能像普通列一样存向量、建 HNSW 索引、用 <=> 计算余弦距离。它仍会增加扩展升级、索引构建、内存、VACUUM、备份和复制成本，并非“零运维”。
2. 向量数据和关系数据在一个库里。你能 JOIN 用户表、能走事务、能用现有备份/监控/权限体系。专用向量库往往要把数据同步两份，一致性是麻烦。
3. 先用现有体系验证，迁移门槛更低。pgvector 同时支持精确检索、HNSW 和 IVFFlat；是否够用不能只看“多少万条”，还取决于维度、过滤选择性、召回率、并发、写入率、内存和副本策略。先用真实数据压测，再根据证据决定是否引入专用系统。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

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

CREATE TABLE docs (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    user_id bigint NOT NULL,
    content text NOT NULL,
    emb vector(1536) NOT NULL
);
CREATE INDEX ON docs (user_id);
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;

最后这个“向量排序 + 关系过滤一条 SQL”是 pgvector 的重要优势，但还要理解执行边界：使用近似索引时，普通过滤通常发生在索引扫描之后，可能拿不满 LIMIT。pgvector 0.8.0 起可按场景启用 iterative scan；低选择性过滤还可以用普通 B-tree 做精确子集检索，固定租户可考虑部分索引或分区。最终方案必须用 EXPLAIN (ANALYZE, BUFFERS) 和精确检索基线共同验证延迟与 recall。

小结

• 向量检索 = embedding 把语义变成向量 + ANN 高效找近邻。它补的是关键词检索"按意思找"这块盲区。
• ANN 的核心是 recall × latency × memory 的三角 tradeoff。HNSW 常见于高召回低延迟场景；IVF 和量化技术适合在更大规模下控制扫描与内存成本，具体组合取决于产品实现。
• 2026 选型：已有 PostgreSQL 可先评估 pgvector；托管方案可评估 Pinecone；需要独立或分布式向量服务时，再按过滤、索引、扩缩容和运维能力比较 Milvus、Qdrant、Chroma 等产品。
• 最重要的一条：如果已有 Postgres，可以先把 pgvector 作为候选基线；是否采用，交给真实数据上的延迟、recall、写入和运维指标，而不是固定数据量口诀。

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

参考资料

• pgvector — PostgreSQL 向量扩展（GitHub）
• Pinecone — 向量数据库（官网）
• Milvus — 开源向量数据库
• Qdrant — Rust 向量搜索引擎
• Chroma — 开源 AI 数据基础设施