Pick the operational rules that prevent stale embedding bugs in production
The four sound rules track model identity, hold the same model on both sides, re-embed on upgrade, and pin the snapshot. The trap option is 'let new docs use a newer model'.
Think of it like a soccer team that switches uniforms mid-season. Half the players wear the old jersey, half wear the new one. From the stands you can no longer tell who is on which team because the colors no longer line up. To keep the game readable you need everyone in the same jersey at any moment, you need to write down which season's jersey it is, and when you change uniforms you swap all of them at once, not one by one. A search index works the same way. Same tool on every side, label what you are storing, swap everything together when you upgrade.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
The 'pick the operational rules' format rewards a candidate who has actually operated an embedding-backed retrieval system. The four correct rules look mundane on paper. In production they are the difference between an index that ages gracefully and one that quietly poisons itself over a series of small migrations.
The trap option in this question deserves attention. It is the most natural-sounding wrong answer because it appeals to a true intuition (newer models are usually better) and applies it incorrectly (you can use them piecewise). An interviewer is watching to see whether you spot the antipattern in the framing.
Why model_id metadata is the cheapest insurance
Storing model_id and model_version alongside each vector is a tiny cost. A short string per vector adds a few bytes to indexes already storing thousands of bytes per vector. Every major vector database in 2026 supports metadata: Pinecone, Weaviate, Qdrant, pgvector, Vespa, Milvus.
The value is asymmetric. In normal operation, you almost never read the metadata. During incidents (suspected bad migration, vendor snapshot bump, debugging a recall regression) it is the only thing that lets you tell what is in the index. Without it, you cannot answer 'is this index mixed?' without re-embedding a sample and comparing.
The discipline is to set the metadata at upsert time, not retroactively. Once a vector is in the index without a model_id, you cannot infer which model produced it without re-embedding.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Pinecone, Weaviate, and Qdrant all support per-vector metadata; production RAG teams in 2026 store model_id and model_version on every upsert.
- OpenAI exposes dated model aliases like text-embedding-3-small-2024-01-01 so teams can pin a stable snapshot in production.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat does the model_id metadata buy you operationally?
Audit trail, ability to filter by model on retrieval, detection of mixed-model states, rollback path. Storage cost is negligible.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Letting new documents use a newer embedding model while older indexed documents stay on the old one, on the theory that 'newer is always better'.
60 second bullets to scan on the way to the call.
model_id and model_version per stored vector
Query model equals index model
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.