候选深度：多少检索才够？
内容提要
本文讨论检索系统中候选深度（candidate depth）的调优方法。建议先设置基线，测试100-200的limit值，并对比近似搜索与精确搜索的召回率。增加候选可提升最佳可能分数，但需权衡延迟。当RAM受限时，优先考虑量化而非降低深度。hnsw_ef仅在召回率未饱和时调整。最后根据最佳可能分数与当前分数的差距，决定优化排序或检索。
延伸解读
最佳可能分数与当前分数的差距
文章强调，通过对比候选集的最佳可能分数（假设候选集完美排序）与当前融合分数（如nDCG@10），可以判断优化方向。若差距大，说明相关文档未被排到顶部，应优先优化排序（如调整融合或重排序）；若差距小，则说明排序已接近极限，应增加候选深度以提升召回。这一诊断方法帮助避免盲目调参。
候选深度与延迟的权衡
增加候选深度会提升最佳可能分数，但也会增加检索和重排序的计算量。文章数据显示，在单分片测试中，将limit从10提高到500，中位延迟增加37%至43%。因此，建议从100到200的limit开始测试，并在自己的延迟预算（如p95）下评估。延迟增加并非线性，需根据实际场景测量。
hnsw_ef的调整时机
hnsw_ef控制HNSW图搜索的宽度，但仅在召回率未饱和时调整才有意义。文章建议对比近似搜索与精确搜索的召回率，若召回率已平缓，增大hnsw_ef只会增加延迟。在测试的五个数据集上，hnsw_ef从16增至512，融合nDCG@10变化不超过0.0022，而延迟上升4%至49%。因此，应选择满足召回目标的最低hnsw_ef值。
量化优先于降低深度
当内存受限时，文章建议优先测试量化而非降低候选深度。Int8标量量化可将向量存储缩小至四分之一，且对融合结果影响极小（nDCG@10变化不超过0.0001）。相比之下，降低limit虽能减少延迟，但不会改变内存占用。量化是更有效的内存优化手段，但需注意量化可能轻微改变候选排序，可通过rescore和oversampling恢复。
Q&A
什么是候选深度（candidate depth）？
候选深度是检索阶段传递给后续排序阶段的候选数量。它只在后续阶段能利用额外候选时才有意义。在混合搜索中，每个预取（prefetch）都有自己的limit，多阶段查询中每个层级都设置深度。在纯稠密或纯稀疏搜索中，它是传递给重排序器或其他下游阶段的候选数量。
如何设置候选深度的初始值？
建议先测试limit为100和200，作为起点而非生产默认值。因为limit是按分片（per shard）计算的，且重排序器会对每个候选进行评分。之后根据自身数据测试更大的值。
增加候选深度如何影响最佳可能分数？
增加候选深度可以提高最佳可能分数，因为更多候选可能包含更多相关文档。但实际融合分数可能不会显著提升，因为默认RRF融合中，排名靠前的候选贡献更大，增加limit可能不会改变top 10结果。例如，在SciFact数据集上，最佳可能分数提升0.103，而当前分数仅提升0.008。
增加候选深度对延迟有什么影响？
增加limit会增加检索工作量，如果后续有重排序器，还会增加其评分候选的数量。在单分片测试中，将limit从10提高到500，中位延迟增加了37%到43%。但具体比例因环境而异，需要根据自身的p95预算、并发和分片扇出进行测量。
何时应该调整hnsw_ef？
当近似搜索的召回率尚未饱和时，才应提高hnsw_ef。如果召回率已经平稳，增加hnsw_ef只会增加延迟而不会改善召回。建议将hnsw_ef与精确搜索对比，以确定遍历是否仍遗漏邻居。如果召回率从第一个值开始就持平，则保持hnsw_ef不变，并确认HNSW图已构建。
当RAM受限时，应该降低候选深度还是使用量化？
当RAM受限时，应优先考虑量化而不是降低候选深度。量化可以缩小向量在RAM中的占用，而降低limit只影响查询时的计算量，不改变集合的磁盘和RAM占用。例如，int8标量量化将向量存储为原始大小的四分之一，且对融合nDCG@10的影响很小（最多0.0001）。
如何判断下一步应该优化排序还是检索？
通过比较最佳可能分数与当前分数的差距。如果差距大，说明相关候选存在但排名不够高，应优化排序（如调整融合设置或使用重排序器）。如果差距小，说明排序已接近候选集的最佳可能，应改进候选集本身（如增加候选深度或调整检索参数）。
