原文翻译自 LanceDB Blog

作者 David Myriel, Yang Cen

September 17, 2025

为什么我们需要更好的量化

在向量检索系统中，绝大多数嵌入向量以 float32 形式存储，精度高但代价不菲：存储占用大、内存带宽压力重、查询计算量高。

乘积量化（IVF_PQ）通过训练码本并将向量拆分为子向量来近似距离，长期以来是稳健的“默认方案”。

但它在高维与大规模场景面临几项权衡：需要训练与维护码本、数据分布变化时需重训、距离估计依赖查表累加，整体速度与更新灵活性受限。

过去，LanceDB 默认采用倒排文件 + 乘积(Product Quantization)量化（IVF_PQ）策略，综合效果稳健，但在大规模与高维场景会遇到一些权衡：训练 PQ codebook成本高、数据分布变化时需重训、距离估计（查表/累加）环节相对较慢。

RaBitQ 概览

高维空间存在“测度集中”现象：单位向量的坐标在随机旋转后往往接近零且分布集中。

RaBitQ 正是抓住了这一性质，在保证误差有界的前提下，以极低的存储与计算成本近似原始向量距离与相似度。

RaBitQ 是一种“随机旋转 + 二值量化”的方法。在 LanceDB 中，它与 IVF 聚类结合形成新索引类型 IVF_RQ。

与 PQ 的codebook训练不同，RaBitQ 不需要训练，索引构建更快；在高维嵌入（512/768/1024）下误差收敛更好，查询时以二进制点积为主，配合轻量校正即可得到很好的近似排序。

💡 关键结论：RaBitQ 的估计误差为 O(1/√D)（D 为维度），维度越高误差越小，属于理论上的渐近最优；在 512、768、1024 等高维嵌入场景下，优势尤为明显。

🌟 存储占用示例：1024 维向量原始 float32：约 4096 B RaBitQ（1bit/维 + 2 个标量）：约 136 B

工作原理：从几何到实现

当你在 LanceDB/Lance 中选择 IVF_RQ 建索引时，RaBitQ 的核心流程可以概述为三步：

第一步，将向量围绕其所属聚类质心进行“残差化”并归一化；

第二步，采样一个随机正交矩阵 P 对向量进行旋转，使其落在单位球面上随机旋转后的超立方体坐标系；

第三步，仅保留每一维的符号（正/负），实现每维 1 比特的二值量化，同时为每个向量额外保存两个校正标量，以在查询时恢复更准确的距离估计。

为了便于推导，可将量化视为将向量映射到单位球面上超立方体的顶点集合。设维度为 D，定义一个二进制符号向量 v_qb 与其对应的顶点向量 v_h：

如果 v_qb[i] = 1，则 v_h[i] = +1/√D如果 v_qb[i] = 0，则 v_h[i] = -1/√D

对量化顶点向量再施加随机旋转，可得到用于近似比较的量化向量：

v_q = P × v_h

在索引构建阶段，除二值符号外，还会为每条向量记录两个轻量校正标量：

1. 与聚类质心的距离（或等价的残差范数项）

2. 原始归一化向量与其量化向量之间的点积（用于尺度校正）

到查询阶段，输入查询向量会经过同样的归一化与随机旋转处理，比较操作被转化为极快的二进制点积与小量标量校正；

通常还会采用“两阶段”流程：先用 RaBitQ 近似快速选出候选，再用全精度向量对候选进行重排以获得最终结果。

由于 RaBitQ 的近似在高维下更精确，往往需要更少候选即可达到既定召回目标，从而降低时延。

以上面图为例，上面展示了数据向量 o、其量化形式 $$\bar{o}$$以及查询向量 q 之间的几何关系。辅助向量e_1位于同一平面内。

RaBitQ 利用了这样一个事实：在高维空间中， $$\bar{o}$$在e_1上的投影高度集中在零附近（右侧红色区域）。这使我们可以将其视为可忽略不计，从而以最小的计算量实现准确的距离估计。

与 IVF_PQ 的区别：PQ 需要训练一个码本，并将向量拆分为子向量。而 RaBitQ 则完全避免了这一点。在更新数据集时，其索引速度更快，维护更简单，结果也更稳定。

与 IVF_PQ 的差异

IVF_PQ 通过训练码本并将向量拆分为子向量，距离估算依赖查表累加，CPU 上表现稳健但在高维与更新频繁的场景会受到约束；

RaBitQ 则完全避免训练，通过按位点积与轻量校正实现更快的候选生成与距离近似，尤其在高维下误差更小、召回更稳，索引构建与数据更新也更为轻量化。

IVF_PQ：倒排 + 乘积量化

- 需要训练码本，构建与维护成本高

- 距离估计查表累加，CPU 友好但难以贴近位运算吞吐

- 维度升高时召回易下滑，数据分布变化需重训

IVF_RQ：倒排 + RaBitQ

- 无需训练，构建更快、更新更稳

- 查询以二进制点积为主，易于 SIMD/GPU 并行

- 维度越高误差越小，候选更少、时延更低

基准测试与效果

在消费级 PC（CPU：Intel 12400F，无 GPU）上的公开数据集评测显示，RaBitQ 在 recall@10、QPS 与 索引构建时间方面均优于 IVF_PQ，且由于 RaBitQ 的位运算更易并行，预期在 GPU 环境下优势将进一步放大。

下图展示了两个代表性数据集的并排对比：

1. DBpedia 1M（文本嵌入，768 维）：RaBitQ 的 recall@10 提升至约 96%，吞吐提升至约 495 QPS，构建时间约 75 秒；IVF_PQ 对应约 92%、约 350 QPS、约 85 秒。

2. GIST1M（图像嵌入，960 维）：RaBitQ 的 recall@10 约 94%，吞吐约 540–765 QPS，构建时间约 21 秒；IVF_PQ 对应约 90%、约 420 QPS、约 130 秒。

💡 检索流程建议：采用“候选 + 全精度重排”的两阶段流程，在 RaBitQ 下通常可以以更小的候选集达到目标召回；在延迟受限场景，可优先考虑 IVF_RQ 以降低每次查询的计算量与内存带宽占用。

API 怎么用

下面给出最常见的配置示例（参数命名保持 Lance/LanceDB 的习惯用法）。

# Python: 使用 Lance Dataset 创建 IVF_RQ 索引import lanceimport numpy as npimport pyarrow as pa# 假设数据集已存在，向量列名为 "vector"dataset = lance.dataset("/tmp/my_vectors.lance")# 索引配置：分区数、度量类型与每维位数（当前仅支持 1）dataset.create_index(    "vector",    index_type="IVF_RQ",    metric="cosine",           # 或 "l2" / "dot"    num_partitions=256,         # 依据数据规模/延迟目标选择    num_bits=1,                 # RaBitQ 当前固定为 1 bit/维)

何时优先选择 IVF_RQ

当你的嵌入维度较高（≥512），数据规模大且多模态混合，CPU 吞吐受限且存储预算紧张，或者索引需要频繁增量更新时，IVF_RQ 往往是更优选择；

而对于压缩与召回更均衡的通用工作负载，已有的 PQ 训练流程与历史数据兼容性要求较强的系统，继续使用或混用 IVF_PQ 也是务实策略。

随着数据规模与维度演化，RaBitQ 与 IVF_PQ 可以视具体阶段进行切换，以在速度、召回与成本之间取得平衡。

生态与采用

RaBitQ 并非停留在论文层面的概念，已被诸多公司（如 Elastic、TensorChord 等）集成到产品中，实践证明其在召回与速度方面相较传统乘积量化具有显著提升。

在 LanceDB 中引入 RaBitQ 后，用户可以针对不同工作负载选型，或在数据集增长与需求改变时灵活切换，以优化 RAG、多模态搜索与分析等应用表现。

后续方向

《RaBitQ 论文》 还介绍了扩展 RaBitQ，这是一种对多位量化的推广。扩展 RaBitQ 不再将每个坐标限制为 1 位，而是允许每个维度有 2 - 4 位。这进一步降低了误差，并且在相同的压缩预算下性能可以超过乘积量化。

⚠️ LanceDB 中尚未提供扩展 RaBitQ。我们在此提及它仅作为研究背景。它展示了这项工作的发展轨迹，并且使 RaBitQ 在 1 位时高效的相同原理在需要时可以扩展到更高的精度。

推荐阅读

  点击阅读原文，跳转LanceDB GitHub