非对称量化：以 97% 存储压缩实现近乎无损的延迟交互检索

TL;DR： 我们构建了一个基于延迟交互的多模态多语言搜索引擎。为了提供服务，我们建立了一个基于对象存储的向量数据库。本文将介绍非对称量化，这种方法让我们在几乎不损失性能的前提下，将存储压缩了 32 倍。

像 Wholembed v3 这样的延迟交互模型使检索更加精确，因为它们保留了细粒度信息，而不是将整个文档压缩成一个向量。但这同时也改变了存储的经济性。单个文档会产生多个嵌入向量，根据文档的复杂程度，可能产生成百上千个向量。每个向量都必须存储起来，并在后续检索中使用。

Mixedbread Search 运行在 silo 之上，这是我们针对十亿级文档规模的延迟交互检索引擎。Silo 将超过 25 亿个文档的向量存储在对象存储中，并根据查询需求将其物化到更快的存储层级。在这种规模下，每个文档每多一个字节，就会被重复数十亿次，并直接体现在每个存储文档的成本、分片冷启动时间以及每次查询需要读取的字节数上。我们需要在保持延迟交互价值所需质量的同时，找到权衡方案，降低整个系统的成本。

本文将介绍非对称量化，这是使延迟交互在生产中可行的优化之一。我们保持查询向量的较高精度，而将文档向量存储为二进制符号。在我们的内部基准测试套件中，这种方法将原始文档向量的存储平均从每文档 393 KiB 压缩到 12.28 KiB，压缩了 32 倍，同时检索质量（NDCG@10）保持在 89.65，而 fp32 基线为 90.26。

量化：让多向量存储变得实用

量化是指用低精度数值（如 int8，甚至 1 位符号）来表示高精度浮点向量。目标是在保持排序质量的同时减少有效载荷大小。这对 silo 尤其重要。对象存储提供了持久、低成本的数据持久化。为了使其适应实际工作负载，我们需要紧凑的索引来保证足够的服务速度。而在文档侧，有效载荷的大小是成本的主导因素。

朴素的延迟交互成本高昂，因为它存储了更多向量。一个标准的 3072 维单向量嵌入在 fp32 格式下每个文档需要 12 KiB。一个具有 786 个 128 维向量的多向量表示携带了更多信息，但未压缩时体积大约大 33 倍。

这里的存储数字仅指原始向量有效载荷。生产环境中的索引还包括文档 ID、元数据和布局开销。

通过二值化文档向量，一个 786 个 token 的多向量文档仅比一个 3072 维的 fp32 单向量大约 2%。这意味着，你可以支付大致单向量存储的成本，却获得延迟交互的质量。这有助于我们改变权衡。延迟交互变得默认即可实用，而不再是仅用于那些值得付出存储代价的场景。

这对延迟交互来说并非全新方向，ColBERTv2 已经展示了激进压缩可以在保持质量的同时减少延迟交互模型的体积。PLAID 则展示了可以通过优化的检索和剪枝技术将延迟交互检索的延迟降低到实用水平。对于生产系统，这两点都很重要：模型必须精确，表示必须足够廉价以便在硬件中高效传递。

为什么采用非对称量化

压缩文档向量可以节省整个语料库的存储、IO、缓存空间和冷启动时间。压缩查询向量几乎节省不了什么，因为查询量小、生命周期短，并且从不存储在索引中。

这也是我们不对双方都进行二值化的原因。全二值化检索是最紧凑的选择，但将查询也降至单个比特会丢弃排序所依赖的幅度信息，其质量损失远比仅二值化文档要大得多（后文会展示）。

因此，我们将查询保持在 int8，只将文档向量存储为二进制符号。查询保持足够精确以维持排序质量，而文档侧则获得了对服务至关重要的存储缩减。

评分技巧

二值化文档向量更小，因此存储成本更低。

对于 int8 × int8 评分，现代 ARM CPU 通过 NEON 点积指令直接支持。我们的 AArch64 内核使用 SDOT 将十六个 int8 乘法累加到 int32 通道中，然后通过 vaddvq_s32 进行水平归约得到结果。对于 int8 × 二值化评分，有用的恒等式更简单。如果每个文档维度存储为一个符号位，b_i 取 {-1, +1}，那么：

因此，评分不需要对每个维度进行完整乘法。我们需要文档正位所对应的查询值之和，以及总的查询值之和。

在内核中，文档符号被压缩成位。对于 128 维路径，我们预先计算查询总和以及八个查询位平面。每个文档 token 被加载为 16 个压缩字节，通过 NEON 整数运算进行移位和掩码操作得到八个 0/1 掩码，然后使用 SDOT 与查询位平面进行评分。最终评分使用上述恒等式：2 * 选中查询值之和 - 查询值之和。

二值化 × 二值化在计算上甚至更便宜，因为可以使用汉明距离，但质量损失太大，不适合我们的主要检索路径。

检索质量

我们在内部检索基准测试套件中评估了几种精度配对。分数是套件中 NDCG@10 的平均值，缩放至 0–100 范围。NDCG@10（归一化折损累积增益，排名 10）衡量前 10 个结果相对于理想排序顺序的好坏，相关文档出现在越靠前的位置得分越高，100 为完美排序。全精度基线平均为 90.26。int8 查询配合二值化文档平均为 89.65，下降了 0.61 分，而文档向量存储减少了 32 倍。性能下降极小，部分原因是 Wholembed v3 的训练已经考虑了 silo 的权衡，因此对量化具有鲁棒性。

在运行时方面，我们在一台 ARM 机器上对评分内核进行了基准测试，使用 33 × 128 的查询对 1000 个文档（每个文档 786 × 128）进行评分。表格报告了经过 2 次预热后 9 次测量结果的中位延迟，以及相对于 fp32 基线的加速比。

有两个有用的操作点。

如果我们希望在降低带宽和更快整数评分的同时获得最高质量，int8 × int8 在这种设置下基本上是零损失的。它在 fp32 基线之上略有提高（在测量噪声范围内），同时将文档存储减少 4 倍，并在该基准测试中运行速度快 3.2 倍。

如果我们想要最佳的存储经济性，int8 × 二值化是更有趣的点。它在保持大部分排序质量的同时，将文档向量缩小 32 倍，并且运行速度比 fp32 快 3.8 倍。对于基于对象存储的系统，这直接减少了语料库侧的字节数。

二值化 × 二值化在纸面上看起来很有吸引力。它使用与 int8 × 二值化相同的 12.28 KiB 文档存储，并且以 4.3 倍的加速比成为这里最快的选项。但它比基线下降了 7.20 分，是 int8 × 二值化下降幅度的十倍以上，尽管读取的文档字节完全相同。唯一改变的是查询。在实践中，它丢弃了太多的查询信号。

这解锁了什么

非对称量化之所以有效，是因为检索系统在查询和文档精度上的成本不同。文档向量主导了系统的长期成本：它们被存储、复制、缓存、驱逐、重新物化，并反复评分。查询向量生命周期很短，因此在查询上多花几个位，而在每个存储的文档上节省位数，是正确的权衡。

对于 silo 来说，这使得大规模部署延迟交互检索变得更加容易。更低的每文档存储成本、更快的分片冷启动，以及一个让更多时间花在评分上（从而允许更高 QPS）并减少字节搬运的硬件路径。这让我们能够获得多向量表示的质量，而无需将每个文档都视为一个巨大的 fp32 对象。

如果你对这类系统问题感兴趣，我们正在招聘。