Dot Product vs Cosine Similarity

What this is

Cosine likeness asks "what angle apart are these two vectors" and ignores length fully. Dot product asks "how much do these two vectors agree, weighted by how long they both are" — length is part of the answer, not discarded. Most embedding search defaults to cosine, but a growing number of models (some recommendation embeddings, some matryoshka and MIPS-optimised models) are trained. That way, dot product is the correct likeness, and using cosine on them silently under-uses the model. In embedding spaces, cosine likeness is the standard retrieval metric because documents of different lengths give vectors of different sizes. And you want a long document about cats to match a short query about cats. The dot product would rank the long document higher simply because its vector is longer, not because it is more apt. But in attention methods inside transformers, the dot product is used on purpose. The size of a key vector encodes how strongly that token wants to be attended to, and normalising it away would lose that signal. Scaled dot-product attention divides by the square root of the dimension to keep the values in a range where softmax gives useful gradients. But it does not normalise the vectors themselves. The two measures agree on direction and disagree on scale. If both vectors are unit-length, cosine likeness and the dot product return exactly the same number. This page computes both measures on pairs of vectors, shows how size affects each one, and covers when to use which in practice.

The formulas

dot(a,b) = Σ aᵢbᵢ     cos(a,b) = dot(a,b) / (‖a‖ ‖b‖)

Cosine is the dot product after dividing out both vectors' lengths —. This is exactly why stretching one vector along its own direction changes its dot product with anything but never changes its cosine with anything.

The same formula, one difference

dot product = a · b = Σ aᵢbᵢ

cosine likeness = (a · b) / (‖a‖ ‖b‖)

Cosine likeness is the dot product divided by both lengths. That division is the whole difference, and it removes size from the check, leaving only direction.

Worked through. Take a = [3, 4] and two candidates:

• b = [6, 8] — the same direction, twice as long.
• c = [4, 3] — a different direction, the same length.

By dot product, b scores twice as high as c. By cosine, b is a perfect match (the same direction) and c is very close. The two measures rank them the same way here, and for different reasons. And they will disagree when lengths vary much.

When size is noise, and when it is signal

Use cosine when length carries no meaning. Text embeddings are the standard case. A 4,000-word article and a 200-word summary of it should be close. And their vector lengths differ mainly because of length and count, not content.

Use the dot product when length carries meaning. Some recommendation systems on purpose encode fame or confidence as vector size. So that a popular item scores higher for an equally-good direction match. Discarding the length would discard that data.

That fourth row is the one people miss. If the embedding model was trained with an inner-product objective, its geometry is arranged for the dot product, and using cosine may not be what it was optimised for. Model documentation often states which to use, and following it matters more than the general argument.

The identity that makes this a non-issue in practice

On vectors normalised to length 1, the two measures are the same. The denominator of cosine likeness becomes 1 × 1.

That is why almost each embedding pipeline normalises on the way in. Then uses plain dot products. You get cosine semantics with the cost of a dot product. And a dot product over a matrix is a single fast matrix product.

There is a second identity worth knowing. On normalised vectors:

‖a − b‖² = 2 − 2(a · b)

So squared Euclidean distance is a dropping function of the dot product. This means ranking by cosine likeness and ranking by Euclidean distance give exactly the same order on normalised vectors. The choice of metric in a vector database is then a question of implementation rather than of results.

import numpy as np

vecs = model.encode(chunks, normalize_embeddings=True)   # normalise once
q = model.encode([question], normalize_embeddings=True)[0]

scores = vecs @ q          # dot product == cosine, because both are unit length
top = np.argsort(-scores)[:5]

The one difference, and when it bites

Cosine likeness is the dot product with the lengths divided out. So the two agree exactly when vectors are normalised and disagree in a specific, predictable way when they are not. This shows which retrieval bugs come from that gap.

import numpy as np

q = np.array([1.0, 1.0, 0.0])
docs = {
    "same direction, short": np.array([1.0, 1.0, 0.0]),
    "same direction, LONG":  np.array([5.0, 5.0, 0.0]),
    "45 deg off, long":      np.array([4.0, 0.0, 0.0]),
    "orthogonal":            np.array([0.0, 0.0, 3.0]),
    "opposite":              np.array([-1.0, -1.0, 0.0]),
}

def cos(a, b):
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

print("QUERY VECTOR: %s   (length %.4f)" % (str(q), np.linalg.norm(q)))
print()
print("%-26s %10s %10s %12s %12s"
      % ("document vector", "length", "dot", "cosine", "angle"))
for name, d in docs.items():
    c = cos(q, d)
    print("%-26s %10.4f %10.4f %12.4f %11.1f deg"
          % (name, np.linalg.norm(d), float(q @ d), c,
             np.degrees(np.arccos(np.clip(c, -1, 1)))))
print()
print("READ THE FIRST TWO ROWS. they point in the SAME DIRECTION -- the")
print("angle between them is 0 -- and the dot product ranks the long one")
print("%.0fx higher. cosine gives them the identical score of %.4f,"
      % (float(q @ docs["same direction, LONG"]) / float(q @ docs["same direction, short"]),
         cos(q, docs["same direction, LONG"])))
print("because it divides the length out.")
print()
print("AND THE THIRD ROW IS THE ONE THAT MATTERS. it is 45 degrees off --")
print("genuinely less relevant -- but it is long, so the dot product")
print("scores it %.4f against the short exact match's %.4f. by dot"
      % (float(q @ docs["45 deg off, long"]),
         float(q @ docs["same direction, short"])))
print("product the WRONG DOCUMENT WINS. by cosine, %.4f against %.4f,"
      % (cos(q, docs["45 deg off, long"]), cos(q, docs["same direction, short"])))
print("and the right one wins.")

That is not a coincidence — it falls straight out of the algebra relating the two. This the next block states right.

print("THE ALGEBRA, so this is not a coincidence:")
print("      dot(a, b)    = |a| |b| cos(theta)")
print("      cosine(a, b) = dot(a, b) / (|a| |b|) = cos(theta)")
print("   cosine is the dot product with the magnitudes cancelled, so it")
print("   depends on DIRECTION ONLY. the dot product mixes direction and")
print("   magnitude into one number, and once mixed you cannot tell which")
print("   contributed what.")

That algebra has a practical result: once each vector is normalised to unit length, dot product and cosine become the same number.

import numpy as np

q = np.array([1.0, 1.0, 0.0])
docs = {
    "same direction, short": np.array([1.0, 1.0, 0.0]),
    "same direction, LONG":  np.array([5.0, 5.0, 0.0]),
    "45 deg off, long":      np.array([4.0, 0.0, 0.0]),
    "orthogonal":            np.array([0.0, 0.0, 3.0]),
    "opposite":              np.array([-1.0, -1.0, 0.0]),
}
def cos(a, b):
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

print("SO IF EVERYTHING IS NORMALISED, THEY ARE THE SAME OPERATION:")
qn = q / np.linalg.norm(q)
print("%-26s %14s %14s %12s" % ("document (normalised)", "dot", "cosine",
                                "difference"))
for name, d in docs.items():
    dn = d / np.linalg.norm(d)
    print("%-26s %14.6f %14.6f %12.1e"
          % (name, float(qn @ dn), cos(qn, dn), abs(float(qn @ dn) - cos(qn, dn))))
print("   identical to floating-point precision. that is why so much")
print("   retrieval code normalises once at index time and then uses the")
print("   dot product: same answer as cosine, no division per comparison,")
print("   and a dot product is a single fused matrix multiply on a GPU.")

Given that equivalence once normalised, the choice comes down to what a vector's length is meant to encode.

print("WHICH TO CHOOSE, and the honest answer is that it depends on what")
print("your vector's LENGTH means:")
print("%-34s %s" % ("if length means...", "then use"))
for k, v in (("nothing (a direction only)", "either -- normalise and dot"),
             ("confidence or signal strength", "dot product, deliberately"),
             ("document length", "cosine, or you rank by length"),
             ("you have no idea", "cosine -- the safe default")):
    print("%-34s %s" % (k, v))

Getting that choice wrong gives a real bug: the next block shows an embedding model whose vector length grows with text length.

import numpy as np

def cos(a, b):
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

print("A CONCRETE FAILURE, because this one appears in real systems. some")
print("embedding models produce longer vectors for longer text:")
short = np.array([0.6, 0.8, 0.0])                  # exactly on topic
long_off = np.array([0.5, 0.2, 0.84]) * 2.6        # partly on topic, long
query = np.array([0.6, 0.8, 0.0])
print("%-30s %10s %12s %12s" % ("", "length", "dot", "cosine"))
for name, v in (("a short, exact answer", short),
                ("a long, rambling page", long_off)):
    print("%-30s %10.4f %12.4f %12.4f"
          % (name, np.linalg.norm(v), float(query @ v), cos(query, v)))
print("   the dot product prefers %s."
      % ("the rambling page" if query @ long_off > query @ short
         else "the exact answer"))
print("   cosine prefers %s."
      % ("the rambling page" if cos(query, long_off) > cos(query, short)
         else "the exact answer"))
print("   if your index was built with the dot product and your embedding")
print("   model does not normalise its output, your retriever has a")
print("   systematic bias toward long documents, and it will not look")
print("   like a bug -- it will look like the model preferring detailed")
print("   pages. check whether your vectors are unit length before you")
print("   conclude anything about your embeddings:")
for name, v in (("query", query), ("short", short), ("long", long_off)):
    n = np.linalg.norm(v)
    print("      |%s| = %.4f  %s"
          % (name, n, "unit" if abs(n - 1) < 1e-6 else "NOT UNIT"))

Finally, it is worth separating cosine likeness from cosine distance, and checking how both relate to euclidean distance on unit vectors.

import numpy as np

q = np.array([1.0, 1.0, 0.0])
qn = q / np.linalg.norm(q)
def cos(a, b):
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

print("ONE LAST DISTINCTION people conflate: cosine SIMILARITY versus")
print("cosine DISTANCE, and versus euclidean distance on unit vectors.")
print("%-26s %14s %14s %16s"
      % ("pair", "cos sim", "cos dist", "euclidean"))
pairs = [("identical", qn, qn),
         ("45 degrees apart", qn, np.array([1.0, 0, 0])),
         ("orthogonal", qn, np.array([0.0, 0, 1.0])),
         ("opposite", qn, -qn)]
for name, a, b in pairs:
    b = b / np.linalg.norm(b)
    c = cos(a, b)
    print("%-26s %14.4f %14.4f %16.4f"
          % (name, c, (1 - c) + 0.0, float(np.linalg.norm(a - b))))
print("   cosine distance is 1 - similarity, so it runs 0 to 2 and is NOT")
print("   a metric you can hand to a k-d tree.")
print("   but look at the last column against the first: on UNIT vectors,")
print("   euclidean^2 = 2 - 2*cos, so ranking by euclidean distance and")
print("   ranking by cosine give the identical order. check it:")
for name, a, b in pairs:
    b = b / np.linalg.norm(b)
    print("      %-22s 2 - 2cos = %6.4f,  euclid^2 = %6.4f"
          % (name, (2 - 2 * cos(a, b)) + 0.0,
             float(np.linalg.norm(a - b) ** 2)))
print("   that identity is why a vector database can offer 'cosine' as an")
print("   option on an index that only really implements L2: for")
print("   normalised vectors they are the same ranking, and it normalises")
print("   your vectors for you on the way in.")

Guided tour

1. Start at 1x with cosine ranking. Doc A, the concise on-topic passage, ranks first.
2. Stretch Doc B to 5x. Under cosine, nothing about the ranking moves — Doc B's direction. And so its angle to the query, never changed.
3. Switch to dot product and stretch again. Somewhere around 3-4x, Doc B overtakes Doc A — purely. This is because it got longer, with its actual topical relevance unchanged.
4. Read both scores side by side at 5x. Cosine still ranks Doc A first; dot product now ranks Doc B first. Same embeddings, same query, opposite answer.

Which one is "right"?

Neither, in the abstract — it depends on what the embedding model was trained to make meaningful. If length in your model's embeddings correlates with noise (document verbosity, padding, repetition), cosine is safer. If length was trained to carry real signal (fame, confidence, specificity), dot product is the metric the model really optimised for, and cosine throws that signal away. Check your model's documentation; do not assume.

What to recall

Cosine likeness divides out vector length and only ever measures direction; dot product does not. So it rewards longer vectors whether or not that length means anything. The two metrics agree only when each vector has the same length — true if you normalise your embeddings to unit length, false if not. Know which one your embedding model was trained against, because using the wrong one is a silent, hard-to-debug retrieval quality bug.

Interpreting the numbers

Cosine likeness has a fixed range, which makes it thresholdable:

The dot product has no fixed range at all, which is a practical downside. A score of 42 means nothing without knowing the typical sizes in that space.

Two cautions about cosine thresholds:

Calibrate against your own data. Many sentence-embedding models score unrelated text at 0.2–0.4. So a threshold of 0.5 admits large noise. Score a few hundred known-related and known-unrelated pairs and put the cut where the distributions separate.

Negative values are rare in practice. Most modern embedding models place nearly all of it in a narrow cone of the space. So scores cluster in a band and true opposition is uncommon. Relative ranking remains reliable; absolute values are model-specific.

The zero-vector trap

Cosine likeness divides by the vector lengths, so a zero-length vector gives a division by zero.

That is not hypothetical. An empty document, a chunk that held only whitespace or markup, a user with no links. All give zero vectors, and the result is a nan that propagates silently through averages and rankings.

def cosine(a, b):
    denom = np.linalg.norm(a) * np.linalg.norm(b)
    return float(a @ b / denom) if denom else 0.0     # guard it

The dot product has no such problem, which is a minor point in its favour. The real fix is to filter empty content before indexing it.

Other measures, briefly

Euclidean distance is the one people reach for by habit from geometry. And it is often the wrong choice for unnormalised embeddings. A long vector is far from all of it. So document length rules the ranking. Normalise, and it becomes the same to cosine.

Questions people ask

Which should I use for RAG? Cosine — or the same way, normalise your vectors and use dot products.

Are they ever truly different in results? Only on unnormalised vectors. Normalised, they rank identically.

Why do some databases default to inner product? Because it is the cheapest step. And it is correct if you normalise on the way in. Check whether yours normalises for you.

Can cosine likeness be negative? In math yes, down to −1. With most text embedding models it is uncommon.

Does normalising lose data? It discards size. For text embeddings that is often noise; for models that encode confidence in the size, it is a loss.

What threshold should I use? Do not guess — measure it on labelled pairs from your own corpus. Model-to-model change is large.

Recap in one screen

• Cosine likeness is the dot product divided by both lengths. This removes size and keeps direction.
• Use cosine when length is noise (almost always, for text). Use the dot product when size encodes something real.
• On unit-length vectors the two are the same, and Euclidean distance ranks the same way.
• Normalise once at indexing time, then a fast matrix times gives you cosine scores.
• Guard against zero vectors, and calibrate thresholds against your own labelled pairs.