Cenário ilustrativo. Um cliente pergunta duas vezes, na mesma manhã, ao agente de apoio se pode devolver uma encomenda aos 40 dias. Às 9:10 o agente responde: «Sim, tens 60 dias». Às 11:30, com as mesmas palavras, responde: «Segundo a tua encomenda, o prazo é de 30 dias; contacta um consultor». As duas respostas parecem razoáveis, foi o mesmo sistema que as gerou e uma delas está prestes a tornar-se uma reclamação. Ninguém mexeu em nada entre uma e outra.
A tese numa linha: a variabilidade de um modelo não é uma falha que se repara, é uma propriedade que se limita. Decides que partes do processo nunca podem variar, quais toleram variação e como a medes antes de um cliente a ver.
Porque é que a IA responde de forma diferente à mesma pergunta?
Porque um modelo de linguagem não vai buscar uma resposta guardada: calcula-a de cada vez. Em cada passo distribui probabilidades pelas palavras possíveis e escolhe uma, e essa escolha leva, por desenho, uma componente de acaso; o parâmetro que a regula chama-se temperatura. Por isso a mesma pergunta pode dar redações diferentes e, quando a pergunta deixa lacunas, conclusões diferentes.
Há mais três fontes de variação que costumam ser esquecidas. A primeira é o que rodeia a pergunta: a ordem em que o sistema recupera documentos, a data, o histórico ou a memória mudam o contexto e, com ele, a resposta. A segunda é o servidor: mesmo com a temperatura a zero, a maioria dos serviços de inferência não garante resultados idênticos, porque o cálculo numérico depende da carga que o servidor tem nesse momento (Thinking Machines, 2025). A terceira é o fornecedor: uma mudança de versão do modelo ou das suas definições altera o comportamento sem que toques em nada, o mesmo efeito que explicamos em porque piora um agente de IA com o tempo se ninguém mudou nada.
É possível eliminar a variabilidade baixando a temperatura?
Em parte, e também não convém por inteiro. Baixar a temperatura reduz a dispersão na redação, mas não a elimina (a fonte acima explica porquê), e não muda nem o que o modelo sabe nem o que lhe chega. Também não corrige o erro: a temperatura baixa, um modelo enganado engana-se de forma mais consistente. Desenvolvemos isto em reduzir alucinações de IA em produção. E alguma variação é precisamente o que queres: é o que permite que um resumo ou uma resposta se adapte ao caso em vez de soar a modelo de carta.
A pergunta útil não é «como consigo que responda sempre igual?», mas «em que pontos do processo não pode responder de forma diferente?».
Que partes de um processo têm de ser deterministas e quais toleram variação?
A regra: o que o cliente pode citar, e o que movimenta dinheiro ou compromissos, não sai de geração livre. Sai de uma regra, de um dado ou de um modelo; o modelo, quando muito, redige-o.
| Parte do processo | Tolera variação? | Onde deve viver |
|---|---|---|
| Prazos, montantes, condições, datas | Não | Num dado do teu sistema ou numa regra de código; o modelo cita-o, não o calcula |
| Decisão de encaminhamento ou classificação | Pouca | Saída fechada (uma lista de categorias), limiar de confiança e revisão dos casos duvidosos |
| Redação, tom, resumo | Sim | Nas instruções e nos exemplos; o modelo tem margem dentro deles |
| Ações com efeito (enviar, cobrar, apagar) | Não | Numa validação determinista antes de executar e em permissões delimitadas |
Se quase todo o teu processo cai nas linhas do «Não», talvez não precises de um agente: um fluxo clássico é mais barato e mais fácil de auditar, como explicamos em como automatizar processos com agentes, não com chatbots. E o que deixas ao modelo define-se nas suas instruções: o que deve citar, o que não pode afirmar e o que faz quando não tem o dado.
Como se mede a variabilidade de um agente antes de o pôr em produção?
Com um teste aborrecido e repetível. É um método, não um número mágico:
- Junta casos reais. Um conjunto de entradas da tua operação, incluindo as ambíguas e as raras, não as da demonstração.
- Repete-os. Passa cada entrada várias vezes pelo sistema completo (com a sua recuperação de documentos, não só o modelo) e guarda cada saída.
- Compara o que importa. Nos campos de decisão (categoria, montante, sim ou não), exige coincidência exata. No texto, compara com uma grelha: diz o mesmo no essencial?
- Fixa um limiar por campo. Um campo que movimenta dinheiro tolera zero discrepâncias; um resumo interno tolera mais. Decide os limiares antes de ver os resultados.
- Repete o teste a cada alteração. Modelo novo, instruções novas, fonte de documentos nova: volta a passar.
Esse teste é uma eval, e desenhá-la e mantê-la faz parte de avaliar a qualidade dos agentes de IA. Com o agente em funcionamento, o passo seguinte é medir o desempenho das tuas automatizações, para que a variação não se infiltre de noite.
O que fazes se duas respostas contraditórias já chegaram a um cliente?
Primeiro, reconstitui o que aconteceu: sem o registo da entrada, do contexto recuperado, da versão do modelo e da saída, não podes saber qual das duas estava certa. Depois, fecha a lacuna:
- Tira o dado do texto livre. Se a contradição era um prazo ou uma condição, deixa de o gerar: faz com que o leia de uma fonte única.
- Faz o sistema contrastar-se a si próprio. Nas respostas de risco, gera duas vezes e, se não coincidirem no essencial, não envies: passa a uma pessoa. Custa mais por resposta, por isso reserva-o para onde o erro sai caro.
- Ajusta a autonomia ao risco. O que não pode variar e não consegues validar automaticamente, que o reveja um humano antes de sair. É para isso que servem os níveis de autonomia de um agente e o humano no ciclo.
Quando não compensa perseguir a consistência?
Quando a saída é um rascunho que uma pessoa vai ler e retocar, quando o erro é barato e reversível, ou quando a variação é o valor (ideias, variantes de um texto). Exigir variação zero aí encarece o sistema sem proteger ninguém. Gasta o rigor onde uma resposta diferente custa dinheiro ou confiança, e deixa o resto respirar.
A linha para levares: não peças ao modelo que seja sempre igual; desenha o processo para que o que não pode mudar não dependa dele.
Fontes (consultadas a 29 de outubro de 2026): «Defeating Nondeterminism in LLM Inference», Thinking Machines Lab (10 de setembro de 2025), usada de forma qualitativa. O cenário de abertura é ilustrativo.