召回率和查询延迟或吞吐量之间的权衡曲线通常呈凹形，即提高召回率会以更高的延迟或降低的吞吐量为代价，尤其是在接近更高的召回率值时。最初，召回率的少量改进可能只需要适度增加延迟。例如，将搜索范围从检查索引数据的 10% 扩大到 20% 可能会显着提高召回率，而对速度的影响很小。但是，超过某个点后，进一步提高召回率需要不成比例的更多计算工作，从而导致延迟激增。这是因为详尽的方法（例如暴力搜索）可以实现接近完美的召回率但速度很慢，而近似最近邻 (ANN) 技术通过限制搜索范围来牺牲部分召回率以换取速度。
索引参数直接影响系统在此曲线上的运行位置。例如，在使用分层可导航小世界 (HNSW) 图的向量数据库中，增加 efSearch 参数（控制查询期间探索的节点数）会提高召回率，但会降低每个查询的速度。同样，在倒排文件索引 (IVF) 方法中，提高 nprobe 值（每个查询要扫描的聚类数）会增加召回率，但需要更多的距离计算，从而影响延迟。量化设置也很重要：使用 8 位整数代替 32 位浮点数可以减少内存使用并加快搜索速度，但会引入近似误差，从而降低召回率。这些参数允许开发人员根据其应用程序的需求调整准确性和速度之间的平衡。
为了做出明智的决策，开发人员必须首先定义其应用程序的需求。例如，实时推荐系统可能优先考虑延迟（例如，每个查询 <50 毫秒）并容忍 80% 的召回率，而批处理数据分析工具可以接受更高的延迟以获得 95% 的召回率。使用具有代表性的工作负载进行测试至关重要：测量召回率和延迟如何随着调整 nprobe 或 efSearch 等参数而变化，有助于识别曲线的“拐点”——即进一步提高召回率的成本过高的点。此外，分片或缓存等技术可以改变曲线本身。将索引拆分到多台机器上（分片）可以提高吞吐量，而不会直接影响召回率，而缓存频繁查询可以减少延迟，但不会改变底层索引行为。通过将参数调整与系统级优化相结合，开发人员可以根据其特定用例定制权衡。