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: você indexa documentos em chunks com embeddings e, na hora da pergunta, traz apenas o top-k mais parecido. É a abordagem padrão quando a base é grande demais para caber no contexto.

CAG (Cache Augmented Generation) inverte a lógica: carrega TODA a base de conhecimento dentro do contexto do modelo uma única vez, deixa o modelo processar esse bloco e reaproveita o estado interno (o KV cache, exposto pelos provedores como prompt cache) nas perguntas seguintes. Não há embedding por query, não há vector store, não há reranking. A pergunta do usuário é anexada ao contexto já cacheado e a geração acontece direto. O preço a pagar é que a base toda precisa caber na janela de contexto.

A escolha entre RAG e CAG não é ideológica: cada dimensão puxa para um lado. A tabela abaixo coloca as seis dimensões que mais pesam na decisão real de engenharia.

Visualizar os dois caminhos deixa clara a diferença de superfície: RAG tem uma cadeia de etapas por query, cada uma com seu ponto de falha; CAG concentra o trabalho pesado uma única vez e depois só 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" é uma chance de errar: a pergunta pode embedar mal, o top-k pode não trazer o trecho certo, o reranking pode reordenar errado. Em CAG, o caminho entre a pergunta e a resposta é curto porque o conhecimento já está presente e processado.

CAG é a escolha certa quando a base é contida e estável, e quando latência ou correção do retrieval importam mais do que escalar para milhões de documentos.

• Base pequena ou média que cabe inteira na janela de contexto: FAQ, manual de produto, políticas de troca e entrega, base de regras de um nicho.
• Dado relativamente estável: muda em semanas ou meses, não a cada minuto, então refazer o cache de vez em quando é barato.
• Latência crítica: ao eliminar embed, busca e reranking, a primeira resposta após o cache quente sai bem mais rápido.
• Evitar erro de retrieval: como o modelo vê a base inteira, some a classe de falha em que o chunk certo simplesmente não foi recuperado.
• Infra enxuta: sem vector store nem pipeline de embeddings para manter, o sistema tem menos partes móveis e menos custo operacional.

RAG continua imbatível quando a base não cabe no contexto, muda o tempo todo, precisa de rastreabilidade fina por fonte ou serve muitos clientes com bases isoladas.

• Base grande que não cabe no contexto: dezenas de milhares de documentos, anos de tickets, catálogos extensos. Aqui CAG simplesmente não entra.
• Dado que muda muito: estoque, preços, conteúdo atualizado todo dia. Reindexar um documento é barato; refazer o cache da base inteira a cada mudança não.
• Necessidade de citar fonte específica: quando cada afirmação precisa apontar exatamente para o documento e a seção 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 coração do CAG é o prompt cache: o provedor processa o bloco grande da base de conhecimento uma vez e guarda o estado, de forma que as próximas requisições que começam 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 fração.

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

const client = new Anthropic();

// A base de conhecimento inteira: FAQ + políticas + 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: 'Você responde EXCLUSIVAMENTE com base na BASE DE CONHECIMENTO abaixo. Se não houver resposta nela, diga que não sabe.',
      },
      {
        type: 'text',
        text: KNOWLEDGE_BASE,
        // Marca este bloco como cacheado: processado uma vez,
        // reaproveitado nas próximas requisições 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 (lê do cache, custa fração).
await ask('Vocês entregam no interior?');
await ask('Como funciona a garantia estendida?');

O ganho fica explícito 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 fração do preço normal de entrada. Ou seja, a base é processada uma vez e o mesmo cache serve todas as perguntas seguintes, enquanto o cache estiver quente. Sem retrieval, sem vector store: o conhecimento já está no contexto.

Na prática, CAG e RAG não são rivais: a arquitetura mais robusta usa CAG para o core estável e RAG para o long tail. O núcleo de conhecimento que quase não muda e que responde a maioria das perguntas fica cacheado no contexto; o que é raro, volumoso ou volátil fica no vector store e só é recuperado quando o core não basta.

1. Identifique o core estável: as políticas, 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, conteúdo que muda com frequência. Eles ficam indexados para RAG.
3. Responda primeiro pelo cache: a pergunta chega ao contexto já cacheado. Se o core cobre, responde direto, com baixa latência e sem risco de retrieval.
4. Acione RAG só no long tail: quando a resposta não está no core, dispare o retrieval para buscar o trecho específico no vector store e injete-o junto.
5. Reavalie a fronteira periodicamente: promova ao core estável o que virou pergunta frequente e refaça o cache; rebaixe ao vector store o que ficou raro.