作者来自 Elastic Mayya Sharipova, Gilad Gal, Quinn Harper在四个数据集上的基准测试表明一个索引设置可以应用 bfloat16 向量量化、缓存预加载和并行合并从而提高向量搜索吞吐量并降低存储开销。我们推出了一个用于生产环境向量搜索的设置。新的vectordb_document索引模式将原始向量以 bfloat16 格式存储使其磁盘占用减少一半并将向量数据结构预加载到文件系统缓存中。它还允许 segment 合并以不受限制且并行的方式运行。在我们的基准测试中使用bbq_hnsw时在高召回率下 QPS 最高提升了 2 倍使用bbq_disk时将索引达到可搜索状态所需的时间缩短了约 20%且无需进行任何调优。该功能目前已在 Stateful Elasticsearch 9.5 和 Elasticsearch Serverless 中提供。Elasticsearch 支持广泛的使用场景包括可观测性指标和日志以及复杂的地理空间分析。然而随着向量搜索逐渐成为现代架构的核心组件对专门优化的需求也越来越大。要让以向量为主的工作负载达到峰值性能通常需要在复杂的配置选项空间中进行调整。为了减少这种运维负担我们希望通过一个设置提供具有明确倾向的高性能默认配置从而简化生产环境中的性能调优。vectordb_document 索引模式 就是专门为实现最佳向量搜索工作负载而设计的。如何设置vectordb_document模式设置只需要一个配置项。创建索引时在索引设置中定义以下内容PUT my-index { settings : { index : { mode : vectordb_document } } }vectordb_document模式适用于所有 Elasticsearch 订阅层级包括 Basic。大多数用于向量搜索的索引也支持其他操作例如聚合或地理搜索。它们同样支持混合搜索。由于向量搜索通常是这些混合工作负载中计算量最大的部分我们建议使用vectordb_document索引模式为最密集的操作优先提供性能优化。采用vectordb_document模式的索引仍然具备很强的功能支持默认标准模式中几乎所有可用的操作同时针对向量搜索对资源的高需求进行了专门优化。“_document”后缀代表了我们的路线图。我们还在开发“vectordb_columnar”模式作为优化向量搜索的另一种方式适用于不同的数据和访问模式。四个数据集上的 Elasticsearch 向量搜索基准测试为了验证这些默认设置我们针对各种数据集以及两种索引类型bbq_hnsw和bbq_disk进行了广泛的基准测试。所有基准测试均在 AWS 上的单节点 Elasticsearch 实例中运行使用c8gd.2xlarge实例Graviton 4、ARM64、本地 NVMe SSDpod 限制为 8GB RAM2GB heap和 4 个 CPU并使用单个 shard。数据集数据集向量数量维度使用场景laion-img-emb-512-20M-cosine2000 万512纯向量搜索低维msmarco-v2-10M-jina-v5-10241000 万1024纯向量搜索中维dbpedia-openai-1M-3072-angular100 万3072纯向量搜索高维arxiv-for-fanns-large270 万4096过滤搜索bbq_hnsw使用vectordb_document的 HNSW 索引性能查询吞吐量和召回率在全部四个数据集上vectordb_document都产生了更好的 QPS–召回率曲线而优势的变化形态本身也很有参考价值。在dbpedia-openai-1M、msmarco-v2-10M和arxiv-for-fanns-large上两条曲线在低召回率时开始时非常接近在 arXiv 上基本完全相同随着召回率提高逐渐拉开差距在高召回率端分别达到约 1.4 倍、2.2 倍和 2 倍。在laion-img-emb-512-20M上两条曲线从一开始就存在差距并且从召回率 0.80 开始稳定在约 2 倍。随着召回率提高差距会扩大因为更高的召回率需要通过过采样来实现而过采样正是vectordb_document能够节省开销的地方。两种效果会叠加。bfloat16 存储将重新评分候选向量时需要读取的字节数减少了一半。对于分层可导航小世界HNSW来说更重要的是过采样因子会应用于图搜索本身每个 segment 都会搜索k × oversample个候选项因此成本会随着过采样倍数和 segment 数量的增加而增加。不受限制的并行合并会留下更少、更大的图14–21 个 segment而不是 22–29 个同时图文件和量化向量文件会预加载到文件系统缓存中因此vectordb_document在每次增加过采样倍数时付出的代价要低得多。比较完全相同的搜索设置而不是相同的召回率可以更清楚地体现这种效果。在关闭重新评分的情况下两种模式的性能差距在 1%–28% 以内当过采样为 5 时vectordb_document的速度快 2–4 倍当过采样为 10 时最高可以快 10 倍。这些高过采样设置位于 QPS–召回率前沿之外这也是为什么上面的曲线最高只达到约 2 倍但它们能够单独体现性能提升究竟来自哪里。过采样DBpediaLAIONMS MARCOarXiv关闭1.23×1.28×1.11×1.01×54.07×2.66×2.66×2.05×1010.5×2.33×2.46×4.03×索引速度和合并行为在我们的基准测试中vectordb_document使上传时间增加了约 16%。这是预期的结果合并现在会以不受限制且并行化的方式跨线程运行因此在文档仍在写入的同时会与索引建立过程竞争 CPU。四个数据集测得的索引建立时间增加了 9%–26%。HNSW 图构建受 CPU 限制因此这种竞争会直接体现出来。相同的变化也使上传后的阶段成本大幅降低。禁用自动限流会完全移除合并速率限制在默认模式下DBpedia 有 57% 的合并时间处于限流状态而 bfloat16 将原始向量数据减少一半使需要合并的总字节数减少 42%–49%。在四个数据集中的三个数据集上数据写入后的合并完成时间缩短了 75%–86%使索引达到可搜索状态的总时间仅比基线高约 6%。DBpedia 是一个例外其合并尾部占据了主要时间因此总时间实际上下降了 25%。bbq_disk使用vectordb_document的基于磁盘的向量搜索性能bbq_disk查询吞吐量和召回率对于bbq_disk索引vectordb_document模式对搜索吞吐量的影响因数据集而异。在低维数据集上相同召回率下的 QPS 基本没有变化laion-img-emb-512-20M-cosine512 维和msmarco-v2-10M-jina-v5-10241024 维在整个召回率范围内的表现非常接近vectordb_document在较低召回率端领先而在高召回率端则落后几个百分点。在高维数据集上我们在相同召回率下观察到了约 20% 的稳定提升dbpedia-openai-1M-3072-angular3072 维和arxiv-for-fanns-large4096 维。我们的解释是这主要来自重新评分的影响。vectordb_document将向量以 bfloat16 格式存储因此重新评分每个候选项时读取的字节数为2 × dims而不是4 × dims。这一点也得到了扫描测试的直接支持优势会随着查询时的过采样倍数增加而扩大而过采样倍数正是决定需要重新评分多少候选项的因素。在 DBpedia 上QPS 比值从过采样为 3 时的 1.16 倍上升到过采样为 8 时的 4.3 倍在 arXiv 上则从 1.20 倍上升到 1.56 倍。相比之下在 LAION 和 MS MARCO 上该比值保持平稳或者略微低于 1。对于规模较小但维度较高的数据集重新评分在查询中的占比明显更大而对于 1000 万和 2000 万向量的数据集扫描 1-bit 倒排列表占据了主要开销。索引速度和合并行为在四个数据集上vectordb_document都将索引完全合并并达到可搜索状态所需的总时间缩短了约 20%。每个数据集都有所改善从msmarco-v2-10M的 6% 到dbpedia-openai-1M的 50% 不等其中 DBpedia 的上传后合并阶段单独就从 322 秒下降到 54 秒。单独来看上传时间的结果并不那么明确在下面图表所展示的当天测试中根据数据集的不同上传完成时间缩短了 2%–15%但在更早的一组测试中上传速度略有下降因此我们将上传时间视为基本不变到略有提升并将达到可搜索状态所需的时间视为真正的结果。性能提升几乎全部来自合并。在默认模式下Elasticsearch 会限制合并可以写入数据的速度而这一限流机制产生了明显影响DBpedia 75% 的合并时间以及 LAION 73% 的合并时间都消耗在因限流而暂停上。vectordb_document禁用了这一限流机制因此暂停时间变为零DBpedia 的合并时间下降了 63%LAION 下降了 42%。bfloat16 也会带来帮助原因相同限流机制按照写入的字节数进行限制因此原始向量数据减少一半意味着在限额下需要写入的数据更少。不同数据集之间的提升幅度与限流程度而不是字节数量相关arXiv 只有 21% 的合并时间受到限流但合并时间减少了 30%而 MS MARCO 从未受到限流虽然写入字节数减少了 55%合并时间却只减少了 11%。两种索引类型在数据写入阶段的表现不同因为它们的合并成本不同。合并bbq_hnswsegment 意味着重新构建 HNSW 图这是一项受 CPU 限制的工作会直接与新写入文档时同样受 CPU 限制的图构建过程竞争。在只有 4 个 CPU 的 pod 上这种竞争会表现为上传速度变慢。bbq_disk的合并则主要受写入字节数影响而不是 CPU因此解除限流后会使用本地 NVMe 尚有余量的 I/O 带宽同时 bfloat16 意味着本来就需要写入更少的字节。两种索引类型都能更快地达到完全合并的状态区别仅在于上传阶段是否需要为此付出代价。vectordb_document在底层设置了什么element_typedense_vector值bfloat16。影响将原始向量的每个维度以 bfloat16 而不是默认的 float32 进行存储使原始向量的存储空间减少一半同时对召回率的影响可以忽略不计。收益更小的磁盘占用降低总体拥有成本 [TCO]更快地获取用于重新评分的向量。动态浮点数组映射值包含 32 个或更多值的浮点数组会被动态映射为dense_vector。在默认模式下该阈值为 128。影响无需显式将字段声明为 dense vector 字段系统会自动识别。收益配置更加简单。exclude_source_vectors值true。影响向量只在向量索引中存储一次不会在_source中重复存储。它们不会出现在响应的_source中但仍然可以按请求进行检索。收益更小的磁盘占用查询速度更快因为大型向量不再随每次_source获取一起传输。index.store.preload值[vex、veq、veb、cenivf]。影响每当新的 segment 打开时将搜索时使用的向量数据结构预加载到文件系统缓存中。收益降低查询延迟。index.merge.intra_merge_parallelism_enabled值true。影响使用并行线程进行 segment 合并以获得最佳的 segment 大小。收益更快地收敛到更少、更大的 segment从而提高召回率并降低查询延迟。index.merge.scheduler.auto_throttle值false。影响允许合并以全速进行。收益更快地达到最佳 segment 大小从而提高召回率并降低查询延迟。虽然这些默认设置针对大多数使用场景进行了优化但其中大多数设置都可以单独覆盖以适应独特的硬件限制或极端的性能需求但有一个例外exclude_source_vectors: true在vectordb_document索引中是锁定的无法更改。总结vectordb_document索引模式为向量搜索提供了一个适用于生产环境的基础通过采用高性能默认设置团队可以专注于构建功能而不必手动调整合并或存储设置也不必调整预加载设置。在四个数据集上整体结果都持续向好不过不同索引类型之间的平衡有所不同。对于bbq_hnsw所有数据集的 QPS–召回率都有所提升从低召回率时大致持平到高召回率端最高达到约 2 倍代价是适度增加数据写入成本上传时间延长约 16%达到可搜索状态的索引总时间延长约 6%。对于bbq_disk情况正好相反达到可搜索状态的索引总时间缩短了约 20%在高维数据集3072 和 4096 维上相同召回率下的搜索性能提升了约 20%而在低维数据集上基本没有变化。两者的差异归根结底取决于合并的成本重新构建 HNSW 图属于 CPU 密集型工作会与索引建立过程竞争 CPU而bbq_disk的合并受写入速度限制解除限流后可以更快地运行。在这两种情况下新的默认设置都让系统朝着大多数用户希望的方向发展无需针对每个索引进行调优。而对于那些真正取决于数据本身的设置例如量化程度现在自动校准功能会为你推导这些设置。参见Elasticsearch 如何自动调优向量量化以达到你的召回率目标。你可以在 Stateful Elasticsearch 9.5 或 Serverless 中创建使用vectordb_document索引模式的索引来进行尝试。原文Vector quantization in Elasticsearch: auto parameter selection | Elasticsearch Labs