Number Class
← Back to Explore
Computer Science Artificial Intelligence & Data Vector Embedding Design

Cosine vs. Euclidean Was Decided Before You Opened the Dropdown

A 2024 Netflix paper shows cosine similarity can be silently gamed by an invisible training-time regularizer

S.J. Nam 7 min read
Cosine vs. Euclidean Was Decided Before You Opened the Dropdown

The Dropdown That Decides Nothing

Open Pinecone, Weaviate, or Qdrant to create a new vector index and you hit a menu that looks consequential: metric type — cosine, Euclidean, dot product. Engineers argue about this choice in Slack threads and conference talks as though it were a fork in the road, repeating a rule of thumb that has calcified into folklore: cosine for text, Euclidean for images. But sit with the math for a minute and a strange fact emerges. For a huge share of embeddings actually running in production search systems today, that dropdown is close to decorative. Cohere's embeddings are normalized to unit length, and once vectors are normalized, "the dot product and cosine similarity are mathematically equivalent for these vectors." The same holds for OpenAI's models, where
when the vectors are normalized to a magnitude of 1, as OpenAI embeddings are, the results of cosine similarity and Euclidean distance will be equivalent
, so that
the rankings of the vectors will be the same, even if the actual values differ
. The debate people are having in those Slack threads isn't really about which metric to choose. It was already settled, upstream, by whoever trained the model — and most of the industry has been arguing about the wrong variable.

Same Neighbors, Different Numbers

This equivalence isn't a minor footnote; it dissolves half the popular explainer content on the topic. Cosine similarity measures the angle between two vectors while ignoring their length; Euclidean distance measures straight-line proximity and cares about length very much. Those are genuinely different geometric ideas —
cosine similarity focuses on directional alignment between vectors while Euclidean distance emphasizes geometric proximity
. But geometric difference is not the same as practical difference. When every vector in your index has been forced onto the surface of a unit hypersphere — which is exactly what normalization does — length stops varying, and the only thing left to differ is angle. At that point Euclidean distance is just a monotonic transform of cosine similarity in disguise: it will pull back the exact same top-k results in the exact same order. A blog by developer Tom Hazledine walks through this directly, noting that once vectors sit at magnitude 1, the two metrics stop disagreeing about which neighbors are closest. So the question "cosine or Euclidean?" only has teeth when someone hasn't normalized — and the interesting story is what happens in that unnormalized world, because it turns out cosine similarity's reputation there is shakier than most tutorials let on.

The Netflix Experiment

In March 2024, three researchers — Harald Steck, Chaitanya Ekanadham, and Nathan Kallus, working out of Netflix and Cornell — published a paper with a deliberately provocative title: "Is Cosine-Similarity of Embeddings Really About Similarity?" Their answer, in short, was: often, no. The paper opens from the textbook definition —
cosine-similarity is the cosine of the angle between two vectors, or equivalently the dot product between their normalizations
— and then shows that this tidy definition hides a trap for the enormous class of embeddings produced by matrix factorization and similar learned models, the very models behind much of recommendation and search. Because such models are typically trained without ever constraining vector length, the paper demonstrates that
cosine similarity of learned embeddings from matrix factorization models can be rendered arbitrary by a diagonal gauge matrix
— meaning a regularization choice invisible to the person running a query later can silently reshape which items look "similar" without changing the model's actual predictions at all. In practice, the authors found that naively applying cosine similarity
can generate meaningless results
, and their conclusion was blunt:
we caution against blindly using cosine-similarity and outline alternatives
. That's a striking thing to hear from people building recommendation systems at one of the largest embedding-driven products on the planet — not "pick the right metric," but "the metric itself may not mean what you think it means."

Cosine's Defenders Fight Back

The Netflix paper did not go unanswered. A follow-up paper, "In Defense of Cosine Similarity: Normalization Eliminates the Gauge Freedom," takes the Steck/Ekanadham/Kallus result seriously rather than dismissing it — the authors write that
their result is correct and important for practitioners who compute cosine similarity on
raw, unconstrained embeddings — but argue the fix was hiding in plain sight the whole time. If the "gauge freedom" that makes cosine similarity arbitrary comes from unconstrained vector length, then constraining that length — normalizing embeddings during or after training, exactly as OpenAI and Cohere already do — eliminates the ambiguity by construction. In other words, the rebuttal doesn't rescue the dropdown-level debate; it relocates the real fix even further upstream, into training-time architecture decisions, and away from anything a search engineer configures when standing up a vector index. Both papers, despite disagreeing about how alarmed to be, agree on where the actual lever sits: not in the metric, but in whether the embedding space was disciplined enough beforehand to make any one metric trustworthy.

Where the Choice Still Bites

None of this makes the cosine-versus-Euclidean question worthless — it just relocates where it matters. Plenty of embeddings in production are not normalized: raw autoencoder bottlenecks, certain image-feature extractors, older matrix-factorization recommenders, and custom embeddings fine-tuned without a normalization layer. Vector database vendors still ship all three metrics for good reason —
most vector databases support multiple metrics, and cosine similarity is most common for text embeddings while Euclidean is often used for image features, since the choice of metric significantly impacts search results and should match the embedding model's training
. That last clause is the whole essay in miniature: the metric has to match how the model was trained, not the other way around. Pick cosine similarity for an unnormalized embedding trained under an L2-distance loss and you're not making a stylistic choice — you're quietly asking the model a question it was never taught to answer, and Steck and her coauthors just showed how badly that can go. There's also a purely operational wrinkle worth naming: dot product is cheaper to compute at scale than cosine similarity, because cosine requires normalizing on the fly unless vectors are pre-normalized, which is one more reason serious production systems normalize once at write time rather than argue about metrics at query time.

The Real Fork in the Road

Treat "cosine or Euclidean" as the central design decision in an AI search system and you'll spend your review meetings on the one lever that, for a normalized embedding space, does nothing at all — and on the one lever that, for an unnormalized space, can be quietly gamed by a regularization term nobody in the room remembers setting. The Netflix paper's real contribution wasn't a verdict against cosine similarity; it was a demonstration that a distance metric is not a free-floating mathematical truth you bolt onto a finished embedding — it's a promise the training process either keeps or breaks. Ask a vendor which metric their index defaults to, by all means. But ask a harder question first: was this embedding space built to make that promise mean anything? If nobody in the room can answer, the dropdown was never where the decision lived.

References