CAG x RAG: quando cache de contexto vence retrieval

RAG (Retrieval Augmented Generation) recupera, a cada query, os trechos mais relevantes de um vector store e os injeta no prompt antes de gerar a resposta. A base nunca entra inteira no contexto: voce indexa documentos em chunks com embeddings e, na hora da pergunta, traz apenas o top-k mais parecido. E a abordagem padrao quando a base e grande demais para caber no contexto.

CAG (Cache Augmented Generation) inverte a logica: carrega TODA a base de conhecimento dentro do contexto do modelo uma unica vez, deixa o modelo processar esse bloco e reaproveita o estado interno (o KV cache, exposto pelos provedores como prompt cache) nas perguntas seguintes. Nao ha embedding por query, nao ha vector store, nao ha reranking. A pergunta do usuario e anexada ao contexto ja cacheado e a geracao acontece direto. O preco a pagar e que a base toda precisa caber na janela de contexto.

A escolha entre RAG e CAG nao e ideologica: cada dimensao puxa para um lado. A tabela abaixo coloca as seis dimensoes que mais pesam na decisao real de engenharia.

Visualizar os dois caminhos deixa clara a diferenca de superficie: RAG tem uma cadeia de etapas por query, cada uma com seu ponto de falha; CAG concentra o trabalho pesado uma unica vez e depois so anexa a pergunta.

RAG (por query)
  Query  ->  Embed  ->  Retrieve (top-k)  ->  Rerank  ->  Gerar  ->  Resposta
                          (vector store)     (cross-encoder)

CAG (uma vez + por query)
  Base inteira  ->  Contexto / KV cache (prompt cache)
                          |
                          v
  Query  ----------->  Gerar  ->  Resposta
  (anexada ao contexto ja cacheado, sem retrieval)

Em RAG, cada seta antes de "Gerar" e uma chance de errar: a pergunta pode embedar mal, o top-k pode nao trazer o trecho certo, o reranking pode reordenar errado. Em CAG, o caminho entre a pergunta e a resposta e curto porque o conhecimento ja esta presente e processado.

CAG e a escolha certa quando a base e contida e estavel, e quando latencia ou correcao do retrieval importam mais do que escalar para milhoes de documentos.

• Base pequena ou media que cabe inteira na janela de contexto: FAQ, manual de produto, politicas de troca e entrega, base de regras de um nicho.
• Dado relativamente estavel: muda em semanas ou meses, nao a cada minuto, entao refazer o cache de vez em quando e barato.
• Latencia critica: ao eliminar embed, busca e reranking, a primeira resposta apos o cache quente sai bem mais rapido.
• Evitar erro de retrieval: como o modelo ve a base inteira, some a classe de falha em que o chunk certo simplesmente nao foi recuperado.
• Infra enxuta: sem vector store nem pipeline de embeddings para manter, o sistema tem menos partes moveis e menos custo operacional.

RAG continua imbativel quando a base nao cabe no contexto, muda o tempo todo, precisa de rastreabilidade fina por fonte ou serve muitos clientes com bases isoladas.

• Base grande que nao cabe no contexto: dezenas de milhares de documentos, anos de tickets, catalogos extensos. Aqui CAG simplesmente nao entra.
• Dado que muda muito: estoque, precos, conteudo atualizado todo dia. Reindexar um documento e barato; refazer o cache da base inteira a cada mudanca nao.
• Necessidade de citar fonte especifica: quando cada afirmacao precisa apontar exatamente para o documento e a secao de origem, o retrieval entrega esse rastro naturalmente.
• Multi-tenant com bases isoladas: muitos clientes, cada um com sua base privada. O vector store filtra por tenant; manter um cache gigante por cliente seria caro e arriscado.

O coracao do CAG e o prompt cache: o provedor processa o bloco grande da base de conhecimento uma vez e guarda o estado, de forma que as proximas requisicoes que comecam com o mesmo prefixo reaproveitam esse trabalho. No exemplo abaixo, usando a Anthropic Messages API, a base de conhecimento vai como um bloco de sistema marcado com cache_control. A primeira pergunta paga o processamento da base; as seguintes leem do cache e custam uma fracao.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

// A base de conhecimento inteira: FAQ + politicas + manual.
// Carregada uma vez e marcada como cacheada.
const KNOWLEDGE_BASE = loadKnowledgeBase(); // string grande, cabe no contexto

async function ask(question) {
  return client.messages.create({
    model: 'claude-sonnet-4-5',
    max_tokens: 512,
    system: [
      {
        type: 'text',
        text: 'Voce responde EXCLUSIVAMENTE com base na BASE DE CONHECIMENTO abaixo. Se nao houver resposta nela, diga que nao sabe.',
      },
      {
        type: 'text',
        text: KNOWLEDGE_BASE,
        // Marca este bloco como cacheado: processado uma vez,
        // reaproveitado nas proximas requisicoes com o mesmo prefixo.
        cache_control: { type: 'ephemeral' },
      },
    ],
    messages: [{ role: 'user', content: question }],
  });
}

// 1a pergunta: cache_creation_input_tokens (paga o processamento da base).
await ask('Qual o prazo de troca de um produto com defeito?');

// 2a pergunta em diante: cache_read_input_tokens (le do cache, custa fracao).
await ask('Voces entregam no interior?');
await ask('Como funciona a garantia estendida?');

O ganho fica explicito nos contadores de uso: a primeira chamada registra cache_creation_input_tokens (a base foi processada e cacheada) e as seguintes registram cache_read_input_tokens, cobrados por uma fracao do preco normal de entrada. Ou seja, a base e processada uma vez e o mesmo cache serve todas as perguntas seguintes, enquanto o cache estiver quente. Sem retrieval, sem vector store: o conhecimento ja esta no contexto.

Na pratica, CAG e RAG nao sao rivais: a arquitetura mais robusta usa CAG para o core estavel e RAG para o long tail. O nucleo de conhecimento que quase nao muda e que responde a maioria das perguntas fica cacheado no contexto; o que e raro, volumoso ou volatil fica no vector store e so e recuperado quando o core nao basta.

1. Identifique o core estavel: as politicas, o FAQ e o manual que respondem a maior parte das perguntas e mudam pouco. Esse bloco vira o contexto cacheado (CAG).
2. Mantenha o long tail no vector store: documentos extensos, casos raros, conteudo que muda com frequencia. Eles ficam indexados para RAG.
3. Responda primeiro pelo cache: a pergunta chega ao contexto ja cacheado. Se o core cobre, responde direto, com baixa latencia e sem risco de retrieval.
4. Acione RAG so no long tail: quando a resposta nao esta no core, dispare o retrieval para buscar o trecho especifico no vector store e injete-o junto.
5. Reavalie a fronteira periodicamente: promova ao core estavel o que virou pergunta frequente e refaca o cache; rebaixe ao vector store o que ficou raro.