Why do E5 and BGE prepend 'query:' / 'passage:' to inputs, and what breaks without them?

Models like **multilingual-e5-large** and **BGE-large-en-v1.5** were trained on a specific contract: every query in the training data had 'query: ' prepended, and every passage had 'passage: ' prepended. The contrastive loss pulled matched (query, passage) pairs together in vector space and pushed mismatched pairs apart. During this training, the model learned that the two prefixes signal different kinds of inputs. Queries are short and intent-bearing; passages are longer and content-bearing. By giving the model a way to know which side an input represents, the encoder can project queries into one sub-region of the embedding space and passages into another. This with the loss aligning matched pairs across the sub-regions. **At inference time** you have to follow that same contract. If you skip the prefix on one side, the encoder embeds the text as if it were generic, landing in an untrained region of the space. The matched sub region geometry the contrastive loss set up breaks down. The symptom is silent. There is no error, no warning, no log line. The vectors are still valid floats, cosine similarities still produce numbers in the expected range. Only a **recall@K benchmark** on a labeled eval set reveals the gap, typically 5 to 15 percent of recall lost compared to using the prefix correctly. This is one of the most common silent production bugs in 2026 RAG.

**The prefix is part of the training contract.** Models like multilingual-e5-large, BGE-large-en-v1.5, and BGE-M3 saw queries with 'query: ' and passages with 'passage: ' in every contrastive training batch. The InfoNCE loss taught the encoder to project the two sides into matched but distinct sub-regions of the embedding space, exploiting the structural asymmetry between short intent-bearing queries and long content-bearing passages. **The asymmetry pays for itself.** A symmetric embedder (no prefix, single encoder for both sides) wastes representational capacity reconciling query and passage shapes. The asymmetric prefix lets the model allocate capacity differently for each side, typically gaining 5 to 10 percent retrieval recall at equal parameter count. **The failure mode is silent.** Forget the prefix on the query side (the most common mistake, teams remember to prefix passages at index time but skip it at query time). The query embeds into a no-prefix sub-region while passages live in the prefixed-passage sub-region. The two sub-regions were never aligned by the contrastive loss. Cosine similarities still produce numbers, but the geometry is miscalibrated. Recall@10 drops by 5 to 15 percent depending on the model and the benchmark. **No error fires.** The API does not reject un-prefixed input. No log line appears. The vectors are dimensionally correct. The only way to detect the bug is to build a recall@K benchmark on a labeled eval set and compare with-prefix vs without-prefix runs. The production fix is operational: read the model card on Hugging Face, follow the documented prefix convention exactly, and measure recall on real data. Tutorials and stack-overflow snippets routinely omit the prefix; the model card is the source of truth.