O cache semântico para LLM usa embeddings para reaproveitar respostas de perguntas com o mesmo significado, cortando 20-70% das chamadas; o limiar de similaridade controla o equilíbrio entre economia e falso positivo.
- Cache exato falha em linguagem natural; o semântico acerta por significado.
- O fluxo é: embed, buscar vizinho, comparar com o limiar, gerar no miss.
- Limiar alto economiza pouco; baixo entrega resposta trocada.
- Calibre o limiar com dados rotulados, não no chute.
- Use TTL, versão do prompt e escopo por usuário na chave.
Em automação de conteúdo, boa parte das chamadas a um modelo de linguagem é redundante — variações da mesma pergunta gerando, no fundo, a mesma resposta. Um cache semântico para LLM ataca exatamente esse desperdício: em vez de exigir que a pergunta seja idêntica para reaproveitar a resposta, ele reconhece quando duas perguntas querem dizer a mesma coisa e devolve o resultado já pago. Bem calibrado, corta de 20% a 70% das chamadas sem que o usuário note. Mal calibrado, devolve a resposta errada com cara de certa. A diferença está em um número: o limiar.
Por que o cache exato não basta
O cache tradicional usa a string da pergunta como chave: mesma string, mesma resposta. Funciona para conteúdo estático, mas desmorona em linguagem natural. “Como reduzir custo de API” e “de que forma eu corto o gasto com a API” são a mesma intenção e geram dois misses num cache exato. Como cada variação é uma chave nova, a taxa de acerto fica baixa justamente onde você mais paga: perguntas abertas e repetidas com palavras diferentes.
Como o cache semântico funciona
A ideia é trocar a chave textual por uma chave de significado. O fluxo tem quatro passos:
- Transforme a pergunta em um vetor (embedding) que representa o seu significado.
- Busque no banco vetorial o vetor mais próximo já armazenado.
- Se a similaridade passar de um limiar, é um acerto: devolva a resposta guardada.
- Se não, chame o modelo, devolva a resposta e guarde o par (vetor, resposta) para a próxima.
O embedding é barato perto da geração: você troca uma chamada cara de geração por uma chamada barata de embedding mais uma busca por similaridade. A escolha do banco — pgvector, Redis ou um banco vetorial dedicado — muda o custo em escala; comparamos as opções em qual banco vetorial usar.
Implementação enxuta
O núcleo cabe em poucas linhas. Aqui em Python, com similaridade de cosseno e um limiar explícito:
def semantic_cache_lookup(question, store, embed, threshold=0.92):
# store: lista de (vetor, resposta) já gerados
q_vec = embed(question) # 1) embedding da pergunta
best, best_sim = None, 0.0
for vec, answer in store: # 2) vizinho mais proximo
sim = cosine(q_vec, vec)
if sim > best_sim:
best, best_sim = answer, sim
if best_sim >= threshold: # 3) acerto acima do limiar
return best, best_sim, True # HIT — nao chama o modelo
return None, best_sim, False # 4) MISS — gere e guarde depoisEm produção você troca o laço linear por uma busca vetorial indexada (o banco faz isso), mas a lógica é essa: um número decide se você paga de novo ou não.
O limiar é tudo
Esse threshold equilibra dois erros opostos. Alto demais (ex.: 0.98) e quase nada bate — você volta a pagar por tudo. Baixo demais (ex.: 0.80) e perguntas diferentes são tratadas como iguais — o usuário recebe a resposta de outra pergunta. Esse falso positivo é o risco real do cache semântico, e é silencioso: não dá erro, só entrega conteúdo errado.
Calibre com dados, não no chute: separe algumas centenas de pares de perguntas, marque quais são de fato equivalentes e suba o limiar até que os falsos positivos sumam. Para domínios sensíveis (jurídico, médico, financeiro), seja conservador e prefira perder um acerto a entregar a resposta trocada.
Invalidação, TTL e versão do prompt
Resposta cacheada envelhece. Três salvaguardas evitam servir algo obsoleto:
- TTL: dê validade às entradas (horas para dados voláteis, dias para conhecimento estável).
- Versão do prompt: inclua a versão da sua instrução de sistema na chave. Mudou o prompt, o cache antigo não vale mais.
- Escopo por usuário: nunca deixe a resposta de um usuário vazar no cache de outro — cacheie por inquilino quando o conteúdo for específico.
Quando NÃO cachear
Cache semântico é para respostas estáveis e repetíveis. Evite em saídas que precisam ser únicas (geração criativa que não pode repetir), em dados em tempo real (preço, estoque) e em qualquer fluxo onde devolver “quase a mesma coisa” é inaceitável. Combinado a outras alavancas — como reduzir o custo de tokens e tratar bem o limite de requisições — ele vira uma das economias mais previsíveis da sua stack de IA.
Exato x semântico
| Critério | Cache exato | Cache semântico |
|---|---|---|
| Chave | String da pergunta | Vetor de significado |
| Acerto em linguagem natural | Baixo | Alto |
| Custo por consulta | Quase zero | 1 embedding + busca |
| Risco principal | Pouco acerto | Falso positivo (resposta trocada) |
Checklist
- Gere embedding da pergunta e busque o vizinho mais próximo.
- Defina o limiar com dados rotulados, não no chute.
- Seja conservador em domínios sensíveis.
- Use TTL, versão do prompt e escopo por usuário na chave.
- Não cacheie saída criativa única nem dado em tempo real.
Perguntas frequentes
Qual a diferença entre cache exato e semântico?
O cache exato exige a mesma string para reaproveitar a resposta; o semântico reaproveita quando duas perguntas têm o mesmo significado, mesmo escritas de formas diferentes. Em linguagem natural, o semântico tem taxa de acerto muito maior.
Qual o maior risco do cache semântico?
O falso positivo: um limiar baixo trata perguntas diferentes como equivalentes e entrega a resposta de outra. É silencioso, não dá erro. Por isso calibra-se o limiar com dados rotulados e adota-se postura conservadora em domínios sensíveis.
Que limiar de similaridade devo usar?
Não existe número universal. Comece perto de 0.92 com similaridade de cosseno e ajuste com um conjunto rotulado de pares equivalentes, subindo até os falsos positivos desaparecerem sem zerar os acertos.
