A model name is not a retrieval decision
Embedding benchmarks published on another corpus cannot predict how your terminology, document structure and query distribution will behave. Exact identifiers, short requests and multilingual questions can react differently from broad semantic questions. Use your own relevant-source labels whenever possible.
Compare one variable at a time
A fair embedding comparison uses the same selected files, query set, chunking strategy and retrieval mode for every candidate. RetrievalGate records the tested configuration so a gain is not silently attributed to an embedding model when chunk boundaries or hybrid retrieval changed at the same time.
Inspect retrieval coverage and regressions
Recall at 5 tells you whether the intended source stays available to the application. MRR and nDCG add rank-sensitive context. The Full Audit also reports segment and query regressions: a model that improves a general score while degrading identifiers or a key language is not automatically the right migration.
Include the cost of changing models
A new embedding model generally means re-embedding the corpus and rebuilding the vector index. The Full Audit estimates chunks, raw vector footprint and configured-model embedding cost from the selected corpus. Those estimates exclude database overhead, requests, reranking and negotiated rates, so confirm them against your provider and infrastructure before committing.
Validate the selected candidate in production
Offline gains do not prove latency, filtering behavior, access controls or final answer quality in your stack. Use the implementation card to stage the change, then run the included validation rerun with fresh queries. A candidate that does not clear the evidence threshold should remain an experiment, not a migration.