AnswersEmbeddings in Production

Can You Convert Vectors Between Models?

When switching embedding models, can existing vectors be converted, or do you have to re-embed everything, and what makes re-embedding cheap?

2 min readJuly 2026

The short answer

No. Embeddings from different models, including different versions of the same model, live in geometrically incompatible spaces. A query embedded with model B scored against documents embedded with model A returns noise, not degraded-but-usable results.

Learned translations between spaces exist in research, but they blur exactly the fine distinctions you're upgrading to get, and their failure modes are unpredictable on your data. Treat vectors as derived data: keep the source text, re-embed on every model change, and put your effort into making re-embedding cheap.

Why don't spaces transfer?

An embedding's coordinates mean nothing outside the model that produced them; dimension 412 encodes whatever that particular training run made it encode. Two models trained on different data with different objectives put "similar" documents in entirely different places. There's no shared frame for a simple transform to recover.

Vectors are derived data: regenerate them, don't translate them.

Convert vectors

Model A vectors

Learned mapping

Approximate model B vectors

Fine neighborhoods lost, silently

Re-embed

Source text

kept as the source of truth

Model B embeds

Native model B vectors

Exact by construction

What about learned mappings?

Research shows rough translation between embedding spaces is possible: vec2vec (Jha et al., 2025) translates embeddings across models without paired data. But "possible" means enough to be interesting for analysis, not enough to serve retrieval. A mapping trained to minimize average error preserves coarse topology and sacrifices the fine-grained neighborhoods that decide top-10 rankings, and it drifts hardest on exactly the out-of-distribution content where you'd least notice. For a production index, "approximately converted" means silently worse results with no error to alert on.

So what makes re-embedding cheap?

Three things cut the cost, in order of impact:

  1. Embed less: deduplicate before embedding, since redundant corpora shrink dramatically (how to chunk redundant documents).
  2. Batch offline: backfills are throughput problems, not latency problems; batched inference is a fraction of per-request pricing on any provider.
  3. Let the database do it: when the engine owns embedding (managed inference), a backfill is a server-side operation instead of an external pipeline you build, monitor, and keep version-consistent. The full migration pattern is in how do you upgrade embedding models.

With TopK's semantic_index, embedding runs inside the database, so re-embedding is a backfill rather than a data-engineering project, and "we should upgrade the model" turns from a quarter-long migration into a routine operation.

Keep reading

How Do You Upgrade Embedding Models?Blue-green the index: backfill with the new model, dual-write, shadow-test, flip reads, keep the old index for rollback. Model vectors never mix.How Do You Chunk Redundant Documents?Deduplicate before you embed: canonicalize versions, hash-dedupe chunks, and reach history through filters. Indexing every version multiplies cost.What Is Multi-Vector Retrieval?Multi-vector retrieval stores one embedding per token and scores documents with MaxSim, so precise queries match exact passages instead of a lossy document summary.