A team indexed embeddings under cosine but queried with Euclidean, and recall collapsed. Diagnose the cause.

**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.