Gemini 3: o Google recomenda não mexer em temperature, top_p e top_k

A documentação do Gemini API não fala em “deprecar” esses parâmetros. A palavra usada é “não recomendado”, e a página não diz que a API os rejeita.

O que a documentação diz

Na página “What’s new in Gemini 3.5”, o Google escreve que temperature, top_p e top_k não são mais recomendados para os modelos Gemini 3.x, e orienta a remover esses parâmetros de todas as requisições. No lugar, a recomendação é usar instruções de sistema com regras explícitas quando você precisa de comportamento mais determinístico.

O guia do Gemini 3 é mais específico sobre temperatura. Recomenda manter o valor padrão de 1.0, porque o raciocínio do Gemini 3 é otimizado para esse valor. Reduzir abaixo de 1.0 pode causar comportamento inesperado, como loops ou desempenho pior, principalmente em matemática e raciocínio complexo. O guia cita Gemini 3.1 Pro, 3 Flash e 3.1 Flash-Lite, além dos modelos de imagem.

Outras mudanças da mesma página

• o nível de raciocínio padrão no 3.5 Flash passou de high (no Gemini 3 Flash Preview) para medium, e os níveis disponíveis são minimal, low, medium e high;
• o parâmetro numérico thinking_budget deixa de ser recomendado em favor de thinking_level, e não dá para combinar os dois na mesma requisição;
• respostas de função precisam ter id, name e quantidade correspondentes;
• a janela é de 1 milhão de tokens, com 65 mil de saída máxima.

O que fazer com isso

Se o seu código passa temperature: 0.2 para deixar respostas previsíveis, vale testar sem o parâmetro e comparar. A documentação não promete que o valor seja ignorado nem que dê erro, então não presuma nenhum dos dois. A versão anterior deste post afirmava que modelos como o Gemini 3.6 Flash já ignoravam os parâmetros. Não encontrei isso nas páginas citadas, e removi.