Cosine Similarity

Cosine similarity measures the similarity of two vectors as the cosine of the angle between them: cos(θ) = (A · B) / (||A|| × ||B||). The output is bounded in [-1, 1], where 1 means identical direction, 0 means orthogonal, and -1 means opposite direction. The defining property is that cosine similarity is invariant to vector magnitude — only direction matters — which matches how modern text embeddings behave: the semantic content is encoded in the direction of the embedding vector, not its length. Two embeddings of the same sentence at different times or from different mini-batches may have slightly different norms but nearly identical directions.

In the 2026 embedding landscape, cosine similarity is the default metric for nearly every text embedder (OpenAI text-embedding-3, Cohere embed-v3/v4, Voyage, BGE, GTE, Jina, E5, Nomic). Many production embedders go further and L2-normalise the output vectors at inference time, which makes cosine similarity mathematically equivalent to dot product — and dot product is faster to compute, so vector databases often index against it while users reason in cosine terms. This is why vector DB documentation sometimes says "we use dot product" and sometimes "we use cosine" — for normalised vectors they produce identical rankings, just different absolute scores.

For APAC mid-market teams building semantic search or RAG, **cosine similarity is the right default without experimentation** if you are using any modern embedder. Only reach for alternative metrics (Euclidean distance, Manhattan distance, learned Mahalanobis) when you have a specific, measured reason: the embedder's documentation recommends a different metric, or benchmark results on your corpus show a reproducible improvement, or you are working with non-text vectors (images, audio, graph) where normalisation doesn't hold the same way. For 99% of enterprise text-embedding workloads, cosine is already optimal.

The non-obvious failure mode is **mixing metrics silently**. An embedder was trained with cosine similarity as the contrastive objective, but the vector database is configured to search with Euclidean distance, or vice versa — and nobody notices because the results look approximately right but retrieval recall on hard queries is materially worse than it should be. The fix is to match the embedder's training metric in the index (read the model card or documentation), verify with a labelled eval set that recall@k matches published benchmarks, and keep the metric in metadata so a future maintainer can tell which similarity the vectors were produced for.