🤖 machine learning

How Robustly do LLMs Understand Execution Semantics?

Cette étude révèle que, contrairement aux modèles de raisonnement open-source qui conservent une compréhension robuste du code face aux perturbations, le modèle GPT-5.2 montre une fragilité marquée, soulignant ainsi les limites actuelles de la compréhension sémantique des LLMs et l'importance d'évaluer leur comportement via des transformations d'entrée.

Auteurs originaux : Claudio Spiess, Prem Devanbu, Earl T. Barr

Publié 2026-04-21

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Claudio Spiess, Prem Devanbu, Earl T. Barr

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

Le Grand Test de Vérité des IA : Comprendre le Code ou juste "Reciter" ?

Imaginez que vous avez un super-élève (une Intelligence Artificielle) qui a lu tous les livres de code du monde. Il est capable de résoudre des énigmes complexes et de prédire exactement ce qu'un programme informatique va faire. C'est impressionnant, non ?

Mais les chercheurs de l'UC Davis et de l'UCL se posent une question cruciale : Est-ce que cet élève comprend vraiment ce qu'il fait, ou est-ce qu'il est juste un excellent acteur qui mémorise des scripts ?

Pour le savoir, ils ont organisé un examen très spécial avec trois épreuves pièges.

Épreuve 1 : Le Jeu de l'Élastique (Perturbation des Entrées)

L'analogie : Imaginez que vous demandez à votre élève de calculer le prix d'une pomme. Il répond "1 euro". Parfait. Maintenant, vous lui dites : "Et si la pomme pesait un tout petit peu plus ?" ou "Et si c'était une pomme verte au lieu d'une rouge ?".

Ce qu'ils ont fait : Ils ont pris des milliers de petits programmes et ont légèrement modifié les données d'entrée (comme changer un nombre de 10 à 10,1).
Le résultat surprenant :
- Les modèles "open-source" (comme DeepSeek) sont restés calmes. Ils ont un peu moins bien réussi, mais ils sont restés cohérents. C'est comme un élève qui dit : "Ah, c'est un peu plus lourd, donc le prix change un peu."
- Le modèle le plus célèbre et puissant, GPT-5.2, s'est effondré. Alors qu'il avait 99 % de réussite sur la question originale, il est tombé à 79 % dès qu'on a changé un tout petit détail.
- La leçon : GPT-5.2 semble avoir appris par cœur la réponse exacte, mais dès qu'on change le contexte, il panique. Il ne "comprend" pas la logique, il devine la réponse attendue.

Épreuve 2 : Le Déguisement (Transformation du Code)

L'analogie : C'est comme demander à votre élève de lire une histoire, puis de lui donner la même histoire écrite avec des mots différents, mais qui raconte exactement la même chose.

Exemple : Au lieu de dire "Le chien a couru", on dit "L'animal à quatre pattes s'est déplacé rapidement". Le sens est identique, mais les mots changent.
Ce qu'ils ont fait : Ils ont réécrit le code des programmes en changeant la structure (par exemple, remplacer une boucle for par une boucle while) sans changer ce que le programme fait.
Le résultat :
- Là encore, GPT-5.2 a eu du mal. Il a perdu beaucoup de points. Il semble très sensible à la "façade" du code.
- Un autre modèle, Gemini 3 Pro, a été très robuste. Il a compris que l'histoire était la même, peu importe les mots utilisés.
- La leçon : Un vrai compréhension du code devrait être insensible à la façon dont il est écrit. GPT-5.2, malgré son titre de "meilleur", semble trop collé à la forme plutôt qu'au fond.

Épreuve 3 : Le Labyrinthe (Les Décisions et les Erreurs)

L'analogie : Imaginez un labyrinthe. Plus il y a de carrefours (décisions) et de murs, plus c'est difficile à naviguer. De plus, imaginez que certains chemins mènent à un précipice (une erreur de programmation).

Ce qu'ils ont fait : Ils ont regardé combien de fois le programme prenait une décision (des "si... alors...") et si le programme plantait (lancait une exception).
Le résultat :
- Plus le chemin était complexe (beaucoup de décisions), moins les IA étaient bonnes. C'est logique, c'est dur pour tout le monde.
- Le gros problème des erreurs : Quand le programme plante (par exemple, division par zéro), les IA ont terriblement du mal à dire "Attention, ça va planter !". Avec le message standard, GPT-5.2 n'avait que 15 % de réussite pour prédire les erreurs.
- Le remède magique (Le Prompt) : Les chercheurs ont simplement ajouté une phrase dans la consigne : "Vérifiez bien les types de données et les erreurs possibles".
- Résultat : La performance de GPT-5.2 pour prédire les erreurs est passée de 15 % à 81 % !
- La leçon : Les IA ne sont pas "bêtes", elles sont juste un peu paresseuses ou trop obéissantes. Si on ne leur demande pas explicitement de chercher les erreurs, elles ne le font pas. C'est comme si on demandait à un détective de trouver un voleur, mais qu'on ne lui disait pas de chercher des empreintes digitales.

En Résumé : Que retenir ?

La force n'est pas la compréhension : Le fait qu'un modèle soit très performant sur les tests standards ne signifie pas qu'il comprend le code. Il peut simplement reconnaître des motifs.
La fragilité des géants : Les modèles les plus puissants (comme GPT-5.2) sont parfois plus fragiles que des modèles plus petits quand on les teste avec des variations. Ils sont comme des athlètes de haut niveau qui trébuchent sur un petit caillou, tandis que des coureurs plus modestes restent stables.
Le pouvoir des mots : La façon dont on pose la question (le "prompt") change tout. En demandant explicitement de chercher les erreurs, on peut transformer un élève médiocre en un expert.

Conclusion de l'auteur :
Les IA actuelles ne sont pas encore des ingénieurs logiciels fiables à 100 %. Elles sont brillantes, mais elles manquent de "robustesse". Pour les faire travailler en sécurité, il faut les tester avec des pièges (des perturbations) et leur donner des instructions très claires sur ce qu'il faut surveiller.

C'est un peu comme conduire une voiture autonome : elle roule bien sur l'autoroute (le test standard), mais il faut vérifier si elle sait gérer un chat qui traverse la route ou une route glissante (les perturbations) avant de lui faire confiance aveuglément.

1. Problématique et Contexte

Les modèles de langage (LLM) démontrent des capacités impressionnantes dans des tâches d'ingénierie logicielle telles que la génération, la synthèse et la réparation de code. Cependant, une question fondamentale demeure : ces performances résultent-elles d'une véritable compréhension de la sémantique d'exécution du code, ou simplement d'un appariement de motifs sophistiqué ?

La maintenance logicielle exige la capacité de prédire le comportement d'un programme face à diverses entrées et transformations, indépendamment de la syntaxe spécifique. Bien que les modèles de pointe (frontier models) obtiennent des scores proches de 100 % sur des benchmarks standards comme CruxEval (qui demande de prédire la sortie exacte d'un programme pour une entrée donnée), il est inconnu si cette performance est robuste. Autrement dit, un développeur peut-il faire confiance aux prédictions d'un LLM lors du débogage ou de la refactorisation, où les entrées et la structure du code varient ?

L'article vise à évaluer la robustesse de la compréhension du code par les LLM en utilisant la prédiction de sortie comme proxy de la compréhension, en testant la stabilité des modèles face à des perturbations d'entrées, des transformations de programmes et des variations de complexité des chemins d'exécution.

2. Méthodologie

Les auteurs ont conçu une série d'expériences basées sur le benchmark CruxEval, en introduisant trois dimensions de perturbation pour répondre à trois questions de recherche (RQ) :

RQ1 : Robustesse aux perturbations d'entrées.
- Utilisation d'un algorithme de mutation sensible aux types pour générer un "voisinage dense" d'entrées synthétiques pour chaque programme.
- Création d'un jeu de données étendu (CruxEvalexc) incluant des entrées provoquant des exceptions d'exécution (ex: IndexError, TypeError, TimeoutError).
- Évaluation de la capacité du modèle à prédire non seulement la valeur de sortie, mais aussi le type et le message de l'exception (critères de correspondance "Strict" et "Any").
RQ2 : Robustesse aux transformations de programmes.
- Application de transformations préservant le sens (Meaning-Preserving Transformations - MPT) : échange d'opérandes, blocs de code, conversion for/while, insertion de code mort.
- Renommage de variables : remplacement des identifiants par des noms génériques tirés d'une distribution de projets Python réels, pour tester la dépendance aux noms de variables.
- Comparaison des performances sur le code original vs. code transformé.
RQ3 : Robustesse face aux décisions de contrôle de flux.
- Analyse dynamique (tracing) pour compter le nombre de décisions (conditions if, itérations de boucles) rencontrées lors de l'exécution.
- Étude de la corrélation entre le nombre de décisions et la précision de la prédiction.

Modèles évalués :
Une suite diversifiée de 14 modèles a été testée, incluant des modèles open-source (Qwen2.5, DeepSeek-R1, Llama 3.1, Nemotron) et des modèles propriétaires de pointe (GPT-5 Nano, GPT-5.2, Gemini 3 Pro).

Métriques :

Précision ( $C_o$ , $C_{\tilde{o}}$ ) : Précision sur les entrées originales et perturbées.
Robustesse Stricte au niveau Programme (PSR) : Fraction de programmes pour lesquels le modèle prédit correctement toutes les sorties (entrées originales + perturbées).
Chute de Robustesse (RΔ) : Différence absolue de précision entre les entrées originales et perturbées.

3. Résultats Clés

A. Robustesse aux perturbations d'entrées (RQ1)

Divergence des modèles : Les modèles open-source de type "raisonnement" (famille DeepSeek-R1) maintiennent une stabilité relative (précision entre 38 % et 67 %) sous perturbation. En revanche, le modèle de pointe GPT-5.2 montre une fragilité extrême : bien qu'il atteigne 99,12 % sur les entrées originales, sa précision chute à 79,61 % sur les entrées perturbées (RΔ = -19,52).
Paradoxe de la taille : Le modèle GPT-5 Nano (plus petit et supposé moins puissant) surpasse GPT-5.2 en robustesse, avec une chute de performance négligeable (-0,18). Les auteurs émettent l'hypothèse que la quantification ou la distillation de GPT-5 Nano agit comme un régularisateur, réduisant le surapprentissage et améliorant la généralisation.
Prédiction d'exceptions : Les modèles échouent massivement à prédire les exceptions avec le prompt standard. GPT-5.2 tombe à ~15 % de précision sur les exceptions, contre ~81 % pour Gemini 3 Pro.

B. Robustesse aux transformations de code (RQ2)

Stabilité globale : La plupart des modèles open-source résistent bien aux transformations syntaxiques (MPT) et au renommage de variables.
Fragilité de GPT-5.2 : Là encore, GPT-5.2 subit une chute drastique, passant de 99,24 % à environ 76 % sur les versions transformées (MPT et renommage). Cela suggère que sa performance initiale repose sur des corrélations superficielles (syntaxe) plutôt que sur une compréhension sémantique profonde.
Gemini 3 Pro : Ce modèle démontre une robustesse exceptionnelle, maintenant des scores élevés (>95 %) même après transformation.

C. Impact des décisions de contrôle (RQ3)

Corrélation négative : Il existe une relation négative entre le nombre de décisions rencontrées dans un chemin d'exécution et la précision du modèle. Plus le nombre de conditions (boucles, if) est élevé, plus la précision baisse.
Seuil critique : La précision chute significativement dès que le nombre de décisions dépasse 3.
Exception : Gemini 3 Pro semble moins affecté par cette complexité, maintenant une stabilité relative même avec un grand nombre de décisions.

D. Analyse des échecs et interventions (Discussion)

Le problème des exceptions : La faible performance sur les exceptions (notamment TypeError) est attribuée à la sensibilité des modèles aux instructions du prompt. Le prompt original de CruxEval ne mentionne pas les exceptions.
Intervention par Prompting : En modifiant le prompt pour inclure explicitement des instructions de suivi des types et des exceptions ("Type-Strict + Exceptions"), les performances s'améliorent radicalement (ex: GPT-5.2 passe de 15 % à ~81 % pour la prédiction d'exceptions).
Effet secondaire négatif : L'utilisation de ce prompt amélioré sur des entrées normales (sans exception) dégrade légèrement la performance de GPT-5.2 (chute de ~5 %), car le modèle commence à prédire faussement des exceptions (comportement "sycophante").

4. Contributions Principales

Évaluation de la robustesse : Introduction d'une méthodologie rigoureuse pour tester la compréhension sémantique du code via la prédiction de sortie sous perturbation, au-delà des benchmarks statiques.
Découverte de la fragilité des modèles de pointe : Mise en évidence que les modèles les plus performants sur les benchmarks standards (GPT-5.2) sont paradoxalement les plus fragiles face à des variations mineures de code ou d'entrées.
Analyse des exceptions : Identification du déficit majeur des LLM à prédire les erreurs d'exécution, et démonstration que cela est en grande partie dû à un manque d'instruction explicite dans le prompt plutôt qu'à une incapacité intrinsèque.
Corrélation complexité-précision : Preuve empirique que la capacité de raisonnement des LLM se dégrade avec la complexité des chemins de contrôle (nombre de décisions).

5. Signification et Implications

Ce travail remet en question la fiabilité des LLM actuels pour des tâches critiques de maintenance logicielle.

Limites de l'état de l'art : La performance élevée sur les benchmarks "propres" ne garantit pas une compréhension robuste. Les modèles peuvent "tricher" en mémorisant des motifs syntaxiques plutôt qu'en simulant l'exécution.
Importance du test par perturbation : L'utilisation de transformations sémantiques et de perturbations d'entrées est essentielle pour évaluer la véritable compréhension du code.
Rôle du Prompting : La capacité d'un modèle à gérer les cas limites (exceptions) dépend fortement de la formulation de la demande. Les ingénieurs doivent être conscients que les prompts standards peuvent masquer des lacunes critiques.
Perspectives futures : Les auteurs suggèrent que la régularisation (via quantification ou distillation) pourrait être une voie pour améliorer la robustesse, et appellent à des recherches sur les causes de cette fragilité des modèles de grande taille.

En conclusion, bien que les LLM soient des outils puissants, leur compréhension de la sémantique d'exécution reste non robuste, en particulier pour les modèles de pointe les plus récents, ce qui pose des risques pour leur utilisation autonome dans des environnements de développement réels.