Context Recall is a retrieval evaluation metric that measures the completeness of your RAG pipeline’s retrieval step. While Context Precision asks “are the retrieved chunks relevant?”, Context Recall asks the complementary question: “did the retriever find all the information needed to produce a correct answer?”
This metric is critical because a retriever can achieve perfect precision by returning a single highly-relevant chunk — but if the query requires information spread across multiple documents, that single chunk won’t be enough. Context Recall catches this failure mode by comparing what was retrieved against what was actually needed (as defined by a ground-truth reference answer).
In the RAGAS framework, Context Recall operates on the retriever side of the evaluation pipeline. Combined with Context Precision, it provides a complete diagnostic: precision tells you about signal-to-noise ratio in retrieved chunks, recall tells you about information coverage. A production RAG system needs both to be high — missing either one leads to degraded answer quality in different ways.
Context Recall is computed by decomposing the ground-truth answer into individual claims, then checking how many of those claims are supported by the retrieved context:
Context Recall = |Ground Truth Claims Attributable to Retrieved Context| / |Total Claims in Ground Truth|
Values range from 0 (no ground-truth claims found in context) to 1 (all ground-truth claims are covered by retrieved chunks).
The evaluation proceeds in two LLM-driven steps:
Consider evaluating a query about machine learning regularization:
Question: "What are the main types of regularization in ML?"
Ground Truth: "The main types are L1 (Lasso) which promotes
sparsity, L2 (Ridge) which prevents large weights, Dropout
which randomly deactivates neurons, and Early Stopping which
halts training when validation loss increases."
Extracted Claims:
1. L1 regularization is also called Lasso
2. L1 promotes sparsity
3. L2 regularization is also called Ridge
4. L2 prevents large weights
5. Dropout randomly deactivates neurons
6. Early Stopping halts training when validation
loss increases
Retrieved Context covers claims 1, 2, 3, 4 (from a chunk
about L1/L2) and claim 5 (from a chunk about dropout).
Claim 6 about Early Stopping is NOT in any retrieved chunk.
Context Recall = 5/6 = 0.833This tells you that the retriever found most of the needed information but missed a chunk about Early Stopping. You now have an actionable diagnosis: either the Early Stopping content doesn’t exist in your knowledge base, or it exists but wasn’t retrieved (suggesting an embedding or indexing issue).
RAGAS provides several implementations to fit different evaluation scenarios:
from ragas import evaluate
from ragas.metrics import context_recall
from datasets import Dataset
eval_data = Dataset.from_dict({
"question": [
"What are the benefits of microservices architecture?"
],
"contexts": [
[
"Microservices enable independent deployment of services.",
"Each microservice can be scaled independently.",
"Teams can use different tech stacks per service."
]
],
"ground_truth": [
"Microservices enable independent deployment, independent "
"scaling, technology diversity per service, and fault "
"isolation where failures in one service don't cascade."
]
})
result = evaluate(eval_data, metrics=[context_recall])
print(result)
# {'context_recall': 0.75}
# 3 of 4 ground-truth claims covered; fault isolation missingUnlike some other metrics, Context Recall fundamentally requires a reference answer. Without knowing what the “correct” answer contains, there’s no way to determine whether the retriever found all necessary information. This requirement has practical implications:
TestsetGenerator) can synthesize these from your corpusLow Context Recall on specific query types often reveals gaps in your knowledge base. If queries about “return policies” consistently score below 0.5 on recall, the most likely explanation is that your knowledge base lacks comprehensive return policy documentation — not that the retriever is broken. Context Recall helps you distinguish between “the information isn’t there” and “the information is there but not being found.”
Context Recall is highly sensitive to chunking strategy. If your chunks are too small, a single claim might be split across two chunks and neither chunk alone supports it. If chunks are too large, relevant chunks may fall below the similarity threshold because the relevant passage is diluted by surrounding text. By measuring Context Recall across different chunking configurations, you can find the optimal balance:
In practice, there’s always a tension between Context Precision and Context Recall. Retrieving more chunks (higher K) tends to improve recall but degrades precision. The optimal K depends on your use case:
Context Recall is especially valuable for multi-hop queries that require synthesizing information from multiple documents. For example, “Compare the pricing tiers of Product A and Product B” requires retrieving information about both products. Context Recall will clearly show when the retriever only finds information about one product, even if that information is perfectly precise.
Teams running Context Recall in CI/CD pipelines typically set a minimum threshold (e.g., 0.8) on a standardized evaluation set. When a code change — new embedding model, changed chunking strategy, updated index — causes Context Recall to drop below the threshold, the pipeline fails and prevents the degradation from reaching production.