企业网站建设研究目的意义,手机网站首页新闻模板,织梦wap网站模版,typecho移植wordpress作者#xff1a;来自 Elastic Benjamin Trent 为什么我们选择花时间研究更好的二进制量化而不是在 Lucene 和 Elasticsearch 中进行生产量化。 我们一直在逐步使 Elasticsearch 和 Lucene 的向量搜索变得更快、更实惠。我们的主要重点不仅是通过 SIMD 提高搜索速度#xff0…作者来自 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 QuantizationBBQ 都有各种优缺点。但我们需要一套静态的标准来测试两者。拥有一个独立的 “优点和缺点pros cons” 列表是一种过于定性的衡量标准。当然事物有不同的好处但我们希望有一套定量的标准来帮助我们做出决策。这遵循了类似于 Rich Hickey 解释的决策矩阵的模式。
我们的标准是
搜索速度索引速度平稳使用 HNSW 的索引速度合并速度内存减少可能该算法是否众所周知并在生产环境中经过实战测试粗粒度聚类是否绝对必要或者该算法如何公平地只使用一个质心需要强力brute force过采样才能实现 95% 的召回率HNSW 索引仍然有效并且可以在与强力类似的重新排序下实现 90% 的召回率
显然几乎所有标准都是可衡量的我们确实有一个我们认为重要的定性标准。对于未来的可支持性成为一种众所周知的算法很重要如果所有其他措施都与之相关这可能是决策的转折点。 我们如何测试它
Lucene 和 Elasticsearch 都是用 Java 编写的因此我们直接用 Java 编写了两个概念证明。这样我们就可以在性能上进行同类比较。另外在进行乘积量化Product Quantization, PQ时我们仅测试了最高 32 倍的空间压缩。虽然 PQ 可以通过减少码本数量code books进一步压缩空间但我们发现对于许多模型来说召回率会迅速下降到不可接受的水平从而需要更高比例的过采样。
此外由于优化 PQOptimized PQ对计算资源要求较高我们没有采用这种技术。
我们测试了不同的数据集和相似性指标。特别是
e5Small它只有 384 个维度与其他模型相比它的向量空间相当窄。你可以在我们的位向量博客中看到 e5small 的简单二进制量化表现有多差。因此我们希望确保二进制量化的演变能够处理这样的模型。Cohere 的 v3 模型它有 1024 个维度并且喜欢被量化。如果量化方法不适用于此方法那么它可能不适用于任何模型。Cohere 的 v2 模型有 768 个维度其出色的性能依赖于最大内积的非欧几里得向量空间。我们希望确保它能够像乘积量化一样处理非欧几里得空间。
我们在基于 ARM 的 MacBook 上进行了本地测试并在更大的 x86 机器上进行了远程测试以确保无论 CPU 架构如何我们发现的任何性能差异都是可重复的。 那么结果如何呢 e5small quora
这是一个较小的数据集使用 e5small 构建了 522k 个向量。它的维度很少嵌入空间很窄因此无法与简单的二进制量化一起使用。由于 BBQ 是二进制量化的演变因此验证它与 PQ 相比在如此不利的模型下是否有效非常重要。
在 M1 Max ARM 笔记本电脑上测试
Algorithmquantization build time (ms)brute-force latency (ms)brute-force recall 10:50hnsw build time (ms)hnsw recall 10:100hnsw latency (ms)BBQ10411199%10481796%0.25Product Quantization593972099%23966096%0.45 CohereV3
此模型在量化方面表现出色。我们希望在单个粗粒度质心中处理更多向量30M以确保我们的小规模结果实际上可以转化为更多向量。
此测试是在 Google Cloud 中一台更大的 x86 机器上进行的
Algorithmquantization build time (ms)brute-force latency (ms)brute-force recall 10:50hnsw build time (ms)hnsw recall 10:100hnsw latency (ms)BBQ998363177698%4004322990%0.6Product Quantization13116553579098%N/AN/AN/A
当谈到类似召回率的索引和搜索速度时BBQ 显然是赢家。 内积搜索和 BBQ
我们在其他实验中注意到在量化时非欧几里得搜索可能很难准确实现。此外简单的二值量化对向量的大小不敏感而向量大小对于内积计算至关重要。
带着这个需要注意的点脚注我们花了几天时间研究代数调整查询估算最后阶段的校正措施。结果是成功了
Algorithmrecall 10:10recall 10:20recall 10:30recall 10:40recall 10:50recall 10:100BBQ71%87%93%95%96%99%Product Quantization65%84%90%93%95%98% 就这样圆满结束 BBQ 与乘积量化的完整决策矩阵。 我们对更优二值量化Better Binary Quantization, BBQ感到非常兴奋经过大量的尝试和验证我们不断被其结果质量所惊艳 —— 每个向量维度仅保留 1 位信息就能达到如此效果。
敬请期待它将在未来的 Elasticsearch 版本中与你见面
Elasticsearch 包含许多新功能助您构建适合各种场景的最佳搜索解决方案。欢迎查看我们的示例笔记本以了解更多开启免费的云端试用或在本地机器上体验 Elastic 的强大功能。 原文Better Binary Quantization vs. Product Quantization - Search Labs
