RAG Failure Modes: How to Find the Real Bottleneck

A wrong RAG answer is rarely a model problem. It is a pipeline problem wearing a model costume.

The scene repeats in every team that ships retrieval-augmented generation. A user asks a question. The answer comes back incomplete, stale, or confidently unsupported. Someone says the model is weak. The model gets swapped. The same class of failure returns two weeks later, wearing a different question.

That loop is not a model problem. It is a diagnostic problem. The team is treating RAG as one system with one quality score, when it is actually a chain of stages, each with its own failure surface and its own ceiling. A defect in ingestion sets a ceiling that no retrieval tuning can raise. A defect in assembly destroys evidence that retrieval delivered perfectly. A defect in generation looks identical to a retrieval miss from the outside.

This article is a bottleneck-location procedure, not a fix catalog. The goal is to walk an answer through ingestion, retrieval, assembly, and generation, and stop at the first stage that fails its check.

Why End-to-End Scores Hide the Real Bottleneck

A single quality metric answers one question: did the system produce a good answer? It cannot answer the question you actually need: which stage produced the bad one.

This is not a minor measurement gap. A systematic taxonomy of RAG failure modes, published in the TrustNLP 2026 workshop proceedings, organizes 33 failure modes across seven pipeline stages and states plainly that single-stage evaluation metrics cannot detect diverse failure classes. The same work documents an asymmetry in research attention: retrieval and generation failures are comparatively well studied, while representation, evaluation, and agentic orchestration failures remain under-investigated despite frequent occurrence in production. Twelve of the catalogued failure modes have no dedicated peer-reviewed empirical evidence, and all eight agentic modes fall into that gap.

Grant the narrow case where end-to-end scoring works. If you have a stable task, a frozen test set, and you only need regression tracking or a coarse go/no-go gate, a single score is fine. It tells you whether the system moved. It does not tell you why.

The working model that replaces it: failures cascade downstream. Upstream defects create quality ceilings that no downstream fix can resolve. A generation-stage symptom — a hallucination, a partial answer, a fabricated citation — often has an ingestion or retrieval root cause. The taxonomy authors make this explicit in their diagnostic procedure: when end-to-end performance degrades, trace failures upstream to identify actual root causes rather than surface symptoms.

So the diagnostic handle for everything that follows is simple. Locate the limiting stage before changing anything. Not the model. Not the prompt. The stage.

Map the Pipeline Before You Debug It

You cannot isolate a stage you cannot observe. Before any measurement, you need a stage map with the artifact each stage emits, because the artifact is the debugging surface.

Stage	Artifact it emits
Ingestion and parsing	Parsed text, extracted tables, normalized documents
Representation	Chunk records, embeddings, index entries
Retrieval and ranking	Ranked candidate list with scores
Context assembly	The exact assembled prompt
Generation	The generated answer
Citation and attribution	Citation map linking claims to sources

If you cannot dump an artifact, you cannot isolate its stage. That is the whole rule.

This builds on two ideas covered elsewhere: RAG as a context-selection system, and observability traces as the mechanism that makes stage artifacts visible. I will not re-teach either here. The practical minimum is narrower than a full observability stack: log the retrieved candidate set with scores, the exact assembled context, and the final answer with citations, all keyed by request ID.

Skip that instrumentation and every debugging session becomes archaeology. You reconstruct what the system saw from memory, guesswork, and a prompt that has since changed. The cost of the missing log is not paid once. It is paid on every future failure.

Ingestion and Representation Failures Set the Ceiling

The most expensive failures happen before retrieval runs. The taxonomy classifies ingestion failures as corrupting or degrading the knowledge base before any retrieval or generation takes place, creating a performance ceiling that downstream components cannot overcome. That sentence is the entire argument for debugging upstream first.

The failure modes in this stage are unglamorous and decisive:

• Stale or outdated data. The index answers confidently from a superseded version of the truth.
• Missing document coverage. The answer does not exist in the knowledge base at all. Retrieval is not the failure; there was nothing to retrieve.
• Layout parsing errors. Tables, multi-column PDFs, and headers get flattened into text that no longer means what the source meant.
• Multimodality conversion loss. Figures, charts, and diagrams become captions or nothing.
• Tokenization fragmentation. Text splits in ways that break the units the model needs to reason over.
• Embedding drift or mismatch. The embedding model used at index time differs from the one used at query time, so vectors live in different spaces and similarity scores become noise.
• Chunking boundary errors. The answer spans two chunks and neither chunk alone is sufficient.

The diagnostic move is mechanical. Take a known-bad answer. Find the source passage that should have answered it. Check whether that passage exists in the index in a usable form.

The decision rule follows directly: if the correct evidence is absent or mangled in the index, stop tuning retrieval and fix ingestion first. Every hour spent on retrieval while the evidence is missing from the index is an hour spent raising the ceiling of a room with no floor.

Retrieval Failures: Missing, Misranked, or Misread

Retrieval failures get collapsed into one complaint — "it didn't find the right thing" — but there are at least three distinct classes, and each requires a different measurement and a different fix.

Missing content. The evidence is in the index but retrieval never returns it. This is a recall problem. The retrieval failure classification in a recent RAG engineering survey lists missing content as high impact and high severity, with low detection difficulty — meaning it is easy to catch once you look for it.

Poor ranking. The evidence is returned but buried below the cutoff. This is a precision-at-k and ordering problem. The same survey rates poor ranking as very high frequency, medium impact, and medium detection difficulty.

Query misinterpretation. The query embedding does not represent what the user actually asked. Vocabulary mismatch between user language and document language is the common case. The survey rates this medium frequency, high impact, and high detection difficulty — the hardest of the three to catch.

Three more retrieval-specific failure modes deserve names:

• Multi-hop gaps. The answer requires chaining two facts that no single query retrieves.
• Position-of-gold bias. The correct chunk is retrieved but placed where the model attends to it least.
• Domain embedding mismatch. A general-purpose embedding model underperforms on specialized vocabulary.

The measurements that separate these are not exotic. Recall@k against a labeled set tells you whether the evidence is reachable at all. The rank of the gold chunk tells you whether ordering is the problem. A query-rewrite ablation — rephrase the query, re-run retrieval, compare — tells you whether the query embedding is the bottleneck.

The decision rule: if recall@k is high but answers are still wrong, the bottleneck is downstream of retrieval. Stop rebuilding the index. The evidence is arriving. Something after retrieval is losing it.

Context Assembly: When the Right Evidence Still Loses

This is the stage most teams skip entirely — the transformation between a ranked list and the actual prompt. It is also where correct retrieval silently dies.

Context overflow. Retrieved evidence is truncated or dropped to fit the window, often cutting the one chunk that mattered. The engineering survey rates context overflow medium frequency, high impact, and low detection difficulty — it is easy to see once you compare the candidate set against the final prompt.

Ordering effects. Evidence placement changes what the model uses, independent of retrieval quality.

Conflicting evidence left unresolved. Two retrieved passages disagree and the model picks one without signaling the conflict. The taxonomy lists this as a generation-stage failure, but the assembly stage is where the conflict could have been flagged.

Distractor dilution. Irrelevant retrieved chunks crowd out relevant ones and shift the answer.

Redundancy. Near-duplicate chunks consume budget without adding information.

Compression and summarization steps that drop the specific number, date, or qualifier the question needed.

The diagnostic move here is the cleanest ablation in the whole pipeline. Freeze retrieval. Replay the same candidate set with different assembly policies — different ordering, different truncation, different compression — and compare answers. This isolates assembly from retrieval because retrieval is held constant.

The decision rule: if the gold chunk is in the candidate set but not in the final prompt, the bug is in assembly, not search. You already have the evidence. You are losing it on the way to the model.

Generation and Citation Failures

Now the stage everyone blames first. Some failures genuinely originate in the model. Others only look like they do.

Hallucination despite adequate context. The evidence was present and the model still produced unsupported content.

Incomplete or partial answers. The model used one retrieved passage and ignored the rest.

Incorrect specificity. The model answers at the wrong granularity — a general statement where a precise figure was required.

Wrong output format. Correct content, unusable structure for the downstream consumer.

Citation failures. Fabricated citations, citations pointing at the wrong span, or correct content with no traceable source.

There is a harder distinction worth holding. Some factual failures are recall failures, not encoding failures — the fact is encoded in the model's parameters but not surfaced during generation. Reporting on a study by researchers at Google Research and Technion describes frontier models encoding 95–98% of tested facts, with recall rather than encoding as the primary bottleneck in many cases, and recovery of a substantial fraction of facts through inference-time computation such as chain-of-thought. Treat this as a research signal, not a settled production rule. It suggests that retrieval is not always the right remedy for a factual failure, but it does not yet tell you which failures in your system fall into that category.

The diagnostic move for generation is the mirror image of the assembly ablation. Re-run generation with the gold context injected directly. If the answer is still wrong, the bottleneck is generation, not retrieval. You have removed every upstream variable.

The decision rule: a generation-stage symptom with clean retrieval and clean assembly points at the model, the prompt contract, or the decoding settings. Those are three different suspects, and they are the only ones left standing.

Choosing Measurements That Actually Isolate a Stage

The stage map tells you where to look. Measurement tells you what you found. The asset that makes every measurement possible is a small labeled set of real failing queries, each paired with the known correct source passage.

With that set, stage-local metrics become available:

• Index coverage checks — does the correct passage exist in the index in usable form?
• Recall@k and gold-chunk rank — is the evidence reachable, and where does it land?
• Assembly inclusion rate — did the gold chunk survive into the final prompt?
• Faithfulness and answer correctness on frozen context — with retrieval and assembly held constant, does generation use what it was given?

The ablation ladder is the cheapest way to find the limiting stage. Hold everything constant, change one stage, observe whether the answer changes. Freeze retrieval, vary assembly. Freeze assembly, inject gold context. Each rung isolates one variable.

One failure mode deserves its own name: metric inadequacy. The taxonomy lists it explicitly. A metric that passes while users complain is a measurement defect, not a quality win. When your dashboard is green and your users are unhappy, the dashboard is wrong.

Continuous monitoring is not the same as one-time evaluation. Production drift, index staleness, and query distribution shift will not show up in a frozen test set. The taxonomy separates evaluation failures from deployment and operations failures for exactly this reason.

State the evidence limits plainly. Some failure classes — particularly representation, evaluation, and agentic orchestration — have thinner peer-reviewed empirical grounding than retrieval and generation. Mitigations there are defensive engineering, not settled practice. The taxonomy authors note that all eight agentic failure modes fall into what they call an evidence desert.

The decision rule for measurement selection: pick the measurement that can falsify your current hypothesis about the bottleneck, not the measurement that is easiest to compute.

A Diagnostic Order of Operations

Compress everything above into a procedure you can run on the next bad answer.

1. Confirm the evidence exists in the index. Find the source passage that should have answered the question. Check it is present and usable.
2. Confirm retrieval returns it. Check recall@k and the rank of the gold chunk.
3. Confirm assembly includes it. Compare the candidate set against the final prompt.
4. Examine generation. Inject gold context and re-run.

Stop at the first stage that fails its check. Later stages cannot be diagnosed while an earlier ceiling is in place. Debugging generation while the evidence is missing from the index is measuring the wrong room.

Keep the failing query as a permanent regression case. One well-chosen failure is worth more than a large unlabeled test set, because it comes with a known correct answer and a known correct source. That is what makes the next diagnosis cheap instead of a fresh investigation.

What to build next: a stage-artifact dump keyed by request ID, a small labeled failure set, and an ablation harness that can replay a frozen candidate set. Those three assets turn every future failure into a bounded question rather than an open-ended hunt.

This connects to the wider learning path in three places. Observability traces and evaluation layers are the infrastructure that makes stage artifacts visible. Context engineering treats the prompt as a constrained resource, which is exactly the frame assembly failures demand. And long-context models are a partial substitute for retrieval, not a replacement — a larger window raises the ceiling on how much evidence you can carry, but it does not fix evidence that was never indexed correctly or never retrieved at all.

The watchpoint: as agentic and multi-step RAG architectures spread, the failure surface moves into orchestration — coordination, control flow, and multi-step state. That is where the empirical evidence base is currently thinnest. Expect to debug coordination and control flow, not just retrieval.

When a RAG answer is wrong, do not start by changing the model or the prompt. Walk the pipeline in order and stop at the first stage that fails its check. The durable asset is not a better prompt. It is a labeled failure set plus stage artifacts you can replay. That is what turns each future failure into a cheap diagnosis instead of a fresh investigation.