Using Mutation-Analysis to Examine an LLM's Ability to Summarize Code

Résumé Technique : Utilisation de l'analyse par mutation pour examiner la capacité d'un LLM à résumer du code

Énoncé du problème
Alors que les développeurs s'appuient de plus en plus sur les modèles de langage étendus (LLM) pour la synthèse de code afin de faciliter la documentation, les tests et la revue, une préoccupation critique émerge concernant l'exactitude de ces résumés. Les LLM génèrent souvent des descriptions confiantes basées sur la logique intentionnelle ou sur des motifs algorithmiques familiers du code, plutôt que sur le comportement réel du code. Cette divergence est particulièrement dangereuse lorsque des changements subtils, tels que des cas limites ou des modifications mineures de la logique, altèrent ce que fait un programme sans en changer l'apparence superficielle. Les méthodes d'évaluation existantes, qui reposent sur des métriques de chevauchement de n-grammes (BLEU, ROUGE) ou sur des évaluateurs basés sur des LLM, échouent souvent à corréler avec le jugement humain concernant la justesse sémantique. De plus, il existe un manque de cadres systématiques pour déterminer si un résumé généré suit réellement le comportement sous-jacent du code ou s'il reflète simplement des motifs textuels de surface.

Méthodologie : Évaluation basée sur la mutation
Les auteurs proposent une méthodologie d'évaluation basée sur la mutation pour tester directement si le résumé d'un LLM reflète la logique spécifique du code fourni. Le principe fondamental est que si un résumé décrit avec précision le comportement du code, il doit changer lorsque le comportement du code est altéré. Le processus expérimental comprend trois étapes principales :

1. Générer des mutants : Des mutations ciblées sont injectées dans les échantillons de code originaux. Ces mutations sont classées en trois types :

   • Mutations de déclaration (statement mutations) : Supprimer, dupliquer ou réorganiser des déclarations pour altérer le flux d'exécution.
   • Mutations de valeur (value mutations) : Modifier des paramètres ou des valeurs constantes.
   • Mutations de décision (decision mutations) : Changer des opérateurs arithmétiques ou logiques pour affecter la logique de prise de décision.
     Les mutations sont placées dans des emplacements spécifiques (début, milieu, fin) pour tester les mécanismes d'attention.

2. Générer des résumés : Le LLM reçoit une instruction fixe (« Expliquez l'extrait de code suivant en langage clair ») pour générer des résumés pour le code original et pour les variantes mutées. La température est réglée à 0 pour garantir une sortie déterministe.

3. Comparer les résumés : Des évaluateurs humains comparent le résumé du code muté par rapport à l'original. Un résultat est classé comme Positif si le résumé reflète explicitement le changement de comportement (par exemple, en notant une condition ou une valeur de retour différente). Il est classé comme Négatif si le résumé reste identique à la description originale ou décrit l'intention algorithmique attendue plutôt que le comportement réel muté.

Principales contributions
La principale contribution de ce travail est l'établissement de l'analyse par mutation comme un cadre d'évaluation systématique pour la synthèse de code. Les auteurs valident cette méthodologie à travers trois expériences complémentaires :

1. Jeu de données synthétique contrôlé : 12 programmes Python couvrant quatre catégories de complexité (Fonction unique, Classe unique, Classes multiples, Multi-threadé) avec un total de 324 mutations.
2. Validation par code écrit par l'humain : Évaluation sur 50 programmes du jeu de données Less Basic Python Problems (LBPP) pour s'assurer que les conclusions se généralisent au-delà du code généré par des modèles.
3. Comparaison inter-modèles : Une comparaison directe entre GPT-4 et GPT-5.2 utilisant le même sous-ensemble LBPP pour mesurer les améliorations générationnelles.

Résultats clés

• Impact de la complexité : Pour GPT-4, la précision du résumé diminue drastiquement à mesure que la complexité du programme augmente. La précision chute de 76,5 % pour les programmes à fonction unique à 17,3 % pour les systèmes multi-threadés. La taille du programme est également corrélée négativement avec la précision (médiane de 60 LOC pour les cas positifs contre 116 LOC pour les cas négatifs).
• Type et emplacement de la mutation : Le type et l'emplacement de la mutation présentent généralement des effets plus faibles sur la précision par rapport à la complexité. Cependant, les mutations de valeur sont souvent détectées plus de manière fiable que les mutations de déclaration ou de décision, sauf dans les contextes multi-threadés où les mutations de valeur se dégradent considérablement.
• Modes de défaillance : L'analyse identifie deux modes de défaillance principaux :
  1. Abstraction : Le résumé est trop de haut niveau, omettant totalement la logique mutée.
  2. Hallucination d'intention : Le modèle décrit le comportement attendu d'un algorithme connu (par exemple, Tri fusion, Kruskal) plutôt que le code réellement muté, ignorant les écarts par rapport aux modèles canoniques.
• Code écrit par l'humain : Les modes de défaillance observés dans les données synthétiques persistent dans le code écrit par l'humain (LBPP), avec un taux de détection de mutation de 49,3 % pour GPT-4. Cela confirme que les limitations ne sont pas des artefacts du code généré par les modèles.
• Générations de modèles : GPT-5.2 démontre une amélioration substantielle par rapport à GPT-4, atteignant un taux de détection de 85,3 % sur le jeu de données LBPP (une augmentation de 36,0 points de pourcentage). GPT-5.2 montre également une nouvelle capacité à identifier les mutations comme des « bugs » ou des « erreurs » dans près de la moitié des cas détectés. Cependant, il éprouve toujours des difficultés avec les changements de flux de contrôle complexes et ne parvient pas à distinguer les détails d'implémentation des modèles standards dans environ 15 % des cas.

Signification et affirmations
L'article affirme que l'analyse par mutation fournit un test de résistance pratique et répétable pour évaluer si les résumés générés par les LLM reflètent le comportement du programme plutôt que des motifs superficiels. Les auteurs positionnent cette méthodologie comme un précurseur nécessaire à l'amélioration, offrant un moyen de :

• Comparer directement les modèles, les invites (prompts) et les jeux de données sous des conditions contrôlées.
• Vérifier si les améliorations de la synthèse (via le fine-tuning, le prompting ou de nouveaux modèles) sont authentiques plutôt que stylistiques.
• Fournir aux développeurs d'IDE et aux chercheurs des métriques mesurables pour déterminer si le changement de modèle ou la modification d'outils apporte des bénéfices tangibles pour des cas d'utilisation spécifiques.

Les auteurs restent modestes, notant que bien que GPT-5.2 montre des progrès significatifs, un taux de réussite de 85,3 % sur le code simple à fonction unique laisse encore un taux d'erreur non négligeable qui pourrait être problématique pour les systèmes à enjeux élevés. Le travail ne prétend pas résoudre le problème de la compréhension du code, mais propose plutôt une méthode rigoureuse pour mesurer l'écart entre le résumé d'un LLM et la logique réelle du code.