HNSW 分布式构建实践

阿里技术

于 2024-12-11 10:11:51 发布

阅读量1.3k

点赞数 20

文章标签：分布式算法 HNSW 向量检索方案

本文链接：https://blog.csdn.net/AlibabaTech1024/article/details/144392632

版权

作者：魏子敬

一、背景

随着大模型时代的到来，向量检索领域面临着前所未有的挑战。embedding 的维度和数量空前增长，这在工程上带来了极大的挑战。智能引擎事业部负责阿里巴巴搜推广及 AI 相关工程系统的设计和建设，我们在实际业务迭代与发展中遭遇了 embedding 维度和数量扩张带来的诸多问题，其中索引构建时间问题尤为突出。

图 1 HNSW

以 HNSW[1]算法为代表的近似图算法因其高性价比与高召回率特性，在向量召回领域已逐渐成为主流技术选择。尤其在淘宝天猫、拍立淘、闲鱼等平台的搜索召回场景中，近似图算法扮演了至关重要的角色，其应用范围极为广泛。但是近似图算法被诟病的一个主要问题就是索引构建时间过长，特别是在高维海量数据场景下，这一缺点被进一步放大。

在分布式场景下，基于分而治之的思想，原始数据会被划分成多个正交子集，然后每个节点只负责其中的一个子集，这样就可以用多个独立的计算(存储)节点来解决单机无法解决的海量数据问题。在向量召回场景中也不例外，原始的 embedding 数据集会被按照 pk 哈希被均匀划分到多个分列中，这样通过一次分片就可以极大缩小单个实例内需要处理的向量数量，然后查询时只需要分别在各列的索引中先做召回，最后再把各列的结果汇总就可以了。

那是不是在不考虑成本的情况下，不管有多少数据只要无线分片下去就能解决一切规模膨胀带来的问题？

1.1 分布式的可扩展性困境(Scalability)

在我们的搜索推荐场景，业务上一般只要求最终一致性，这使我们无需支付高昂的成本来支持复杂的事务处理或维护严格一致性。而宽松的一致性要求使得水平扩展更加容易。然而即使如此，分布式环境的不稳定性以及网络开销等因素仍然限制了这种扩展能力，更不用说成本问题。

在向量召回场景中，仅因离线索引构建过慢而扩列是不划算的。以 HNSW 为例，如果撇开其他索引和检索时间，同样是在召回 topk 情境下，不进行分列并将所有数据构建成一个图，在检索计算量上来看是必然最优的。因此一个自然的问题是：如何加速近似图的构建呢？利用现代处理器的多线程并发处理能力是一个显而易见的方向。