Context Recall

The Context Precision article covered whether retrieved chunks were actually relevant. This final article in the phase covers the necessary, complementary question: did retrieval find everything relevant that actually existed? That’s context recall.

The simple definition

Context recall measures what proportion of all the genuinely relevant information available in the knowledge base actually made it into the retrieved chunks, rather than being missed entirely. Recall from the Recall article, back in the Evaluation Basics phase — the fraction of actual positives a model successfully caught, as opposed to precision’s focus on the fraction of predictions that were correct. Context recall is that same foundational concept, applied specifically to a RAG system’s retrieval step, completing the precision-and-recall pair this entire phase has been building toward.

Why a retriever can have perfect context precision and still fail badly

This is worth being direct about, since it’s the exact scenario context precision alone can’t catch. Recall from the Context Precision article’s core measurement — the proportion of retrieved chunks that were relevant. A retriever that returns only two chunks, both of them genuinely, perfectly relevant, would score a flawless 100% on context precision — even if the knowledge base actually contained six other equally relevant chunks that were never retrieved at all. Context recall is the metric built specifically to catch this exact, real failure mode: technically precise, but incomplete.

flowchart LR
    A[Knowledge base contains 8 genuinely relevant chunks total] --> B[Retrieval returns only 2 of them]
    B --> C[Context Precision: 100% — both retrieved chunks were relevant]
    B --> D[Context Recall: 25% — 6 of 8 relevant chunks were missed entirely]

Why this specific gap matters so much for real answer quality

Recall directly from the Faithfulness and Answer Correctness articles’ shared concern — a response can only be as complete and accurate as the material it was actually given to work with. A RAG system with strong context precision but weak context recall will confidently, faithfully answer using the two relevant chunks it did find, while genuinely, silently missing the other six pieces of relevant information that would have made the answer meaningfully more complete or accurate — a real, harder-to-detect failure than an obviously wrong answer, since the response that results can look perfectly polished and well-supported.

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of a research assistant asked to gather all relevant precedent cases for a legal argument, who returns two genuinely relevant, well-chosen cases — technically flawless work on those two — while never mentioning the other six equally relevant cases sitting in the same case library, simply because the search never surfaced them.

Where this breaks down: A human research assistant’s search process involves conscious, adaptable judgment about where else to look. Context recall, as calculated in real evaluation frameworks like RAGAS, is measured mechanically — typically by comparing retrieved chunks against a pre-established, human- or expert-verified list of everything that should have been retrievable for a given test question, a precise comparison against a known, complete answer key rather than a researcher’s adaptive judgment.

A concrete example, layered

For a simple beginner example: evaluating a company’s internal-policy retriever against the test question “what are all the steps for requesting parental leave,” a knowledge base containing five separate, relevant policy paragraphs but a retriever surfacing only two of them would show low context recall, meaning a generated answer built from that retrieval would very likely omit real, important steps, even though the two chunks it did find were entirely accurate.

For a production example: teams building evaluation datasets specifically for RAG systems, echoing the Evaluation Dataset article’s core practice, commonly annotate each test question with a complete, expert-verified list of every chunk that should ideally be retrieved, specifically to make context recall measurable at all — without that reference list, there’s no way to know what retrieval actually missed.

Why context precision and context recall together, not separately, tell the real story

It’s worth being direct about this closing insight, tying together the last two articles of this phase. A retriever can score well on one while failing the other — narrow and precise but incomplete, or broad and complete but full of irrelevant noise — and only tracking both together gives a genuinely diagnostic picture: low precision points toward tightening retrieval (better reranking, smaller chunk sizes), while low recall points toward widening it (retrieving more chunks, improving the underlying embeddings or knowledge base coverage).

Common misconception

Retrieval has a knowledge-base ceiling

Suppose the verified answer needs three facts, but the knowledge base contains only two:

fact A -> present in knowledge base -> retrievable
fact B -> present in knowledge base -> retrievable
fact C -> absent from knowledge base  -> impossible to retrieve

No embedding model, query rewrite, or larger top-k can retrieve fact C from a collection that does not contain it. The team must fix ingestion, source coverage, permissions, or document freshness.

The denominator can also be wrong

Context Recall uses expected facts as its denominator. If the reference answer omits a required fact, recall may look perfect even though the retrieved context is incomplete. If the reference includes a false or unnecessary fact, recall may be unfairly low.

Have experts review required claims, store their sources and dates, and allow evaluation cases to be marked ambiguous.

Diagnose the whole path

source coverage -> ingestion -> chunking -> indexing -> query -> retrieval -> reranking

Low Context Recall can originate anywhere along this path. A GPT-, Gemini-, or Claude-based generator cannot reliably repair missing evidence by guessing; that would trade a retrieval failure for a hallucination risk.

Calculate recall from required facts

The verified reference requires two facts:

Returns are allowed for 30 days.
The customer pays return shipping.

Suppose the retrieved chunks contain the 30-day rule but nothing about shipping:

context recall = 1 supported required fact / 2 required facts = 0.50

Retrieving ten copies of the 30-day rule does not recover the missing shipping fact. Recall is about covering the needed information, not collecting more text.

What the metric needs

reference answer or required claims + retrieved chunks
                                      -> context recall

This makes context recall harder to measure than simple precision when no reliable reference exists. Teams may use human-written required claims or an evaluator model, then manually inspect a sample of the judgments.

Diagnose precision and recall together

Result	Likely retrieval behavior
High precision, high recall	Mostly useful chunks and required facts are covered
High precision, low recall	Retrieved text is useful but incomplete
Low precision, high recall	Required facts are present among much distracting text
Low precision, low recall	Retrieval is noisy and incomplete

Real RAG application

A GPT-, Gemini-, or Claude-based assistant can generate an incorrect answer because its retriever never supplied one required fact. Changing the prompt cannot reliably recover information absent from the context. Engineers may need query rewriting, hybrid retrieval, a larger search scope, or better source coverage.

Ragas provides context-recall metrics for evaluating this retrieval coverage across a dataset.

Verified sources

A frequent beginner assumption: that a RAG system performing well on context precision has, by extension, “solved” retrieval quality overall. As this article’s parallel-cases example directly demonstrated, this isn’t reliable at all — a retriever can be flawlessly precise about the small handful of chunks it does return while still missing the majority of genuinely relevant material sitting untouched in the knowledge base, a real, serious gap precision alone will never reveal.

Closing out this phase

This article completes the LLM/RAG Evaluation phase, and it’s worth tracing the full arc it built: LLM Evaluation named the broad discipline, split between Human Evaluation’s genuine but costly gold standard and Automated Evaluation’s faster, scalable alternative — vulnerable, as OpenAI’s own public admissions showed, to real benchmark contamination in the Evaluation Dataset underneath it. LLM-as-a-Judge offered a more flexible automated technique, with its own real, documented biases.

Faithfulness and Answer Correctness together captured factual quality from two genuinely separate angles, while Toxicity and Relevance covered safety and on-topic quality respectively. Context Precision and Context Recall close the phase exactly where the RAG & Retrieval phase’s own Retrieval Evaluation article first promised they would — giving that earlier phase’s diagnostic principle its full, precise, RAGAS-computed form.

In one sentence

Context recall measures what proportion of all genuinely relevant information in the knowledge base actually made it into retrieval, catching the real, serious failure mode context precision alone can’t — a retriever being flawlessly accurate about a small, incomplete set of chunks while silently missing the rest — and together, precision and recall give the complete, genuinely diagnostic picture this entire phase has built toward.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026