A production team built their HNSW index with the distance metric set to cosine, then later switched the query-side metric to Euclidean to 'test something.' Recall@10 dropped from 0.95 to near random. Explain in concrete terms why this happened and what fix is required.
Free · 2 AI evals / day
**ANN indexes are not metric agnostic.** When you build an HNSW index with `metric = cosine`, the index code chooses each node's M neighbors as the M nearest neighbors **under cosine distance**. Those graph edges are then permanent (until rebuild). The same is true for IVF: the k-means centroids and the vector-to-partition assignments are computed under the build time metric.
At query time, HNSW does a greedy walk: start at an entry point, look at the current node's neighbors, jump to whichever is closest to the query, repeat until no neighbor is closer. The crucial property is that 'closest neighbor' is measured with the same metric used to build the graph.
If the team switches the query metric to Euclidean while keeping the cosine-built graph, the walk follows edges that lead toward cosine-near nodes, not Euclidean-near ones. On normalized data those happen to coincide. On unnormalized embeddings (which is what they almost certainly had if they could ask the question), the two metrics induce different orderings and the walk drifts in a useless direction.
**Fix:** rebuild the index with `metric = euclidean` (the metric they actually want to query with), or normalize the vectors so that cosine and Euclidean both rank-order points the same way. Patching only the query side does not fix the underlying graph.
**Cosine-versus-dot is the one safe swap**, but only if the vectors are L2-normalized: for unit vectors, `cosine_distance(a, b) = 1 - dot(a, b)` produces the same ordering as `1 - dot`. Cosine-versus-Euclidean is never a safe swap on arbitrary vectors.
**Root cause.** An ANN index encodes its metric structurally. HNSW selected each node's M neighbors as the M nearest under cosine distance during build. The graph edges literally point toward cosine-near nodes. The greedy search algorithm relies on the invariant that moving along an edge moves you closer (under the build metric) to the query. Swap the metric at query time and that invariant breaks: the walk follows edges that point at cosine-near nodes while measuring 'closeness' under Euclidean. The walk strands at a node whose cosine-neighbors are not its Euclidean-neighbors, and recall collapses.
IVF has the same problem with a different mechanism. The centroids were learned by k-means under cosine. The 'nprobe nearest centroids' selection at query time, even if done under a different metric, ranks centroids by the wrong criterion. The vectors inside the visited partitions are no longer the right candidates for Euclidean nearest neighbors.
**The exception worth knowing.** Cosine and inner-product (dot) are equivalent for L2-normalized vectors: for unit vectors, `cosine(a, b) = dot(a, b)` and so all rankings coincide. A DB built under cosine can be queried under dot on normalized vectors without harm; this is why many libraries optimize cosine by normalizing once and then running dot internally. This exception does NOT extend to Euclidean.
**Fix.** Rebuild the index under the metric you actually want to query with. There is no shortcut. Some databases (Qdrant, pgvector) force you to declare the metric at collection creation precisely so this footgun cannot happen in the first place. If the team needs to support both metrics, they need two indexes.
**Operational lesson.** Always pin the build time metric in code or in IaC alongside the embedding model version. Metric mismatch is one of the silent recall killers in vector-DB production, alongside model drift and the metadata-filter HNSW pitfall.
Quick reference
TL;DR
HNSW edges were chosen under cosine. Searching them with Euclidean follows edges that point in the wrong direction for the new metric, so the greedy walk strands in the wrong region.
Imagine someone built a subway map where the lines connect stations that are close in **walking distance**. Now you decide to use that same map but you want to travel by **car**. The lines on the map no longer reflect car distances; following them, you end up far from your destination. The map (the index graph) is welded to the distance it was built for. To use a different distance, you need a different map.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Application needs to switch metrics at runtime An ANN index cannot serve multiple metrics. Build separate indexes, one per metric.
Vectors are already L2-normalized for all use cases Then cosine, dot, and Euclidean all coincide and the bug cannot happen. But verify normalization is enforced everywhere, not just at embedding time.
Production system needs zero downtime metric migration You must build the new index in parallel and cut traffic over; you cannot mutate the existing index in place.
Quick scan · 2–4 min
Everything important, quickly.
3 min: graph edges encode the metric explanation + cosine versus dot exception with the unit-vector identity + rebuild as the only correct fix + operational guardrails (Qdrant/pgvector declare at creation).
Side-by-side
Metric swap
Safe?
When
Cosine -> Dot product
Yes
Only on L2-normalized vectors
Cosine -> Euclidean
No
Different orderings on unnormalized vectors
Dot product -> Euclidean
No
Different orderings
Cosine -> Cosine (different index)
Yes (trivially)
Same metric, same ordering
Real-world examples
Real products, models, and research that use this idea.
1Qdrant requires the distance metric to be declared at collection creation and refuses to swap it on existing collections.
2pgvector also requires the metric to be picked at index creation (`USING ivfflat (embedding vector_cosine_ops)` vs `vector_l2_ops`).
3Faiss does not enforce the metric at the API level; teams routinely encounter this bug when migrating between IndexFlatIP and IndexFlatL2.
4Pinecone tracks the metric at index creation and rejects queries that imply a different metric.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you migrate metric without downtime?
Sign in or go Pro to see the approach for this follow-up.
QWhy does normalization make cosine, dot, and Euclidean coincide?
Sign in or go Pro to see the approach for this follow-up.
QWhat if the team built one HNSW under cosine and another under Euclidean and the cosine one has higher recall on their eval set?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Trying to fix the bug by changing the query metric back to cosine while keeping the same index. That works only because the index was correct for cosine to begin with; the real lesson is that the index cannot serve a metric it was not built for.