7 Vector Similarity Metrics: How They Work, Differ, and When to Use Them

AI search, RAG pipelines, and recommendation engines rely on distance metrics to define "similarity" in the embedding space. The metric you choose directly influences ranking results, latency, and infrastructure costs, so it must align with the loss function used to train the embedding model.

“The math behind it isn’t complex, but scaling it in production is. You need a metric that keeps latency under 100 ms at scale and infrastructure that won’t become a bottleneck for millions of vectors.” — Rini Vasan (Redis author)

What an Embedding Is

An embedding is simply a vector of floating‑point numbers representing a piece of data (query, product description, genome record, etc.). For example, OpenAI’s text-embedding-3-large produces a 3,072‑dimensional array, while BERT‑base yields 768 dimensions. Similarity search finds vectors that are "close" to a query point, where "closeness" depends entirely on the chosen metric.

Metric 1: Cosine Similarity

Cosine similarity measures the angle between two vectors, ignoring their magnitudes. It treats two vectors as similar if they point in the same direction, even if one is much longer. This property makes it the industry standard for NLP, semantic search, document clustering, and cross‑language embedding comparison. However, it discards length information, which can be a signal (e.g., a high‑frequency user vs. a low‑frequency user) and may hide product‑ranking defects.

Metric 2: Dot Product (Inner Product)

Dot product combines direction and magnitude: each pair of components is multiplied and summed. When vectors are L2‑normalized (length = 1), dot product rankings are mathematically identical to cosine similarity, but dot product avoids the normalization division, reducing compute cost. Production systems like Pinecone recommend normalizing embeddings at index time and using dot product at query time. The risk is that if embeddings are not normalized, dot product mixes direction and length, potentially lowering recall without raising errors.

Metric 3: Euclidean Distance (L2)

Euclidean distance is the straight‑line distance between two points. Both direction and magnitude affect the score, making it suitable when raw feature differences matter (e.g., a user who bought 100 items vs. one who bought 1). In very high‑dimensional spaces (> 1,000 dimensions) distance concentration can occur, causing "nearest" and "farthest" points to become indistinguishable—a limitation that should be flagged during technical reviews.

Metric 4: Manhattan Distance (L1)

Manhattan distance sums absolute per‑dimension differences, akin to navigating a city grid. Unlike Euclidean, it does not square differences, so outlier dimensions are not amplified, offering more robustness to noise or extreme values. On modern CPUs with AVX SIMD, Euclidean can sometimes be faster because squaring is a single multiplication, while absolute‑value computation may need conditional logic; therefore benchmark on target hardware.

Metric 5: Jaccard Similarity

Jaccard operates on sets, computing the ratio of intersected elements to the union. It is ideal for binary or sparse features such as shopping‑cart overlap, tag matching, or large‑scale near‑duplicate detection. It is unsuitable for dense floating‑point embeddings generated by Transformers, as the result would be meaningless.

Metric 6: Pearson Correlation

Pearson correlation is cosine similarity applied after mean‑centering each vector, removing absolute scale and baseline offsets. It is useful for comparing gene‑expression profiles, time‑series trends, or rating‑based collaborative filtering where users have different rating baselines. Most vector databases lack native Pearson support because per‑query mean‑centering is costly; a common production pattern is to pre‑center embeddings at index time and then use cosine similarity.

Metric 7: Hamming Distance

Hamming distance counts differing positions between equal‑length binary vectors. It can be computed with fast XOR operations, making it extremely efficient for binary‑quantized embeddings. Quantizing a 32‑bit float vector to 1‑bit reduces memory by ~32×. Production systems like FAISS and Qdrant often use a two‑stage approach: first retrieve candidates with binary quantization and Hamming distance, then re‑rank with cosine similarity for accuracy.

How to Choose the Right Metric

Use the metric that matches the embedding model’s training objective; all other factors come afterward.

If documentation is unclear, follow the decision tree (see image) to narrow down the appropriate metric based on whether the embeddings are already normalized, the training loss type, and the nature of the data (dense vs. sparse, binary vs. continuous).

Pre‑launch Validation Checklist

Choosing a metric is only the first step; you must validate it with real data and query patterns. Common pitfalls include skipping this verification.

Evaluation should cover three key indicators:

Recall@K – checks whether correct results appear in the top K.

Mean Reciprocal Rank (MRR) – measures how early the best result appears.

P99 latency – Redis engineers consider sub‑100 ms latency a production requirement.

If two metrics yield identical recall, prefer the one with lower computational cost.

Summary Checklist

Embeddings are pre‑normalized: use dot product for speed; results equal cosine similarity.

Cosine‑trained, non‑normalized embeddings: explicitly use cosine similarity or normalize at index time.

Dot‑product‑trained, non‑normalized embeddings: use dot product; magnitude carries signal.

If data is already normalized, cosine similarity and dot product become indistinguishable.

Metric selection is an ongoing product risk. Whenever the embedding model, its version, or the vector database changes, re‑verify that the chosen metric still matches the training loss and performance requirements.

Embedding providers differ: Cohere’s embeddings are unit‑normalized by default, making dot product and cosine identical; OpenAI recommends normalizing before indexing.