What is an exact brute-force baseline?

An exact brute-force baseline is a nearest-neighbor search that compares the query to every vector in the collection with the true metric – no graph hops, no cluster pruning, no hash buckets – and returns the real top-k, serving as the ground-truth reference against which approximate indexes are measured.

What does “brute force” actually compute, step by step?

For each database vector you evaluate the agreed distance or similarity – L2, cosine, inner product, or another defined metric – using full-precision (or otherwise agreed) coordinates, keep a heap of the best k so far, and finish only when every vector has been considered. There is no candidate reduction: the candidate set is the entire collection. “Exact” means exact with respect to that metric and representation; if you brute-force on quantized codes you are only exact relative to those codes, not to the original floats. Production flat indexes in systems such as Weaviate follow this scan pattern for small collections: trivial to reason about, linear in dataset size, and complete.

That completeness is why the method is the yardstick for ANN recall, not why it is the default at scale.

Why do approximate methods still need a brute-force baseline?

HNSW, IVF, LSH, and trees all trade the guarantee of true top-k for speed. Recall@k is defined as how much of the brute-force top-k the approximate method returns. Without a baseline, a fast index that systematically misses true neighbors can look “good” on latency alone. Benchmarks therefore precompute ground-truth neighbors with exact search on a query set, then score ANN outputs against that set. The baseline also catches metric bugs: if cosine brute force and your ANN index disagree wildly even at huge efSearch or nprobe, you may have a normalization or distance-definition mismatch rather than a mild approximation gap. Latency of the baseline documents how much speed ANN buys on the same hardware and data.

Building a trustworthy baseline takes more care than a naive nested loop suggests.

What makes a brute-force baseline trustworthy in practice?

Use the same metric, normalization, and dimensionality as production queries. Prefer float32 (or the canonical store format) over evaluating ground truth on compressed codes unless you intentionally study quantization-only error. For huge corpora, exact top-k for every benchmark query can be expensive – people shard the scan, use batch GEMM-style distance kernels, or compute ground truth once offline and freeze it. Document hardware, thread count, and whether distances were SIMD-accelerated so others can reproduce timings. Exclude deleted IDs the same way the serving path does. A baseline that silently uses a different cut of the data than the ANN index under test invalidates recall numbers.

Knowing when brute force is also a viable serving mode prevents over-engineering.

When is exact search the right production choice, not only a benchmark tool?

For tiny collections, cold start before an ANN build, or correctness-critical offline jobs, a flat exact scan can beat a poorly tuned graph on simplicity and even on wall-clock time. GPU-friendly dense distance kernels can push the exact frontier further for moderate N. Past that, linear growth loses to HNSW or partition-based ANN. Use brute force to certify recall curves, to validate migrations, and as a fallback path – not as the default for large embedding corpora. The taxonomy of ANN methods only makes sense when “approximate” is measured against this exact line.

An exact brute-force baseline scores every vector with the true metric to produce ground-truth neighbors for recall measurement and for small-scale serving. From here, the taxonomy of ANN methods organizes the approximate alternatives, ground-truth computation in the benchmarking glossary deepens evaluation practice, HNSW and IVF chapters show what you trade away for speed, and the trade-off in choosing an ANN index helps you decide when the baseline is enough on its own.