本页探讨了MongoDB Vector Search 性能基准测试的结果。 MongoDB提供了范围解决方案来支持各种实施需求。客户可以选择适合其特定业务设置的性能和准确性级别。
结果总结
在 2048 维度使用
voyage-3-large个嵌入的 15.3M 个向量时，配置了量化的MongoDB Vector Search 保持了 90-95% 的准确性，查询延迟低于 50 毫秒。二进制量化提供了一种更便宜的解决方案，大约是提供索引的价格的四分之一。由于它使用全保真向量重新评分，因此对于许多扩展工作负载来说，它可能是更好的选择，但我们建议对示例数据集运行测试，以确保性能满足您的需求。
在运行较大工作负载时进行量化时，我们建议使用超过 1024 个维度。
选择性过滤器可以提高或降低性能，具体取决于为
numCandidates选择的值。在运行高度并发的工作负载时，二进制量化重新评分的额外成本会导致吞吐量降低。
分片可略微提高吞吐量，但我们仍建议扩大搜索节点的数量或搜索节点上可用内核的数量，以提高吞吐量。
多维基准测试中的召回率和延迟分析
第一组结果显示的是我们对 5. 5 百万个文档数据集进行的测试，该数据集包含多个维度的向量（256、512、1024、2048），每个文档中的所有向量均使用 voyage-3-large 生成。
标量量化结果的起始级别都高于二进制量化结果的级别，但即使 numCandidates 增加，仍会保持在渐近级别。相反，随着请求的 numCandidates 越多，二进制量化查询就会产生更准确的结果，接近标量量化的渐近线，并且在某些情况下超过标量量化的渐近线，但费用是更高的延迟，特别是在超过 1000 的 numCandidates 时。
Lower values of limit generally require higher numCandidates to approach 100% accuracy, because the query is more selective about the very top results. This effect is particularly visible in the binary quantization plot. Higher-dimensional vectors (1024d and above) reach the 90-95% target range at lower numCandidates, as the richer representation makes near neighbors easier to distinguish. The tests that limit the results to 100 reach the 90-95% target range with lower numCandidates than the tests that limit the results to 10, because the larger result set gives the search more opportunities to surface relevant neighbors.
根据这些信息，我们认为，在处理大型数据集时，我们建议维度至少为 1024 维，并应用量化来扩展规模，而不是采用更低维度且不进行量化的方案，同时应用场景请求的向量数量也是考量因素之一。
更大规模的基准测试结果
对于较大的 15.3M 向量数据集，我们将维度固定为 2048 维，并检查了量化、过滤和并发操作对性能的影响。我们最终选择将维度固定在 2048 维，这是因为前一组测试的结果显示，更高维度能更有效地保持召回率，不过，要达到 90-95% 的召回率目标，1024 维可能同样适用。
召回率和延迟分析
我们观察到，与基线相比，使用二进制量化要实现 90–95% 的召回率目标，需要花费更多的 numCandidates。较高的 numCandidates 通常意味着更高的延迟，但这可能会有所不同。
过滤
我们观察了在数据集上使用选择性过滤器时召回率与延迟的变化情况，当约 500 千条项目（占语料库的 ~3%）属于宠物用品类别（总项目数 15.3 百万条）时：
选择性过滤是仅匹配一小部分数据的过滤（在本例中为 ~3%）。由于搜索引擎现在必须在这个小子集中找到最近邻，因此它必须探索更多索引并评估更多候选索引，才能达到相同的召回率。每个查询比未筛选的查询执行更多工作。
正如预期的那样，我们可以看到 3% 选择性过滤会导致查询执行更多工作。对于较低 limit 值的二进制量化，与未经过滤的查询相比，要实现 90-95% 的召回率，需要大约 4 倍的工作量。
Lucene 10 的未来改进（支持用于分层可导航小世界的 Acorn-1搜索策略）可能会改进此进程。但是，当请求的候选数量超过分段内与元数据过滤匹配的向量数量时，执行 ENN 表明，无论选择哪种量化机制，过滤的选择性在查询性能中都发挥着重要作用。
并发
在使用标量和二进制量化时，这些测试会根据不同的 limit 值在 1、 10 和 100 之间扩展并发请求。numCandidates 是通过选择能达到 90-95% 召回率的值来选定的：
我们观察到，标量量化在所有 limit 值下都能实现更高的 QPS，这可能是因为每个查询可以在较低的 numCandidates 下完成，并且无需重新评分。在较高的并发度下，并发度 10 和并发度 100 的 QPS 曲线非常接近，这表明系统正在有效地使用可用的 CPU 资源，而额外的并发度主要影响延迟。
一个异常数据点是标量量化的限制 10、并发 100，可显着提高 QPS。这可能是因为没有重新评分，并且较低的 limit 值意味着对此查询执行的比较次数较少，从而允许每个请求更快地返回并使内核可用于为其他查询提供服务。
通过扩展搜索节点层级或扩展搜索节点数量，从最小 2 个节点扩展到 32 个节点，增加可用 vCPU 的数量来提供服务请求，可能有助于解决并发瓶颈，并使 QPS 规模达到数千。
分片
我们还观察了当集群和集合基于 _id 进行分片，并且对二进制量化索引执行无过滤查询时会出现的情况。
在这里，我们看到分片的结果在限制 10 下具有更高的 QPS，因为可以提供较低的 numCandidates 值来生成 90-95% 召回范围内的结果。这是因为 15.3M 数据集被分割为三个分片，每个分片都有自己的索引，而这些索引填充了分布在包含 HNSW 图的线段上的 5.1M 个向量。我们在功能上进行了不太高级的搜索，同时在 3 分片中收集的每个分散查询更有可能找到最近的 n 向量。出于这个原因，分片QPS 会稍高，因为您可以减少 numCandidates 并有更多内核可用于为查询提供服务，但这种差异并没有那么显着，不足以证明对集群分片所增加的费用是合理的。大多数情况下，您应该出于与操作工作负载相关的原因对集群分片，而不是因为需要扩展向量搜索的吞吐量。
注意
当 limit 为 100、numCandidates 为 200 时，数值相近。我们可能希望使用智能分片键匹配作为过滤器，来处理过滤查询，从而获得更好的性能。