Cache semântico para chatbots de IA: respostas rápidas sem entregar dados desatualizados

Muitas perguntas feitas a um chatbot de website repetem-se: prazos de entrega, políticas de devolução, horário de funcionamento ou o passo seguinte numa reclamação. É natural reutilizar uma resposta já gerada. Um cache semântico vai mais longe do que um armazenamento chave-valor clássico: reconhece consultas formuladas de forma idêntica ou semelhante através de pesquisa vetorial e pode fornecer diretamente uma resposta anterior adequada. Isso economiza chamadas ao modelo e reduz o tempo de espera. Ao mesmo tempo, cria-se um novo fluxo de publicação que deve ser verificado com o mesmo rigor que a recuperação (retrieval) e a resposta do modelo.

A questão central não é «Qual é a taxa de acerto?», mas sim «Em que condições é que esta resposta concreta pode voltar a ser apresentada a este utilizador?» Este guia descreve uma arquitetura de cache que trata o cliente/inquilino, o idioma, as permissões, a versão do conhecimento e o contexto da conversa como partes integrantes da decisão.

Diferença entre cache de prompt e cache de resposta

O Prompt Caching do lado do fornecedor acelera prefixos de entrada recorrentes, mas continua a gerar uma nova resposta. Em contrapartida, um cache semântico de respostas guarda a consulta e o resultado na própria aplicação e, havendo semelhança suficiente, pode fornecer diretamente a resposta anterior. A segunda abordagem tem um impacto maior na latência e nos custos, mas também comporta maior risco: uma afirmação antiga, gerada para outro contexto, pode tornar-se visível sem uma nova verificação do modelo ou das fontes.

A documentação da Microsoft sobre caches semânticos descreve a pesquisa vetorial através de chaves de cache incorporadas (embeddings) e assinala que o contexto da conversa deve ser tido em conta. A pergunta isolada «Qual é o segundo maior?» é irrelevante se faltar o assunto anterior da conversa. Por isso, para chatbots de websites, a chave de cache nunca deve consistir apenas na última frase do utilizador.

Modelar explicitamente o escopo de validade

Uma linha no cache precisa de mais do que embedding, resposta e carimbo de data/hora. Armazene, no mínimo, uma estrutura técnica de validade:

• Inquilino e website: As respostas de diferentes clientes ou domínios nunca devem partilhar o mesmo espaço.
• Locale: Idioma, região e, se aplicável, variante de mercado devem fazer parte da chave.
• Classe de identidade e permissões: público, autenticado, função (role) e grupos de documentos autorizados.
• Versão do conhecimento: estado do índice ou do documento em que a resposta se baseia.
• Versão da configuração: prompt, rota do modelo, regras de segurança e esquema de ferramentas (tools).
• Pegada do contexto: apenas os atributos da conversa estritamente necessários para o significado, normalizados e com minimização de dados.

Uma consulta semelhante só pode ser procurada dentro do mesmo escopo de validade. A semelhança vetorial não substitui o controlo de acessos. Verifique as permissões antes de pesquisar no cache e novamente antes da exibição. Um resultado obtido num portal de clientes privilegiado nunca pode converter-se numa resposta pública de FAQ.

Guardar apenas respostas adequadas

Nem todas as respostas do modelo podem ser armazenadas no cache. Bons candidatos são informações estáveis, públicas e fundamentadas em fontes autorizadas. Deve excluir dados pessoais, saldos de conta, propostas individuais, stocks em tempo real, resultados de ferramentas em aberto e respostas com baixo nível de confiança. Um encaminhamento seguro para apoio humano ou a frase «Não sei» também podem ser armazenados temporariamente para mitigar uma sobrecarga conhecida, mas exigem um tempo de validade significativamente mais curto.

Sinalize a elegibilidade para cache após a validação da resposta, não antes. A etapa de verificação pode avaliar a cobertura das fontes, os tipos de dados permitidos, o estado das ferramentas e a classe de conteúdo. Defina também se apenas respostas validadas por humanos ou também respostas aprovadas automaticamente podem ser armazenadas.

A semelhança é um parâmetro de qualidade

Um limite (threshold) demasiado elevado gera poucos acertos e pouca poupança. Um valor demasiado baixo fornece respostas formalmente idênticas, mas com conteúdo incorreto. Determine o valor limite com um conjunto de teste composto por pares de perguntas reais: equivalentes, relacionadas mas diferentes, e claramente inadequadas. Meça a precisão dos acertos no cache separadamente por intenção (intent) e idioma. Um limite global único raramente é suficiente.

Em caso de dúvida, um cache miss é a decisão mais segura. O fluxo normal de RAG e do modelo pode então gerar uma resposta atualizada. Um acerto rápido mas incorreto sai mais caro do que uma chamada de modelo ligeiramente mais lenta, pois compromete a confiança, o tempo de suporte e, eventualmente, a proteção de dados.

Vincular a invalidação às fontes e não ao calendário

Um Time-to-live (TTL) genérico é útil, mas insuficiente. Uma página de preços ou de políticas pode ficar desatualizada imediatamente após uma alteração, mesmo que a entrada no cache tenha apenas alguns minutos. Por isso, guarde os IDs e as versões das fontes utilizadas juntamente com a resposta. Se uma fonte mudar, as entradas dependentes devem ser eliminadas ou marcadas como inválidas.

Além disso, cada classe de conteúdo precisa de uma idade máxima. Os horários de funcionamento podem ser válidos até à próxima alteração confirmada, enquanto o stock de armazém talvez nem deva ser armazenado em cache. Um fluxo do tipo stale-while-revalidate só deve ser aplicado a informações em que uma resposta temporariamente antiga seja aceitável e transparente. Para prazos legais, preços ou dados pessoais, uma falha direta (hard miss) é quase sempre o mais adequado.

Integrar a proteção de dados desde o início

Um cache semântico pode multiplicar o histórico de chat, embeddings e respostas a longo prazo. De acordo com o Artigo 5.º do RGPD, os dados pessoais devem ser tratados de forma leal, limitados ao estritamente necessário e conservados apenas durante o tempo preciso. Remova ou categorize dados sensíveis antes de criar a chave. Não guarde um endereço de e-mail no vetor apenas porque ele constava de uma pergunta.

Defina uma cadeia de eliminação: se uma conversa ou documento for eliminado, as entradas de cache dependentes e os respetivos embeddings também devem desaparecer. Registe os acessos administrativos ao conteúdo do cache e separe a telemetria do produto do armazenamento real de respostas. Fins analíticos não justificam automaticamente a retenção ilimitada.

Tornar os acertos visíveis e mensuráveis

Registe cache hit, motivo do miss, intervalo de semelhança, classe de idade, versão do conhecimento e a latência resultante – sem copiar a frase completa do utilizador para as métricas. Compare respostas em cache e respostas recém-geradas com os mesmos sinais de qualidade e de transição para atendimento humano. Uma taxa de acertos crescente só é positiva se as correções, reclamações e respostas sem fundamentação não aumentarem na mesma proporção.

Um Golden Set reduzido deve cobrir especificamente os riscos do cache: perguntas semelhantes sobre produtos diferentes, mudança de idioma, alteração de funções (roles), diretrizes atualizadas e perguntas de acompanhamento sem contexto suficiente. Teste a invalidação com o mesmo rigor que os acertos. O teste mais importante é: após uma alteração na fonte, a resposta antiga não pode voltar a aparecer.

Um processo seguro em sete passos

1. Normalizar a consulta e remover ou classificar valores sensíveis.
2. Definir inquilino, locale, classe de identidade e versão do conhecimento.
3. Procurar chaves semânticas semelhantes apenas no escopo de validade adequado.
4. Verificar o limite de semelhança, idade, estado da fonte e permissões.
5. Em caso de dúvida, acionar um miss e utilizar o fluxo de resposta normal.
6. Guardar uma nova entrada apenas após uma verificação de qualidade bem-sucedida.
7. Testar continuamente a qualidade dos acertos, a eliminação e a invalidação.

Conclusão: os limites do cache são limites de segurança

Um cache semântico de respostas pode tornar um chatbot de website notavelmente mais rápido e económico. No entanto, só se torna fiável quando a semelhança é apenas o ponto de partida da decisão. A separação de inquilinos, permissões, contexto, versões de fontes, retenção curta e um fluxo seguro em caso de miss evitam que a velocidade seja paga com respostas erradas ou indevidas.

Comece com uma única classe de intenções (intent) estável e pública. Meça a precisão e a invalidação nessa classe antes de disponibilizar outros conteúdos. Dessa forma, o cache cresce com base na qualidade comprovada e não apenas no número de chamadas ao modelo economizadas.

Fontes

• Microsoft Learn: Semantic Cache for Large Language Models
• EUR-Lex: Regulamento Geral sobre a Proteção de Dados, Artigo 5.º
• OWASP GenAI Security Project: LLM Risks and Mitigations
• NIST AI RMF Core: Measure e Manage