Why must you use the same embedding model for documents and queries?
Each embedding model builds its own vector space, with its own dimensions and meaning for every number. Vectors from different models are not comparable, so mixing them gives meaningless similarity scores, or fails if the sizes differ.
Explain it simply
Imagine two cities with their own map systems. A coordinate like "12, 40" in one city's grid points somewhere unrelated in the other's. Comparing a location from city A to a location from city B tells you nothing.
Embedding models are the same. Model A may place "refund" and "money back" close together in its space. Model B uses a different space entirely, with different axes and often a different number of dimensions. A query embedded with one and documents embedded with the other have no shared geometry.
Practical rule: record which model and version produced your index. If you change the model, even to a newer one from the same family, re-embed the whole collection. Some models also expect a different prefix or instruction for queries and documents, so follow their documentation.
Example
Index built with model A (768 dims).
Query embedded with model B (1024 dims) -> dimension mismatch, error.
Query embedded with model C (768 dims) -> runs, but scores are noise.What to say in the interview
"Similarity is only meaningful inside one embedding space. I use one model for both documents and queries, store the model name with the index, and re-embed everything when the model changes."
Common mistakes
- Assuming equal vector length means compatible vectors.