Por que a mesma pergunta gera respostas diferentes

Faça a mesma pergunta duas vezes pro mesmo modelo e você recebe dois textos diferentes. Isso não é defeito nem "criatividade" no sentido humano da palavra: é o resultado direto de como o modelo escolhe cada palavra, uma decisão estatística de cada vez.

O que o modelo faz a cada palavra

Um modelo de linguagem não "sabe" a resposta e a escreve de uma vez, como uma pessoa recuperando uma memória. Ele gera texto token a token, e a cada passo calcula uma distribuição de probabilidade sobre todos os tokens possíveis que poderiam vir a seguir, dado tudo que já foi escrito até ali.

Se o sistema sempre escolhesse o token de maior probabilidade nessa distribuição, a saída seria completamente determinística — sempre a mesma pra mesma entrada. Na prática, isso tende a produzir texto repetitivo, genérico e às vezes travado em loops, porque textos naturais e bem escritos raramente são formados só pela palavra mais estatisticamente óbvia a cada momento. Bons textos variam ritmo, escolhem sinônimos, fazem escolhas menos previsíveis que ainda fazem sentido.

Por isso, em vez de sempre pegar o token mais provável, o sistema costuma sortear dentro dessa distribuição de probabilidade — dando chance real a opções além da mais óbvia, ponderadas pela própria probabilidade. Sorteio implica variação por definição: mesmo com a mesma pergunta de entrada, o caminho escolhido a cada palavra pode divergir, e uma vez que diverge num ponto, todo o texto que vem depois segue por um caminho diferente.

Os controles que existem

Quem usa modelos de linguagem por API geralmente tem acesso a parâmetros que ajustam esse comportamento de sorteio:

Temperatura. Esse parâmetro achata ou concentra a distribuição de probabilidade antes do sorteio acontecer. Com temperatura próxima de zero, o modelo quase sempre escolhe o token mais provável — a saída fica estável e previsível, mas às vezes engessada e repetitiva. Com temperatura mais alta, opções menos prováveis ganham chance real de serem escolhidas — o texto fica mais variado e mais "criativo" no sentido estatístico, com o custo de um risco maior de saída menos coerente ou até sem sentido.
Top-p, também chamado de nucleus sampling. Em vez de mexer na distribuição inteira, esse controle limita o sorteio a um subconjunto: o menor grupo de tokens cuja probabilidade somada ultrapassa um limite definido. Na prática, isso corta a "cauda longa" de opções muito improváveis e provavelmente ruins, sem achatar artificialmente as opções boas que sobram. É um jeito de permitir variedade sem abrir a porta pra escolhas absurdas.
Seed. Quando exposto pela interface de programação usada, esse valor fixa o ponto de partida do processo de sorteio, tornando a saída reproduzível — a mesma entrada, com o mesmo seed e os mesmos demais parâmetros, tende a gerar o mesmo resultado.

Por que temperatura zero não garante saída idêntica

Essa é a parte que mais surpreende quem espera determinismo perfeito. Mesmo configurando o modelo pra sempre escolher a opção de maior probabilidade, execuções em infraestrutura de computação distribuída e paralela podem divergir de leve entre uma chamada e outra.

A explicação está em detalhes de baixo nível de como os cálculos são executados: a ordem exata das operações de ponto flutuante em processamento paralelo, o agrupamento de requisições que chegam ao mesmo tempo (batching), e até qual hardware específico atende cada requisição podem mudar minimamente os últimos dígitos de precisão das probabilidades calculadas. Na maioria das vezes isso não importa, porque a diferença é ínfima demais pra mudar qual token "ganha". Mas quando dois tokens estão com probabilidades quase empatadas, essa diferença mínima de precisão pode inverter qual dos dois é escolhido — e a partir desse ponto de divergência, o restante do texto segue por um caminho diferente, porque cada token novo depende de tudo que veio antes.

Ou seja: "temperatura zero" reduz drasticamente a variação, mas não é uma garantia absoluta de saída idêntica bit a bit em toda execução, especialmente em sistemas de produção operando em escala.

Um exemplo prático de como isso aparece no dia a dia

Imagine pedir duas vezes pro modelo resumir o mesmo parágrafo em uma frase. Com temperatura alta, é bem provável que as duas frases resultantes usem estruturas e palavras diferentes, ainda que capturem a mesma ideia central — um efeito desejável se o que você quer é variedade de opções de redação. Agora imagine pedir duas vezes pro modelo extrair, de um texto, apenas um número específico mencionado nele. Se a configuração de temperatura estiver alta, existe risco real do modelo "enfeitar" a resposta de formas levemente diferentes a cada vez, ou até variar detalhes que deveriam ser fixos — porque a mesma lógica de sorteio se aplica independente da tarefa, a menos que você ajuste os parâmetros para o tipo de trabalho que está fazendo.

O que fazer na prática

A escolha certa de configuração depende inteiramente do tipo de tarefa:

Para extração de dados, classificação, ou geração de saída estruturada (como o JSON discutido no post sobre fazer a IA devolver JSON), use temperatura baixa e, sempre que possível, valide a saída contra um schema definido — reduzindo tanto a variação indesejada quanto o risco de formato inválido.
Para redação criativa, geração de ideias e variação de texto, temperatura mais alta é exatamente o que produz o resultado desejado — múltiplas opções genuinamente diferentes entre si, em vez de variações mínimas da mesma frase.
Se o requisito real é reprodutibilidade perfeita e auditável, não confie inteiramente no modelo pra recriar a mesma saída depois, mesmo com seed fixo — guarde a saída já gerada como registro, em vez de assumir que basta rodar de novo com os mesmos parâmetros pra obter resultado idêntico.

Vale lembrar também que, além dos parâmetros de amostragem, o próprio modelo por trás de uma API pode ser atualizado silenciosamente pelo provedor ao longo do tempo — o que introduz outra fonte de variação que não tem relação nenhuma com temperatura ou seed, apenas com o fato de que a versão do modelo respondendo hoje pode não ser exatamente a mesma de um mês atrás.

O ponto

Variação de resposta não é falha do modelo — é consequência direta de como ele funciona, gerando texto por sorteio probabilístico em vez de recuperação determinística de uma resposta fixa. O erro comum não é o modelo variar, é usar uma configuração pensada para texto criativo numa tarefa que na verdade exige resposta estável e previsível. A solução não é lutar contra a natureza probabilística do modelo — é configurar os parâmetros de acordo com o que a tarefa realmente precisa.