Les LLM ne peuvent pas encore s'autocorriger en matière de raisonnement — Constats de l'ICLR 2024 et implications pour l'IA en finance

Cet article est le contrepoint direct des travaux sur CRITIC et Reflexion que j'ai consultés. Huang et al. (ICLR 2024) avancent un argument simple et inconfortable : lorsque les LLM tentent d'autocorriger leur raisonnement sans aucun signal externe, ils ne s'améliorent pas — ils empirent. Publié juste après le LOG-013 sur CRITIC, où la critique ancrée dans des outils aidait véritablement, cet article précise exactement quel type d'« autocorrection » est réel et lequel est un artefact de la configuration expérimentale.

L'article

« Large Language Models Cannot Self-Correct Reasoning Yet » par Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song et Denny Zhou (Google DeepMind / UIUC) a été publié à l'ICLR 2024. La thèse centrale est étroite mais dévastatrice pour une certaine catégorie de conception d'agents : l'autocorrection intrinsèque — demander à un LLM de réviser sa propre réponse en utilisant uniquement son propre jugement, sans signal de vérité terrain — dégrade systématiquement les performances sur les benchmarks de raisonnement. Les gains rapportés dans plusieurs articles antérieurs sur l'autocorrection résultent, selon les auteurs, d'une faille méthodologique subtile : ces articles utilisaient des étiquettes d'oracle pour décider quand arrêter la correction, ce qui signifie que le modèle ne corrigeait que les réponses déjà fausses. Ce n'est pas de l'autocorrection ; c'est du filtrage guidé par oracle.

Idées clés

• Sur GSM8K, GPT-4 commence avec une précision de 95,5 %. Après un cycle d'autocorrection intrinsèque, elle tombe à 91,5 %, et après un second cycle à 89,0 %. GPT-3.5 chute de 75,9 % à 74,7 % en deux cycles.
• La chute est plus spectaculaire sur CommonSenseQA : GPT-3.5 tombe de 75,8 % à 38,1 % après un seul cycle d'autocorrection, remontant légèrement à 41,8 % au second cycle — mais restant catastrophiquement en dessous de la ligne de base.
• L'analyse des changements de réponses sur GSM8K montre que le modèle transforme plus souvent des réponses correctes en réponses fausses que l'inverse. La direction nette du changement est préjudiciable.
• L'autocorrection guidée par oracle améliore effectivement les choses : GPT-4 sur GSM8K avec des étiquettes d'oracle passe de 95,5 % à 97,5 %, et GPT-3.5 sur CommonSenseQA de 75,8 % à 89,7 %. Mais cela nécessite de savoir quelles réponses sont fausses — ce qu'on ne peut pas savoir en production.
• Le débat multi-agents, une autre idée populaire, est moins performant que la simple auto-cohérence (self-consistency) à budget d'inférence égal. Avec 9 réponses au total, l'auto-cohérence atteint 88,2 % sur GSM8K ; le débat multi-agents n'atteint que 83,0 %.
• La génération contrainte (CommonGen-Hard) semble de prime abord être une victoire pour l'autocorrection (44 % → 67 %), mais ce gain s'évapore si l'on améliore simplement le prompt initial (81,8 %). Lorsque le prompt de départ est déjà bon, l'autocorrection nuit, faisant chuter la précision à 75,1 %.

Ce qui tient la route — et ce qui ne tient pas

La conclusion principale est solide : les chiffres parlent d'eux-mêmes. Si vous incitez GPT-4 à réexaminer ses réponses mathématiques sans lui dire lesquelles sont fausses, les réponses empirent en moyenne. L'intuition offerte par l'article est également juste : les LLM ne peuvent pas juger de manière fiable la justesse de leur propre raisonnement. Ainsi, lorsqu'ils décident de modifier une réponse, ils devinent, et ils se trompent au moins aussi souvent qu'ils voient juste.

L'article est moins convaincant sur ses prétentions à la généralisation. Il teste exclusivement des tâches de raisonnement et de connaissance. Il existe des domaines — style d'écriture, respect des contraintes de format, réduction de la toxicité — où la révision itérative aide sans doute, et l'article élude largement ces points. Les auteurs le reconnaissent au passage, notant que « l'autocorrection peut être plus efficace pour des tâches où l'évaluation est plus simple », mais ne le testent pas rigoureusement. L'expérience de génération contrainte CommonGen est suggestive, mais utiliser un prompt initial inadéquat comme base de référence et qualifier l'amélioration résultante d'« autocorrection » est la même faille méthodologique que l'article reproche à d'autres travaux.

L'article n'aborde pas non plus la question de l'autocorrection apprise. Un suivi de 2025 (SCoRe, ICLR 2025, arXiv:2409.12917) montre que l'autocorrection entraînée par apprentissage par renforcement (RL) sur les propres sorties du modèle permet d'obtenir +15,6 % sur MATH et +9,1 % sur HumanEval — une véritable amélioration intrinsèque. Ainsi, le titre « ne peuvent pas encore s'autocorriger » a mieux vieilli qu'une interprétation plus stricte ne le laisserait supposer ; l'interprétation correcte est « ne peuvent pas être amenés à s'autocorriger par simple prompt », et non « ne peuvent pas apprendre à s'autocorriger ».

Pourquoi c'est important pour l'IA en finance

L'implication pour les agents d'écriture sur grand livre est concrète. Un agent qui génère une entrée de journal Beancount, puis se demande « est-ce que cela semble correct ? » avant de réviser, ne sollicite pas un deuxième avis — il introduit du bruit. Les données ici indiquent que si la première réponse était fausse, l'auto-examen est tout aussi susceptible de corrompre une réponse correcte que de corriger une erreur.

Ce que cet article confirme, c'est la contrainte de conception que j'ai tirée de CRITIC : l'auto-validation sans oracle externe n'est pas fiable. Pour Beancount spécifiquement, l'oracle externe est disponible et peu coûteux — les assertions de solde s'exécutent en millisecondes, les noms de comptes sont validés par rapport à un plan comptable connu, les montants doivent se réconcilier au centime près. Une architecture d'agent qui soumet une entrée provisoire, exécute bean-check et renvoie toute erreur sous forme de retour structuré concret est fondamentalement différente d'une architecture qui demande au modèle de « réviser votre entrée de journal ». La première utilise le moteur de comptabilité comme oracle. La seconde repose sur le même mécanisme de raisonnement que celui qui a produit l'erreur à l'origine.

Il y a aussi une leçon plus subtile sur la conception des prompts. L'expérience CommonGen montre que lorsque le prompt est déjà précis et explicite, l'autocorrection dégrade les performances. Cela signifie que si nous investissons des efforts dans l'écriture de prompts de parsing de transactions très clairs — ceux qui énoncent explicitement toutes les règles de syntaxe Beancount — ajouter une boucle d'auto-révision par-dessus pourrait activement nuire à la précision. La bonne architecture devrait probablement conditionner l'auto-révision à l'échec d'une vérification externe, et non l'appliquer à chaque génération.

Lectures recommandées

• SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — Approche basée sur le RL qui réalise les premiers gains réels d'autocorrection intrinsèque ; contexte nécessaire pour comprendre ce que l'article actuel valide ou invalide.
• When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — Taxonomie systématique des cas où l'autocorrection fonctionne, distinguant les variantes intrinsèques, basées sur l'entraînement et assistées par des outils.
• Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — L'article principal critiqué par Huang et al. ; le lire en parallèle permet de clarifier exactement où l'hypothèse de l'étiquette d'oracle est intégrée.