Skip to content
RetrievalAsymmetric search

Mid · 6 chapters

Asymmetric search

Query vs document prefixes and instructions, task-specific embeddings

Ignoring task-specific formatting can make a capable embedding model look useless by silently reducing retrieval recall.

Read these first

What you will know

  • Apply the query and document prefixes your model expects

    Some models expect a prefix marking query versus document, and behave badly without it.

  • Measure recall with and without them

    Use the same labeled queries, corpus, rank cutoff, and index settings so any change reflects formatting rather than evaluation noise.

  • Compare query-to-document retrieval with document-to-document retrieval using the model's prescribed formatting

    A model may be optimized for a directional search task rather than general semantic similarity, so symmetric comparisons can misrepresent its intended behavior.

  • Find the required prefixes in a model card

    The exact strings, placement, and whether they apply during indexing or querying are model-specific and are easy to guess incorrectly.

  • Trace a low-recall retrieval result to a missing, reversed, or duplicated prefix

    The resulting failure often resembles poor data or a bad embedding model until the raw model inputs are inspected.


Chapters

  1. 1

    Asymmetric means role, not length, and the card names the strings

    A model trained for asymmetric search learned to place a five-word question next to the long passage that answers it — a relationship between roles, not between lengths. That is why such models ship two different prefixes, and why applying the query prefix to both sides drops recall substantially while raising no error and returning plausible results. Read a model card for the exact strings, their placement, and which side each belongs to.

  2. 2

    The document prefix is baked into the index at build time

    A passage prefix is applied when the document is embedded, so it is frozen into every stored vector, while the query prefix is applied per request and changes with a deploy. That asymmetry makes a wrong document prefix a full reindex and a wrong query prefix a hotfix, and it decides which of the two you should test first when recall looks wrong but nothing is erroring.

  3. 3

    The exact string handed to the encoder is the only evidence worth trusting

    Prefixes get applied in more than one place, which is where the reversed and duplicated cases come from: a sentence-transformer wrapper, a client library or a framework retriever frequently prepends the model's prefix already, so the one your pipeline adds becomes a second copy, and a shared embedding helper called from both paths ends up putting the passage prefix on queries and the query prefix on passages. Neither defect appears in code that reads perfectly correctly. Log or intercept the final string on each side immediately before the encode call and look at it — that one line is what separates missing from reversed from duplicated, and it is the inspection this failure hides behind until somebody performs it.

  4. 4

    Prefix on, prefix off: the run that turns suspicion into a number

    Hold corpus, chunking, labelled queries, rank cutoff and index settings fixed, then run once with the prescribed prefixes and once without, so the only thing the difference can reflect is formatting. Use that number to build an ordered triage for a team reporting recall@10 near 0.3 with a well-regarded encoder and clean documents: capture the raw encoder inputs on both sides first, run this on/off comparison second, and confirm third that the documents are actually in the index and that their stored text is what you believe it is. Each step produces its own evidence, which is why reaching for a model swap before any of them is the dangerous suggestion.

  5. 5

    Retrieve a document with its own text to test the encoder alone

    Searching with each document's own text as the query gives you a ceiling that depends only on the encoder and the index, not on how the two sides are formatted; a healthy self-retrieval run beside poor real-query recall points straight at a missing, reversed or duplicated prefix. The same document-to-document setup is what near-duplicate detection needs, with the passage role on both sides and explicit validation that the model transfers — an asymmetric model was optimised for a directional task, so reusing it symmetrically is a different job it has to earn.

  6. 6

    A second ingestion path without the prefix never moves the average

    A connector added six weeks after launch that forgets the passage prefix corrupts only the documents it ingests, and a corpus-wide recall average barely twitches when four percent of the index goes bad — which is exactly why the retrieval dashboard will not catch it. Build the hour-long guard instead: assert the prefix at write time, sample stored text on a schedule, and break recall out by ingestion source.

External resources