Recall@k

Recall@k measures the fraction of all documents relevant to a query that appear anywhere within the top k retrieved results — the number of relevant items found, divided by the total number of relevant items that exist.

It answers a specific question: of everything that should have been retrieved, how much did the system actually surface within its result window? It says nothing about the order of those results within the top k, and nothing about how many irrelevant results came along with them — that's precision@k's job. The two metrics are deliberately complementary.

How it works

The formula is:

recall@k = (relevant documents in top k) / (total relevant documents that exist)

Computing it requires knowing the total relevant count ahead of time — which is why recall@k depends entirely on a golden dataset with labeled relevant documents per query. Without that ground truth, there's no denominator, and "recall" is not a computable number, just a guess.

Recall@k is monotonic in k by construction: recall@20 can only be greater than or equal to recall@5 for the same query, because widening the window can only add relevant documents, never remove them. That makes recall@k a natural metric for tuning how many candidates a first-pass retriever should hand to a reranker — you want k large enough that recall@k is near its ceiling before reranking narrows the list back down.

Why it matters

Recall@k is the metric that catches the retrieval failure a RAG system cannot recover from: a document that never enters the top k is a document the language model will never see, no matter how good the prompt, the reranker, or the model downstream. A RAG system with excellent prompting and a weak retriever fails silently and looks, from the outside, like a hallucination problem — when the real problem was that the evidence was never in the context to begin with. Teams debugging groundedness issues should check recall@k before touching the prompt.

A worked example

A query has 4 documents in the corpus genuinely relevant to it, labeled by hand in a golden dataset. A retrieval system's top-5 results contain 3 of those 4 relevant documents, mixed in with 2 irrelevant ones.

recall@5 = 3 / 4 = 0.75

Widen the window to top-10 and, say, the 4th relevant document appears at rank 8: recall@10 becomes 4/4 = 1.0. That single shift — 0.75 at k=5, rising to 1.0 at k=10 — tells a concrete engineering fact: this retriever needs a slightly larger first-pass k, or a better ranking, to make sure a downstream reranker or generator sees all four before it has to choose.

How miatz teaches it

Learners build a small golden dataset with hand-labeled relevant documents per query, then compute recall@k at several values of k for their own retrieval pipeline — plotting the curve rather than reading one number — so the "how big should k be" question turns into evidence instead of a guess.