导读
向量数据库是高效处理和准确检索高维数据的基石，对于生成式 AI 技术而言至关重要。本文将分享向量数据库的架构设计和实现中的关键点。
1.
向量数据库背景介绍
2.
Milvus 整体架构设计
3.
性能的关键-索引
4.
面向 AI 持续进化
5.
问答环节
分享嘉宾｜
高超
Zilliz
senior software engineer
编辑整理｜
蔡郁婕
内容校对｜李瑶
出品社区｜
DataFun
向量数据库背景介绍
1.
什么是向量数据
我们经常会遇到一些非结构化数据，比如图片、视频、语音、文本等，它们通过模型被向量化，进而有助于模型的理解、训练和推理。向量，与数学中向量的概念相同，代表高维空间里面的一个点。
2.
什么是向量检索
向量检索，即给定场景向量，找出离场景向量最近的 k 条向量，也就是 KN 查询。常见的计算 metric 有 L2、IP、Cosine 等，这与产生向量的模型定义是有关系的。
3.
什么是向量数据库
向量数据库是一种专门为存储和查询等高维度向量数据而优化的数据库系统，类似于图数据库、时空数据库这种 specialized 数据库，针对特殊的数据进行特别的管理和优化。
4.
为什么需要向量数据库
在当前的大模型浪潮之前，向量数据库已经被很广泛地应用于推荐系统、风控、安防等系统中。现在仍然是一个重要的使用场景。
大模型浪潮以后，给数据库带来了机遇，向量数据库作为 RAG 中一个存储的记忆体可以帮助用户构建领域内相关的知识库，当向大模型提问时，可在向量数据库中找出相似的提问，来增强提示词，从而获得一个更加为用户量身定制的答案，增强了结果的相关性。
5.
什么是好的向量数据库
一个向量数据库优劣，主要从性能、扩展性、易用性、功能、可观测可运维、生态集成、故障恢复以及安全等方面进行衡量。
Milvus 整体架构设计
1.
云原生的分布式向量数据库
Milvus 有四个关键角色，以数据的流入作为参考，首先会经过 proxy 即接入层，主要负责请求检查和路由的功能；当插入请求经过 proxy 时进入到消息队列，被 data node 消费，把流式数据转化为持久化数据，放到对象存储上；批次的数据累积了一段时间以后交给 index node 支持索引的构建。
查询链路走向如下：经过 proxy 的路由后，交给 query node 做实际数据的检索，然后把 index node 构建好的索引加载上来，同时消费流里的数据来支持实时检索。
四个角色的设计可以带来很好的隔离性，首先建索引的过程非常吃 CPU 和内存资源，我们不希望该过程影响到查询的资源，因此要做读写分离。其次，基于这样的设计可以具备很好的扩展能力，比如扩展 query node，有效地去提升查询的性能，当 index 构建可能跟不上时候也可以去扩容 index。最后，可以做更灵活的流式数据处理，同时具备了流批数据的写入和查询的能力。
2. 实时性和性能的 trade off
Segment 是 Milvus 查询的一个最小单位，growing segment 保证数据的实时可见，但性能相对差；sealed segment 负责持久化数据的查询，性能较好。在后台通过 indexNode 构建索引替换 queryNode 上的数据，逐渐把 growing
segment 替换成 sealed segment，从而达到实时性和性能比较好的 trade off。
3.
异步 compaction
我们会把小的 segment 合成大 segment 来加速查询。因为向量索引大小和性能不是完全呈线性变化的，比如数据是原来的四倍但性能没有任何变化，如果用 4 个小 segment 去查，对性能有比较大损害，所以会通过 compaction 操作把一些小的数据合并成大的，然后替换掉 query node 上一些小 segment 的数据。Compaction 同时合并 delete 数据做物理删除，这样对向量检索会更加友好。
4.
批量写入
用户对于数据的实时性要求不是非常高，或者更新删除不是很频繁的情况下，更加推荐采用批量写入，这样可以跳过消息队列的限制直接把数据插入到对象存储当中。我们还支持 Spark connector，外部数据源可以通过 Spark ETL 导入到 Milvus。
5.
全局索引
在查询的过程中默认会访问所有的 segment，然后把结果做 reduce，得到最终的结果。假如预先知道了数据的分布，就能够减少 segment 的访问，对于性能提升会有很大的帮助。常见的数据分布方式包括：
（1）根据不同的租户划分数据，租户 1 ~ 10 的数据落在这一部分上，租户 11 ~ 20 落在另外一部分上，查询时可跳过一些数据的查询。
（2）根据标量过滤条件划分数据，即定义标亮的 key，它的 ID 遵从某种分布，可以对分布做数据重组，当知道标量落在的范围时，可以做有效的剪枝。
（3）根据向量空间分布划分数据，把相似向量放在同一个 segment 上，从而有效地减少 segment 的访问。
6. Zilliz cloud
：向量数据库
Zilliz cloud 是基于 Milvus 打造的一个全托管云服务。做好一款数据库产品有很多要求，除了 Milvus 数据库内核，还要实现监控报警、备份恢复、生态工具、网络控制、负载均衡等云平台的工作，这样才能打造一个完善的数据库服务。我们也对 Milvus 内核做了进一步的优化和升级。云上商业版的搜索引擎具备更好的索引性能。最近发布的 serverless 版本，能够帮助用户更低成本地使用向量数据库的服务。
性能的关键-索引
接下来介绍影响向量数据库性能的一个关键因素——向量索引。
1.
主流向量索引介绍
主流的向量索引包括四种，首先是传统的基于空间划分的树索引，在高维空间下会受到维度灾难的限制，性能比较差；哈希和量化是对于向量的压缩编码的不同方式，主流以量化居多，因为其精度比哈希更优；图索引通过近邻的连接关系达成迅速导航的效果，缺点是对资源的占用比较高，但精度和性能优异。
Knowhere 是 Milvus 的核心向量引擎，集成了多种向量检索算法，供用户自由选择。通过对外统一接口，可以很方便地集成第三方索引。
FLAT，即暴力搜索，其效率很低，但可以提供 100% 的准确率，在数据量较少时可能优于索引的性能。
对数据做聚类的操作，分成若干个 bucket，在查询向量时查找若干个最近的 bucket，可有效避免搜索全量数据。
乘积量化是一个非常常用的一种量化手段。下图右侧，常用的向量表示的 128 维数组，内存占用会达到 512 字节，内存占用是较大的，我们可以通过一些压缩手段，缩小内存占用。通过向量可将其分成若干个段，每 8 维分成一个段，总共 16 个段，每段通过聚类操作，分成 256 个聚类中心，这样通过一个字节的 ID 就可以表示原来的向量，从而有效压缩了向量的内存占用。查询时预计算 query 向量和每一段聚类中心的距离，这样就把距离计算转化成了查表操作，可有效地提升性能。
HNSW 是目前使用最为广泛的图索引。通过去找近邻的方式去对库里面的点进行连边，同时会引入一些长边，从而防止陷入局部最优。通过层次化结构快速定位，贪心式搜索逼近查询向量，找到最终结果。其缺点是内存占用比较高，且由于整个过程是一个流式的过程，没有 refine 的过程，因此可能出现图的连通性问题，这一问题可以通过补边操作进行弥补。
DiskANN 是针对磁盘进行优化的索引，其本质也是一种图索引，不过是把图索引结构保存在磁盘上，在查询中按需读取，而不是持久化在内存中。在内存中保存的是 PQ 量化后的向量表示，内存占用非常少。在搜索过程中，内存中的 PQ 可以用作磁盘上保存的图索引的导航，从 PQ 队列中找出 PQ 距离最近的点，进而即可到磁盘对应位置找到向量和邻居。每次 IO 得到原始向量计算精确距离，同时得到邻居 id，用到内存中的 PQ 编码计算近似距离用于导航。
DiskANN 可以实现较低的内存占用，达到不错的性能和高精度。
Milvus 与 NVIDIA 团队合作，将 GPU cagra 索引集成到了 knowhere，充分利用 GPU 的并行计算能力加速索引构建和查询。在 HNSW 基础上，性能可进一步提升一至两个数量级。
2.
如何选择最合适的索引
通常，单一索引并不能解决全部问题，因此需要根据实际场景进行选择。选择主要基于三方面的考虑，第一个是 cost，即 CPU、GPU、内存等资源的情况；第二个是 accuracy，即精度，向量索引在大部分情况下都会有精度上的损失，因此要考虑对精度的需求；第三个是 performance，即性能。没有一个索引可以同时在三个方面都做到最优，因此需要做出取舍。
3.
Zilliz cloud
商业版索引引擎-cardinal
Cardinal 对外展示的接口和 knowhere 基本一致，作为我们云上的一个索引引擎去提供服务。其优势主要包括：
-
更加工程化的代码：比如用一些 C++ 模板去代替虚函数，或者用更高效的数据结构替换掉原来比较低效的数据结构。
-
更加智能的参数学习：向量索引是近似的，因此参数设置上会有一些调整细化的空间，智能调整参数可以使得性能得到更好发挥。
-
更加优异的数据存储布局：包括内存上的布局，磁盘上的布局，达到局部性更好，更有益于 CPU 的计算和内存访问，磁盘 IO。
-
更加极致的 SIMD 优化：充分利用新硬件 SIMD 的指令，实现更好的效果。
面向 AI 持续优化
向量数据库作为一个单纯的向量检索工具已无法满足不断产生的新的需求，因此需要面向 AI 持续优化。
1.
Filter search
带标量过滤条件的向量检索已经成为一个基本需求，比如在查询相似图片时可能会加上一些约束条件，如品牌是什么。
Milvus 支持多种 scalar
index 加速标量过滤的效率。同时支持向量侧通过标量分布构建融合索引加速过滤。
2.
Sparse vector
传统的基于向量的检索在很多场景上效果欠佳，这时 sparse
vector 可能更具优势，其通过关键词匹配查找相关结果，具有更强的可解释性。另外，dense vector 往往是通过模型训练产生的向量，因此在 out of domain 数据上泛化能力可能并不理想，而 sparse
vector 是通过关键词来查询，因此效果更优。
3.
Hybrid search
Milvus 也支持了多向量多模态的存储和检索，可以从更多信息的维度召回和 rerank，相比于单纯使用 dense vector 或 sparse vector 会有更好的结果。
4.
Grouping search
在向量维度的召回不一定能够满足用户需求，如下图，同一个 doc 可能分成了不同的 chunk，每一个 chunk 会被 embedding 成一个向量。做检索时如果只是向量视角可能不一定满足用户需求，用户可能希望能够在 doc 维度而不是 chunk 维度去做聚合的搜索，我们就可以找到用户最希望得到的这些 doc 的结果。
5.
更加易用
向量本身不是 source of the
truth，真正的数据是其背后的非结构化数据，比如文本、图片。用户在使用向量数据库的过程中希望能有更加易用的模式，即直接去导入图片或者文本就可以直接在线下数据库上去做存储和检索。我们会在后续版本中提供调用第三方模型转向量的能力，使用户可以更加方便地使用非结构化数据。
问答环节
A1：HNW 可以支持实时更新，但是要看怎么定义实时，因为它的插入性能其实没有太好。Milvus 中没有做图索引的实时更新。
Q2
：面向大模型的向量数据库还有哪些值得继续深入研究的？主要是指学术方面。
A2：参数的智能学习，这部分的工作和很多数据库都有关系，但在向量数据库上更加显著，因为结果本身就是近似的，所以有更多的提升空间。另外，更为复杂的搜索方式也有较大空间去做学术上的创新。
A3：智能的参数化学习可能是一个方面，这是 AI
for DB 方面；DB for AI 方面，会面向AI 的新需求做功能的迭代。
Q4
：针对 grouping search 是否有进一步的工作？未来是否会提供更多面向更加复杂场景查询的功能？
A4：现在已经支持 Grouping search，在聚合方面，目前比较常用的方式是取一个 Max 函数作为聚合函数，未来可以做一些新的探索。
