A Google mudou o modelo por trás do "stable" no Agent Search. Se você nunca escolheu, suas respostas mudaram

Se a aplicação de busca da sua empresa no Google Cloud Agent Search gera respostas e ninguém nunca definiu a versão do modelo, o modelo dela mudou em 16 de outubro.

Naquele dia, o Google atualizou o modelo stable de geração de respostas de gemini-2.5-flash/answer_gen/v1 para gemini-3.5-flash/answer_gen/v1. O Gemini 3.5 Flash estava disponível para geração de respostas desde 13 de agosto para quem o escolhesse explicitamente. O que mudou é o alias. E, segundo a documentação do Google, stable é o que uma aplicação recebe quando não especifica uma versão. A mesma página diz que o modelo por trás de stable “muda periodicamente conforme novos modelos e versões ficam disponíveis.”

É uma mudança estreita: a geração de respostas do Agent Search, não a API Gemini em geral, e a nota de versão não define data de desativação para o modelo antigo. Ainda assim, é o tipo de mudança que escapa de todos os controles que a maioria das empresas tem, porque nada no seu código, nos seus prompts ou na sua configuração mudou.

Mesma semana, mesmo padrão

Um dia depois, o alias deepseek-flash da DeepSeek também começou a servir o modelo atualizado. Dois fornecedores, dois aliases, uma semana. Aliases móveis são uma conveniência: as aplicações ganham modelos melhores sem um deploy. Também significam que o fornecedor decide quando o comportamento da sua aplicação muda.

Para busca enterprise, o que está em jogo é específico. A geração de respostas transforma documentos recuperados em uma resposta que um funcionário ou cliente lê como a resposta da empresa. Um novo modelo pode citar de outra forma, resumir com mais ou menos agressividade, responder onde o antigo se recusava por falta de grounding, ou se recusar onde antes respondia. Cada uma dessas é uma mudança de comportamento em um sistema que pode estar na frente de políticas de RH, documentação de produto ou conteúdo regulado.

O que checar esta semana

Encontre as aplicações no alias. Procure no seu código e na sua configuração por requisições de resposta que passam stable ou que não passam versão de modelo. Essas mudaram em 16 de outubro. As que têm uma versão explícita não mudaram.

Rode o conjunto de regressão que você rodaria para um release. Para respostas com grounding, as checagens úteis são precisão das citações (cada afirmação aponta para um trecho que a sustenta?), comportamento quando a recuperação não encontra nada, tamanho da resposta, latência e custo por consulta. Se você guardou respostas de antes de 16 de outubro, compare-as nas mesmas perguntas. Se não guardou, comece a guardar agora.

Decida entre alias ou versão fixa, por aplicação. Um assistente interno que responde perguntas sobre o cardápio da cantina pode usar o stable. Uma aplicação que responde a clientes sobre termos de contrato ou a pacientes sobre medicação deve fixar uma versão explícita e avançar de forma deliberada, com um teste e um aprovador, como defendemos quando as aposentadorias de modelos viraram calendários de mudança. Fixar a versão tem seu próprio dever: versões explícitas também são desativadas, e a documentação vincula os modelos do Agent Search ao ciclo de vida dos modelos base. Fixar move a data da mudança para as suas mãos; não remove a mudança.

Registre o modelo junto com a resposta. Se uma resposta for questionada algum dia, você vai querer saber qual modelo a produziu. Registre em log a versão resolvida do modelo junto com a consulta, as fontes recuperadas e a resposta.

A regra mais ampla

Uma dependência de modelo que é resolvida no momento da requisição é uma dependência que você não controla. Todo inventário de IA enterprise deve registrar, para cada aplicação, não só qual fornecedor e modelo ela usa, mas se ela chama uma versão fixa ou um alias, e quem é avisado quando o alias muda. Na maioria das vezes, a resposta para a segunda pergunta hoje é ninguém.