Pagando Duas Vezes

Como reconhecer

A busca semântica de um e-commerce gera um embedding para cada consulta e, nas consultas difíceis, chama um modelo para reescrever a busca. Uma amostra de uma hora de tráfego (anonimizada):

consulta                       vezes na última hora   chamadas pagas
"tênis preto"                  1.204                  1.204 embeddings
"tenis preto"                  388                    388 embeddings
"tênis preto masculino"        301                    301 embeddings + 301 reescritas
"notebook para programar"      277                    277 embeddings + 277 reescritas

As mesmas consultas, digitadas de novo por pessoas diferentes, são processadas do zero toda vez. Ao mesmo tempo, o assistente de compras do mesmo site manda um system prompt de 9 mil tokens, idêntico, em toda mensagem, sem cache de prompt.

Num marketplace brasileiro isso se mistura com NF-e e frete. A ficha do produto quase não muda. A pergunta “tem na voltagem 220?” se repete o dia inteiro. Cada repetição paga embedding, às vezes reescrita, às vezes o modelo de resposta.

Sinais de Pagando Duas Vezes:

• Entradas iguais ou equivalentes são processadas do zero a cada vez.
• O prefixo fixo do prompt (instruções, ferramentas, documentos) é grande e nunca usa cache.
• Os campos de tokens de cache no usage da API estão sempre zerados.
• Embeddings de textos que não mudam são recalculados.
• O custo cresce linear com o tráfego, mesmo com muita repetição.

flowchart LR
  Q1(["1. 'tênis preto'"]):::io --> M(["2. Processa do zero"]):::llm
  Q2(["1. 'tênis preto' de novo"]):::io --> M
  Q3(["1. 'tenis preto'"]):::io --> M
  M --> C[("3. Paga três vezes")]:::store

1. Entradas repetidas ou equivalentes chegam.
2. Cada uma é processada como se fosse nova.
3. O custo e a latência se repetem a cada vez.

Checagem +20 XP de primeiraEm uma hora, 'tênis preto' aparece 1.204 vezes e cada uma gera embedding do zero. Qual medida confirma o smell?

A latência p50 da busca

A distribuição de consultas repetidas e o custo por consulta distinta

O tamanho do índice vetorial

Por que acontece

• Cache parece otimização prematura. No começo o volume é baixo e a repetição não aparece.
• Prompt montado com dados variáveis no início. Uma data ou um id no começo do prompt impede o cache de prefixo.
• Ninguém olha a distribuição de entradas. Sem medir, não se sabe quanta repetição existe.
• Medo de resposta velha. Um cache sem regra de validade pode servir dado desatualizado, então o time prefere não ter cache.

Erro comum: ligar cache de prompt e deixar a data no topo

Provedores de modelo oferecem cache de prefixo: o trecho idêntico do começo do prompt se cobra mais barato nas próximas chamadas. A condição é o prefixo ser byte a byte o mesmo. Se a primeira linha é Data e hora atual: 14:31:07, o prefixo muda a cada segundo e o campo cache_read_input_tokens fica zerado. Você “ligou o cache” e continua pagando o prompt inteiro.

Quanto custa ignorar

• Dinheiro. Pagar de novo por trabalho já feito, em toda requisição repetida.
• Latência. Uma resposta que poderia vir em milissegundos leva segundos.
• Rate limit. Chamadas repetidas consomem a cota que faltaria nos picos.

Suponha, só para escala, US$ 0,0001 por embedding de consulta e US$ 0,01 por reescrita. Na hora da amostra, “tênis preto” e “tenis preto” sozinhas somam cerca de 1.600 embeddings. Sem cache, isso se repete todas as horas do dia. O prefixo de 9 mil tokens do assistente se soma em cima, em cada turno de cada conversa.

O primeiro cache que costuma pagar é o prefixo: ele não serve resposta velha de produto, só evita reler instruções que o modelo já viu. Meça cache_read_input_tokens depois de mover hora e id para baixo do bloco estável. Se o campo continuar zerado, você ainda não cacheou nada.

Tratamento

Refatoração	Escolha quando
Introduzir Cache	Há prefixo fixo grande ou entradas repetidas. Cache de prompt para o prefixo; cache exato ou semântico para respostas de perguntas equivalentes; cache de embeddings para textos que não mudam.

Três camadas, da mais segura para a mais delicada:

1. Prefixo do prompt. Instruções e ferramentas estáveis no começo, dados que mudam (hora, saldo, nome) depois. Confira cache_read_input_tokens de verdade, não só a flag ligada.
2. Embedding e busca. A chave é o texto normalizado. Recalcule quando o documento mudar, não a cada request.
3. Resposta. Só para perguntas estáveis (prazo de entrega, política de troca). Nunca para saldo, preço ao vivo ou status de pedido.

Normalizar (“tênis preto” e “tenis preto”) pega o cache exato. Equivalentes de verdade (“tênis preto masculino” vs “tênis preto para homem”) pedem cache semântico, com limiar medido num eval. Sem o limiar, você serve a resposta errada com confiança.

Checagem +20 XP de primeiraO assistente de compras manda um system prompt idêntico de 9 mil tokens em toda mensagem. Qual cache você liga primeiro?

Cache de prompt no prefixo fixo

Cache semântico de todas as respostas

Cache de embeddings das mensagens do cliente

O que você ganha

• Custo que cresce menos que o tráfego.
• Respostas instantâneas para o que é repetido.
• Cota livre para os picos.
• Uma medida clara de repetição, que mostra onde otimizar.

Quando ignorar

• Entradas sempre únicas. Documentos diferentes a cada pedido, sem prefixo comum relevante, não se beneficiam de cache.
• Respostas que mudam a cada segundo. Preço em tempo real, saldo de conta. Cache de resposta aqui é perigoso; cache de prompt ainda pode valer.
• Volume baixo. Se a fatura é pequena, a complexidade não compensa. O cache de prompt costuma ser só uma linha, então comece por ele.

É esse smell?

Checagem +20 XP de primeiraO system prompt tem 6 mil tokens e começa com 'Data e hora atual: 2026-10-02 14:31:07'. O cache de prompt está ligado, mas o cache_read_input_tokens é sempre zero. Por quê?

O provedor não suporta cache

O prompt é curto demais para cachear

O prefixo muda a cada chamada

Checagem +20 XP de primeiraUm chat de suporte guarda respostas por pergunta exata. 'Qual o prazo de entrega?' e 'qual é o prazo de entrega?' geram duas chamadas. O que considerar?

Normalizar a pergunta ou usar cache semântico

Nada, o cache exato já basta

Cachear o embedding do catálogo inteiro

Checagem +20 XP de primeiraO assistente responde o saldo da conta do cliente, que muda a cada transação. O time quer cachear as respostas. O que fazer?

Cachear por pergunta, por uma hora

Cachear a resposta por 24h e invalidar à meia-noite

Não cachear a resposta; cachear só o prefixo do prompt

Checagem +20 XP de primeiraA busca recalcula o embedding de cada ficha de produto em toda consulta, porque o texto vem do banco a cada request. O que fazer?

Cachear a resposta da busca por 1 segundo

Guardar o embedding junto do produto e só recalcular quando a descrição mudar

Parar de usar embeddings e buscar só por texto exato