Embedding systems often compare vectors with cosine similarity or a dot product. The formulas look similar enough that it is easy to treat the two metrics as interchangeable. They are not interchangeable for arbitrary vectors.
A dot product depends on both the angle between two vectors and their magnitudes. Cosine similarity removes magnitude and compares direction only. That difference can change nearest-neighbor rankings, retrieval results, and similarity thresholds.
This article builds a practical mental model for deciding whether to normalize embeddings. You will see why L2 normalization makes dot product equivalent to cosine similarity, how inconsistent normalization breaks comparisons, and when preserving vector magnitude may be intentional.
Start with a two-dimensional example
Suppose a query embedding is:
q = [1, 1]and two candidate embeddings are:
a = [1, 1]
b = [10, 0]Their dot products with the query are:
q · a = 1*1 + 1*1 = 2
q · b = 1*10 + 1*0 = 10By dot product, b wins by a large margin.
But direction tells a different story. Vector a points in exactly the same direction as q, while b points along one axis. Their cosine similarities are:
cos(q, a) = 1
cos(q, b) = 1 / sqrt(2) ≈ 0.707By cosine similarity, a is the closer match.
Neither calculation is wrong. They answer different questions. The dot product rewards b partly because b is much longer. Cosine similarity deliberately removes that effect.
Separate direction from magnitude
For vectors x and y, the dot product can be written as:
x · y = ||x|| ||y|| cos(theta)Here, ||x|| and ||y|| are the vectors’ Euclidean, or L2, norms, and theta is the angle between them.
This equation exposes the three factors that influence a raw dot product:
- the magnitude of
x; - the magnitude of
y; - how closely their directions align.
Cosine similarity divides out the magnitudes:
cosine_similarity(x, y) = (x · y) / (||x|| ||y||)As a result, multiplying one nonzero vector by a positive constant changes its magnitude but not its cosine similarity to another vector.
That property is useful when direction represents the semantic information you want to compare and magnitude should not affect ranking.
L2 normalization turns vectors into unit vectors
L2 normalization divides a nonzero vector by its norm:
normalize(x) = x / ||x||The normalized vector has norm 1. For example:
x = [3, 4]
||x|| = sqrt(3^2 + 4^2) = 5
normalize(x) = [0.6, 0.8]If both vectors are normalized, their dot product becomes:
normalize(x) · normalize(y)
= (x · y) / (||x|| ||y||)
= cosine_similarity(x, y)So for nonzero, L2-normalized vectors:
dot product = cosine similarityThis is an algebraic equivalence, not an approximation.
It has a useful engineering consequence. If your intended metric is cosine similarity, you can normalize vectors once and use an inner-product search implementation, provided the stored vectors and queries are normalized consistently.
Normalize both sides, not just the index
A common implementation mistake is to normalize document embeddings before storing them but forget to normalize query embeddings.
Suppose every stored vector d has unit norm. The score for an unnormalized query q is then:
q · d = ||q|| cos(theta)For a single query, ||q|| is the same positive factor for every candidate. Therefore, if all stored vectors are unit vectors, leaving that one query unnormalized does not change the ranking produced by dot product.
That does not make the score equal to cosine similarity. Its scale now depends on the query norm. A threshold such as score >= 0.8 can behave differently for queries with different magnitudes, and scores from separate queries are no longer directly on the cosine scale.
Normalizing both stored and query embeddings avoids this ambiguity:
indexing:
document -> embedding -> L2 normalize -> store
search:
query -> embedding -> L2 normalize -> compareConsistency matters more than memorizing a particular library setting. Different vector-search systems may expose cosine, inner product, or distance metrics with different names and score conventions. Check the system’s documented definition rather than assuming that a field called score has a universal meaning.
Normalization changes nearest-neighbor rankings
Normalization is not merely a numerical cleanup step. It changes the geometry of the search problem.
Consider a unit-length query and two candidates:
candidate A:
cosine similarity = 0.95
norm = 1
raw dot product = 0.95
candidate B:
cosine similarity = 0.80
norm = 2
raw dot product = 1.60Raw dot product ranks B first because its larger magnitude outweighs its weaker directional alignment. After L2 normalization, dot product ranks A first because only the cosine remains.
Before normalizing an existing retrieval system, therefore, measure the effect on retrieval quality. If vector magnitude carries useful information learned by the embedding model, removing it can discard signal.
Do not assume magnitude is meaningless
Whether magnitude matters depends on how an embedding model was trained and how its output is intended to be used.
Some systems are explicitly designed around cosine similarity or normalized embeddings. In that case, unit normalization matches the intended comparison geometry.
Other models or learned retrieval systems may use an inner-product objective where vector norms participate in the score. Normalizing those vectors after training changes the scoring function. It can alter rankings even though the directions remain unchanged.
The safe rule is not “normalize every embedding.” The safe rule is:
Match preprocessing and similarity computation to the model’s intended scoring method, then validate that choice on your retrieval task.
If model documentation specifies a similarity function or normalization step, treat that as part of the model interface rather than an optional optimization.
Handle zero and near-zero vectors deliberately
A zero vector has norm zero:
x = [0, 0, 0]
||x|| = 0Dividing it by its norm is undefined. Cosine similarity is also undefined because its denominator contains the vector norm.
Production code should define what happens before normalization. Depending on the application, sensible choices include rejecting the vector, logging it as an embedding failure, or applying a documented fallback outside the similarity calculation.
Adding a small epsilon to the denominator can prevent division-by-zero errors in numerical code, but it does not give a zero vector a meaningful direction. Treat numerical stability and semantic validity as separate concerns.
Very small norms deserve similar attention. They may indicate unusual model output, invalid preprocessing, or a representation with little useful signal. Inspect their frequency rather than silently assuming every generated vector is suitable for retrieval.
Keep normalization consistent across an index lifecycle
Changing normalization policy after an index has been populated can create a mixed vector space.
For example, suppose older documents were stored as raw embeddings and newer documents are stored as unit vectors. An inner-product search then compares candidates under two different scoring assumptions. Large-norm old vectors can receive an advantage that new normalized vectors cannot reproduce.
Treat normalization policy as index metadata. When changing it:
- choose the intended metric explicitly;
- apply the same embedding model and preprocessing policy to all comparable documents;
- rebuild or migrate vectors that use the old policy;
- normalize queries according to the same scoring design;
- recompute similarity thresholds on representative validation data.
Threshold recalibration matters because normalization changes score scale. A threshold tuned for raw dot products cannot be assumed to mean the same thing after scores become cosine similarities.
Validate retrieval instead of trusting geometric intuition alone
The equations tell you what normalization changes, but they do not tell you which geometry works better for your application.
Build a small evaluation set containing queries and examples of relevant documents. Compare candidate configurations with a retrieval metric that matches your use case, such as recall at a fixed number of retrieved items. Also inspect important failure cases manually.
A useful comparison is:
configuration A: model-recommended raw dot product
configuration B: L2-normalized vectors + dot productIf the model already produces normalized vectors, the two configurations may be identical in practice. If norms vary, the comparison reveals whether magnitude helps or hurts your task.
Also measure operational effects. Normalizing embeddings requires a small amount of computation, usually once per stored vector and once per query. In most embedding pipelines that cost is minor compared with model inference, but actual latency and throughput should be measured in the system that matters to you.
Common mistakes
Normalizing only because cosine similarity sounds safer
Cosine similarity is not inherently more accurate. It is appropriate when magnitude should not affect similarity. If magnitude is part of the learned scoring function, normalization changes the model’s behavior.
Mixing raw and normalized embeddings
A single index should not silently contain vectors produced under incompatible scoring policies. Record the embedding model, model version where relevant, dimensionality, and normalization policy with the index configuration.
Reusing thresholds after changing the metric
A raw inner-product score and a cosine similarity have different interpretations and often different ranges. Re-evaluate thresholds after changing normalization or similarity functions.
Assuming every vector database defines scores identically
A system may return similarity, distance, negative distance, or another transformed score. Use the documented metric semantics before comparing scores or setting thresholds.
Ignoring embedding-model changes
Even if two model versions have the same vector dimension, their embedding spaces are not automatically compatible. Normalization cannot make embeddings from unrelated spaces comparable. Re-embedding the corpus is usually necessary when a model change creates a new representation space.
When normalization is a good fit
L2 normalization is a strong fit when your intended similarity is cosine similarity, when the embedding model recommends normalized representations, or when you deliberately want direction to determine ranking independently of vector magnitude.
Keeping raw vectors is appropriate when the model’s intended scoring function uses inner product and vector norms carry useful learned signal. It is also reasonable when an API or retrieval model explicitly specifies raw dot-product scoring.
If the intended behavior is unclear, do not decide from formula aesthetics. Test both approaches on representative relevance judgments and inspect how rankings change.
Conclusion
Dot product combines directional alignment with vector magnitude. Cosine similarity removes magnitude. L2 normalization connects the two: once both nonzero vectors have unit norm, their dot product is exactly their cosine similarity.
That equivalence makes normalization useful, but not universally correct. Choose the geometry your embedding model and application actually require, apply it consistently to stored vectors and queries, handle invalid vectors deliberately, and retune evaluation thresholds whenever the scoring policy changes. In vector search, normalization is part of the meaning of the score—not just a preprocessing detail.