An IVF-style index uses clusters to reduce vector search work. Two common tuning ideas are nlist, the number of clusters created at index time, and nprobe, the number of clusters searched at query time.
These two settings are related, but they solve different problems. nlist controls how the dataset is partitioned. nprobe controls how much of that partitioned space a query explores.
Short Answer
In an IVF-style vector index, nlist is the number of centroid-based clusters or posting lists, while nprobe is the number of those lists searched for each query.
More clusters can make each list smaller, but query recall depends on probing enough lists. More probes usually improve recall but increase latency.
What an IVF-Style Index Does
IVF stands for inverted file.
An IVF-style index partitions vectors into posting lists. Each posting list represents a region of vector space, usually around a centroid. At query time, the search compares the query with centroids and scans only selected posting lists.
This avoids a full scan of every vector.
What nlist Means
nlist is the number of clusters or posting lists created during indexing.
If nlist is 1,000, the index divides the vector collection into about 1,000 regions. Each vector is assigned to one or more of those regions depending on the implementation.
This is a build-time or index-structure setting.
What nprobe Means
nprobe is the number of clusters searched during a query.
If nprobe is 10, the query searches the 10 most relevant posting lists. In some systems this idea is called searchProbe or probe count.
This is a query-time search breadth setting.
The Difference Between nlist and nprobe
The simplest way to remember the difference is:
nlistcontrols how many buckets exist.nprobecontrols how many buckets a query opens.
You choose nlist when designing or building the index. You tune nprobe to trade recall against latency.
Why nlist Matters
nlist affects posting-list size.
More clusters usually means fewer vectors per list. That can reduce the scan work inside each probed list. But if there are too many clusters, nearest neighbors may be spread across more boundaries, requiring higher probe counts for good recall.
Fewer clusters usually means larger lists. That makes cluster selection easier, but scanning each selected list costs more.
Why nprobe Matters
nprobe affects query coverage.
Higher nprobe searches more clusters. That improves the chance of finding true nearest neighbors, especially near cluster boundaries.
Lower nprobe searches fewer clusters. That reduces latency, but it can miss relevant candidates in unsearched lists.
How nlist and nprobe Interact
nlist and nprobe should be tuned together.
If you increase nlist, each list may get smaller, but you may also need to increase nprobe to cover enough of the space. If you decrease nlist, each probed list may contain more vectors, so query scans can become heavier.
The best setting is not the largest or smallest value. It is the combination that meets the recall and latency target.
Posting Lists
A posting list is the group of vectors assigned to a centroid or region.
During query search, the index chooses posting lists that appear close to the query. The candidates inside those lists are then scanned, scored, or rescored depending on the index variant.
Posting-list size and balance are crucial for predictable latency.
Centroid Lookup
Before probing posting lists, the query must find relevant centroids.
The query vector is compared with centroid vectors. The closest centroids determine which posting lists are likely to contain nearest neighbors.
If the centroid routing is poor, the query may search the wrong lists.
Cluster Boundaries
Cluster boundaries are a common source of recall loss.
A true nearest neighbor may live in a neighboring posting list that is not among the first few probed lists. Increasing nprobe can reduce this risk by searching more adjacent regions.
Some systems also use replicas, assigning each vector to multiple posting lists, to improve recall near boundaries.
Replicas
Replicas mean storing a vector in more than one posting list.
This increases the chance that a relevant vector appears in a probed list. It can improve recall, but it uses more storage and can increase indexing work.
Replica count is another way to trade storage for search quality.
Maximum Posting Size
Some IVF-style systems control the maximum size of each posting list.
Larger posting lists can improve recall because each list covers more candidates, but they increase scan time. Smaller posting lists reduce per-list scan work, but may require more probes or replicas.
Posting size should be chosen with vector dimensions and query latency targets in mind.
Recall vs Latency
The nprobe trade-off is direct.
Higher nprobe means better recall and higher latency. Lower nprobe means lower latency and more risk of missing true nearest neighbors.
nlist shapes the search space. nprobe decides how much of that space each query explores.
Memory and Storage Effects
nlist and replicas can affect memory and storage.
More centroids require more routing data. More replicas duplicate candidate references or vector representations across posting lists. Compression can reduce candidate size but may require rescoring to maintain recall.
Index tuning should include resource usage, not only latency.
Filtered Search
Filters can change the best probe setting.
If a filter removes most candidates from a probed list, the query may need to probe more lists to find enough eligible results. A probe count that works for unfiltered search may not work for filtered search.
Benchmark filtered workloads separately.
How to Tune in Practice
A practical tuning process is:
- choose a reasonable cluster count for the dataset size
- build the index with representative data
- measure recall at target
k - increase probe count until recall is acceptable
- check p95 and p99 latency
- inspect posting-list size balance
- repeat with realistic filters and concurrency
Common Misunderstandings
Common misunderstandings include:
- confusing
nlistwithnprobe - thinking more clusters always improves performance
- thinking more probes are free
- ignoring cluster balance
- benchmarking only average latency
- forgetting that filters may require more probing
Summary
In an IVF-style index, nlist defines how many clusters or posting lists the index builds, and nprobe defines how many of those lists each query searches.
nlist is about partition design. nprobe is about query coverage. Tuning them well requires measuring recall, latency, posting-list balance, memory, storage, filters, and real query patterns together.