导语：向量数据库，堪称支撑推荐系统、图像识别及大模型检索增强生成（RAG）等 AI 应用的核心基石。然而，当业务数据规模从百万级跃升至百亿甚至千亿时，如何在海量数据下平衡检索性能、召回精度与硬件成本，直接决定了 AI 应用的商业价值与可行性。 传统的 HNSW 索引虽性能优越但内存成本高昂，限制了其在超大规模场景的应用；而 IVF 系列索引在降低成本时，又常以牺牲性能和召回率为代价。RabitQ 的出现，正是为了解决这一业界难题。本文将深入剖析 RabitQ 算法从单 bit 到多 bit 版本的演进脉络与数学理论，并结合腾讯云 NoSQL 团队向量数据库（VDB）的工程实践，揭示其在并发读写、内存管理等方面的优化方案，为读者完整展示下一代向量索引技术如何兼得性能、成本与召回率。
本文作者：腾讯云NoSQL团队：何华均、霄文韬、章俊&PCG大数据部： 周建国、 白嗣东
RabitQ之前向量索引面临的现实问题
自从2017年Faiss库和HNSWlib开源后，向量索引近些年经过演进后，主要以HNSW图搜、IVF聚簇索引两大方向为主要演进路线。在RabitQ算法出来之前，在索引面临实际业务场景落地的时候，始终会面临一些客观问题：
HNSW图搜-性能好但成本高
HNSW索引以Search性能佳的特点在很多业务场景中作为向量索引盲选目标，但随着数据规模的增加，HNSW图搜默认放在机器中有限的内存资源上运行，所以硬件成本会随着数据规模的增加而线性增加。
例如在100万1024d的向量，在不量化的前提下数据本身会占用4GB内存空间，而HNSW的边也会占用内存空间，所以实际会占用5-6GB，这个成本并不昂贵，但当数据规模达到100亿其内存资源将是现在的1万倍，值得注意的是这些资源并非用于计算，而是用于存储数据。而相对来讲，传统数据库的100亿数据属于家常便饭，成本相对来讲要低数百倍。
HNSW量化在一定程度上可节约成本，通常可以使用FP16、BF16、int8三种方式进行量化，其中FP16、BF16可以进行接近2倍内存空间的压缩，在Tencent VDB已工程落地：《技术之向量数据库篇:腾讯云向量数据库如何实现召回不变，成本减半?》，int8量化虽然可以进一步降低内存使用，但我们在多组数据集验证后，其召回率会有明显下降，因此VDB暂时未考虑基于int8量化进行工程落地。
即使不考虑召回率，通过int8量化后的图索引，也只会减少4倍的空间，对于10亿、100亿乃至更大数据规模时，资源的成本依然是一个非常头痛的问题，我们需要更大的量化比，同时又希望召回率达到很高的标准。
IVF-SQ/PQ量化-低成本但性能差且召回不可控
IVF-SQ/PQ的量化等级可以做到更高，例如IVF-PQ的量化可以达到无限大，另外IVF索引在内存中并没有存放边，其额外内存较少且可控。同时IVF索引相对于FLAT暴搜，会提前将范围缩小到nprobe个聚簇中，这样相对于FLAT来讲性能通常有10倍以上的提升，所以在RabitQ正式推出前，其作为诸多业务选择百亿级规模向量存储方案之一，但是IVF同样会面临2大问题：
性能差： 相对于HNSW图搜索引的新能要低1个数量级（虽然相对FLAT会更好）。
召回率不可控： SQ和PQ的量化方式，无法从数学上证明其精度损失的范围，更多需要基于数据特征做特定的选择和细节优化来提升召回率。
关于HNSW和IVF系列的索引问题不局限于上述提到的点（例如IVF的预训练和聚簇倾斜问题），但由于本文主要聚焦召回/成本/性能，在此不再继续展开。
RabitQ改变现状格局
随着AI应用的爆发，业界对向量数据库的应用场景、规模上提出越来越高的要求，各向量服务厂商、开源组织一直通过各种方式在召回、性能、成本上下功夫，但基于工程封装始终难以找到很好的解法，这几者之间始终在现实中是彼此矛盾的，例如：DiskANN是一种磁盘方案来降低成本，但其性能表现欠佳。大家一直期待有一种相对完美的索引来解决这样的问题，RabitQ的诞生让我们对这块找到了希望。
南洋理工大学龙程老师团队的Jianyang Gao博士论证的RabitQ算法[1,2]在性能（时间）、空间（成本）、召回上把向量索引带入一个新的理论阶段。在整个向量领域，作者第一个通过数学理论证明了经过RabitQ量化后的索引，其召回误差可以控制在一个公式内“距离无偏估计器”（与原始数据的特点关系不大），而经过实际的工程实践也符合作者推导的数学公式，RabitQ最高可以做到32倍的量化，同时其性能也超越HNSW。那么接下来就RabitQ理论和实践细节将展开介绍。
RabitQ的数学理论
Rabit在2024年作者推出了1 bit版本，虽然具备32倍的量化比，但会有明显的召回率下降，需通过原始数据二次精排来提升召回，但这就导致了其性能的下降。在今年（2025年）作者推出了多bit版本，可以通过调整bit数来提升召回，实践证明通常5-7bit的量化就可以达到99的召回率，同时作者对查询性能上进行了大量的优化。
目前外部同行所推出的RabitQ版本是基于 1bit版本的，TencentVDB很有幸在多bit版本上首个进行工程落地和实践，并已正式在V2.7版正式对外服务。接下来文章内容中，我们会先介绍单bit理论基础，进一步介绍多bit的理论，同时介绍部分在TencentVDB上的工程实践。
1-bit RaBitQ [1]
公式衍变
以欧式距离为基础，RaBitQ衍生出了仅依赖内积计算的理论。首先归一化原始向量
和原始查询向量
，即：
其中c为簇心向量. D维向量的欧式距离公式计算衍生如下（三角函数）：
其中，
表示簇中原始向量到簇心的距离，可通过预计算提前保存下来；
为查询向量到簇心的距离，仅需计算一次。因此，公式中仅内积⟨q,o⟩不可提前计算。
码表构建
码本空间：假设归一化后的D维向量数据均匀地分布在单位超球面上，通过直觉，码本也应该均匀地分布在单位超球面上。为此，码本的天然构造如下：
即当时，
则是由
组成的D维向量。为了使得向量分布更加均匀，使得量化结果更好。RaBitQ通过Johnson-Lindenstrauss转换，利用随机正交矩阵PP使得码本更加分散和随机，定义如下：
计算量化码：量化的目标是从码本空间中找到一条与数据向量距离最小的向量Px作为其量化向量，即,给定一条归一化后的数据向量o，量化目标为找到：
因此, o的量化向量为
。令
其中：
当
，此时：
当
，此时：
因此，o的量化码为
，其中每一维的量化码都可仅用1bit来表示。
误差分析
RaBitQ的无偏差估计是其核心贡献之一。通过理论分析，内积⟨o,q⟩可近似表示为如下形式：
因此有，
。进而通过下面的公式来评估误差:
公式中：
是可变参数，控制误差范围
-
是常数项
因此，在置信度为
时，区间为：
误差有很大的概率在：
附近。该理论推导涉及较多的数学证明，感兴趣的同学可以查看论文原文。
内积计算
回到
的计算上。其中
可预计算。因此，仅需要计算归一化后的查询向量q与量化向量 的内积⟨,q⟩即可
其中，
- 量化查询向量q′：
基于前面的介绍,可知
每个维度的值都为：
，其符号由量化码
决定。进一步地，采用标量量化SQ的思想，将查询向量q′的每个维度值量化为Bq个比特表示的整数。令：
则标量量化计算公式如下:
其中 是从均分分布的[0,1]区间中采样得到,
。因此q′的量化向量
为：
计算量化向量内积: 将内积计算转
和
的内积
其中：
和
可预计算保存下来，
查询全流程中仅需计算一次。因此，剩下的任务仅需计算：
其中，
由0和1组成，
由Bq-bits的整数组成。快速计算
：基于PQ的思路，可通过两种方案快速计算量化码的内积。
1. 单向量计算方案： 基于二进制“与”运算（bitwise-AND）和popcount（数1）运算。此方案适用于单个数据向量的距离估计，核心思想是将整数内积分解为二进制位操作，利用现代CPU的位指令（如AND和popcount）实现高效计算。
原理
- 位分解：将查询向量的量化代码
的每个维度，分解为Bq个二进制位，即:
其中：
表示
的第 j 位，如，当
时，
分别为：
内积分解：将内积分解为二进制运算
其中：
是两个二进制的内积，可通过位运算操作快速计算，即“与”运算后进行popcount运算，下图展示了分解过程：
● 硬件加速与优势：
指令支持：现代CPU（如x86）提供单周期位操作（AND）和popcount指令，延迟极低。
效率：仅需进行Bq次二进操作和在D-bit上做popcount操作，位操作效率远高于整数乘加。
2. 批量计算方案-基于SIMD和LUTs的FastScan：其设计灵感来自PQ的FastScan实现，通过子段分割、查找表（LUTs）和SIMD指令实现高吞吐量。
原理
● 子段分割：将数据向量的量化码
(D维)分解为M个子段，每个字段包含4位，即M=D/4。
● 预计算LUTs：为每个子段 i (1≤i≤M)生成一张查找表(LUT)，其包含16个条目（4位bits对应的值0-15），用 s表示。每个条目存储预计算的内积值：
○ s是子段值（0-15）
○
是查询向量在第i个子段对应的4个维度的量化值(Bq-bits整数)；
○ 实际计算的内积为：
其中： 是s的第k位，
是子段 i 中的第 k 个维度量化值。
● SIMD并行查表: 使用SIMD指令（如AVX2，AVX512）批量处理数据向量，以子段值为索引并行检索LUTs，累加最终的内积。
● 数据打包：将数据向量的量化代码分组为批量（如32个向量一组），并且对齐每个向量的子段值，打包到SIMD寄存器（如AVX2的256位寄存器可存32个8位值）。
两种方案共同支撑了RaBitQ在ANN搜索中的高效性，平衡了灵活性与吞吐量。实际系统中，可根据查询模式动态选择方案（如IVF索引中，批量处理候选向量）。此设计体现了RaBitQ在理论严谨性（无偏估计）与工程优化（硬件加速）间的平衡。
多bits版RaBitQ [2]
回顾1-bit RaBitQ，其通过正交旋转矩阵P，将归一化后的数据向量o，映射到码表空间Cr中：
然而，其量化得到的量化码
的值仅为0或1，导致最终得到的误差仍然较大。因此，作者2025年提出了Extending RaBitQ，即多比特版RaBitQ。主要的扩展在于提供了更精细的码本空间（B比特）。
码表构建
码本空间：
如下图所示，左图为集合
，
右图中红色实心点为归一化后的向量
计算量化码：目标为找到
，使得距离
最小。令
最小时，
是
中对应的向量
论文中提供了快速寻找
的方法，感兴趣的同学可以查看原论文。
由码本空间
的定义，可将
表示为如下形式：
其中,对于任意
, 有
，即
为o的量化码向量。
内积计算：
的估计与1-bit版RaBitQ一样，为
。因此，多比特版本也需要实时评估
的大小。
由此可见，上述公式中，仅
需实时计算，其中
同样可采用SQ对其进行量化。
由 B-bits的整数组成，当 B等于1时，上述计算可退变成1-bit版RaBitQ。由于1-bit的计算速度很快，所以作者进一步地将
拆解成了两部分：
可知：
(1-bit), 如下图所示：
基于此分解后，可基于1-bit版RaBitQ提供FastScan方案快速计算：
，进而提供的误差估计快速剔除不可能ANN候选集的向量。进一步地，再计算候选向量的余下部分
。最终的内积为：
其中，当B=5或B=9时，
为4-bits和8-bits，可根据现存的多种量化技术快速计算。同时，当B=3,4,7,8时，效率仍然十分可观。
实验
1-bit版Rabit实验
在1-bit版RaBitQ实验中，作者对比了普通PQ，4bitPQ（ScaNN），优化版本的PQ（OPQ/LSQ），以及HNSW。实验结果表明，1-bit版RaBitQ在精度和召回上均远好于IVF-PQ，并且提供了更极致的压缩比例。
多bit版Rabit实验
在多bits版RaBitQ的实验中，可直观地看到bit设置的越大，RaBitQ能获得的最大召回率越高，同时QPS会有所下降，但仍然比LVQ性能高。
实验结论
10倍+性能： 在同等召回率下，其性能大约是HNSW的1.5倍，是IVF-PQ的15-20倍。
1/10成本： 满足同等召回率下，其成本只有HNSW的1/10左右
召回随着维度和bit数增加而增加： 作者提出的“距离无偏估计器”公式上与之对应，实验也证明同等bit数下随着维度增加召回率会随之上升。
TencentVDB在RabitQ工程落地
作者开源了RabitQ-lib库，其代码已接近工程实践水准，并进行了AVX-512的指令集优化。
不过在与VDB的框架结合过程中，依然避免不了诸多改造。框架与接口本身的适配，以及部分bug修复这里不一一说明，本文主要聚焦于内存存储结构和指令集的改造，主要包括以下几点：
● 开源版RabitQ不具备流式写入（增、删、改）能力，VDB需要提供这样的能力，才可以满足最终用户对数据的CRUD操作。
● 开源版RabitQ在聚簇内部实现时，直接采用一大块连续内存存储向量数据，这种实现针对静态数据是高效的，但如果数据是持续写入和更新的，则不够高效：如果采取预分配策略，则前期可能导致大量内存空间浪费；预分配空间写满后，后续新增导致扩容时，会导致数据拷贝和内存临时翻倍的问题，影响在线读写延迟。
● 开源多bit版RabitQ默认不支持avx-2指令集，导致在相对低端的机型上无法运行。
内存体系结构Segment化
内存布局&运行访问
TencentVDB基于IVF-RabitQ代码，对其内存管理部分进行了重构，将聚簇内的内存存储结构从整块连续内存，优化为多Segment的分段连续存储的方式。
● 无大内存分配：此时一个聚簇内部不在是一块大的数组，而是有1-N个Segment组成，每个Segment的内存size是可控的，且按照cache line对齐，避免False Sharing。因此后续新增数据时，只需要追加新的Segment数据块，从而避免数据拷贝。在代码层面VDB使用SegmentCluster来实现每个聚簇数据的存储：
○ num_表示该聚簇的条目总量
○ batch_data_表示1bit量化数据，分段存储。vector的每个元素是一个char指针，指向Segment大小的连续存储空间，表示为：
■ 其中BatchSize为32，即32个向量数据为1个基本单元。
■ padded_dim是按照64位对齐之后的向量维度，用于加速SIMD指令集的处理速度。
■ f_add，f_rescale以及f_error是预计算的3个相关因子，每个向量1组，用于加速距离无偏估计。
■ Factor是可调的放大系数，用于控制单个Segment的实际向量个数。一定取值范围内，Factor越大，则检索效率越高（连续内存寻址，可加速向量距离计算），但空间浪费可能越大，新增Segment的分配时间可能越长。实测发现，Factor取值为8，能较好的平衡空间占用和检索性能。
○ ex_data_表示额外bit量化数据，同样分段存储，和batch_data_结构相似。vector的每个元素是一个char*指针，同样指向Segment大小的连续存储空间，表示为：
● 多Segment快速寻址：经过多Segment调整后，通过统一的外部业务id到内部id映射，可快速定位到对应的聚簇Cluster、Segment、Segment内的offset偏移量。
● 读写加锁范围：Segment化后，当数据要进行读写并发操作时，会针对局部Segment进行加锁（分段锁），例如聚簇内有100个Segment，此时读写并发过程中“锁冲突概率”降低到：1/100，可以有效地提升系统的吞吐能力。
插入数据到Segment
● 首先，计算出距离新数据距离最近的聚簇，该聚簇即为新数据插入的目标聚簇。
● 接着，尝试追加新数据到该聚簇的最后一个Segment的空闲区域，确保整体数据的紧密排布，从而充分利用空间。
● 如果Segment不存在空闲区域，则会创建新的Segment写入数据，这使得后续一段时间内持续写入“无需频繁分配”内存。
从Segment上删除和修改数据
● 尝试将Segment的尾部数据填充到删除数据的位置，确保删除后数据依然密集分布。通常的数组元素删除操作，需要将“数组元素大量向前移动的方式”来完成删除空间的填充，其时间复杂度是O(n)，而改进后的方式时间复杂度是O(1）
● 跨Segment移动的处理2种方式：
○ 方案1：始终只保持最后1个Segment尾部存在空闲空间，其余的Segment删除数据时，都从最后一个Segment的尾部数据移动填补，所有插入数据也从最后一个Segment尾部追加。该方式简单直接，无需维护Free-list和空间碎片整理，如果最后一个Segment无数据时，可以整块内存直接释放，不会破坏整体结构。不过删除和修改数据时会出现跨Segment加锁，以及并发写入时，锁冲突概率相对较高。
○ 方案2：每个Segment删除数据时，从当前删除数据所在Segment上移动其尾部数据到被删除的位置，确保Segment空间前缀部分是紧凑的，该方式在追加数据时，锁冲突会更小，删除阶段不会出现跨Segment加锁。但该方法需要维护Free-list，期间内存空间会出现碎片，如果集中整理空间碎片可能会导致业务出现抖动。
● 当发生修改时，VDB是通过先删除、再插入的方式进行封装，也就是复用上述删除和新增的两个步骤来完成。
AVX2指令集适配改造
RabitQ算法相比其他量化算法，存储空间小的一大关键在于量化后的向量各个元素通过高位打包，低位拼接的形式存储量化后的向量；召回率高的另一关键在于量化向量解压缩后，配合预先计算好的误差参数得到相对无损的距离；计算速度快在于硬件加速，引入更多向量寄存器的avx2/avx512指令集的SIMD计算架构比较适合当前的任务。
需要硬件加速的地方主要是涉及到到量化码的压缩/解压缩部分、以及部分计算结果累加的代码。
量化向量解压缩
压缩和解压缩是适配的。压缩阶段将量化后的向量的高位元素打包进一个为一个最近整型，低位不断拼接到多个8位整型数组中。最终合并到一起。期间大部分为移位操作，且性能约束低，直接使用SSE指令比较通用；解压缩阶段avx指令贯穿其中。解压缩阶段目的是将向量恢复压缩前的状态，此时主要涉及到查询场景，性能要求更高。
我们以以3bit版本的压缩和解压缩为例, 了解压缩原理并为其适配解压的代码，剩余的其他1~8bit的解压缩程序虽然都不一样，但原理近似。
● 压缩3bit：以长度为64的向量，3bit压缩，向量元素取值为unit8：0~2^3-1 = 0~7。我们以下述向量为例
● 解压3bit：以avx 512为例，解压缩时主要是将低位和高位还原，其还原原理图示如下。对于avx2而言，即是将一次性处理512bit转换为分两次各处理256 bit即可。
● 3bit 示例code：
其基本逻辑遵循解包的流程，主要包括以下几步：
● 从内存中一次性加载此前被压缩的64个向量元素的：低位的128位数据到128个XMM寄存器（占16byte）、以及高64位到一个64bit的整型中（占8byte）
● 解出64个向量元素压缩前的低2位：利用整数左移函数，分批将128位共计64个向量元素拆解为4组，每组16个向量元素，与低位mask 按位&
● 解包64个向量元素压缩前的高1位：移位解，2个64位整型组合成一个128位向量，与高位mask求与，得到64个元素的高1位
● 合并高低位，加载解包向量到256个YMM寄存器，执行内积计算
avx2/avx512 性能对比
使用ann-benchmark评测，avx2 性能微弱于avx512，整体强于Faiss标准库；以SIFT-1M数据集为例，在topk=10、100下，avx2/avx512优于Faiss，且索引文件size大幅降低4倍于Faiss IVF
机器环境：
● CPU: AMD EPYC 9754 128-Core Processor
● 内存：64GB
向量索引的进一步探索
RabitQ是一种量化方式，目前VDB已提供多bit版IVF-RabitQ，后续还会进一步提供HNSW-RabitQ索引服务，其综合HNSW的图搜与RabitQ的空间量化和计算代价低的优势。
RabitQ的思路将向量索引算法带入一个新的阶段，不过向量索引本身还依然存在其它的工程问题是RabitQ也无法解决的。例如: IVF索引的聚簇倾斜问题依然会发生，RabitQ通过算法虽可以极大减少input query向量与聚簇内每个向量的计算代价，但其并不能解决input query命中数据倾斜的聚簇时，其匹配的向量数量会突然变多，我们需要通过其它的手段来处理以下几个重点：
● 发现聚簇倾斜（可观测）
● 不断优化“采样算法”让数据尽可能不倾斜，简单的思路是让倾斜的聚簇按照比例采集更多的样本，调整步长让采集的数据可分布在更大的写入时间序中
● 有效减少扫描行数，即使命中倾斜的聚簇，也依然可以保证稳定的性能和高召回
● 控制相对稳定的扫描行数，随着聚簇内数据规模增加，不会导致检索性能线性增加
VDB团队也在上述方向上持续探索算法有一段时间，并已在理论和实验上取得一定的突破，将在此基础上构建自研索引（IVF-ABQ），其核心理论基础是基于三角函数中的距离和夹角来划分Blocking的思路。
目前VDB已在1million~1billion多组数据集下（开源/业务）实验验证结论，通过IVF-ABQ算法在几乎不降低召回的前提下，可减少10倍以上的“扫描行数”以降低整体向量计算次数，简单归纳：
● IVF-ABQ：减少扫描行数，相对稳定的扫描行数
● IVF-RabitQ：相同扫描行数下，降低计算代价
可见IVF-ABQ、IVF-RabitQ分别解决不同的问题，两者可以有效结合，发挥出更大的价值，这是我们VDB团队接下来落地自动弹性索引的坚实基础。
参考文献：
[1] Gao, J., & Long, C. (2024). Rabitq: Quantizing high-dimensional vectors with a theoretical error bound for approximate nearest neighbor search. Proceedings of the ACM on Management of Data, 2(3), 1-27.
[2] Gao, J., Gou, Y., Xu, Y., Yang, Y., Long, C., & Wong, R. C. W. (2025). Practical and asymptotically optimal quantization of high-dimensional vectors in euclidean space for approximate nearest neighbor search. Proceedings of the ACM on Management of Data, 3(3), 1-26.
