Cache semântico para LLMs: quando reutilizar uma resposta

O cache semântico pode eliminar chamadas repetidas ao modelo, desde que perguntas formuladas de maneiras diferentes possam receber a mesma resposta com segurança. O fluxo tem 4 etapas: gerar o embedding do prompt, buscar vizinhos, aplicar um limiar e, por fim, devolver uma resposta armazenada ou chamar o modelo. A parte difícil é reconhecer quando uma correspondência próxima ainda leva à resposta errada.

Comece por uma central de ajuda com conteúdo estável ou pelas perguntas frequentes públicas de um produto. Um modelo de linguagem de grande porte (LLM), o sistema que gera a resposta, não deveria precisar explicar a mesma política publicada toda vez que alguém muda a forma de perguntar. Saldos de contas, status de pedidos e ações como emitir reembolsos devem ficar fora desse cache compartilhado.

Os detalhes de implementação a seguir foram verificados na documentação primária em 21 de outubro de 2026. O exemplo da loja é fictício; suas pontuações de similaridade servem para ilustrar uma decisão, não são resultados medidos de embeddings.

Cache semântico, cache exato e cache de prompts: o que muda?

Um cache semântico reutiliza uma resposta anterior quando uma nova solicitação parece ter o mesmo significado. Pense em um atendente que busca uma resposta aprovada em um arquivo: maneiras diferentes de perguntar podem levar à mesma ficha, mas ele ainda precisa conferir a qual política e cliente ela se aplica.

Um embedding é uma representação numérica de um texto usada para comparar significados. O cache armazena o embedding de um prompt anterior junto com sua resposta e o contexto que a identifica. Um novo prompt vira outro embedding, e uma busca vetorial procura entradas próximas. A documentação sobre cache semântico da Microsoft descreve esse padrão de reutilização de respostas e explica por que o contexto da conversa importa.

Cada camada de cache evita um tipo diferente de trabalho:

No cache exato de respostas, “Posso devolver estes fones de ouvido?” e “Estes fones de ouvido podem ser devolvidos?” normalmente têm chaves diferentes. O cache semântico pode reconhecer a relação entre essas paráfrases. Nenhuma das abordagens torna segura uma resposta desatualizada ou aplicada ao escopo errado.

O cache de prompts do provedor não recupera uma resposta antiga porque a pergunta parece semelhante. A documentação sobre cache de prompts da Anthropic descreve a reutilização de prefixos de prompt correspondentes e separa explicitamente esse processo da geração da saída. Sua aplicação continua pedindo ao modelo que produza uma resposta. O guia sobre KV cache explica o estado interno do modelo por trás dessa diferença.

As camadas podem coexistir: consulte primeiro um cache exato de respostas, depois um cache semântico e, por fim, chame o modelo com o cache de prompts do provedor, quando disponível. Meça o ganho do cache semântico em relação a essa configuração já otimizada.

Como o cache semântico de respostas de LLMs funciona em quatro etapas

A consulta deve encontrar uma resposta reutilizável dentro de um contexto permitido. Defina esse contexto antes de buscar: o usuário ou tenant autenticado, a política aplicável, o idioma e qualquer outro dado que altere o que a resposta pode dizer.

1. 1

   1. Gere o embedding do prompt

   Converta a pergunta recebida em um embedding usando o mesmo modelo de embeddings e uma configuração compatível com a das entradas armazenadas. Inclua o contexto da conversa necessário para interpretar a solicitação ou restrinja o cache a perguntas que façam sentido por si só.

   “E o meu?” não é uma chave de cache completa. Se entender a que “meu” se refere exige dados privados de um pedido, não use o cache compartilhado de respostas.

2. 2

   2. Busque os vizinhos

   Procure candidatos próximos entre os embeddings de prompts armazenados, dentro do escopo permitido. Recupere a resposta e os metadados de cada candidato: os campos que descrevem a quem ele pertence, a versão da fonte e sua expiração.

   O vizinho mais próximo é apenas a entrada mais próxima encontrada. Ela ainda pode ser irrelevante. Encontrar algo não significa ter um hit no cache.

3. 3

   3. Aplique o limiar e as verificações de elegibilidade

   Compare a similaridade ou a distância do candidato com o limite que você calibrou. Em seguida, exija correspondência exata nos campos que alteram a resposta, como a condição do produto, a versão da política e o escopo de acesso.

   Se a pontuação passar, mas o contexto não, trate o resultado como um miss. Faça o mesmo quando não for possível determinar o contexto necessário com confiança.

4. 4

   4. Devolva a resposta ou chame o modelo

   Em um hit aceito, devolva a resposta armazenada sem uma nova chamada de geração. Em um miss, execute o fluxo normal do modelo ou de recuperação de informações, devolva o resultado e só o armazene se ele atender às regras de admissão no cache.

   Não transforme automaticamente toda saída do modelo em uma resposta reutilizável. Erros, dados pessoais e respostas vinculadas a resultados transitórios de ferramentas podem ser inadequados.

A diferença importante em relação à busca semântica está no que acontece depois da recuperação. A busca apresenta material relevante; um cache de respostas pode apresentar diretamente uma resposta anterior como a resposta à solicitação atual. Por isso, uma correspondência incorreta tem consequências maiores.

Um hit válido e uma correspondência quase perfeita que deve ser rejeitada

Mudar uma única condição pode invalidar uma correspondência que, de resto, parece convincente. Imagine uma loja cuja política permite devolver fones de ouvido em embalagens fechadas, mas exclui os que já foram abertos. Esses são dados didáticos, não uma descrição da política de qualquer varejista.

O cache contém:

• Pergunta armazenada: “Posso devolver fones de ouvido com a embalagem fechada?”
• Resposta armazenada: “Sim. Fones de ouvido com a embalagem fechada são elegíveis para devolução pela política desta loja.”
• Contexto armazenado: a versão atual da política da loja, a categoria de fones de ouvido, o idioma inglês e condition=unopened.

Apenas para este exemplo, suponha que a similaridade de cosseno mínima seja 0.90. A similaridade de cosseno compara a direção dos vetores; ela não é a probabilidade de uma resposta estar correta. As pontuações abaixo são fictícias e servem para mostrar a decisão.

Os dois candidatos superam o limiar numérico. Só a paráfrase pode reutilizar a resposta. A correspondência quase perfeita mantém o produto, a ação e boa parte das palavras, mas muda o fato que determina a resposta.

A aplicação deve registrar a condição em um campo estruturado quando ela for conhecida. Se precisar extraí-la do texto, uma extração incerta deve encaminhar a solicitação para o fluxo normal de resposta. Outra comparação de embeddings não substitui saber se o item foi aberto.

Os ajustes que tornam a reutilização segura

Limiar, tempo de vida e escopo funcionam em conjunto. Ajustar só o limiar deixa o cache vulnerável a solicitações perfeitamente semelhantes que precisam de respostas diferentes.

Limiar de similaridade: calibre com base nas respostas erradas

Um limite mais rigoroso abre mão de alguns hits úteis para reduzir as correspondências incorretas. Um limite mais permissivo aumenta a reutilização e pode aumentar também a reutilização indevida. A partir do tráfego da sua aplicação, monte um conjunto rotulado de paráfrases e negativos difíceis: perguntas semelhantes cujas respostas precisam ser diferentes.

Inclua mudanças de datas, variantes de produtos, negações, moedas, perfis de acesso e históricos de conversa. Avalie se a resposta armazenada é válida para a nova solicitação, em vez de verificar apenas se os prompts tratam do mesmo assunto.

Entenda a métrica antes de alterar o ajuste. A Redis Vector Library (RedisVL), biblioteca para criar aplicações com busca vetorial no Redis, documenta distance_threshold em unidades de distância COSINE do Redis, de 0 a 2; valores menores exigem correspondências mais estritas. Já um limiar mínimo de similaridade costuma funcionar no sentido oposto. Referência da API RedisVL.

Não existe um limite universal que possa ser copiado entre modelos de embeddings, conjuntos de dados ou produtos. Trocar o modelo de embeddings também exige uma migração planejada do índice e uma nova calibração; vetores antigos e novos não devem ser misturados sem critério.

Tempo de vida: a expiração é só uma proteção adicional

O tempo de vida (TTL) determina por quanto tempo uma entrada permanece elegível antes de expirar. Defina-o pelo tempo que você tolera uma resposta antiga, não pelo tempo que o cache consegue guardá-la.

Uma resposta sobre documentação estável e uma resposta sobre disponibilidade de estoque em tempo real têm necessidades diferentes de atualização. Pode ser melhor deixar a segunda fora do cache. Uma correção emergencial de política deve invalidar imediatamente as entradas afetadas, mesmo que o TTL delas ainda não tenha vencido.

Inclua a versão da fonte ou da política na verificação de elegibilidade. Quando essa versão muda, as entradas antigas deixam de corresponder. O RedisVL oferece tanto um TTL padrão quanto ajustes por entrada, mas cabe à aplicação definir o prazo adequado. API de cache do RedisVL.

Escopo por usuário: a identidade exige correspondência exata

Use o cache compartilhado apenas para respostas que podem ser compartilhadas. Um tenant é uma organização cliente; limitar o acesso por tenant não basta quando os funcionários dessa organização têm permissões diferentes.

Uma resposta específica de uma conta precisa de um escopo que reflita o usuário autenticado e suas permissões atuais. “Qual é a minha data de renovação?” não deve buscar entre todas as pessoas que fizeram a mesma pergunta. Obtenha a identidade pela autenticação confiável da aplicação, não por uma frase fornecida pelo usuário nem por um embedding.

Aplique os filtros de escopo antes de selecionar o candidato e valide a autorização antes de devolver a resposta. Mudanças de permissão e exclusões devem invalidar a reutilização afetada. Os recursos filterable_fields e filter_expression do RedisVL oferecem mecanismos de filtragem; eles não definem automaticamente a política de autorização da sua aplicação. Parâmetros de filtragem.

Contexto e versões: preserve as premissas da resposta

Delimite as entradas pelo prompt de sistema, requisitos de modelo, esquema de saída, idioma e versão da fonte que afetam a resposta. Um parágrafo em cache não atende a uma nova solicitação que exige uma resposta estruturada diferente.

No cache de conversas, a mesma frase final pode se referir a assuntos anteriores distintos. A explicação sobre a janela de contexto da Microsoft explicita essa falha. Comece por perguntas independentes, a menos que consiga representar e validar o histórico relevante.

Como implementar: gateway, arquitetura com Redis ou biblioteca

Escolha o ponto de integração conforme o lugar em que você consegue impor os limites de uso da resposta. As opções a seguir são exemplos de implementação, não um ranking de produtos intercambiáveis.

No gateway: Kong AI Semantic Cache

O Kong AI Semantic Cache, plugin da oferta AI Gateway Enterprise da Kong, coloca o cache semântico de respostas no gateway, o ponto de entrada por onde passam as solicitações ao modelo. Sua documentação descreve consultas baseadas em embeddings com configurações de Redis ou pgvector. A referência de configuração expõe cache_ttl, message_countback e vectordb.threshold.

Essa opção se encaixa em fluxos repetíveis de solicitações com gestão centralizada. Sua principal limitação é o contexto da aplicação: um gateway só consegue impor as distinções que você leva para a configuração e para as solicitações. Verifique o isolamento entre usuários e o tratamento do histórico antes de habilitá-lo em um chat personalizado.

Há também um detalhe de nomenclatura que merece atenção: a visão geral do plugin da Kong informa que habilitar a opção de cache exato não desativa as correspondências por similaridade. Não interprete essa opção como um modo de segurança que aceita apenas correspondências exatas.

Cache semântico com Redis

O Redis, um sistema de armazenamento de dados com recursos de busca vetorial, permite que a aplicação controle a consulta e o caminho seguido em caso de miss. O SemanticCache documentado pelo RedisVL oferece as operações check e store, metadados, filtros e controles de TTL. Documentação do RedisVL.

Use essa arquitetura quando a aplicação já conhece o tenant e as versões da política e dos registros, e precisa verificar essas condições antes de devolver um resultado. O mesmo padrão arquitetural pode ser implementado com outro armazenamento vetorial adequado: os vetores dos prompts localizam candidatos, enquanto as respostas e os metadados armazenados determinam o que pode ser reutilizado.

A contrapartida é a responsabilidade. Um índice vetorial não fornece regras de admissão no cache, invalidação, autorização nem uma resposta correta. Você precisa implementar e monitorar esses comportamentos, além de operar um ambiente que suporte as consultas vetoriais utilizadas.

Como biblioteca: GPTCache

O GPTCache, uma biblioteca para construir caches semânticos, separa a geração de embeddings, o armazenamento de respostas, a busca vetorial e a avaliação de similaridade em componentes configuráveis. Sua documentação alerta explicitamente que nem todas as combinações de módulos são compatíveis.

Essa opção atende a quem quer experimentar os componentes de recuperação e avaliação dentro da aplicação. Sua principal limitação é a responsabilidade pela integração: verifique os adaptadores escolhidos com o SDK atual do modelo e seu ambiente de execução, e mantenha as mesmas verificações de escopo e atualização ao redor da biblioteca. A abstração de uma biblioteca não torna correto um hit semântico.

Se você também está escolhendo a camada de roteamento de solicitações, consulte o comparativo de gateways de IA e LiteLLM vs OpenRouter para essa decisão mais ampla. O cache é um requisito ao lado de roteamento, credenciais e observabilidade.

Calcule a economia com o perfil real das suas solicitações

Um cache só economiza dinheiro quando os custos de geração evitados superam os gastos com embeddings, consultas, armazenamento e operação. Conte também os misses: eles pagam o custo adicional do cache e ainda chamam o modelo.

Use um único período de medição e uma única moeda. Considere N como o número de solicitações elegíveis que chegam à camada semântica, depois dos hits no cache exato; H, os hits semânticos aceitos; G, o custo de geração por solicitação, com a hipótese simplificadora de custos iguais; E, o custo de embedding mais consulta por solicitação elegível; W, o custo de gravação no cache por miss; e F, o custo fixo de infraestrutura e operação no período.

O cálculo fica assim:

• Sem a camada semântica: N × G
• Com a camada semântica: (N − H) × G + N × E + (N − H) × W + F
• Economia líquida: H × G − N × E − (N − H) × W − F

Faça a conta com seus logs: multiplique os hits aceitos pelo custo do modelo que eles evitaram, subtraia os custos de consulta de todas as solicitações elegíveis, subtraia as gravações dos misses e, por fim, os custos fixos. Use o custo de geração após qualquer benefício do cache de prompts do provedor, não o preço de tabela sem cache.

Com essas premissas, a condição para superar o ponto de equilíbrio é:

H > [N × (E + W) + F] / (G + W)

Para uma carga de trabalho mista, substitua H × G pela soma dos custos de geração efetivamente evitados nas solicitações que tiveram hit. Conte as gravações reais caso algumas respostas não sejam admitidas no cache. Inclua novas tentativas, chamadas de avaliação e trabalho operacional nos totais correspondentes. A taxa de hits, sozinha, não mostra se a reutilização compensou seus custos.

O mesmo raciocínio vale para a latência. Os hits retiram a geração do caminho; os misses acrescentam embedding e busca antes da geração. Meça os dois percursos, incluindo a latência das respostas mais lentas. Uma carga formada principalmente por solicitações únicas pode ficar mais lenta, mesmo que seus hits ocasionais sejam rápidos.

O que há de exagerado nas promessas do cache semântico?

“Significado parecido” não garante respostas equivalentes. O cache seleciona uma resposta existente; ele não comprova que ela continua correta, autorizada ou atualizada.

A métrica mais enganosa é uma taxa de hits em alta sem uma auditoria das reutilizações incorretas. Um limiar mais permissivo pode melhorar o painel e, ao mesmo tempo, aumentar o retrabalho da equipe de suporte. Revise as respostas em cache à luz das novas solicitações, especialmente aquelas mais próximas do limite de aceitação.

O cache de respostas também não substitui a geração aumentada por recuperação (RAG), em que o modelo recebe material recuperado de fontes para ajudar a produzir uma resposta. Um cache pode vir antes desse fluxo, mas pular o fluxo também significa abrir mão de uma nova consulta às fontes. Vincule as respostas em cache às versões das fontes ou não reutilize respostas quando os fatos subjacentes precisarem estar atualizados.

Trate “cancele meu pedido” como uma ação, não como uma pergunta reutilizável. Uma confirmação anterior não comprova que uma nova ação foi autorizada ou executada. Mantenha a execução e seu resultado atual no fluxo normal da aplicação.

Quem deve começar agora e quais são os próximos passos

Quem desenvolve aplicações com perguntas públicas repetidas deve começar agora, com escopo restrito. Escolha uma intenção estável, defina o escopo permitido e mantenha uma configuração de referência com cache exato. O benefício é reduzir chamadas repetidas de geração sem ampliar os tipos de resposta que a aplicação pode reutilizar.

Quem opera a aplicação deve primeiro avaliar em modo sombra. Registre qual resposta do cache teria sido devolvida enquanto continua entregando a resposta normal. Rotule as paráfrases verdadeiras e as correspondências quase perfeitas que precisam ser rejeitadas; depois, calibre o limiar para evitar erros inaceitáveis. Meça o custo adicional do cache, o comportamento da expiração e a qualidade da própria resposta armazenada.

Quem contrata uma solução deve pedir evidências de isolamento e invalidação. Marcar “cache semântico” em uma lista de recursos não basta. Pergunte como o sistema lida com perguntas idênticas de usuários diferentes e o que acontece imediatamente após uma mudança de política.

Espere se a maioria das perguntas depender de registros que mudam ou de um contexto de várias interações que você não consegue isolar. Se as repetições exatas já cobrem o tráfego reutilizável, a busca semântica pode acrescentar pouco. O cache de prompts do provedor ainda pode ajudar com prefixos de entrada repetidos, sem exigir a reutilização de uma resposta pronta.

Para começar na segunda-feira: escolha uma intenção da central de ajuda, reúna paráfrases e alternativas deliberadamente confusas, defina o escopo do cache e a regra de invalidação, e reproduza essas solicitações em modo sombra. Habilite a reutilização de respostas só depois de confirmar que os casos que levariam a respostas erradas são rejeitados com segurança.

Perguntas frequentes

O que é cache semântico?

É o armazenamento de respostas anteriores para recuperá-las por similaridade de significado. A reutilização também deve exigir contexto correspondente, permissões válidas e atualização adequada.

Quais são os três tipos de cache?

Para esta decisão envolvendo LLMs, diferencie o cache exato de respostas, o cache semântico de respostas e o cache de prompts do provedor. Essa comparação é útil para este artigo, mas não constitui uma classificação universal de todos os caches da computação.

Como implementar cache semântico?

Defina o escopo permitido, gere embeddings dos prompts recebidos, recupere candidatos, aplique um limiar calibrado e verificações de elegibilidade e, então, devolva a resposta armazenada ou chame o modelo. Adicione expiração, invalidação e monitoramento de hits incorretos antes de habilitar a reutilização.

Uma CDN é apenas um cache?

Não. Uma rede de distribuição de conteúdo (CDN) distribui a entrega de conteúdo entre diferentes localidades; o cache é um dos mecanismos que ela usa. Veja a arquitetura de CDN da Cloudflare.

A Cloudflare é uma CDN ou um WAF?

A Cloudflare oferece tanto serviços de CDN quanto um firewall de aplicações web (WAF), que filtra o tráfego das aplicações. Nenhuma dessas classificações, por si só, significa cache semântico de respostas de LLMs. Arquitetura da Cloudflare.

Qual é a diferença entre CDN e Redis?

Uma CDN entrega conteúdo por uma rede de borda. O Redis é um sistema de armazenamento de dados que uma aplicação pode usar como cache, inclusive em uma arquitetura configurada para cache semântico. Eles ocupam partes diferentes do sistema.

A Cloudflare é só uma CDN?

Não. A Cloudflare também documenta serviços de DNS, firewall e outros serviços de borda em sua arquitetura de referência.

Kafka é melhor que Redis?

Eles resolvem problemas diferentes. O Apache Kafka é uma plataforma de streaming de eventos. Ele não substitui diretamente a arquitetura de cache semântico de respostas com Redis descrita aqui.

A Netflix usa Redis?

Sim. O Redis documenta o uso do Redis pela Netflix para filas com prioridade, com um link para o texto da Netflix sobre o Timestone. Esse exemplo histórico não é evidência de cache semântico para LLMs nem motivo para habilitá-lo na sua aplicação.

Para receber orientações práticas sobre como criar aplicações de IA confiáveis, assine a newsletter.