In Cohere's Embed API, why must input_type differ for documents and queries?

## The parameter `input_type` is a required field on Cohere's `/v2/embed` request for the current Embed generations. It takes one of a small set of values: - `search_document` — text that will be **stored** in an index and later retrieved. - `search_query` — text that a user is **searching with**. - `classification` — text whose vector will be a feature for a classifier. - `clustering` — text whose vector will be grouped by similarity. - `image` — image input on the multimodal models. It is not documentation and not telemetry. It changes the numbers that come back. ## Why an embedding model would care Naively you would expect one text to have one embedding. That is the *symmetric* assumption, and it fits symmetric problems: comparing two paraphrases, deduplicating headlines, clustering support tickets. Retrieval is not symmetric. A query is short, interrogative, keyword-ish and often ungrammatical ("reset pw admin"). A passage is long, declarative and full of surrounding context. Those two texts are stylistically nothing alike even when one perfectly answers the other, and a single symmetric encoder must trade off matching *like with like* against matching *question with answer*. Asymmetric embedding models resolve that by conditioning on the role. Cohere implements this behind `input_type`: the value is turned into a task marker prepended to the text before encoding, so the same string yields a different vector under `search_query` than under `search_document`. The training objective pulls query-role vectors toward the document-role vectors of the passages that answer them. Other model families expose the same idea through instruction prefixes you write yourself; Cohere makes it an API parameter so you cannot forget the exact prefix string. ## The failure mode: silent, not loud This is the part interviewers push on. If you embed everything as `search_document` — including the queries — the API returns valid vectors, similarity search runs, and results come back. They are simply worse. Typical symptoms are a retrieval system that "kind of works": exact keyword overlaps still rank fine, paraphrased questions miss, and top-1 accuracy on an eval set sits several points below what the model is capable of. There is no exception, no warning field, and no way to detect it from the response — only from an evaluation set or a careful code review of your ingest and query paths. The reason it happens is structural: ingest and query usually live in different code paths, often different services, written at different times. The ingest job passes `search_document`; someone later writes the query path by copy-pasting the ingest call. A good defence is to wrap the two calls in two named functions — `embed_for_index()` and `embed_for_query()` — so the value is never a caller's choice, and to assert on it in tests. ## Non-retrieval values `classification` and `clustering` exist because those tasks want a different geometry from retrieval. For classification you want vectors that separate along the label boundaries you care about; for clustering you want vectors whose neighbourhood structure reflects topical grouping rather than question–answer relevance. Use them for their stated purpose, and use them **consistently**: a classifier trained on `classification` vectors must be served `classification` vectors, exactly as a retrieval index built with `search_document` must be queried with `search_query`. ## Consequences for the index lifecycle Because the value is fused into the stored vector, `input_type` behaves like part of the index schema, alongside the model id and the embedding type: - **Changing it is a full re-embed.** You cannot mix vectors built under different input types in one index and expect coherent distances. - **Record it.** Store the model id, embedding type and input type alongside the collection so a future engineer can tell what the vectors mean. - **Keep the raw text.** Re-embedding is the standard migration path for any of these changes, and it is only possible if the source text is still around. ## What a strong answer sounds like Name the parameter, name the retrieval pair, explain asymmetry in one sentence about queries versus passages, then land on the operational point: the failure is silent and the fix is a re-embed. Candidates who only recite the enum values are reciting docs; candidates who mention the silent recall loss have run this in production.