Cache Semântico e Memória em LLMs: Latência, Custo e Contexto que Aprende

Este é o terceiro artigo da série LLMOps em Produção. No artigo anterior sobre roteamento de modelos LLM, vimos como escolher entre modelos quality, balanced e budget. Aqui entramos no próximo bloco de otimização: depois que o roteador escolhe o modelo, ainda existe uma fronteira grande entre o prompt e o dólar gasto. Essa fronteira é preenchida por cache e memória — dois mecanismos que parecem fazer a mesma coisa, mas resolvem problemas diferentes.

O problema operacional é conhecido. Você sobe um chatbot em produção e descobre nas primeiras 48 horas que:

• 40% das perguntas são variações das mesmas dúvidas.
• O system prompt de 8.000 tokens é reenviado integralmente a cada requisição, mesmo sendo idêntico em 99% das chamadas.
• A conversa acumula histórico até estourar a janela de contexto.
• O custo da API dobra semana após semana sem que o produto tenha dobrado de usuários.

Cache mal feito não reduz custo: troca custo de inferência por custo de retrabalho, churn e respostas erradas em produção.

Principais aprendizados

• Cache exato atende prompts determinísticos; cache semântico atende perguntas paráfraseadas — confundir os dois gera respostas erradas com aparência de acerto.
• Prompt cache nativo do provider (Anthropic, Google) economiza recomputação de prefixo sem mudar a semântica; exige separar system prompt (cacheável) de user message (variável).
• Cache semântico exige threshold alto (0.95+ com cosseno) e namespace por tenant; threshold baixo transforma cache em uma fonte de bugs silenciosos.
• Invalide por versão de modelo, atualização de dados e mudança de regra de negócio — nunca deixe cache com TTL infinito.
• Memória de conversa não é "guardar tudo": é janela deslizante + sumarização + RAG sobre histórico relevante.

Cache exato vs cache semântico: dois problemas, duas soluções

Prompt cache nativo do provider: a vitória fácil

Antes de construir cache próprio, use o que o provider já oferece. A Anthropic mantém prompt caching e a Google tem context caching para Gemini.

Chunking de mensagens: o que é cacheável

// ✅ Bom: separa prefixo cacheável de partes variáveis
const cachedPrefix = [
  {
    role: 'system',
    content: SYSTEM_PROMPT_FIXED, // instruções, regras, few-shot — nunca muda
  },
];

const variableSuffix = [
  {
    role: 'system',
    content: `Data atual: ${new Date().toISOString()}`, // muda a cada dia
  },
  ...history,
  { role: 'user', content: userQuestion },
];

Memória de conversa: janela, sumarização e RAG

Padrão 1: janela deslizante com buffer

function pushToWindow(memory: SlidingMemory, msg: ChatMessage): ChatMessage[] {
  memory.messages.push(msg);
  if (memory.messages.length > memory.maxMessages) {
    memory.messages = memory.messages.slice(-memory.maxMessages);
  }
  return memory.messages;
}

Padrão 2: sumarização do histórico

Padrão 3: RAG sobre conversas passadas

async function recall(memory: ConversationMemory, query: string): Promise<MemoryFact[]> {
  const queryEmbedding = await embed(query);
  const scored = memory.facts.map((fact) => ({
    fact,
    score: cosine(queryEmbedding, fact.embedding),
  }));
  return scored
    .filter((s) => s.score >= RECALL_THRESHOLD)
    .sort((a, b) => b.score - a.score)
    .slice(0, 5)
    .map((s) => s.fact);
}

Vector store para cache semântico: pgvector, Pinecone, Qdrant

Similaridade cosseno e threshold

function cosine(a: number[], b: number[]): number {
  if (a.length !== b.length) {
    throw new Error(`dimensões incompatíveis: ${a.length} vs ${b.length}`);
  }
  let dot = 0;
  let normA = 0;
  let normB = 0;
  for (let i = 0; i < a.length; i++) {
    dot += a[i] * b[i];
    normA += a[i] * a[i];
    normB += b[i] * b[i];
  }
  const denom = Math.sqrt(normA) * Math.sqrt(normB);
  return denom === 0 ? 0 : dot / denom;
}

Recomendação prática: comece em 0.95 e só abaixe se tiver evals medindo taxa de falso positivo.

Namespace por tenant

async function semanticLookup(
  store: VectorStore,
  key: SemanticKey,
): Promise<CachedAnswer | null> {
  const candidates = await store.search({
    vector: key.embedding,
    filter: { tenantId: key.tenantId }, // filtro obrigatório
    topK: 5,
  });
  const hit = candidates.find((c) => c.score >= key.threshold);
  return hit ? hit.payload : null;
}

Implementação: cachedCompletion em TypeScript

async function cachedCompletion(
  req: CompletionRequest,
  deps: {
    exact: ExactCache;
    semantic: SemanticStore;
    model: (req: CompletionRequest) => Promise<string>;
    embed: (text: string) => Promise<number[]>;
    ttlSeconds: number;
  },
): Promise<CompletionResponse> {
  const start = Date.now();

  // 1. cache exato
  const exactKey = `exact:${req.tenantId}:${hashPrompt(req)}`;
  const exactHit = await deps.exact.get(exactKey);
  if (exactHit) {
    return { text: exactHit, fromCache: 'exact', latencyMs: Date.now() - start };
  }

  // 2. cache semântico
  const semHit = await semanticLookup(deps.semantic, req.tenantId, req.user);
  if (semHit && semHit.modelVersion === req.model) {
    return { text: semHit.answer, fromCache: 'semantic', latencyMs: Date.now() - start };
  }

  // 3. miss — chama o modelo
  const text = await deps.model(req);

  // 4. popula ambos os caches com TTL e versão
  await deps.exact.set(exactKey, text, deps.ttlSeconds);
  await deps.semantic.upsert({
    tenantId: req.tenantId,
    prompt: req.user,
    answer: text,
    embedding: await deps.embed(req.user),
    modelVersion: req.model,
    ttlSeconds: deps.ttlSeconds,
  });

  return { text, fromCache: 'miss', latencyMs: Date.now() - start };
}

Headers de prompt cache na API

const response = await anthropic.messages.create({
  model: 'claude-3-5-sonnet-20241022',
  max_tokens: 1024,
  system: [
    {
      type: 'text',
      text: SYSTEM_PROMPT_FIXED,
      cache_control: { type: 'ephemeral' }, // marca prefixo para cache
    },
  ],
  messages: variableMessages,
});

TTL e invalidação: quando o cache mente

1. Mudança de versão do modelo

Trate modelVersion como parte da chave e invalide entradas antigas no rollout.

2. Atualização de dados

Use namespace por domínio (domain: 'refund-policy') — invalida tudo daquele domínio sem mexer no resto.

3. Mudança de regra de negócio

A resposta "não atendemos domingo" passa a estar errada quando a loja passa a atender domingo. Sem invalidação, o cache continua servindo a resposta antiga até o TTL expirar.

Anti-patterns: como cache vira incidente de produção

• Cachear resposta com PII sem anonimizar: vaza dados entre usuários semanticamente próximos.
• TTL infinito: a única forma de corrigir uma resposta errada é esperar o usuário reclamar.
• Cache compartilhado entre tenants sem namespace: vaza respostas entre organizações.
• Threshold de similaridade muito baixo: infla hit rate e destrói confiança.
• Cache de chamadas non-determinísticas (temperature > 0): cria inconsistência.
• Misturar prompt cache do provider com cache de saída sem distinguir: perde capacidade de diagnosticar regressões.

Observabilidade: o que medir em cache

A métrica de falso positivo é a mais negligenciada e a mais importante para cache semântico.

Como aplicar hoje

1. Audite o tráfego atual: quais prompts são idênticos em mais de 30% das chamadas?
2. Implemente cache exato primeiro: Redis com TTL de 1h para FAQs.
3. Ative prompt cache do provider: identifique system prompt estável, marque com cache_control.
4. Só então adicione cache semântico: comece com threshold 0.95, namespace por tenant.
5. Defina política de invalidação: por versão de modelo, por domínio, por regra de negócio.
6. Adicione memória de conversa em camadas: janela deslizante primeiro, sumarização, RAG por último.

Checklist de cache e memória pronto para produção

• Cache exato implementado com TTL e chave normalizada.
• System prompt separado de user message para permitir prompt cache.
• cache_control aplicado no prefixo estável.
• Cache semântico tem threshold ≥ 0.95.
• Toda chave (exata e semântica) carrega tenantId.
• modelVersion é parte da chave; invalide em rollout.
• Respostas com PII não entram em cache semântico.
• Existe TTL máximo operacional mesmo para conteúdo estável.
• Amostragem periódica mede falso positivo no cache semântico.
• Métricas separadas para hit exato, hit semântico e miss.
• Memória de conversa tem política explícita de janela e sumarização.
• Dashboard mostra dólares economizados e taxa de falso positivo lado a lado.

Conclusão

Cache e memória são as duas maiores alavancas de custo e latência em sistemas de LLM em produção — e também duas das formas mais fáceis de servir a resposta errada com aparência de eficiência.

A disciplina básica é separar as camadas: cache exato para o determinístico, cache semântico para o paráfraseado, prompt cache do provider para o prefixo, memória de curto prazo para a sessão, memória de longo prazo para o usuário.

A regra que vale repetir: hit rate não é objetivo. Objetivo é resposta correta com menor custo.

No próximo artigo da série, sobre guardrails em runtime para LLM, vamos fechar o ciclo: mesmo com roteamento correto, cache eficiente e memória bem desenhada, ainda é preciso validar entrada, saída e efeitos colaterais em tempo de execução.

Referências

• Prompt caching — Anthropic
• Context caching — Google Gemini API
• Prompt caching — OpenAI
• pgvector: open-source vector similarity search for Postgres
• Pinecone documentation
• Qdrant documentation
• Building effective agents — Anthropic
• Demystifying evals for AI agents — Anthropic