Define recall@k in the embedding retrieval context

**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.