🤖 machine learning

Is Code Better Than Language for Algorithmic Reasoning

Cet article démontre que pour les modèles de langage augmentés par des outils, l'avantage de performance du code sur le langage naturel dans le raisonnement algorithmique provient principalement de l'exécution externe fiable plutôt que de la représentation de code intermédiaire elle-même, car le raisonnement simulé par code n'apporte aucun gain significatif par rapport au raisonnement en langage naturel.

Auteurs originaux : Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

Publié 2026-06-16

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de résoudre une énigme mathématique très complexe. Vous avez deux manières principales d'obtenir la réponse :

La méthode du « Parleur » : Vous demandez à un assistant intelligent de réfléchir à voix haute en anglais courant, étape par étape, puis de vous donner la réponse.
La méthode du « Codeur » : Vous demandez au même assistant d'écrire un programme informatique pour résoudre l'énigme, puis vous laissez un ordinateur exécuter réellement ce programme pour obtenir la réponse.

Pendant longtemps, les gens ont remarqué que la méthode du « Codeur » fonctionnait généralement beaucoup mieux. Mais personne ne savait vraiment pourquoi. Était-ce parce que l'écriture de code force l'assistant à réfléchir plus clairement ? Ou était-ce parce que laisser un ordinateur exécuter le code est plus fiable que de faire confiance à l'assistant pour faire les calculs dans sa tête ?

Cet article met en place une expérience ingénieuse pour déterminer quel facteur est le véritable héros.

L'expérience des trois voies

Les auteurs ont créé une « autoroute à trois voies » pour tester cela, en utilisant un benchmark de 40 tâches de puzzles algorithmiques (comme le tri de listes, la recherche de chemins ou des mathématiques complexes).

Voie 1 (Le Pur Parleur) : L'assistant résout entièrement le problème en anglais. Il réfléchit, écrit un paragraphe de raisonnement, et donne la réponse.
- Résultat : Il a obtenu environ 17 % des bonnes réponses.
Voie 2 (Le Faux Codeur) : L'assistant écrit le code (comme du Python), mais il fait semblant de l'exécuter. Au lieu de donner le code à un ordinateur, l'assistant lit son propre code et simule les étapes dans sa tête, écrivant le résultat en anglais.
- Résultat : Il a obtenu environ 17 % des bonnes réponses.
- La grande révélation : C'est presque exactement la même chose que la Voie 1. Écrire le code n'a pas aidé l'assistant à mieux réfléchir ; cela a simplement changé le format de ses pensées.
Voie 3 (Le Vrai Codeur) : L'assistant écrit exactement le même code que dans la Voie 2, mais cette fois, il remet le code à un véritable ordinateur (un environnement d'exécution Python) pour l'exécuter.
- Résultat : Il a obtenu environ 49 % des bonnes réponses.

Le « Pourquoi » derrière la magie

L'article utilise plusieurs moyens créatifs pour expliquer ces résultats :

1. L'analogie de la « Traduction » (Représentation vs Exécution)
Considérez le « Trace » (les étapes de raisonnement) comme une recette.

La Voie 1 est une recette écrite sous la forme d'une longue histoire fleurie.
La Voie 2 est la même recette, mais écrite sous la forme d'une liste stricte et structurée.
La Voie 3 est cette liste stricte, mais au lieu de la donner à un chef humain qui essaierait de la lire et d'en deviner le résultat, vous la donnez à un chef robotique qui suit les instructions à la perfection.

L'expérience a montré que changer la recette (passer d'une histoire à une liste) n'a pas rendu le chef humain plus intelligent. Le chef humain (le LLM) commettait les mêmes erreurs qu'il lise l'histoire ou la liste. Le bond massif de performance n'a eu lieu que lorsque le chef robot (l'exécuteur informatique) a pris le relais.

2. La théorie du « Nuisance »
Les auteurs soutiennent que le langage naturel est plein de « bruit ». On peut dire la même chose de mille façons différentes (« additionnez les nombres », « faites la somme », « regroupez-les »). Cette variété supplémentaire perturbe le modèle. Le code est plus strict ; il y a moins de façons de dire la même chose.
Cependant, l'article prouve que même si le code est plus « propre », le modèle ne peut toujours pas utiliser cette clarté pour résoudre les problèmes mathématiques par lui-même. Le code ne donne pas magiquement de nouvelles compétences mathématiques au modèle.

3. Le test de « Récupération »
Les auteurs ont examiné les cas où l'ordinateur a trouvé la bonne réponse, mais où l'assistant humain (simulant le code) s'est trompé. Cela s'est produit 33 % du temps.
Inversement, ils ont examiné les cas où l'ordinateur a échoué (peut-être que le code était défectueux), mais où l'assistant humain a quand même trouvé la bonne réponse. Cela ne s'est produit que 1,6 % du temps.
Cela prou parfaitement que l'ordinateur est un « exécuteur » bien plus fiable que l'assistant humain ne l'est pour « simuler » le code.

L'essentiel

L'article conclut que le Code n'est pas meilleur que le Langage parce qu'il est un meilleur moyen de penser.

L'avantage d'utiliser le code n'est pas qu'il force l'IA à être plus intelligente. L'avantage est que le Code permet à l'IA de déléguer le travail à une machine qui ne fait pas d'erreurs de calcul.

Le goulot d'étranglement : Le problème n'est pas que l'IA ne sait pas écrire de bon code ; c'est que l'IA est mauvaise pour vérifier son propre travail ou faire les calculs dans sa tête.
La solution : La véritable puissance vient de l'outil (l'ordinateur qui exécute le code), et non du langage (le code lui-même).

En bref : si vous voulez qu'une IA résolve un problème mathématique difficile, ne lui demandez pas seulement d'écrire du code en espérant qu'elle trouve la réponse. Demandez-lui d'écrire du code, puis laissez un ordinateur l'exécuter réellement. C'est là que la magie opère.

Résumé Technique : Le Code est-il Meilleur que le Langage pour le Raisonnement Algorithmique ?

Énoncé du Problème

Dans les systèmes de modèles de langage (LLM) augmentés par des outils, il est bien établi que la traduction de problèmes en code exécutable par un solveur (délégation de l'exécution à un outil externe) surpasse souvent le raisonnement en langage naturel (NL) de bout en bout sur des tâches algorithmiques complexes. Cependant, la source de ce gain de performance reste ambiguë. Les comparaisons antérieures confondent deux facteurs distincts :

Représentation Intermédiaire : Le passage de traces en langage naturel à des traces de code.
Mécanisme d'Exécution : Le passage d'une simulation par LLM (passe avant) à une exécution externe déterministe (ex: runtime Python).

Parce que les études précédentes comparaient directement le « raisonnement NL » au « Code + Exécution Externe », elles ne pouvaient pas isoler si l'amélioration provenait de la nature structurée du code, de la fiabilité de l'exécuteur externe, ou des deux. Ce document répond à la question de recherche suivante : La représentation par le code est-elle intrinsèquement supérieure au langage naturel pour le raisonnement algorithmique, ou l'avantage est-il principalement piloté par une exécution externe fiable ?

Méthodologie : Le Cadre des Trois Voies

Pour démêler la représentation de l'exécution, les auteurs proposent un Cadre des Trois Voies systématique qui décompose le pipeline de raisonnement en deux étapes : la Génération de Trace et l'Exécution.

Voie 1 (NL Direct) : Le LLM génère une trace de Chaîne de Pensée (Chain-of-Thought) en langage naturel et utilise ensuite ce même LLM pour simuler le raisonnement et produire une réponse.
- Trace : Langage Naturel.
- Exécuteur : LLM (Simulation NL).
Voie 2 (Code + Simulation NL) : Le LLM génère une trace de code (ex: Python), mais au lieu de l'exécuter de manière externe, le même LLM simule l'exécution du code en langage naturel pour produire une réponse.
- Trace : Code.
- Exécuteur : LLM (Simulation de code).
Voie 3 (Code + Exécution par Solveur) : Le LLM génère la même trace de code que la Voie 2, mais le code est exécuté par un runtime Python externe déterministe.
- Trace : Code.
- Exécuteur : Solveur Externe (Déterministe).

Configuration Expérimentale :

Benchmark : Un benchmark algorithmique vérifiable de 40 tâches couvrant l'arithmétique, la programmation dynamique, les algorithmes de graphes, la manipulation de chaînes, la géométrie, le tri et l'optimisation NP-difficile.
Données : 1 113 instances de problèmes uniques sur 3 graines aléatoires (seeds), évaluées sur 6 modèles (incluant des modèles fermés comme GPT-4o-mini et des modèles ouverts comme Mixtral-8x22b).
Métriques : Précision de la tâche finale sous perte 0–1, analysée via des tests statistiques appariés (McNemar) et des intervalles de confiance par bootstrap de grappes (cluster-bootstrap).

Contributions Clés

1. Démêlage Empirique des Facteurs

Le cadre permet des comparaisons par paires qui isolent des variables spécifiques :

Voie 1 vs. Voie 2 (Isoler la Représentation) : En maintenant l'exécuteur LLM constant et en ne changeant que la modalité de la trace (NL vs. Code), les auteurs testent si la représentation par le code offre en soi un avantage.
Voie 2 vs. Voie 3 (Isoler l'Exécution) : En maintenant la trace de code constante et en ne changeant que l'exécuteur (Simulation LLM vs. Runtime Python), les auteurs testent si le mécanisme d'exécution est le moteur de la performance.

2. Formalisation Théorique (Modèle de Théorie de la Décision)

Les auteurs formalisent l'intuition selon laquelle le code est une « canonicalisation » du langage naturel. Ils proposent un modèle linéaire où :

Les deux traces partagent un noyau ( $B$ ) contenant l'information algorithmique pertinente à la décision (ex: relations de récurrence).
Les traces en langage naturel contiennent des variations de nuisance supplémentaires ( $\eta_N$ ) telles que le paraphrasage, la verbosité et les choix stylistiques qui ne modifient pas la réponse.
Théorème : Sous ce modèle, le code est non-inférieur en représentation au langage naturel. La nuisance supplémentaire dans le langage naturel augmente le risque (erreur) pour les apprenants à échantillon fini sans apporter de signal supplémentaire. Ainsi, changer la représentation seule ne devrait pas produire de gains significatifs si le noyau d'information est préservé.

3. Intervention de Reconstruction

Pour valider la théorie empiriquement, les auteurs effectuent une « intervention de reconstruction ». Ils prennent des traces de code générées par le modèle et les traduisent à nouveau en langage naturel en utilisant une transformation fixe. Ils constatent que ces traces NL traduites récupèrent une performance comparable aux traces NL natives. Cela confirme que le code conserve toute l'information décisionnelle et que la « perte » dans le raisonnement NL ne provient pas d'un contenu algorithmique manquant, mais plutôt de la présence de variations de nuisance.

Résultats

Comparaison de Performance

Sur le benchmark de 40 tâches, les résultats sont les suivants :

Voie 1 (NL + NL) : 17,21 % de précision.
Voie 2 (Code + Simulation NL) : 17,37 % de précision.
Voie 3 (Code + Exécution Python) : 48,84 % de précision.

Résultats Statistiques :

Voie 1 vs. Voie 2 : La différence est de +0,15 point de pourcentage (pp), avec un intervalle de confiance à 95 % de $[-0,30, +0,61]$ pp ( $p=0,39$ ). Cela indique aucune différence statistiquement significative entre le raisonnement en langage naturel et la simulation de code lorsque l'exécuteur est le même LLM.
Voie 2 vs. Voie 3 : La différence est de +31,47 pp, avec un IC à 95 % de $[+29,20, +33,71]$ pp ( $p < 0,001$ ). Cela indique un avantage massif et statistiquement significatif pour l'exécution externe déterministe par rapport à la simulation par LLM, même lorsque la trace de code est identique.

Mise à l'Échelle de la Difficulté

À mesure que la difficulté des tâches augmente (contrôlée par des paramètres tels que la longueur des chiffres ou la taille de la matrice), la Voie 3 maintient une précision élevée tandis que les Voies 1 et 2 se dégradent considérablement.

Analyse de Récupération

Les auteurs analysent les cas où la Voie 2 (simulation) réussit mais la Voie 3 (exécution) échoue (« masse de récupération »).

Masse de Récupération : 1,61 % (Cas où le LLM simule correctement un code défectueux ou ignore un échec d'exécution).
Masse de Victoire de l'Exécution : 33,08 % (Cas où l'exécution réussit mais la simulation du LLM échoue).
Ceci confirme que le LLM compense rarement les erreurs d'exécution ; inversement, le solveur externe surpasse systématiquement la capacité du LLM à simuler le code.

Signification et Revendications

L'article affirme que dans le cadre évalué du raisonnement algorithmique :

La représentation n'est pas le goulot d'étranglement : L'intervention intermédiaire consistant à utiliser des traces de code n'améliore pas significativement la performance par rapport aux traces en langage naturel lorsque le mécanisme d'exécution reste un LLM. L'écart de performance entre la Voie 1 et la Voie 2 est négligeable.
L'exécution est le goulot d'étranglement : Le principal moteur des gains de performance observés dans les systèmes augmentés par des outils est la fiabilité de l'exécuteur externe, et non la nature structurée de la représentation par le code elle-même.
Mécanisme d'Utilisation d'Outils : L'avantage de l'utilisation d'outils basés sur le code provient du fait qu'ils permettent le transfert d'une trace générée à un solveur déterministe. La représentation par le code sert principalement de véhicule pour permettre cette exécution fiable, plutôt que d'agir comme un substrat de raisonnement supérieur pour le LLM lui-même.

Les auteurs concluent que pour les tâches algorithmiques avec des réponses vérifiables, l'avantage central de l'utilisation d'outils est la capacité de déléguer l'exécution à un environnement déterministe, plutôt que la supériorité intrinsèque du code en tant que format de raisonnement par rapport au langage naturel.