An Exact Distance Does Not Make an Approximate Vector Search Exhaustive

Ask what the word exact describes

An offer describing exact vector distances leaves a crucial question open: distances to which vectors? Scoring a selected candidate correctly establishes its position among the candidates considered. Exhaustive retrieval must also account for the complete vector population in the comparison.

Faiss supplies a concrete distinction. Its index wiki lists IndexFlatL2 and IndexFlatIP as exhaustive exact searches. It lists IndexHNSWFlat and IndexIVFFlat as non-exhaustive. These are the documented Faiss objects checked on October 20, 2026; the word Flat is insufficient to identify the search method.

Candidate selection and representation compression are separate choices. An index can retain uncompressed vectors while reducing the population examined. Conversely, scanning every compressed representation does not restore the original uncompressed values. Ask the provider to identify both the search structure and the stored representation.

References: [DR107-FLAT][DR107-INDEXGUIDE]

Follow the candidates through IVF and HNSW

In the documented IVF mechanism, database vectors belong to inverted lists. A query selects lists and searches the vectors assigned to them. If the nearest vector belongs to an unvisited list, exact scoring inside the visited lists cannot discover it.

HNSW instead explores a graph built over indexed vectors. IndexHNSWFlat uses uncompressed vector storage beneath that graph search. Graph exploration and an exhaustive scan by IndexFlatL2 are different operations, even when the candidate distances use the same L2 metric.

The useful question for a software offer is therefore how it establishes the returned neighbors. Keeping original vector values resolves one possible source of approximation; it does not establish that candidate selection preserved the exhaustive top results.

References: [DR107-FLAT][FAISS-IVF-API][FAISS-HNSW-API]

See one omitted vector change the top two

Faiss METRIC_L2 reports squared Euclidean distance. For a two-component query q and vector x, that quantity is the sum of the two squared component differences. Smaller values rank nearer. Taking a square root would change the distance values, but not this ranking.

Original example VR-224 stipulates query q = (0, 0) and the five invented vectors shown below. Exhaustively scoring all five gives top two A and B, with squared-L2 distances 1 and 4.

Separately stipulate a candidate search that visits only B, C, D and E. Exact scoring of those four returns B and C, with distances 4 and 9. Every computed distance is correct; the returned pair still omits A.

Define recall@2 here as the number of returned vector IDs also present in the exhaustive top two, divided by two. The intersection of {B, C} and {A, B} is {B}, so recall@2 = 1/2 = 50% for this one invented query. This is set overlap, rather than a requirement that a matching vector occupy the same rank.

Reranking only B and C cannot introduce A. Even reranking all four visited candidates cannot find it. If a different candidate search visits A and B, its result can change; the example assigns no fixed recall to an index family.

References: [DR107-METRIC]

Make the exhaustive reference answer the same question

Faiss's index-selection guide identifies IndexFlatL2 and IndexFlatIP as comparison baselines. To isolate candidate-search loss, compare against the same corpus revision and vector IDs, stored vectors, query vectors, preprocessing, metric and requested k. Define the same eligible population where the application restricts retrieval, and agree how equal scores at the cutoff are treated.

Record the embedding model and revision as part of that basis. Re-embedding the documents or queries can change their numerical relationships. A ranking produced by a changed embedding model is a changed reference, so a difference from the old ranking cannot automatically be attributed to approximate search.

Keep the metric explicit too. The Faiss metric guide distinguishes inner product from cosine similarity; the cosine mapping requires normalization of both query and database vectors. A label such as similarity score does not establish that two offers are ranking the same quantity.

Assess more than one illustrative query. Request results across a representative query set, with the recall definition, aggregation and weak cases visible. An average can conceal missed neighbors for a particular class of request. Retain the corpus date and the tested search configuration with the evidence so a later change can be recognized.

References: [DR107-INDEXGUIDE][DR107-METRIC]

Test useful evidence separately from nearest-vector agreement

An exhaustive vector reference establishes the nearest items under the chosen representation and metric. It does not establish that those items are the passages the application ought to use. A numerically close passage can carry a superseded rule, concern a different product or lack the authority required for the answer.

Keep two evaluations. The vector comparison asks whether the search reproduces the exhaustive neighbors. A relevance and task evaluation asks whether the returned passages contain applicable evidence and whether the generated response answers the question faithfully. Amazon Bedrock's evaluation documentation illustrates this separation with retrieval relevance and coverage measures alongside generated-answer correctness and faithfulness measures.

A search can reproduce the reference perfectly while the reference's nearest passages remain unhelpful. An approximate search can miss a reference neighbor while still returning enough applicable evidence for one task. Neither observation makes the other test unnecessary.

The related RAG-versus-fine-tuning guide addresses how external passages reach inference and how that differs from changing model parameters. This comparison resolves the earlier selection question: which vectors entered the result before their passages could be used.

References: [AWS-EVAL]

Separate vector payload from the complete memory requirement

VR-224 exposes a search-quality distinction, not a hardware requirement. For a separate payload illustration, stipulate 1,000,000 vectors, 768 components per vector and float32 storage at four bytes per component. The vector values alone occupy 1,000,000 x 768 x 4 = 3,072,000,000 bytes, or 3.072 decimal GB.

That arithmetic excludes graph links, IDs, metadata, auxiliary structures and runtime allocations. Faiss's HNSW API explicitly separates the graph link structure from the underlying vector storage. Retaining uncompressed vectors therefore does not mean a graph index has only the vector payload to store.

The 3.072 GB figure is neither a total index estimate nor a required RAM or HBM capacity. Ask the provider to account for the actual index, supporting data, working memory and any copies in its proposed execution arrangement. Keep host and accelerator allocations separate where both are used.

References: [FAISS-HNSW-API]

Include construction, updates and the intended query load

The Faiss selection guide treats index-building work as part of the decision, especially when there are few searches over which to spread it. An IVF arrangement includes partition preparation; an HNSW arrangement includes graph construction. Those are index activities, distinct from training an embedding or answer-generating model.

Ask how additions, replaced documents and deletions reach the searchable population for the exact index and version offered. Identify any required rebuild, the update interval and the point at which the replacement becomes visible. A recall result for yesterday's corpus does not establish that today's material is searchable.

Request recall and resource behavior for the same tested configuration. Keep dataset size and revision, query mix, concurrency, batching, hardware, memory placement and the timed operation visible. Search-only latency excludes embedding, passage retrieval and answer generation unless the measurement explicitly includes them.

Evaluate the response-time distribution under the intended load alongside throughput and measured memory use. Include initial preparation and recurring update work in the comparison. No universal latency, memory saving or hardware purchase follows from the names Flat, IVF or HNSW.

References: [DR107-INDEXGUIDE][FAISS-IVF-API][FAISS-HNSW-API]

Compare three promises with three kinds of evidence

Consider an offer for exhaustive IndexFlatL2 search and another for approximate IndexHNSWFlat search over the same uncompressed vectors. The first offers a complete vector result for that metric and population. The second may offer a useful operating tradeoff, but exact candidate distances alone do not establish it.

For the exhaustive offer, ask for the defined corpus and metric plus resource evidence under the required load. For the approximate offer, add assessed recall against the matching exhaustive reference, including difficult queries and the construction and update conditions. Neither offer's name supplies a measured response time or a system fit.

For both, ask separately whether the retrieved passages and final answers meet the task requirement. Buying agreement with a vector reference, buying lower resource use and buying useful application output are related decisions with different evidence.

Choose after those results are available. If an offer supplies only a distance formula or a vector-payload calculation, it has explained one component; it has not completed the retrieval-quality and resource comparison.

References: [DR107-FLAT][DR107-INDEXGUIDE]

Carry any physical cabling requirement into its own scope

If the selected infrastructure also requires physical connections between equipment, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed fiber or copper installation, routing, dressing, labeling and physical handoff records using customer-furnished or separately sourced materials.

Use the linked service and project inquiry to share a nonconfidential endpoint schedule, approved assemblies, routes, site constraints and required records. Vector-database implementation, RAG design, query tuning, storage sizing and application-quality acceptance remain with the appointed software and infrastructure owners. A retrieval choice alone does not establish a need for new equipment or cabling.

References: [L1]