提高向量搜索性能

减少向量维度

Atlas Vector Search 最多支持 4096 （含）向量维度。 然而，向量Atlas Search索引和查询的计算量很大，因为较大的向量需要更多的浮点比较。 因此，在可能的情况下，我们建议在确保可以衡量更改嵌入模型对向量查询准确性的影响后，减少维数。

运行查询时避免对向量建立索引

向量嵌入在索引期间会消耗计算资源。我们建议避免在向量搜索期间编制索引或重新索引。如果您决定更改生成索引向量的嵌入模型，我们建议您将新向量重新编入一个新索引，而不是更新当前使用的索引。

预过滤数据

如果向量更多或维度更高，则可以缩小语义搜索的范围，并确保不会考虑所有向量进行比较。我们建议在filter $vectorSearch管道中包含 选项，该管道执行预过滤以减少要执行向量搜索的文档数量。此外，请考虑极高维向量的性能影响，因为大型数组可能会降低查询性能。

使用专用搜索节点

如果部署mongod 和mongot 进程部署在同一节点上，则进程之间可能会出现资源争用。为了优化Atlas Vector Search查询的性能，我们建议您在专用搜索节点上部署mongot 进程。这不仅有助于避免mongot 和mongod 进程之间的资源争用，而且默认为搜索节点上的 $vectorSearch查询启用并行段搜索。

从结果中排除向量字段

您可以请求结果中文档的现有字段，以及在 $project阶段返回新计算的字段。 要提高查询性能，请使用$project阶段审慎选择要在结果中返回的字段，除非您需要结果中的所有字段。 我们建议在$project阶段排除向量字段，因为向量嵌入可能很大，会影响返回结果的查询延迟。

确保有足够的内存

当矢量数据保存在内存中时，分层可导航小世界 可以高效运行。您必须确保数据节点有足够的RAM来保存向量数据和索引。我们建议部署单独的搜索节点以实现工作负载隔离性，而不进行数据隔离性，这样可以更有效地为向量搜索使用案例使用内存。

预热文件系统缓存

执行向量搜索时，当您遍历分层导航小世界图表时，您的查询最初会在磁盘上执行随机查找，并将向量值读入内存。这会导致初始查询出现非常高的延迟。当分层导航小世界遍历将所有已索引向量读入内存时，延迟会有所改善，这样在后续查询时就能更快地访问这些向量。

但是，在进行大型写入或重建索引时，必须重复此缓存预热进程。

使用binData 向量

在 中使用浮点向量时，BinData 向量子类型可节省3mongod int8int1倍的存储，并且还支持使用 向量和 向量等替代类型对向量进行索引。这种显着减少的资源配置文件加快了内部查询路径的速度，mongod 用来为每个$vectorSearch 查询从数据库检索文档。即使使用binData binData浮点数，使用 向量也会大幅加快查询延迟，尤其是当limit （结果数）大于20 时。

量化向量嵌入

标量量化会降低每个单独维度的精度，例如将32 位浮点数转换为8 位整数。但是，它保留了为大多数嵌入模型检索相关信息的能力。另一方面，二进制量化可将向量减少为1 或0 ，这对于 QAT 嵌入模型来说性能更好。

标量量化擅长保持大多数嵌入模型中向量的召回率。如果您有来自 QAT 嵌入模型的向量，则二值量化可以提供更好的性能，因为培训进程会训练模型以适应精度的极端降低。