# How does the parameter for candidate set size (for example, nprobe in IVF or efSearch in HNSW) affect search efficiency and result quality in ANN searches?

Source: https://zilliz.com/ai-faq/how-does-the-parameter-for-candidate-set-size-for-example-nprobe-in-ivf-or-efsearch-in-hnsw-affect-search-efficiency-and-result-quality-in-ann-searches
Author: zilliz

The parameter for candidate set size, such as `nprobe` in IVF or `efSearch` in HNSW, directly balances search efficiency and result quality in ANN algorithms. Increasing these parameters improves the likelihood of finding accurate nearest neighbors but at the cost of higher computational overhead. For example, a larger `nprobe` in IVF means more clusters are scanned during a query, increasing the chance of capturing true neighbors but requiring more distance calculations. Similarly, a higher `efSearch` in HNSW expands the candidate pool during graph traversal, allowing the algorithm to explore more paths and refine results, which slows down queries. Conversely, smaller values reduce latency but risk missing relevant candidates, leading to lower recall.

In IVF, the data is partitioned into clusters during indexing. At search time, `nprobe` determines how many clusters to probe. If the query vector’s true neighbors are concentrated in a few clusters, a low `nprobe` (e.g., 5–10) may suffice for fast results. However, if neighbors are spread across many clusters (e.g., in high-dimensional or poorly clustered data), a higher `nprobe` (e.g., 50–100) becomes necessary to maintain accuracy. For HNSW, `efSearch` controls the size of the priority queue used during traversal. A low `efSearch` (e.g., 20) limits exploration, potentially causing the search to settle for suboptimal nodes early in the graph. A higher `efSearch` (e.g., 200–400) allows backtracking and deeper exploration, improving recall but increasing the number of distance computations and memory accesses.

Developers must tune these parameters based on their specific latency and accuracy requirements. For real-time applications like recommendation systems, lower values may prioritize speed, accepting minor accuracy trade-offs. In contrast, offline tasks like batch data analysis might favor larger parameters to maximize recall. The optimal setting also depends on dataset characteristics: well-clustered data requires smaller `nprobe`, while complex distributions demand higher values. Similarly, HNSW’s hierarchical structure benefits from larger `efSearch` for datasets with high intrinsic dimensionality. Benchmarking with metrics like recall@k and query latency on representative data is critical to finding the right balance.