What does a text embedding encode, and what does it fail to encode?
An embedding places text in a space where distance approximates the similarity its training data taught it. It does not encode relevance, and it represents exact identifiers, negation and numeric constraints so weakly that dense retrieval alone is unreliable wherever those decide the answer.
What the interviewer is scoring
- Does the candidate distinguish similarity from relevance rather than using the words interchangeably
- Whether the specific failure classes are named with an example rather than described as edge cases
- That the embedding reflects its training distribution and therefore degrades on unfamiliar domain vocabulary
- Whether asymmetry between a short query and a long passage is recognised as a modelling choice
- Does the candidate reach for a non-dense mechanism for the queries dense retrieval cannot serve
Answer
What the vector is
An embedding model maps a span of text to a fixed-length vector, trained so that texts people treat as related end up close together under a distance measure — usually cosine similarity. What "related" means is not a mathematical property; it is whatever the training objective and training pairs taught the model. A model trained on question-and-passage pairs learns that a question and the passage answering it should be close. A model trained on paraphrase pairs learns that two sentences meaning the same thing should be close. Those are different spaces and they behave differently on the same corpus.
The practical consequence is that an embedding compresses meaning into a few hundred or a few thousand numbers, and compression is lossy in a specific direction: it keeps what varies across the training distribution and discards what does not. Broad topical content survives. Fine distinctions that rarely mattered during training do not.
Similarity is not relevance
The gap that matters most is conceptual rather than technical. Nearest-neighbour search returns the passages closest to the query, and closeness correlates with usefulness without being it. A question and its own restatement are extremely close, and the restatement answers nothing. The FAQ entry asking exactly your question and replying "contact your administrator" is closer to the query than the buried paragraph that contains the answer, because the query's vocabulary is in the question, not in the answer.
This is also why a query and a document are not symmetric objects. A five-word question and a 300-word passage have different lengths, different registers and different information content, and treating them as the same kind of thing is a modelling choice that some models make deliberately and others do not. Models trained for asymmetric retrieval, sometimes with distinct instructions or prefixes for the query and the document side, exist precisely because the naive symmetric treatment underperforms. Using a model outside the regime it was trained for is a common and invisible mistake, because the results are plausible rather than broken.
The three failure classes worth naming
Exact identifiers. Part numbers, error codes, ticket references, invoice numbers, unusual proper nouns. A tokeniser splits EM-4471-B into fragments that carry almost no learned meaning, so its vector is dominated by whatever context surrounded it. Two different part numbers in similar sentences therefore sit close together, and a search for one will happily return the other. This is the single most reported complaint about a dense-only system in an enterprise, because internal corpora are full of identifiers and users type them expecting exact matching.
Negation. "The warranty covers water damage" and "the warranty does not cover water damage" share almost every token and almost all their topic. Their embeddings are close, and a retriever asked which products lack a feature will return passages about products that have it. Nothing in the standard training objective forces a model to separate a claim from its denial, so it largely does not.
Numeric and temporal constraints. "Orders above £500" and "orders above £50" differ by one character and by the entire meaning of a policy. Embeddings do not encode magnitude comparison, so a query about a threshold retrieves passages about thresholds. The same applies to dates: a question about the 2025 rate card retrieves rate cards, and which year it belongs to is a fact you must have stored as metadata and filtered on.
There is a fourth, less discussed: domain drift. A model trained on general web text has thin representations of the vocabulary of your specialised corpus — clinical abbreviations, a trading desk's jargon, a company's internal product names — so distances in that region of the space are noisier than the benchmark numbers suggest. Retrieval benchmarks that span heterogeneous domains exist because in-domain results do not transfer.
What follows from the limits
None of this is an argument against embeddings. It is an argument that dense retrieval is one signal, and the queries where it fails are predictable enough to be routed. A lexical index handles the identifier case directly, because BM25 rewards the literal token that an embedding dissolves. Structured metadata and a filter handle dates and thresholds properly rather than approximately, since a numeric constraint is a WHERE clause pretending to be a search. And a reranker that reads the query and passage together can separate a claim from its negation in a way that two independently computed vectors cannot, because it sees both texts at once.
The signal an interviewer is looking for is whether you know which class a failing query belongs to before you start tuning. Reaching for a larger embedding model when the failing queries are all part numbers is the most expensive way to make no progress.
A high similarity score means the retrieved text resembles the query. It does not mean the text answers it, and for identifiers, negations and numeric limits the resemblance is close enough to be actively misleading.
Likely follow-ups
- Why does an embedding of a negated sentence sit close to the embedding of its opposite?
- How would you handle a query that is a single part number?
- What breaks if you embed queries with one model and documents with another?
- When is a filter on structured metadata a better answer than any retrieval improvement?
Related questions
- Your RAG system cannot answer a question whose answer is definitely in the documents. Where is the fault?hardAlso on rag and retrieval4 min
- How do you build a gold set for a retrieval system?mediumAlso on retrieval and rag5 min
- How do you choose a chunking strategy for a document corpus?mediumAlso on retrieval and rag4 min
- A better embedding model has come out. What does moving to it cost you?hardAlso on embeddings and rag5 min
- Why is a recommender built as candidate generation followed by ranking rather than as one model?hardAlso on retrieval5 min
- Models take a million tokens of context now. Does that remove the need for retrieval?mediumAlso on retrieval4 min
- How do you keep a retrieval index current as the underlying documents change?mediumAlso on rag5 min
- How do you decide between prompting, retrieval and fine-tuning?mediumAlso on retrieval5 min