「腾讯云 NoSQL」技术之向量数据库篇: 腾讯云向量数据库如何实现召回不变，成本减半?

HNSW (Hierarchical Navigable Small World) 作为向量检索的索引类型之一，因其高召回率和相对优秀的查询性能而广受青睐。然而，HNSW 在实际应用中仍面临一些挑战，为满足客户对极致性能和成本效益的需求，腾讯云 NoSQL 的 VDB 团队深入研究了业界前沿的半精度技术，创新性地结合了通过 SIMD 指令的方式，来完成向量压缩和相似度距离的批量计算，从而在保证召回率的前提下，优化整体性能和资源利用率。

目前，该半精度优化方案已在公司内外部多个亿级规模向量的生产环境中成功落地，为客户带来了显著的成本节约和查询延迟降低。

本文作者：腾讯云 NoSQL 团队-章俊

1 向量检索索引：数据库的导航员

随着大模型（LLMs）、推荐系统、图像识别等前沿技术的飞速发展与普及，我们所处理的数据形态正经历着深刻的变革。传统结构化的数字和文本已不足以承载日益复杂的语义信息，取而代之的是大量高维度的“向量”数据。这些向量是文本、图像、音频等非结构化内容经过嵌入模型转换而来的数值表示，然而，如何在海量向量数据中高效、准确地发现“相似”的向量，成为了当前数据库技术面临的一大核心挑战。在没有索引的情况下，查找与给定查询向量最相似的数据点需要对所有向量进行逐一比对，这种暴力搜索（Brute Force）的方式在数据量庞大时将变得极其耗时且资源密集。而索引能够通过构建特定的数据结构，大幅缩小搜索范围，从而在毫秒级时间内返回近似最近邻（Approximate Nearest Neighbor, ANN）结果。可以想象，索引在业务场景中发挥着重要的作用，比如：

• 在推荐系统中，它能快速找出与用户兴趣或已购商品相似的其他商品，实现高度个性化的推荐；

• 在语义搜索领域，用户不再局限于关键词匹配，而是能基于查询的深层含义找到相关文档、图片或视频，极大提升了搜索的准确性和用户体验，广泛应用于智能问答、知识图谱检索；

• 在图像和视频内容理解中，可用于快速检索相似视觉内容，实现版权保护、内容审核或以图搜图功能。

2 客户对 HNSW 爱恨交织

2.1 HNSW 近 8 年向量搜索性能 No.1

为了应对海量向量数据的挑战，向量索引技术发展出了多种类型。近几年向量检索常见的索引有 FLAT、IVF-SQ 系列、IVF-PQ、HNSW、FastSCANN 等，HNSW 凭借其图搜特征脱颖而出，在 ANNsearch 方面具备极高的性能优势，在同等硬件条件下，其查询速度通常能比其他许多索引类型快上 10 倍甚至更多，同时还能保持极高的召回率。这种在查询速度和召回率之间取得的卓越平衡，使得 HNSW 在业界获得了广泛的认可和青睐，尤其是在对查询延迟和召回率都有严苛要求的 AI 应用场景中。在过去几年里，HNSW 已成为许多企业和开发者在构建高性能向量检索系统时的首选方案。

2.2 HNSW 索引依旧不完美

2.2.1 规模上涨让性价比变低 HNSW 通过分层导航图，实现高效的向量检索，然而 HNSW 导航每一层的每个节点会存放有多条边去构建这个分层图结构，HNSWlib 实现中默认是采用 4 字节的节点 ID 数组来实现的，以下是一个 HNSW 元素的内存示意图。

1 条 1024 维度的向量数据本身会占用 4KB，加上临接边和其他内存消耗，内存空间会达到 5-6KB，100 万向量会达到 5-6GB，这些向量默认是放在内存中计算的（从图中可以看出如果用磁盘的方式来存储图结构，会产生大量的随机磁盘 IO），当数据规模达到亿级以上，内存会达到数百 GB，再叠加多个副本则会达到 TB 级内存，当数据规模达到百亿级时，会达到百 TB 级内存（128GB 内存的机器需要 10000 台）。这个规模的集群从物理架构和技术层面来讲，完全可以实现，但对用户而言实在是“性价比不高”，这个规模的向量服务将会付出昂贵的硬件成本，但其所产生的业务价值在很多场景下却无法与成本对齐。所以对于向量成本的优化（性价比优化）是一个重要的方向，业界包含了诸多的技术方案，而 HNSW 的半精度是其中一类方案，可以在召回率下降可控的情况下，降低接近 50%的内存成本，提供更高的性能。

2.2.2 HNSW 其它问题 HNSW 除上述性价比问题外，还有写入性能不稳定、读写并发度低、空间占用高（标记删除不能及时回收空间）、图连通性差（数据聚集，可能导致部分节点入度为 0）等诸多问题。所有这些深层次的问题，都将在后续文章中详细阐述腾讯云向量数据库（VDB）所提供的创新性解法，及其在实际应用中展现的卓越效果。

3 细说 HNSW 向量半精度（Half Precision）

3.1 向量的半精度是什么

半精度本质是使用 16 个 bit 来表达 Float32 的数据，所以它的空间只有原来的 1/2。通常意义上来说，半精度特指 FP16（Half-precision Floating Point），本文主要从内存成本角度出发，故而将 BF16（Brain Floating Point 16）也描述为“半精度”。这两种 16 位浮点数，具有不同的数据特征：

目前业界比较主流的向量精度采用 FP32（Float32）：8bit 的范围指数，23bit 的精度尾数。但实际发现用 16 个 bit，几乎可以保证绝大部分向量数据的精度：部分 Embedding 模型输出的向量结果整数位很小（乃至都是 0），范围指数 bit 位是浪费的。部分 Embedding 模型输出的向量整数位较大但小数位数很小，精度尾数 bit 位是浪费的。精度越靠后的 bit 位对精度的影响越小，用 10 进制来理解精度的影响：0.1 和 0.11 区别很小，0.11 和 0.111 区别更小，以此类推，因此当精度靠后的 bit 位损失后，对向量数据的区分度影响很小，很多模型只需要小数点后面 2-3 位足以区分，除非模型本身输出的结果区分位在小数点后非常靠后的位置或者数据本身的区分度太低。由于向量每个维度从 float32 变成了 float16 或 bfloat16，每条数据空间只有原来的 1/2，极限情况下内存占用会下降 50%，由于还有额外的内存开销，内存占用下降通常在 45%左右。

3.2 向量的半精度对召回的影响

同一个 Embedding 模型所获得结果会在一个相对稳定的空间，因此在实际的应用场景中，可以取出一些样本数据来看向量数据的分布。例如 sift-128-eclidean 数据集的数据小数点后几乎没有数据，就比较适合用 BF16 来进行半精度量化，gist-960-eclidean 更多使用小数点后的精度来表达数据，就更适合使用 FP16 来进行半精度量化。实验公开数据集后，证明对召回率的影响几乎趋近于 0：

数据集 1：sift-128-eclideanHNSW 构建参数：M=16、efc=200 目标召回是 reclal@10=0.99，HNSW 的 searchef=128 与 BF16 量化后的保持一致，说明 BF16 量化后的向量几乎不损失召回效果，FP16 会增加到 129 达到 0.99 召回说明影响也很小，不过整体来讲这个数据集更适合用 BF16 来做。

查看一条 sift-128-ecliean 向量的数据如下，整数位在 200-300 之间，小数点后面 5 位来表达，基本符合预期的判断：

数据集 2：chinese200w-768-angularHNSW 构建参数：M=16、efc=200 目标召回是 reclal@10=0.99，默认情况下 searchef=381 的时候达到预期召回，经过 FP16 半精度量化后 searchef=384 达到预期召回说明对其精度影响非常可控，BF16 量化不适合于该样本数据导致无论如何都无法达到预期召回。

查看该数据集下的一条样本数据如下，整数位范围很小[-10, 10]，小数点精度位数偏多，所以此时用 BF16 精度损失会很严重，而采用 FP16 后精度损失很小，略微提高 searchef 值就可以满足召回需求：

3.3 客户业务召回

经过多家内外部客户基于真实业务场景，在 512、768、1024、2048 维进行业务验证，从业务侧端到端验证召回效果的对比，判断业务召回未出现下降，而成本下降 45%。从理论、公开数据集、客户真实业务数据等角度确认，只要根据业务选择正确的量化方案，召回效果是可靠的，这也让 vdb 团队的同学更有信心。

4 业界的技术实现

VDB 着手技术落地阶段，也调研了业界的相关实现。首先，我们调研了开源索引库 Faiss，其支持了精度量化版的 HNSW，但当时 Faiss 版本（v1.8.0）尚不支持 BF16 半精度类型，只支持 FP16。

Faiss 库在向量匹配时，会先将 FP16 半精度转换为 FP32 单精度再进行距离计算，并支持 AVX2 指令集加速，但未支持 AVX-512 指令集，整体运行效率较低。其入库/检索的主要操作如下：

• 入库时调用 encode_fp16，将 FP32 转换为 FP16 。

• 检索时先调用 decode_fp16，将 FP16 转换为 FP32，再进行相似度距离计算。

另一知名厂商的开源版本实现中，也提供了半精度浮点数量化。在实现 FP16、BF16 半精度向量计算时，也是先转换半精度浮点数为单精度浮点数，再进行距离运算。核心代码如下：

该实现简洁易读，但不够高效。半精度到单精度浮点数的类型转换通过函数实现，单精度浮点数之间的乘积计算效率，则被动依赖于编译器优化，但通常编译器自动优化效果相对保守，远远没有根据硬件指令集的不同，直接采用更高处理位宽的 SIMD 指令效率高。

5 TencentVDB

腾讯云 VDB 团队在理解业界做法后，认为业界的做法可以归纳为：

• 先将半精度浮点数转换为 FP32 单精度浮点数，以降低乘积和累加误差。

• 再使用单精度标量乘法进行相似度距离计算（比如，x86 架构下 mulss 指令）。

  
  

这种运行方式显然是低效的：

• 每发起一次 search 请求，需要将以半精度量化存储的向量转换为 FP32，再进行相似度匹配，那么随着底库规模的增大，转换过程的运算规模也将随之增大。

• 每次转换过程，默认需要通过函数中一系列的标量代码来完成转换（每一个维度均需要），代价是十分高的。

VDB 优化方式：VDB 内核同学采用了通过 SIMD 指令的方式，来完成向量压缩和相似度距离的批量计算，虽然在实现上比起直接使用标量计算代码更为复杂且容易出错，但团队秉持着为首个版本奠定坚实性能基础的理念，坚持走了一条更具挑战性的技术路线。最终，这一决策带来了卓越的性能表现和显著的计算效率提升。下面，我们将以 AVX512 指令集为例，简述 VDB 的核心实现：FP16

• 指令_mm512_cvtps_ph: 将 FP32 转换为 FP16。

• 指令_mm512_cvtph_ps: 将 FP16 转换为 FP32。

在 AVX512 指令集下，根据向量维度适配的 FP16 压缩计算方式：

AVX512 指令集下，相似度距离计算方式：

BF16

• 指令_mm512_srl_epi32：将以 32 位整数表达的 FP32 右移 16 位，高 16 位零扩展。

• 指令_mm512_cvtepi32_epi16: 移除 32 位整数的高 16 位，转换为以 16 位整数表达的 BF16。

• 指令_mm512_cvtepu16_epi32：将以 16 位整数表达的 BF16，高 16 位零扩展，表达为 32 位整数。

• 指令_mm512_slli_epi32：将 32 位整数左移 16 位，表达为 FP32。

AVX512 指令集下，根据向量维度适配的 BF16 压缩计算方式：

AVX512 指令集下，相似度距离计算方式：

6 下一步探索

目前 AVX512 扩展指令集中，已经包含对半精度浮点数直接进行点积运算，而无需额外类型转换的指令。部分用户场景可以针对性进行优化，以实现更高的计算效率。更新的 AMX 指令集，则能提供更高的数据位宽和计算并行度，进一步提升效率。目前受操作系统版本的限制，暂未实现，VDB 也会持续这部分的动态变化，在后续适当版本会适配这部分指令以达到更好的效果。

7 客户效果

自腾讯云向量数据库半精度发布后，多个拥有亿级规模向量数据的客户已通过采用半精度方案获得了显著的收益。这些客户的应用场景广泛，涵盖了教育、大模型训练与推理、代码管理以及搜索推荐等多个核心业务场景，我们对客户的的收益变化进行了以下简单总结：

• 实例成本下降 45%

• 同等实例规模下性能提升 15%

• 召回率损失低于 1%

8 未来目标：性价比持续升级

HNSW 半精度是 VDB 在提升向量性价比的开始，这显然面对百亿级、千亿级规模的向量还远远不够，向量的成本也远远高于传统数据库的数十倍乃至上百倍，所以还有很长的路需要走。

VDB 将根据客户的实际业务场景，结合新技术，持续不断探索高性价比方案，让向量数据库可以服务于更多更大规模的业务场景，接下来大致会从以下几个角度入手和落地：

• IVF-RabitQ/HNSW-RabitQ：新的向量索引技术集高召回、高性能、低成本于一身的向量六边形战士，将在近期正式服务

• 磁盘方案在不同场景下的持续探索：自研 DISK_FLAT，用以支持 RAG 的海量租户场景引入 DISK_ANN，数倍量化内存空间，通过磁盘二次召回提升召回率内存索引卸载和装载、休眠挂起和唤醒，以充分利用资源稀疏向量的磁盘交换，解决稀疏向量的性价比问题

VDB 也将会同时从以下几个角度进一步提升整体能力，敬请期待！

• 进一步提供丰富的业务特性（如多向量、聚合分组、排序）

• 自研索引 IVF-ABQ 提升性能的同时，降低同等数据规模下的计算成本

• AI 数据面服务的 Memory 记忆、深度检索 DeepSearch 等能力

腾讯云向量数据库（Tencent Cloud VectorDB）是一款全托管的自研企业级分布式数据库服务，专用于存储、检索、分析多维向量数据。该数据库支持多种索引类型和相似度计算方法，单索引支持千亿级向量规模，可支持百万级 QPS 及毫秒级查询延迟。腾讯云向量数据库不仅能为大模型提供外部知识库，提高大模型回答的准确性，还可广泛应用于推荐系统、自然语言处理等 AI 领域。