What is an embedding space?

An embedding space is the full vector space that a given embedding model’s output vectors live in — a coordinate system with a fixed number of dimensions, defined entirely by the model that produces the vectors, within which every possible output that model could ever generate sits somewhere. Talking about “the embedding space” for a particular model is a way of talking about the entire universe of vectors that model is capable of producing, along with whatever geometric structure — distances, directions, clusters — that universe happens to have as a consequence of how the model was trained.

Why does it matter to think of embeddings as living in a shared space, rather than just as a list of independent vectors?

Any single embedding vector, considered entirely on its own, is just a list of numbers with no inherent meaning. What actually makes an embedding useful is its position relative to every other vector the same model could produce — whether it sits close to or far from other vectors representing related or unrelated concepts. Framing this in terms of a shared embedding space makes that relational nature explicit: rather than thinking of each vector in isolation, the embedding space is the single geometric structure within which all of a model’s vectors coexist, and the entire value of an embedding model comes from the shape of that structure — where it places related concepts near each other and unrelated concepts far apart — rather than from any individual vector considered by itself.

This framing also makes clear why embeddings from different models generally can’t be mixed or compared directly, a point worth being precise about since it trips people up in practice. Two different embedding models, even ones trained on similar kinds of data, produce vectors that live in entirely different embedding spaces, with no shared coordinate system or orientation between them — a vector from one model’s embedding space and a vector from another’s aren’t directly comparable by distance, even if they happen to have the same number of dimensions, because the two spaces have no established correspondence between what a given direction or position means in one versus the other. Comparing vectors meaningfully requires that they come from the same embedding space, produced by the same model applied consistently, which is exactly why swapping embedding models partway through a project generally requires re-embedding the entire existing dataset rather than mixing old and new vectors together.

What gives an embedding space its particular geometric shape?

An embedding space’s structure — which regions correspond to which concepts, how tightly related items cluster, how far apart unrelated categories sit — is entirely a product of the training process that produced the model generating the vectors. A model is typically trained by being shown many examples of things that should be considered similar and things that should be considered different, and adjusted repeatedly so that its own output vectors increasingly reflect that intended similarity structure — items marked as similar during training get pushed closer together in the model’s output space, and items marked as different get pushed farther apart. The embedding space that eventually results is essentially a geometric record of everything the model learned about similarity during that training process, shaped entirely by the training data and the specific objective the model was optimized against.

This is also why an embedding space’s usefulness for a specific application is a direct reflection of how well-matched its training was to that application. A model trained specifically on product descriptions produces an embedding space well-organized around product similarity, but that same space might organize legal documents or medical text quite poorly, since the training process never saw examples that would teach it what similarity means in those other domains. Choosing an embedding model is, in an important sense, choosing which embedding space — which particular notion of similarity, encoded geometrically — best matches the kind of search a given application actually needs to perform.

How does this connect back to what HNSW actually operates on?

HNSW and every other nearest-neighbor search structure built on vectors are entirely agnostic to which embedding space they’re operating within — the search algorithm only ever sees raw numeric vectors and a distance function, with no awareness of what those vectors are supposed to represent or which model produced them. All of the meaning behind a search result — why one document is considered similar to another, why one image looks related to a different one — lives entirely in the embedding space the vectors came from, not in the search algorithm that navigates it. This division of responsibility is precisely why the same HNSW implementation, unchanged, can be productively applied to text search, image search, or recommendation systems: the search machinery stays fixed, while the embedding space it operates within changes completely depending on what kind of data and what notion of similarity a given application actually needs.

Having covered what an embedding space is and why its structure is entirely determined by the model that produces it, the embedding glossary page is worth revisiting with this fuller picture in mind if you read it earlier without this context. From there, the query-database distribution shift and out-of-distribution query glossary pages look at a specific, practically important failure mode that arises when a query vector falls into a poorly populated or unusual region of an embedding space, which is a concern that only makes sense once the embedding space itself is understood as a real geometric structure with regions that are better or worse covered by the indexed data.