What Is a Vector Index?
A vector index is the data structure that makes nearest-neighbour lookup over embeddings affordable. It arranges the stored vectors so that a query can reach the closest of them without being compared against every one, and nearly every arrangement in production use returns an approximate answer by design rather than by accident.
The structures in general use, and what each one spends
The baseline is no structure at all. A flat index keeps the vectors in a list and compares the query against all of them, which is exact and grows linearly slower as the store grows. It is the right choice for a small collection, and it is also the reference every other structure is measured against, because the word approximate only means something relative to the exhaustive answer.
Partition-based structures divide the space in advance, commonly by clustering the vectors and keeping one list per cluster. At query time the query is compared against the cluster centres and only the lists belonging to the nearest few are searched. How many lists are probed is the tuning knob, and it maps directly onto the compromise: probe more and the result approaches the exhaustive one at proportionally more work. The characteristic weakness is a query landing near a boundary, where its true neighbours sit in a partition that was not probed.
Graph-based structures store a neighbour list for each vector and search by walking from an entry point towards progressively closer vectors, holding a bounded queue of candidates as they go. Result quality is set by how wide that queue is allowed to grow, and build quality by how many neighbours each vector was linked to. These are typically the fastest at a given recall and the most expensive in memory, because the graph is stored on top of the vectors it connects.
Compression is orthogonal to all three. Quantisation replaces each vector with a compact code — a product quantiser splits the vector into segments and stores, for each segment, the identifier of the nearest prototype from a small learned set — which cuts memory by a large factor and turns every distance into an estimate. It is normally combined with one of the structures above rather than used alone, and it is the reason an index can occupy less space than the vectors it was built from.
| Structure | What it spends to find neighbours |
|---|---|
| Flat | Nothing is precomputed. Every query compares against every vector and the answer is exact. |
| Partition-based | A build-time clustering step. Recall is traded for the share of lists actually probed. |
| Graph-based | Memory for the neighbour lists. Recall is traded for the width of the search queue. |
| Quantised | Precision. Vectors are held as compact codes, so every distance is an estimate. |
| Combinations of these | A build step and two knobs instead of one. Most production stores are one of these. |
All of them answer the same question, and the question is narrower than it looks: which of the stored vectors did the search manage to examine. That is why the error of an index is measured against the exhaustive scan and not against a judgement of relevance — the quantity reported is the share of the true nearest neighbours it returned, and a structure can score perfectly on that while returning passages nobody would call useful. Two separate evaluations, and only one of them is the index's.
Updates, filters, and the parts that are fixed at build time
Several properties of an index are decided when it is built and cannot be changed afterwards without rebuilding it: the distance measure it sorts by, the dimension of the vectors it accepts, and the structural parameters chosen for it. Feeding it vectors produced by a different embedding pass, or by a later version of the same one, yields a store whose neighbourhoods are quietly incoherent — positions from two spaces are not comparable, and nothing in the arithmetic raises an objection.
Deletion is the operation that most often surprises. Partition and graph structures are built for insertion and lookup; unlinking a vector from a live graph would damage the paths that run through it, so implementations generally mark the entry as removed, filter it out of results, and reclaim its space only during a later rebuild or compaction. A store with heavy churn therefore carries dead entries between rebuilds, and its memory footprint reflects what it once held rather than what it holds now.
Filtering is the second one. A query wanting nearest neighbours and a constraint at the same time — one tenant, one date range, one permission — has two routes and both are compromised. Applying the constraint after the search keeps whatever survives it, which can be very little when the constraint is selective. Applying it during the search means walking a structure with parts of it removed, which for a graph can cut off the region holding the answer. Systems that need this dependably tend to partition their stores along the constraint instead of filtering inside one.
How the Registry classifies a nearest-neighbour indexing task
Building an approximate nearest-neighbour index over a catalogue of vectors and querying it by distance is filed as information retrieval in this registry's classification, and both halves of the operation qualify. The build step organises material that already exists; the query step selects from it. Nothing in either half produces a value that was not already implied by the vectors handed over.
The Registry's canonical brief for this entry is filed as:
Build an approximate nearest-neighbour index over a catalogue of embedding vectors and query it by distance.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
9d90b9a6985a9f47…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about vector index
No structure is recommended here and no recall is published for any of them, because this registry has measured none. Which index suits a store is decided by its size, its update rate, its memory budget and the filters its queries carry — four properties of a deployment, and the canonical brief above encodes none of them.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about vector index
- What is a vector index?
- A vector index is a data structure over embedding vectors that returns the vectors nearest to a query vector without comparing against all of them. Most such structures are approximate: they give up a share of the true neighbours in exchange for a large reduction in the work per query.
- What is the difference between an exact and an approximate index?
- An exact index compares the query against every stored vector and returns the true nearest neighbours. An approximate index examines only the part of the store its structure leads it to, and returns most of the true neighbours most of the time. The gap between them is reported as recall against the exact result.
- Does a vector index decide what is relevant?
- No. It decides which stored vectors are considered at all. What counts as near was settled by the embedding pass that produced the vectors, so an index returning every true neighbour can still return nothing useful when the space places the wrong things together.
- Can vectors be deleted from an index?
- They can be removed from results immediately and reclaimed from the structure later. Graph and partition indexes generally mark an entry as deleted and skip it, freeing the space during a rebuild or compaction, because removing it from a live structure would break the paths that pass through it.
- Why do filtered vector queries return too few results?
- Because the filter and the search work against each other. Applied after the search, a selective constraint can eliminate nearly every candidate that came back; applied during the search, it removes parts of the structure the walk depends on. Neither raises an error, so the symptom is a short result list rather than an exception.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.