Number Class
← Back to Explore
Computer Science Artificial Intelligence & Data Natural Language Processing

Cosine Similarity Was Built for Card Catalogs, Not Meaning

A 2024 Netflix study found that regularized embedding models can yield contradictory similarity rankings from the exact same training accuracy

S.J. Nam 7 min read
Cosine Similarity Was Built for Card Catalogs, Not Meaning

A recommendation engine tells a streaming company that two thrillers are "0.91 similar." A resume-screening tool tells a recruiter that a candidate's skills vector sits at "0.84" against the job description. These numbers carry an air of scientific exactness, as if some hidden ruler had measured the true conceptual distance between two ideas. It hasn't. That number is cosine similarity, and it was never built to measure meaning. It was built, in the 1960s, to stop a library search engine from getting fooled by long documents. The fact that it now sits at the center of how large language models decide what's "relevant" to you is less a triumph of mathematical destiny and more a happy accident that nobody has seriously reconsidered — and a 2024 paper shows the accident has a crack in it that most explainers never mention.

The Angle, Not the Distance

Strip away the AI mystique and cosine similarity is a single geometric idea: instead of asking how far apart two vectors are, ask what angle separates them. The formula divides the dot product of two vectors by the product of their magnitudes, which cancels out length entirely and leaves you with a number between −1 and 1 — pure direction, no size. Two vectors pointing the same way score 1 regardless of whether one is twice as long as the other; two at right angles score 0; opposites score −1.

That single design choice — discard magnitude, keep direction — is the whole trick, and it's also the whole limitation. Cosine similarity cannot tell you that one document is simply "more" of something than another; it can only tell you they point the same way. Whether that's a feature or a bug depends entirely on why you're comparing the vectors in the first place, which is a question the formula itself has no opinion about.

Born to Fix a Library Problem

Cosine similarity's popularity didn't start with neural networks. It started with Gerard Salton, the Cornell computer scientist who built the SMART information retrieval system starting in the 1960s and, with collaborators, formalized the vector space model for text search in the mid-1970s — representing documents and queries as vectors of word weights so that a computer could rank which documents "matched" a query. Salton's group, working alongside Karen Spärck Jones's inverse-document-frequency insight, was solving a mundane engineering headache: a 4,000-word article naturally shares more raw word overlap with a query than a 40-word abstract does, simply because it has more words to overlap with. Dot-product similarity rewarded length. Dividing by each vector's magnitude — cosine similarity — neutralized that bias so a short, precise document could rank alongside a long, sprawling one.

In other words, the normalization at the heart of cosine similarity was invented to solve a bookkeeping problem in library science, not to formalize a theory of conceptual closeness. It was a length-correction, retrofitted decades later into a universal similarity metric because it happened to be cheap to compute and easy to reason about. That lineage matters, because every time someone treats a cosine score as a semantic verdict, they're inheriting a fix for term-frequency bias in card-catalog software and asking it to do philosophy.

From Card Catalogs to King Minus Man Plus Woman

The tool migrated because it was lying around and it worked well enough. When Tomas Mikolov and colleagues at Google published word2vec in 2013, showing that word embeddings could support arithmetic like "king − man + woman ≈ queen," the standard way to check "how close" the resulting vector landed to "queen" was, again, cosine similarity — angle, not distance, because word frequency effects distort raw vector length in the same way document length once did. The habit carried straight into today's large-scale systems: OpenAI's own embeddings guidance recommends cosine similarity for comparing its text-embedding vectors, and because those particular embeddings are normalized to unit length by the provider, the cosine calculation there quietly collapses into a plain dot product anyway. Vector databases built to serve semantic search and retrieval-augmented generation — the infrastructure behind most "chat with your documents" products — offer cosine similarity as a default index metric alongside Euclidean distance and dot product, largely because it's numerically stable and easy to threshold.

None of this happened because researchers proved cosine similarity was the mathematically correct notion of semantic closeness for high-dimensional learned representations. It happened because the metric was already sitting in every statistics and information-retrieval textbook, computationally trivial, and comfortingly bounded between −1 and 1 — a number that looks like a probability even though it isn't one.

The Angle That Isn't Really There

Here is the detail most cosine-similarity primers skip entirely. In 2024, Netflix researcher Harald Steck and coauthors published an analysis interrogating a question that sounds almost heretical: is cosine similarity of learned embeddings actually measuring similarity at all? Their answer, for an important class of models, was unsettling. When embeddings come from models trained with regularization — a near-universal practice to prevent overfitting — you can often find multiple embedding solutions that fit the training data and the loss function equally well, yet disagree with each other about which items are "similar," sometimes dramatically. Cosine similarity, in these cases, isn't reading off some fixed geometric truth latent in the data; it's reading off an artifact of which particular, arbitrary solution the optimizer happened to settle into.

This is the counterintuitive part worth sitting with: the same underlying recommendation model, trained on the same data to the same accuracy, can be represented by embeddings that yield contradictory cosine-similarity rankings — and there's no principled way, from the loss function alone, to say which ranking is the "real" one. The angle between two vectors feels like an objective geometric fact once it's computed, precisely because arccosine and dot products are exact operations. But exactness in the arithmetic says nothing about whether the vectors being compared were pinned down by the training process in a unique, meaningful way. Salton's 1975 fix solved a real, well-defined problem: normalizing for document length in a fixed vector space built from word counts. Modern embedding spaces are not fixed in that sense — they're the byproduct of stochastic optimization with regularization, and cosine similarity was never built to survive that kind of ambiguity.

What the Angle Actually Buys You

None of this means cosine similarity is a bad tool — for genuinely length-invariant comparisons, like matching a short query against long documents, or comparing normalized embeddings where the model architecture guarantees a stable geometry, it remains a sensible and cheap default. The mistake is treating the number it outputs as a discovery about the world rather than a consequence of choices made upstream: how the embedding was trained, how it was regularized, whether it was normalized, and what objective it was optimized against. A cosine score of 0.91 is not evidence that two ideas are 91 percent alike. It's evidence that two vectors, produced by a specific pipeline with specific arbitrary settings, happen to point in nearly the same direction — this time.

The next time a system reports a similarity score with three decimal places of confidence, the right question isn't "how similar are these things?" It's "similar according to which arbitrary solution, trained under which arbitrary constraints, on which particular day?" Precision in the decimal point is not the same thing as precision in the concept.

References