Cosine, dot product or Euclidean distance: choosing a similarity measure for keyword embeddings

Picking an embedding model is only half the job when it comes to similarity. The next question is how you're going to compare the vectors it produces.

Cosine similarity, dot product and Euclidean distance are the three usual choices. In some setups they give you nearly identical rankings. In others, they behave very differently.

For keyword clustering, that means the metric deserves to be treated as part of the model itself, not as a harmless implementation detail you can pick without thinking.

Cosine similarity compares direction

Cosine similarity measures the angle between two vectors. It's high when they point in similar directions, regardless of how long each vector is.

That's attractive for sentence embeddings, because the direction of the vector usually carries the semantic signal we actually care about.

Our guide to cosine similarity for keyword clustering explains why the score still shouldn't be read as a probability of shared intent.

Dot product includes magnitude

The dot product goes up both when vectors are aligned and when their magnitudes are larger.

If every vector is L2-normalised to unit length, dot product and cosine similarity become equivalent. Sentence Transformers documents this relationship directly.

If the vectors aren't normalised, magnitude can shift the ranking. Whether that's a good or bad thing depends on how the embedding model was trained and what vector length actually represents in that model.

Euclidean distance measures straight-line separation

Euclidean distance simply asks how far apart two points sit in vector space.

For unit-normalised vectors, Euclidean distance and cosine similarity move together, so the nearest neighbours can end up very similar either way.

Without normalisation, though, Euclidean distance becomes sensitive to vector magnitude and can produce a noticeably different neighbourhood structure.

Normalisation is the hidden decision

Teams often compare similarity metrics without first checking whether the vectors were normalised.

That can make the whole comparison misleading.

Worth recording:

• whether embeddings are normalised;
• which norm is used;
• whether the model documentation recommends a specific similarity function;
• whether the vector database applies normalisation automatically.

A metric name on its own, without those details, doesn't tell you much.

The ranking matters more than the raw score

For neighbour retrieval, the practical question is usually:

Which other keywords come out as the closest neighbours?

Two metrics can produce scores on totally different scales while still returning nearly the same top ten neighbours.

That's why evaluation should focus on:

• neighbour recall on labelled pairs;
• the rank order of important neighbours;
• the resulting cluster structure downstream;
• the boundary cases where metrics actually disagree.

Don't compare the raw number 0.82 from one metric with 0.82 from another as though they mean the same thing, because they usually don't.

Metric choice can alter graph density

If a graph is built by applying a fixed threshold, switching the similarity measure changes which edges survive that threshold.

This matters especially when moving between cosine similarity and Euclidean distance, because one is a similarity and the other is a distance. A larger cosine value means closer together. A smaller Euclidean value means the same thing.

Your threshold logic needs to reflect that direction correctly, or you'll get the opposite of what you intended.

Vector databases may constrain the choice for you

Similarity-search systems such as Faiss support several index and metric options, and some vector databases are heavily optimised around cosine, inner product or L2 distance specifically.

Operational constraints can therefore end up driving the metric choice. That's fine, as long as the decision is documented and tested against the actual SEO task.

Don't choose a metric based on one attractive example

A pair like "cheap running trainers" and "affordable running shoes" is easy for almost any decent semantic model to get right.

The useful tests are the harder ones:

• same entity, different task;
• same task, different entity;
• short ambiguous queries;
• important modifiers;
• technical identifiers;
• near-synonyms that actually need different pages.

Those cases show you whether the metric and representation preserve the distinctions you actually care about.

A practical comparison experiment

1. Embed one fixed judgement set.
2. Evaluate cosine, dot product and Euclidean distance on the same vectors.
3. Normalise and repeat.
4. Compare the nearest-neighbour rankings.
5. Build small graphs or clusters under each configuration.
6. Check where assignments change.
7. Pick the configuration that best supports the downstream task.

Practitioner principle: a similarity metric isn't a cosmetic setting. It decides which relationships the clustering system even gets to see.

ClusterIQ Conclusion

Cosine similarity, dot product and Euclidean distance can behave the same way once vectors are normalised, but you should never simply assume that's the case.

Metric choice, vector normalisation and threshold logic all belong in the same configuration record. Test the neighbour relationships that matter to you, and judge the result on downstream usefulness rather than on how familiar the formula looks.

Worked example: where the rankings can diverge

Picture three query embeddings where two vectors point in a very similar direction but one has a much larger magnitude. Cosine similarity can rank them as almost equivalent, since it only cares about direction. Raw dot product can favour the larger vector instead. Euclidean distance can shift again depending on how magnitude affects the straight-line separation.

That difference matters in practice once the top neighbours get used to build graph edges. If one metric keeps promoting broad, generic queries because of magnitude effects, those terms can turn into hubs and drag otherwise separate topics together.

How we'd choose the metric in practice

Start with a small labelled set and compare the neighbour lists themselves, not just average scores. Pay close attention to queries where a single modifier changes the commercial meaning. Once the neighbour behaviour looks sensible, lock in the metric and normalisation rule as part of the run configuration, so later threshold tests stay comparable.

Sources and further reading

• Sentence Transformers: similarity functions
• Scikit-learn: pairwise metrics
• Faiss documentation
• ClusterIQ: Choosing a similarity threshold