Similarity metrics
The math for 'how close are two vectors' - cosine similarity, dot product, Euclidean distance - and it matters less than you fear.
In plain terms
Given two points on the meaning-map, you can compare the angle between them (cosine), or the straight-line gap (Euclidean), or a mix (dot product). Like comparing cities by flight bearing vs. distance: different numbers, usually the same verdict on 'near or far'.
Why it matters
Every vector database asks you to pick a metric at index creation, and beginners freeze on the choice. Knowing the 10-minute version prevents both the freeze and subtle bugs.
How it works
Cosine compares direction only, ignoring vector length - the default for text. Dot product rewards direction and magnitude. Euclidean is straight-line distance. Crucial simplification: most modern embedding models output normalized vectors (length 1), where all three metrics rank results identically. So: use cosine, match your model's documentation, move on.
When you use it
Once, when creating each vector index - and when debugging a system where scores look bizarre (metric/model mismatch is a classic silent bug).
Common mistakes
- Using raw similarity scores as absolute quality ('0.8 = good match') across models - scales differ; scores are for ranking, thresholds must be tuned per model.
- Mixing normalized and unnormalized vectors with dot product.
- Agonizing over the metric while ignoring chunking, which matters 100x more.
Best practices
- Follow your embedding model's docs; they state the intended metric.
- Tune 'good enough' thresholds empirically on your own data.
Try it yourself
Take 5 sentence pairs, compute cosine and Euclidean rankings by hand with numpy - confirm the order matches even though numbers differ.
Resources
- Pinecone - Vector similarity explained Visual, short, settles the topic.