Describe what the 'query:' and 'passage:' prefixes do for models like E5 and BGE

Many open-weight embedding models like **multilingual-e5-large** and **BGE-M3** require an instruction prefix on every input. Queries get 'query: ' prepended; documents (passages) get 'passage: ' prepended. The prefixes look like ordinary preprocessing strings, but they are not. They are part of the **training contract**. During contrastive training, the model saw queries with the 'query: ' prefix and passages with the 'passage: ' prefix in every batch. The model learned to project the two sides into slightly different sub-regions of the embedding space, capturing the asymmetry between short intent-bearing queries and longer content-bearing passages. At inference time you have to follow the same contract. Embed queries with 'query: ' and passages with 'passage: '. Mix them up or skip the prefix on one side and the geometry shifts: the model embeds the text as if it were generic. Which drops retrieval recall by 5 to 15 percent compared to using the prefixes correctly. This is one of the most common silent bugs in production embedding pipelines. There is no error, no warning, no API rejection. The vectors are still valid floats, cosine similarities still produce numbers, but the recall benchmark would show the gap if you measured it.

**Instruction prefixes** are part of the model's training contract, not optional preprocessing. Models like multilingual-e5-large, multilingual-e5-base, BGE-large-en-v1.5, BGE-M3, and several instruction-tuned embedders were contrastive-trained with explicit asymmetric prefixes on queries vs passages. The purpose is to encode the **asymmetry** between the two sides of retrieval. Queries are typically short, intent-bearing, question-shaped; passages are longer, content-bearing, declarative. A model that projects both into a single uniform geometric space wastes capacity on the asymmetry. A model that uses prefixes to signal which side the input represents can project queries and passages into matched but distinct sub-regions of the same space. This with the contrastive loss aligning matched pairs across the sub-regions. The failure mode is silent. If you skip the prefix on one side but apply it on the other, you embed the un-prefixed input as if it were generic content. The vectors are still valid floats and cosine similarities still produce numbers in the expected range. The geometry has shifted by a few degrees, enough to drop retrieval recall by 5 to 15 percent depending on the model and benchmark. No error fires, no log line appears, nothing fails loudly. The only way to detect the bug is a recall benchmark on a labeled eval set. This is the single most common silent bug in 2026 production RAG pipelines. Teams onboard a new embedding model, copy the API call shape from a tutorial, forget to add the prefix on the query side. Absorb a percentage points of recall hit they never measure.