AI 场景内存降本 95%！一文看懂 OceanBase BQ 向量量化

作者 | OceanBase 研发技术专家 敖泽柳

在使用通义千问、 ChatGPT、豆包这些 AI 智能对话应用的时候，你有没有考虑过，它是如何“理解”你的提问，并给出合适的回答的？其实，这背后是“向量检索”在悄悄发力。

OceanBase 2024 年引入向量检索能力，近期在全球数据库流行度榜单 DB-Engines 的向量数据库（Vector DBMS）分类排名中，凭借多模融合、一体化向量能力入围榜单，流行度评分达到全球 Top9。

来源：DB-Engines，2025年7月

https://db-engines.com/en/ranking/vector+dbms

向量是将文档、图片、音视频等非结构化数据通过嵌入模型进行向量化处理转化为向量数据，这一过程被称为“向量嵌入”。

而一旦把这些非结构化数据转化为数学中常见的向量之后，我们就有了大量的数学工具，如向量运算、矩阵等，可以用它们来处理这些数据，将海量非结构化数据的分析处理转化为对海量向量的近似搜索。

于是，通过计算你的提问与向量数据库里各条信息的距离，就可以找到距离最近、最近似的回答，从而达到“理解”提问的效果。

比如将一张图片向量化为一系列的浮点数组 [ 1.65,0.36,0.93,0.36…… ][ 0.06…… ]，其中每个特征对应一个数值，即向量维度。一个向量可以视为在高维度向量空间（几何空间）的一个点，这些数值就是坐标。而向量搜索即为在这些点中找到与目标点（下图中绿色点）相近似的点。

向量检索

然而接下来我们将不可避免地遇到下一个问题：在这么多点中定位绿色的目标点，如果像大海捞针一样使用暴力搜索，资源开销大，性能也差，如何加速查询？

为了回答这个问题，向量索引便顺理成章地出现了。向量索引是指通过某种数学模型，对向量构建的一种时间和空间上比较高效的数据结构。借助向量索引，我们能够高效地查询与目标向量相似的若干个向量。

一种典型的向量索引是 HNSW （Hierarchical Navigable Small Worlds，层次化导航小世界算法），这是一种基于图论的数据结构，它构建了一个层次化的导航小世界网络来加速最近邻搜索过程。

HNSW 向量索引

具体来看，HNSW 从顶层至底层依次搜索，在顶层中快速搜索，确定大致区域，然后在底层做精细搜索。

其优点是性能好，最终的召回率也很高。但是缺点也很明显，即内存消耗很大，比如 1 亿个 1536 维的向量，至少就需要 572G 内存，这样的内存开销在很多场景下是不可接受的。

为了解决内存开销的问题，我们进一步引入向量量化的概念，以实现数据压缩的目的。

在大规模向量检索系统的设计中，内存资源的优化始终是核心挑战之一。若采用 32 位浮点数（FP32）存储高精度向量，每个向量需要消耗 4 字节存储空间。对于包含十亿量级的向量数据库而言，内存需求将突破 TB 。为此需要引入向量量化技术。

向量量化（Vector Quantization，VQ）是一种将高维空间中的向量映射到低维码本（Codebook）中的技术，广泛应用于数据压缩、AI 等领域。

其核心思想是将一组高维输入向量用一组数量较少或者低精度的 “代表性向量”来近似表示，从而实现数据压缩或特征降维，最终达到降低内存开销的目的。

在向量搜索中的向量量化，目标是在保持搜索性能的前提下，降低计算复杂度和内存占用，侧重搜索效率优化。这里的一个核心是通过 “代表性向量” 近似原始数据，平衡精度与效率。

我们知道向量搜索是一种近似搜索，量化类似于降低了视频的分辨率。我们看视频时，为了保证观看不卡顿，有时能接受低一些的视频分辨率，能看清就行。

向量量化与之类似，如果量化后的精度和性能可以满足业务场景的需要，虽然精度降低了，但召回率满足业务需求，那么就是可以接受的。

向量量化

注：1 字节= 8 比特，字节是计算机存储和处理数据的最小单位，而比特是信息的最小单位

比如通过向量量化，将彩色图像转化为灰度图，灰度图可以保持它的原始状态，虽然少了一些信息，但是它的必要特征还在，可以满足许多场景下的业务需要。

当前，有以下两种比较常见的量化方法：

• 标量量化（Scalar Quantization, SQ）：这种方法把浮点数直接转成 int8 的整数，这样就可以把一个 4 字节的浮点数转成一个 1 字节的整数，从而降低 4 倍的内存开销。

• 二进制量化（Binary Quantization, BQ）：这种方法将一个浮点数直接变成 ±1，比如大于 0 就是 +1 ，小于 0 就是 -1，这样仅用 1 个比特就可以表示这些信息，从而降低 32 倍的内存开销。

以上两种量化方法都能大幅度降低内存开销，但是原始信息丢失太多，导致召回率非常低，对于很大一部分场景来说都难以满足业务需求。

RaBitQ 是南洋理工大学 Cheng LONG 老师及 Jianyang Gao 博士在数据库顶级会议 SIGMOD 2024 上发表的量化技术。

RaBitQ 是一种新型的二值（Binary）量化方法，能够在保证召回率和性能的前提下，将向量的每一维表示从 float-32bit 压缩为 1-bit ，理论上，可以达到 32 倍内存降本。

RaBitQ 量化算法

为了解决朴素的二值量化精度损失太严重的问题，RaBitQ 引入了随机投影及无偏距离估计器，其保证了即使是在高压缩比下也有极佳的量化精度，如上图计算公式所示。如此，向量的召回率就有了保障。

在 2025 开发者大会上，OcenBase 宣布正式推出了基于 RaBitQ 量化算法的 HNSW_BQ 向量索引，在提升索引效率和性能的同时，相比原始索引实现了 95% 的内存降本。

这其中主要涉及两大挑战：如何在低内存的同时做到高召回？如何在高召回的基础上实现高性能？

前文提到 RaBitQ 算法理论上可将 32bit 的浮点数量化为 1bit。在这种压缩效率下，即使有无偏距离估计器，也还是会有一定的精度损失。

那么如何才能在降低内存消耗的同时，尽可能保证召回率不降低呢？OceanBase 分别在索引构建和查询两个阶段进行了优化。

一、索引构建阶段

对于 HNSW 这类图索引，图的质量对召回率至关重要。若直接使用 RaBitQ 量化后的向量构图，精度损失将导致图质量下降，进而影响召回率。

因此，构图仍需使用高精度向量，并在构建完成后将其删除以释放内存。但构建 HNSW 索引时要求图中向量常驻内存，使用高精度的 32 位浮点向量则内存开销无法降低。

为此 OceanBase 通过两个手段解决：

• SQ8 量化构图技术助力内存降本：

  OceanBase 引入了 SQ8 量化构图技术，将 32 位浮点数转换为 8 位整数，使得构建过程的内存降低为原来的四分之一。虽然使用 SQ8 构图的质量可能不如 32 位浮点数向量，但通过引入重排优化策略，在向量检索阶段采用自适应精度补偿机制，可保持召回率不下降，实现内存降本与检索精度的平衡。

• 多分区内存自适应并行构建提升构建效率：

  面对向量数据量指数级增长（如千亿级规模向量数据库，内存占用可达数十 TB），传统单一分区索引构建方法常因内存不足导致性能崩溃，还可能因单点构建的串行化操作而无法满足实时性需求。

为此，OceanBase 提出多分区内存自适应并行构建技术，通过分治策略和动态资源调度，显著提升了大规模向量索引的构建效率与资源利用率。

由于 HNSW_BQ 单分区构建索引的内存开销与 SQ8 相当，但是构建后，可以删除 SQ8 向量，释放内存，因此通过分区内存自适应并行构建技术，可以使得由于内存限制导致 HNSW 或者 HNSW_SQ 无法构建的索引可以成功构建。

在实际测试中，1 千万 768 维向量在 16G 内存下，能够以两分区方式构建成功，并且仍然可以在 0.95 召回下保持毫秒级响应延迟。

二、查询阶段

查询阶段分为两个步骤：基于量化向量的召回与基于磁盘原始向量的重排。

OceanBase 通过两步骤优化，实现内存开销与精度的平衡。

基于 RabitQ 的 HNSW_BQ 向量索引

• 基于量化向量的召回：OceanBase 内存中存储了 HNSW 的图结构和 RabitQ 量化向量，从而保证低内存使用。在查询阶段，先基于量化向量召回一批候选集合，集合的大小由 ef_search 参数控制。一般该集合的大小大于实际返回给用户要求的 topK。

• 基于磁盘原始向量的重排：为抵消量化带来的负面影响，下一步 OceanBase 基于原始向量，对上述候选集进行重排。由于重排阶段使用的原始向量不需要常驻内存，而是按需加载，因此可大幅降低内存开销，并且借助 OceanBase 高性能的 SQL 计算、磁盘预取及缓存能力，使得这种基于磁盘的重排对整体性能的影响大大降低。

为了保证 HNSW_BQ 的高召回率，OceanBase 引入了一些额外的开销，比如随机投影，基于磁盘的重排等。为了在保证高召回的前提下实现高性能，需要进一步对其进行优化。

一、随机投影优化

为了能够进行二值量化，需要让量化后的向量更加均匀地分布在量化后的几何空间中以避免碰撞，RaBitQ 引入 Johnson-Lindenstrauss Transformation（简称JLT随机投影）技术解决这个问题。

但是这种随机投影的时间复杂度是 O ( N^2 )（其中N表述向量的维度），这对性能的影响是极大的。为此，OceanBase 将其替换为基于Fast Hadamard Transform（简称 FHT ）的随机投影，这使得其时间复杂度降低为 O ( NlogN )。

比如对于 768 维向量，原先需要进行 768 次内积计算，现在可减少 98%，降至仅 9 次计算。实际端到端的搜索性能相较于使用 JLT 随机投影提升了 5%-15%，特别在 0.95 召回下，性能提升最明显。

二、查询 SQ4 量化

基于 32bit 浮点数的向量距离计算虽然能保证较高精度，但其计算开销在大规模场景下成为显著瓶颈。而 1bit 量化虽能极大压缩存储空间，却因精度损失过重导致搜索结果质量急剧下降。

为此 OceanBase 将查询向量进行了 SQ4 量化，即将查询向量的 32bit 的浮点数量化为 4bit 的整数，结合 Intel AVX512VPOPCNTDQ  SIMD 位运算指令集，实现了高精度与高效计算的平衡。

由于 AVX512 寄存器宽度为 512 位，每个循环可处理 128 个 4bit 元素（512/4），因此 512 维向量仅需 4 次循环即可完成全部计算，相较传统标量计算方式（512次循环）提速 128 倍。实验数据显示，端到端的性能提升达 2%-10%，随着 ef_search 的增加，对召回率要求高的场景下，性能提升越明显。

三、基于磁盘的重排优化

实际测试发现，对于 HNSW_BQ，不需要使用 ef_search 大小的候选集用于重排，一般 4 倍 topK 的大小即可。但是不同的场景，可能需要不同的比例。

为此 OceanBase 引入动态可调的 refine_k 参数，用于控制参与重排向量的比例（topK * refine_k），从而实现了 HNSW_BQ 索引在不同场景下的自适应优化，有效平衡搜索精度与计算效率。

实验数据显示，在保持召回率不变的前提下，该优化可使查询的性能提升 3%-20%。一般在 topK 较小的场景下，提升最为明显。

为了验证实际性能，我们在 16c32G 的机器上，借助 VectorDBBench 工具，测试了 1536 维 500K 数据下 HNSW_BQ 的表现。

结果显示，在 0.995 召回率基准要求下，OceanBase 的 HNSW_BQ 索引可以做到毫秒级响应，P99 延迟仅为 6.7 ms，相比同等硬件资源配置下 Elasticsearch 的 BBQ 索引，QPS 高 33%，P99 延迟低 26%。

接下来，我们进一步在 VectorDBbench 的 Performance768D100M 数据集下，针对亿级规模的向量索引构建的内存成本需求进行测试。

1 亿个 768 位的向量，如果使用 32 位浮点存储，则至少需要 286GB 内存（实际上由于要存图结构，可能需要更多的内存）；SQ8 量化需要 71G  内存；而使用 BQ 量化后，内存则可以降低至 8.9G。

按照前文所述，为了保证召回率，OceanBase 的 HNSW_BQ 索引采用 SQ8 量化构图，所以如果采用单分区，峰值内存开销至少需要 71G。在借助多分区内存自适应构建后，将 1 亿向量拆分为 16 个分区，构建过程中的峰值内存可以降低 16 倍，使得使用 64G 的内存也可以为 1 亿向量构建索引。

上述表现得益于 OceanBase 成熟的 SQL 并行执行及 AP 能力。对于多分区表，在查询过程中，可以并行搜索多个分区，从而保证查询的高性能。

总结

综合而言，OceanBase 基于 RabitQ 量化的 HNSW_BQ 向量索引尤其适用于以下场景：

• 大规模向量场景（如亿级）：传统 SQ/PQ 量化会导致内存开销过大，引入 RabitQ 量化可以有效解决内存开销问题。

• 高维向量场景： 由于维度越高，信息密度越低，所以量化后的距离估计也会越准确，从而使得量化对召回率的影响越低，RabitQ 量化能够提供较好的召回率。

  
  

在这些场景下，HNSW_BQ 一方面能显著降低内存开销（特别是在向量维度更高、规模更大的场景，压缩效益更突出）；另一方面在同等召回率要求下，其性能表现与传统索引相当甚至更优。

向量能力是 AI 时代不可或缺的数据基础能力。未来，OceanBase 将持续加强向量与混合检索等 AI 能力建设，打造更精准、高效、具性价比的向量检索体验，通过一体化架构，助力客户以现代技术栈加速AI应用落地。

了解更多

在线咨询

优质资料下载