Match your distance metric to the metric your embedding model was trained with. That single rule resolves most of the cosine-versus-dot-product-versus-Euclidean debate before any math starts. And here is the part most explainers bury: if your vectors are normalized to unit length, cosine similarity, dot product, and a monotonic version of Euclidean distance all rank results the same way, so for normalized embeddings the choice is often cosmetic. The danger is not the debate. It is the silent bug when vectors are not normalized and the metric in your index disagrees with the one the model learned on. The wrong metric does not crash. It quietly returns plausible-looking wrong answers that nobody notices.
Several popular text embedding models, including OpenAI's, return vectors already normalized to length 1. In that case cosine, dot product, and Euclidean ranking all agree, and people argue over a difference that does not change a single search result. Plenty of other models do not normalize by default, so confirm rather than assume.
The 30-second decision table
Read this table top to bottom and stop at the first row that matches your situation. The rows are ordered by how often they apply in practice.
- Your model documents a metric (cosine, dot, or Euclidean): use exactly that. Stop here. This overrides every other consideration.
- Your vectors are L2-normalized (unit length) and the model is silent: cosine and dot product are identical, so use whichever your database makes fastest. Often that is dot product.
- Vectors are not normalized and magnitude carries meaning you want to keep (popularity, frequency, confidence): use dot product.
- Vectors are not normalized and you want to ignore magnitude and compare only direction or topic: use cosine.
- You are clustering raw feature vectors, image pixel intensities, or coordinates where absolute position matters: use Euclidean.
The single most common silent accuracy bug: building an index with one metric while the model was trained for another. A cosine-trained model queried with a raw dot product on unnormalized vectors can return subtly wrong neighbors that still look plausible, so nobody notices.
Cosine vs dot product vs Euclidean: what each measures
Cosine similarity measures the angle between two vectors and ignores their length. Dot product measures both the angle and the lengths combined into one number. Euclidean distance measures the straight-line gap between the two points the vectors end at. Direction, direction-plus-magnitude, and position: that is the whole distinction.
Cosine similarity: angle only
Two vectors pointing the same way score 1, perpendicular vectors score 0, opposite vectors score -1. Lengthening either vector changes nothing because the angle stays fixed. This is why cosine dominates text search. A long document and a short query about the same topic point in nearly the same direction even though one vector is far longer, and cosine treats them as close. You usually do not want a document ranked higher just because it has more words.
Dot product: angle and magnitude together
Dot product folds angle and magnitude into one score: longer vectors that also point the same way score higher. That makes magnitude part of the ranking. When length encodes something real, like an item's popularity or a model's confidence, dot product carries that signal into the result. When length is noise, dot product lets that noise distort the ranking. The behavior depends entirely on what your magnitudes mean.
Euclidean distance: position in space
Euclidean is the ruler distance between two points. Smaller means closer. It cares about absolute location, so two vectors can point in the same direction yet sit far apart if one is much longer. Euclidean is the natural choice for clustering algorithms like k-means and for feature spaces where the raw coordinate values are the meaningful quantity, such as some image or geometric embeddings.
The trick that collapses the choice: normalize
When every vector is normalized to unit length, the three metrics stop disagreeing. Cosine similarity and dot product become mathematically equivalent, because the dot product of two unit vectors is exactly the cosine of the angle between them. Euclidean distance on unit vectors reduces to the square root of (2 minus 2 times cosine similarity), which is a monotonic function of cosine. Monotonic means it preserves order: as cosine goes up, that Euclidean distance goes down, with no crossovers. So ranking by any of the three returns the same neighbors in the same order.
This is the insight most comparison pages bury. If your embeddings arrive normalized, the metric argument is settled: pick whichever your database computes fastest, usually dot product, and you lose no accuracy. The decision only carries weight when magnitudes vary and you have not normalized.
Want cosine behavior but your database only offers dot product, or wants speed? Normalize your vectors once at write time, then use dot product. The result is identical to cosine and skips the per-query division. Many teams do exactly this.
The rule that prevents the silent bug: match the model
Choose the similarity metric your embedding model was trained with. Vendor guidance from Pinecone states this directly: matching the index metric to the training metric gives the most accurate results. A model learns to place related items close together under one specific notion of distance. Score it with a different notion and you measure something the model never optimized for.
Concrete examples make this practical. The sentence-transformers model all-MiniLM-L6-v2 was trained with cosine similarity, so a cosine index gives its best results. Models with a dot suffix, like msmarco-bert-base-dot-v5, were tuned for dot product and should be scored that way. The metric is not a free preference. It is a property the model already committed to during training, and most model cards name it.
In many vector databases the metric is fixed when the index is created and cannot be changed afterward. Picking wrong means a full re-index. Read your model card for its training metric before you create the index, not after.
Conventions by task (rules of thumb, not laws)
These are common defaults, not requirements. Your model card always wins over any convention listed here. Treat them as a starting guess when documentation is missing.
- Text embeddings, semantic search, document retrieval: cosine similarity is the usual default, because topic should outweigh length.
- Recommendation systems: cosine or dot product, depending on whether you want item popularity (magnitude) to influence ranking.
- Transformer attention: dot product, scaled by the square root of the dimension, is the standard inside the attention mechanism itself.
- Image embeddings and raw feature clustering: Euclidean distance often fits, especially for k-means and pixel-intensity spaces where absolute values matter.
- Any model whose name or card specifies a metric: use that metric and ignore the convention.
Scaled dot-product attention is the clearest fixed convention: the formula computes query-key dot products, divides by the square root of the key dimension to keep the softmax stable, then weights the values. The dot product there is structural, not a tunable choice.
| Property | Cosine similarity | Dot product |
|---|---|---|
| Measures | Angle between vectors only | Angle and magnitude combined |
| Sensitive to vector length | No, length is ignored | Yes, longer vectors score higher |
| On unit-length vectors | Identical ranking to dot product | Identical ranking to cosine |
| Typical use | Text search, semantic retrieval | Recommendations, attention, magnitude-aware ranking |
| Compute cost per pair | Slightly higher (a division) | Lower (just the product sum) |
A practical workflow
- Open your embedding model's card or docs and find its training or recommended metric. Use that. This is the answer most of the time.
- If no metric is documented, check whether the model returns normalized vectors. If yes, cosine and dot product are interchangeable; pick the faster one.
- If vectors are not normalized, decide whether magnitude carries meaning you want in the ranking. Yes means dot product, no means cosine (or normalize first, then dot product).
- Reserve Euclidean for clustering and feature spaces where absolute position is the signal.
- Confirm the metric in your vector index matches the one you chose, since many indexes lock it at creation time.
Where this shows up in a memory app
Any system that searches your own content by meaning relies on one of these metrics under the surface. MemX is a consumer AI memory app that builds an external memory layer over your own documents, photos, notes, and chats across Android, iOS, and WhatsApp. When you ask it to recall something, it compares the embedding of your question against the embeddings of your stored items, and the metric choice is exactly what decides which memories surface first. MemX is private by architecture, with per-user keys, encryption at rest, and an on-device first pass, so the matching happens against your own data rather than a shared pool.
Pick the metric the model was trained on, normalize when you want cosine behavior cheaply, and remember that for unit vectors the whole debate evaporates.
01Is cosine similarity the same as dot product?
Only for vectors normalized to unit length. There the dot product equals the cosine of the angle, so both rank results identically. For vectors of differing lengths they differ, because dot product factors in magnitude while cosine ignores it entirely.
02Which distance metric should I use for text embeddings?
Cosine similarity is the common default for text search, since it compares topic and ignores document length. But always check your model card first: if it names a metric like dot product, use that one instead of the convention.
03Do cosine, dot product, and Euclidean give the same search results?
For normalized vectors, yes. Cosine and dot product are equal, and Euclidean distance becomes a monotonic function of cosine, so all three return the same neighbors in the same order. For unnormalized vectors, they can rank results differently.
04When should I use Euclidean distance instead of cosine?
Use Euclidean for clustering with algorithms like k-means, and for feature spaces where the absolute coordinate values matter, such as some image or geometric embeddings. Cosine fits better when only direction or topic matters and magnitude is noise.
05Why does the metric have to match the embedding model?
A model learns to place related items close together under one specific distance. Scoring with a different metric measures something it never optimized for, producing subtly wrong neighbors. Vendors like Pinecone advise matching the index metric to the model's training metric for accuracy.
