Cosine Similarity

Definition: Cosine similarity measures how alike two vectors are by comparing the angle between them, not their length. It is the cosine of that angle, computed as the dot product of the vectors divided by the product of their magnitudes, and it ranges from -1 (pointing in exactly opposite directions) through 0 (orthogonal, unrelated) to 1 (pointing in exactly the same direction). Because it discards magnitude entirely, it is the default way to compare high-dimensional Embeddings where direction encodes meaning and length is often just an artifact of how a vector was produced.

How It Works

The Core Formula

For two vectors $\mathbf{A}$ and $\mathbf{B}$ in $n$ -dimensional space, cosine similarity is:

\cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \, \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \; \sqrt{\sum_{i=1}^{n} B_i^2}}

The numerator, $\mathbf{A} \cdot \mathbf{B}$ , is the dot product — it grows when the two vectors point in similar directions and shrinks (or goes negative) when they diverge. The denominator, $\|\mathbf{A}\| \, \|\mathbf{B}\|$ , is the product of the two vectors’ Euclidean (L2) norms — their lengths. Dividing by that product is what strips magnitude out of the result: scaling either vector by any positive constant leaves $\cos(\theta)$ unchanged, because the scale factor appears in both the dot product and the norm and cancels.

Geometric Interpretation

Cosine similarity is literally the cosine function applied to the angle $\theta$ between two vectors anchored at the origin. Small angles mean the vectors point roughly the same way and the cosine approaches 1. A right angle means the vectors share no directional relationship and the cosine is 0. An angle approaching 180° means the vectors point away from each other and the cosine approaches -1.

  theta = 0 deg  ->  similarity = 1.0
  A ------------------> B
  (same direction, perfectly aligned)

  theta = 45 deg ->  similarity = 0.71
                    B
                   /
                  /
                 / 45deg
  A -------------+----------->

  theta = 90 deg ->  similarity = 0.0
        B
        |
        |
        | 90deg
  A -----+----------->

  theta = 180 deg -> similarity = -1.0
  B <------------------ A
  (opposite direction)

Step-by-Step Computation

Compute the dot product of the two vectors: multiply corresponding components and sum them.
Compute the magnitude of each vector: square each component, sum, take the square root.
Divide the dot product by the product of the two magnitudes.
Interpret the result as a value in $[-1, 1]$ (or $[0, 1]$ if all components are non-negative, which is common for word counts, TF-IDF weights, and many learned embeddings after certain activation functions).

In production systems this is almost never computed pairwise from raw formulas. Instead, every vector is L2-normalized once — divided by its own magnitude so it has length 1 — and stored that way. Once vectors are unit-length, cosine similarity collapses to a plain dot product, because $\|\mathbf{A}\| = \|\mathbf{B}\| = 1$ removes the denominator entirely. That single simplification is why vector databases and similarity search libraries can lean on highly optimized matrix-multiply routines (BLAS, GPU tensor cores) instead of recomputing norms on every query.

Implementation Notes

The formula translates directly into code, and the naive and production-optimized versions are worth seeing side by side:

function cosine_similarity(A, B):
    dot = 0
    norm_a = 0
    norm_b = 0
    for i in range(len(A)):
        dot += A[i] * B[i]
        norm_a += A[i] * A[i]
        norm_b += B[i] * B[i]
    if norm_a == 0 or norm_b == 0:
        return 0.0   # guard: undefined for a zero vector
    return dot / (sqrt(norm_a) * sqrt(norm_b))

# Production shortcut: normalize once at index time,
# then similarity search at query time is just a dot product.
function normalize(A):
    norm = sqrt(sum(a * a for a in A))
    return A if norm == 0 else [a / norm for a in A]

unit_A = normalize(A)
unit_B = normalize(B)
similarity = dot(unit_A, unit_B)   # equals cosine_similarity(A, B)

The naive version runs in $O(n)$ time for one pair. Comparing one query against $m$ stored vectors of dimension $n$ costs $O(mn)$ — exactly a matrix-vector multiply, which is why production similarity search sits on top of BLAS or GPU matrix-multiplication kernels rather than a hand-rolled loop over the collection.

Cosine Similarity and the Unit Hypersphere

L2-normalizing a vector projects it onto the unit hypersphere, the set of all points at distance 1 from the origin in $n$ -dimensional space. For two vectors already on that sphere, $\|\mathbf{A} - \mathbf{B}\|^2 = 2 - 2(\mathbf{A} \cdot \mathbf{B})$ , which means minimizing Euclidean distance and maximizing cosine similarity produce the identical ranking once vectors are normalized. That equivalence is why many vector databases let an index be queried with either metric and return the same nearest neighbors — the normalization step, not the metric choice, is what actually matters.

Variants

Cosine distance: $1 - \cos(\theta)$ , turning similarity into a dissimilarity score for algorithms (like many clustering routines) that expect a distance rather than a similarity.
Angular distance: $\arccos(\cos(\theta)) / \pi$ , a properly normalized metric that, unlike cosine distance, satisfies the triangle inequality — useful when an algorithm’s correctness proof depends on a true metric space.
Soft cosine similarity: extends the formula with a similarity matrix between dimensions themselves, so near-synonymous terms contribute partial overlap instead of requiring exact dimension matches. Common in classic bag-of-words NLP pipelines.
Weighted cosine similarity: applies term weighting (most often TF-IDF) to the raw vectors before computing cosine, so common, low-information words contribute less to the score than rare, distinctive ones.
Multi-vector / late-interaction similarity: instead of pooling a passage into one vector, keeps one embedding per token and aggregates token-level cosine matches (the approach behind ColBERT-style retrieval), trading the speed of a single dot product for finer-grained matching that a single pooled vector would blur together.

Why It Matters

It is the default scoring function for Retrieval-Augmented Generation (RAG) pipelines — ranking document chunks against a query embedding to decide what gets fed into the model’s context window.
Recommendation systems use it for both collaborative filtering (comparing user-preference vectors) and content-based filtering (comparing item-feature vectors) to surface “more like this” results.
It is the standard metric behind semantic textual similarity (STS) benchmarks used to evaluate how well an embedding model captures meaning, independent of surface wording.
Contrastive learning objectives — the training approach behind models like CLIP and SimCLR — directly optimize cosine similarity, pulling matching pairs toward 1 and pushing mismatched pairs toward 0 or negative.
Face verification and speaker-identification systems compare embedding vectors from a neural encoder using cosine similarity to decide whether two samples belong to the same identity.
Near-duplicate and plagiarism detection tools use it to flag documents that reuse the same ideas even when the exact wording differs substantially.
Anomaly detection systems flag data points whose embedding falls below a cosine similarity threshold to the nearest known cluster centroid, catching outliers a raw-distance metric might miss.
Because pre-normalized vectors reduce cosine similarity to a dot product, approximate nearest neighbor (ANN) indexes such as FAISS and HNSW can use fast inner-product search as a direct proxy for cosine ranking, making similarity search viable at billions of vectors.
It is scale-invariant, which matters enormously for embeddings: two encoders (or two runs of the same encoder) can produce vectors of very different typical length, and cosine similarity still yields comparable, meaningful scores.
Multimodal systems lean on it to bridge modalities entirely — CLIP-style models embed images and text into a shared space specifically so that cosine similarity between an image vector and a caption vector is meaningful.

Worked Example: Computing Cosine Similarity by Hand

Suppose a simple bag-of-words model represents short documents as counts over a 3-word vocabulary: ["loan", "credit", "touchdown"]. Three documents:

Document	Text	Vector (loan, credit, touchdown)
A	“bank issues personal loan”	(3, 2, 0)
B	“credit card loan approval”	(2, 3, 0)
C	“quarterback throws touchdown”	(0, 0, 4)

Visualizing the Worked Example

Ignoring the “touchdown” dimension (which is 0 for both A and B), the vectors A and B sit close together in the loan-credit plane, separated by a narrow angle:

  credit
  ^
  3 |            B (2,3)
    |           /
  2 |          /
    |         /   A (3,2)
  1 |        /   /
    |       /   /
    |      / θ /
  0 +-----+---+------------------> loan
    0     1   2   3

  theta(A,B) ~ 22 degrees  ->  cos(theta) = 12/13 ~ 0.9231

Vector C = (0, 0, 4) points entirely along the touchdown axis, perpendicular to this loan-credit plane, which is exactly why its dot product with A is 0.

Step 1 — Dot product of A and B:

\mathbf{A} \cdot \mathbf{B} = (3)(2) + (2)(3) + (0)(0) = 6 + 6 + 0 = 12

Step 2 — Magnitudes:

\|\mathbf{A}\| = \sqrt{3^2 + 2^2 + 0^2} = \sqrt{9 + 4} = \sqrt{13} \approx 3.6056

\|\mathbf{B}\| = \sqrt{2^2 + 3^2 + 0^2} = \sqrt{4 + 9} = \sqrt{13} \approx 3.6056

Step 3 — Divide:

\cos(\theta) = \frac{12}{3.6056 \times 3.6056} = \frac{12}{13} \approx 0.9231

Documents A and B share heavy overlap on “loan” and “credit,” and their cosine similarity of roughly 0.92 reflects that they’re topically almost the same, even though they aren’t word-for-word identical.

Now compare A to C:

\mathbf{A} \cdot \mathbf{C} = (3)(0) + (2)(0) + (0)(4) = 0

The dot product is exactly 0, so $\cos(\theta) = 0$ regardless of the magnitudes — the vectors are orthogonal because they don’t share a single nonzero dimension. A finance document and a sports document score 0.0, correctly signaling “unrelated.”

Demonstrating magnitude invariance: scale document B’s counts up tenfold, as if it were a much longer document repeating the same words proportionally — $\mathbf{B'} = (20, 30, 0)$ .

\mathbf{A} \cdot \mathbf{B'} = (3)(20) + (2)(30) = 60 + 60 = 120, \qquad \|\mathbf{B'}\| = \sqrt{400 + 900} \approx 36.056

\cos(\theta) = \frac{120}{3.6056 \times 36.056} = \frac{120}{130.02} \approx 0.9231

Identical result. Document length changed by 10x; the similarity score didn’t move at all, because cosine similarity only cares about the proportions between dimensions, not their absolute scale.

Bonus — what negative similarity looks like: introduce a fourth document, D, whose vector is $(-2, -3, 0)$ — the mirror image of B, as if it were built from opposite-signed weights (for instance, a topic model dimension that flips sign for content warning against loans and credit).

\mathbf{A} \cdot \mathbf{D} = (3)(-2) + (2)(-3) + (0)(0) = -6 - 6 = -12

\|\mathbf{D}\| = \sqrt{(-2)^2 + (-3)^2} = \sqrt{13} \approx 3.6056, \qquad \cos(\theta) = \frac{-12}{3.6056 \times 3.6056} = \frac{-12}{13} \approx -0.9231

A score of -0.92 places A and D almost diametrically opposite each other — the geometric signal that two vectors don’t just fail to relate, they point in actively contrary directions.

Cosine Similarity vs Euclidean Distance vs Dot Product

These three metrics are the workhorses of vector comparison, and picking the wrong one silently degrades results without throwing any error.

Metric	Formula	Sensitive to Magnitude?	Typical Range	Best Used When
Cosine similarity	$\frac{\mathbf{A} \cdot \mathbf{B}}{\\|\mathbf{A}\\|\\|\mathbf{B}\\|}$	No — fully invariant	$[-1, 1]$	Comparing direction/meaning; embeddings whose length varies with unrelated factors (document length, encoder quirks)
Euclidean distance	$\sqrt{\sum (A_i - B_i)^2}$	Yes — heavily	$[0, \infty)$	Magnitude itself carries real information (physical measurements, pixel intensities, k-means centroids in raw feature space)
Dot product (raw)	$\sum A_i B_i$	Yes — proportional to both magnitudes	$(-\infty, \infty)$	Vectors are already pre-normalized (then it equals cosine similarity) or magnitude is an intentional relevance signal (e.g., popularity-weighted embeddings)
Angular distance	$\arccos(\cos\theta)/\pi$	No — invariant	$[0, 1]$	An algorithm’s correctness proof requires a true metric satisfying the triangle inequality

Why does normalization invariance matter so much specifically for embeddings? Embedding magnitude is frequently an accident of training — it can correlate with token frequency, sentence length, or how many times a model has seen similar inputs, none of which are meant to represent “relevance” or “meaning.” Two sentences with identical meaning but different lengths can produce embeddings pointing in nearly the same direction but with different norms. Euclidean distance and raw dot product both get pulled around by that difference in norm; cosine similarity ignores it and measures only what the embedding was actually trained to encode: direction. This is precisely why nearly every semantic search, RAG, and recommendation system defaults to cosine similarity (or its dot-product shortcut on pre-normalized vectors) rather than Euclidean distance.

Cosine Similarity at Scale

Computing exact cosine similarity against every vector in a collection costs $O(mn)$ per query for $m$ stored vectors of dimension $n$ — fine for thousands of vectors, far too slow for the hundreds of millions typical of production embedding indexes. A handful of techniques make it practical:

Technique	What It Trades Off	Example Systems
Pre-normalization + dot product	No accuracy loss, just algebraic simplification	FAISS (IndexFlatIP), pgvector, most vector databases
HNSW graph search	Small recall loss for a large speedup	FAISS, Qdrant, Weaviate, Milvus
IVF (inverted file index)	Coarser candidate lists, very fast at huge scale	FAISS, Milvus
Product / scalar quantization	Compressed vectors, small approximation error	FAISS, ScaNN
Locality-sensitive hashing (LSH)	Approximates cosine ranking via bucketed hash collisions	Historical baseline; largely superseded by HNSW in modern stacks

None of these change what is being measured — they still rank by cosine similarity — they just avoid a brute-force scan of every stored vector. Sentence and document embedding models commonly output 384, 768, 1536, or 3072 dimensions, dense enough that dot-product search stays fast on modern hardware while still tall enough to run into the curse-of-dimensionality effect covered below.

Cosine Similarity Across Data Representations

Cosine similarity behaves differently depending on what kind of vector it’s applied to:

Representation	Typical Dimensionality	Sparsity	Behavior
One-hot / raw word counts	Vocabulary size (10k–1M+)	Very sparse	Similarity dominated by shared rare words unless reweighted
TF-IDF vectors	Vocabulary size	Sparse	Downweights common words; the classic pre-neural search technique
Dense neural embeddings	128–4096	Dense	Every dimension contributes; captures relationships absent from exact word overlap
Binary / hashed vectors	Hundreds–thousands of bits	Dense as bits	Approximates cosine similarity cheaply via Hamming distance at extreme scale
Learned sparse vectors (e.g. SPLADE)	Vocabulary size	Sparse, but learned rather than hand-weighted	Combines the interpretability of sparse features with signal from a trained neural model

Sparse representations produce a similarity of exactly 0 far more often, since two documents may simply share no vocabulary term at all. Dense neural embeddings almost always yield some nonzero similarity, because every learned dimension mixes information from the whole input rather than one discrete feature.

Choosing a Similarity Threshold

Cosine similarity returns a continuous score, but most applications need a binary decision — match or no match, auto-route or escalate to a human. Picking that cutoff is an empirical exercise, not a formula:

Score Range	Typical Interpretation	Caveat
0.90 – 1.00	Near-duplicate or close paraphrase	Can still miss meaning-changing negation (“approved” vs “not approved”)
0.75 – 0.90	Strongly related, same topic	Common default zone for RAG chunk retrieval
0.50 – 0.75	Loosely related	Often too noisy for a fully automated decision
Below 0.50	Weak or no relationship	Highly model- and domain-dependent

These bands are only a starting point. The right cutoff depends on the embedding model, typical text length, and domain vocabulary, so calibrating against a held-out set of known matches and non-matches — rather than guessing a round number — is standard practice before shipping a threshold-based decision.

Sweep and score. Compute similarity for a labeled sample of true matches and true non-matches, then scan candidate thresholds against precision and recall to find where they trade off acceptably for the product’s tolerance for false positives versus false negatives.
Re-calibrate on every model change. Any change to the embedding model — a version bump, a fine-tune, a switch in dimensionality — invalidates the old sweep and requires a fresh one.

Comparison

Concept	What It Measures	Handles Magnitude?	Common Domain
Cosine Similarity	Angle between two vectors	Invariant	Dense embeddings (text, image, audio)
Jaccard Similarity	Overlap of two sets relative to their union	N/A — set-based, not vector-based	Sparse binary features, tag/keyword overlap, deduplication
Pearson Correlation	Linear relationship between two variables after centering each on its own mean	Invariant to scale and offset	Statistics, comparing rating patterns where users have different baseline scales
Manhattan (L1) Distance	Sum of absolute per-dimension differences	Sensitive	Grid-like or sparse feature spaces, robust to outliers in individual dimensions
Hamming Distance	Count of differing positions between two equal-length binary strings	N/A — bit-based, not magnitude-based	Locality-sensitive-hashed vectors, extreme-scale approximate search

Cosine similarity and Pearson correlation are closely related — correlation is essentially cosine similarity computed on mean-centered vectors, which is why correlation can handle cases where two rating vectors are shifted by a constant offset (a “harsh” rater and a “generous” rater with the same relative preferences) while raw cosine similarity would not. Jaccard similarity operates on sets rather than continuous vectors entirely, making it suited to binary presence/absence data like shared tags, rather than dense embeddings.

Real-World Use Cases

Semantic search engines ranking indexed documents against a query embedding instead of relying on exact keyword matches.
Retrieval-Augmented Generation (RAG) pipelines selecting which chunks of a knowledge base to inject into an Large Language Model (LLM)‘s context window.
Streaming platforms computing item-to-item similarity (“more like this”) from learned embeddings of songs, videos, or products.
Reverse image search and visual similarity tools comparing Computer Vision embeddings from a convolutional or transformer-based image encoder.
Chatbot and voice-assistant intent classifiers matching a user’s utterance embedding against a library of canonical intent examples.
Fraud and anomaly detection systems comparing a transaction’s or user’s behavioral embedding against known-normal cluster centroids.
Deduplication pipelines for large scraped datasets, flagging near-identical text or images before they pollute a training set.
Resume-to-job-description matching tools in HR tech, ranking candidates by embedding similarity to a role’s requirements.
Customer support ticket triage, routing incoming tickets to the team whose historical tickets have the closest embedding match.
Plagiarism detection software comparing submitted text against a reference corpus at the paragraph or sentence-embedding level.

Common Pitfalls

Confusing similarity with distance. Cosine distance is typically 1 - similarity; mixing the two up silently flips whether “higher” means “more alike” or “less alike,” which is an easy bug to miss because both are just numbers in a similar range.
Comparing embeddings from two different models. Cosine similarity assumes both vectors live in the same learned space. Embeddings from different models (or even different versions of the same model) aren’t guaranteed to share a coordinate system, so the resulting score can look plausible while meaning nothing.
Dividing by a zero vector. A document or item with no matching features at all — an all-zero vector — has undefined magnitude in the denominator. Production code needs explicit handling (skip, default score, or small epsilon) rather than letting it throw or silently return NaN.
Treating high cosine similarity as proof of truth. Two pieces of text can be semantically similar in phrasing while being factually inconsistent; RAG systems that trust similarity scores alone as a truth signal are vulnerable to retrieving confidently-worded but wrong context, compounding Hallucination risk downstream.
Applying raw cosine similarity to sparse, unweighted count vectors. With extremely sparse vectors, similarity ends up dominated by a handful of high-frequency, low-information words unless the vectors are reweighted first (TF-IDF is the classic fix).
Assuming similarity thresholds transfer across model versions. A cutoff like “0.8 counts as a match” tuned for one embedding model becomes meaningless — often silently — after re-embedding a corpus with a newer or different model, because the score distribution shifts.
Relying on cosine distance where a true metric is required. Cosine distance does not satisfy the triangle inequality in all cases, so algorithms whose correctness guarantees depend on a proper metric space can behave unexpectedly if swapped in naively.
Ignoring the curse of dimensionality. In very high-dimensional embedding spaces, cosine similarities between essentially random vectors cluster tightly around 0, compressing the range that actually carries signal and making fixed thresholds fragile.
Skipping normalization before inner-product ANN search. Many vector databases use raw dot product internally for speed. If vectors aren’t L2-normalized before indexing, a search that’s supposed to approximate cosine similarity quietly becomes biased toward longer vectors instead.
Reusing a single global threshold across very different query lengths. A one-word query and a three-paragraph query against the same index rarely produce comparable similarity distributions, so a threshold tuned on one length class can misfire badly on the other.

Example

A mid-sized SaaS company builds a support-ticket triage system to route incoming tickets to the right team without a human reading each one first. Every night, an Large Language Model (LLM)-based encoder converts a library of 4,000 historically-resolved tickets into embedding vectors and stores them, pre-normalized, in a vector index alongside the team that resolved each one. When a new ticket arrives, the system embeds its text the same way and computes cosine similarity against every vector in the index — in practice, a single fast dot-product matrix multiply against the pre-normalized library.

The ticket “my invoice charged me twice this month” comes in. Its embedding lands with cosine similarity 0.89 against a cluster of past billing tickets, 0.31 against a cluster of login-issue tickets, and 0.04 against a cluster of feature-request tickets. The system routes it straight to billing support, confident because 0.89 clears the team’s calibrated threshold with room to spare. A second ticket, “the app crashed when I tried to export my invoice as a PDF,” scores 0.61 against billing and 0.58 against a technical-bugs cluster — close enough that the system doesn’t auto-route it and instead flags it for a human to triage, since a narrow margin between competing clusters is exactly the situation where a wrong automatic routing decision is most likely.

Six months later, the company swaps in a newer, more accurate embedding model. Every threshold tuned against the old model’s score distribution stops making sense immediately, because the new model produces systematically different similarity values for the same ticket pairs — a textbook case of the “thresholds don’t transfer across model versions” pitfall. The team re-embeds the entire historical ticket library and re-calibrates thresholds against the new model before rolling it out, rather than assuming the old cutoffs still apply.

Referenced by

Dig deeper

Spot an error in this note?