A team has an existing vector index built entirely with embedding model A, and decides to switch to a newer embedding model B for future documents, adding model B's embeddings for new documents directly into the same index alongside the old model A vectors, without touching the old ones. Comparing similarity between a query embedded with model B and an old document vector still embedded with model A produces meaningless results. Why?
- Because each embedding model learns its own distinct vector space during training, so numerically comparing a vector from one model against a vector from a different model is comparing coordinates from two unrelated coordinate systems, not two points that were ever placed in the same space to begin with, even if the two vectors happen to have the same number of dimensions
- Because model B's vectors are always higher-precision floating-point numbers than model A's, and comparing two different numeric precisions always produces a runtime error rather than a similarity score
- Because vector databases only support one embedding model per collection at the software level, so inserting model B vectors into the same collection as model A vectors is rejected before any similarity computation happens
- Because the query text itself must be re-encoded once per document being compared against, and skipping that per-document re-encoding step is what produces meaningless results here, not anything about the two embedding models
Why A? And why not the others?
Correct answer: A. Because each embedding model learns its own distinct vector space during training, so numerically comparing a vector from one model against a vector from a different model is comparing coordinates from two unrelated coordinate systems, not two points that were ever placed in the same space to begin with, even if the two vectors happen to have the same number of dimensions
An embedding model's vector space is a byproduct of its own particular training process, so the geometric relationships that make similarity scores meaningful, such as which directions correspond to which shades of meaning, are specific to that one model; a vector produced by a different model, even one with an identical number of dimensions, was never placed into that same learned geometry, so measuring cosine similarity or a dot product between the two amounts to comparing coordinates from two unrelated coordinate systems that happen to share a dimension count, not two points meaningfully positioned relative to each other. This is why switching embedding models requires re-embedding the entire existing corpus with the new model rather than mixing old and new vectors in one index. The claim about precision mismatches always causing a runtime error is wrong; numeric precision differences do not by themselves make a similarity computation fail, and this is not the actual reason the comparison is meaningless. The claim that vector databases reject multiple models per collection at the software level is also wrong; most vector databases will happily store and compare vectors of matching dimensionality regardless of which model produced them, which is exactly why this mistake is possible to make silently rather than being blocked outright. And re-encoding the query once per document is not a real requirement of any embedding-based retrieval system; the query is embedded once and compared against many pre-computed document vectors, so this option describes a nonexistent step rather than the actual cause of the mismatch.
Source: OpenAI, embedding models documentation on model-specific vector spaces, https://developers.openai.com/api/docs/guides/embeddings; OpenAI Help Center, 'Embeddings FAQ,' https://help.openai.com/en/articles/6824809-embeddings-faq