Retrieval versus direct context selection
Choose an evidence path using task coverage and measured complete costs rather than assuming a larger prompt or a smaller retrieved set always wins.
On this page
The question for today
What you’ll understand
- Distinguish full-context evidence access from retrieval-selected coverage.
- Calculate token and attention-pair proxies without claiming runtime speedups.
- Evaluate routing with retrieval misses, source versions, and generation costs included.
A system can place a whole source collection into the prompt, retrieve selected passages, compress the source, or combine those paths. A long accepted context does not establish that the generator will use every included fact, while retrieval can omit decisive evidence before generation begins. LongBench evaluates multiple long-context tasks, and Lost in the Middle studies information use at different positions. These findings motivate task-specific comparisons rather than a universal winner between retrieval and direct context.
Identify which evidence the task needs
An exact lookup can need one short passage, while a global comparison or synthesis may require evidence distributed across many documents. A retriever optimized for local relevance can miss a low-overlap source needed for a multi-document constraint. Direct context can include that source but still suffer from distractors, truncation, or weak positional use. Define the required evidence and evaluate whether it is present, visible, and actually sufficient for the answer. Candidate recall and generator reasoning are separate parts of that diagnosis.
Keep corpus eligibility, source versions, and task definitions consistent across the compared paths. Retrieval over a newer index than the direct-context snapshot is not an isolated comparison of context strategy. Chunk boundaries, duplicates, passage ordering, and metadata can alter what the generator sees. Log exact retrieved identities and text, including separators and instructions. If a hybrid fallback expands context when retrieval is uncertain, evaluate its missed activations as well as successful examples instead of assuming a confidence signal identifies every retrieval failure.
Count all work on the request path
For a fixed-width dense-attention prefill, a squared-token proxy illustrates how prompt reduction can lower the attention-pair component. It does not model every projection, feed-forward layer, kernel, device, or cached prefix. Retrieval has its own embedding, search, fusion, reranking, and transfer costs; a query-aware compressor adds another inference stage. Measure complete time to first token and generation under representative arrivals rather than claiming a runtime speedup from token ratio alone. Repeated queries and prefix reuse can change the comparison substantially.
Both strategies must fit the actual serving limit with instructions and output reserve accounted for. Reducing the prompt can leave more output capacity, while a huge direct prompt can constrain completion length. A short retrieved set may reduce generation cost yet lower answer completeness. Report those quality and resource outcomes together. A routing policy can choose among paths, but its thresholds need held-out evaluation by task and query class; easy-query averages can hide expensive failures on the cases that needed broader evidence.
Use matched evidence and quality controls
Compare direct context with a retrieved path and an oracle-evidence condition where the necessary sources are supplied deliberately. If the oracle succeeds but retrieval fails, inspect candidate coverage. If direct context fails despite containing the same evidence, test ordering, distractors, and reasoning separately. Use fresh source-dependent values to reduce shortcuts through model memory, while preserving realistic tasks as another test set. A single synthetic lookup result cannot settle the tradeoff for summaries, code repositories, or multi-document reconciliation.
The Roofline lab illustrates only a generic assumed traffic effect. Reset, set operational intensity to 8 and bandwidth to 80, predict the synthetic ceiling, then Step: 640 GFLOP/s. Compare a fresh Reset with both intensity at 2 and bandwidth at 80 before Step: 160 GFLOP/s. Its fixed compute ceiling is 1000. It does not retrieve documents, execute attention, count prompt tokens, or measure an LLM request; the plotted ceilings cannot establish which context path answers better or faster.
Work it through
Prompt reduction is not an end-to-end speedup claim
Under one tokenizer, fixed query/instructions cost 1,000 tokens and the full source costs 16,000. A retrieved path selects four 1,000-token chunks. Reserve 1,000 output tokens and assume a 20,000-token total limit. Compare fit and the squared-token prefill proxy.
The direct prompt is 17,000 tokens, or 18,000 including output reserve. The retrieved prompt is 5,000, or 6,000 with reserve. Both fit the declared limit.
The attention-pair proxy ratio is (17,000/5,000)² = 11.56. This compares one idealized work component, not complete inference time.
Check whether the four retrieved chunks contain every required fact, then include retrieval and reranking cost in timing. Missing decisive evidence can make the cheaper prompt fail even though direct context also needs separate evidence-use tests.
A useful path choice combines complete cost and task quality rather than equating a token-work ratio with measured performance.
The living notebook
Explore the model
Interactive lab · roofline
A generic traffic ceiling without a context router
Reset, set I = 8 and B = 80, predict the ceiling, then Step: 640 GFLOP/s. Compare a fresh Reset with both I = 2 and B = 80 before Step: 160 GFLOP/s. The fixed 1000-GFLOP/s model does not execute attention, retrieval, compression, or text generation.
- Attainable ceiling
- 640 GFLOP/s
- Ridge intensity
- 12.5 FLOP/byte
- Ceiling regime
- Memory-bound ceiling
Synthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA resource proxy is one input to a decision; actual evidence coverage and request timing remain separate measurements.
Pause & reason
Check your understanding
Your turn
Try it yourself
Fixed instructions cost 500 tokens. Compare an 8,000-token complete source with three 1,000-token retrieved chunks. Compute prompt sizes and the squared-token proxy ratio, then name one necessary quality control.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Add the fixed query cost to both paths before squaring their ratio.
Compare with the solution
Prompt sizes are 8,500 and 3,500 tokens. The proxy ratio is (8,500/3,500)² = 289/49, approximately 5.898. Verify whether the retrieved set contains all supporting evidence, ideally with an oracle-evidence comparison, and test whether the generator uses it correctly. Retrieval overhead, other model work, cached prefixes, and output reserve keep this ratio from being a measured latency claim.
Keep the idea
Take it with you
- Retrieval and direct context have different evidence-coverage failure modes.
- Token and attention-pair ratios omit important end-to-end costs.
- Matched corpus, oracle evidence, and task-specific quality tests support a defensible routing decision.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.