跳转至

4-bit 旋转量化技术深度剖析:消除离群值的极致压缩艺术

4-bit Rotational Quantization

4-bit rotational quantization

文章背景与核心概要

在海量向量检索与大语言模型 (LLM) 部署中,高维嵌入向量的爆炸式增长给服务器内存与带宽带来了严峻挑战。传统的标量或二值量化往往受制于向量维度的“离群值” (Outliers) ,导致低比特压缩时精度急剧下滑。开源向量数据库 Weaviate 在 1.39 版本中重磅升级了旋转量化 (Rotational Quantization, RQ) 技术,正式推出 4-bit 旋转量化,并通过快速沃尔什-阿达马变换 (Fast Walsh-Hadamard Transforms, FWHT) 和 SIMD 指令级优化打通了硬件性能瓶颈。该方案在保持与原始精度近乎一致召回率的同时,将堆内存占用骤降 45%,并显著超越了 TurboQuant 等前沿方案,为亿级规模向量检索树立了极致压缩与极速查询的新标杆。


核心内容摘要

Summary

在 Weaviate 1.39 版本中,旋转量化 (Rotational Quantization, RQ) 正式拓展支持了 4-bit 量化,并同步带来了一整套全方位的底层性能升级。这些改进涵盖了旋转计算、距离算子内核、内存访问通道以及编码流水线——不仅让 8-bit RQ 的运行速度实现了质的飞跃,更全新引入了 4-bit RQ。在提供与以往相当的召回率的同时,4-bit RQ 成功将堆内存 (Heap) 占用削减了 45%。本文将深入剖析这些性能提升背后的底层技术细节,深度剖析 RQ 在亿级海量数据规模下的扩展表现,并将其与前沿的 TurboQuant 算法进行详尽的横向对比。

In Weaviate 1.39, Rotational Quantization (RQ) is extended to support 4-bit quantization alongside a comprehensive suite of performance updates. These enhancements cover rotations, distance kernels, memory access paths, and encoding pipelines—making 8-bit RQ significantly faster while introducing 4-bit RQ, which delivers comparable recall with a 45% heap reduction. This post explores the technical details behind these improvements, analyzes RQ's behavior at massive scale, and compares its performance against TurboQuant.


技术引言

Introduction

去年,我们推出了支持 8-bit 与 1-bit 规格的 旋转量化 (Rotational Quantization, RQ) 。这些量化技术能够在大幅削减内存占用的同时实现极速向量检索,并且相比标量量化 (Scalar Quantization) 和二值量化 (Binary Quantization) 等同类替代方案,拥有显著更出色的召回率表现。

Last year we introduced Rotational Quantization (or RQ) with 8-bit and 1-bit sizes. These quantization techniques allow for fast vector search, while reducing memory usage, and at better recall than comparable alternatives such as scalar and binary quantization.

在全新的 Weaviate 1.39 中,我们进一步为 RQ 赋予了 4-bit 量化能力,并带来了一整套通用的量化性能优化。旋转计算、距离算子、编码逻辑以及内存访问路径均得到了全链路重构,最终达成了显著成效:1.39 中的 8-bit RQ 运行速度迎来了大幅飞跃,而全新的 4-bit RQ 则在保持相近召回率的前提下,实现了 45% 的堆内存降幅。

Weaviate 1.39 extends RQ with 4-bit support, alongside a stack of quantization improvements in general. Rotations, distance kernels, encoding and the memory path have all been improved with net effect: 8-bit RQ is now significantly faster in 1.39 and 4-bit RQ provides similar recall with a 45% heap reduction.

本文将完整记录这一工程探索背后的技术历程,并顺带解答开发者们最常关心的两个核心问题:随着数据集规模呈几何级数膨胀,RQ 的表现依然坚挺吗?以及,RQ 相比业界大热的 TurboQuant 究竟孰优孰劣?

This post documents the story of that work, and along the way answers two questions people often ask: How does RQ hold up as datasets scale? And how does RQ compare to TurboQuant?


核心优化与架构升级

Improvements

旋转量化基于 Extended-RaBitQ 算法演进而来,通过引入结构化快速旋转机制以及简化的逐向量区间拟合,大幅提升了编码速度。极速的编码性能(即将原始高维向量转换为量化压缩表示的过程)是衡量优秀量化算法的核心指标之一,因为它直接决定了向量数据导入与构建索引时的吞吐效率。

Rotational quantization is based on Extended-RaBitQ with a structured fast rotation and simplified per-vector interval fitting to speed up encoding. Fast encoding performance (converting the original vector into its quantized representation) is an important part of a good quantization algorithm as it can have significant impacts on import performance.

这类方法的第一步,就是将原始向量与一个随机旋转矩阵相乘。这听起来或许有些反直觉,但随机旋转矩阵能赋予向量 更优异的数学特性 ——尤其是抹平各维度上的尖锐离群值,使数值更加均匀地散布在整个量化区间的全长之上。

The first step in these approaches is to multiply the original vector by a random rotation matrix. It may seem counter-intuitive but a random rotation matrix gives better properties to the vector in particular distributing the dimension values over the entire length of the quantization interval.

为了让随机旋转快如闪电,我们采用快速沃尔什-阿达马变换 (Fast Walsh-Hadamard Transforms, FWHT) 来对原始向量进行旋转。在 1.39 版本中,我们为 FWHT 增加了 SIMD 硬件指令集级优化支持。在输出结果与原有 Go 语言基线实现完全保持比特级一致 (Bit-identical) 的前提下,取得了如下显著的加速成绩:

To speed up the random rotation we use Fast Walsh-Hadamard Transforms (FWHT) to rotate the original vector. In 1.39, we added SIMD support for FWHT which led to the below improvements while being bit-identical to the Go reference:

变换类型 (Transform) 处理器架构 (CPU) 1.38 版本 (Go 原生) 1.39 版本 (SIMD 加速) 加速比 (Speedup)
FWHT64 Intel Xeon 8581C (amd64/AVX) 81.3 ns 26.5 ns 3.1×
FWHT256 Intel Xeon 8581C (amd64/AVX) 515 ns 84.5 ns 6.1×
FWHT64 Apple M1 (arm64/NEON) 67.4 ns 21.6 ns 3.1×
FWHT256 Apple M1 (arm64/NEON) 428 ns 96.2 ns 4.5×
Transform CPU 1.38 (Go) 1.39 (SIMD) Speedup
FWHT64 Intel Xeon 8581C (amd64/AVX) 81.3 ns 26.5 ns 3.1×
FWHT256 Intel Xeon 8581C (amd64/AVX) 515 ns 84.5 ns 6.1×
FWHT64 Apple M1 (arm64/NEON) 67.4 ns 21.6 ns 3.1×
FWHT256 Apple M1 (arm64/NEON) 428 ns 96.2 ns 4.5×

配合对 SIMD 编码算子内核的一系列深度优化,整套 RQ 量化家族在向量编码性能上迎来了全方位的净提升:

Together with some other enhancements to SIMD encode kernels, this led to the following net increases in encoding performance across the whole RQ family:

量化器类型 (Quantizer) 处理器架构 (CPU) 1.38 版本 1.39 版本 加速比 (Speedup)
RQ8 Intel Xeon 8581C (amd64/AVX) 27.3 µs 7.11 µs 3.8×
RQ1 Intel Xeon 8581C (amd64/AVX) 15.2 µs 6.84 µs 2.2×
RQ4 (非中心化 / uncentered) Intel Xeon 8581C (amd64/AVX) 6.36 µs 1.39 新增
RQ4 (中心化 / centered) Intel Xeon 8581C (amd64/AVX) 8.08 µs 1.39 新增
RQ8 Apple M1 (arm64/NEON) 14.7 µs 6.18 µs 2.4×
RQ1 Apple M1 (arm64/NEON) 13.0 µs 6.18 µs 2.1×
RQ4 (非中心化 / uncentered) Apple M1 (arm64/NEON) 5.65 µs 1.39 新增
RQ4 (中心化 / centered) Apple M1 (arm64/NEON) 7.00 µs 1.39 新增
Quantizer CPU 1.38 1.39 Speedup
RQ8 Intel Xeon 8581C (amd64/AVX) 27.3 µs 7.11 µs 3.8×
RQ1 Intel Xeon 8581C (amd64/AVX) 15.2 µs 6.84 µs 2.2×
RQ4 (uncentered) Intel Xeon 8581C (amd64/AVX) 6.36 µs new in 1.39
RQ4 (centered) Intel Xeon 8581C (amd64/AVX) 8.08 µs new in 1.39
RQ8 Apple M1 (arm64/NEON) 14.7 µs 6.18 µs 2.4×
RQ1 Apple M1 (arm64/NEON) 13.0 µs 6.18 µs 2.1×
RQ4 (uncentered) Apple M1 (arm64/NEON) 5.65 µs new in 1.39
RQ4 (centered) Apple M1 (arm64/NEON) 7.00 µs new in 1.39

距离算子内核优化

Distance Kernels

我们通过引入高效的 SIMD 半字节 (nibble, 即 4 位) 操作函数,使距离算子内核完美适配了 4-bit 规格。同时,在支持的硬件平台上,我们尽可能切换到了 UDOT (arm64 架构) 与 VPDPBUSD (amd64 架构) 字节点积专用指令,这也同步推动了 8-bit 量化性能的跃升。值得注意的是,8-bit 与 4-bit 的距离计算逻辑虽然十分接近,但正如我们在后文所揭示的,4-bit 对内存带宽瓶颈的缓解带来了颠覆性的连锁收益。

The distance kernels were adapted to 4-bits via use of SIMD nibble (half byte) functions. We also switched to UDOT (arm64) and VPDPBUSD (amd64) byte dot functions where possible, which also improved 8-bit quantization. Note the distance functions of 8-bit and 4-bit are similar but there is a big impact on memory bandwidth as explained in the following section.

单次查询向量至量化编码的余弦距离计算延迟 (Cosine Distance) ,1.38 版本对比 1.39 版本:

Single query→code distance computation (cosine), 1.38 vs 1.39:

算子内核 (Kernel) 处理器架构 (CPU) 维度 (d) 1.38 版本 1.39 版本 加速比 (Speedup)
RQ8 Intel Xeon 8581C (amd64/AVX2) 768 34.3 ns 16.6 ns 2.1×
RQ8 Intel Xeon 8581C (amd64/AVX2) 1024 42.8 ns 19.8 ns 2.2×
RQ4 (非中心化 / uncentered) Intel Xeon 8581C (amd64/AVX2) 768 16.0 ns 1.39 新增
RQ4 (非中心化 / uncentered) Intel Xeon 8581C (amd64/AVX2) 1024 17.7 ns 1.39 新增
RQ4 (中心化 / centered) Intel Xeon 8581C (amd64/AVX2) 768 21.9 ns 1.39 新增
RQ4 (中心化 / centered) Intel Xeon 8581C (amd64/AVX2) 1024 23.4 ns 1.39 新增
RQ8 Apple M1 (arm64/NEON) 768 24.9 ns 17.0 ns 1.5×
RQ8 Apple M1 (arm64/NEON) 1024 31.1 ns 20.0 ns 1.6×
RQ4 (非中心化 / uncentered) Apple M1 (arm64/NEON) 768 17.8 ns 1.39 新增
RQ4 (非中心化 / uncentered) Apple M1 (arm64/NEON) 1024 21.0 ns new in 1.39
RQ4 (中心化 / centered) Apple M1 (arm64/NEON) 768 24.5 ns 1.39 新增
RQ4 (中心化 / centered) Apple M1 (arm64/NEON) 1024 27.0 ns 1.39 新增
Kernel CPU d 1.38 1.39 Speedup
RQ8 Intel Xeon 8581C (amd64/AVX2) 768 34.3 ns 16.6 ns 2.1×
RQ8 Intel Xeon 8581C (amd64/AVX2) 1024 42.8 ns 19.8 ns 2.2×
RQ4 (uncentered) Intel Xeon 8581C (amd64/AVX2) 768 16.0 ns new in 1.39
RQ4 (uncentered) Intel Xeon 8581C (amd64/AVX2) 1024 17.7 ns new in 1.39
RQ4 (centered) Intel Xeon 8581C (amd64/AVX2) 768 21.9 ns new in 1.39
RQ4 (centered) Intel Xeon 8581C (amd64/AVX2) 1024 23.4 ns new in 1.39
RQ8 Apple M1 (arm64/NEON) 768 24.9 ns 17.0 ns 1.5×
RQ8 Apple M1 (arm64/NEON) 1024 31.1 ns 20.0 ns 1.6×
RQ4 (uncentered) Apple M1 (arm64/NEON) 768 17.8 ns new in 1.39
RQ4 (uncentered) Apple M1 (arm64/NEON) 1024 21.0 ns new in 1.39
RQ4 (centered) Apple M1 (arm64/NEON) 768 24.5 ns new in 1.39
RQ4 (centered) Apple M1 (arm64/NEON) 1024 27.0 ns new in 1.39

预取机制与内存访问优化

Prefetching and Memory Access

要想让距离算子内核突破 30ns 的极致速度,仅凭算力本身远远不够,还必须保证向量数据能够被 CPU 缓存极速命中。由于图结构的近似最近邻 (Approximate Nearest Neighbor, ANN) 索引(如 HNSW)在检索遍历时呈现高度离散的随机内存访问特征,内存带宽往往才是制约系统性能的头号瓶颈——而非纯粹的距离数学计算。

To achieve sub 30ns distance kernels we also need the vectors to be cached effectively by the CPU cache. As graph ANN indices (like HNSW) have scattered DRAM access, memory bandwidth is often the primary bottleneck in performance - not the distance calculation itself.

为了在 1.39 中彻底攻克这一痛点,我们针对 AMD64 和 ARM64 架构均引入了高能效的预取机制 (Prefetching) (并一举修复了 AMD64 上潜伏数年之久的预取缺陷)。预取的作用在于提前向处理器发出提示指令,告知其下一步将要用到哪些向量数据。当 HNSW 在图上扩展并准备计算邻居节点的距离时,系统会提前将下一批向量批次数据预取装载至高速缓存中。

To improve this in 1.39, we added efficient prefetching for both AMD64 and ARM64 architectures (and fixed a prefetching bug in AMD64 that was many years old). Prefetching helps by hinting to the processor what vectors will be used next. As HNSW expands to compute distances of neighbours we now prefetch or hint ahead of a batch of vector distance computations.

在包含 100 万向量、维度高达 1536 的测试索引中(压缩编码体积约 800 MB,体量远超 CPU 缓存容量),仅通过对比开启与关闭预取指令的 A/B 测试便可发现:预取优化带来了 7–11% 的查询吞吐量提升(且收益随搜索参数 ef 增大而持续扩大),同时使数据导入速度加快了 12%

On a 1M-vector index (d=1536, ~800 MB of compressed codes, far beyond CPU cache), an A/B with only the prefetch hints removed shows they contribute 7–11% query throughput (growing with ef) and 12% faster imports.

中心化与离群值消除

Centering and Outliers

在整条处理流水线已逼近硬件物理极限的速度下,我们开始全力探索 4-bit 下的召回率上限空间。其中一个极具潜力的改进方向是中心化 (Centering) 技术,已知它能为绝大多数嵌入向量数据集带来显著的召回率增益。中心化利用了一个普遍客观规律:大量模型的嵌入向量在空间中并非围绕原点对称,而是拥有非零的均值向量。我们通过在向量子集上计算出该全局均值 μ,进而在压缩编码时对零均值化后的 x − μ 进行编码,查询时使用相同的均值对查询向量进行中心化对齐,最后在计算中还原交叉项。

With the pipeline at hardware speed, we went looking for recall headroom at 4-bits. One open item was centering which we knew can add recall to many embedding datasets. Centering exploits the fact many embeddings have a non-zero mean vector. We compute this mean μ on a subset of the vectors and then encode x − μ against a single mean fitted at compression time, centering the query with the same mean, and add the cross-term back.

在多个真实数据集上的测试表明,中心化带来了惊人的精度跃升,多个数据集的 recall@10 提升了 +0.1 到 +6.1 个百分点 (pp) 。这是由于现实中的嵌入向量往往呈现出强烈的各向异性 (Anisotropic),尤其是在后期交互模型 (Late-interaction models) 中尤为突出。不过,也有部分嵌入模型在训练中进行了中心化正则化以消除该均值偏移,因此我们将该特性设计为可配置选项,用户可通过设置 centering=true 按需启用。

On many datasets centering showed significant recall improvements with recall@10 increasing by +0.1 to +6.1pp across several datasets, as embeddings tend to be anisotropic, particularly late-interaction models. However some embedding models are regularized to remove this mean so we make the feature opt-in via a flag centering=true.

此外,当对向量进行量化时,旋转后某些维度上的极端极值(离群坐标)会将量化噪声波及扩散至该向量的每一个维度。通过精准保存绝对值最大的前两个极端坐标分量,我们在中心化的基础上进一步斩获了 +0.2 到 +1.7 个百分点 (pp) 的召回率提升。不仅如此,通过对元数据字节的紧凑封装设计,我们成功将这两个坐标值无缝嵌入到了现有的 16 字节标准元数据头中,完全没有引入任何额外的内存开销。

Additionally, when quantizing a vector the most extreme rotated coordinates add quantization noise to every dimension in that vector. By storing the largest two magnitude coordinates exactly, we managed to add +0.2 to +1.7pp recall on top of centering, and by careful packing of metadata bytes, we found we could store this in the standard 16 byte metadata header we already have.


实测成果与基准测试

Results

召回率评测

Recall

下表展示了各量化方案所能达到的 recall@10 评测结果。为了精准剥离 ANN 图索引结构的影响并纯粹评估量化算法本身的保真度,此处的测试数据基于暴力搜索 (Brute Force) 方式统计得出:

The below table shows the recall@10 achievable by each quantization method. This table shows brute force recall excluding the ANN index to isolate the effect on quantization itself.

数据集 (Dataset) RQ4 recall@10 / 重排@20 (rescored@20) RQ4c recall@10 / 重排@20 (rescored@20) RQ8 recall@10 / 重排@20 (rescored@20)
dbpedia-ada002-1536-1M (cosine) 93.5 / 100.0 96.8 / 100.0 99.0 / 100.0
sphere-dpr-768-1M (dot) 90.9 / 99.4 96.3 / 100.0 98.2 / 100.0
sift-128-1M (l2) 81.4 / 97.2 87.5 / 99.3 96.7 / 99.9
glove-100-1.2M (cosine) 87.0 / 99.2 89.9 / 99.8 98.5 / 100.0
dbpedia-cohere-v2-4096-500k (dot) 98.1 / 100.0 98.5 / 100.0 99.9 / 100.0
msmarco-arctic-embed-m-768-1M (cosine) 94.7 / 100.0 95.8 / 100.0 99.3 / 100.0
nfcorpus-mlateon-mv-128 (maxsim) 72.0 / 88.6 94.1 / 99.9 93.4 / 99.9
scifact-mlateon-mv-128 (maxsim) 77.7 / 94.0 94.5 / 100.0 94.9 / 100.0
Dataset RQ4 recall@10 / rescored@20 RQ4c recall@10 / rescored@20 RQ8 recall@10 / rescored@20
dbpedia-ada002-1536-1M (cosine) 93.5 / 100.0 96.8 / 100.0 99.0 / 100.0
sphere-dpr-768-1M (dot) 90.9 / 99.4 96.3 / 100.0 98.2 / 100.0
sift-128-1M (l2) 81.4 / 97.2 87.5 / 99.3 96.7 / 99.9
glove-100-1.2M (cosine) 87.0 / 99.2 89.9 / 99.8 98.5 / 100.0
dbpedia-cohere-v2-4096-500k (dot) 98.1 / 100.0 98.5 / 100.0 99.9 / 100.0
msmarco-arctic-embed-m-768-1M (cosine) 94.7 / 100.0 95.8 / 100.0 99.3 / 100.0
nfcorpus-mlateon-mv-128 (maxsim) 72.0 / 88.6 94.1 / 99.9 93.4 / 99.9
scifact-mlateon-mv-128 (maxsim) 77.7 / 94.0 94.5 / 100.0 94.9 / 100.0

接下来尤为关键的是,我们展示了在 Weaviate 中基于真实 HNSW 索引构建下的召回率与查询性能 (QPS) 对比曲线:

Next and importantly, we show recall vs query performance in Weaviate using an HNSW index:

QPS vs recall@10 on dbpedia-openai-1M for RQ8, RQ4 and RQ4c in Weaviate 1.39, against RQ8 in 1.38 QPS vs recall@10 on dbpedia-openai-1M for RQ8, RQ4 and RQ4c in Weaviate 1.39, against RQ8 in 1.38

从图中可以清晰看到,即便是相同的 8-bit 量化器,1.39 相比 1.38 同样呈现出了跨越式的性能飙升。更为惊艳的是,4-bit 量化在大幅削减内存占用的前提下,其“性能-召回率”折线甚至全面超越了过去的 8-bit 方案。

It is quite visible the jump between 1.38 and 1.39 for the same 8-bit quantizer. Additionally the 4-bit performance to recall curves exceed 8-bit while using significantly less memory.

下图展示了在 1536 维高维向量数据集上的堆内存 (Heap) 占用对比。值得一提的是,内存降幅之所以是 45% 而非理论上的 50% 减半,是因为 HNSW 图结构的元数据(主要是紧凑打包的节点邻居连接关系)同样需要占据一定内存。作为基准参考,如果对该数据集完全不进行量化压缩,仅向量数据就需要消耗 5.7 GiB,此外还需叠加额外的图元数据开销。

Here is the heap impact on the 1536 dimension vector dataset. Note you don't see half the memory usage (only 45%) because HNSW graph metadata (mainly the packed connections) also use memory. For reference storing this dataset unquantized would take 5.7GiB plus the graph metadata.

Go heap in use on dbpedia-openai-1M: peak heap falls from 4.2 GiB with RQ8 in 1.38 to 2.3 GiB with RQ4 and RQ4c in 1.39 Go heap in use on dbpedia-openai-1M: peak heap falls from 4.2 GiB with RQ8 in 1.38 to 2.3 GiB with RQ4 and RQ4c in 1.39

得益于更极速的向量编码算子与距离计算函数,数据导入耗时同样迎来了大幅缩减。在同一数据集上,从 1.38 升级至 1.39 后,RQ8 的导入耗时下降了 16%;而全新的 RQ4 和 RQ4c 相比 1.38 基准线,耗时更是分别大幅缩减了 37% 和 32%。

Import times are also improved due to the faster encoding and distance functions. Imports on the same dataset drop 16% for RQ8 going from 1.38 to 1.39, and RQ4 and RQ4c come in 37% and 32% under the 1.38 baseline respectively.

Import time on dbpedia-openai-1M: RQ8 is 16% faster in 1.39 than 1.38, and RQ4 and RQ4c are 37% and 32% faster than the 1.38 baseline Import time on dbpedia-openai-1M: RQ8 is 16% faster in 1.39 than 1.38, and RQ4 and RQ4c are 37% and 32% faster than the 1.38 baseline

面对超大规模扩展,RQ 还能稳得住吗?

Does it hold at scale?

我们进行了一项非常硬核的扩展性实验:从 Meta 的 Sphere 语料库(基于 DPR 模型、768 维、点积距离)中随机打乱采样不同规模的子集,并在 100 万 (1M) 到高达 2.5 亿 (250M) 个向量的超大规模跨度上,使用每个测试点 1,000 次查询,直接与真实的精确基准 (Ground Truth) 对比暴力搜索下的 recall@10:

One interesting experiment we performed was to scale subsets of a shuffled sample of Meta's Sphere corpus (DPR, 768-dim, dot product) and then brute-force recall@10 against the exact ground truth, using 1,000 queries per point, from 1M to 250M vectors.

RQ quantizer recall is constant from 1M to 250M vectors RQ quantizer recall is constant from 1M to 250M vectors

量化器类型 (Quantizer) 100 万规模召回率 (Recall 1M) 1000 万规模召回率 (Recall 10M) 1 亿规模召回率 (Recall 100M) 2.5 亿规模召回率 (Recall 250M)
rq8 97.15 97.09 97.09 96.90
rq4c 94.00 93.51 93.82 93.53
rq4 84.58 83.41 84.63 85.02
Quantizer Recall 1M Recall 10M Recall 100M Recall 250M
rq8 97.15 97.09 97.09 96.90
rq4c 94.00 93.51 93.82 93.53
rq4 84.58 83.41 84.63 85.02

这项测试最重磅的发现是:在从 100 万到 2.5 亿向量的巨大跨度下,召回率几乎保持完全平稳 (Flat)。即使使用完全独立的查询集重复运行,测量波动依然被严格锁定在一个极其狭窄的区间内。

The big result here is that recall is flat across a 1M-250M range. Even re-running with independent queries still produced a fairly tight band.

该测试曲线还直观展现了二次重排 (Rescoring) 所释放出的巨大召回率红利(即使用未量化的原始高精度向量对排名前 20 的候选结果进行二次精确距离计算),并清晰证明了中心化 RQ4 (RQ4c) 在应对具有均值偏移的数据集时展现出的卓越稳健性。

This graph also clearly shows the huge recall benefit that comes from rescoring (i.e. rescoring the top 20 vector distances with unquantized vectors), and how RQ4 centered can more accurately handle datasets with skewed mean.

需要说明的是:虽然量化器本身在这一跨度下展现出了近似“尺度无关” (Scale-free) 的稳定召回表现,但近似最近邻 (ANN) 图索引本身的拓扑参数确实会随数据规模扩张而出现一定程度的性能衰减。业界应对这一现象的标准工程方案是对数据集进行合理分片 (Sharding) (在海量数据扩展时,分布式分片原本就是最佳实践推荐)。

A caveat of this result: although the quantizers can have close to scale free recall in this range, the ANN indices do have parameters that degrade with scale. One standard way to handle this is to shard the dataset appropriately (and sharding is usually recommended anyway when scaling to large datasets).

RQ4 计算均值究竟需要采样多少向量?

How many vectors does the RQ4 mean need?

中心化 RQ4 算法在计算均值 μ 时,默认仅需抽取上限为 10,000 个向量的样本即可完成拟合。在启用异步索引的情况下,这一拟合过程完全在后台自动化完成。我们通过在数据集的前 N 个向量上拟合均值,并精确测量其与全量数据真实均值之间的距离,来评估采样区间所覆盖的误差扩散:

RQ4 centered fits the mean μ, from a sample capped at 10,000 vectors by default. This is automatically completed with async indexing enabled. By fitting the mean on the first N vectors of a dataset and measuring its distance to the full-corpus mean we can measure the spread the interval covers:

Distance from the full-corpus mean as a function of the number of vectors used to fit it, on dbpedia-1M, for a random sample and for dataset order; both follow the sqrt(1/N - 1/M) sampling curve Distance from the full-corpus mean as a function of the number of vectors used to fit it, on dbpedia-1M, for a random sample and for dataset order; both follow the sqrt(1/N - 1/M) sampling curve

在默认的 10,000 (10k) 样本量下,拟合出的均值与使用 100 倍更庞大数据量算出的结果相比,在语料空间半径中的偏差已不足 ~1%。若耗费庞大算力在全量语料上强行拟合均值,所能换来的精度收益完全微乎其微(在 7 个数据集上的最大差异仅为 0.20 个百分点,甚至有两个数据集在 10k 采样拟合下的表现反而更优)。因此,RQ4 将默认训练样本上限设定为 10,000,能让系统更早享受到内存缩减带来的红利。

At the 10k default the fitted mean sits within ~1% of a corpus radius of where 100x more data would put it. Fitting on the whole corpus instead is worth nothing measurable (largest difference across seven datasets: 0.20pp, with two datasets ahead on the 10k fit). Hence for RQ4 the default training limit is 10,000 which enables memory savings to start earlier.

与 TurboQuant 算法的深度对比

Comparison with TurboQuant

围绕 RQ 技术,社区最常问到的问题之一就是它与 TurboQuant 相比究竟如何。TurboQuant 同样利用随机旋转,但其不同之处在于旋转后采用 Lloyd-Max 码本 (Lloyd-Max codebooks) 而非均匀网格对向量进行量化。

One question we get about RQ is how it compares to TurboQuant, another quantization technique using a random rotation but using Lloyd-Max codebooks instead of a uniform grid to quantize the vectors after rotation.

在下方的对比基准测试中,我们使用自身实现与目前主流的开源 TurboQuant 实现版本 进行了召回率全方位对标。如果您希望了解 RaBitQ 与 TurboQuant 在理论和实验上的更深层次对比,我们强烈推荐阅读论文 《重温 RaBitQ 与 TurboQuant:方法、理论与实验的对称性对比》(Revisiting RaBitQ and TurboQuant: A Symmetric Comparison of Methods, Theory, and Experiments) ,该文对两种算法的异同进行了更为详尽的数学解构。

For the below comparison we ran a recall benchmark of our own implementation against a popular open-source TurboQuant implementation. If you would like more details comparing RaBitQ with TurboQuant we also recommend Revisiting RaBitQ and TurboQuant: A Symmetric Comparison of Methods, Theory, and Experiments, which goes further into details of comparing the two algorithms.

数据集 (Dataset) RQ8 RQ4 RQ4c 4-bit TurboQuant (论文原版 / paper) 4-bit TurboQuant (重归一化 / renorm) 4-bit TurboQuant (中心化+重归一化 / centered+renorm)
dbpedia-ada002-1536-1M (cosine) 99.0 93.5 96.8 87.4 94.5 96.4
sphere-dpr-768-1M (dot) 98.2 90.9 96.3 76.6 91.6 95.8
sift-128-1M (l2) 96.7 81.4 87.5 80.4 81.0 85.3
glove-100-1.2M (cosine) 98.5 87.0 89.9 79.0 85.4 86.9
dbpedia-cohere-v2-4096-500k (dot) 99.9 98.1 98.5 97.4 98.2 98.2
msmarco-arctic-embed-m-768-1M (cosine) 99.3 94.7 95.8 91.5 95.1 95.9
nfcorpus-mlateon-mv-128 (maxsim) 93.4 72.0 94.1 26.8 76.2 93.2
scifact-mlateon-mv-128 (maxsim) 94.9 77.7 94.5 36.7 81.1 94.1

| Dataset | RQ8 | RQ4 | RQ4c | 4-bit TurboQuant (paper) | 4-bit TurboQuant (renorm) | 4-bit TurboQuant (centered+renorm) | | :--- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | | dbpedia-ada002-1536-1M (cosine) | 99.0 | 93.5 | 96.8 | 87.4 | 94.5 | 96.4 | | sphere-dpr-768-1M (dot) | 98.2 | 90.9 | 96.3 | 76.6 | 91.6 | 95.8 | | sift-128-1M (l2) | 96.7 | 81.4 | 87.5 | 80.4 | 81.0 | 85.3 | | glove-100-1.2M (cosine) | 98.5 | 87.0 | 89.9 | 79.0 | 85.4 | 86.9 | | dbpedia-cohere-v2-4096-500k (dot) | 99.9 | 98.1 | 98.5 | 97.4 | 98.2 | 98.2 | | msmarco-arctic-embed-m-768-1M (cosine) | 99.3 | 94.7 | 95.8 | 91.5 | 95.1 | 95.9 | | nfcorpus-mlateon-mv-128 (maxsim) | 93.4 | 72.0 | 94.1 | 26.8 | 76.2 | 93.2 | | scifact-mlateon-mv-128 (maxsim) | 94.9 | 77.7 | 94.5 | 36.7 | 81.1 | 94.1 |

在上述测试中,TurboQuant (paper) 代表论文中未做修改的原始 MSE 变体;(renorm) 代表加入了重新归一化 (Renormalization) 机制——这是后续研究中发现对提升 TurboQuant 基线性能至关重要的补丁;而 (centered+renorm) 则进一步融合了均值中心化,以实现与中心化 RQ4 的同维度公平成准对比。

Here TurboQuant (paper) is the stock TurboQuant MSE variant in the paper, (renorm) adds renormalization which has been found to be important in improving the base TurboQuant, and (centered+renorm) also adds mean centering to make things comparable with centered RQ4.

完全忠实于原始论文的 TurboQuant 在所有测试数据集上全面落败(尤其是在高各向异性的多向量模型如 mLateOn 上,性能甚至出现了断崖式崩溃)。在补齐中心化与重归一化优化后,二者的差距有所收窄,但中心化 RQ4 (RQ4c) 依然在 8 个数据集中的 7 个上稳拔头筹。

Paper-faithful TurboQuant loses on every dataset (and notably collapses with highly anisotropic multi-vector models like mLateOn). When adding centering and renormalization, the gap is closer but RQ4c wins on 7/8 datasets.

最后,细心的读者可能会发现,绝大多数开源实现中几乎看不到“8-bit” TurboQuant 的身影。这是因为在 2-bit 或 4-bit 下行之有效的 SIMD 码本加速黑魔法,在扩展到 8-bit 时会彻底失效(并伴随极其严重的性能崩塌)。相比之下,旋转量化 (RQ) 在工程适应性上展现出无可比拟的优势,能够优雅无缝地覆盖全比特位宽。

Finally, you may have noticed there is no "8-bit" TurboQuant in most public implementations. This is because the SIMD codebook trick that works at 2 or 4 bits no longer works at 8 bits (with large performance decreases). RQ is more adaptable here and usable across the full range.


如何在 Weaviate 中启用 4-bit RQ

Using 4-bit RQ

4-bit RQ 在 Weaviate 1.39 中已原生集成,只需在原有 RQ 量化器配置中指定 bits 参数即可直接使用:

4-bit RQ ships in Weaviate 1.39 as a bits setting on the existing RQ quantizer.

"vectorIndexConfig": {
  "rq": {
    "enabled": true,
    "centering": true,
    "bits": 4
  }
}

在 Python 客户端中的使用示例:

In the Python client:

from weaviate.classes.config import Configure, Property, DataType

client.collections.create(
    name="Recipes",
    vector_config=Configure.Vectors.text2vec_openai(
        quantizer=Configure.VectorIndex.Quantizer.rq(
            bits=4,
            centering=True,
        )
    ),
    properties=[
        Property(name="title", data_type=DataType.TEXT),
    ],
)

结语

Conclusion

我们非常高兴地向大家呈现对旋转量化所打造的全套性能优化,以及全新推出的 4-bit 规格。旋转量化专为极速向量编码与高频距离计算而精心打磨,在守住高水准召回率的同时,释放了极为可观的内存红利。尽管目前在 Weaviate Cloud 云服务中我们仍默认采用 8-bit,但我们强烈推荐并欢迎大家亲自体验 4-bit RQ ,感受极致的成本节约与轻量级内存表现。

We are excited to announce the suite of performance improvements we have done to Rotational Quantization, along with the new 4-bit size. Rotational quantization is tuned for fast encoding and distance calculations, achieving competitive recall and saving significant memory usage. Although we are keeping our default of 8-bit in Weaviate Cloud, we invite you to try out 4-bit RQ for cost savings and lower RAM usage.