Pinterest 数百亿向量检索：量化与 SSD 的取舍明细
Pinterest 的搜索平台 Manas 在 80 个集群上服务数百亿嵌入向量。在 1 亿条向量上的离线基准里，标量量化把 HNSW 索引从 121GB 压到 50GB、召回几乎不掉；乘积量化压到 32GB，召回从 93.7% 掉到 77.3%。上线后服务成本降低 20% 到 30%。搬到 SSD 时，SPANN 加乘积量化的吞吐是 DiskANN 的 3 倍、延迟三分之一，召回低 5%。选哪种，取决于你的召回下限，不取决于压缩率。
编辑标为信号级，适合持续跟踪。
本页目录11 节
记录
信号正文
#背景
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 工程团队。
为什么是现在
为什么重要
#向量检索的成本主要在内存，而大多数团队选量化方案时只看压缩率。这份生产数据把压缩率、召回和吞吐放在同一张表里，说明决定选择的是召回下限；它还给出了把索引搬到 SSD 时两种方案的实测差距。
背景
技术背景
#HNSW 是图索引，查询快但整张图常驻内存；IVF 先把向量聚类成分区，查询时只搜少数分区。标量量化逐个分量降精度；乘积量化把向量切成子段、每段用码本编号表示，压缩率高但距离计算有近似误差。SPANN 与 DiskANN 都是为 SSD 设计的索引，区别在于把什么留在内存、把什么放在盘上。
关注人群
谁该关注
#下一步
学习路径
#- 先读《检索增强生成基础》：召回决定生成能看到什么
- 读《模型量化与数值精度》：同一个用精度换内存的道理在权重一侧
- 在你自己的数据上量一次召回下限，再决定用哪种量化
- 读《检索流水线调优》：多向量后期交互改变的是重排之前那一层
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
#- 你的检索召回下限是多少，是凭什么定的？
- 索引内存占你检索服务成本的多少？
- 在你的数据上，标量量化与乘积量化的召回差距和 Pinterest 的数字接近吗？
发布记录
收录于
#收录这条信号的技术简报，新的在前；最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考