Guia prático de cache para respostas e buscas com IA

Cache hit não significa resposta certa. Cache só ajuda quando a aplicação sabe o que pode reutilizar, por quanto tempo e dentro de quais limites.

A mesma pergunta não deveria custar tudo de novo

Nos guias anteriores, passamos por RAG, chunking, embeddings, retrieval, respostas estruturadas, evals, observabilidade e segurança. Depois de montar essas camadas, aparece uma pergunta natural: como evitar repetir a mesma busca e a mesma geração toda vez?

Cache pode reduzir chamadas, tokens e tempo de resposta. Mas, em aplicações com IA, ele não é apenas uma decisão de performance. É uma política de consistência: o sistema precisa saber quando um resultado antigo ainda pode ser usado e quando deve voltar para a fonte, para a busca ou para o modelo.

Uma resposta rápida também pode estar errada

Imagine um assistente que responde perguntas sobre documentação técnica. Uma pessoa pergunta como configurar o timeout de um worker. O sistema busca documentos, monta o contexto, chama o modelo, valida a saída e devolve a resposta. Se a mesma pergunta aparece pouco depois, repetir todo o fluxo pode ser desperdício.

Agora imagine que a documentação mudou, a segunda pessoa não pode acessar o documento usado antes ou a primeira resposta foi criada com outra versão de prompt e outro formato de saída. Devolver o resultado anterior continua rápido e barato, mas pode estar incorreto. A chave de cache precisa representar o contexto que torna a resposta válida.

Cache não é uma coisa só

• Prompt ou context cache reaproveita o processamento de um prefixo estável, mas o modelo ainda gera uma nova resposta.
• Cache exato devolve uma resposta pronta quando encontra a mesma chave válida.
• Cache semântico procura perguntas com significado parecido e tenta reutilizar uma resposta anterior.
• Cache de embedding evita recalcular o vetor do mesmo texto com o mesmo modelo e processamento.
• Cache de retrieval reaproveita documentos, IDs ou chunks recuperados para uma busca.
• Cache HTTP ou CDN pode guardar uma resposta de endpoint, desde que conteúdo privado e variações de requisição estejam controlados.

Um modelo mental em cinco perguntas

1. Repetição: qual trabalho está acontecendo de novo?
2. Validade: por quanto tempo o resultado continua correto?
3. Limites: para quem e em qual contexto ele vale?
4. Camada: qual cache evita apenas o trabalho repetido?
5. Medição: como detectar economia, desatualização e falso acerto?

Sem observar repetição, cache vira otimização por intuição. Sem definir validade, TTL vira um número arbitrário. Sem limites de tenant, usuário, idioma e permissão, a aplicação pode compartilhar uma resposta que nunca deveria atravessar aquele contexto.

Prompt cache não é cache de resposta

No prompt caching, a aplicação continua solicitando uma geração. O ganho vem do reaproveitamento de uma parte estável da entrada, como instruções, exemplos, ferramentas, documentos ou o início da conversa. A parte nova ainda precisa ser processada e o modelo ainda produz uma saída.

1prompt cache2  prefixo estável + pergunta nova3  -> modelo gera nova resposta45cache de resposta6  chave válida encontrada7  -> resposta pronta

OpenAI, Anthropic e Google documentam mecanismos próprios para reaproveitar contexto. Eles diferem em suporte, retenção, limites e dados de uso, e esses detalhes mudam com APIs e modelos. O princípio mais durável é manter conteúdo grande e estável no início, a parte variável depois e medir o que realmente foi reutilizado.

Comece pelo cache exato quando ele resolver

Cache semântico parece mais inteligente, mas também cria uma nova classe de erro. Quando a aplicação recebe entradas idênticas e consegue construir uma chave completa, cache exato costuma ser mais previsível e fácil de testar.

Mesmo assim, a pergunta sozinha raramente representa tudo. A validade pode depender de organização, idioma, acesso, ambiente, versão da documentação, prompt, modelo, ferramentas, schema e regras de segurança.

1tenant:locale:permissionScope:knowledgeBaseVersion:promptVersion:model:responseSchema:normalizedQuestion23acme:pt-BR:developer:docs-v42:support-v3:model-a:answer-v2:como-configuro-o-timeout-do-worker

A chave real pode ser serializada e transformada em hash. O importante é o raciocínio: se `docs-v42` vira `docs-v43`, a aplicação passa a procurar outra entrada. As respostas antigas podem expirar depois sem bloquear a publicação da nova documentação.

Normalizar a pergunta muda a definição de igualdade

Remover espaços duplicados, padronizar maiúsculas e serializar filtros de forma estável pode aumentar acertos exatos. Mas normalização agressiva pode apagar detalhes importantes. Se números forem removidos, perguntas sobre timeout de 30 e 300 segundos podem virar a mesma chave.

Cache exato continua dependendo de uma definição correta de igualdade.

Cache semântico: mais acertos, mais responsabilidade

No cache semântico, a aplicação gera um embedding da nova pergunta e procura uma entrada anterior próxima o suficiente. Se a similaridade ultrapassa o threshold e os filtros obrigatórios batem, a resposta pode ser reutilizada.

• Threshold frouxo pode servir respostas para intenções diferentes.
• Threshold rígido demais transforma quase tudo em miss.
• Filtros de tenant, idioma, versão e segurança precisam ser limites duros.
• O conjunto de evals precisa incluir paráfrases positivas e negativos difíceis.

1positivo esperado:2Onde altero o tempo limite do worker?34negativo próximo:5Qual é o timeout atual do worker em produção?

As perguntas são próximas no tema, mas não pedem a mesma coisa. A primeira busca uma instrução. A segunda pede um estado atual, possivelmente dinâmico e restrito. Similaridade não substitui intenção, contexto ou autorização.

Onde cache entra em um fluxo de RAG

1pergunta2  -> embedding da consulta3  -> busca e filtros4  -> chunks recuperados5  -> montagem do prompt6  -> modelo7  -> resposta

Cachear o embedding evita recalcular o vetor, mas busca e geração continuam. Cachear retrieval evita repetir busca e filtros, mas o modelo ainda responde. Cachear a resposta final pode pular quase todo o fluxo, mas também corre o maior risco de esconder mudanças na fonte.

A chave de retrieval precisa considerar modelo de embedding, versão do índice, filtros, permissões e parâmetros relevantes da busca. Em um fluxo dinâmico, prompt cache sobre o contexto recuperado só ajuda quando existe repetição real daquele prefixo.

TTL responde tempo; invalidação responde mudança

TTL responde por quanto tempo uma entrada pode ser reutilizada. Invalidação por evento responde o que mudou e tornou a entrada antiga. Um TTL curto limita a idade; uma versão na chave separa conteúdo novo e antigo; uma invalidação remove ou torna inacessíveis respostas quando documento, permissão ou regra muda.

• Documento publicado, atualizado ou removido.
• Índice reprocessado ou modelo de embedding trocado.
• Permissão ou grupo de acesso alterado.
• Prompt, modelo, ferramentas ou schema modificados.
• Política de segurança revisada.

O cache precisa ser descartável e reconstruível. A fonte de verdade continua fora dele.

Permissão não é detalhe da chave

Verificar autorização apenas antes de gravar não basta. A leitura também precisa respeitar o acesso atual. Uma resposta pode ter sido criada legitimamente e permanecer armazenada depois que a permissão mudou. Se o valor é entregue antes da verificação, o cache vira um atalho ao redor da autorização.

• Separe namespaces por tenant quando necessário.
• Inclua escopo de acesso na chave ou em filtros obrigatórios.
• Revalide autorização na leitura em fluxos privados.
• Invalide entradas afetadas quando permissões mudarem.

Cache de resposta não substitui idempotência

Uma feature que responde é diferente de uma ferramenta que altera estado. Se um agente recebe o pedido para criar uma tarefa, devolver `tarefa criada` do cache não prova que a ação atual aconteceu. Também não é seguro executar novamente sem pensar em idempotência, autorização, confirmação, auditoria e estado atual.

Cache de texto não deve fingir que uma operação ocorreu. E uma solicitação parecida não deve reutilizar o efeito de outra execução.

Como validar se funcionou

• Performance: hit rate e miss rate por camada, além de latência p50 e p95 separada para hits e misses.
• Custo: chamadas e tokens evitados, mais leitura, escrita, embeddings e armazenamento adicionados.
• Corretude: idade das respostas, falsos acertos semânticos, divergência de versão, idioma, tenant ou ambiente.
• Segurança: respostas usadas depois de mudança de permissão e falhas de autorização.
• Qualidade: avaliação humana ou automática de uma amostra dos hits.
• Operação: camada e motivo do hit, versões usadas e capacidade de desativar o cache.

Hit rate alta não basta. Se o sistema reutiliza respostas velhas ou semanticamente erradas, a métrica está celebrando o problema. Economia e qualidade precisam aparecer na mesma análise.

Quando não usar cache

• Existe pouco volume e quase nenhuma repetição.
• A resposta muda em tempo real ou depende muito do usuário.
• A aplicação não consegue representar permissões com segurança.
• A fonte muda com frequência e não existe estratégia de invalidação.
• O custo operacional do cache supera o trabalho evitado.
• O time ainda não consegue medir falsos acertos semânticos.
• O domínio tem alto risco e uma resposta antiga pode causar dano.
• O fluxo executa ações com efeitos colaterais.

Como começar simples

1. Meça quais entradas, prefixos ou buscas realmente se repetem.
2. Escolha uma única camada para testar.
3. Comece com cache exato quando ele resolver o problema.
4. Construa uma chave que represente contexto, versões e limites.
5. Use um TTL conservador e defina eventos de invalidação.
6. Registre hit, miss, idade, camada e motivo.
7. Compare latência e custo antes e depois.
8. Revise uma amostra das respostas reutilizadas.
9. Adicione cache semântico apenas com evals positivos e negativos.

Fechamento

Cache bom evita trabalho repetido. Cache ruim repete erro com mais velocidade. A decisão não começa em Redis, CDN ou no botão que ativa prompt caching. Começa em entender o fluxo: o que se repete, por quanto tempo vale, para quem serve, qual camada deve agir e como um falso acerto será detectado.

Quando essas respostas estão claras, cache deixa de ser um atalho genérico para reduzir custo. Ele vira uma decisão de arquitetura que equilibra performance, consistência, segurança e qualidade.