Pinterest 数百亿向量检索：量化与 SSD 的取舍明细

背景

Pinterest 的分布式搜索平台 Manas 部署在 80 个集群上，为首页信息流、搜索、相关 Pin、广告和通知提供检索，处理数百亿个嵌入向量。语料扩到数十亿条之后，HNSW 这类内存占用高的算法在成本和硬件分配上越来越吃紧。

离线基准：1 亿条 GraphSage 向量

• HNSW 基线：121GB，Recall@100 为 93.72%，302.5 QPS
• HNSW 加乘积量化：32GB，77.25%，276.4 QPS
• HNSW 加标量量化：50GB，92.92%，305.2 QPS
• IVF 基线：97GB，91.69%，1659.8 QPS
• IVF 加乘积量化：6.8GB，76.00%，1747.9 QPS
• IVF 加标量量化：25GB，95.71%，1588.8 QPS

怎么读这组数

标量量化把每个分量压成低比特整数，HNSW 索引缩小 59%、IVF 索引缩小 75%，召回几乎不变。乘积量化把整个向量压成紧凑的字节编码，压得更狠——HNSW 缩小 74%、IVF 缩小 93%——但召回掉到 76% 到 77%。

所以选哪种取决于你的召回下限，而不取决于压缩率本身：对内存极敏感、能接受召回折损的场景用乘积量化，其余多数情况标量量化更划算。低比特表示在算距离前要解码，团队用 SIMD 实现了线性缩放的标量量化，把查询计算降低 10% 到 15%。上线后，生产负载的服务成本降低 20% 到 30%。

把索引搬到 SSD

为了进一步降低内存成本，团队对比了两种基于 SSD 的方案。SPANN 加乘积量化的吞吐是 DiskANN 的 3 倍、延迟是它的三分之一，召回低 5%。结构是：内存里放一个小而快的质心索引，用来定位分区；大的倒排列表放在 SSD 上。

下一步：多向量

团队正在从单向量双塔转向 ColBERT 这类多向量后期交互模型，按 token 细粒度匹配。这需要改查询解析，把一个多 token 查询拆成多个向量、在不同索引上同时做近邻搜索，目前在一个内部团队试点。

为什么收录

本站「检索」话题下的信号很少，而这是一份少见的、带完整取舍明细的生产数据。它把「量化」从模型权重搬到了索引上：同一个用精度换内存的道理，本站《模型量化与数值精度》讲的是权重那一侧，这一条是向量那一侧。本条依据 InfoQ 中文对 InfoQ 英文报道的翻译，原始数据来自 Pinterest 工程团队。