Your search broke when you upgraded the model

// one space, or nothing works

Retrieval works because the stored vectors and the query vector are points in the same space, produced by the same model:

At inference time, an incoming query is mapped into the exact same latent vector space using the identical embedding model … query vectors are compared to a vector database constructed from the knowledge corpus, typically encoded using the same embedding model.

Swap the model and your query lands in a different coordinate system from everything already indexed. Nearest-neighbour search still runs perfectly well — it returns the closest points it can find, and those points no longer mean what you think.

This is a silent quality collapse, not a crash. There is no error to catch, no log line, no failed health check. Recall just degrades, and the only symptom is answers that feel slightly off.

A library that renumbered its shelves

Your old catalogue still returns a number for every book. That number now points at the wrong shelf. Nothing about the catalogue looks broken — every lookup succeeds and hands you a location.

And critically: no formula converts the old numbering to the new one. You have to walk the building and re-catalogue every book.

Do not reach for Celsius and Fahrenheit here. The literature does, and it argues against the point: C and F are related by an exact formula, so anyone following the analogy correctly concludes "just convert them" — which is precisely the thing you cannot do. There is no function mapping one model's vector space onto another's, and that is the entire reason a full re-index is required.

A dimension change is the lucky case

If the new model outputs a different vector width, most stores reject the write outright on a dimension mismatch.

# the GOOD outcome — it fails loudly new model, different width → write rejected # the dangerous one — everything "works" new model, same width → write succeeds, search runs, quality quietly degrades

Being stopped by a dimension mismatch is a gift. The case to fear is a new model with the same dimensionality, because every layer of your stack will report success.

The fix

Re-embed the entire corpus with the new model. There is no incremental path — a partial re-index leaves two incompatible coordinate systems inside one collection, which is strictly worse than either alone.

Which makes the embedding model a versioned dependency of your index, not a setting. Pin it, record it alongside the collection, and treat changing it as a migration with a backfill.

Related and often confused with this: the copy your search kept is the case where you changed the document rather than the model — there the vectors are perfectly readable, they just describe text that no longer exists. And embeddings explained with one analogy is the map this all sits on.

One concept a week. Free.

The deeper, copy-paste version of each ToolCall short — in your inbox.

// total: 0.00 · spam: void · unsubscribe: one click