火山引擎向量数据库：抖音大规模实践 _向量数据库

作者 | 火山引擎 VikingDB
AI 时代，如何用好大模型是当前各行各业瞩目的焦点。向量数据库作为大模型“记忆体”，不仅能够为其提供数据存储，而且能通过数据检索、分析让大模型进行知识增强，成为生成式 AI 应用开发新范式的重要组成部分。
用图片搜索图片或者文本搜索文本时，在数据库中存储和对比的并不是图片和视频片段，而是通过深度学习等算法将其提取出来的“特征”，“特征”提取的过程称为 Embedding，提取出的“特征”用数学中的向量来表示。向量化的目的是为了通过向量相似来进行非结构化数据的检索，向量化后的数据才能够被 AI 模型更好的理解使用。向量数据库就是用于生产、存储、索引和分析来自机器学习模型产生的海量向量数据的数据库系统。其典型应用场景比如：基于大语言模型的智能客服、基于企业知识库的问答以及 Chatdoc 等工具应用。
火山引擎向量数据库技术演进之路
存算分离的分布式架构搭建
在抖音集团内部，早期的向量化检索引擎是围绕搜索、推荐、广告业务来构建的，由于这些业务天然具有极大的数据规模，因此从一开始，就需要思考如何在向量索引中支持百亿数据的检索需求，比如图虫拥有几亿图片素材，数量规模早已超出单机内存的极限，举个例子，对于 1 亿条 128 维的 Float 向量，不考虑任何辅助结构，就需要 100000000*128*4 bytes 也就是约 48GB 的服务器内存。
研发团队设计了一套存算分离的分布式系统架构，来进行向量数据的分片和分布式编排，通过向量存储、批式构建和实时在线检索，解决一份向量多个索引、支持多个场景的问题，同时，还能够节省索引构建资源，加快索引构建，使在线检索服务稳定性得到明显提升。对于用户来讲，在抖音上搜索内容则会又快又准。

文章插图
计算内核性能优化
构建一个企业级的向量检索应用，数据量可能超过亿级，延迟在 10ms 内，要求用起来更快、更稳，所以在计算框架搭建好之后，也必须关注其内核，如何提供高性能的向量化检索服务以满足业务的苛刻需求。由于向量化检索是典型的计算密集、数据密集场景，其优化方向主要围绕提升吞吐、降低服务成本、提升稳定性开展。通过一系列性能优化工作，如降低内存占用、优化索引性能、CPU 指令集计算优化、优化过滤和重排序等业务相关的计算过程，这套架构可以很好解决各类业务场景的离线和在线检索计算需求，相同检索精度下的吞吐和时延相比开源基线有了 3 倍以上的改善，且满足大规模线上业务的稳定性要求，因此被抖音集团大量业务采用。
但因为每个索引搭建一套集群的成本较高，且存在配置复杂等问题，研发团队又对框架进一步迭代，进行云原生改造，实现组件多租户化，提供自动化调度能力，以降低错误率，加快交付。
向量标量混合检索能力
向量数据库用于业务场景时，向量数据通常与结构化数据配合使用，例如，在将文档表示为向量的同时，还需要存储文档所属的部门，以方便在检索时进行权限过滤。这类需求可以抽象为使用与向量相关的结构化数据进行过滤，业界通常有两种解决方案：一是后过滤，将排名 top 的 K 个结果扩大一定倍数，检索出更多的向量，然后用结构化数据做过滤，留下 topK 个，这种方法适用于结构化过滤掉的比例较低，向量召回结果比例较高的场景；二是先过滤，先使用 DSL 过滤数据集，然后在结果集中进行向量排序，适用于 DSL 过滤结果较少的场景。
随着数据量的增加，这两种检索链路的性能各有适用的场景，但如何在执行时自动找到最适合的执行路径呢？为此，技术团队又研发了 DSL 定向引擎，支持在检索过程中同时进行向量检索和 DSL 过滤（结构化过滤），具有高性能、逻辑完备、可按需终止和执行计划优化等特点。在混合查询性能对比行业评测中，该向量数据库的无过滤吞吐、1% 过滤吞吐和 99% 过滤吞吐多项性能均排名第一。

文章插图
帮助大模型知识库更快落地
大模型应用场景的不断拓宽，催生了向量数据的存储、检索需求。将企业自身数据转化为向量数据时遇到不少困难，如何帮助业务选择开箱即用的向量化模型，也影响到大模型应用的落地速度。技术团队在知识库、生成式 AI 素材管理等场景，开始尝试提供预设的向量化方法以供业务选择。大多数业务只需要选择一个适合自身数据的向量化方法，即可用原始数据直接写入向量数据库，并用相同的模型将请求数据转换为请求向量进行查询。