The wrong model still answers

Why

A vector is a position in one model's space. Two models build their spaces independently, and there is no reason a position in one means anything in the other. So the embedding model that wrote your vectors has to be the model that queries them.

Nothing in the database will tell you when it is not. The last example is the entire extent of the checking: the index counts the numbers, confirms each one is a finite 32-bit float, and stops. It has no idea which model produced them. Both models here emit 384 numbers, so there is nothing to count wrong, and the mismatched search comes back with a full set of results, ordinary-looking scores, and no error field anywhere in the response.

The second and fourth examples are the pair worth sitting with. Same broken pairing, same index, same articles. One question comes back visibly wrong; the other comes back fine. The two models are both English sentence encoders trained on overlapping data, so their spaces are loosely correlated: a strongly worded query still lands in roughly the right region, while a vaguer one drifts. That is worse than the failure being total. A total failure is caught in five minutes. This one passes whichever question you happened to try first, and ships.

The scores degrade even where the ranking survives, so they are worth reading too. Matched, the best result scores 0.43 and the fourth 0.78. Mismatched, the same question gives 0.83 and 0.89. Two things have gone wrong there. Everything is further away, so anything downstream holding a relevance threshold - and every retrieval pipeline holds one somewhere - now rejects the lot and reports no results rather than an error. And the spread has collapsed from 0.34 to 0.06, which means the index can no longer tell you which of its answers is the good one. A vector from the wrong model lands in a region where nothing in particular is near it, so everything is equally far away and the ordering that comes back is close to arbitrary.

Where this actually bites is rarely a careless developer. It is a model upgrade that re-embeds new documents but not the old ones, or two services running different library versions. The fix is to treat the model identity and version as part of the index's contract: write it down beside the index, and when it changes, re-embed the whole corpus rather than half of it.

The index checks the number of dimensions and nothing else, so a query from the wrong model returns confident nonsense with no error - and because two models' spaces are loosely correlated, some questions still look right, which is what stops anyone noticing.