Given a labeled set of (query, relevant_doc_ids) pairs, recall@k is the fraction of queries where AT LEAST ONE relevant doc appears in the top-k retrieved results. So recall@10 = 0.85 means 85% of queries had a relevant doc in the top 10. It's the standard headline metric for embedding-retrieval quality but is incomplete: it ignores ordering within the top-k and confounds embedding quality with ANN index quality.
**Recall@k** is the standard headline metric for retrieval systems. Given a labeled evaluation set where each query has known relevant documents, recall@k asks. For what fraction of queries does at least one relevant document appear in the top-k retrieved results?
Here's the calculation. You have 100 evaluation queries. For each query, you run retrieval and look at the top-k results (say k=10). For each query, ask 'did at least one relevant doc appear in those 10?'. If yes, count it. The fraction of queries where the answer is yes is recall@10.
So recall@10 = 0.85 means that in 85% of queries, at least one relevant document made it into the top 10. The other 15% of queries failed: none of their relevant documents showed up in the top 10.
Recall@k is a useful baseline metric because it directly measures whether the system surfaces relevant content within a budget of k results. But it has two big blind spots. First, it ignores ordering within the top-k: a relevant doc at rank 1 and a relevant doc at rank 10 count the same.
Second, if you measure it on a production ANN index (HNSW, IVF-PQ), you're measuring the combined quality of the embedding and the index, not the embedding alone. Metrics like NDCG@k and MRR capture ordering; using an exact (flat) index isolates embedding quality.
**Recall@k** is the proportion of queries in a labeled evaluation set where at least one relevant document appears in the top-k retrieved results. It's the headline retrieval metric in most production eval pipelines.
The calculation. Given an evaluation set of (query, relevant_doc_ids) pairs, run retrieval for each query. Look at the top-k retrieved documents. Score the query as 'hit' if at least one of its relevant docs is in the top-k, 'miss' otherwise. Recall@k is the fraction of hits across all queries.
For example: 100 queries, each with one or more labeled relevant documents. Run retrieval, take top-10 for each. 85 queries have at least one relevant doc in the top-10. Recall@10 = 0.85.
The metric has clean operational meaning: 'in what fraction of cases does the system find SOMETHING relevant within a budget of k retrievals?'. For RAG, k is often the chunk budget you'll pass to the LLM (k=5 or k=10 are common), so recall@k directly tells you whether the LLM will see relevant context.
Two important limitations.
First, recall@k ignores ordering within the top-k. A relevant doc at rank 1 and a relevant doc at rank 10 contribute equally. But the downstream LLM behavior differs: lost-in-the-middle effects mean rank-1 content has outsized impact on the answer. Use NDCG@k or MRR to capture rank-sensitivity.
Second, recall@k against an approximate ANN index (HNSW, IVF-PQ) confounds embedding quality with index quality. The result is the product of the embedding's true recall and the ANN index's recall against an exact baseline. To isolate embedding quality, run the eval against an exact (flat) index. To measure the ANN trade-off separately, compare ANN recall@k to flat recall@k.
In 2026 production stacks, recall@k typically appears alongside NDCG@10 and per-domain recall breakouts, all measured on an exact index for a defensible embedding comparison.
Quick reference
TL;DR
Recall@k is the fraction of queries where at least one relevant document appears in the top-k retrieved results.
Picture asking a librarian for any book about World War II and watching them grab the top 10 from the shelf. Recall@10 asks one question: did at least one actual WW2 book make it into those 10? If yes, the librarian got credit for the query. Recall@10 across many queries is the fraction of times the librarian got credit. The blind spot: the metric doesn't care whether the WW2 book was the first one handed over or buried at position 10, only that it showed up somewhere in the pile.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Comparing two retrieval systems where rank within the top-k matters (lost-in-the-middle, click through at rank-1). Recall@k ignores rank inside the budget. Use NDCG@k or MRR when the consumer is rank-sensitive.
Evaluating an embedding model on a production HNSW index without a flat-index control. The result confounds embedding quality with index quality. Without a flat-index control, you can't tell whether a difference came from the model or the index.
Workloads with very large ground-truth sets per query (recommendation, where many documents are 'relevant'). Recall@k saturates quickly when many docs are relevant; precision@k or NDCG@k captures discrimination better in that regime.
Quick scan · 2–4 min
Everything important, quickly.
5 min: define recall@k, walk through the calculation on a concrete 100-query example, distinguish from precision@k, name the two main limitations (rank blindness, index confound), and recommend companion metrics.
Real-world examples
Real products, models, and research that use this idea.
1BEIR benchmarks all report NDCG@10 as the primary metric, but recall@k breakouts are also published for downstream analysis.
2MTEB's retrieval category reports NDCG@10 in the headline; per-task recall@k is available in the detailed breakdown.
3Production RAG stacks (Voyage, Cohere, Pinecone reference implementations) measure recall@k against an exact index during model selection, then accept some ANN-index penalty for production deployment.
4LangSmith and other LLM-eval platforms expose recall@k as a first-class retrieval metric alongside LLM-as-judge graders for end to end RAG quality.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does measuring recall@k on an HNSW index confound embedding quality and index quality?
Sign in or go Pro to see the approach for this follow-up.
QHow do you handle false negatives in a labeled retrieval eval?
Sign in or go Pro to see the approach for this follow-up.
QWhen would precision@k be more informative than recall@k?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Confusing recall@k with precision@k. Recall@k asks 'did at least one relevant doc make it in?' Precision@k asks 'how many of the top-k are relevant?' They measure different things and can move in opposite directions.