Les agents GPT perdent jusqu'à 11,3 points de précision quand le rapport du simulateur est stocké dans un fichier

Un calcul juste ne garantit pas une réponse juste. Un nouvel article, repéré dans les Hugging Face Daily Papers, montre comment cela se produit dans un schéma courant de gestion du contexte : la longue sortie d'un outil est enregistrée dans un fichier, et l'agent y cherche l'information voulue à l'aide d'un index des sections. Sur le simulateur géochimique PHREEQC de l'USGS, les modèles GPT-5.1 et GPT-5.2 perdent dans ce mode 11,3 et 7,9 points de précision. Claude Opus 4.6 et Claude Sonnet 4.6 n'affichent pas de perte notable.

Un terrain d'essai où chaque nombre est traçable

Le choix de PHREEQC n'a rien d'aléatoire. Ce simulateur est très répandu, et ses rapports peuvent atteindre 846,8 mille caractères. Il est déterministe : toute valeur affichée peut donc être remontée jusqu'à sa source. Les agents ont répondu à 158 questions à choix multiples, dont chaque réponse correcte était confirmée par exécution. Ce protocole permet de distinguer deux causes d'erreur : le modèle a mal lancé la simulation, ou il en a mal lu le résultat.

Les auteurs ont rejoué les 11 007 appels du simulateur consignés dans les logs et vérifié à quelle fréquence l'agent obtient effectivement la valeur recherchée. Pour les deux modèles GPT, cette proportion a à peine changé. Leurs simulations ne sont pas devenues moins bonnes. Ce qui change, c'est la source dans laquelle ils puisent leur réponse.

La substitution des preuves

Ce défaut est baptisé evidence substitution. Lorsqu'il faut chercher le rapport via l'index, les modèles GPT le sautent souvent. Ils répondent à partir de leurs propres fichiers de sortie, où les nombres sont écrits avec plus de précision, puis, en arrondissant, tombent à côté sur l'option de réponse voisine. Le calcul est juste, mais l'option choisie ne l'est pas.

L'effet ne s'explique pas par une moins bonne capacité de calcul. Avec une simulation fixée, la recherche coûte encore 9,4 points à GPT-5.2. Le cas de GPT-5.4 est plus intéressant : sa variation globale ne se distingue pas de zéro. Mais ce bilan nul résulte de deux effets opposés. Des simulations correctes plus fréquentes ajoutent de la précision, tandis que la perte liée à l'usage des preuves en retire environ dix points. La métrique globale masque le problème.

Les chiffres clés de l'étude :

• 158 tâches vérifiées par exécution ;
• jusqu'à 846,8 mille caractères dans un seul rapport ;
• 11 007 appels du simulateur rejoués ;
• −11,3 points pour GPT-5.1 et −7,9 pour GPT-5.2 en lecture via l'index ;
• −9,4 points pour GPT-5.2 avec une simulation fixée ;
• environ −10 points de perte masquée pour GPT-5.4 ;
• de +6,3 à +7,9 points pour trois modèles GPT lorsque le fichier de sortie faisant autorité est nommé.

Ce qui aide, et ce qui ne sert à rien

La méthode la plus efficace consiste à indiquer directement quelle sortie considérer comme la principale. Nommer le fichier faisant autorité dans le prompt améliore la précision de 6,3 à 7,9 points par rapport à la recherche ordinaire pour trois modèles GPT. Pour GPT-5.1 et GPT-5.2, insérer les sorties dans le contexte fonctionne tout aussi bien, lorsqu'elles y tiennent. Demander d'« arrondir correctement » n'a eu aucun effet : le modèle connaît les règles d'arrondi, mais ne sait pas à quelle source se fier.

Pour ceux qui conçoivent des harnais d'agents, la conclusion pratique est unique : la précision finale ne suffit pas pour évaluer la décision de stocker une sortie hors du contexte. Il faut séparer la qualité de l'appel de l'outil de la qualité d'utilisation de son résultat, comme l'ont fait les auteurs grâce aux logs. Sinon, le résultat apparemment neutre de GPT-5.4 pourrait facilement passer pour l'absence de problème.

Si le rapport tient dans le contexte, il est plus simple de l'y insérer en entier. Sinon, mieux vaut nommer explicitement dans les instructions le fichier principal et interdire de lui substituer des copies intermédiaires ou plus précises. Enfin, pour choisir un modèle destiné à des agents confrontés à de longues sorties d'outils, il est utile de tester précisément ce scénario : dans ce test, Claude Opus 4.6 et Sonnet 4.6 ont supporté la recherche dans les fichiers sans perte notable, contrairement aux modèles GPT.