Skip to course content
Free RAG fundamentals course

Introduction to RAG and Knowledge Assistants

Unit 03.02: Indexes, neighbours, and how many to fetch

k - the number of chunks you retrieve - looks like a tuning knob and behaves like a design decision. It trades recall against noise, cost and latency all at once.

What each additional chunk buys and costs

Small k risks missing the chunk that holds the answer. Large k guarantees you include it and surrounds it with irrelevant material, which dilutes the context and gives the model more chances to cite the wrong thing.

The example below builds a 200-vector corpus, perturbs one of them into a query, and reports what k=1, 3 and 10 return.

A corpus of 200 chunks. The chunk that answers the question is number 7.

k     CHUNKS RETURNED                 CONTAINS THE ANSWER?   NOISE
1     7                               yes                    0
3     7, 69, 33                       yes                    2
10    7, 69, 33, 134, 199, 53, ...    yes                    9

score gap, rank 1 to rank 2:   0.163   <- a decisive separation
score gap, rank 9 to rank 10:  0.012   <- effectively a tie

The answer is at rank 1, so every setting of k finds it and k=10 adds nine
chunks of noise -- each one a citable id the model might attach to a claim.

The true match is at rank 1, so every setting of k finds it and k=10 adds nine chunks of pure noise. The score gaps say why: 0.163 between ranks 1 and 2, and 0.012 between ranks 9 and 10. The first gap is a real separation; the second is arbitrary ordering of near-identical scores.

That gap between consecutive scores is the number to watch. A large rank-1-to-rank-2 gap means the ranking is decisive. A tiny one means two chunks are effectively tied, and which one lands in slot 1 is close to chance - worth escalating rather than answering from, as Module 10 does.

The mistake this prevents

There is a second reason to keep k modest, and it is what makes the standard two-stage pattern work. Retrieve generously with the cheap vector search - recall first - then re-rank those candidates with a costlier, more accurate relevance model and pass only the top few forward. Re-ranking is expensive per candidate, so it is affordable only over a shortlist, and the shortlist is exactly what k defines. Cheap recall, expensive precision, in that order.

The mistake is raising k when answers are wrong. If the answer chunk was already at rank 1, retrieving ten chunks does not help - the failure is in generation or citation checking, not recall. Diagnose which stage failed before tuning the one that did not.

Takeaway

Choose k by measuring recall on your own eval set and stopping where the curve flattens. Then watch the rank-1-to-rank-2 gap per query: it tells you whether the ranking was decisive or a coin flip.