Why does RAG return wrong or irrelevant results?

RAG often fails before generation because retrieval missed the right evidence, ranked weak evidence too high, used stale indexes, or hid the trace needed to debug the miss.

What should I inspect first when RAG is wrong?

Inspect the retrieval query, candidate chunks, ranks, source scope, index currency, reranker output, and final citations before changing the prompt.

How many retrieval failure modes should I check?

Start with seven: chunk boundary breakage, embedding mismatch, query drift, missing reranking, stale index, ACL noise, and no inspectability.

RAG Returns Wrong or Irrelevant Results: 7 Retrieval Failure Modes to Inspect

Q: Does Answer Engine have a live inspector screenshot for these modes?

No. The full inspector is roadmap-labeled until product C.2; this guide describes the trace fields to inspect and does not fabricate screenshots.

If RAG returns wrong or irrelevant results, inspect retrieval before rewriting prompts. The quotable triage hook is: “~70% of failures are retrieval” is a useful first-pass rule, not an Answer Engine benchmark claim. Start with the candidate chunks, ranks, source scope, index currency, and trace visibility.

Last updated: June 20, 2026.

Why should you inspect retrieval first?

Inspect retrieval first because the generator can only answer from the evidence it receives. If the right source never appears, the model will guess, overfit to weak context, or cite irrelevant material with confidence.

An ICLR 2026 paper on LLM-agent memory found that failures most often manifested at the retrieval stage rather than utilization, and that retrieval method drove the largest differences across its tested memory-agent configurations (Diagnosing Retrieval vs. Utilization Bottlenecks). Treat the “~70% of failures are retrieval” line as a troubleshooting heuristic from this retrieval-dominant pattern, not as a universal product metric.

Other 2026 RAG work lands in the same neighborhood. A financial QA study decomposes retrieval misses by document, page, and chunk level, showing how a system can retrieve the right filing but miss the exact page or chunk needed for the answer (Decomposing Retrieval Failures in RAG). A graph-perspective RAG paper studies why retrieved evidence may still fail to influence the answer path (Why Retrieval-Augmented Generation Fails).

What are the 7 retrieval failure modes?

Use this table as the diagnostic checklist. It intentionally lists exactly seven modes.

ID	Failure mode	Symptom	Root cause	How to inspect	Fix
FM-1	Chunk boundary breakage	The answer is one sentence away from the retrieved chunk.	Chunking split the fact, definition, or table away from its qualifier.	Open the source around each returned chunk and inspect neighboring text, headings, and table rows.	Re-chunk by semantic section, preserve headings, and add parent-document expansion.
FM-2	Embedding mismatch	Semantically close but wrong chunks outrank exact evidence.	The embedding model or indexing text does not match the query domain, vocabulary, or entity style.	Compare semantic top-k against full-text or hybrid results for the same query.	Use hybrid retrieval, domain-specific query expansion, or a better embedding/indexing strategy.
FM-3	Query drift	The retrieval query searches for the model’s interpretation instead of the user’s actual need.	The agent rewrote the query too broadly, dropped constraints, or chased a subquestion.	Log the raw user query, rewritten query, filters, and retrieved candidates side by side.	Constrain query rewriting and preserve hard filters such as product, date, customer, or source type.
FM-4	Missing reranking	Good evidence appears in candidates but loses to weaker chunks.	First-stage retrieval returns a noisy pool and no reranker evaluates answer fitness.	Inspect candidate ranks before and after reranking; if there is no second list, reranking is missing.	Add reranking over a larger candidate pool and log why the final top items won.
FM-5	Stale index	The agent cites an old policy, endpoint, or price after the source changed.	The index did not re-ingest changed content or lacks current-state metadata.	Compare source modified time, indexed time, content hash, and supersession status.	Add incremental re-indexing, source versioning, and supersession-aware retrieval.
FM-6	ACL noise	Results include documents the user should not see or omit documents they can access.	Permissions were applied after retrieval, copied incompletely, or not represented in vector metadata.	Inspect tenant, workspace, library, source ACL, and user scope on every candidate.	Enforce scope and ACL filters before retrieval, then audit post-filtered misses.
FM-7	No inspectability	Nobody can explain why this result appeared.	The system logs only the final answer, not the retrieval path.	Require a trace containing query, candidates, ranks, filters, source ids, and citations.	Add visible retrieval traces and correction hooks before scaling the workflow.

Labeled product placeholder: the full Answer Engine inspector for this failure-mode workflow is roadmap work under product C.2. This guide describes the trace fields to inspect and does not include fabricated inspector screenshots.

How do you inspect chunk boundary breakage?

Chunk boundary breakage happens when the relevant fact is adjacent to the retrieved chunk but not inside it. This is common with tables, policy exceptions, API docs, and legal or financial text where the qualifier is as important as the main sentence.

Inspect the source before and after the returned span. If the answer requires the previous heading, next table row, or a footnote, the retrieval system needs parent expansion or better chunking. The financial QA paper is useful here because it separates retrieval at document, page, and chunk granularity rather than treating “found the document” as enough (Decomposing Retrieval Failures in RAG).

How do you inspect embedding mismatch?

Embedding mismatch appears when vector search returns material that feels thematically similar but operationally wrong. Exact entity names, product SKUs, internal abbreviations, error codes, and policy labels are common casualties.

Run the same query three ways: semantic, full-text, and hybrid. If full-text finds the exact policy while semantic finds a conceptually nearby doc, the embedding path is under-specified for this domain. If semantic finds useful paraphrases but misses exact IDs, hybrid retrieval is usually the safer default.

How do you inspect query drift?

Query drift starts before retrieval. The agent rewrites the user’s question, drops a constraint, or turns a precise request into a broad topic search.

Log the raw user question, rewritten search query, filters, and final candidate list. If the user asked “current onboarding policy for contractors” and the retrieval query became “onboarding policy,” the miss is not a vector database mystery. It is a query-planning bug. Preserve hard constraints as filters whenever possible.

How do you inspect missing reranking?

Missing reranking is visible when the right evidence is in the candidate pool but not in the final context. First-stage retrieval is usually optimized for broad recall; it is not always the best final judge of answer usefulness.

The agent-memory diagnostic paper compared retrieval methods and found retrieval quality was the dominant bottleneck in its study (Diagnosing Retrieval vs. Utilization Bottlenecks). In production debugging, the practical question is simpler: can you see candidate ranks before and after reranking? If not, you cannot tell whether the right evidence was found and then lost.

How do you inspect stale indexes?

A stale index returns old content because the index is behind the source or because the source changed without a replacement signal. This is the RAG cousin of stale agent memory.

Inspect source_updated_at, indexed_at, content hash, source version, and supersession state. If the source changed after the chunk was embedded, the result should be marked suspect. OwlerLite’s freshness-aware retrieval paper centers changed-page monitoring and selective re-indexing because static indexes can mix stale and current content (OwlerLite).

For changed facts, connect this to Supersession-Aware Memory: the retrieval layer should know whether a newer artifact replaced an older one.

How do you inspect ACL noise?

ACL noise is a security and relevance problem. If retrieval sees documents outside the user’s scope, the model may answer from evidence the user should not access. If permissions are filtered only after retrieval, the final candidate pool may become empty or biased.

Inspect every candidate’s tenant, workspace, library, source-system ACL, and user scope. The Agent Memory guide lists tenant isolation as a core trust requirement because memory that crosses scope boundaries is not trustworthy memory.

The fix is architectural: apply scope and ACL filters before retrieval, not only at display time. Then log post-filtered candidates so you can distinguish “no relevant docs exist” from “relevant docs were removed by permission filters.”

How do you inspect a system with no inspectability?

If the system cannot show query, candidates, ranks, filters, source ids, and citations, it cannot be debugged reliably. You may still improve it by guessing, but you cannot prove which stage failed.

The Model Context Protocol architecture includes logging as a client-side primitive and describes servers that expose tools and resources to AI applications (MCP architecture). A memory or retrieval server should use that boundary to return more than answer text. It should expose traceable tool results that a product, log pipeline, or human can inspect.

The minimum trace should include:

raw user query;
rewritten retrieval query;
source and permission filters;
candidate ids, titles, ranks, and scores;
selected citations;
current or superseded status;
final answer references.

That is the core of Inspectable Agent Memory: the user can see what was remembered or retrieved and why.

What is the fastest diagnostic sequence?

Run this sequence before changing prompts:

Replay the question with retrieval logging enabled.
Confirm the right source exists in the indexed library.
Check whether the source is current.
Compare semantic, full-text, and hybrid candidate pools.
Inspect rewritten query and filters.
Check reranker output, if present.
Compare final citations to the answer text.

If the right source never appears, fix retrieval. If the right source appears but loses ranking, fix reranking. If the right source appears and is cited but the answer is wrong, then inspect generation and grounding.