What Problem Is Traditional RAG Solving? (www.gojiberries.io)

The piece reframes retrieval-augmented generation (RAG) as a solution to a concrete constrained decision problem: given a corpus, a query and a budget (latency, cost, context), choose a minimal evidence set E that suffices for a correct decision while minimizing cost and error. It enumerates the core factors that determine that selection problem—footprint, dispersion, signal alignment, authority/time, structure, redundancy, dynamics, economics and explanation demand—and shows how traditional RAG implicitly assumes a sweet spot: small footprint, low dispersion, semantic (paraphrase) matching, weak time/authority constraints, light structure, manageable redundancy and stable dynamics. The author formalizes the choice to run an LLM as Δ = Utility(LLM(E)) − Utility(extractive E) − Cost(LLM); generation is justified when Δ > 0, notably for semantic integration, small conditional joins, or when a justified, cited conclusion is required. Practically, this yields clear engineering guidance: use RAG when an expensive LLM adds integrative, conditional or justificatory value; prefer extractive, deterministic, or live-API reads when answers are single-span, table-based, provenance-sensitive or rapidly changing. The OpenSSL vulnerability example illustrates retrieval selecting a few authoritative spans and generation normalizing versions and producing a cited decision—something brittle parsers or raw snippets would mishandle. In short, pick the pipeline to match the evidence-selection objective and pay for generation only when it measurably improves decision quality.