CLOUD CONCEPT

Recall@k

Recall@k measures the fraction of all known relevant items that a retrieval system returns within its first k results.

Cloud Concepts Hub →

What is Recall@k

Recall@k evaluates whether a search or retrieval pipeline finds the evidence needed for a query within a limited result budget. In retrieval-augmented generation (RAG), it helps engineers detect missing context, compare retrieval configurations, and balance evidence coverage against latency and context-window cost.

Recall@k is a retrieval quality metric calculated as the number of relevant items in the first k results divided by the total number of relevant items for that query. If a labeled evaluation set identifies five relevant passages and the first ten retrieved results contain three of them, Recall@10 is 3/5, or 0.60. The denominator is the relevant set, not the number of returned results; dividing by the number of returned results measures precision instead.

In a cloud-hosted RAG application, retrieval supplies evidence to a foundation model before it generates an answer. Low recall means useful evidence is missing from the retrieved context, even if the model produces a fluent response. For example, a support assistant answering a question about account recovery might retrieve the general procedure but miss a separate policy covering locked administrator accounts. Increasing model size or changing the answer prompt does not reliably correct that retrieval failure.

Build an evaluation dataset containing representative queries and relevance judgments for documents or passages. Define the evaluation unit explicitly: document-level recall and chunk-level recall answer different questions. Use stable identifiers, version the corpus and judgments, and avoid giving duplicate or overlapping chunks credit for repeatedly retrieving the same evidence. Relevant items should also reflect the query's intended authorization and filtering scope. Queries with no relevant items have an undefined recall denominator; handle them separately when evaluating correct abstention or empty-result behavior.

Run the same queries against candidate configurations and calculate Recall@k for each query. A common aggregate is the mean across queries, which gives each query equal weight. Also examine results by language, topic, tenant, document age, and query difficulty, because an overall average can conceal severe failures in smaller groups. When relevance judgments are incomplete, the score measures recovery of known relevant items rather than guaranteed coverage of every useful item in the corpus.

For a fixed ranked result sequence, increasing k cannot decrease recall, but it can reduce precision and increase retrieval, reranking, and generation costs. More context can also distract the generator or exceed its input budget. Measure recall both before reranking and on the final context passed to the model: a large candidate pool may have good coverage while a later reranker or token-budget truncation removes essential evidence. Recall@k does not distinguish where relevant items appear within the first k positions, so complement it with ranking metrics such as nDCG or mean reciprocal rank.

When recall declines, trace failures through ingestion, preprocessing, chunking, embedding generation, indexing, filtering, and search. Check whether documents were indexed successfully, whether chunk boundaries separated questions from their answers, and whether query and document embeddings use compatible models and preprocessing. Confirm vector dimensions and the distance metric expected by the embedding model. Then investigate overly restrictive metadata filters, stale indexes, and approximate nearest-neighbor search settings. Compare approximate results with an exact vector search baseline to isolate search approximation losses; recovering exact nearest neighbors is not the same as retrieving semantically relevant evidence.

Production monitoring should combine periodic labeled retrieval tests with sampled relevance reviews, latency percentiles, empty-result rates, and index freshness indicators. Track changes in query distribution and embedding behavior to investigate drift. Similarity scores and model response relevance are useful diagnostics, but neither is a substitute for Recall@k against relevance judgments. Validate that retrieved passages actually support the requested facts, and evaluate answer correctness and faithfulness separately. Promote retrieval changes only after checking evidence coverage, response quality, latency, and cost together.

Key aspects of Recall@k

Recall@k provides a labeled measure of evidence coverage that supports retrieval tuning, stage-by-stage troubleshooting, and ongoing quality monitoring.

Coverage within a result budget

Recall@k measures how much of the known relevant set appears among the first k results. Choose k to reflect a real retrieval or context-selection budget, and compare configurations at the same cutoff.

Explicit relevance ground truth

The metric requires query-specific relevance judgments and a defined evaluation unit, such as documents or chunks. Version the labels and corpus together, and define how duplicates, access restrictions, and queries without relevant results are handled.

Stage-specific evaluation

Measure coverage at candidate retrieval, after reranking, and after final context selection. This identifies whether evidence was never found or was discarded later in the pipeline.

Recall, precision, and latency trade-offs

A larger result set can recover more evidence while introducing irrelevant context and additional processing cost. Select retrieval depth using recall, precision, latency percentiles, and downstream answer quality rather than recall alone.

Retrieval failure diagnosis

Use missed relevant items to investigate ingestion gaps, poor chunking, incompatible embeddings, restrictive filters, and approximate search losses. Separate relevance-based recall from approximate nearest-neighbor recall against exact search results.

Regression and drift monitoring

Run a versioned query suite after retrieval changes and periodically during production operation. Segment results to expose failures hidden by averages, and refresh judgments as the corpus and user questions evolve.

Cloud services for Recall@k

A retrieval application can use Amazon Bedrock Knowledge Bases backed by a supported Amazon OpenSearch Service configuration to retrieve evidence for generation. A custom evaluation workload on Amazon SageMaker AI can submit a versioned set of queries, compare returned identifiers with relevance labels, and calculate Recall@k at selected cutoffs. Publish aggregate and segmented results to Amazon CloudWatch alongside latency and operational metrics. This separates evidence-coverage testing from infrastructure health checks and helps determine whether a regression comes from retrieval configuration, data changes, or a later context-selection step.

Amazon Bedrock

Amazon Bedrock Knowledge Bases provides retrieval APIs that return source chunks for RAG applications. Use those results in a labeled evaluation harness to calculate Recall@k and compare retrieval depth, filtering, and reranking configurations rather than inferring recall from similarity scores.

Open Amazon Bedrock →
Amazon OpenSearch Service image Amazon OpenSearch Service

Amazon OpenSearch Service supports vector and lexical retrieval for building search and RAG pipelines. Evaluate its returned document or chunk identifiers against relevance labels while tuning hybrid retrieval, metadata filters, and approximate nearest-neighbor search parameters.

Open Amazon OpenSearch Service →
Amazon SageMaker image Amazon SageMaker

Amazon SageMaker AI processing jobs can run custom retrieval evaluation workloads over versioned query datasets. Use repeatable jobs to compare embedding models, preprocessing strategies, and retrieval configurations while recording Recall@k alongside other metrics.

Open Amazon SageMaker →
Amazon CloudWatch image Amazon CloudWatch

Amazon CloudWatch can receive custom Recall@k metrics produced by an evaluation pipeline and display them alongside retrieval latency and error metrics. Configure alarms for quality regressions, recognizing that recall measurements require relevance judgments and are not automatically available for every live query.

Open Amazon CloudWatch →