pgvector 进阶:向量检索优化

很多人入坑 pgvector 是冲着"一个 Postgres 全搞定"去的:关系数据、JSONB、全文检索、向量检索都塞在一个库里,省心。demo 阶段也确实丝滑——一千条文档,<=> 算一下,top-10 召回毫秒级返回。

但数据一上量,故事就变了。十万条还行,五十万开始卡,百万级直接 P99 几秒。你盯着慢查询日志怀疑人生:不就是算个余弦吗,怎么这么慢?

答案很简单:你没用 ANN 索引,pgvector 在做全表扫描。 这篇把生产环境把 pgvector 调快调准的关键点讲透。

一、为什么默认的全表扫描撑不住

pgvector 的距离算符(<=> 余弦/内积、<-> L2、<#> 负内积)本身不挑索引。没建索引时,下面这条 SQL 老老实实扫每一行算距离再排序:

SELECT id, content, embedding <=> $1 AS distance
FROM chunks
ORDER BY embedding <=> $1
LIMIT 10;

10 万行算 10 万次距离,1536 维每次几十微秒,加起来就是几百毫秒到秒级。这叫 KNN 精确检索——100% 准,但 O(N×D),线性扩展,数据翻倍延迟翻倍。

生产环境必须换成 ANN(Approximate Nearest Neighbor,近似最近邻) 索引:牺牲一点点召回率(通常 1-3%),换几十倍的延迟下降。pgvector 内置两种 ANN 索引:IVFFlat 和 HNSW。选哪个、怎么调,是性能的分水岭。

二、IVFFlat vs HNSW:两种 ANN 怎么选

两种索引的底层逻辑完全不同,理解了差异才知道怎么选。

IVFFlat(Inverted File Flat):聚类分桶。 建索引时先用 K-means 把向量空间切成 N 个桶,查询时先定位到最近的几个桶,只在这些桶里做精确扫描。桶内是 flat(扁平)的,所以叫 IVFFlat。

• 优点:建索引快、内存占用小、构建时可调 lists(桶数)。
• 缺点:召回率对参数极敏感,桶划不好就漏召回;数据分布偏斜时表现差;需要先有数据才能训练(空表建索引没意义)。
• 关键参数:lists(一般 rows / 1000 起步)、probes(查询时探查的桶数,越大越准越慢)。

HNSW(Hierarchical Navigable Small World):分层图。 把向量组织成一张多层"跳表式"的近邻图,查询时从顶层稀疏入口逐层往下细搜,沿着边快速逼近目标。

• 优点:查询快、召回率高,对数据分布不敏感,空表也能建(边插边维护)。
• 缺点:建索引慢、内存占用大(图本身要常驻 RAM)、写入时会触发图的局部重排。
• 关键参数:m(每个节点的连接数)、ef_construction(建图时的搜索宽度)、ef_search(查询时的搜索宽度)。

给个量级感(百万级 768 维):HNSW 建索引可能要十几分钟、吃几个 G 内存,查询 P99 在个位数毫秒,Recall@10 轻松 95%+;IVFFlat 建索引快一倍以上、内存只有 HNSW 的 1/3 左右,但 probes 调不好召回会掉到 85%,查询延迟也更抖。差出来的这十几个点召回率,在 RAG 里就是"答得对不对"的差别。

怎么选?一句话:质量优先选 HNSW,资源极度紧张或写入密集再考虑 IVFFlat。 pgvector 0.5+ 已经把 HNSW 作为主推路径,官方文档和社区共识都偏向它。除非你跑在内存只有几个 G 的小机器上、或者写入极其密集(图重排成本顶不住),否则无脑 HNSW。IVFFlat 真正适合的场景是:数据静态、机器小、且你愿意花时间用评测集把 lists/probes 反复打磨——这种耐心多数团队没有。

三、HNSW 三个参数怎么调

HNSW 的全部秘密在三个参数里,记住一个总原则:值越大越准,也越慢。

建索引:

-- 1536 维余弦距离,中等规模推荐配置
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);

vector_cosine_ops 是算符族(operator class),必须和你查询用的距离算符匹配:<=> 用 _cosine_ops,<-> 用 _l2_ops,<#> 用 _ip_ops。用错算符族索引直接失效,这是个经典踩坑点。

查询时调 ef_search(注意:这是会话级 GUC,不是索引参数):

SET hnsw.ef_search = 60;  -- 默认 40,召回不够就往上加

SELECT id, content, embedding <=> $1 AS distance
FROM chunks
ORDER BY embedding <=> $1
LIMIT 10;

实战经验:m=16, ef_construction=200 是个安全起点,大多数场景够用。召回不达标的优先调 ef_search(查询时成本,不重建索引),不行再加大 m 和 ef_construction 重建。别一上来就 m=64,内存和写入延迟会教你做人。

四、混合检索:向量 + 全文,RRF 融合

纯向量检索有个老毛病:专有名词、SKU 编号、人名这些"字面量"召回不准。PostgreSQL-15.4 这种字符串,语义模型可能觉得和 最新版本数据库 最像,但你真正要的是字面命中。这时候得请全文检索上场补位。

pgvector 跑在 Postgres 上最大的红利就是:向量检索和 tsvector 全文检索天然在同一个库里,不用再接一个 ES。两边各跑一遍,用 RRF(Reciprocal Rank Fusion,倒数排名融合) 把结果合并:

-- 向量召回:top 20
WITH vec AS (
  SELECT id,
         ROW_NUMBER() OVER (ORDER BY embedding <=> $1) AS rk
  FROM chunks
  ORDER BY embedding <=> $1
  LIMIT 20
),
-- 全文召回:top 20
fts AS (
  SELECT id,
         ROW_NUMBER() OVER (ORDER BY ts_rank(tsv, q) DESC) AS rk
  FROM chunks, websearch_to_tsquery('chinese', $2) q
  WHERE tsv @@ q
  ORDER BY ts_rank(tsv, q) DESC
  LIMIT 20
)
-- RRF 融合:k=60 是经验值
SELECT id, SUM(1.0 / (60 + rk)) AS score
FROM (
  SELECT id, rk FROM vec
  UNION ALL
  SELECT id, rk FROM fts
) t
GROUP BY id
ORDER BY score DESC
LIMIT 10;

RRF 的妙处是不用归一化分数——向量距离和 ts_rank 根本不是一个量纲,直接加权基本是玄学。换成各自排名的倒数融合,稳健得多。详细的融合策略可以参考之前的混合检索文章,这里只给生产可用的骨架。

五、过滤先于检索:别让向量算白干

生产检索几乎都带条件:只看某个产品、某段时间、某租户。naive 写法是把过滤塞进同一条 SQL:

-- ❌ 危险写法:可能让 HNSW 索引直接退化成全扫
SELECT id FROM chunks
WHERE tenant_id = 42 AND status = 'published'
ORDER BY embedding <=> $1
LIMIT 10;

为什么危险?HNSW 是基于图的无监督近似检索,它不认识你的 WHERE。优化器有两种执行路径:先走索引取 top-k 再过滤(可能过滤完剩 0 条,得重试),或先过滤出子集再排序(子集大了退化成全扫)。如果过滤后的候选集小于 HNSW 的 ef_search,索引基本白建。

pgvector 0.8+ 给了解药——过滤下推到索引内部,先过滤再算距离:

-- ✅ 用 > 约束让 pgvector 走"过滤优先"路径
SET hnsw.iterative_scan = strict_order;  -- 严格保证过滤后够数
SET hnsw.max_scan_tuples = 20000;        -- 扫描上限,兜底防失控

SELECT id FROM chunks
WHERE tenant_id = 42 AND status = 'published'
ORDER BY embedding <=> $1
LIMIT 10;

经验法则:选择性高(过滤掉 90%+)的过滤,务必建普通 B-tree 索引配合(CREATE INDEX ON chunks(tenant_id, status)),让过滤先走 B-tree 缩小集合,再让 HNSW 在小集合里跑,性能往往比无脑加索引参数高一个数量级。这块和元数据过滤的思路是一脉相承的:embedding 负责"像不像",元数据负责"能不能用",而且能先卡的先卡掉。

六、百万级数据的最佳实践

数据上百万后,光调参数不够,得在工程层面做对几件事:

1. 维度别贪大。 768 维(BGE-base、text-embedding-3-small)够大多数场景,1536 维(OpenAI ada/text-embedding-3)更准但内存翻倍。能用 768 解决就别上 1536,索引内存 ≈ 行数 × 维度 × 4 字节 × 1.5(HNSW 开销),自己算清楚。
2. 批量插入再建索引,千万别逐条。 HNSW 建图开销大,逐条 INSERT 每次都触发图重排,慢到怀疑人生。正确做法:先 INSERT 全部数据(不带索引或先 DROP),再用 CREATE INDEX 一次性构建。百万级数据批量建索引几分钟到十几分钟,逐条可能跑一晚上。
3. 写入和查询分离。 高频写入会让 HNSW 的图频繁重排、内存膨胀。线上建议:写入走离线/异步,查询走只读副本,或用 TimescaleDB 之类的分区策略按时间分片。
4. 定期 REINDEX 或重建。 大量删除/更新后,HNSW 图会有"空洞",召回悄悄下滑。定期监控、必要时零停机重建(参考向量索引零停机重建那篇)。
5. JIT 该关就关。 Postgres 的 JIT 对向量查询这种短查询往往是负担,SET jit = off 在纯向量检索场景常常更快。

七、监控:别靠感觉调参

调参不能靠手感,三个指标必须盯:

-- 索引到底命中了没?
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM chunks
ORDER BY embedding <=> '[...]'::vector
LIMIT 10;

执行计划里看到 Index Scan using ..._hnsw 就是命中了;看到 Seq Scan 就是白建了,通常是算符族不匹配或 ef_search 路径被优化器放弃。

• 查询延迟:盯 P95/P99,别看平均。HNSW 偶有长尾(图重排),P99 才反映真实体感。
• 召回率:必须有评测集。留 200 条标注好的 query-relevant 对,每次调参后跑一遍,算 Recall@10。没有召回率指标的调参都是玄学。
• 内存与磁盘:HNSW 索引常驻 RAM,pg_relation_size 看磁盘,EXPLAIN ... BUFFERS 看是不是在拼命换页。

小结

• 数据上量必须上 ANN 索引,默认全表扫描撑不过十万级。质量优先选 HNSW(pgvector 0.5+ 主推),内存极度紧张再考虑 IVFFlat。
• HNSW 三参数:m(16–48)、ef_construction(128–256)、ef_search(40–100)。召回不够先调 ef_search(不重建),再调 m 和 ef_construction。算符族必须和距离算符匹配。
• 混合检索用 pgvector + tsvector,RRF 融合不用归一化分数,稳。向量找"像不像",全文找"字面命中",互补。
• 过滤先于检索:选择性高的条件建 B-tree 索引先缩小集合,再用 HNSW 跑;pgvector 0.8+ 支持把过滤下推进索引。
• 百万级要工程化:维度选 768–1536、批量插入后一次性建索引、读写分离、定期重建、必要时关 JIT。监控靠 EXPLAIN ANALYZE + P99 延迟 + Recall@10 评测集,别靠手感。

金句:pgvector 不是"装上就快"的开关,而是"调对了才快"的手艺——索引选型决定下限,参数和过滤策略决定上限,评测集决定你调的方向对不对。