Cosine Similarity explained.

Why direction only

Because cosine depends only on direction, it is robust to magnitude: a short and a long vector in the same direction have cosine 1. That makes it ideal when length is irrelevant—e.g. many text embedding models produce vectors whose direction encodes meaning.

Discarding magnitude reduces sensitivity to embedding scale and batch effects: two documents with the same semantic content but different chunk lengths or model runs still get high cosine if their directions align. That stability is why cosine is the default for text and semantic retrieval in most vector databases and embedding benchmarks.

For normalized vectors (unit length), cosine similarity equals the dot product, which is fast to compute and is how many vector DBs implement cosine search internally. Practical tip: ensure both stored and query vectors are normalized the same way so that scores are comparable and thresholding is meaningful.

Using cosine as a distance

Cosine is a similarity (higher = more similar). To use it as a distance for nearest neighbor indexes, it’s often converted to angular distance or to 1 − cos(a, b) so that “closer” means smaller distance. Choosing cosine over Euclidean (L2) depends on whether magnitude matters in your embeddings.

Trade-off: cosine ignores magnitude, which is good for semantic text but can be wrong when vector length carries information (e.g. confidence or intensity). When in doubt for text embeddings, cosine is the default; for other modalities or mixed signals, compare L2 and cosine on a small eval set.

When defining a “good” match, use a threshold on cosine (e.g. > 0.7 or > 0.8) depending on your data and recall requirements. Thresholding and normalized vs. unnormalized distance scores affect how you interpret and tune these cutoffs; keep the metric fixed across ingestion and query so that thresholds remain comparable.

Pipeline and implementation

Typical pipeline: embed documents and queries with the same model; normalize all vectors to unit length before upserting and before each query. Create a collection with cosine (or dot product) as the distance metric. At search time, the index compares the query vector to stored vectors via dot product; returned scores are in [−1, 1], which makes thresholding and re-ranking straightforward.

Many embedding APIs return normalized vectors by default. If yours does not, normalize once at ingestion and once per query. Do not double-normalize (idempotent but redundant). For how cosine compares to other metrics in CPU cost and for faster execution, see computation overhead of different distance metrics and hardware acceleration (SIMD) for distance calculations.

Practical tip: when migrating from one embedding model to another, re-normalize and re-index; cosine scores are not comparable across models. If you use re-ranking after retrieval, cosine (or dot product) scores from the first stage are often fed into a cross-encoder or scorer for a second pass—see re-ranking for why that improves accuracy.