Thinking-in-Bets : les agents consignent leurs affirmations avant la critique et se dédisent moins souvent

Les agents basés sur des modèles de langage ont une fâcheuse habitude : dès que l'utilisateur met en doute leur travail, ils abandonnent une solution pourtant correcte. Une simple instruction du type « tiens bon » ne règle rien, car l'agent se met alors à ignorer aussi les véritables erreurs. Le chercheur Nghi D. Q. Bui propose de s'en sortir sans réentraînement. La méthode Thinking-in-Bets demande à l'agent de rédiger un court rapport privé sur ses affirmations avant même de voir la critique. Des tests sur cinq modèles Gemini et huit benchmarks montrent que lors de la relecture de patchs, les revirements injustifiés disparaissent presque.

Pourquoi l'agent capitule dès la première remarque

L'auteur décrit ainsi le mécanisme : en lisant la réclamation, le modèle dévalorise ses propres vérifications antérieures pour se mettre en accord avec son interlocuteur. Le raisonnement s'ajuste au ton de l'utilisateur, pas aux faits. C'est pourquoi une interdiction directe de céder fonctionne mal. L'agent perd alors la capacité à distinguer une remarque fondée d'une remarque erronée, et finit par balayer les deux d'un revers de main.

Thinking-in-Bets change l'ordre des opérations. L'agent consigne d'abord dans une note privée trois éléments : les principales affirmations, les vérifications sur lesquelles elles s'appuient, et son niveau de confiance pour chacune. L'auteur appelle cette note Claim Checklist. Lorsqu'une objection arrive, l'agent ouvre cette liste et agit de manière sélective. Les éléments confirmés restent intacts, tandis que les points incertains ou contestés pour la première fois sont réexaminés. Le nom renvoie à l'idée de mise : une affirmation dont la confiance a été fixée au préalable est plus difficile à abandonner sans argument.

Huit benchmarks et cinq modèles

L'évaluation couvre cinq modèles Gemini :

• Gemini 3.5 Flash-Lite ;
• Gemini 3.5 Flash ;
• Gemini 3.6 Flash ;
• Gemini 3.8 Flash ;
• Gemini 4.0 Argon.

Le jeu de test comprend huit benchmarks :

• SWE-Together, SWE-Interact et DeepSWE pour le développement logiciel ;
• Agents' Last Exam pour les rapports professionnels ;
• Humanity's Last Exam et SycEval pour le raisonnement académique ;
• Vals Finance pour l'analyse financière ;
• Terminal-Bench pour les tâches en ligne de commande.

La conclusion principale porte sur le moment de la rédaction. Si les affirmations sont consignées avant la critique, les revirements injustifiés lors de la relecture de patchs disparaissent presque, et les rapports finalisés ayant passé la vérification restent intacts sous une pression erronée. Lorsque la même note est écrite après la lecture de la remarque, le gain disparaît presque entièrement. Cela signifie que ce n'est pas la checklist en elle-même qui compte, mais le fait qu'elle soit créée avant la pression sociale.

Codage, économie de tokens et travail sans critique

Dans le codage multi-étapes, les notes rédigées avant la réponse réduisent nettement les modifications de fichiers superflues après des remarques erronées. Il y a là un enjeu pratique : un diff inutile dans un dépôt coûte du temps au relecteur et peut casser du code qui fonctionnait.

La méthode ajoute des tokens, mais l'auteur propose un garde-fou. La note n'est rédigée que lorsque l'agent lui-même n'est pas sûr du résultat. Dans cette configuration, la consommation de tokens est plus faible, et davantage de véritables bugs sont corrigés que dans la version de base. L'économie ne se fait donc pas au détriment de la capacité à accepter une critique fondée.

L'effet ne se limite pas aux dialogues. Dans les tâches sans retour de l'utilisateur, il suffit d'énumérer les principales affirmations d'un brouillon et de revérifier le point le plus faible avant de rendre le travail. Cela améliore à la fois la précision des réponses et l'évaluation de la confiance. Le résultat s'est reproduit sur tous les modèles testés.

Ce qui peut être implémenté dès maintenant dans un agent

La méthode ne nécessite ni réentraînement ni accès aux poids du modèle, elle peut donc être mise en place au niveau du prompt et de l'orchestration :

• Avant chaque remise de travail, l'agent sauvegarde une liste cachée d'affirmations, de vérifications et de niveaux de confiance. L'utilisateur ne la voit pas.
• L'agent ne lit la réponse de l'utilisateur qu'une fois cette liste enregistrée.
• En cas d'objection, l'agent se réfère d'abord à la liste et ne révise que les points faibles ou contestés pour la première fois.
• La rédaction de la note se déclenche en cas de faible confiance, pour ne pas faire gonfler la facture de tokens.
• Pour les tâches autonomes, une revérification finale du point le plus faible du brouillon s'avère utile.

Pour les équipes qui construisent des agents de codage ou d'analyse, c'est un moyen peu coûteux de réduire la complaisance sans priver l'agent de sa capacité à se corriger. Le code et les ressources du projet sont publiés sur la page thinking-in-bets.github.io.