RAG vs CAG vs KAG: What I'd Choose for Production AI

RAG vs CAG vs KAG comes down to how I get the right knowledge into an AI answer: retrieve relevant text per question, reuse a preloaded knowledge base, or follow relationships through a knowledge graph. The source comparison makes a useful distinction: CAG removes retrieval for small datasets, while KAG adds structured reasoning. I would not treat either as a blanket replacement for RAG.

For a production system, I'd choose based on the questions and the update workflow, not the acronym. My starting point would still be RAG for changing documents. I'd test CAG for a compact, stable reference set, and consider KAG when answering correctly requires following relationships rather than finding a relevant paragraph.

What I'd actually be choosing between

With retrieval-augmented generation, I'd split documents into chunks, create embeddings, and retrieve relevant chunks for each question. The model then answers using that context. This separates the document collection from the material sent with an individual request.

With cache-augmented generation, I'd preload the knowledge base and reuse the model's cached processing of that context. The source describes saving a key-value cache, adding a question, generating an answer, and removing the question-specific tokens before reuse. Provider prompt caching offers a related route without managing that cache directly.

With knowledge-augmented generation, I'd represent entities and their relationships explicitly. Ant Group's KAG framework combines graph knowledge, links back to source text, and a reasoning process that breaks questions into executable steps. I would not call every small graph application an implementation of that framework.

The distinction I'd keep in view is this: RAG chooses evidence, CAG keeps the evidence available, and KAG structures how connected evidence can be followed. Those are different jobs, so combining them can make more sense than declaring a winner.

What do the CAG and KAG results actually prove?

I would read the CAG results narrowly. As reported in the source, the researchers tested Llama 3.1 8B on SQuAD and HotpotQA, with knowledge bases ranging from about 21,000 to 85,000 tokens. CAG achieved the highest BERTScore in all six setups, but the margins were often under 0.01.

The timing comparison needs even more care. On the large HotpotQA setup, the reported generation time was 2.33 seconds with caching versus 94.35 seconds without caching. That compares cached context against processing the full context again. It is not a published RAG-versus-CAG timing result; the source explicitly notes that RAG timing numbers were not provided.

For KAG, the source reports improvements over HippoRAG on multi-hop benchmarks. I'd take that as a reason to evaluate graph reasoning for relationship-heavy questions, not proof that a graph will improve every document assistant. My own acceptance test would still need representative questions, maintained source data, and evidence paths I can inspect.

I also would not generalize the source's fictional-college experiment too far. Its basic TF-IDF retriever missed intermediate facts that a graph traversal connected correctly. That demonstrates a retrieval failure clearly. It does not establish that every RAG implementation fails the same question: the source also discusses iterative retrieval as another way to collect missing facts.

Choosing RAG, CAG or KAG for a newsroom workflow

For intelligent search in a newsroom platform, I'd begin with RAG. My reason is the changing material, not familiarity with a vector database. I'd want a document update to become available through the retrieval pipeline, with enough source information attached to check the answer.

I would evaluate a small editorial reference guide separately. If the material fits comfortably within the chosen model's context and changes infrequently, I'd test cached context before building a retrieval pipeline around it. I'd still reserve room for the question and answer rather than treating the advertised context limit as a document-size target.

I'd consider graph reasoning for questions involving several explicit relationships. The source's college example connects an award winner to a course, then a room, then a building. In an editorial tool, I'd look for similarly well-defined chains before proposing KAG. I would not turn ordinary article search into a graph project just because some articles mention connected people.

Evaluating RAG, CAG and KAG before implementation

I'd start with one evaluation set and keep it unchanged across the approaches. Otherwise, I could accidentally give each architecture questions that suit it and call the comparison useful.

1. Separate question types. I'd include direct lookups, questions needing several facts, unanswerable questions, and questions about recently changed material. I'd write down the supporting evidence expected for each answer.
2. Inspect RAG evidence before generation. I'd record the selected chunks and check whether they contain every required fact. If an intermediate relationship is absent, I'd test retrieval changes or a second search before changing the answer model.
3. Test CAG with realistic context. I'd include unrelated material, not just the answer-bearing paragraphs. Having all the facts available does not prove that the model will select and connect them correctly.
4. Give cached knowledge an update procedure. I'd define when a changed document requires rebuilding the cache and how I'd verify the replacement. I'd test that process alongside normal answering.
5. Keep the first graph narrow. I'd choose a small set of relationship types and require source references for each edge. I'd review extracted relationships before trusting the resulting answer path.
6. Compare the complete request. I'd measure evidence quality, answer quality, latency, and cost together. I'd include cache misses and graph maintenance in the evaluation rather than comparing only the cleanest successful requests.

For a minimal graph check, I'd use something like the JavaScript below. It follows the source's fictional college relationships and preserves an evidence reference at each step. This is an illustrative traversal, not Ant Group's KAG framework or a complete question-answering system.

const edges = [
  { from: 'Dr. Meera Iyer', relation: 'teaches',
    to: 'Data Structures', source: 'fact-2' },
  { from: 'Data Structures', relation: 'held_in',
    to: 'Room 204', source: 'fact-3' },
  { from: 'Room 204', relation: 'located_in',
    to: 'Raman Block', source: 'fact-4' }
];

function follow(start, relations) {
  let current = start;
  const evidence = [];

  for (const relation of relations) {
    const matches = edges.filter(edge =>
      edge.from === current && edge.relation === relation
    );
    if (matches.length !== 1) {
      return { answer: null, evidence, unresolved: relation };
    }
    const edge = matches[0];
    evidence.push(edge);
    current = edge.to;
  }
  return { answer: current, evidence };
}

const result = follow('Dr. Meera Iyer', [
  'teaches', 'held_in', 'located_in'
]);
console.log(result);

I'd deliberately stop on a missing or ambiguous relationship rather than pick an arbitrary edge. The starting person is supplied here; resolving the award winner from the question remains a separate step. That boundary matters because a correct traversal cannot repair an incorrectly identified starting entity.

Is CAG cheaper than RAG?

I would not budget on that assumption. The source's illustrative calculation uses an input price of $3 per million tokens, cached reads at 10% of that price, and five retrieved chunks of 300 tokens each. It excludes the initial cache-write cost.

Under those assumptions, cached CAG is cheaper only below roughly 15,000 knowledge-base tokens. As the cached knowledge grows, its input bill grows too. RAG's selected context stays fixed in that calculation, so its modeled input cost stays fixed.

I'd use that example to challenge the claim that caching automatically makes CAG cheaper, not as a quote for my own deployment. My worksheet would include the selected provider's terms, actual context size, output usage, retrieval expenses, cache reuse, and update frequency. I'd also distinguish savings against repeatedly sending everything from savings against retrieving a small evidence set.

What RAG, CAG and KAG do not solve

I would not treat any of these methods as a guarantee of correctness. RAG can select the wrong evidence. CAG can present everything while leaving the model to find the relevant detail. KAG can follow a relationship that was extracted incorrectly or has become outdated.

I'd also separate traceability from truth. A visible graph path helps me inspect the reasoning, but I'd still check the underlying source. Similarly, a retrieved citation tells me where to look; I'd verify that it supports the answer rather than accepting its presence as validation.

I'd skip CAG if the required knowledge does not fit or changes too often for a practical rebuild workflow. I'd postpone KAG if my questions are mostly direct lookups and I cannot justify maintaining the graph. If a small reference set already works well with cached context, I'd avoid adding retrieval merely to match a standard architecture.

My next step would be an evidence review, not a framework migration. I'd collect the questions the current system gets wrong and inspect what reached the model. Missing paragraphs would send me toward retrieval work; missing relationship chains would justify a graph experiment. I'd ask the failure to earn the extra infrastructure.

Source: ByteMuni, “RAG vs CAG vs KAG: How Each Works, What the Research Says and Which One to Use,” at https://bytemuni.com/artificial-intelligence-machine-learning/llms-generative-ai/rag-vs-cag-vs-kag-explained/. Research results above are reported through that source; the implementation checks are my recommendations.