Context Engineering vs RAG vs Memory: diferenças e quando usar cada abordagem

Context Engineering decide o que entra na janela do modelo agora. RAG decide o que recuperar do corpus sob demanda. Memory decide o que persistir entre turnos e sessões. Misturar os três sem política gera custo, vazamento e respostas instáveis.

Definições operacionais

• Context Engineering: política de montagem do prompt (instruções, evidências, estado, histórico útil)
• RAG: recuperação de trechos/documentos no momento da consulta, com ranking e (em produção) ACL
• Memory: armazenamento seletivo de fatos, preferências ou resumos entre runs, com retenção e escopo

Comparativo lado a lado

Context Engineering na prática

Trate a janela como um orçamento com camadas. Instruções de sistema estáveis. Evidências recuperadas. Estado de ferramentas do run. Histórico compactado. Preferências do usuário só quando necessárias. Cada bloco compete por tokens.

type Block = { kind: "system" | "evidence" | "state" | "history"; text: string; tokens: number };

function pack(blocks: Block[], budget: number): Block[] {
  const priority = { system: 0, evidence: 1, state: 2, history: 3 } as const;
  const ordered = [...blocks].sort((a, b) => priority[a.kind] - priority[b.kind]);
  const out: Block[] = [];
  let used = 0;
  for (const block of ordered) {
    if (used + block.tokens > budget) continue;
    out.push(block);
    used += block.tokens;
  }
  return out;
}

• Priorize evidências citáveis sobre histórico verboso
• Compacte histórico com sumarização versionada, não delete cego
• Nunca injete segredos ou PII desnecessária no contexto
• Logue quais blocos entraram: sem isso, debug vira adivinhação

Onde RAG entra

RAG alimenta o Context Engineering com evidências sob demanda. Sem retrieval, o contexto depende só do que couber no treino ou no prompt estático. Em corpora mutáveis e multi-tenant, RAG com ACL é o padrão mínimo de honestidade factual.

RAG não substitui Context Engineering: trechos ruins bem recuperados ainda estragam a resposta se a montagem ignorar prioridade, citações e limite de tokens. Tampouco substitui Memory: recuperar o mesmo fato a cada turno sem política de persistência pode ser caro e inconsistente.

Memory: persistir com intenção

Memória de curto prazo (sessão) e de longo prazo (usuário/produto) são stores com schema. Grave fatos verificáveis, preferências explícitas e resumos com carimbo de tempo. Evite “lembrar tudo”: isso multiplica risco de privacidade e de contexto poluído.

Quando usar cada abordagem

• Só Context Engineering: tarefas curtas com instruções e poucos fatos estáveis
• Context + RAG: perguntas sobre documentos, políticas e bases mutáveis
• Context + Memory: assistentes com continuidade e preferências
• Os três juntos: agentes em produção com retrieval, estado e continuidade

Relação com CAG e KAG

CAG (cache de conhecimento) e KAG (grafo) são estratégias de conhecimento que alimentam o contexto. Continuam subordinadas ao Context Engineering: mesmo com grafo perfeito, a janela precisa de política de embalagem. Detalhes de RAG vs CAG vs KAG ficam no artigo comparativo dedicado.

Antipadrões

• Despejar o histórico inteiro na janela “por garantia”
• Usar Memory como dump de transcripts sem curadoria
• RAG sem ACL e sem citação
• Tratar Context Engineering como sinonimo de prompt criativo
• Otimizar só o modelo quando o problema é montagem de contexto

Checklist rápido

1. Defina orçamento de tokens por feature
2. Separe blocos: system, evidence, state, history, memory
3. Exija ACL no retrieval antes de qualquer produção multi-tenant
4. Versionne sumários e políticas de retenção
5. Meça groundedness e tokens úteis, não só “satisfação subjetiva”

Emerson Amorim trata Context Engineering como disciplina de arquitetura em AI Engineering: a mesma lógica usada em pipelines RAG e em agentes com harness, onde memória e retrieval só entram com contrato explícito.