CRITIC : Pourquoi l'auto-correction des LLM nécessite un retour d'outils externes

En lisant CRITIC (Gou et al., ICLR 2024) tout en réfléchissant à ce qui se passe après qu'un agent financier a commis une erreur. Reflexion nous a appris que les agents peuvent apprendre de leurs échecs au fil des épisodes. CRITIC pose une question plus incisive : un LLM peut-il détecter et corriger ses propres erreurs au sein d'une seule passe de génération — et si oui, de quoi a-t-il réellement besoin pour y parvenir ?

L'article

CRITIC introduit un cadre dans lequel un modèle de langage génère une sortie initiale, puis itère à travers une boucle "vérifier-puis-corriger" en utilisant des outils externes — une API de recherche pour les affirmations factuelles, un interpréteur Python pour le code et l'arithmétique, et un classificateur de toxicité pour la modération de contenu. La boucle s'exécute pendant un nombre fixe d'itérations (l'article rapporte des résultats efficaces en environ trois corrections), produisant une sortie affinée que les auteurs évaluent sur des questionnaires à réponse libre (TriviaQA, AmbigNQ, HotpotQA), la synthèse de programmes mathématiques et la réduction de la toxicité.

L'affirmation centrale n'est pas que les LLM peuvent s'auto-corriger seuls. C'est presque l'inverse : la valeur de CRITIC provient précisément de l'ancrage de la critique dans un signal externe que le modèle ne peut pas simuler. Sans l'API de recherche, les améliorations en QA tombent presque à zéro ou s'inversent. Le cadre fonctionne parce que l'outil indique au modèle quelque chose qu'il ne savait pas véritablement, et non parce que le modèle devient un auto-auditeur fiable.

Idées clés

• Appliqué à ChatGPT, CRITIC obtient des améliorations de 7,7 points de score F1 en moyenne sur trois tâches de QA en domaine ouvert et des gains absolus de 7,0 points de pourcentage sur trois benchmarks de raisonnement mathématique.
• La réduction de la toxicité est le résultat individuel le plus frappant : une réduction de 79,2 % de la probabilité de toxicité sur l'ensemble de données évalué.
• La suppression de l'API de recherche entraîne une stagnation ou une dégradation des performances en QA — la capacité d'auto-critique intrinsèque du modèle est quasi inutile pour les tâches factuelles.
• La boucle converge rapidement : trois cycles de correction capturent l'essentiel du gain, avec des rendements décroissants au-delà.
• Le cadre est agnostique vis-à-vis du modèle et ne nécessite aucun réglage fin (fine-tuning) ; il fonctionne sur des API "boîte noire", notamment Text-Davinci-003 et ChatGPT.
• CRITIC surpasse l'auto-consistance (vote majoritaire sur plusieurs échantillons) sur la plupart des tâches, ce qui est significatif car l'auto-consistance n'a pas de coût d'outil par étape.

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

Le résultat empirique principal est solide : le feedback d'outils externes améliore considérablement les résultats, et l'étude d'ablation supprimant l'API de recherche est accablante pour les partisans d'une auto-correction naïve. L'article est également honnête sur le mécanisme — les gains proviennent de l'outil, pas d'une quelconque capacité métacognitive émergente.

Ce que je trouve sous-exploré, c'est la taxonomie des modes d'échec. Quand le modèle génère-t-il une mauvaise critique qui l'éloigne davantage de la bonne réponse ? L'article rapporte des performances moyennes, mais la variance selon les tâches et les types de questions importerait énormément pour un déploiement réel. Dans un contexte financier, le pire résultat n'est pas "aucune amélioration" — c'est une correction à l'apparence plausible qui introduit une nouvelle erreur.

Le choix de limiter à trois itérations est également présenté comme une commodité pratique plutôt que comme un critère d'arrêt théorique. Trois cycles peuvent fonctionner pour TriviaQA où il existe une réponse de référence vers laquelle converger. Dans un domaine comme le rapprochement de grand livre, où la "bonne" réponse nécessite un raisonnement multi-documents et des connaissances métier, il n'est pas évident que trois appels d'outils suffisent — ni qu'une API de recherche généraliste fournisse le bon signal de vérification.

L'article compagnon de ICLR 2024, "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv:2310.01798), confirme la propre conclusion de CRITIC sous un autre angle : sans feedback externe, l'auto-correction dégrade systématiquement la précision du raisonnement. Ces deux articles forment ensemble un tableau cohérent — la capacité que les gens appelaient "auto-correction" est principalement un affinement piloté par un feedback externe, et la distinction est cruciale.

Pourquoi cela compte pour l'IA financière

La boucle CRITIC s'adapte naturellement au problème de la sécurité de l'écriture (write-back safety) pour les agents Beancount. Actuellement, lorsqu'un agent LLM propose une écriture comptable — par exemple, la catégorisation d'une transaction ou la ventilation d'une dépense — il n'existe aucun moyen théorique pour lui de vérifier sa propre sortie avant de la valider sur le disque. L'architecture de CRITIC suggère un modèle concret : générer une proposition d'écriture, puis exécuter une vérification via un outil (une fonction de vérification de solde, un moteur de règles, un détecteur de doublons) et utiliser le résultat de l'outil pour solliciter une révision avant que l'écriture ne soit enregistrée.

Le résultat sur la toxicité est une analogie que je trouve utile à reformuler : une réduction de 79,2 % des violations de politique ne provient pas d'une internalisation des règles par le modèle — elle provient d'un classificateur qui signale les violations au modèle. Pour un grand livre Beancount, l'équivalent serait un vérificateur de règles qui signale les transactions comptabilisées deux fois ou les violations de catégories, et transmet ce signal dans la passe de révision de l'agent. L'agent n'a pas besoin de savoir de manière autonome que les règles sont enfreintes ; il a besoin du signal de l'outil.

La limitation critique pour la finance est la dépendance à l'API de recherche. Les agents financiers ont besoin d'outils de vérification spécifiques au domaine : vérificateurs d'intégrité des soldes de comptes, validateurs de plans comptables, consultations de règles fiscales. Une recherche web générique a peu de chances de détecter une dépense mal classée. Construire la couche d'outils appropriée pour une correction de type CRITIC en comptabilité est là où se situe le véritable travail d'ingénierie — et l'article n'aborde pas du tout la conception d'outils spécifiques à un domaine.

Que lire ensuite

• "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — l'argument empirique direct selon lequel l'auto-correction intrinsèque échoue ; à lire en parallèle de CRITIC car ils triangulent le même mécanisme depuis des directions opposées.
• "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — étend l'idée de critique-et-correction à chemin unique vers un arbre de recherche sur des étapes intermédiaires ; pertinent pour le rapprochement multi-étapes où l'agent doit explorer et revenir en arrière.
• "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — examine comment les agents apprennent à sélectionner et à enchaîner les appels d'outils, ce qui est le problème en amont que CRITIC tient pour acquis.