Re-Indexing Embeddings When Models Change

An embedding model maps text, images, or other inputs into vectors used for similarity search. A model upgrade can change the embedding dimension, normalization, tokenization, training objective, or semantic geometry. Even if dimensions match, old and new vectors may not be comparable because they occupy different learned spaces. Mixing both generations in one index can produce misleading neighbors. A common migration creates a second index for the new model. First record a stable source dataset and preprocessing version. Generate new embeddings in batches, write them with stable document identifiers and metadata, and track progress, retries, and failed records. Validate vector dimensions, counts, duplicate IDs, and metadata before testing retrieval. Do not delete the existing index while the backfill remains incomplete. Evaluation should compare old and new retrieval on a representative query set using relevance judgments or task metrics such as recall at K, ranking quality, and latency. Shadow traffic can send queries to both versions without changing user-visible results. If results are acceptable, switch a routing alias or application configuration to the new index gradually. Keep the old index available during the rollback window. Dual writing can keep both indexes up to date while a migration is in progress, but it adds write cost and consistency complexity. For frequently changing data, capture updates during backfill and reconcile them before cutover. Version model, index, preprocessing, and documents together so retrieval behavior can be traced. After switching, monitor query failures, empty results, latency, relevance, and index freshness. A rollback should restore a compatible model-index pair, not just point the service at old vectors while leaving the new query encoder active. Delete old artifacts only after the upgrade is stable and retention requirements are met.