# OceanBase BQ 向量量化技术：AI 应用背后的高效检索黑科技 本文将为您深入解析 OceanBase 向量检索的核心技术——**RaBitQ 量化算法**。通过本文，您将了解： 1. RaBitQ 量化算法如何突破传统 HNSW 索引的内存瓶颈。 2. OceanBase 向量检索技术在全球数据库榜单的亮眼表现。 3. 向量化处理在 AI 对话系统中的实际应用原理。

## 导言 在 AI 时代，如通义千问、ChatGPT、豆包等智能对话应用能够“理解”您的提问并给出恰当回答，背后是向量检索技术在进行支撑。这一过程将非结构化的文档、图片、音视频等数据，通过嵌入模型转换为向量数据，即“向量嵌入”。 通过计算您的提问与向量数据库中各条信息的距离，系统能够找到最接近、最相似的答案，从而实现“理解”的效果。但面对海量向量数据，如何高效、低成本地进行搜索，是技术落地的核心挑战。OceanBase 在 2024 年引入向量检索能力，并凭借多模融合、一体化向量能力，在全球数据库流行度榜单 DB-Engines 的向量数据库分类排名中，流行度评分达到全球 Top9。

> **小提示**：向量的每个特征对应一个数值（即维度），一个向量可以视为高维空间中的一个点。向量搜索的目标就是在这些点中找到与目标点最接近的若干个点。 ## 常规向量索引的挑战：HNSW与内存瓶颈 一种典型的高效向量索引是 **HNSW**（Hierarchical Na vigable Small Worlds，层次化导航小世界算法）。它通过构建一个层次化的导航小世界网络来加速最近邻搜索过程。

HNSW 从顶层到底层依次搜索：在顶层快速定位大致区域，然后在底层进行精细搜索。其优点是性能好，召回率高。然而，缺点也十分明显——内存消耗巨大。例如，1 亿个 1536 维的向量，至少需要 572G 内存，这在很多场景下都难以接受。 为了解决内存开销问题，向量量化技术应运而生。 ## 向量量化：精度与效率的权衡 向量量化（Vector Quantization，VQ）是一种将高维空间中的向量映射到低维码本中的技术，核心思想是用一组数量较少或低精度的“代表性向量”来近似表示原始向量，实现数据压缩。 > **小提示**：可以将向量量化类比为降低视频的分辨率。我们为了观看流畅，有时能接受较低的分辨率。同理，如果量化后的精度能满足业务需求，即使略有损失，也是可接受的。 当前，有两种常见的量化方法： * **标量量化 (SQ)**：将浮点数直接转为 int8 整数，从而将 4 字节浮点数压缩为 1 字节整数，降低 4 倍 内存开销。 * **二进制量化 (BQ)**：将浮点数变为 ±1（例如大于 0 为 +1，小于 0 为 -1），用 1 个比特表示，降低 32 倍 内存开销。 虽然这两种方法能大幅降低内存，但原始信息丢失严重，导致召回率很低，难以满足许多业务需求。 ## RaBitQ 量化算法：极致压缩，兼顾性能与召回 为了解决朴素二值量化精度损失严重的问题，RaBitQ（南洋理工大学在数据库顶级会议 SIGMOD 2024 发表的量化技术）应运而生。它是一种新型二值量化方法，能在保证召回率和性能的前提下，将向量的每一维从 32bit 浮点数压缩为 1bit，理论上实现 **32 倍** 内存降本。

RaBitQ 引入了**随机投影**及**无偏距离估计器**，确保即使在高压缩比下也能拥有极佳的量化精度，从而保障向量召回率。 > **常见问题**：RaBitQ 与普通的 BQ 有什么区别？ > **回答**：普通的 BQ 直接对数据进行零点线性分割，信息损失较大。而 RaBitQ 通过随机投影将数据变换到一个更均匀分布的空间，再进行二值化，并配合无偏距离估计器，使得距离计算结果更准确、无偏差，因此能在相同的压缩比下获得远高于普通 BQ 的召回率。 ## HNSW_BQ 向量索引：实现 95% 内存降本 在 2025 开发者大会上，OceanBase 正式推出了基于 RaBitQ 量化算法的 **HNSW_BQ** 向量索引，相比原始 HNSW 索引，实现了 95% 的内存降本。实现这一成果，主要攻克了两大核心挑战： ### 如何低内存，还能高召回？ #### 一、索引构建阶段 直接使用 RaBitQ 量化后的向量构图，精度损失会导致图质量下降。因此，构图仍需高精度向量，但若使用 32 位浮点向量，内存开销无法降低。为此，OceanBase 采用了以下策略： * **SQ8 量化构图技术**：在构建时，先将 32 位浮点数转换为 8 位整数（SQ8），内存降为原始的四分之一。 * **多分区内存自适应并行构建**：采用分治和动态调度策略，将大规模向量数据拆分为多个子分区并行构建。例如，1 千万 768 维向量在 16G 内存下，能以两分区方式成功构建，仍可在 0.95 召回下保持毫秒级响应。 > **小提示**：构建完成后，系统会删除 SQ8 向量以释放内存，只保留 HNSW 图结构和 RaBitQ 量化向量，实现最终的低内存占用。 #### 二、查询阶段 OceanBase 通过两个步骤实现内存与精度的平衡： * **基于量化向量的召回**：系统在内存中使用 HNSW 图结构和 RaBitQ 量化向量，先基于量化向量召回一批候选集合。 * **基于磁盘原始向量的重排**：对上述候选集，从磁盘按需加载原始向量进行重排，大幅降低内存开销。借助高性能 SQL 计算、磁盘预取及缓存能力，重排阶段对整体性能影响很小。

### 如何高召回，还能高性能？ 为了保证高召回率，OceanBase 引入了一些额外开销，并通过以下优化实现了高性能： * **随机投影优化**：将原始的 Johnson-Lindenstrauss Transformation (JLT) 随机投影（时间复杂度 O(N²)），替换为基于 Fast Hadamard Transform (FHT) 的随机投影，时间复杂度降为 **O(NlogN)**。例如，对于 768 维向量，计算量减少 98%，仅需 9 次计算，端到端搜索性能提升 5%-15%。 * **查询 SQ4 量化**：将查询向量量化为 4bit 整数，结合 Intel A VX512VPOPCNTDQ SIMD 位运算指令集，实现高精度与高效计算的平衡。512 维向量仅需 4 次循环即可完成计算，相比传统标量计算（512 次循环）提速 128 倍。 * **基于磁盘的重排优化**：引入动态可调的 `refine_k` 参数，控制参与重排向量的比例（topK * refine_k），实现了在不同场景下的自适应优化，查询性能提升 3%-20%。 ## 基准测试与亿级向量实践 为了验证实际性能，在 16c32G 机器上，使用 VectorDBBench 工具测试了 **1536 维 500K 数据**下的表现： * 在 **0.995** 召回率基准下，OceanBase 的 HNSW_BQ 索引 P99 延迟仅为 **6.7 ms**。 * 相比同等硬件下的 Elasticsearch BBQ 索引，QPS 高 **33%**，P99 延迟低 **26%**。 接下来，对 **1 亿个 768 维向量** 的内存成本进行测试： | 存储方式 | 内存需求 | | :--- | :--- | | FP32 (原始浮点) | 286 GB | | SQ8 量化 | 71 GB | | BQ 量化 | 8.9 GB | 得益于多分区内存自适应构建技术，将 1 亿向量拆分为 16 个分区后，构建过程中的峰值内存可降低 16 倍，仅需 **64G 内存** 即可完成构建。 > **常见问题**：HNSW_BQ 索引适用于哪些场景？ > **回答**： >

>
• 大规模向量场景（如亿级）：传统 SQ/PQ 量化内存仍然过大，RaBitQ 量化能有效解决内存瓶颈。
>
• 高维向量场景：维度越高，信息密度相对越低，量化后的距离估计越准确，对召回率影响越小，RaBitQ 优势明显。
>

## 总结 综合来看，OceanBase 基于 RaBitQ 量化的 HNSW_BQ 向量索引，实现了 高性能、低成本 的向量检索。它尤其适用于大规模、高维向量场景，能够在显著降低内存开销的同时，保持与传统索引相当甚至更优的性能。未来，OceanBase 将持续加强向量与混合检索等 AI 能力建设，助力客户以现代技术栈加速 AI 应用落地。