Agentes GPT perdem até 11,3 pontos de precisão quando o relatório do simulador fica em um arquivo

Calcular corretamente não garante que o agente chegue à resposta certa. Um novo estudo, que apareceu no Hugging Face Daily Papers, mostra como isso acontece em um esquema popular de gerenciamento de contexto: a saída longa de uma ferramenta é salva em um arquivo, e o agente procura nele o que precisa usando um índice de seções. No simulador geoquímico PHREEQC, do USGS, os modelos GPT-5.1 e GPT-5.2 perdem 11,3 e 7,9 pontos de precisão nesse modo. Claude Opus 4.6 e Claude Sonnet 4.6 não mostram perda perceptível.

Um campo de testes em que cada número pode ser rastreado

A escolha do PHREEQC não foi aleatória. O simulador é amplamente usado, e seus relatórios chegam a 846,8 mil caracteres. Ele também é determinístico, então qualquer valor impresso pode ser rastreado até a origem. Os agentes resolveram 158 questões de múltipla escolha, e a correção de cada uma foi confirmada por execução. Esse formato permite separar duas causas de erro: o modelo rodou a simulação de forma errada ou leu o resultado de forma errada.

Os autores reexecutaram todas as 11 007 chamadas do simulador registradas em log e verificaram com que frequência o agente chega a obter o valor necessário. Para os dois modelos GPT, essa taxa quase não mudou. Ou seja, eles não passaram a simular pior. O que mudou foi a fonte da qual tiram a resposta.

Substituição de evidências

Essa falha foi batizada de evidence substitution. Quando precisam procurar o relatório por um índice, os modelos GPT muitas vezes o ignoram. Eles respondem com base nos próprios arquivos de saída, em que os números aparecem com mais casas decimais, e, ao arredondar, erram para a alternativa vizinha. O cálculo está certo, mas a opção escolhida não.

O efeito não se explica por uma pior capacidade de cálculo. Com a simulação fixada, a busca ainda custa 9,4 pontos ao GPT-5.2. No GPT-5.4, o quadro é mais interessante: a variação final é indistinguível de zero. Mas esse saldo zero resulta de dois efeitos opostos. Simulações corretas com mais frequência somam precisão, enquanto a perda no uso das evidências tira cerca de dez pontos. A métrica final esconde o problema.

Principais números do estudo:

• 158 tarefas com verificação por execução;
• até 846,8 mil caracteres em um único relatório;
• 11 007 chamadas do simulador reexecutadas;
• −11,3 pontos no GPT-5.1 e −7,9 no GPT-5.2 na leitura via índice;
• −9,4 pontos no GPT-5.2 com simulação fixada;
• cerca de −10 pontos de perda oculta no GPT-5.4;
• de +6,3 a +7,9 pontos nos três modelos GPT quando o arquivo de saída de referência é indicado pelo nome.

O que ajuda e o que não ajuda

O que mais funciona é dizer diretamente qual saída deve ser considerada a principal. Indicar no prompt o nome do arquivo de referência eleva a precisão em 6,3–7,9 pontos em relação à busca comum nos três modelos GPT. Para GPT-5.1 e GPT-5.2, inserir as saídas no contexto também funciona bem, desde que caibam. Já pedir para "arredondar corretamente" não surtiu efeito: o modelo conhece as regras de arredondamento, mas não entende em qual fonte deve confiar.

Para quem constrói harnesses de agentes, a conclusão prática é uma só: avaliar a decisão de guardar a saída fora do contexto apenas pela precisão final não basta. É preciso separar a qualidade da chamada da ferramenta da qualidade do uso do resultado, como os autores fizeram com os logs. Caso contrário, o resultado aparentemente neutro do GPT-5.4 pode ser confundido com ausência de problema.

Se o relatório cabe no contexto, o mais simples é inseri-lo por inteiro. Se não cabe, vale nomear explicitamente na instrução o arquivo principal e proibir que o agente o substitua por cópias intermediárias ou mais precisas. Por fim, ao escolher um modelo para agentes que lidam com saídas longas de ferramentas, é útil testar justamente esse cenário: neste teste, Claude Opus 4.6 e Sonnet 4.6 lidaram com a busca em arquivos sem perda perceptível, e os modelos GPT, não.