Neste artigo
- O que é cache semântico para LLMs e por que ele importa
- Quando faz sentido implementar cache semântico
- Como funciona o cache semântico na prática
- Cache semântico vs prompt caching: qual usar quando
- O que esperar de resultado e como medir
- Os riscos que aparecem depois de implementar
- Dúvidas comuns sobre cache semântico para LLMs
- Conclusão e próximo passo
Você olha a fatura da API no final do mês e percebe que uma parcela considerável veio de requests quase idênticos. Perguntas diferentes na forma, mas com intenção e resposta praticamente iguais. O modelo processou cada uma do zero, como se nunca tivesse visto nada parecido.
Isso não é falha de engenharia. É o comportamento padrão de qualquer LLM sem infraestrutura de cache. E acontece com frequência surpreendente em aplicações com volume real de usuários.
Trabalhei num produto de atendimento numa fintech onde o assistente recebia dezenas de variações da mesma pergunta por hora. ‘Como cancelo meu cartão’, ‘quero cancelar o cartão’, ‘como faço pra cancelar’. Custo individual aceitável. No agregado, pesava. Foi o primeiro contato que tive com cache semântico em produção de verdade, não em tutorial.
Cache semântico resolve exatamente esse cenário: reutilizar respostas do modelo para perguntas semanticamente similares, sem processar cada request do zero. Mas tem detalhe importante antes de sair implementando. Abaixo, você vai entender como funciona, quando vale o investimento e como medir se está funcionando de verdade.
O que é cache semântico para LLMs e por que ele importa
Cache semântico é uma camada intermediária entre o usuário e a API do LLM. Quando chega um request, o sistema verifica se existe uma resposta armazenada para uma pergunta semanticamente próxima. Se sim, devolve essa resposta em milissegundos, sem chamar o modelo. Se não, chama o modelo normalmente e guarda o resultado para próximos requests similares.
A diferença para cache convencional é que a comparação não é por texto exato. É por significado. Duas frases diferentes que perguntam a mesma coisa geram o mesmo cache hit.
Por que isso importa? Porque em aplicações reais, a diversidade de formulações de uma mesma dúvida é enorme, mas o espaço de intenções é muito menor. Um FAQ de produto pode ter 50 perguntas únicas mas 5.000 variações de usuários por dia. Sem cache semântico, você paga pelo processamento das 5.000. Com cache bem configurado, você paga pelas 50 mais a margem de misses.
Quando faz sentido implementar cache semântico
Não é toda aplicação que se beneficia. Antes de investir, vale checar três sinais.
Volume com padrões repetíveis
Cache semântico funciona quando a distribuição de intenções dos usuários é concentrada. Assistentes de atendimento, FAQs dinâmicas, buscas em base de conhecimento. Nesses casos, a taxa de repetição de intenção costuma ser alta o suficiente para justificar a estrutura. Aplicações abertas onde cada conversa é radicalmente diferente têm hit rate baixo e o cache vira overhead.
Custo por request escalando com o volume
Se o custo mensal de API está crescendo proporcionalmente com o número de usuários sem nenhuma economia de escala, é sinal que não há reutilização. Cache semântico bem implementado quebra essa proporcionalidade. O custo começa a crescer mais devagar que o volume.
Latência impactando experiência
Chamar um LLM custa entre 500ms e vários segundos dependendo do modelo e do tamanho do output. Um cache hit entrega a resposta em menos de 50ms na maioria das implementações. Se latência é crítica para a experiência, cache semântico resolve de forma mais limpa do que otimizar o modelo em si.
Como funciona o cache semântico na prática
O mecanismo tem três partes que você precisa entender para tomar boas decisões sobre configuração.
A camada de embeddings
Quando um request chega, o sistema gera um embedding da pergunta, que é uma representação numérica do significado. Esse embedding é comparado com os embeddings das perguntas já armazenadas. A comparação usa distância vetorial para medir o quanto as perguntas são semanticamente próximas. O modelo de embedding precisa ser bom o suficiente para capturar nuances do domínio. Um modelo genérico de embedding pode tratar como similares duas perguntas que, no seu contexto, têm respostas completamente diferentes.
O limiar de similaridade
Aqui mora a decisão mais importante. Você define um threshold: acima de determinado nível de similaridade, considera um hit e devolve o cache. Abaixo, chama o modelo. Threshold alto demais significa poucas economias e pouca chance de erro. Threshold baixo demais significa mais economia mas risco de devolver respostas erradas para perguntas que parecem similares mas não são. Não existe valor correto universal. O valor certo depende do domínio e você descobre ajustando com dados reais.
A política de expiração
Respostas cacheadas ficam obsoletas. Preços mudam, políticas mudam, informações de produto se atualizam. Sem política de expiração, o cache entrega informação velha com confiança. A política mais simples é TTL por tempo. A mais sofisticada invalida entradas específicas quando o conteúdo fonte muda. Qual escolher depende de quão dinâmico é o seu domínio.
Cache semântico vs prompt caching: qual usar quando
Essas são técnicas diferentes com propósitos diferentes, mas é comum misturar as duas.
Prompt caching opera na camada do modelo: reutiliza tokens de contexto já processados dentro de uma sessão ou entre sessões com prefixo idêntico. Economiza custo de input tokens quando você tem um system prompt longo que se repete.
Cache semântico opera na camada da aplicação: reutiliza respostas completas para perguntas semanticamente equivalentes. Economiza custo total do request, input e output.
Quando o gargalo é um system prompt gigante que se repete: prompt caching. Quando o gargalo é volume de perguntas similares de usuários diferentes: cache semântico. Em aplicações maiores, as duas técnicas coexistem sem conflito.
O que esperar de resultado e como medir
A métrica que importa é o cache hit rate. Porcentagem de requests respondidos pelo cache sem chamar o modelo. Um hit rate de 30% já produz economia relevante. Acima de 50% começa a mudar o perfil de custo de forma significativa.
Mas hit rate sozinho não basta. Você precisa medir também a qualidade das respostas cacheadas. A forma mais direta é amostragem com avaliação humana ou conjunto de evals automatizado: pega uma amostra de cache hits e verifica se a resposta era de fato adequada para a pergunta recebida. Se a taxa de erro for maior do que no fluxo sem cache, o threshold está baixo demais.
Monitore os dois juntos. Hit rate alto com qualidade degradada não é vitória. É um problema mais difícil de perceber porque o sistema parece mais rápido e mais barato enquanto entrega respostas erradas.
Os riscos que aparecem depois de implementar
Spoiler: os problemas mais chatos surgem depois que o cache está rodando há semanas.
O primeiro é a staleness silenciosa. O cache entrega uma resposta que estava correta quando foi gerada mas ficou desatualizada. Sem monitoramento de freshness, você não sabe quantos usuários receberam informação velha.
O segundo é o viés de distribuição. Se as primeiras respostas geradas tiverem qualidade ruim, o cache as perpetua. Um modelo mal configurado no início alimenta o cache com lixo e esse lixo fica disponível por tempo indefinido.
O terceiro é o cache poisoning por input adversarial. Um usuário que manipula a formulação da pergunta pode introduzir no cache uma resposta inadequada que depois é servida para outros usuários com perguntas legítimas. Em aplicações abertas ao público, isso é vetor real de problema.
Dúvidas comuns sobre cache semântico para LLMs
Cache semântico serve para qualquer tipo de aplicação com LLM?
Não. Funciona bem em aplicações com espaço de intenções previsível e volume repetitivo, como atendimento, FAQ, busca em base de conhecimento. Em aplicações criativas, conversas abertas ou análises personalizadas, a diversidade de inputs é alta demais para gerar hit rate relevante.
Qual modelo de embedding devo usar?
Depende do domínio. Modelos de embedding genéricos funcionam como ponto de partida, mas domínios técnicos ou com vocabulário específico se beneficiam de modelos ajustados. A forma de descobrir é comparar a qualidade dos hits com cada modelo usando um conjunto de pares de perguntas rotulados manualmente como ‘mesma intenção’ ou ‘intenções diferentes’.
Como definir o threshold de similaridade certo?
Não tem resposta antes de ver dados reais. O processo correto é começar com threshold conservador alto, coletar hits e avaliar qualidade, reduzir gradualmente enquanto monitora degradação. É ajuste empírico, não configuração teórica.
Cache semântico viola LGPD ou compromete privacidade dos dados?
Potencialmente sim, se as respostas cacheadas contiverem dados pessoais do usuário original. Antes de implementar, mapeie se as respostas do modelo incluem informações do input específico do usuário. Se sim, você precisa de política de expiração mais agressiva e possivelmente anonimização antes de armazenar.
Conclusão e próximo passo
Cache semântico não é bala de prata. É uma decisão de infraestrutura com trade-offs reais: entre custo e qualidade, entre hit rate e staleness, entre performance e risco de privacidade. O que diferencia uma implementação que funciona de uma que cria problema silencioso é ter métrica de qualidade rodando desde o primeiro dia, não só métrica de custo.
Se você quer começar com isso, o próximo passo concreto é:
- Medir qual fração dos seus requests atuais tem intenção repetida (análise de clustering nos inputs já existentes)
- Definir o que ‘resposta correta’ significa no seu domínio antes de configurar qualquer threshold
- Montar um conjunto pequeno de pares de perguntas para validar o modelo de embedding antes de colocar em produção
Se quiser entender mais sobre como avaliar qualidade de respostas de LLM antes de confiar no cache, o artigo sobre evals para IA em produção cobre exatamente esse processo. E se o gargalo for custo de tokens de contexto em vez de volume de perguntas repetidas, veja o artigo sobre prompt caching para LLMs.
