Por que seu Semantic Cache está retornando respostas incorretas

Um usuário relatou que nosso plugin de tradução estava retornando o mesmo resultado em cache para todas as solicitações, independentemente da entrada. Investigamos e descobrimos algo pior: 95% de todos os acertos de cache semântico em nossa plataforma eram falsos positivos. 199 solicitações de tradução diferentes, 198 corpos de solicitação únicos, uma única resposta em cache servida para todos eles.

Se você se preocupa com o estado de agentes de longa duração e o tratamento de solicitações em produção, este post combina bem com Por que seu agente de IA continua perdendo a memória, o guia de chatbot com uma chave de API e o guia de limitação de taxa da API de IA.

Principais conclusões

• 95% dos acertos de cache semântico na plataforma eram falsos positivos, com 198 solicitações únicas recebendo a mesma resposta em cache.
• A causa raiz é a entrada estruturada. O texto de modelo fixo domina o vetor de embedding, de modo que o conteúdo variável quase não altera a similaridade de cosseno.
• Aumentar o limite de similaridade não resolve isso, porque as distribuições de acertos corretos e incorretos se sobrepõem. Pesquisas recentes sobre a confiabilidade do cache semântico confirmam o mesmo padrão.
• A correção funciona em duas camadas: extraia o conteúdo significativo antes do embedding e, em seguida, verifique cada acerto com um hash de impressão digital FNV-1a rápido. Isso reduziu os falsos positivos de aproximadamente 95% para menos de 5%.
• A escolha do modelo afeta a exposição. Prompts de sistema longos e entradas envolvidas em JSON tornam o problema pior, independentemente de qual modelo serve a conclusão; verifique o diretório de modelos do TokenLab (observado em 07/07/2026) para opções de modelos atuais se você estiver decidindo por quais deles rotear o tráfego em cache.

O relatório de bug

O relatório era simples: "Desativei o cache semântico, mas toda tradução retorna o mesmo resultado."

Três IDs de solicitação, três segmentos de tradução diferentes, respostas em cache idênticas. Os corpos das solicitações variavam de 1.564 a 8.676 bytes. O ID da resposta em cache era o mesmo para todos eles: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

Primeira suspeita: as configurações de cache do usuário não estavam sendo aplicadas. Isso acabou sendo um bug separado de sincronização de fonte de dados (o painel administrativo escrevia em uma tabela, o gateway da API lia de outra). Corrigir isso resolveu apenas metade do problema. Mesmo com o cache ativado e funcionando corretamente, o cache semântico estava correspondendo a solicitações que nunca deveriam corresponder.

Os dados de produção

Extraímos 24 horas de dados de acertos de cache do ClickHouse. Os números eram ruins.

Modelo	Total de Solicitações	Acertos de Cache	Solicitações Únicas	Respostas Únicas	Taxa de Acerto
DeepSeek V4 Flash	200	199	198	1	99,5%
glm-4.6-thinking	100	38	13	1	38%
gpt-5-nano	31	29	28	2	93,5%
gpt-oss-120b	18	17	17	1	94,4%
qwen3-vl-flash	17	16	16	1	94,1%

198 solicitações de tradução únicas, todas retornando a mesma resposta em cache. Isso não é um cache. Isso é uma função quebrada que retorna uma constante.

Cada modelo afetado compartilhava duas características: todas as solicitações vinham de um único usuário e todas usavam um modelo de prompt de sistema fixo com conteúdo variável do usuário. Para uma lista atual de modelos disponíveis na plataforma, o diretório de modelos do TokenLab (observado em 07/07/2026) é a fonte da verdade, já que as ofertas mudam frequentemente.

Como detectar isso em seu próprio sistema

Você não precisa de nossos logs para descobrir se tem o mesmo problema. O sinal mais rápido é a diversidade de respostas por modelo. Se um modelo tem uma alta taxa de acerto de cache, mas quase nenhuma resposta única, você está servindo uma resposta para muitas perguntas diferentes.

Aqui está a consulta estilo ClickHouse que usamos, generalizada:

SELECT
  model,
  count() AS total_hits,
  uniqExact(substring(response_body, 1, 200)) AS unique_responses,
  round(uniqExact(substring(response_body, 1, 200)) / count(), 3) AS diversity_ratio
FROM request_logs
WHERE cache_hit = true
GROUP BY model
ORDER BY total_hits DESC;

Um cache saudável tem uma diversity_ratio próxima de 1.0, o que significa que a maioria dos acertos retorna respostas distintas para entradas distintas. Uma proporção próxima de 0 significa que muitas solicitações colapsam em um punhado de respostas em cache. Qualquer valor abaixo de aproximadamente 0,5 em um modelo com variedade real de entrada merece investigação.

Se você não registra os corpos das respostas, um proxy mais barato também funciona: compare a contagem de corpos de solicitação únicos com a contagem de respostas únicas servidas a partir do cache. Quando 198 solicitações únicas mapeiam para 1 resposta, o cache não está correspondendo ao significado, está correspondendo ao texto padrão (boilerplate).

Um segundo indicador são as reclamações de usuários que se concentram em cargas de trabalho estruturadas. Plugins de tradução, resumidores, preenchedores de formulários e ferramentas JSON-in/JSON-out são os suspeitos usuais porque envolvem conteúdo variável em um modelo fixo.

Por que os embeddings falham em entradas estruturadas

O plugin de tradução envia solicitações como esta:

System: "Atue como uma API de tradução. Gere apenas um único objeto JSON bruto.
         Entrada: {"targetLanguage":"<lang>","title":"...","segments":[...]}"

User:   {"targetLanguage":"zh","title":"Página do Produto",
         "description":"Traduzir descrições de produtos",
         "tone":"formal",
         "segments":[{"text":"conteúdo variável real aqui"}]}

O prompt do sistema é idêntico em todas as solicitações. A mensagem do usuário é um objeto JSON onde targetLanguage, title, description e tone são fixos. Apenas segments[].text muda.

Quando nosso cache semântico extrai texto para embedding, ele concatena o prompt do sistema e a mensagem do usuário. O modelo fixo representa aproximadamente 80% do texto. O modelo de embedding (all-mpnet-base-v2, 768 dimensões) comprime isso em um vetor onde a estrutura do modelo domina. O conteúdo real da tradução quase não altera o resultado.

Resultado: a similaridade de cosseno entre "traduzir 'Olá mundo'" e "traduzir 'O relatório financeiro trimestral mostra um aumento de 15% na receita'" excede 0,95. Nosso limite é 0,95. Cada solicitação de tradução corresponde à primeira entrada em cache.

Analisando os logs, descobrimos três maneiras pelas quais isso falha:

O plugin de tradução é o pior infrator. Chaves e valores JSON fixos abafam os segmentos de tradução reais. Tanto o DeepSeek V4 Flash quanto o gpt-5-nano atingiram esse problema.

Um assistente de sumarização de contexto teve uma variação diferente do mesmo problema. Seu prompt de sistema era tão longo que o conteúdo do usuário, variando de 5KB a 47KB, mal era registrado no embedding. Foi assim que o glm-4.6-thinking acabou retornando o mesmo resumo para todas as conversas.

O terceiro padrão foi mais sutil. Para o gpt-oss-120b e o qwen3-vl-flash, os primeiros 500 caracteres de cada solicitação eram idênticos byte a byte. O conteúdo variável vinha depois, mas o embedding já estava dominado pelo prefixo compartilhado.

O que a pesquisa diz

Este não é um problema novo. Artigos recentes o quantificaram.

O projeto vCache da UC Berkeley descobriu que as distribuições de similaridade de acertos de cache corretos e incorretos se sobrepõem fortemente, o que significa que nenhum limite fixo separa claramente uma correspondência verdadeira de uma falsa estruturalmente semelhante. Essa descoberta corresponde exatamente ao que vimos em produção: os falsos positivos do plugin de tradução se concentraram acima de 0,95, bem dentro da faixa onde correspondências legítimas de paráfrases também vivem.

Outros trabalhos recentes sobre a confiabilidade do cache semântico chegam a conclusões semelhantes: a similaridade bruta de embedding é um sinal necessário, mas não suficiente, para a correção do cache, e qualquer sistema de produção que dependa apenas dele deve esperar uma taxa significativa de falsos positivos em tráfego estruturado e pesado em modelos.

A correção de duas camadas

A Camada 1 é a extração de conteúdo. Antes do embedding, remova o prompt do sistema fixo e a estrutura do modelo, e faça o embedding apenas do payload variável: o conteúdo real de segments[].text, não as chaves JSON e o texto padrão ao redor. Isso, por si só, aumenta drasticamente a relação sinal-ruído no vetor de embedding.

A Camada 2 é a verificação de impressão digital. Mesmo com uma extração melhor, conteúdo quase duplicado ainda pode produzir pontuações de similaridade altas. Antes de servir um acerto de cache, calcule um hash rápido (usamos FNV-1a) sobre o conteúdo extraído tanto da solicitação recebida quanto da entrada em cache. Se os hashes coincidirem exatamente, sirva o cache. Se não coincidirem, siga para uma conclusão nova ou, para tráfego de maior valor, roteie para uma chamada de verificação barata que pontua o significado, não os bytes.

O erro é pular a verificação completamente e confiar na similaridade de cosseno bruta. Cada abordagem na tabela supera isso. Comece com a mais barata que se ajusta ao seu tipo de consulta e só suba na escala quando medir perdas reais de paráfrases.

Juntas, essas duas camadas reduziram nossa taxa de falsos positivos de aproximadamente 95% para menos de 5% no tráfego afetado.

Quando o cache semântico é a ferramenta errada

O cache não é engenharia gratuita, e algumas cargas de trabalho não valem a pena ser armazenadas em cache.

• Tráfego de alta cardinalidade e baixa repetição. Se quase toda solicitação é única, como geração criativa pontual, a taxa de acerto é muito baixa para justificar a sobrecarga de embedding. Você paga para fazer o embedding de tudo e raramente colhe os frutos.
• Saídas que devem ser novas. Qualquer coisa sensível ao tempo, dados ao vivo, resultados personalizados, qualquer coisa com um "hoje" nela, pode retornar respostas obsoletas do cache mesmo quando a correspondência é tecnicamente correta. A resposta estava certa uma hora atrás e errada agora.
• Domínios de correção estrita. Para respostas médicas, jurídicas ou financeiras, um único falso positivo pode ser pior do que o custo economizado. Se você usar cache aqui, a camada de verificação é obrigatória, não opcional, e uma verificação de nível de LLM pode ser a única aceitável.
• Prompts minúsculos onde a chamada do modelo já é barata. Embedding, busca de similaridade e verificação têm seu próprio custo. Se a conclusão subjacente for de algumas centenas de tokens em um modelo barato, o cache pode custar mais do que economiza.

O cache brilha em conclusões repetitivas, pesadas em modelos e caras, exatamente as cargas de trabalho onde um falso positivo também é mais fácil de introduzir. Essa tensão é o motivo pelo qual a camada de verificação é importante. Se seu objetivo é principalmente o controle de custos, vale a pena combinar o cache com o roteamento de modelos mais baratos também. A comparação de preços e o guia dos melhores modelos de IA para codificação cobrem de onde vêm as economias por token, e o diretório de modelos do TokenLab (observado em 07/07/2026) mostra as opções atuais, incluindo escolhas de roteamento de baixo custo como DeepSeek V4 Flash e Gemini 3.5 Flash, se você estiver avaliando qual modelo usar para rotear tráfego em cache versus não cache. Verifique os preços atuais no diretório vinculado antes de se comprometer com um plano de roteamento.

Por que não apenas aumentar o limite?

Nosso limite já é 0,95. Aumentá-lo não ajuda. O problema é que entradas estruturalmente semelhantes produzem pontuações de similaridade acima de 0,95, não importa o que o conteúdo real diga.

Os dados do vCache confirmam isso: as distribuições de similaridade de acertos corretos e incorretos se sobrepõem tanto que nenhum corte único os separa. Aumente o limite para 0,99 e você eliminará acertos de cache legítimos para paráfrases genuínas, enquanto solicitações estruturalmente idênticas, como nossos payloads JSON de tradução, ainda se concentrarão acima de 0,99, independentemente do conteúdo. O limite não é a alavanca. A representação da entrada é. É por isso que a Camada 1 (extração de conteúdo) e a Camada 2 (verificação de impressão digital) funcionam onde um aumento de limite não funciona: elas mudam o que é comparado, não o quão rigorosa é a comparação.

Se você está construindo ou mantendo um cache semântico, trate o limite como um filtro grosseiro, não como uma garantia de correção. Combine-o com a extração de conteúdo para que o embedding represente realmente a parte variável da solicitação e, em seguida, adicione uma etapa de verificação barata para que uma correspondência de embedding quase correta nunca se torne silenciosamente uma resposta errada em produção.

Comece com o diretório de modelos do TokenLab para comparar preços e benchmarks atuais entre modelos de fronteira, codificação e roteamento de baixo custo antes de conectar sua camada de verificação de cache. Independentemente do modelo que esteja por trás do seu endpoint de conclusão, a abordagem de extração mais impressão digital é o que realmente corrige os falsos positivos.

FAQ

Aumentar o limite de similaridade corrige os falsos positivos do cache semântico? Não. Pesquisas do vCache e estudos relacionados mostram que as distribuições de acertos corretos e incorretos se sobrepõem em toda a faixa de limite, portanto, aumentar o corte bloqueia correspondências legítimas sem filtrar de forma confiável solicitações estruturalmente semelhantes, mas semanticamente diferentes.

Qual é a maneira mais barata de verificar um acerto de cache semântico? Um hash de impressão digital (FNV-1a ou similar) sobre o conteúdo extraído e significativo adiciona menos de um milissegundo de latência e é gratuito para calcular. Ele não detectará paráfrases, mas elimina falsos positivos exatos como os descritos aqui, que é onde a maior parte do dano em cargas de trabalho estruturadas ocorre.

Esse problema depende de qual modelo serve a conclusão? Não, o problema de falso positivo reside na camada de embedding e correspondência, não no modelo de conclusão. Qualquer modelo por trás de um cache semântico, seja DeepSeek V4 Flash, glm-4.6-thinking ou algo mais novo, será afetado da mesma maneira se o cache incorporar texto de modelo fixo junto com conteúdo variável. Verifique o diretório de modelos do TokenLab (observado em 07/07/2026) para a disponibilidade atual de modelos ao decidir quais modelos rotear através de um pipeline em cache.