Two embedding models can emit vectors with the same number of dimensions and still produce similarity scores that have no useful cross-version meaning. A vector database accepts the shapes, the distance function runs normally, and retrieval returns ranked results. Nothing in that execution path proves that query and document vectors occupy a compatible representation space.
This makes embedding model identity part of the retrieval interface. Replacing an encoder is not equivalent to swapping a serialization routine. Unless compatibility is explicitly established, vectors produced by separate model versions should be treated as belonging to separate spaces.
Matching dimensions do not establish compatibility
An embedding vector is useful because its coordinates are interpreted relative to the representation created by a particular encoder. A dimension count only states the shape of the output.
Suppose encoder A and encoder B both emit 768-dimensional normalized vectors. A query encoded with B can be compared numerically with a document encoded with A:
score = q_B · d_AThe dot product is mathematically defined, but its retrieval meaning is not established merely because both vectors have length 768. Coordinate 117 in one representation has no required relation to coordinate 117 in the other.
Even two checkpoints from the same architecture can differ in this respect. Parameter updates can rotate, reshape, or otherwise alter the representation geometry while preserving output shape. A storage layer cannot infer semantic compatibility from tensor dimensions, model family names, or normalization alone.
Mixed indexes create a silent failure mode
A partial migration can leave an index containing vectors from multiple encoder versions. New documents may use encoder B while older documents retain vectors from encoder A. If incoming queries use only B, the index now compares one query representation against two document spaces.
This failure is easy to miss because vector search infrastructure usually validates data types and dimensions rather than representation identity. Approximate nearest-neighbor search can still return a complete top-k list. Latency, index health, and request success rates can remain normal while ranking quality changes.
Score thresholds become especially difficult to interpret. A threshold calibrated on A-to-A comparisons does not automatically transfer to B-to-B comparisons, and it says even less about B-to-A comparisons. A change in score distribution can come from altered geometry rather than altered relevance.
The same issue affects cached query embeddings. Re-encoding the document corpus while retaining query vectors from an older encoder creates the inverse mismatch.
Space identity belongs beside each vector
A retrieval system can make the compatibility boundary explicit by storing an embedding-space identifier with vectors and query-generation configuration. The identifier can include the encoder release, relevant preprocessing contract, and any representation-affecting configuration.
For example:
embedding_space = "encoder-b:2026-09"
dimension = 768
normalized = trueThe exact metadata schema is application-specific. The useful property is that retrieval code can reject or route incompatible comparisons before ranking occurs.
Preprocessing is part of this identity when it changes encoder input. A model release paired with one text normalization or truncation policy can produce a different retrieval distribution from the same model paired with another policy. Versioning only the model artifact can therefore be too coarse for systems that change representation-affecting preprocessing independently.
Distance configuration also deserves explicit tracking. L2-normalized vectors make cosine ranking equivalent to dot-product ranking up to a monotonic transformation, but that fact does not make unnormalized and normalized representations interchangeable. The index contract should describe the vectors actually stored.
Migration should compare complete retrieval paths
A safe migration evaluates the new space as a complete query-to-document path: queries encoded with the candidate encoder against documents encoded with that same encoder. The old path remains a separate baseline.
This avoids attributing mixed-space behavior to the candidate model. If B queries are tested against A documents, the evaluation measures a cross-space configuration rather than the intended B retrieval system.
A shadow index is one practical structure for this comparison. The existing index retains A vectors while a separate index receives B vectors for the same document set. Evaluation queries are encoded once per space and sent to the matching index:
q_A -> index_A
q_B -> index_BRelevant retrieval metrics can then be compared under the same query set and relevance criteria. Score histograms are useful diagnostics, but raw score equality is not a migration objective. A new embedding space can produce a different numeric score distribution while preserving or improving ranking for the target workload.
Dual writes reduce migration ambiguity
Large corpora may take time to re-encode. During that interval, writing only the new representation creates a mixed-version primary index unless the storage design separates spaces.
Dual writes keep the boundary clearer. New or updated documents can receive both A and B embeddings while backfill proceeds, with each vector written to its matching index or namespace. Query traffic can remain on the old path until the new corpus reaches the required coverage and evaluation criteria.
This approach costs additional encoding and storage during migration, but it avoids making document age determine representation compatibility. It also gives rollback a concrete boundary: routing can return to the old query and index pair while both representations remain available.
If dual writes are not practical, another design is to complete a new index offline and switch routing only after the backfill is ready. The core constraint is the same: do not rely on mixed-space similarity unless cross-version compatibility has been deliberately established.
Compatibility can exist, but it needs evidence
Some systems intentionally map vectors between spaces or train representations with constraints designed to preserve compatibility. In that case, cross-version comparison is part of the model contract and should be evaluated directly.
That is different from assuming compatibility because two encoders share an architecture or vector size. The relevant evidence is retrieval behavior for cross-version pairs under the intended metric and data distribution.
A compatibility claim should also state its direction. A system may care about new queries against old document vectors, old queries against new vectors, or both. Those are separate comparison paths and can be tested separately.
Embedding migrations become easier to reason about when a vector is treated as a value plus a space identity. Dimensions make arithmetic possible; a shared representation contract makes the resulting similarity score meaningful for retrieval.