向量数据库优化：索引与分片

你的 RAG 系统的速度和支持大量用户的能力，通常取决于其向量 (vector)数据库的性能。虽然这些数据库旨在进行快速相似性搜索，但它们并非万能。随着数据集的增长或查询负载的增加，如果不及早优化配置，向量数据库可能成为主要瓶颈。为此，两个主要策略是选择合适的索引方法和实施分片。

优化向量 (vector)数据库性能

向量数据库效率的核心在于其索引和数据分布机制。正确配置这些机制对于最小化延迟和最大化吞吐量 (throughput)是必要的，尤其在系统扩展时。

用于向量 (vector)搜索的先进索引策略

向量索引是数据结构，它们使得数据库能够快速查找与查询向量相似的向量，而无需与数据集中的每个向量进行穷尽式比较。这通常通过近似最近邻（ANN）搜索算法来实现，这些算法会牺牲少量准确性以换取显著的速度提升。

精确搜索与近似搜索

• 平面索引（精确搜索）：此方法涉及暴力搜索，将查询向量与数据库中的所有其他向量进行比较。它保证找到真正的最近邻（100% 召回率）。然而，其查询时间随数据集大小线性扩展（$O(N \cdot D)$，其中 $N$ 是向量数量，$D$ 是它们的维度）。这使得它对于大型数据集不实用，但它可能适用于较小的数据集（例如，数万个向量），或者当对准确性要求极高且延迟容忍度高时。一些数据库可能会将其称为 FLAT 或简单地称之为无索引。

• 近似最近邻（ANN）索引：对于大多数生产 RAG 系统，ANN 索引是首选方案。它们通过组织向量以实现定向搜索，显著降低大型数据集上的搜索延迟。常见类型包括：

  1. 倒排文件索引 (IVF): 基于 IVF 的索引，如 IVFFlat 或 IVF_SQ，首先将数据集向量聚类成 $k$ 个分区（Voronoi 单元），每个分区由一个质心表示。当查询到来时，系统识别 nprobe 个最近的质心，然后仅在与这些选定分区关联的倒排列表（包含向量）中搜索相似向量。

     IVF 索引将向量划分为簇。查询与簇质心进行比较，搜索仅限于最近簇中的向量。

     • 可调参数 (parameter)：
       • nlist：索引构建期间要创建的簇（分区）数量。一个常见的起始点是 $4 \cdot \sqrt{N}$ 到 $16 \cdot \sqrt{N}$。
       • nprobe：查询时要搜索的邻近簇数量。较高的 nprobe 会提高召回率但也会增加延迟。
     • 权衡：适用于大型数据集的良好平衡。比平面索引快，但召回率取决于 nprobe。索引构建时间可能相当长。

  2. 分层可导航小世界图 (HNSW): HNSW 构建一个多层图结构，其中节点是向量，边表示邻近性。搜索从顶层（最稀疏层）的一个入口点开始，贪婪地向查询向量移动，并转移到更密集的层以进行更精细的搜索。

     HNSW 使用多层图。搜索从稀疏的顶层向更密集的基层导航，以查找最近邻。

     • 可调参数：
       • M：每层每个节点的最大出边数量。更高的 M 意味着更密集的图，更好的召回率，但构建时间和内存消耗更高。
       • efConstruction：（构建效率因子）索引构建期间动态候选列表的大小。更高的值会带来更好的索引质量但构建时间更长。
       • efSearch 或 ef：搜索期间动态候选列表的大小。更高的值以增加延迟为代价提高召回率。
     • 权衡：通常提供高召回率和快速查询速度，在相似召回率水平下通常优于 IVF。然而，HNSW 索引会消耗更多内存并需要更长的构建时间。它们非常适合动态数据集，因为它们通常比 IVF 更好地支持增量添加。

  3. 基于量化 (quantization)的索引（例如，乘积量化 - PQ，标量量化 - SQ）: 这些技术会压缩向量本身，减少其内存占用并加速距离计算（因为计算是在更短的代码上进行的）。

     • 乘积量化 (PQ)：将向量划分为子向量，并使用 k-均值对每个子向量空间进行单独量化，以创建小码本。然后，完整向量通过这些短代码的串联表示。
     • 标量量化 (SQ)：独立量化向量的每个维度。例如，将 float32 值转换为 int8。
     • 组合：量化常与 IVF 等其他索引结构结合使用（例如，IVF_PQ、IVF_SQ8）。IVF 结构首先缩小搜索空间，然后使用量化表示和专用距离函数（如 PQ 的非对称距离计算）比较这些分区内的压缩向量。
     • 权衡：显著减少内存使用（例如，4倍-30倍）。由于数据量更小和距离计算更快，可以实现更快的搜索。然而，量化是有损的，因此会降低召回率。压缩程度（例如，PQ 中每个子向量的位数）是一个重要的调优参数。

选择合适的索引和调优

没有普遍“最佳”的索引。最佳选择取决于你的具体需求：

• 数据集大小：对于非常小的数据集使用 Flat，中大型使用 IVF 或 HNSW。对于超大型或内存受限系统使用 PQ/SQ。
• 召回率要求：如果需要接近完美的召回率，可能需要使用高 efSearch 的 HNSW，甚至 Flat（如果可行）。如果可以接受一定的近似，IVF 或基于 PQ 的索引是不错的选择。
• 查询延迟 SLA：HNSW 和 IVF_PQ 可以提供非常低的延迟。
• 更新频率：HNSW 通常比 IVF 结构更好地处理增量更新，IVF 结构可能需要定期重新训练/重建。
• 内存限制：PQ 和 SQ 在这方面表现出色。HNSW 可能会消耗大量内存。
• 构建时间：Flat 没有构建时间。当 M 和 efConstruction 较大时，HNSW 构建可能很慢。IVF 构建时间取决于 nlist 和数据集大小。

索引类型比较，说明了搜索召回率和查询延迟之间的普遍权衡。实际性能根据数据和配置而异。

索引构建和维护： 构建 ANN 索引是一个计算密集型过程。这个“训练”阶段可能需要数分钟到数小时，具体取决于数据集大小和索引参数。

• 初次构建：在首次填充数据库或创建新索引时执行此操作。
• 重建：如果数据发生显著变化（大量添加/删除），索引质量可能会下降，导致召回率降低或查询变慢。某些索引类型（如 IVF）可能需要定期完整重建。其他类型（如 HNSW）可能更好地处理增量添加，但删除仍可能存在问题，并最终可能需要重建。
• 索引内存：确保你的系统在索引构建期间有足够的 RAM，因为它通常是一个内存密集型过程。

分片以实现可扩展性和吞吐量 (throughput)

当你的向量 (vector)数据集超出单台服务器的容量（无论是存储向量/索引的内存，还是处理查询的 CPU），或者你需要将查询吞吐量提高到单个节点所能处理的范围以上时，分片就变得必要。分片涉及将数据水平分区到向量数据库的多个节点或实例上。

分片式向量数据库架构。查询被分发到所有分片，结果被聚合以查找全局最近邻。

分片的工作方式： 大多数现代向量数据库都提供内置分片功能。当查询到来时：

1. 查询通常会广播到所有分片（如果元数据允许路由，则广播到子集）。
2. 每个分片使用其本地索引独立搜索其本地数据子集，并返回其本地 Top-k 结果。
3. 协调器节点（或查询路由器）聚合这些部分结果，根据相似度分数重新排序，并将全局 Top-k 结果返回给客户端。

分片考量：

• 分片数量：增加分片会分散数据和查询负载，可能提高吞吐量并允许更大的总数据集大小。然而，过多的分片可能会因网络通信和聚合成本而增加查询开销。最佳数量取决于你的数据大小、查询量和硬件。
• 数据分布：向量数据库通常自动处理数据分布，常使用向量 ID 的一致性哈希或轮询策略来平衡分片之间的数据。
• 复制：为了高可用性和容错性，分片通常会被复制。如果托管分片（或其副本）的节点发生故障，系统可以继续使用其他副本运行。复制也有助于读取扩展。
• 一致性：了解分片向量数据库的一致性模型，尤其是在数据摄入或模式更改期间。
• 每个分片的资源分配：每个分片需要足够的 CPU、内存（用于其数据子集和索引）和网络带宽。
• 查询聚合成本：查询分片的散射-收集模式会带来网络延迟和结果聚合的计算成本。对于非常高的 top_k 请求，这个聚合步骤可能会变得明显。

分片的好处：

• 水平可扩展性：存储和索引远超单机容量的数据集。
• 吞吐量增加：在多个节点上并行执行查询，处理更多并发请求。
• 弹性提升（带复制）：系统可以容忍单个节点的故障。

分片内的索引： 每个分片都维护其所持数据的独立索引。前面讨论的索引策略（IVF、HNSW 等）适用于每个分片的本地数据集。这意味着你将为每个分片配置索引参数 (parameter)，尽管在集合中这些设置通常在所有分片上保持一致。

实用优化步骤

1. 严格基准测试：

   • 使用一个在大小和特征上反映你生产数据的数据集。
   • 模拟真实的查询负载（QPS，并发）。
   • 测量重要指标：查询延迟（p50、p90、p99）、ANN 索引的召回率、索引构建时间和内存使用。
   • 尝试不同索引类型及其参数 (parameter)（IVF 的 nlist、nprobe；HNSW 的 M、efConstruction、efSearch；PQ/SQ 的压缩比）。

2. 监控你的向量 (vector)数据库：

   • 查询延迟：跟踪平均和百分位延迟。为性能下降设置警报。
   • 每秒查询数 (QPS)：监控吞吐量 (throughput)。
   • 召回率（如果使用 ANN）：定期使用真实数据集运行评估，以确保召回率满足要求。
   • CPU 和内存利用率：监控数据库节点/分片上的资源使用。高 CPU 可能表明查询效率低下或索引不足。高内存可能需要量化 (quantization)或更多分片。
   • 磁盘 I/O 和网络流量：对于理解瓶颈很重要，尤其是在分片设置中或当索引无法完全放入 RAM 时。
   • 索引构建状态/时间：监控索引构建或更新所需的时间。

3. 迭代和优化： 向量数据库优化通常是一个迭代过程。从所选数据库的合理默认值或建议开始，进行基准测试，分析结果，然后调整参数或策略。例如，如果延迟过高但召回率良好，你可以尝试降低 nprobe（对于 IVF）或 efSearch（对于 HNSW）。如果内存有问题，可以考虑量化或增加更多分片。

4. 考量数据特征对索引的影响： 向量的分布可以影响索引性能。高度聚集的数据在某些索引类型下可能与均匀分布的数据表现不同。虽然对向量分布的详细分析是高级主题，但了解它可以帮助你在遇到性能瓶颈时解决问题。

5. 硬件选择： 确保你的向量数据库节点有足够的 RAM，因为许多索引和搜索操作都受内存限制。快速 CPU 也有帮助，特别是对于 HNSW 中的距离计算和图遍历。如果索引或数据溢出到磁盘，通常建议使用 SSD 而不是 HDD。

通过系统地选择和调整索引策略，并在需要扩展时慎重实施分片，你可以确保你的向量数据库仍然是 RAG 系统中高性能的组成部分，即使在严苛的生产负载下也能快速提供相关结果。这种细致的优化直接有助于整个 RAG 流水线的整体响应速度和可扩展性。