Elasticsearch：更好的二进制量化（BBQ）对比乘积量化（PQ）

作者：来自 Elastic Benjamin Trent

为什么我们选择花时间研究更好的二进制量化而不是在 Lucene 和 Elasticsearch 中进行生产量化。

我们一直在逐步使 Elasticsearch 和 Lucene 的向量搜索变得更快、更实惠。我们的主要重点不仅是通过 SIMD 提高搜索速度，而且还通过标量量化降低成本。首先是 4 倍，然后是 8 倍。然而，这还不够。通过乘积量化（Product Quantization 简称 PQ）等技术，可以在不显著降低召回率的情况下实现 32 倍的减少。我们需要实现更高级别的量化，以在速度和成本之间提供足够的权衡。

一种实现这一目标的方法是专注于 PQ（乘积量化）。另一种则是直接改进二值量化。剧透如下：

BBQ 的向量量化速度比 PQ 快 10-50 倍
BBQ 的查询速度比 PQ 快 2-4 倍
BBQ 的召回率与 PQ 相当或更好

那么，我们到底测试了什么？结果如何？

我们到底要测试什么？

从理论上讲，PQ 和 Better Binary Quantization（BBQ）都有各种优缺点。但我们需要一套静态的标准来测试两者。拥有一个独立的 “优点和缺点（pros & cons）” 列表是一种过于定性的衡量标准。当然，事物有不同的好处，但我们希望有一套定量的标准来帮助我们做出决策。这遵循了类似于 Rich Hickey 解释的决策矩阵的模式。

我们的标准是：

搜索速度
索引速度平稳
使用 HNSW 的索引速度
合并速度
内存减少可能
该算法是否众所周知并在生产环境中经过实战测试？
粗粒度聚类是否绝对必要？或者，该算法如何公平地只使用一个质心
需要强力（brute force）过采样才能实现 95% 的召回率
HNSW 索引仍然有效，并且可以在与强力类似的重新排序下实现 +90% 的召回率

显然，几乎所有标准都是可衡量的，我们确实有一个我们认为重要的定性标准。对于未来的可支持性，成为一种众所周知的算法很重要，如果所有其他措施都与之相关，这可能是决策的转折点。

我们如何测试它？

Lucene 和 Elasticsearch 都是用 Java 编写的，因此我们直接用 Java 编写了两个概念证明。这样，我们就可以在性能上进行同类比较。另外，在进行乘积量化（Product Quantization, PQ）时，我们仅测试了最高 32 倍的空间压缩。虽然 PQ 可以通过减少码本数量（code books）进一步压缩空间，但我们发现对于许多模型来说，召回率会迅速下降到不可接受的水平，从而需要更高比例的过采样。

此外，由于优化 PQ（Optimized PQ）对计算资源要求较高，我们没有采用这种技术。

我们测试了不同的数据集和相似性指标。特别是：

e5Small，它只有 384 个维度，与其他模型相比，它的向量空间相当窄。你可以在我们的位向量博客中看到 e5small 的简单二进制量化表现有多差。因此，我们希望确保二进制量化的演变能够处理这样的模型。
Cohere 的 v3 模型，它有 1024 个维度，并且喜欢被量化。如果量化方法不适用于此方法，那么它可能不适用于任何模型。
Cohere 的 v2 模型有 768 个维度，其出色的性能依赖于最大内积的非欧几里得向量空间。我们希望确保它能够像乘积量化一样处理非欧几里得空间。

我们在基于 ARM 的 MacBook 上进行了本地测试，并在更大的 x86 机器上进行了远程测试，以确保无论 CPU 架构如何，我们发现的任何性能差异都是可重复的。