选型与前沿

前四章都站在一条 SQL 里面往下看零件。这一章把镜头拉远：同样这条多租户 RAG 查询，当向量数从 100 万涨到 1 亿、当 churn 高到 vacuum 追不上、当向量延迟变成热路径的瓶颈，该不该继续用 pgvector，又该换成什么。先把"什么稳定、什么在变、什么已过时"这条时间线讲清楚，再逐一拆 pgvector 周边的三条技术路线，最后给一棵能照着走的决策树。

5.1pgvector 的边界，与接力者 pgvectorscale

pgvector 把内核做到了点版本维护阶段（最新 0.8.2）；真正把规模上限往上推的，是它周围的扩展——首先是 Timescale（现 Tiger Data）的 pgvectorscale。

先把 pgvector 的甜点区说诚实。它不是被周边项目"打败"了，而是把自己的领域做到了收敛：类型、运算符、HNSW、iterative scan 这套，对"数据已经在 Postgres 里、向量规模在千万级以内、要和租户/语言/时间一起过滤、要事务一致性"的场景——也就是前四章那条多租户 SQL 的全部场景——已经够用且稳定。停在 0.8.2 不是停滞，是这一层的问题基本解完了。新东西，发生在它之外。

StreamingDiskANN：把"图必须装进内存"改成"压缩副本装进内存"

底层机制（比文档深一层）：pgvectorscale（Tiger Data，2025）给 Postgres 加了一个全新的索引访问方法 diskann，底子是微软的 DiskANN 图算法，但做成了 streaming。关键设计是把一条向量拆成两份存：

• 内存里只放压缩副本：每条向量经 SBQ（下面讲）压成几十到几百字节，整张图的压缩版能驻留内存。搜索阶段在压缩副本上跑图遍历——内存够、图不必装全精度。
• SSD 上放全精度原值：图遍历定位到候选后，再从磁盘流式读出这些候选的全精度向量做 rescore（重新精确算距离、重排）。

于是成本结构变了：内存成本被压缩副本的大小绑定，精度成本被磁盘 rescore 绑定。这正好绕开第 2 章那条"全精度图必须装进 RAM"的悬崖——图遍历这条热路径不再被原值大小拖住，原值只在最后 rescore 那一步从 SSD 顺序读。"streaming"指的是它能持续从图里吐候选、配合 rescore 动态决定要不要继续往下挖，而不是一次性取一个固定的候选池。

SBQ 与 Filtered-DiskANN

SBQ（Statistical Binary Quantization）是 pgvectorscale 用来生成那份"内存压缩副本"的量化方法——统计学加权的二值量化，比朴素的逐位取符号保留更多信息，配合磁盘上的全精度 rescore，把"压缩省内存"和"rescore 保精度"两件事接到了一起。它和第 1 章见过的 binary_quantize()、以及 §5.3 要讲的 RaBitQ 是同一个家族的不同手法。

pgvectorscale 还把第 4 章的过滤难题往前推了一步：它支持 label-based filtered search（Filtered-DiskANN）——把标签信息编进图结构，让过滤在图遍历内部就生效，而不是像 pgvector 那样靠 post-filter / iterative scan 在索引之外补救。这正面回应了第 4 章"带 WHERE 过滤在大规模下尾延迟爆炸"的痛点。

5.2其它路线：VectorChord，与非-HNSW 的 AlloyDB ScaNN

同一时期 Postgres 向量生态冒出两个强力挑战者——VectorChord 把建索引砍快两个数量级，AlloyDB 干脆没选 HNSW。

VectorChord：RaBitQ 量化的 DiskANN

VectorChord（pgvecto.rs 的继任者，TensorChord）走的也是 DiskANN + 量化路线，但量化用的是 RaBitQ——一种带理论误差界的随机化二值量化。它的 v1.0（2025）主打两个卖点：建索引比 pgvector HNSW 快约 100×、查询 QPS 约 2×，并打出"400k 向量 1 美元"的成本口号。把它放进选型版图：当你的痛点是建索引/重建索引太慢（回想第 2 章百万级建图动辄几十分钟、第 3 章 churn 后要 REINDEX），VectorChord 是 Postgres 生态内一个真实的备选，而不必直接跳到专用库。

AlloyDB ScaNN：连 Google 都没选 HNSW

这是给 2024 年那个"向量索引 = HNSW"直觉的最大一记纠正。Google 的 AlloyDB（兼容 Postgres）在 2025 年中 GA 的向量索引，用的不是 HNSW，而是 ScaNN——Google 自研、驱动其内部十亿级检索的算法。机制上 ScaNN 是另一条路：分区（partition）→ 量化（quantize）→ rescore，更像 IVF 家族的精装版，而非图索引。它宣称查询快至 4×、建索引快 8×、内存省 3–4×，能扩到约 10 亿向量、p95 < 25ms。

顺带一提：Postgres 终于有了原生 BM25

第 4 章讲混合检索（hybrid + RRF）时，词法这条腿当时只能用 Postgres 内置的 ts_rank 全文检索——它能跑，但打分不是真正的 BM25，相关性弱于专业搜索引擎。这一块现在被补上了：ParadeDB pg_search（V2，2025 年底）和 Tiger pg_textsearch 把真正的 BM25 带进了 Postgres，提供 @@@ 操作符和 USING bm25 索引。落到第 4 章的混合检索：向量腿走 pgvector 的 <=>，词法腿从 ts_rank 升级成 BM25，两路结果再用 RRF 融合——整条混合检索链可以全部留在 Postgres 内完成，不必为了一个像样的 BM25 引入外部搜索引擎。详见 第 4 章的混合检索一节。

5.3量化阶梯：用精度换体积，rescore 兜回精度

量化是一架阶梯——fp32 → fp16 → 二值，索引每级缩小约 2×，而 rescore 这一步把召回损失基本兜回来。

底层机制（比文档深一层）：量化就是用更少的比特表示每个分量，索引体积随之线性缩小。pgvector 原生就覆盖了这架阶梯的三级：

• vector（fp32，4 字节/维）：基线。1536 维 = 6KB/条。
• halfvec（fp16，2 字节/维）：体积砍半。半精度浮点对 embedding 这种本就含噪的数据几乎无损，召回损失通常 <1%。这是性价比最高的一级，很多生产系统的默认选择。
• 二值 bit（1 比特/维，0.125 字节/维）：经 binary_quantize() 把每个分量压成 1 位（取符号），体积只剩 fp32 的 1/32，距离用 Hamming（按位异或计数）算，极快。SBQ、RaBitQ 是这一级更聪明的变体。

为什么压成 1/32 召回还能撑住？答案是 rescore（两阶段检索）。它的套路对前面每条路线都成立：

1. 粗筛：在便宜的量化表示上检索，快速捞出一个比 k 大得多的候选 shortlist（比如要 top-10，先用二值距离捞 top-200）。
2. 精排：只对这 200 个候选，用全精度原值重新精确算距离、重排，取真正的 top-10。

关键在于：量化只用在"粗筛排序"这步，它只需要把对的候选圈进 shortlist 即可，不需要把它们之间的精细排名也算准——精细排名由全精度 rescore 负责。于是索引缩 2×–32×，召回损失往往只有 1–2%。这就是第 5.1 节 DiskANN"内存放压缩副本、磁盘放全精度 rescore"在 pgvector 层面的同构版本。

-- ① halfvec：性价比最高的一级，索引砍半，召回几乎不掉
CREATE INDEX ON doc_chunks
    USING hnsw ((embedding::halfvec(1536)) halfvec_cosine_ops);

-- ② 二值 + rescore：先用 Hamming 在 bit 上粗筛 top-200，再用全精度精排 top-10
SELECT id, content
FROM (
    SELECT id, content, embedding
    FROM   doc_chunks
    ORDER  BY binary_quantize(embedding)::bit(1536) <~> binary_quantize($1)  -- Hamming 粗筛
    LIMIT  200
) AS shortlist
ORDER BY embedding <=> $1   -- 全精度 rescore 精排
LIMIT 10;

5.4选型决策：何时 pgvector 赢，何时该换

把前四章的内核行为和这一章的周边路线合到一张决策树上——分界线落在数据量、过滤尾延迟、热路径性质和 churn 这四个轴上。

pgvector 赢的场景

• 数据已经在 Postgres 里：向量和业务表同库，省掉一套独立向量库的双写、同步、运维。这是 pgvector 最大的结构性优势，专用库给不了。
• 规模 ≲10M 向量：全精度图能舒服地装进内存，HNSW 低延迟，没到要 DiskANN 的地步。
• 要事务一致性：向量写入和业务写入在同一个事务里原子提交——"文档入库即可被检索、回滚即一起消失"。专用库的最终一致在这里是硬伤。
• 要和关系字段一起过滤：第 1 章那条 WHERE tenant_id=42 AND lang='zh' ORDER BY embedding <=> $1 ——租户、语言、时间窗的过滤和向量检索焊在一条 SQL 里，走第 4 章的 partial index / iterative scan。这是 pgvector 的主场。
• 中等 churn：写入/更新频率在 vacuum 追得上的范围内（第 3 章）。

pgvector 吃力、该上 pgvectorscale 或专用库的场景

• 上亿向量：全精度图装不进内存，撞第 2 章构建悬崖 → 上 pgvectorscale（StreamingDiskANN）或专用库。
• 纯向量热路径、延迟由向量主导：没有重的关系过滤、QPS 极高、延迟预算苛刻，向量检索本身就是瓶颈 → 专用库（Qdrant / Milvus）为这条路径做了极致优化。
• 大规模 + 重过滤的尾延迟：上亿向量还要带高选择性过滤，第 4 章的 post-filter / iterative scan 尾延迟会爆 → pgvectorscale 的 Filtered-DiskANN，或专用库的原生 payload 过滤。
• 极高 churn：写入快到 vacuum 追不上、召回持续腐烂、REINDEX 频率高到影响可用性（第 3 章）→ 专用库的写入路径通常对高频更新更友好。