TechByteByByte

Cosine Similarity

The most common way to measure how similar two vectors are — comparing the angle between them rather than their raw size, which is exactly why it works so well for comparing meaning.

#cosine-similarity#vector#embedding#data-representation-phase

Every article about vector search and HNSW so far has said “find the closest vectors” without pinning down exactly what “closest” means mathematically. The single most common answer, especially for embeddings, is cosine similarity.

The simple definition

Cosine similarity measures how similar two vectors are by comparing the angle between them, ignoring their length entirely. Two vectors pointing in almost exactly the same direction get a cosine similarity close to 1 (highly similar), two vectors pointing in completely unrelated directions get a similarity close to 0, and two vectors pointing in exactly opposite directions get a similarity of -1 (maximally dissimilar). The key word is angle — cosine similarity deliberately doesn’t care how long either vector is, only which direction each one points.

flowchart LR
    A[Vector A] -->|small angle between them| B[Vector B: high cosine similarity, close to 1]
    C[Vector A] -->|large angle between them| D[Vector C: low cosine similarity, close to 0]

Why ignoring length is exactly the right choice for embeddings

This is the single most important thing to understand about why cosine similarity became the standard choice for comparing embeddings, and it’s worth being precise about it. Recall from the Embedding article that a vector’s meaning comes from its overall pattern and direction in space, not from its raw magnitude. Two sentences that say the same thing using very different amounts of detail or repetition might produce embedding vectors of somewhat different lengths, even while pointing in essentially the same semantic direction. Cosine similarity correctly recognizes these as highly similar, because it only compares direction — a distance measure that also factored in raw vector length could incorrectly judge them as less similar, purely because of an incidental difference in magnitude that has nothing to do with actual meaning.

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of two people pointing at something in the distance. One person points with their arm fully extended; the other points with their arm only half-extended, more casually. Both are pointing in essentially the same direction, at the same thing — the difference in arm length doesn’t change what they’re indicating. Cosine similarity is like judging “are these two people pointing at the same thing” purely by comparing the direction of their arms, ignoring how far each arm happens to be extended.

Where this breaks down: Two people’s pointing gestures are interpreted by another person using real, intuitive spatial reasoning. Cosine similarity is a precise mathematical calculation — specifically, it’s calculated using the Dot Product of the two vectors, divided by the product of their lengths, a formula covered in full in the Dot Product article later in this phase — with the “angle” language serving as an intuitive description of a purely numerical result, not an actual geometric measurement being performed by anything resembling a person’s eye.

Reading the actual numbers

It’s worth knowing the practical range and what specific values mean in real use, since cosine similarity scores show up directly in vector database results. A score of 1.0 means the two vectors point in exactly the same direction (often, though not always, meaning nearly identical or paraphrased meaning). A score of 0.0 means the vectors are unrelated in direction — no meaningful similarity. A score near -1.0 is genuinely rare in practice for most text embeddings, since it would mean nearly opposite meaning, and most real-world text pairs, even very different ones, tend to land somewhere in the middle rather than at the true mathematical extremes.

A concrete example, layered

For a simple beginner example: comparing the embeddings for “I love sunny weather” and “I enjoy warm, clear days” would likely produce a high cosine similarity, perhaps around 0.85-0.9, since both sentences point in a very similar semantic direction despite using almost entirely different words — echoing the hiking/trekking example from the Embedding article. For a production example: OpenAI’s documentation for its embedding models describes them as normalized to unit length, which means cosine similarity and the dot product produce equivalent rankings for these embeddings — and virtually every major vector database mentioned in the Vector Database article, Pinecone, Weaviate, and Milvus among them, offers cosine similarity as a selectable, standard similarity metric for indexing and querying stored embeddings.

Why it’s not always the automatic right choice

It’s worth being honest about a genuine limitation, not presenting cosine similarity as universally correct. Because it deliberately ignores vector length, cosine similarity throws away any information a model’s embeddings might encode in that length — for embedding models where magnitude genuinely does carry meaningful signal (some do use vector length to represent confidence or intensity), cosine similarity would discard that signal entirely. This is exactly why the next article, Euclidean Distance, which does account for magnitude, remains a genuinely useful alternative for certain kinds of vectors, rather than cosine similarity being a strict, universal replacement.

Calculate cosine similarity step by step

Let:

query A    = [1, 2]
document B = [2, 4]

First calculate the dot product:

A · B = (1 × 2) + (2 × 4) = 10

Then calculate both lengths:

||A|| = √(1² + 2²) = √5
||B|| = √(2² + 4²) = √20

Finally:

cosine(A, B) = 10 ÷ (√5 × √20)
             = 10 ÷ 10
             = 1

The vectors point in exactly the same direction even though B is twice as long.

Real embedding behavior: normalized OpenAI vectors

OpenAI’s Embeddings FAQ states that its API embeddings are normalized to length 1. For unit-length vectors, cosine similarity can be computed using their dot product, and cosine similarity and Euclidean distance produce the same ranking.

That equivalence depends on normalization; it is not a universal rule for arbitrary vectors.

How cosine similarity relates to GPT and Gemini

Cosine similarity is commonly used to compare vectors produced by dedicated OpenAI or Gemini embedding models in retrieval, clustering, and duplicate detection.

flowchart LR
    A[Query] --> B[Embedding model]
    C[Document] --> B
    B --> D[Query vector]
    B --> E[Document vector]
    D --> F[Cosine similarity]
    E --> F
    F --> G[Ranking score]

Inside Transformer attention, GPT and Gemini-style architectures primarily use scaled dot products between query and key vectors. That internal attention calculation is related vector math but is not the same application as cosine-ranking stored documents.

Common misconception

A frequent beginner assumption: that “similarity” and “distance” are the same measurement, just phrased differently. They’re related but distinct — a similarity score (like cosine similarity) is typically higher when things are more alike, while a distance measure (like the Euclidean distance covered next) is typically lower when things are more alike. Mixing up which direction “better” points in, when reading raw scores from a vector database’s search results, is a genuinely common source of confusion worth watching for.

Where this fits in what comes next

You now understand the most widely used similarity metric for comparing embeddings. The next article, Euclidean Distance, covers a different, magnitude-sensitive way of measuring closeness between two vectors — useful in different situations from the ones cosine similarity handles best.

In one sentence

Cosine similarity measures the angle between two vectors, deliberately ignoring their length, which makes it especially well-suited to comparing embeddings where direction — not magnitude — is what actually carries semantic meaning.

Author
TechByteByByte Editorial Team
Reviewed by
TechByteByByte Admin
Published
Last reviewed