Elasticsearch 9.5 的 DiskBBQ：把向量放到磁盘上检索，内存省 90%

做向量检索最痛的不是召回率，是内存账单。float32 的 HNSW 索引，十亿级向量要吃掉几百 GB 内存。Elasticsearch 9.x 走的是一条不同的路：把向量尽量留在磁盘上。

DiskBBQ 是什么

BBQ 是 Better Binary Quantization，9.1 起成为默认的向量索引方式；9.2 DiskBBQ GA，9.4 起成为默认。它把向量压成二值表示后放到磁盘上，查询时在磁盘上做近似检索。官方场景下，相比 float32 HNSW，内存节省可达 90% 以上，查询延迟在亚 20ms 级，内存占用与索引规模解耦。

代价

量化必然损失精度。二值化后的召回率取决于数据分布，对 embedding 维度高、语义区分细的场景（比如法律条文、医疗术语），召回衰减会比较明显。缓解手段是「二值粗筛 + 原始向量精排」，也就是先用 DiskBBQ 找候选，再用完整向量重排。ES 的实现里这条路径是支持的。

什么时候该切

你的向量规模超过内存预算，或者正在为扩容发愁——这时候 DiskBBQ 是明确的收益。数据量小（千万级以下）、内存充裕，用 float32 HNSW 更省心，别为了省内存牺牲召回。

配套的两个能力

ES|QL 现在是一等公民，管道式查询语言支持跨集群搜索，9.4 补齐了时序聚合与子查询，还内置 Arrow Flight SQL 高速导出。semantic_text 字段配合 RRF 混合检索，一次查询同时做 BM25 关键词、稠密向量、稀疏向量，再用 RRF 融合排序——开箱即用的混合搜索，不用自己拼三路结果。

迁移注意

9.x 与 8.x 的索引格式不完全兼容，大规模迁移要规划滚动重建。别指望原地升级完就完事。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

DiskBBQ把向量放磁盘，内存省90%以上，代价是二值化的召回损失。缓解手段是二值粗筛加原始向量精排，ES里这条路径是支持的。数据量千万以下、内存充裕的，还是用float32 HNSW省心。9.x和8.x索引格式不兼容，迁移要规划滚动重建。

二值量化换来的内存节省很实在，代价是召回率。做推荐召回可以接受，做语义搜索就要看业务能不能容忍丢那部分长尾。我的做法是热数据走内存索引、冷数据走 DiskBBQ，按访问频次分层。

内存省 90% 这个数字要配上召回率和延迟一起看才成立。二值量化本质是把信息压到 1 bit，多阶段重排做得再好，长尾近邻还是会丢。我们是十亿级商品向量，更关心 P99 延迟在磁盘 IO 抖动时能到多少，如果高峰期还得回表重排，省下的内存就换成磁盘 QPS 账单了。