千亿级向量索引的秘密武器：一文详解蚂蚁集团的工程实践和开源突破

在 InfoQ 举办的QCon 全球软件开发大会（北京站）上，蚂蚁集团资深技术专家贾玮分享了「

蚂蚁集团向量检索技术的挑战与实践」，本文是该演讲实录整理，围绕向量检索技术的研究与实践展开系统性阐述，包含以下四个维度：

1. 向量检索的基础原理以及相关的核心技术挑战；

2. 蚂蚁集团在向量检索领域的工程实践和具体案例；

3. 向量检索领域的最新学术研究和应用成果；

4. 蚂蚁开源向量索引库 VSAG 的最新进展。

一、向量检索的技术挑战

1.1 非结构化数据规模飞速增长

根据 IDC 的预测，到 2028 年全球互联网数据总规模将达到 393ZB，其中超 80%为非结构化数据。从 2023 年开始，蚂蚁集团内部非结构化数据的规模增速首次超过了结构化数据。这一趋势表明，数据管理的范式正在转变，对非结构化数据的管理和价值发现将会成为全新的挑战。

1.2 非结构化数据与向量检索

非结构化数据：

• 非结构化数据是指像音频、视频、图片、文本等没有固定结构的数据。

• 数据量大、信息丰富且处理成本高。

非结构化数据的处理，正是向量数据库所擅长的。

向量化表示及向量索引：

通过深度神经网络提取非机构化数据特征，形成向量化表示。向量数据库为了对向量数据进行高效检索，会将这些向量按照近邻图或者倒排索引的方式，组织成一个向量索引，以加速检索过程。以近邻图格式的索引为例，对近邻图的检索过程，其实就是对这个近邻图的遍历过程。找出和查询向量最接近的目标向量结果集，这个过程需要进行大量的浮点运算。浮点运算就是去计算向量之间的距离。例如计算一千维向量之间的距离需要进行 1000 次浮点运算。正常情况下在大规模向量索引上进行完整检索，可能需要几十万次浮点运算。这里的算力需求是惊人的，跟传统的数据库对算力的需求有很大差别。

1.3 RAG 范式和向量数据库

向量数据库除了能对非结构化数据进行管理之外，也是 AI infra 中重要的基础设施。大语言模型展现了惊人的语言理解和内容生成能力，但由于模型的静态性，存在生成的内容信息更新不及时，生成内容无法溯源，有时还会存在幻觉等问题。通过 RAG 技术结合向量数据库，可以很好的解决大语言模型带来的这些问题。 解决的思路其实也很简单，在大语言模型生成最终结果之前，先将用户问题交给线上数据库检索。找出与用户问题相关的更新补充信息，或者是企业私域的专业领域的信息，以辅助大语言模型来生成更准确的结果。

因此向量数据库除了能应用在非结构化数据的管理之外，也同样可以用在大模型的增强上。

1.4 向量检索的技术挑战

高资源消耗

向量数据库具备强大的非结构化数据管理能力，但是也有一个很显著的代价，它是一个高资源消耗的服务。举个例子：同样是单个 CPU Core 的情况下，在 NoSQL 数据库中每秒钟能够处理上万次的查询请求。而向量数据库进行一次向量检索需要进行数十万次的浮点运算，算力需求非常高。向量检索的算力需求相比 NoSQL 高两个数量级。

同样是去管理 1 亿条数据，在 NoSQL 中只需要在内存里存储用户的 key 以及 value 在磁盘中索引的位置。在 NoSQL 里管理 1 亿条数据的内存需求约为 10+GB。而向量数据库却有惊人的内存需求：因为需要把用户高维的这些向量都存储在内存中，以方便快速的去进行向量的检索。管理 1 亿条 1024 维的向量，需要的内存消耗超过 1TB，同样也是高出了两个数量级。 

向量数据库不像存储工程，只是单纯存储工程的优化。它其实是一个算力、算法以及工程架构的全面挑战。我们需要去做诸多方面的优化，包括算法，CPU cache 等方面的优化。

实践案例：成本、高召回率及性能带来的挑战

在蚂蚁集团内部实际场景的挑战，首先是存储成本挑战。随着蚂蚁集团内部内容业务的发展，向量存储及检索的成本也越来越高。通常情况下，我们可能需要管理数百亿甚至数千亿的向量索引。而往往如果要维护一个千亿级别的向量索引，在不考虑算力需求和 QPS 要求，仅从内存角度，就需要数千台服务器。

另一方面，一些业务的主要挑战是在召回精度上面，例如图像识别或者是智能凭证识别这样的场景，需要做到 100%的召回。在向量检索的过程中，想把召回率从 99%提升到 99.9%，虽然提升不到 1 个点，但在资源不变的情况下，需要增加近一倍的延迟，需要付出巨大的代价。

此外，由于向量索引是近似查找的索引实现，很难保证 100%召回率。而且索引的静态性，会使得之前出错的查询后续还会一直出错，这是召回率方面的一个实际问题。

最后是性能挑战，比较典型的场景：广告推荐、RAG 场景，都提出了超高的 QPS 要求，而且也对延迟有严苛的要求。在一个大规模的集群中，做扩容的时候成本也很高，不是线性的，所以这里的性能挑战也很明显。

新 CAP 问题

向量检索在成本（Cost）、精度（Accuracy）和性能（Performance）之间面临不同的挑战，而这三个变量之间又会相互影响，就像分布式领域的 CAP 问题一样，在向量检索领域，我们也有类似的三角问题。总结下来可以称之为一个向量检索领域里的新 CAP 问题。

1.成本：通过量化或降维可以降低成本、提升吞吐量，但会牺牲精度，影响召回率。

2.精度：提升维度或检索深度可以提高精度和召回率，但会增加算力需求和延迟。

3.性能：增加机器可以提升性能，但会增加成本；降低精度可以减少算力需求，提升性能，但也会降低精度。

本质问题和 CAP 一样，我们这三个点之间会相互影响。因此向量数据库真正的优化的思路，其实就是在成本、精度和性能之间做出平衡，以满足实际业务的诉求。

二、蚂蚁集团的工程实践与案例总结

2.1 蚂蚁自研向量数据库 VectorDB

蚂蚁集团针对性能、成本和精度这三方面的挑战，自研了一套向量数据库系统。这套系统本身也是在蚂蚁内部的一个行列混合存储的底座上构建的。这个底座是蚂蚁几年前自研的一套分布式 KV 存储，它能同时支持行存和列存的 NoSQL，能够支持在线的点查，也支持分析类的场景；也是一套采用基于共享存储的存算分离架构的系统，所以具备了非常高的扩展性。也采用了一个独立的 compactor 架构，比如说压缩的动作或者合并的动作都卸载到独立的服务器上，不会影响到软件 ranger server 上的读写。此外它也是一个读写分离的系统，可以把读和写的影响做隔离。 

在这套行列混合存储的底座之上，我们构建了蚂蚁自研的向量数据库。因为这个底座是非常灵活的，可以很好的扩展。

基于蚂蚁自研存储底座 UCS：

• 增加向量索引和混合检索引擎，用于向量的查找和向量 &标量混合的查询。

• 新增检索代理服务。

• 把相对比较重负载的索引构建模块放到 Compactor 的节点上，可以单独的做弹性，也可以用 GPU 机器。

在实现这套系统的过程中，我其实意识到这是一款跨界的产品——其实是存储工程跟向量索引算法的一个深度的融合，只有把计算跟存储绑在一起，然后做深度的优化，才能把这件事情做好。

2.2 索引方案选型

有了底座之后，接下来就是索引算法的选型了。通过调研我们发现单一的向量索引无法把实时性、成本和召回率这三件事情同时做好。

• HNSW：召回率和延迟好，但内存成本高

• IVF-PQ：量化后成本低，但精度不足

• DiskANN：磁盘索引方案，成本低，但更新困难

2.3 成本优化实践

针对目前这些索引的问题，我们团队在去年提出了一个业界首创的全新方案：采用 HNSW+DiskANN 的混合索引方案，来应对成本挑战。这套方案本质上是把这两套索引方案有效的进行了组合，并且充分发挥了这两套索引的优点：不仅发挥了 HNSW 索引实时更新的优势，同时 DiskANN 索引低成本的能力也得以凸显，并且通过工程优化的方式规避缺点。

整体的实现思路：将新增的或者变更的数据，写到可以实时更新的 HNSW 的索引中；并且在后台 Compactor 的索引构建节点中，定时的把之前新增写入的节点，批量构建成 DiskANN 索引。构建完之后，再用 DiskANN 索引来替换之前在内存里的高成本的 HNSW 索引。从而实现 HNSW 里只有少量变更的增量数据，大量的历史数据都是用更低成本的 DiskANN 索引来存储的。从而解决我们在实时性和成本，还有精度上的挑战。

如上图所示，采用 HNSW+DiskANN 混合索引方案，内存需求只有纯 HNSW 方案的 1/10，QPS 和延迟可以做到几乎与 HNSW 相当，并且召回率也是接近的。整体成本的优化效果达到整体 TCO 降到原来的 1/7，纯向量索引部分达到 1/10。 

2.4 稀疏向量的应用

稀疏向量索引是一种高维向量的特殊表示形式，每个维度都对应一个单词，一个数据。其中稀疏向量里大量的数据都是 0，它是用另外一种紧凑的方式去排布数据的。相比于稠密向量，稀疏向量的计算成本更低，并且能够更精确的匹配关键词或者短语。它的精确匹配性比稠密向量的语义匹配更好。 

稠密向量、稀疏向量，还有 BM25 这样的传统召回算法，它们之间存在互补性。任何两个索引之间的召回结果，通过并集并重排之后，都可以提升召回率，且效果非常显著。最终，我们采用把三种索引结合在一起，并且加上一个加权的重排算法，能够实现整体的一个性能和召回率的提升。

Dense/Sparse/BM25 的召回效果

A 或 B：算法在 Top-10 中找到正确结果的查询集合

在 Top 10 的场景下，召回率提升了 3.7%。 在 Top 3 的场景下，召回率提升了 18%。

三、学术影响力与应用实践

3.1 性能突破：BSA 剪枝框架+内存排布和预取

向量检索作为一种计算密集型场景，其性能优化至关重要。为此，我们引入了一种基于 BSA 剪枝框架的优化方法。该方法的核心思想是：在向量检索过程中，并不直接使用全维度向量进行计算，而是首先利用降维后的向量完成第一轮的图遍历与查询操作。待初步结果集生成后，在最终返回结果之前，再通过高精度向量对候选结果进行重排，以确保检索质量。然而，第二阶段的高精度重排仍然会消耗大量算力资源。

为解决这一问题，我们进一步引入了线性分类器的思想。在线性分类器的辅助下，我们能够在进入第二阶段高精度重排之前，预先评估当前量化误差是否已满足业务对召回率的要求。具体而言，通过线性分类器对现阶段的检索结果进行快速预估，判断其是否已经达到业务所需的精度标准。若评估结果显示当前精度已足够，则无需执行第二阶段的高精度重排，从而显著减少不必要的算力开销。

实验数据表明，通过上述优化策略，向量检索的吞吐性能得到了显著提升，最高可达 1.4 倍至 2.2 倍。尤其是在高维向量场景下，由于距离计算的复杂度随维度增加而显著上升，该优化方案的效果尤为突出。

在性能优化的另一重要领域，我们聚焦于内存排布与数据预取的改进。近邻图检索因其在性能和延迟方面的优越表现，已成为向量检索中的关键方法。然而，近邻图检索过程中涉及大量的随机内存访问，这使得传统 CPU 默认的缓存预取策略难以有效发挥作用，从而导致缓存命中率下降，影响整体性能。因此，针对内存访问模式的优化显得尤为重要。

为此，我们从两个方面进行了深入优化：首先，通过对内存排布的重新设计，改善数据在内存中的存储结构，以减少随机访问对缓存效率的影响；其次，通过引入定制化的数据预取策略，提前将可能被访问的数据加载至缓存中，从而进一步提升缓存利用率。实验结果表明，经过内存排布优化后，系统吞吐性能提升了 25%；而结合数据预取优化后，吞吐性能进一步提升了 20%。

3.2 精度突破：基于反馈的召回优化

在检索精度优化方面，我们创新性地引入了共轭图机制。该机制通过利用用户查询反馈对图结构进行动态改进，从而持续优化近邻图的检索过程。

具体而言，近邻图在检索过程中可能会面临局部最优解的问题。例如，在遍历图时，检索算法可能会找到一个当前最接近目标点的节点，但该节点未必是全局范围内最优的匹配点。这种局部最优现象会限制检索结果的召回率。而共轭图的设计正是为了弥补这一缺陷。通过将那些因局部最优问题而未能被正确检索到的节点信息纳入共轭图中，我们能够对原近邻图的检索结果进行有效补充。在实际查询过程中，系统首先基于近邻图进行初步检索，然后进一步查询共轭图以补充结果，从而显著提升整体召回率。

实验数据显示，经过用户反馈驱动的优化后，系统的召回率从 99.8%提升至 99.97%。尽管表面上看提升幅度较小，但其实际价值极为显著。在高召回率场景下，每 0.1%的提升都极具挑战性。更重要的是，这些通过优化而得以提升的向量查询结果，在后续检索中具有高达 95%的概率不再失败。这种改进对于那些对召回率要求接近 100%的业务场景尤为重要，能够有效满足高精度需求下的性能指标，为关键业务提供了强有力的技术保障。

3.3 其他方面的技术改进

1）基于 Binary 量化的优化

我们引入了一种基于二值量化（Binary Quantization）的优化方案，该方案借鉴了新加坡南洋理工大学在 SIGMOD 2025 论文中提出的 RabitQ 方法。RabitQ 是一种高效的二值量化技术，能够在实现高达 32 倍压缩比的同时，保持极低的精度损失。作为工程化实现的一部分，我们基于 RabitQ 算法完成了生产级别的开发，并将其集成到我们的向量索引库 VSAG 中。这一优化不仅显著降低了存储成本，还为大规模向量检索场景提供了高效且可靠的解决方案。

新加坡南洋理工大学 SIGMOD2025RabitQ 论文 复现

2）磁盘索引上的改进（PAG）

针对磁盘与内存混合索引的性能瓶颈，我们提出了一种基于 PAG（Partitioned Aggregation Graph）的创新压缩方案。此前，使用 HNSW 和 DiskANN 等方法构建磁盘索引时，会产生大量的 I/O 需求，而检索吞吐量的上限往往受限于硬盘的 IOPS 能力。因此，优化 I/O 开销成为提升性能的关键。PAG 的核心思想是将图结构与聚类方法相结合，形成一种两层索引架构：上层为图结构，下层为聚类结构。通过将图中距离接近的节点合并为单个节点，PAG 有效减少了需要从磁盘读取的数据量，从而显著降低 I/O 需求。实验结果表明，采用 PAG 方案后，系统的 I/O 需求减少了 22%，尤其适用于分布式存储架构的优化。

3）HGraph 层次化图索引框架表

为了更灵活地支持新型索引结构的快速构建，我们设计了 HGraph 层次化图索引框架。该框架旨在提供一个通用的基础设施，使用户能够自由组合不同类型的向量索引。例如，可以在上层使用图索引，而在下层结合倒排索引；或者反过来，在上层使用倒排索引，下层采用图索引。

四、VSAG 开源进展

VSAG 是我们在向量检索领域的工程实践与算法优化成果的集中体现。我们将多年来在性能优化、算法改进等方面的积累沉淀于这一向量索引库中，使其成为适用于相似性检索的强大工具。VSAG 能够高效支持不同规模的向量集搜索任务，尤其在内存资源有限的场景下表现出色，例如支持混合内存加磁盘的混合索引方案。

2024 年 7 月，我们正式将 VSAG 开源至 GitHub，并迅速在业界获得了广泛关注。随后，VSAG 在权威的 ANN-Benchmarks 榜单上提交了基于 GIST-960 数据集的测试结果，取得了 SOTA 级别的性能表现。在 90%召回率区间，其查询吞吐量（QPS）相比此前最优算法 GLASS 提升了 100%，相较于基线算法 HNSWLib 更是提升了 300%。

为了更好地服务开发者社区，我们在 VSAG 的生态适配和易用性提升方面也投入了大量工作：

• PyVSAG：Python 生态支持

我们推出了专为 Python 生态设计的版本——PyVSAG，使用户能够在 Python 环境中轻松使用 VSAG 的强大功能。这一举措极大地降低了使用门槛，为科研和工业应用提供了便利。

• SQLlite 集成

VSAG 已成功与 SQLlite 集成，实现了向量索引能力在传统数据库中的无缝嵌入。目前该功能已在内部使用，计划于 2025 年下半年对外开源。

• Valkey/Redis 生态支持

针对 Valkey 和 Redis 生态，我们开发了一个集成 VSAG 向量索引的模块。该模块能够帮助用户在现有的 Valkey 或 Redis 产品中快速部署 VSAG 的向量检索能力，极大提升了其在实时应用场景中的可用性。目前该模块已在内部使用，预计将在 2025 年下半年正式对外发布。

• 与 OceanBase 和 Greptime 的集成

此外，我们还完成了 VSAG 与分布式数据库 OceanBase 以及时序数据库 Greptime 的集成工作，进一步拓展了其在大数据和时序分析领域的适用范围。

未来，我们也将继续推动 VSAG 在更多场景中的落地应用，并期待与开源社区共同成长。

附：VSAG 开源规划

v0.15 (预计发布日期：2025 年 4 月)

• 集成持稀疏向量搜索

• 提供可插拔的量化框架及能力

v0.16 (预计发布日期：2025 年 5 月)

• 提供针对 ARM 架构 Neon 指令优化的版本

• 使用 GPU 加速索引构建

• 提供一个自动调仓器，简化用户在使用索引中对参数的调整

v0.17 (预计发布日期：2025 年 6 月)

• 对 Intel AMX 指令集的适配，提升向量的构建和检索的效率

• 在向量索引中增加属性存储的支持

• 支持图形结构压缩

VSAG 开源地址：https://github.com/antgroup/vsag

作者介绍

贾玮，蚂蚁集团资深技术专家。2016 年加入蚂蚁集团，专注于存储基础设施领域，负责蚂蚁在线存储系统的设计研发工作，目前是蚂蚁在线 KV 存储 / 内存存储 和 向量数据库的技术负责人，对计算存储基础设施、中间件、向量检索有一定实践经验。

本文首发于蚂蚁数据 AntData，原文链接：https://mp.weixin.qq.com/s/ksxfXCRqGas1gLAycr1P4A

演讲征集

日前，由极客邦旗下 InfoQ 中国主办的 QCon 全球软件开发大会在北京圆满落幕。140 多场精彩演讲放送，直击行业痛点，为现场 1500+ 参会者传递可复制的经验与模式。10 月 23 - 25 日，QCon 上海站即将召开，如果你有相关案例想要分享，欢迎提交演讲申请。