Inverted File Index (IVF)

An inverted file index (IVF) is a partitioning scheme that makes vector search scale far beyond brute force. At build time, a coarse quantizer — usually k-means — groups all vectors into a fixed number of clusters or cells (the count is called nlist). Each cell holds an inverted list: the IDs of every vector assigned to that centroid. At query time, instead of comparing the query against every vector in the collection, the index compares it only against vectors in the handful of cells whose centroids lie closest. The name is borrowed from classic text search, where an inverted index maps each word to the documents containing it; IVF maps each learned "region" of vector space to the vectors living there.

The nprobe trade-off

At search time you set nprobe, the number of nearest cells to actually scan. Probe one cell and the search is blazing fast but may miss true neighbours that landed just across a cell boundary; probe more cells and recall climbs while latency grows roughly in proportion. This boundary problem is fundamental — k-means draws hard partitions through a space where nearness does not respect them — so nprobe is the honest dial between speed and recall. A common rule of thumb is to probe enough cells to cover a few percent of the dataset, which typically recovers high recall while still skipping the vast majority of comparisons. For a self-hosted index this is the first knob to tune, and it can be adjusted per query: cheap-and-fast for autocomplete, thorough for a research question. Measure it honestly — build a small ground-truth set with exact brute-force search, then sweep nprobe and plot recall against latency; the curve usually shows a comfortable knee where a modest probe count buys most of the achievable recall.

Build-time choices that matter

The other big decision is nlist itself. Too few cells and each inverted list is huge, so every probe scans too much; too many and cells become sparse, forcing higher nprobe to reach the same recall. Practitioners commonly size nlist in the neighbourhood of the square root of the collection size and then tune empirically. Training the coarse quantizer also matters: k-means centroids should be learned on a representative sample of the actual embedding distribution, and an index trained on one embedding model's output should be rebuilt if you switch models — the geometry changes underneath it.

IVF plus product quantization

IVF only narrows which vectors to examine; it does not shrink them. In practice it is paired with compression: the popular IVF-PQ index uses IVF to pick candidate cells and product quantization to store the vectors inside those cells at a fraction of their raw size. This pairing is how libraries like Faiss fit hundred-million-vector corpora into the RAM of a single machine you own. A refinement step can re-score the top candidates with full-precision vectors kept on disk, clawing back most of the accuracy that compression costs while paying its memory price only for a handful of finalists.

Where IVF fits in a sovereign stack

For a self-hosted vector database, IVF is the workhorse of the memory-constrained regime. Graph-based indexes usually win on pure recall-versus-latency but keep full vectors (and a neighbour graph) in RAM; IVF-PQ trades some recall for a dramatically smaller footprint and fast builds. On a homelab box also running your models, node, and services, that footprint is often the deciding factor. Compare IVF's cell-based pruning with the alternatives under vector quantization, and remember that the retrieval layer above the index — hybrid search, reranking — usually moves answer quality more than another decimal of index recall.