Context Precision vs Recall Explained - Diagnosing RAG Retrieval in 2026

When a RAG answer is bad, the first fork in the diagnosis is always the same - was it the retriever or the generator? Context precision and context recall are the two metrics that answer the retriever half of that question, and they do it by measuring opposite failures. Confuse them and you will tune the wrong knob.

This guide explains how each score is computed, runs both on the same retrieval so you can see them diverge, and shows how to read them together to know exactly what to fix.

The two metrics in one line

Context precision punishes noise. Context recall punishes gaps. That is the whole distinction, and everything else follows from it.

• Precision - of the chunks you retrieved, how many were relevant, and did the relevant ones rank near the top?
• Recall - of the relevant chunks that exist, how many did you actually retrieve?

Both judge the retrieval step only - they say nothing about whether the model then used the context well. That generation question is faithfulness, a separate metric. Keep the two stages apart and each failure points at a specific fix.

Context precision - how it is computed

After your system retrieves a set of chunks for a query, a judge marks each chunk as relevant or not relevant to the question. Context precision is the fraction that are relevant, weighted so that relevant chunks ranked near the top score higher than relevant chunks buried at the bottom.

That ranking weight matters. Two retrievers can pull the same relevant chunk, but the one that ranks it first scores better than the one that ranks it eighth behind seven junk passages - because the model reads the top of the context window most reliably, and every junk chunk is tokens you pay for on every request. See the context precision glossary entry for the underlying definition.

Low precision means your retriever is over-fetching noise. The fix lives in the retriever - a reranker, tighter chunk boundaries, or a lower top-k - not in the prompt.

Context recall - how it is computed

Recall flips the question. Given the set of relevant chunks or facts that should be retrieved to answer the query, context recall is the fraction the retriever actually pulled.

The practical difference from precision - recall usually needs a reference. You need to know what the complete set of relevant information is, either from a ground-truth answer or a labeled set of relevant chunks, so you can measure what was missed. That makes recall an offline-eval metric more often than a live-production one, whereas precision can sometimes be judged reference-free.

Low recall means your retriever is missing information the answer needs. No prompt engineering rescues an answer whose evidence never made it into the context window. The fix is again in the retriever - more retrieval, better embeddings, or smarter chunking.

A worked example

A query needs three facts to answer fully - call them A, B, and C. Your retriever returns four chunks in this order - [A, junk, junk, B]. Fact C is never retrieved.

Metric	Reasoning	Score
Precision	2 of 4 retrieved chunks (A, B) are relevant, and A ranked first but B ranked last behind two junk chunks	moderate - noise and poor ranking drag it down
Recall	2 of the 3 needed facts (A, B) were retrieved; C was missed	0.67

Read together, the diagnosis is specific - the retriever is both over-fetching junk (precision hit) and missing fact C (recall hit). You would add a reranker to clear the junk and lift B’s rank, and widen retrieval or fix chunking so C gets pulled. One number would have hidden all of that.

Reading the two scores together

This is where the pair earns its keep. The combination of high or low on each tells you which way the retriever is failing.

Precision	Recall	Diagnosis	Fix
Low	High	Over-fetching - you pull everything relevant plus noise	Add a reranker, lower top-k, tighten chunks
High	Low	Too conservative - clean but missing context	Raise top-k, improve embeddings, refine chunking
Low	Low	Retriever is broken for this query type	Rework embeddings and chunking together
High	High	Retrieval is healthy - look at generation next	Check faithfulness and answer relevancy

The rule - if precision is low, retrieve more selectively; if recall is low, retrieve more. A reranking step is the most common single fix because it lifts precision without giving up much recall. Whatever you change, re-measure both, because tuning one usually moves the other. These two sit alongside faithfulness in the RAG triad, and the full metric set is in RAG evaluation metrics explained.

Common mistakes

• Optimizing recall alone. Cranking top-k to catch everything tanks precision, floods the context with noise, and inflates token cost. Balance the two.
• Judging retrieval by the final answer. A good answer can mask poor retrieval if the model guessed well, and a bad answer can come from good retrieval the model ignored. Measure retrieval directly.
• Skipping the reference for recall. Without a labeled set of what should have been retrieved, you cannot compute true recall - you can only estimate it. Build a small eval dataset with known-relevant chunks.
• Forgetting to log chunk IDs. Log which chunks were retrieved alongside each answer. When precision drops, you can read exactly which passages the retriever wrongly promoted.

Where the tools fit

You do not compute these by hand. DeepEval implements contextual precision and recall as standard RAG metrics you run over a labeled dataset with deepeval test run, inside its free Apache-2.0 framework - watch the judge-call cost, since nearly every metric is LLM-as-judge. Braintrust lets you track retrieval scorers across experiments, so you can see whether a new embedding model or chunk size actually improved precision or recall before you ship it - just keep an eye on its processed-data billing meter, which large RAG contexts burn fastest. Arize Phoenix ships the deepest RAG evaluation in the category and runs locally in under a minute, which makes it the fastest way to eyeball retrieval quality on real traces.

Bottom line - precision and recall are two halves of retrieval quality, and you need both. Precision tells you if you are pulling noise, recall tells you if you are missing evidence, and the four-quadrant read tells you exactly which retriever knob to turn. Measure them separately from generation, re-measure after every change, and you will stop guessing at whether the retriever or the prompt is at fault. For the platforms side by side, see best RAG evaluation tools, and for the end-to-end workflow, how to evaluate RAG.