Short answer: They are common ways to score how close two vectors are once candidates are compared.
Cosine focuses on angle, Euclidean on straight-line distance, and dot product on magnitude-aware alignment. The metric you choose changes which neighbors rank highest, so it must match how your embeddings were trained.
HNSW explained how a search navigates toward a small set of promising candidates without checking everything. What it didn’t specify is exactly how “close” gets measured once the search has narrowed down to comparing a query against those candidates directly. That measurement is a distance metric, and while several exist, three specific ones, cosine, dot product, and Euclidean, come up constantly enough to deserve a clear, direct comparison.
What Does Cosine Similarity Actually Measure, and Why Does That Make It Useful for Text?
Cosine similarity measures the angle between two vectors, entirely ignoring how long each vector happens to be. Two vectors pointing in nearly the same direction score as highly similar even if one is much longer than the other, because only the angle between them matters, not their individual magnitudes. This property turns out to be exactly what’s needed for comparing text: a short sentence and a long passage discussing the identical topic can still point in very similar directions in the vector space, even though the underlying embeddings might differ in overall magnitude simply due to length. Cosine similarity correctly recognizes these as similar in meaning, since it was never looking at magnitude to begin with.
How Does Dot Product Differ From Cosine Similarity if Both Involve Angles?
Dot product incorporates both the angle between two vectors and their magnitudes together in a single calculation, whereas cosine similarity deliberately strips magnitude out and considers only the angle. This means dot product and cosine similarity can actually produce identical rankings under one specific, common condition: when every vector has already been normalized to the same length. Once magnitude has been standardized away for every vector in a comparison, whatever differences dot product would have picked up due to length simply no longer exist, leaving angle as the only thing left to distinguish one comparison from another, which is exactly what cosine similarity was measuring the whole time.
This is precisely why some systems, including Weaviate’s own cosine implementation, normalize vectors to a standard length before actually computing distance, using the computationally cheaper dot product internally to arrive at what is, in that specific case, mathematically the same answer cosine similarity would have given directly.
What Does Euclidean Distance Measure That’s Genuinely Different From the Other Two?
Euclidean distance measures the straight-line distance between two points in the vector space, the way a ruler would measure distance between two dots on a page, rather than measuring an angle at all. This means Euclidean distance is sensitive to both direction and magnitude in a way cosine similarity specifically isn’t, two vectors pointing in a similar direction but differing substantially in length can register as quite far apart under Euclidean distance, even in a case where cosine similarity would have judged them as nearly identical in meaning.
Whether this sensitivity to magnitude is a feature or a problem depends entirely on what a specific embedding model was actually trained to represent. If a model’s magnitude genuinely carries meaningful information, Euclidean distance correctly uses that signal. If a model’s magnitude is largely incidental, an artifact of how long the input text happened to be rather than a meaningful signal, Euclidean distance risks being misled by exactly the kind of variation cosine similarity was specifically designed to ignore.
How Should Someone Actually Decide Which Metric to Use for a Given System?
The single most reliable rule is to match whichever distance metric the specific embedding model was actually trained against, since a model learns its geometry under one particular notion of “close,” and comparing its output vectors using a different metric than the one it was trained with risks measuring something the model was never actually optimized to represent correctly. Most modern text-embedding models are trained with cosine similarity in mind, which is why cosine tends to be the sensible default for text-based semantic search specifically, but this isn’t a universal law, some models are trained differently, and the model provider’s own documentation is the authoritative source for which metric that specific model actually expects.
How Does Weaviate Engram Handle Distance Metric Selection So Users Don’t Have to Manage It Directly?
Weaviate Engram’s memory search abstracts this decision away entirely, using the distance metric appropriate for its underlying embedding configuration automatically, so a developer building on top of Engram never has to manually choose or verify which metric matches which model. Consider a translation agency’s assignment assistant matching incoming documents to specialist translators based on domain expertise, where the underlying similarity comparison happens transparently behind a simple search call:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"This translator specializes in pharmaceutical regulatory filings, with particular strength in EMA submission language and dosage-terminology precision.",
properties={"translator_id": "translator-4471"},
)
When a new document comes in needing assignment, the search doesn’t require anyone to think about angles, magnitudes, or which metric applies:
candidate_translators = client.memories.search(
query="Need a translator experienced with clinical trial dosage documentation for a European regulatory submission.",
retrieval_config=HybridRetrieval(limit=5),
)
Behind this single call, Engram’s search correctly measures how closely this new request’s meaning aligns with each stored translator’s documented specialty, using whichever distance metric its underlying embedding configuration was actually built around, consistently applied across every comparison. The agency’s staff never has to know that cosine similarity, or any other specific metric, is doing the actual mathematical work, they just get correctly ranked, meaningfully relevant matches back. That’s exactly the point of understanding these metrics conceptually even when a system like Engram handles the mechanical details automatically: knowing what’s happening under the hood explains why the results behave the way they do, without requiring anyone to manage that machinery by hand.
Distance metrics explain how closeness gets measured once embeddings exist. A more fundamental question, sitting underneath everything covered in this Part so far, is whether vector search by itself is actually sufficient for building a full memory system, or whether it’s structurally missing something memory genuinely needs. Our next chapter, Why is vector search alone not enough for memory?, takes up exactly that question.