CodeAct : Pourquoi le code Python exécutable rend les agents LLM 20 % plus précis

Après avoir lu l'article sur l'impossibilité de l'auto-correction la semaine dernière, une question naturelle se pose : si les LLM ne peuvent pas auditer de manière fiable leur propre production, quel format d'action offre aux agents la meilleure chance de détecter et de corriger automatiquement les erreurs ? CodeAct, publié par Xingyao Wang et al. et accepté à l'ICML 2024, soutient que la réponse réside dans le code Python — non pas parce que le code est magique, mais parce qu'un interpréteur Python fournit exactement le type de retour externe et déterministe dont la littérature sur l'auto-correction montre que les LLM ont désespérément besoin.

L'article

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) par Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng et Heng Ji propose de remplacer les formats d'action JSON et textuels courants dans les agents d'appel d'outils par du code Python exécutable. L'idée centrale est que le code est une meilleure lingua franca pour les actions des agents que les instructions en langage naturel ou le JSON structuré, car le code encode déjà le flux de contrôle, les dépendances de données et la composition en plusieurs étapes — et parce que les LLM ont été massivement pré-entraînés sur celui-ci.

L'article apporte trois contributions : (1) un argument conceptuel en faveur du code comme espace d'action unifié ; (2) M3ToolEval, un nouveau benchmark de 82 tâches organisées par des humains nécessitant une composition multi-outils ; et (3) CodeActAgent, un modèle 7B affiné entraîné sur CodeActInstruct, un ensemble de données de 7 139 trajectoires basées sur du code à plusieurs tours couvrant la recherche d'informations, les packages logiciels, la mémoire externe et la planification robotique.

Idées clés

• Sur M3ToolEval, GPT-4 avec CodeAct atteint un taux de réussite de 74,4 % contre 53,7 % avec des actions textuelles — une amélioration absolue d'environ 20 points de pourcentage dans le cadre multi-outils le plus exigeant.
• CodeAct nécessite environ 30 % de tours d'interaction en moins que les agents basés sur JSON pour les mêmes tâches. Moins de tours, c'est important : chaque aller-retour supplémentaire est une nouvelle opportunité de propagation d'erreurs.
• L'interpréteur Python agit comme un signal d'erreur automatique et sans coût. Un mauvais calcul intermédiaire lève immédiatement une exception ; l'agent voit la trace (traceback) et peut réviser sans étape de critique séparée.
• Les modèles open-source en bénéficient davantage que les modèles propriétaires. CodeActAgent (Mistral 7B) atteint 12,2 % sur M3ToolEval contre 3,7 % pour l'agent open-source le plus performant auparavant (Lemur-70B avec texte). L'effet de levier est plus élevé car Python est abondant dans les données de pré-entraînement, contrairement aux formats spécialisés d'appel d'outils JSON.
• CodeActInstruct s'entraîne sur quatre domaines spécifiquement choisis pour tester la composition : la recherche d'informations, les appels de packages, la manipulation de mémoire externe et la planification robotique. Ce sont toutes des tâches multi-étapes dépendantes de l'état — précisément les modes de défaillance où les agents JSON échouent.

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

L'amélioration de 20 % sur M3ToolEval est réelle, mais M3ToolEval ne comporte que 82 tâches. C'est un petit échantillon, et l'article ne rapporte pas d'intervalles de confiance. Le benchmark est également préparé par la même équipe qui propose la méthode, ce qui est courant dans le domaine mais mérite d'être souligné. J'aimerais voir cela reproduit sur un benchmark totalement indépendant avant de considérer 74,4 % comme un chiffre fiable.

L'affirmation d'efficacité — 30 % de tours en moins — est plausible mais mélange deux choses. Moins de tours pourraient signifier que l'agent est plus précis à chaque étape, ou que les échecs s'interrompent plus tôt. L'article ne décompose pas cela clairement.

L'écart reconnu entre les modèles open-source et propriétaires est large et n'est pas comblé par CodeAct. CodeActAgent (Mistral 7B) à 12,2 % est bien meilleur que Lemur-70B à 3,7 %, mais GPT-4 avec CodeAct est à 74,4 %. Le format aide, mais il ne comble pas un écart de capacité de 60 points. Quiconque prévoit de déployer un agent Beancount open-source devrait lire ce chiffre attentivement.

La question du bac à sable (sandboxing) n'occupe qu'un paragraphe. L'exécution de code arbitraire dans un contexte financier n'est pas un cas particulier gênant — c'est la principale préoccupation de sécurité. L'article n'aborde pas ce qui se passe lorsque l'agent génère du code qui supprime des fichiers, effectue des appels réseau ou importe des bibliothèques inattendues. Pour un agent comptable en production, la conception du bac à sable est au moins aussi importante que le format de l'action.

Pourquoi cela est important pour l'IA financière

Le problème de l'écriture (write-back) dans Beancount est par essence le problème pour lequel CodeAct est conçu : un agent doit composer plusieurs opérations (lire le solde actuel, valider la transaction, écrire une nouvelle écriture, vérifier l'équation du solde) dans un ordre spécifique, avec des données circulant entre les étapes. L'appel d'outils JSON gère mal cela car chaque appel est isolé. Python le gère naturellement.

Plus concrètement : un agent Beancount de style CodeAct pourrait exprimer l'intégralité d'un flux de rapprochement sous la forme d'un script Python unique — interroger le grand livre via une bibliothèque, calculer les écarts, proposer de nouvelles entrées et exécuter bean-check sur le résultat — le tout avant de valider quoi que ce soit. L'interpréteur intercepte les erreurs évidentes ; le LLM n'a plus qu'à gérer les erreurs sémantiques. C'est une meilleure division du travail que de demander au LLM de valider son propre JSON.

L'inquiétude concernant la sécurité va dans l'autre sens. Un agent avec une exécution Python sans restriction sur un grand livre financier constitue une surface d'attaque significative. La bonne conception est presque certainement un bac à sable fortement restreint — aucune écriture de système de fichiers en dehors d'un répertoire temporaire désigné, aucun accès réseau, aucune commande shell — combiné à une barrière obligatoire bean-check avant qu'un fichier ne soit touché. CodeAct vous donne le format d'action ; il vous reste encore à construire la cage.

Que lire ensuite

• OpenHands (anciennement OpenDevin) — le système d'agent de production basé sur CodeAct par le même groupe de recherche ; montre comment le bac à sable et l'environnement d'exécution sont réellement implémentés (arXiv:2407.16741)
• ToolBench / ToolLLM — benchmarks et données d'entraînement pour les agents d'appel d'outils utilisant des API REST plutôt que Python ; un contraste utile avec l'approche code-first de CodeAct (arXiv:2307.16789)
• SWE-bench — évalue les agents sur des problèmes GitHub réels, ce qui nécessite l'exécution de code en plusieurs étapes et l'édition de fichiers ; le benchmark existant le plus proche de ce qu'un agent d'écriture Beancount devrait réussir (arXiv:2310.06770)