Spot the subtle bug in this BGE-M3 indexing snippet

The bug is in the `search` function. The indexing path wraps each document with `'passage: '` before encoding, but the query path encodes the raw query string with no prefix. **BGE-M3** and the E5 family were trained with two specific prefixes: `passage:` for documents and `query:` for user queries. During training the model learned to project each side into a region of vector space tuned for that role. At inference, leaving one prefix off pushes that input into the wrong neighborhood. Nothing crashes. The encoder still produces a 1024-dim vector. The vector DB still returns the top-k nearest neighbors. But those neighbors are no longer the best matches: recall@10 typically drops 5-15% versus the correctly-prefixed version. The fix is one line: wrap the query with `f'query: {query}'` before calling encode.

**The bug is on the query side.** Documents get prefixed with `'passage: '`, queries are encoded raw. BGE-M3 was trained with both prefixes, so the model learned to separate the input distribution into a query sub-space and a passage sub-space. Skipping the query prefix lands the query in the wrong sub-space. This is the worst class of embedding bug because it is silent. The encoder returns a valid vector, the vector DB returns a valid top-k, and the application keeps shipping. The only signal is a recall@k benchmark on a labeled set, and most teams do not have one wired into CI. The fix is one line: $$\text{query\_text} \to f\texttt{'query: \{query\}'}$$ The broader lesson: any model with an asymmetric encoder treats the prefix as part of the input contract, not as decoration. Wrap the prefix in a helper function that both paths call. Better still, store the expected prefix alongside the index metadata so a recall canary can assert it on every deploy.