Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Cette étude présente un cadre utilisant des tests et une analyse statique pour évaluer et améliorer l'auto-correction des modèles de langage open-source dans la génération de code C, révélant que bien qu'ils produisent souvent du code incorrect et vulnérable avec une mauvaise capacité de détection d'erreurs, ils parviennent à corriger efficacement ces défauts lorsqu'ils reçoivent un retour d'information approprié.

L'essentiel

🤖 Le Grand Défi : Les Robots qui écrivent du code

Imaginez que vous avez embauché quatre super-assistants très intelligents (ce sont les modèles d'IA comme Llama ou Gemma). Leur travail ? Écrire du code informatique (des recettes pour les ordinateurs) pour résoudre des problèmes.

Ces assistants sont incroyablement rapides et créatifs. Mais il y a un gros problème : ils sont souvent un peu étourdis. Parfois, ils oublient de verrouiller la porte (sécurité), parfois ils mettent le sucre à la place du sel (erreurs de logique), et parfois leur recette ne fonctionne tout simplement pas.

Les chercheurs de cet article se sont demandé : "Peut-on apprendre à ces assistants à mieux faire leur travail en leur donnant des corrections, et peuvent-ils même se corriger eux-mêmes ?"

---

🛠️ La Méthode : Le Cycle de la "Recette Parfaite"

Pour répondre à cette question, les chercheurs ont mis en place un système en trois étapes, un peu comme un chef étoilé qui teste ses plats dans un restaurant.

1. La Cuisine (Génération du code)

Les assistants reçoivent une commande : "Fais-moi un gâteau au chocolat". Ils écrivent leur recette (le code).

• Le problème : Souvent, la recette est bizarre. Ils utilisent des ingrédients qui n'existent pas en C (le langage utilisé), ou ils oublient des étapes.
• La solution des chercheurs : Ils nettoient la recette. Ils ajoutent les ingrédients manquants (les bibliothèques) et s'assurent que le texte est propre.

2. Le Dégustateur et l'Inspecteur (Tests et Analyse)

Une fois la recette prête, deux experts interviennent :

• Le Dégustateur (Tests) : Il essaie de faire le gâteau. Si ça brûle ou si c'est trop sucré, il dit : "Échec !". C'est la vérification de la correction.
• L'Inspecteur de Sécurité (Analyse statique) : Il ne goûte pas, il regarde la cuisine. Il cherche des dangers : "Attention, le four est mal branché !" ou "Il y a un couteau posé sur le bord de la table !". C'est la vérification de la sécurité (fuites de mémoire, accès interdits, etc.).

3. Le Retour en Cuisine (Réparation)

C'est ici que la magie opère. Les chercheurs donnent les rapports de l'Inspecteur et du Dégustateur à l'assistant.

• "Tu as oublié de verrouiller la porte, corrige ça."
• "Ton gâteau ne monte pas, réessaie."
  L'assistant doit alors réécrire sa recette pour qu'elle soit parfaite.

---

🔍 Ce qu'ils ont découvert (Les Résultats)

Voici les conclusions principales, traduites en langage courant :

1. Les assistants font beaucoup d'erreurs au début.
Sur 100 recettes, seulement la moitié environ fonctionnent correctement dès le premier coup. Et même si elles fonctionnent, elles contiennent souvent des "pièges" cachés (des failles de sécurité).

2. Ils sont très mauvais pour se juger eux-mêmes.
C'est la partie la plus surprenante. Quand on demande à un assistant : "Est-ce que ta recette est bonne ?" ou "Y a-t-il un danger ici ?", il répond souvent n'importe quoi.

• C'est comme si un élève qui a fait une faute de calcul dans un devoir ne voyait pas l'erreur quand on lui demande de relire son travail.
• Ils ne montrent aucune "conscience de soi" : ils ne préfèrent pas leurs propres erreurs, ils sont juste confus.

3. Mais ils sont excellents pour se faire corriger !
C'est la bonne nouvelle. Quand on leur donne les rapports précis de l'Inspecteur ("Il y a une fuite de mémoire à la ligne 10"), ils comprennent très vite.

• Avec un peu d'aide, ils réussissent à corriger 89 % des problèmes de sécurité.
• Pour les erreurs de logique, ils arrivent à en corriger environ 60 %.

4. L'outil "Inspecteur" est crucial.
Sans l'avis de l'Inspecteur (l'outil d'analyse statique), les assistants restent aveugles. C'est comme si on leur donnait une carte au trésor : sans la carte, ils tournent en rond. Avec la carte, ils trouvent le trésor.

---

💡 La Conclusion en une phrase

Les robots qui écrivent du code sont encore de grands enfants : ils font des bêtises et ne savent pas toujours les voir eux-mêmes, MAIS si on leur donne un bon professeur (l'outil d'analyse) qui leur montre exactement où ils ont tort, ils apprennent très vite et peuvent produire un code très sûr.

En résumé : Ne faites pas confiance aveuglément à l'IA pour coder. Utilisez-la comme un apprenti brillant, mais gardez toujours un expert humain (ou un outil automatique) pour vérifier son travail et lui donner les corrections nécessaires.

Résumé technique

1. Problématique

L'adoption croissante des Modèles de Langage (LLM) pour la génération de code soulève des préoccupations majeures concernant la sécurité, la correction fonctionnelle et la fiabilité des logiciels produits. Bien que les outils basés sur l'IA augmentent la productivité, les études antérieures montrent que le code généré par les LLM commerciaux contient souvent des vulnérabilités, des bugs et des "code smells".

Les défis principaux identifiés sont :

• L'incapacité des LLM à générer du code entièrement conforme aux spécifications et sécurisé dès la première tentative.
• Une faible capacité des modèles à s'auto-évaluer (détecter leurs propres erreurs ou celles d'autres modèles).
• L'absence de mécanismes automatisés robustes pour guider l'amélioration itérative du code généré sans intervention humaine constante.

2. Méthodologie

Les auteurs proposent un cadre expérimental automatisé et modulaire composé de trois phases principales, appliqué à la génération de code en C (un langage exigeant en gestion de mémoire).

A. Configuration Expérimentale

• Données : Un benchmark de 100 tâches issues du dataset MBPP (Mostly Basic Python Problems), traduites et adaptées manuellement en C pour éviter la mémorisation des tâches par les modèles.
• Modèles étudiés : Quatre LLM open-source récents et performants :
  • Llama 3 (8B et 70B paramètres)
  • Gemma 7B
  • Mixtral 8x7B
• Outils d'analyse :
  • Tests unitaires : Basés sur les tests MBPP adaptés pour vérifier la correction fonctionnelle.
  • Analyse statique : Utilisation de Infer (outil open-source de Meta) pour détecter les vulnérabilités de sécurité (déréférencement de pointeurs nul, fuites de mémoire, débordements de tampon, etc.).

B. Les Trois Phases du Framework

1. Génération de Code : Les modèles génèrent du code C pour résoudre les tâches. Le code est nettoyé automatiquement (suppression du texte explicatif, ajout de bibliothèques manquantes) et compilé.
2. Auto-évaluation (Self-Evaluation) : Chaque modèle est interrogé pour évaluer la correction et la sécurité du code généré (par lui-même ou par les autres modèles). Cela permet de mesurer la "préférence pour soi-même" (self-preference) et la capacité de détection d'erreurs.
3. Réparation (Repair) : Les modèles tentent de corriger le code incorrect ou vulnérable. Ils reçoivent en retour des feedbacks précis :
   • Pour la correction : les tests unitaires échoués.
   • Pour la sécurité : les rapports d'Infer détaillant le type de vulnérabilité et la ligne concernée.
   • Ce processus est itératif (jusqu'à 6 itérations) pour maximiser les chances de succès.

3. Contributions Clés

• Évaluation complète : Une analyse systématique de la génération, de l'auto-évaluation et de la réparation de code sur des modèles open-source, en distinguant correction fonctionnelle et sécurité.
• Benchmarks adaptés : Création d'un ensemble de tâches C dérivé de MBPP, conçu pour minimiser les risques de mémorisation et forcer une génération "from scratch".
• Intégration de l'analyse statique : Démonstration de l'efficacité d'utiliser des rapports d'outils formels (Infer) comme feedback pour guider les LLM vers des réparations de code plus sûres.
• Analyse de l'auto-préférence : Étude de la tendance des modèles à favoriser leurs propres sorties, révélant une absence de biais de "self-preference" significatif mais une tendance à des prédictions unilatérales (toujours "Oui" ou toujours "Non").
• Pipeline automatisé : Mise à disposition d'un pipeline entièrement automatisé, extensible à d'autres modèles et analyseurs, avec un code et des données publics.

4. Résultats Expérimentaux

Génération Initiale

• Correction : Seulement 46 % à 65 % du code généré est fonctionnellement correct (selon le modèle). Llama 3-70B obtient les meilleurs résultats (65 %).
• Sécurité : Selon l'analyse Infer, 87 % à 96 % du code ne contient pas de vulnérabilités détectées. Cependant, le code est plus susceptible d'être incorrect fonctionnellement que d'être intrinsèquement dangereux.

Auto-évaluation

• Les modèles échouent lamentablement à détecter leurs propres erreurs ou celles des autres.
• Les scores F1 pour la détection de vulnérabilités sont très faibles (< 0,3).
• Les modèles montrent des stratégies biaisées : Gemma 7B répond presque toujours "OUI" (détecte tout, mais avec beaucoup de faux positifs), tandis que Llama 3-8B répond presque toujours "NON" (ne détecte rien, mais a une haute précision sur les cas négatifs).

Capacité de Réparation

• Correction fonctionnelle : Avec le feedback des tests, les modèles améliorent significativement le code. Llama 3-70B corrige 62 % des fichiers incorrects initiaux (92 sur 155).
• Réparation de sécurité : L'apport des rapports d'Infer est très efficace. Les meilleurs modèles (Llama 3-70B et Mixtral) corrigent 89 % des vulnérabilités détectées (39 sur 44).
• Absence de biais d'auto-réparation : Les modèles ne corrigent pas mieux leur propre code que celui des autres. Ils réussissent même mieux à corriger le code généré par Gemma 7B (le moins performant) que le leur.

5. Signification et Conclusion

Cette étude démontre que si les LLM actuels ne sont pas encore fiables pour générer du code sécurisé et correct de manière autonome (zero-shot), ils possèdent un potentiel de réparation considérable lorsqu'ils sont guidés par des feedbacks externes précis (tests et analyse statique).

Implications principales :

1. Nécessité de boucles de rétroaction : L'intégration d'outils de vérification formelle (comme Infer) dans le pipeline de génération de code est cruciale pour transformer les LLM en assistants de développement fiables.
2. Limites de l'auto-évaluation : Il ne faut pas se fier aux LLM pour auditer leur propre code ou celui d'autres modèles sans outils externes.
3. Voie d'amélioration : L'approche itérative guidée par l'analyse statique permet d'atteindre des taux de réparation élevés (près de 90 % pour la sécurité), suggérant que l'avenir des outils de codage par IA réside dans l'hybridation entre la génération par LLM et la vérification par des analyseurs statiques.

Les auteurs prévoient d'étendre ce travail à d'autres langages (Rust, Python) et d'explorer des approches hybrides combinant analyse statique et dynamique pour réduire encore les faux positifs et négatifs.