Which distance function should you choose, and when?

Which distance function to choose depends mainly on whether a vector‘s raw magnitude carries meaningful information or is essentially incidental, and secondarily on whether the underlying data is naturally continuous, binary, or set-based — get this choice wrong and no amount of parameter tuning elsewhere in an HNSW index will fully make up for measuring the wrong notion of “close” in the first place.

When does Euclidean distance make the most sense?

Euclidean distance, covered in this site’s vector-and-distance-math glossary section, measures straight-line distance and treats every dimension’s raw scale as meaningful. It’s the natural choice whenever a vector’s magnitude genuinely reflects something real about the underlying data — physical coordinates, sensor measurements, or any representation where the actual numeric scale of each dimension carries information that shouldn’t be normalized away. It’s a poor choice, however, for embeddings from models where only direction, not magnitude, was optimized to carry meaning, since Euclidean distance would then be penalizing differences in a quantity — vector length — that the embedding model never intended to be meaningful in the first place.

When should cosine similarity or normalized inner product be used instead?

Cosine similarity measures the angle between two vectors while ignoring their length entirely, which makes it the right choice whenever an embedding model was trained so that direction, not magnitude, encodes similarity — the common case for text and many other learned embeddings, where two vectors pointing in nearly the same direction represent similar content even if their raw lengths differ for reasons unrelated to meaning, such as differing input length. As covered in this site’s page on measuring distance and similarity between vectors, normalizing every vector to unit length once and then using inner product afterward produces identical rankings to cosine similarity while being cheaper to compute repeatedly, which is why many systems normalize vectors upfront rather than computing a full cosine similarity calculation on every single comparison.

When does raw inner product outperform cosine similarity?

Maximum inner-product search deliberately keeps magnitude in play, which is the right choice whenever a system wants both direction and scale to influence the final ranking — recommendation systems are the clearest example, discussed in depth in this site’s page on how HNSW is used inside recommendation systems, where an item’s embedding length might meaningfully reflect its overall popularity or the model’s confidence in that representation, information cosine similarity would discard by normalizing it away. Choosing inner product over cosine similarity is really a modeling decision as much as a distance-function decision: it only makes sense when whatever produced the vectors was actually trained with the expectation that magnitude would matter at query time.

What about data that isn’t naturally continuous, like binary or set-based data?

Binary vectors — each dimension holding only a 0 or a 1, as produced by some compression schemes covered in this site’s compression-and-quantization section — are typically compared using Hamming distance, which simply counts how many positions differ between two binary vectors rather than measuring a continuous geometric distance that wouldn’t meaningfully apply to purely binary data. Set-based data, where each item is represented as a collection of discrete elements rather than a fixed-length numeric vector, is more naturally compared using Jaccard similarity, which measures the overlap between two sets relative to their combined size rather than anything resembling geometric distance at all. Reaching for one of the continuous distance functions covered above on data that’s fundamentally binary or set-based tends to produce a technically computable but conceptually meaningless number, since those functions were built around assumptions — continuous values spread across real-valued dimensions — that simply don’t hold for this kind of data.

Choosing the right distance function is a modeling decision made once, upstream of any HNSW parameter tuning, and getting it right is a precondition for everything else this site covers to actually work as intended. The next appendix turns from choosing a distance function to a related practical concern: what a complete, trustworthy benchmark record needs to capture once that choice, and every other configuration decision, has actually been made.