An embedding model change does not merely replace a function that emits arrays of the same length. It can change the coordinate system in which stored items and incoming queries are represented. Even when two models produce vectors with identical dimensions, their coordinates and similarity-score distributions are not interchangeable by default.

That makes an embedding model version part of the index schema. A retrieval system that changes the query encoder while retaining vectors produced by an older encoder can still return numeric scores, but those scores no longer have a justified geometric interpretation unless cross-version compatibility is an explicit property of the models.

Vector dimensions do not define compatibility

A vector index typically validates structural properties such as dimensionality and numeric type. Those checks say nothing about semantic compatibility.

Suppose both model versions emit 768-dimensional vectors:

v_old = encoder_A(document)
q_new = encoder_B(query)

score = cosine(q_new, v_old)

The cosine operation is mathematically defined because both vectors have the same length. The retrieval meaning is a separate question. Coordinates from encoder_A and encoder_B may represent different directions, scales, or semantic relationships.

Dimension equality is therefore necessary for many index operations but insufficient as a migration contract. The model identifier, model revision when relevant, preprocessing rules, and post-processing rules belong with the stored representation metadata.

Mixed spaces create silent failure modes

A partial re-embedding job can produce an index containing vectors from two representation spaces. Approximate nearest-neighbor software may accept that state if every vector has the expected shape.

The resulting ranking then compares a query against heterogeneous coordinates:

query: encoder_B

item 1: encoder_A
item 2: encoder_B
item 3: encoder_A
item 4: encoder_B

There is no general rule that makes scores across those two groups comparable. Items encoded by one version can gain or lose rank because of the representation change rather than because their content is more or less relevant.

This failure can be hard to spot through availability metrics. The index responds, latency can remain normal, and every result can have a valid floating-point score. Retrieval quality is the component that changed.

A safer boundary keeps model versions separated during migration. A new index, collection, namespace, or versioned vector field can hold the replacement representation until enough content has been re-encoded for evaluation and cutover.

Score thresholds belong to a representation version

Applications often use similarity scores for more than ordering. A system may reject retrieval results below a threshold, decide whether to invoke a fallback, or select candidates for a later reranker.

Those thresholds are coupled to the score distribution produced by the representation pipeline. A model migration can shift that distribution even when the same similarity function remains in use.

For a threshold t, the application rule may look simple:

accept candidate if cosine(q, d) >= t

The value of t has meaning only relative to the vectors used to estimate or validate it. Carrying the same threshold into a new embedding space assumes score calibration remains stable. That assumption needs evidence from representative data rather than dimensional compatibility.

The same applies to distance-based cutoffs and hybrid-search weights. If dense scores are combined with lexical or structured signals, a distribution shift in the dense component can change the balance of the combined ranking.

Dual indexing gives the migration an observable boundary

A model replacement is easier to evaluate when old and new representations coexist in separate indexes for a limited period. The application can encode a representative query set with each matching model and compare retrieval outputs without mixing vector spaces.

The comparison should match the behavior the application actually depends on. If only top-ranked documents matter, ranking agreement and relevance judgments are more informative than comparing raw vector coordinates. If a threshold controls fallback behavior, acceptance rates and errors around that threshold deserve direct inspection.

Raw cosine values from two models should not be expected to match numerically. The useful comparison is whether each model-index pair supports the required retrieval decisions under the same evaluation cases.

Dual indexing also creates a clean rollback point. The serving path can switch between complete representation versions instead of trying to reconstruct which individual records were encoded by which model after a mixed migration.

Incremental updates need version metadata

Long-running indexes continue to receive inserts, edits, and deletions while a migration runs. Without explicit representation metadata, concurrent writes can leave ambiguous state.

A stored record can carry a representation version alongside its vector:

document_id: 42
embedding_version: "catalog-v3"
vector: [...]

The exact storage design depends on the vector database and application architecture. The invariant matters more than the field name: code must be able to determine which representation contract produced a stored vector.

That metadata supports idempotent backfills. A migration worker can skip records already encoded with the target version and retry interrupted work without guessing from timestamps. It also allows validation to detect records that escaped the intended migration.

If preprocessing changes independently from the model, the version should identify the complete representation pipeline rather than only the model artifact. Text normalization, truncation, chunk construction, pooling, and vector normalization can all alter the final coordinates.

Cache keys need the same boundary

Embedding caches can reintroduce old vectors after an index migration if cache identity ignores the representation version. A key derived only from input text treats the embedding as though it were a timeless property of that text.

A safer cache identity includes the representation contract:

cache_key = hash(
    representation_version
    + normalized_input
)

This prevents a request using the replacement model from receiving a vector created under the previous pipeline. The same principle applies to cached query embeddings and precomputed document vectors stored outside the primary vector index.

Cache invalidation does not require deleting every old entry immediately if versioned keys make old and new values distinct. Expiration can then reclaim obsolete entries without allowing cross-version reuse.

Cutover is a retrieval decision

Finishing a backfill is not enough to establish that the replacement representation is suitable. A complete new index can still rank the target corpus differently in ways that matter to the application.

The cutover criterion should therefore be expressed in retrieval behavior: the new model-index pair meets the evaluation conditions used for the serving path, its thresholds or hybrid weights have been checked against the new score distribution, and incoming writes are producing only the target representation.

After cutover, retaining the old index for a bounded rollback window can separate operational recovery from the re-embedding process. Once that window closes, old vectors and caches can be retired as obsolete schema versions.

Treating embeddings as versioned index data makes model replacement explicit. The central boundary is not the array shape; it is the representation space that gives those numbers meaning.

Artificial Intelligence Embeddings Vector Search Retrieval