RAG vs CAG vs KAG: Three Ways to Give a Model Knowledge

RAG retrieves from a large or changing corpus; cache-augmented generation preloads a bounded stable corpus into KV state; knowledge-augmented generation reasons over structured relationships. Chan et al. (2024) named cache-augmented generation in “Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks” (arXiv:2412.15605) as a retrieval-free path when the working set fits the window. GenerativeAI.pub’s RAG versus KAG versus CAG explainer (captured 18 September 2026) restates CAG as preloading static knowledge into an LLM’s KV cache and KAG as structured knowledge-graph grounding. Among the comparisons that come up, this three-way is corpus size, freshness, and structure.

What do RAG, CAG, and KAG each mean?

RAG means retrieve relevant passages at query time from an external index, then generate. CAG, in Chan’s definition used across this site, means preload a curated corpus, KV-encode it once, and answer later queries from that cached state without calling a retriever. KAG means ground generation in structured knowledge, typically a knowledge graph of entities and relations, rather than in similarity search alone.

GenerativeAI.pub’s 2026 capture groups the three as complementary tools for hallucinations, outdated knowledge, and reasoning gaps. Plain Concepts’ RAG versus KAG article (captured 18 September 2026) contrasts open-domain unstructured retrieval with structured factual graph reasoning. AWS Builder’s RAG versus CAG versus KAG note in the same harvest uses “CAG” for a different key-value lookup idea; this comparison stays with Chan’s cache-augmented meaning so it stays consistent with the site’s cache-augmented architecture leaf.

Codebrains’ 2025 strategy post (captured 18 September 2026) sometimes treats CAG as caching frequent answers in front of RAG. That response-cache pattern is useful but is not Chan’s KV preload of a knowledge corpus. When builders say CAG, ask which definition they mean before you redesign the stack.

The practical labels for decision-making are therefore: similarity retrieval over documents (RAG), preload-and-cache a fitting static corpus (CAG), relationship traversal over a graph (KAG). Mixing the acronyms without those mechanisms is how three-way tables become noise.

When should you use RAG versus CAG versus KAG?

Use RAG when the corpus is larger than the context window, changes often, or must cite freshly indexed passages. Use CAG when a bounded corpus fits the context window, stays stable between reloads, and query volume amortises the preload. Use KAG when answers depend on multi-hop entity relationships that similarity search under-serves.

Chan’s manageable-size precondition and GenerativeAI.pub’s when-to-use-CAG notes both require fit and stability. Monte Carlo-style summaries elsewhere on the site state that CAG knowledge is only as fresh as the last cache update. Plain Concepts assigns KAG to structured, domain-specific, complex queries and RAG to dynamic unstructured retrieval.

AWS Builder’s decision matrix in the harvest still helps as a shape checklist even under their divergent CAG definition: unstructured semantic search points to RAG; relationship reasoning points to KAG. Map their “exact known keys” row to application state lookup, not to Chan’s CAG, so you do not merge three mechanisms into one cell.

If two rows fire at once, plan a hybrid rather than forcing a single winner. Preload the stable core with CAG, retrieve the long tail with RAG, and traverse entities with KAG when the question is relational. GenerativeAI.pub’s combine notes and AWS Builder’s combine section both expect mixtures in modern systems.

Read the first three rows before arguing cost. Corpus size and freshness usually decide RAG versus CAG before any latency anecdote matters. Relationship density decides whether KAG earns its ontology cost. Deep KAG and graph build guidance lives on RAG versus knowledge graphs and the graph architecture leaf.

How do corpus size, freshness, and cost compare?

Corpus size pushes toward RAG as soon as the working set exceeds the window. Freshness pushes toward RAG when documents change faster than you can afford a full KV re-encode. Cost for CAG is front-loaded preload and GPU memory for the cache; cost for RAG is ongoing embedding, storage, and retrieval latency; cost for KAG is ontology engineering plus graph infrastructure.

Chan et al. (2024) report quality and timing figures for Llama 3.1 8B Instruct configurations in their paper tables. On HotPotQA-small they report CAG BERTScore 0.7759 versus dense RAG top-10 at 0.7516; on SQuAD-small, CAG 0.8265 versus sparse RAG top-10 at 0.8191. Those are the paper’s published scores for those setups, not a ranking of every production RAG system. Table 3’s large generation-time gaps compare CAG to an in-context prefill baseline without a precomputed knowledge KV cache, not to a full retrieval stack’s end-to-end latency.

None of GenerativeAI.pub, Plain Concepts, Codebrains, AWS Builder, or LinkedIn’s InteligenAI pulse in this harvest publishes a single universal dollar crossover among the three as of 18 September 2026. Decide with fit, change rate, and relationship density measured on your tickets. Invented price tables are worse than a directional matrix.

Operational cost also includes failure tax. Stale CAG caches look fluent and wrong. Wrong RAG chunks look fluent and wrong with a citation. Wrong KAG edges look structured and wrong. Evaluation must match the mechanism you chose.

When should you combine RAG and CAG?

Combine RAG and CAG when a stable foundation can be preloaded while a changing long tail still needs retrieval. Chan’s outlook discusses hybrid designs that preload a foundation and retrieve for edge cases. GenerativeAI.pub’s CAG plus RAG note describes preloading common knowledge and retrieving for dynamic data. Codebrains’ “CAG in front of RAG” pattern is a related but narrower response-cache idea.

AWS Builder’s combine list includes RAG plus CAG for documents enriched with live application context, which maps cleanly if their CAG means application key-value state rather than Chan’s KV corpus cache. In Chan’s vocabulary, live application context is usually a tool or memory concern; the stable manual remains the CAG candidate.

Start the hybrid only after measuring which queries hit the stable core. If ninety percent of traffic is the weekly-changing ticket corpus, CAG will thrash on re-encodes. If ninety percent is a quarterly policy pack, CAG earns its keep and RAG covers exceptions.

Do not combine as a compromise when you have not named the corpus bounds. Hybrids without bounds become two incomplete systems. Name the preload set, the retrieve set, and the reload trigger in the same design review.

What are the use cases for RAG, CAG, and KAG?

RAG use cases include large knowledge bases, news and research desks, and any assistant that must cite passages from a corpus that will not fit in one preload. GenerativeAI.pub and Plain Concepts both place RAG on dynamic unstructured settings. Vector stores such as Weaviate, Pinecone, or Qdrant are the usual home for that index.

CAG use cases include FAQs, SOPs, product manuals, and other bounded static packs answered thousands of times between updates. Chan’s paper and GenerativeAI.pub’s manuals-or-policies examples match that shape. Latency-sensitive assistants over a frozen policy pack are the clearest win.

KAG use cases include organisational hierarchies, dependency maps, fraud links, and supply-chain questions where the path between entities is the answer. Plain Concepts’ structured factual emphasis and AWS Builder’s relationship row describe that family. Ontology cost is the gate, not the acronym.

Mixed products are common: cache the employee handbook with CAG, retrieve tickets with RAG, traverse org relations with KAG. Plan evaluation per path so one fluent generator cannot hide which store failed.

LinkedIn’s InteligenAI pulse in this harvest (captured 18 September 2026) uses “CAG” for a cognitive-control architecture rather than Chan’s cache preload. That third meaning is why acronyms need a definition sentence every time they appear in a design review. This comparison keeps cache-augmented generation as the site meaning and routes deep graph work to the knowledge-graph decision.

Window budgeting is the quiet dependency under every CAG plan. If the manual grows past the model’s usable context, CAG stops being a strategy and becomes a compression problem. Link that limit to context-window practice before promising retrieval-free latency. Chan’s experiments on long-context Llama configurations are a research ceiling for their paper, not a permanent product guarantee as models and windows change.

Operational runbooks should name the reload trigger in hours or events, the owner of the preload corpus, and the fallback when a question falls outside the cache. Without those three lines, “we use CAG” is a demo setting. With them, CAG becomes a maintained path beside RAG and KAG rather than a one-off speed trick.

Keep CAG’s success criteria boring and measurable: preload size in tokens, reload interval, cache hit share of traffic, and quality on a frozen eval set after each reload. Those meters prevent latency anecdotes from hiding freshness regressions.

RAG, CAG, and KAG are three grounding bets, not three logos for the same pipeline. Retrieve when the corpus is large or fresh; preload and cache when it fits and stays still; traverse a graph when relationships are the question; combine them when the product spans more than one knowledge shape. Chan et al. (2024), GenerativeAI.pub, Plain Concepts, Codebrains, and AWS Builder all supply pieces of that three-way even when their CAG definitions disagree, and this comparison keeps Chan’s cache-augmented meaning as the site baseline.