作者来自 Elastic Benjamin Trent 及 Thomas Veasey了解非对称量化如何在几乎不影响召回率的情况下将 DiskBBQ 查询量化开销从约 20% 降低到 4%。从向量搜索到强大的 REST API Elasticsearch 为开发者提供了最全面的搜索工具集。深入体验 Elasticsearch Labs 仓库中的示例 notebooks尝试一些新功能。你也可以立即开始免费试用或在本地运行 Elasticsearch。非对称量化将 Elasticsearch DiskBBQ 在查询量化上花费的时间降低了 5 倍。我们发现过多时间被消耗在查询量化上。 DiskBBQ 最初使用与已索引文档相同的质心来对查询进行量化。不过我们可以通过使用更粗粒度的质心对查询进行量化来降低这部分成本。这在我们的测试中以极小的召回率影响提升了查询延迟表现。DiskBBQ 如何使用双层质心进行非对称量化DiskBBQ 现在使用两层质心细粒度文档质心和更粗粒度的查询质心因此查询只需对每个父质心量化一次而不是对每个文档质心量化一次。旧的思维模型是 “一个质心负责 posting list 的所有事情”。新的模型拆分了职责文档质心细粒度仍然用于 posting list 结构和文档居中。查询质心更粗粒度作为父质心可被多个文档质心复用。因此我们不再为访问到的每个文档质心独立量化查询而是按父质心进行量化并在其所有子质心之间复用这部分工作。由于随着索引规模增长我们已经在使用双层聚类逻辑因此这是一个非常自然的适配。我们可以复用查询过程中已经完成的工作。这些图片是我们目标的一个简单示意每个质心进行一次量化就会带来一次对应的开销。让我们消除它目标是显著减少我们实际需要对某个查询进行量化的次数。Elasticsearch 中非对称 BBQ 背后的数学原理为了在计算量化后的查询向量和文档向量之前对数据进行中心化我们将点积重写为并展开。我们也可以执行完全相同的操作但为查询向量 q 和文档向量 d 使用不同的质心。具体来说对于标准的 Better Binary Quantization BBQ 来说我们会量化和以估算点积中每个文档查询对的组成部分。和是标量因此对于我们计算的每个点积来说只需要额外增加两次加法操作。对于我们会在寻找最近质心时自然地计算得到。对于它可以与量化后的文档向量一起存储这只会带来 4 字节的额外开销。下面我们将讨论如何动态管理另一个项。DiskBBQ 中的非对称 BBQ我们将文档质心例如使用 k-means 聚类为个簇其中和分别表示查询质心数量和文档质心数量。这意味着从文档质心到查询质心存在一个多对一映射。我们使用索引表示文档质心并将其到查询质心的映射定义为。由于每个文档质心都对应唯一的查询质心因此对于每个量化后的文档向量我们只需要缓存一个的值。也就是说对于 posting list ( i ) 中的每个文档向量我们需要将与量化后的文档向量一起缓存。当我们开始计算查询与某个簇中文档向量之间的点积时我们会查找对应于的量化查询向量并且只计算一次然后将其用于整个 posting list 的处理。量化过程相比计算点积要昂贵得多因此这是一个非常大的净收益。这一项则使用常规 BBQ 机制进行估算。也就是说这些向量会被量化并基于量化后的向量估算点积值。然后我们可以使用公式1来计算最终的点积估算值。请注意这意味着我们最多只需要对查询量化次。此外在一次搜索过程中我们通常会访问来自同一个父质心的多个质心因为它们彼此之间距离很近。用于非对称量化的欧几里得距离修正对于欧几里得距离我们可以写成并且像上面一样处理这一项。实际上这里还有一种稍微更优雅的形式。代入之后我们得到我们可以将其重写如下修正项包括查询向量与文档质心之间差值的范数、文档向量与查询质心之间差值的范数以及查询质心与文档质心之间差值的范数。和之前一样可以作为单个浮点数与每个文档一起存储。DiskBBQ 在索引与评分中的变化在索引 / merge 阶段当质心数量足够大时可以将质心聚类为父组。 posting 元数据从“质心 ordinal 质心得分”变成了一种显式携带查询质心 ordinal 和文档质心得分的结构。这种解耦使得评分阶段能够分别从不同位置读取文档信息和查询中心化信息。对于欧几里得距离我们可以基于上面的数学公式进一步拆解- 这是 “查询向量” 到 “文档质心” 的距离。我们在查询过程中寻找最近质心时已经会计算到这一项没有新增工作。- 这是“文档向量” 到 “查询质心” 的距离。然而回顾我们最初的量化工作这一项可以直接替换之前存储的一个浮点数值因此不需要新增存储空间。- 这只是查询质心与文档质心之间的距离。它只是每个 posting list 需要额外存储的一个浮点数。对于点积空间来说实际变化更简单唯一需要变化的修正值是将改为存储。这些改动不会引入新的计算开销并且由于我们不再使用文档质心对查询进行量化因此存储开销还会略微下降。这些原始质心也不再需要和 posting list 一起存储。我们增加的一点开销是一个小型的已量化查询缓存用于处理聚类边界情况。例如查询 ( q ) 可能非常接近查询质心但可能并不比更接近。然而实际最近的三个文档质心可能具有这样的相对顺序。因此为了避免对同一个查询进行两次量化我们为该查询维护一个有限的最近量化值缓存。这里有一个对上述情况的可视化。通常在迭代过程中我们不希望在访问同一个查询质心时反复对查询进行量化从而产生不必要的风险。DiskBBQ 非对称量化性能结果下面的火焰图展示了前后对比。优化之前大约 20% 的时间花在每次访问各个簇时的查询量化上。优化之后这一比例下降到了约 4%。Flame graph 展示使用 symmetric quantization 的计算成本。Flame graph 展示在引入 asymmetric quantization 后quantization 上的计算时间减少情况。当然大部分成本仍然来自在每个 cluster 中对 vectors 进行 scoring。但每一点优化都会有帮助。下面是一个更完整的端到端性能与 recall 视图。数据集使用的是 100 万条 DBpedia 文档并由 GTE-Base 模型进行编码。在这里“sec” 表示每个 secondaryparentcluster 中的 cluster 数量。需要注意的是对称量化symmetric quantization 仍然会受到二级 cluster 大小的影响因为它同样影响我们已有的两层 clustering indexing 机制。这显示了 非对称量化 的好处移除该成本在几乎没有如果有的话召回影响的情况下提升延迟。然而我们当前索引结构的影响仍然主要由聚类中的质心打分和向量打分所主导。非对称量化移除了我们打分开销中一个令人头疼的高成本部分但在当前结构下整体影响并不显著。DiskBBQ 量化 的下一步是什么这个简单的数学方法将我们的查询量化与文档量化解耦从而带来更好的存储效率和更快的查询速度。这一能力现在已经在 Elasticsearch Serverless 中提供并将包含在 Elastic Stack 版本 9.4.0 中。这也意味着查询量化时间不再是未来决策中的直接关注点。我们可以进行更大的索引结构调整而不必担心量化与文档质心之间的稳定开销。这是一个偏技术细节的内容。希望你已经 “扛住” 了这些数学内容也希望我没有抄错。能够用简单数学去解决复杂问题总是很有趣的而且在真实用例和数据中结果确实是正向的。原文https://www.elastic.co/search-labs/blog/diskbbq-asymmetric-query-quantization
将 Elasticsearch DiskBBQ 查询量化时间降低 5 倍
发布时间：2026/5/28 23:20:56
作者来自 Elastic Benjamin Trent 及 Thomas Veasey了解非对称量化如何在几乎不影响召回率的情况下将 DiskBBQ 查询量化开销从约 20% 降低到 4%。从向量搜索到强大的 REST API Elasticsearch 为开发者提供了最全面的搜索工具集。深入体验 Elasticsearch Labs 仓库中的示例 notebooks尝试一些新功能。你也可以立即开始免费试用或在本地运行 Elasticsearch。非对称量化将 Elasticsearch DiskBBQ 在查询量化上花费的时间降低了 5 倍。我们发现过多时间被消耗在查询量化上。 DiskBBQ 最初使用与已索引文档相同的质心来对查询进行量化。不过我们可以通过使用更粗粒度的质心对查询进行量化来降低这部分成本。这在我们的测试中以极小的召回率影响提升了查询延迟表现。DiskBBQ 如何使用双层质心进行非对称量化DiskBBQ 现在使用两层质心细粒度文档质心和更粗粒度的查询质心因此查询只需对每个父质心量化一次而不是对每个文档质心量化一次。旧的思维模型是 “一个质心负责 posting list 的所有事情”。新的模型拆分了职责文档质心细粒度仍然用于 posting list 结构和文档居中。查询质心更粗粒度作为父质心可被多个文档质心复用。因此我们不再为访问到的每个文档质心独立量化查询而是按父质心进行量化并在其所有子质心之间复用这部分工作。由于随着索引规模增长我们已经在使用双层聚类逻辑因此这是一个非常自然的适配。我们可以复用查询过程中已经完成的工作。这些图片是我们目标的一个简单示意每个质心进行一次量化就会带来一次对应的开销。让我们消除它目标是显著减少我们实际需要对某个查询进行量化的次数。Elasticsearch 中非对称 BBQ 背后的数学原理为了在计算量化后的查询向量和文档向量之前对数据进行中心化我们将点积重写为并展开。我们也可以执行完全相同的操作但为查询向量 q 和文档向量 d 使用不同的质心。具体来说对于标准的 Better Binary Quantization BBQ 来说我们会量化和以估算点积中每个文档查询对的组成部分。和是标量因此对于我们计算的每个点积来说只需要额外增加两次加法操作。对于我们会在寻找最近质心时自然地计算得到。对于它可以与量化后的文档向量一起存储这只会带来 4 字节的额外开销。下面我们将讨论如何动态管理另一个项。DiskBBQ 中的非对称 BBQ我们将文档质心例如使用 k-means 聚类为个簇其中和分别表示查询质心数量和文档质心数量。这意味着从文档质心到查询质心存在一个多对一映射。我们使用索引表示文档质心并将其到查询质心的映射定义为。由于每个文档质心都对应唯一的查询质心因此对于每个量化后的文档向量我们只需要缓存一个的值。也就是说对于 posting list ( i ) 中的每个文档向量我们需要将与量化后的文档向量一起缓存。当我们开始计算查询与某个簇中文档向量之间的点积时我们会查找对应于的量化查询向量并且只计算一次然后将其用于整个 posting list 的处理。量化过程相比计算点积要昂贵得多因此这是一个非常大的净收益。这一项则使用常规 BBQ 机制进行估算。也就是说这些向量会被量化并基于量化后的向量估算点积值。然后我们可以使用公式1来计算最终的点积估算值。请注意这意味着我们最多只需要对查询量化次。此外在一次搜索过程中我们通常会访问来自同一个父质心的多个质心因为它们彼此之间距离很近。用于非对称量化的欧几里得距离修正对于欧几里得距离我们可以写成并且像上面一样处理这一项。实际上这里还有一种稍微更优雅的形式。代入之后我们得到我们可以将其重写如下修正项包括查询向量与文档质心之间差值的范数、文档向量与查询质心之间差值的范数以及查询质心与文档质心之间差值的范数。和之前一样可以作为单个浮点数与每个文档一起存储。DiskBBQ 在索引与评分中的变化在索引 / merge 阶段当质心数量足够大时可以将质心聚类为父组。 posting 元数据从“质心 ordinal 质心得分”变成了一种显式携带查询质心 ordinal 和文档质心得分的结构。这种解耦使得评分阶段能够分别从不同位置读取文档信息和查询中心化信息。对于欧几里得距离我们可以基于上面的数学公式进一步拆解- 这是 “查询向量” 到 “文档质心” 的距离。我们在查询过程中寻找最近质心时已经会计算到这一项没有新增工作。- 这是“文档向量” 到 “查询质心” 的距离。然而回顾我们最初的量化工作这一项可以直接替换之前存储的一个浮点数值因此不需要新增存储空间。- 这只是查询质心与文档质心之间的距离。它只是每个 posting list 需要额外存储的一个浮点数。对于点积空间来说实际变化更简单唯一需要变化的修正值是将改为存储。这些改动不会引入新的计算开销并且由于我们不再使用文档质心对查询进行量化因此存储开销还会略微下降。这些原始质心也不再需要和 posting list 一起存储。我们增加的一点开销是一个小型的已量化查询缓存用于处理聚类边界情况。例如查询 ( q ) 可能非常接近查询质心但可能并不比更接近。然而实际最近的三个文档质心可能具有这样的相对顺序。因此为了避免对同一个查询进行两次量化我们为该查询维护一个有限的最近量化值缓存。这里有一个对上述情况的可视化。通常在迭代过程中我们不希望在访问同一个查询质心时反复对查询进行量化从而产生不必要的风险。DiskBBQ 非对称量化性能结果下面的火焰图展示了前后对比。优化之前大约 20% 的时间花在每次访问各个簇时的查询量化上。优化之后这一比例下降到了约 4%。Flame graph 展示使用 symmetric quantization 的计算成本。Flame graph 展示在引入 asymmetric quantization 后quantization 上的计算时间减少情况。当然大部分成本仍然来自在每个 cluster 中对 vectors 进行 scoring。但每一点优化都会有帮助。下面是一个更完整的端到端性能与 recall 视图。数据集使用的是 100 万条 DBpedia 文档并由 GTE-Base 模型进行编码。在这里“sec” 表示每个 secondaryparentcluster 中的 cluster 数量。需要注意的是对称量化symmetric quantization 仍然会受到二级 cluster 大小的影响因为它同样影响我们已有的两层 clustering indexing 机制。这显示了 非对称量化 的好处移除该成本在几乎没有如果有的话召回影响的情况下提升延迟。然而我们当前索引结构的影响仍然主要由聚类中的质心打分和向量打分所主导。非对称量化移除了我们打分开销中一个令人头疼的高成本部分但在当前结构下整体影响并不显著。DiskBBQ 量化 的下一步是什么这个简单的数学方法将我们的查询量化与文档量化解耦从而带来更好的存储效率和更快的查询速度。这一能力现在已经在 Elasticsearch Serverless 中提供并将包含在 Elastic Stack 版本 9.4.0 中。这也意味着查询量化时间不再是未来决策中的直接关注点。我们可以进行更大的索引结构调整而不必担心量化与文档质心之间的稳定开销。这是一个偏技术细节的内容。希望你已经 “扛住” 了这些数学内容也希望我没有抄错。能够用简单数学去解决复杂问题总是很有趣的而且在真实用例和数据中结果确实是正向的。原文https://www.elastic.co/search-labs/blog/diskbbq-asymmetric-query-quantization
