Limits of embedding search: negation, recency, and source authority

An embedding model maps text to a point such that semantically related text lands nearby. That objective — stated plainly — contains all three limits, because three things a retrieval system needs are not semantic relatedness:

There is a fourth item that belongs in the same family and is often bundled with it: embedding search has no concept of authorisation. Similarity does not know that this user may not read that document. That one is severe enough to get its own lesson, 07-05.

All four share a shape worth naming once and remembering: the failure is a wrong answer, not a missing one. Embedding search always returns its top k, ranked by a similarity that is real, computed correctly, and answering a question you did not ask.

L1 — The intuition you can carry into an exam

The embedding model was trained to put text about the same thing in the same place. "Not supported" is text about the same thing as "supported". The 2019 policy is text about the same thing as the 2026 policy. A forum guess about TLS errors is text about the same thing as the TLS specification. The model is working correctly. Your requirement was never expressible as similarity.

Anything you need the retriever to respect that is not "aboutness" must be supplied from outside the vector: from metadata, from a filter, from a second retrieval leg, or from a reranker that reads the passage properly.

L2 — The mechanism, limit by limit

Negation. A sentence's polarity is carried by one short, extremely common word — not, never, cannot, unsupported, except. In the embedding space, that word contributes a small perturbation to a vector dominated by the sentence's content words. Consider these two sentences:

A: "TLS 1.0 is supported for legacy clients."
B: "TLS 1.0 is not supported for legacy clients."

They share every content word. TLS, 1.0, supported, legacy, clients all point the vector in the same direction; not nudges it slightly. A constructed illustrative similarity between them might be around 0.93 — far higher than either's similarity to a genuinely unrelated passage. Now ask "is TLS 1.0 supported?" Both A and B are near your query. The retriever cannot rank them by polarity because polarity is not what the space encodes. Whichever happens to be marginally nearer wins, and that ordering is effectively arbitrary with respect to the thing you cared about.

This gets worse with queries that contain negation. A user asks "which browsers are not supported?" The query vector is dominated by browsers and supported, so the retriever confidently returns the supported-browsers table. The user reads a list of supported browsers under the impression it answers the opposite question. There is no similarity threshold that catches this, because the retrieved passage genuinely is highly similar.

Recency. Embeddings encode content. Time is not content. Two versions of a document differ in a date, a version string, and perhaps three sentences out of forty; their vectors are nearly identical. Constructed illustration:

query:  "what is the maximum expense claim window?"
doc_v1 (2019, superseded): "Claims must be submitted within 90 days."   cos = 0.88
doc_v2 (2026, current):    "Claims must be submitted within 30 days."   cos = 0.88

The similarities are the same because the meaning is the same kind of meaning. The retriever has no basis for preferring doc_v2, and if both are retrieved, the LLM now receives two contradictory numbers with no signal about which governs. It will pick one, or average them, or present both without noticing they conflict. 06-04 on deduplication is directly relevant here: near-duplicate versions of a document are one of the most damaging corpus defects precisely because they defeat the retriever's ability to be decisive.

A related and more insidious version: superseded content often outranks current content, because the superseded version is frequently longer, more explanatory, and more thoroughly indexed than the terse update that replaced it. Nothing in the retrieval stack notices.

Authority. Embedding similarity rewards register match — text that reads like the query. Queries read like questions from confused people. So do forum posts, Stack Overflow questions, internal chat logs, and support-ticket bodies. Specifications, standards documents, and reference manuals read like specifications. Constructed illustration:

query: "why do I get a handshake failure with my client cert?"

forum reply (unverified, wrong): "I got this too — you probably need
  to disable cert verification, that fixed it for me."         cos = 0.86

RFC-style spec section (authoritative, correct): "The server MUST
  abort the handshake if the presented certificate chain cannot be
  validated against a configured trust anchor."                cos = 0.71

The wrong answer scores higher, and it scores higher for a legitimate reason: it is written in the same register as the query. If your corpus mixes authoritative and community content — and most real corpora do — dense retrieval will systematically over-select the community content. This is one of the strongest arguments for corpus curation (08-01) being a retrieval-quality intervention rather than a data-hygiene chore.

L3 — Why a better embedding model does not fix any of this

It is tempting to read all three as "current models are not good enough yet". That reading is wrong for structural reasons worth stating precisely.

On negation: contrastive training (07-02) teaches the model that a query and its relevant passage should be close. Negation-flipped pairs are exactly the hard negatives that are hardest to mine, because automatically distinguishing "the relevant passage" from "the passage that says the opposite" requires the labelling capability you were trying to build. Some models are measurably better at negation than others. None of them are reliable at it, and the improvement axis is bounded by the objective itself: a model that pushed negation-flipped pairs far apart would also push apart pairs that are genuinely about the same topic, which is the capability you bought the model for. There is a real tension here, not just an engineering gap.

On recency: this one is not a modelling gap at all. It is a category error. Publication date is metadata, and metadata is not in the text. Even a perfect semantic encoder cannot encode a fact that was never in its input. The fix is architectural — store the date, filter or boost on it — and it belongs in 06-03 and 07-04, not in model selection.

On authority: same category. Provenance is metadata. A model can be trained to prefer formal register, but "formal" is not "authoritative", and the correlation between the two is weak enough to be dangerous. The fix is again architectural: tag sources with a trust tier at ingestion, and use that tier in ranking.

The general principle, and the one worth carrying into every RAG design review: requirements that are not about meaning must be enforced outside the vector. If you find yourself hoping a better embedding model will make your retriever respect dates, permissions, versions, or logical polarity, you have located a design problem rather than a procurement problem.

The reason this module teaches both retrievers before combining them is that the blind-spot tables barely overlap. Read this side by side:

Two observations that exam items probe directly.

The first four rows are complementary — that is the hybrid search argument. Where one fails the other works, so fusing the two result lists recovers both capabilities. 07-06 is the mechanism.

The middle four rows are shared failures — and hybrid search does not fix them. This is the point most often missed. Adding BM25 to a dense retriever does nothing for recency, authority, or permissions, because BM25 is equally blind to all three. Those require metadata and policy, not a second similarity function. A distractor that offers "add hybrid search" as the fix for a stale-document problem is exploiting exactly this confusion.

Negation sits awkwardly between the two groups, which is why it is worth a nuance. BM25 at least treats not as a term, so a query for "not supported" gets some lift from documents containing not near supported — especially with phrase or proximity queries. That is not reliable, because not has very low IDF and phrase matching is brittle, but it is not zero. Dense retrieval's handling is worse in a specific sense: it produces a confident ranking that ignores polarity, whereas sparse retrieval produces a weak signal that at least does not actively invert.

All similarity values below are constructed illustrative numbers, chosen so the ranking logic is inspectable. They are not measured from any model and must not be quoted as benchmark results.

Our corpus is an internal support knowledge base with mixed provenance — official docs, deprecated docs, and archived team-chat threads — chunked per 06-02 and embedded per 07-02. Six chunks:

Query 1 — negation: "is TLS 1.0 supported?"

cos(q, k2) = 0.91     "TLS 1.0 is supported for legacy clients"        ← WRONG (superseded, and affirms)
cos(q, k1) = 0.89     "TLS 1.0 and 1.1 are not supported"             ← RIGHT
cos(q, k6) = 0.54
cos(q, k5) = 0.47

Top-1 retrieval returns k2. The gap is 0.02 — noise. The retriever has effectively flipped a coin on the polarity of a security control. Worse, if you retrieve top-3 you hand the LLM both k2 and k1, which directly contradict each other, and the model must resolve a conflict it has no basis for resolving. Two failures are stacked here: negation insensitivity and recency blindness, since k2 is five years out of date.

The correction that works: retrieve with a metadata filter on status = current, which eliminates k2 before similarity is ever computed. Notice that this fixes the symptom by fixing the recency problem, not the negation problem — the negation problem is still there and would resurface if both polarities were current for different products. Reranking (07-07) is the correction that addresses polarity itself, because a cross-encoder reads the query and passage jointly and can register that not inverts the answer.

Query 2 — recency: "how long do I have to submit an expense claim?"

cos(q, k4) = 0.88     "within 90 days"     ← superseded 2019 policy
cos(q, k3) = 0.88     "within 30 days"     ← current 2026 policy

Identical scores. This is not an artefact of constructed numbers; it is the expected outcome, because the two passages are the same sentence with one number changed. The retriever has no preference and no way to form one. Three consequences:

1. Top-1 is arbitrary — determined by index insertion order, tie-breaking behaviour, or ANN graph traversal. It may even differ between runs, which makes the bug intermittent and therefore harder to believe (09-11 covers why "temperature 0" does not save you from non-determinism elsewhere either).
2. Top-2 delivers a contradiction. The LLM receives "90 days" and "30 days" and must choose. It has no dates, no version numbers, and no instruction about precedence unless you gave it some.
3. Your evaluation set may score this as correct. If the eval label is "retrieved a chunk about expense-claim windows", both chunks qualify. This is a case where a poorly specified retrieval metric conceals a total failure — an argument for labelling eval sets with the specific correct chunk id (01-08, 03-04).

The corrections, in order of effectiveness: do not index superseded documents at all (corpus curation, 06-04); if you must keep them, tag them and filter (06-03); if you must retrieve both, put the date in the chunk text so the model can see it and instruct the model to prefer the most recent (07-11).

That last one deserves emphasis because it is cheap and widely skipped: if a fact matters to the answer, it must be in the text the model reads, not only in a metadata field the model never sees. A date stored in a metadata column and not injected into the assembled context is invisible to the LLM (07-08).

Query 3 — authority: "why does my client certificate handshake keep failing?"

cos(q, k5) = 0.86     archived chat: "turned off cert verification"    ← WRONG and dangerous
cos(q, k6) = 0.72     official spec: "MUST abort … trust anchor"       ← RIGHT
cos(q, k1) = 0.44

The archived chat message wins by 0.14 — a decisive margin, not a coin flip. It wins because it is a first-person description of the same symptom in the same register as the query. The specification loses because specifications are written in a register no user's question ever matches.

The answer the LLM produces from k5 is fluent, on-topic, actionable, and tells the user to disable certificate verification. It is a security incident delivered by a working retrieval system.

Corrections, in order:

1. Trust tiers at ingestion. Tag each source authoritative | reference | community | archived, and rank or filter with the tag. This is the single highest-value intervention for mixed-provenance corpora.
2. Do not index what you would not cite. If you would not put an archived chat message in front of a customer as an answer, keeping it in the retrieval corpus is a decision to eventually do exactly that.
3. Reranking. A cross-encoder trained on relevance will often prefer the specification, because joint encoding lets it register that the spec actually answers the question while the chat message only shares the complaint.
4. Citation in the output (07-11). If every claim carries a source, a reader can see the answer came from an archived chat message. That does not prevent the error but it makes it survivable and auditable.

The purpose of this table is to stop the reflexive answer. "Add hybrid search" and "add reranking" are not general-purpose fixes, and mismatching a correction to a blind spot wastes a sprint.

Read the "no help at all" cells carefully. They are the exam-relevant ones, and they are where scenario distractors live. The dangerous instinct is to treat retrieval quality as one dial. It is at least four independent dials — lexical recall, semantic recall, metadata correctness, and generation discipline — and a symptom must be attributed to the right one before a fix is chosen. 07-10 makes that attribution a formal procedure.

A second reading of the same table: permissions is the only row where a partial fix is unacceptable. A recency miss produces a wrong answer; a permissions miss produces a data breach. This is why 07-05 insists the filter is applied inside the retrieval query rather than to the results afterwards.

This lesson serves the same objectives as the two before it — 1.3 and 4.2 (build RAG use cases), 1.4 (curate and embed content datasets for RAGs), 1.8 (select and use models to create text embeddings), 1.6 and 4.3 (vector databases) — but it serves them from the direction the exam most values.

The exam is calibrated to test recognising correct practice and correct tool choice rather than novel design [OFFICIAL] — the official job-role frame describes an associate who contributes under supervision, assessing and resolving performance issues. Scenario items of the form "the system returns an outdated policy / a wrong-polarity answer / an unverified community post — what should be added?" are precisely tool-choice questions, and they are unanswerable without knowing which correction addresses which blind spot.

There is one further reason to take this lesson seriously as exam preparation. Candidate reports converge on a heuristic that when one option proposes building a RAG solution, it is usually the keyed answer [FIELD]. That is field calibration, not official guidance, and this lesson is the corrective: RAG's blind spots are real, and an item describing a stale-data problem may well key to "filter by document date" rather than "add RAG" or "add hybrid search". Applying the heuristic without knowing the counter-cases is how a candidate loses the questions that separate a pass from a strong pass. 07-12 treats the counter-cases as its whole subject.

Question phrasings you should recognise:

Distractor families:

• "Use a larger / better embedding model." Offered as the fix for recency or authority. It cannot be, because neither is in the text.
• "Increase k." Retrieving more passages does not fix polarity or supersession; it usually worsens them by putting contradictory passages in the same context (07-08).
• "Add hybrid search" offered for recency, authority, or permissions. BM25 is blind to all three.
• "Lower the similarity threshold." The wrong passage scored high. Thresholds do not discriminate on the axis that failed.
• "Fine-tune the LLM." Changing the generator does not change what was retrieved (11-08 on the full decision rule).
• "Filter the results after retrieval" offered for permissions. For recency it is merely wasteful; for permissions it is a security defect, because the retrieval already read data the user may not see (07-05).

Mistake 8 is the sneakiest, and it is worth building a habit around. Put negation pairs and version pairs into your evaluation set deliberately. A handful of items where the correct answer is the negative statement, and a handful where the correct answer is the newer of two near-identical documents, will surface these failures immediately. An eval set assembled from naturally occurring questions tends not to contain them, which is exactly why they reach production.

Because polarity is carried by a low-information word inside a vector dominated by high-information words, and because the training objective actively resists separating them.

The mechanical part: not is one token among fifteen, and it is a token that appears in a large fraction of all English sentences, so the model has learned it as weak evidence about topic. The vector for "X is supported" and the vector for "X is not supported" differ by a small perturbation, while both differ enormously from a vector about anything else. Ranking by distance therefore ranks by topic, and polarity ends up in the noise.

The structural part is more interesting. To separate those two sentences in the embedding space, the model would need to learn that a one-word difference can imply maximal dissimilarity. But the same model must also learn that "the claim window is 30 days" and "expenses must be filed within a month" are highly similar despite sharing almost no words. Those two lessons pull in opposite directions. A model tuned to be maximally sensitive to small lexical differences loses the paraphrase robustness that is dense retrieval's entire reason for existing. This is a genuine trade-off in the objective, not a gap awaiting the next model release.

What actually works, in increasing order of cost:

Chunk so that polarity travels with its subject. If the supported and unsupported lists live in the same chunk, both are always retrieved together and the model can read the distinction. This is a chunking decision (06-02) that pays off as a retrieval property — a good illustration of why ingestion choices are retrieval-quality choices.

Rerank with a cross-encoder. Joint encoding lets the model attend to the query and passage together, and cross-encoders are meaningfully better at polarity than bi-encoders for exactly that reason. This is the best generally available correction and it is 07-07.

Make the generator responsible. Instruct the model to quote the sentence supporting its answer (07-11). A model forced to cite "TLS 1.0 is not supported" cannot easily produce an answer claiming the opposite, and a reader can catch it when it does.

Do not build the requirement on retrieval at all. If "which configurations are unsupported?" is a question your system must answer reliably, the answer is a maintained structured list — a table, a config file, a database query — not a passage to be found by similarity. This is the 07-12 reflex: sometimes the correct RAG design decision is not to use retrieval for that field.

With metadata, applied at three points, because each point catches what the others miss.

At ingestion — decide what enters the index. The cheapest possible recency fix is not indexing superseded documents. A corpus that contains only current content cannot return stale content, and no amount of clever ranking is as reliable as absence. Tag every chunk at ingestion with at least: source system, publication or effective date, version, status (current | superseded | draft | archived), and a trust tier. 06-03 is the lesson on what to embed versus what to store, and 08-01 on curation.

At retrieval — filter, then boost. Two distinct operations that are frequently confused:

Filters must be applied inside the retrieval query, not to its output. A post-filter over a top-10 list can return three results when you asked for ten, or zero, because the filter removed most of them — and the ANN index never went looking for the ten eligible nearest neighbours. 07-04 covers why filtered ANN search is harder than it sounds and 07-05 covers why post-filtering is unacceptable for authorisation.

At assembly — put the facts in the context. Metadata the model never sees cannot influence the answer. If recency governs, render the date into the passage header the model reads:

[SOURCE: Expense Policy v4 · effective 2026-01-15 · status: current]
Expense claims must be submitted within 30 days of the transaction date.

Then instruct the model: prefer the most recent effective date; if sources conflict, say so and cite both. That instruction is worth more than it looks, because a model that surfaces a conflict has converted a silent wrong answer into a visible one. 07-08 covers assembly and 07-11 covers grounding and citation.

The habit to build: for every non-semantic requirement, name where it is enforced. Recency — filter plus rendered date. Authority — trust tier plus rerank plus citation. Permissions — pre-filter, always, no exceptions. If a requirement has no named enforcement point, it is not enforced, whatever anyone believes.

No. They mean vector search is one component with a known specification, and building as though its specification were "understands my requirements" is the actual unreliability.

Frame it the way you would frame any component. BM25 matches strings; you would not blame it for missing a synonym. Dense retrieval matches meanings; blaming it for missing a date is the same error. NVIDIA's own description of the RAG pipeline is explicitly staged — query → embedding model → vector match against the indexed knowledge base → retrieve and decode → the LLM synthesises and cites sources [NVIDIA-DOC] — and a staged pipeline is one where each stage has a contract. The blind spots in this lesson are all cases where a requirement was assigned to a stage whose contract does not cover it.

Read positively, this lesson is a design checklist. Before shipping a retrieval system, answer these six questions:

1. Does any answer depend on logical polarity? If yes: chunk polarity together, rerank, and require quoted support.
2. Does any answer depend on which version governs? If yes: exclude superseded content, tag status, filter, and render dates into the context.
3. Does the corpus mix provenance tiers? If yes: tag trust, and either filter or rerank on it.
4. Do different users see different documents? If yes: pre-filter inside the retrieval query (07-05).
5. Have you measured lexical and semantic recall separately, against a baseline? If no: do that before adding anything (07-01, 03-04).
6. Does your eval set contain negation pairs and version pairs? If no: add them, because production will.

A team that can answer all six has a retrieval system with a specification. A team that cannot has a demo.

• Three structural blind spots: negation, recency, authority. None is fixed by a better embedding model, because the first is a trade-off in the training objective and the other two are metadata that were never in the text.
• A fourth, more severe one: authorisation. Similarity has no permission model. That is 07-05, and it is a security matter rather than a quality matter.
• Every blind spot produces a confidently wrong answer, not an empty result. The retrieved passage genuinely is highly similar; that is what makes it dangerous and what makes similarity thresholds useless as a defence.
• The worked example's headline result: two policy versions saying "90 days" and "30 days" scored identically at 0.88. The retriever had no basis for a preference, so top-1 was arbitrary and top-2 was a contradiction handed to the LLM.
• Hybrid search does not fix recency, authority, or permissions, because BM25 is equally blind to all three. Matching the correction to the blind spot is the actual skill.
• What does fix them: metadata at ingestion, filters and boosts inside the retrieval query, dates and sources rendered into the context, and reranking for polarity.
• Metadata the model never sees cannot change the answer. If a fact governs, put it in the text.
• Put negation pairs and version pairs in your evaluation set on purpose. Naturally collected questions rarely contain them, which is precisely why these failures reach production.

You now know what the vector can and cannot see, and you know that several fixes depend on filtering candidates by metadata before similarity is computed. That turns out to be a hard requirement to satisfy, because the index structures that make similarity search fast at scale — the approximate-nearest-neighbour graphs and inverted-file partitions — are not naturally cooperative with filters. Next: 07-04 covers vector databases, HNSW, and IVF: how approximate search trades recall for latency, why metadata filtering interacts badly with graph traversal, and the argument that a corpus of ten thousand chunks does not need a vector database at all — which is the most common piece of over-engineering in applied RAG.