🤖 AI

Bridging Generation and Training: A Systematic Review of Quality Issues in LLMs for Code

Cet article présente une revue systématique de 114 études visant à établir une taxonomie unifiée et un cadre causal reliant les problèmes de qualité des données d'entraînement à la génération de code défectueux dans les LLM, tout en synthétisant les techniques d'atténuation et en esquissant un changement de paradigme vers une gouvernance proactive centrée sur les données pour des modèles de code fiables.

Auteurs originaux : Kaifeng He, Xiaojun Zhang, Peiliang Cai, Mingwei Liu, Yanlin Wang, Chong Wang, Kaifeng Huang, Bihuan Chen, Xin Peng, Zibin Zheng

Publié 2026-05-08

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Kaifeng He, Xiaojun Zhang, Peiliang Cai, Mingwei Liu, Yanlin Wang, Chong Wang, Kaifeng Huang, Bihuan Chen, Xin Peng, Zibin Zheng

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 essayiez d'enseigner à un étudiant brillant mais très littéral comment écrire du code informatique. Vous lui donnez une immense bibliothèque de livres (les données d'entraînement) à étudier. L'étudiant lit tout, mémorise les motifs, puis tente d'écrire du nouveau code par lui-même.

Ce document est une vaste enquête sur les raisons pour lesquelles cet étudiant écrit parfois du code bogué, non sécurisé ou tout simplement erroné. Les auteurs, une équipe de chercheurs, ont examiné 114 études différentes pour répondre à une question simple mais cruciale : Est-ce la faute de la mauvaise écriture de l'étudiant, ou est-ce parce que les livres qu'il étudiait étaient remplis d'erreurs ?

Leur conclusion est frappante : Ce sont surtout les livres.

Voici la répartition de leurs résultats, expliquée par de simples analogies :

1. La réalité « Garbage In, Garbage Out » (Ordures en entrée, ordures en sortie)

Le document soutient que lorsqu'une IA (modèle de langage à grande échelle) génère du mauvais code, c'est rarement parce que l'IA « réfléchit » mal. Au contraire, c'est parce que l'IA copie simplement ce qu'elle a vu dans ses données d'entraînement.

L'analogie : Imaginez que vous appreniez à cuisiner en lisant un livre de cuisine. Si le livre de cuisine contient une recette indiquant « Ajoutez une tasse de sel à la soupe » et que vous la suivez, votre soupe sera immangeable. Vous n'avez pas fait d'erreur ; c'est le livre qui a fait l'erreur.
L'affirmation du document : L'IA apprend à partir d'un « livre de cuisine » (données d'entraînement) contenant des millions de lignes de code provenant d'Internet. Si ce code Internet comporte des failles de sécurité, des instructions obsolètes ou des fautes de frappe, l'IA apprendra ces erreurs comme si elles étaient la manière correcte de faire les choses.

2. Les deux types de « mauvais livres »

Les chercheurs ont organisé les problèmes présents dans les données d'entraînement en deux catégories principales :

Les problèmes de « mauvaise recette » (Attributs du code) : Ce sont des erreurs spécifiques à l'intérieur des extraits de code eux-mêmes.
- Exemple : Une recette utilisant un outil interdit il y a 10 ans. L'IA apprend à utiliser cet outil interdit car elle l'a vu dans le livre.
- Exemple : Une recette qui oublie de laver le poulet, entraînant un repas malade (une vulnérabilité de sécurité).
Les problèmes de « mauvaise bibliothèque » (Attributs non liés au code) : Ce sont des problèmes affectant la bibliothèque dans son ensemble, et non pas seulement les recettes individuelles.
- Exemple : La bibliothèque contient 1 000 copies de la même recette ennuyeuse, mais seulement un exemplaire d'un plat complexe et sain. L'IA devient experte du plat ennuyeux mais échoue complètement sur le plat complexe.
- Exemple : La bibliothèque est remplie de pages de charabia aléatoire ou de publicités (bruit) qui distraient l'étudiant de l'apprentissage de la vraie cuisine.

3. Comment les erreurs voyagent (Le pipeline)

Le document cartographie exactement comment une erreur dans le « livre » devient une erreur dans le « plat final ». Ils ont identifié 18 façons différentes dont cela se produit, qu'ils regroupent en deux voies :

Copie directe (Mappages directs) : L'IA voit un motif spécifique mauvais et le répète.
- Analogie : L'étudiant voit une faute de frappe dans le livre et tape la même faute dans son essai.
- Résultat concret : L'IA utilise une commande informatique obsolète (ancienne) qui ne fonctionne plus, provoquant un plantage du programme.
Apprentissage déformé (Mappages indirects) : L'IA apprend le mauvais équilibre des choses parce que la bibliothèque était déséquilibrée.
- Analogie : Parce que la bibliothèque contenait 99 % de recettes pour « griller du pain » et seulement 1 % pour « faire du pain », l'IA pense que griller du pain est le seul moyen de cuisiner. Elle ne sait pas faire de bon pain car elle n'a jamais vu assez d'exemples.
- Résultat concret : L'IA est excellente pour écrire du code Python simple mais terrible pour écrire du code dans d'autres langages ou pour des tâches complexes, car les données d'entraînement étaient déséquilibrées.

4. La solution actuelle vs La meilleure solution

Le document souligne que la plupart des entreprises tentent actuellement de résoudre ce problème après que l'IA a écrit le code. Elles agissent comme un inspecteur alimentaire qui goûte la soupe à la fin et dit : « C'est trop salé, jetez-la. »

Le problème : C'est lent, coûteux et réactif. Vous continuez à jeter de la mauvaise soupe.
La recommandation du document : Nous devons devenir des bibliothécaires et des éditeurs avant que l'étudiant ne commence à étudier.
- Au lieu de simplement filtrer la mauvaise soupe à la fin, nous devons entrer dans la bibliothèque, retirer les mauvaises recettes, corriger les fautes de frappe et nous assurer qu'il y a un bon mélange de différents types de plats.
- Les auteurs appellent cela un passage du « filtrage réactif » à la « gouvernance proactive des données ».

5. Ce qui reste difficile ?

Même avec cette nouvelle compréhension, le document admet qu'il existe de grands obstacles :

La bibliothèque « fuyante » : Parfois, les « livres » que l'IA étudie contiennent les réponses aux tests qu'elle passera plus tard. Cela rend l'IA plus intelligente qu'elle ne l'est réellement car elle a simplement mémorisé les réponses.
La bibliothèque « boîte noire » : Nous ne savons souvent pas exactement quels livres ont été utilisés pour entraîner les IA les plus populaires. Sans connaître la source, il est difficile de retracer pourquoi une erreur spécifique s'est produite.
La cible mouvante : Le monde du logiciel évolue rapidement. Une « bonne » recette aujourd'hui peut devenir une « mauvaise » recette demain car la technologie se met à jour. La bibliothèque doit être constamment mise à jour, ce qui est très difficile.

Résumé

Le document conclut que pour obtenir du code fiable de la part de l'IA, nous ne pouvons pas simplement blâmer l'IA ou essayer de corriger sa production a posteriori. Nous devons corriger le matériel source. Si nous voulons que l'IA écrive du code parfait, nous devons d'abord nous assurer que la « bibliothèque » à partir de laquelle elle a appris est propre, équilibrée et à jour. La qualité de la sortie est le reflet direct de la qualité de l'entrée.

Résumé technique : Relier la génération et l'entraînement : Une revue systématique des problèmes de qualité dans les LLM pour le code

Énoncé du problème

Les modèles de langage de grande taille (LLM) ont transformé l'ingénierie logicielle en automatisant des tâches telles que la complétion de code, la réparation et la génération de tests. Cependant, leur adoption pratique est entravée par la génération fréquente de code défectueux, allant des bogues logiques et des erreurs de syntaxe aux vulnérabilités de sécurité critiques et aux violations de conformité. Bien que ces échecs soient souvent attribués à des limitations inhérentes des modèles, des preuves empiriques suggèrent de plus en plus que leurs causes profondes résident dans les imperfections des corpus d'entraînement.

Un écart significatif existe dans la littérature actuelle : les mécanismes spécifiques reliant les problèmes de qualité des données d'entraînement aux problèmes de qualité du code généré restent largement inexplorés. Les recherches existantes souffrent de trois déficiences critiques :

Taxonomies fragmentées : Les études se concentrent sur des dimensions de qualité isolées (par exemple, la sécurité ou la correction) sans cadre unifié pour catégoriser à la fois les défauts du code généré et les imperfections des données d'entraînement.
Correspondances causales floues : Il manque de mécanismes formalisés expliquant comment des défauts spécifiques des ensembles de données (par exemple, des API obsolètes, un déséquilibre des données) se propagent en défauts de code.
Stratégies d'atténuation disjointes : Les techniques de détection et d'atténuation sont dispersées à travers les phases de curation des données, d'entraînement du modèle et de post-génération, manquant d'une approche intégrée du cycle de vie.

Méthodologie

Cet article présente une revue systématique de la littérature (SLR) de 114 études primaires publiées entre fin 2021 et début 2026. La revue a suivi les guidelines établies en ingénierie logicielle, impliquant :

Stratégie de recherche : Un processus multi-étapes combinant des recherches par mots-clés booléens dans cinq grandes bibliothèques numériques (IEEE Xplore, ACM Digital Library, SpringerLink, ScienceDirect, arXiv) avec une méthode de boule de neige rétrospective et prospective.
Critères de sélection : Les études ont été incluses si elles examinaient des LLM appliqués à des tâches de code, se concentraient sur des attributs de qualité spécifiques du code ou des données, et fournissaient une base empirique.
Évaluation de la qualité : Une évaluation structurée utilisant huit critères (par exemple, rigueur méthodologique, profondeur de l'analyse causale, transparence) avec un système de notation (0–16). Les études obtenant moins de 10 points ont été exclues.
Synthèse : Une approche itérative de codage qualitatif (codage ouvert, axial et sélectif) a été utilisée pour extraire les données et synthétiser les résultats en taxonomies unifiées et en cadres causaux.

Contributions clés

1. Taxonomie unifiée bidimensionnelle

Les auteurs proposent une taxonomie complète qui catégorise les problèmes de qualité selon deux dimensions :

Problèmes de qualité du code généré (9 dimensions) :
1. Correction : Erreurs de syntaxe, défauts logiques et utilisation inappropriée des API/dépendances.
2. Sécurité : Vulnérabilités déclenchées par des facteurs externes (par exemple, injection SQL) et vulnérabilités inhérentes (par exemple, clés codées en dur).
3. Conformité : Violations des contraintes légales/éthiques, incluant le code malveillant, les fuites de données personnelles et la violation du droit d'auteur.
4. Robustesse : Incapacité à gérer des entrées anormales ou des conditions limites.
5. Maintenabilité : Complexité structurelle, mauvaise modularité et manque de réutilisabilité.
6. Compréhensibilité : Mauvaises conventions de nommage, commentaires manquants et « nombres magiques ».
7. Efficacité : Complexité temporelle/spatiale sous-optimale et gaspillage de ressources.
8. Parcimonie de la sortie : Génération de code redondant, verbeux ou répétitif.
9. Divers : Problèmes tels que le mauvais suivi des instructions.
Problèmes de qualité des données d'entraînement (2 groupes majeurs) :
- Attributs de code : Défauts au sein d'échantillons individuels (Correction, Sécurité, Conformité, Robustesse, Maintenabilité, Compréhensibilité, Efficacité).
- Attributs non-code : Propriétés macro-niveau des ensembles de données (Risques de conformité/sécurité dans le texte, Déséquilibre de distribution, Redondance, Diversité inadéquate, Contamination des données, Données de faible valeur).

2. Cadre causal et mécanismes de propagation

L'article formalise un cadre causal détaillant 18 mécanismes typiques de correspondance de propagation reliant les problèmes de données aux défauts de code. Ceux-ci sont divisés en :

Correspondances directes (10 mécanismes) : Reproduction explicite des défauts d'attributs de code. Exemples incluent :
- API obsolètes $\rightarrow$ Échecs de compatibilité : Mémorisation d'appels de bibliothèques obsolètes.
- Défauts de syntaxe $\rightarrow$ Erreurs de compilation : Propagation d'une invalidité structurelle à partir d'extraits non vérifiés.
- Pratiques non sécurisées $\rightarrow$ Code vulnérable : Reproduction d'idiomes non sécurisés (par exemple, eval(), entrée non validée).
Correspondances indirectes (8 mécanismes) : Distorsion de la distribution d'apprentissage due aux attributs non-code. Exemples incluent :
- Redondance $\rightarrow$ Réduction de la diversité : Surapprentissage à des motifs répétitifs dus à des échantillons dupliqués.
- Déséquilibre de distribution $\rightarrow$ Performance biaisée : Performance déséquilibrée entre les langages ou les domaines due à la rareté des données.
- Désalignement des instructions $\rightarrow$ Dérive sémantique : Génération de code syntaxiquement correct mais sémantiquement incorrect en raison de docstrings inadaptés.

3. Synthèse des techniques de détection et d'atténuation

La revue synthétise les techniques de pointe à travers le cycle de vie des LLM :

Détection : Dépasse la vérification statique des règles pour adopter des cadres hybrides combinant analyse dynamique (tests basés sur l'exécution, surveillance en temps d'exécution), analyse statique (outils basés sur des règles, revue humaine) et détection basée sur le modèle (LLM en tant que juge, classificateurs ML légers).
Atténuation : Identifie un passage d'un filtrage réactif post-génération à une gouvernance proactive centrée sur les données. Les stratégies incluent :
- Niveau données : Filtrage par retour d'exécution, assainissement basé sur des règles, nettoyage par LLM et équilibrage des données.
- Niveau modèle : Affinage, alignement des instructions (RLHF/DPO) et optimisation basée sur la récompense.
- Niveau génération : Ingénierie des invites, génération augmentée par la récupération (RAG), interventions au moment du décodage et auto-réflexion itérative.

Résultats et constatations

Tendances de la recherche : La recherche sur la qualité du code a explosé depuis 2023, avec un changement clair d'un focus unique sur la Correction (52 études) vers une vision multidimensionnelle incluant la Sécurité (24) et la Maintenabilité (22).
Analyse des causes profondes : La revue confirme que les défauts de code généré sont rarement des déficits de raisonnement isolés, mais sont profondément enracinés dans la qualité des données d'entraînement. « Des déchets en entrée, des déchets en sortie » s'applique non seulement aux erreurs explicites, mais aussi aux biais distributionnels systémiques (par exemple, un déséquilibre des données causant une mauvaise généralisation dans les langues à faibles ressources).
Changement méthodologique : Le domaine est en transition d'un filtrage post-génération réactif et basé sur des heuristiques vers une gouvernance proactive centrée sur les données et une réparation en boucle fermée.
Identification des lacunes : La recherche actuelle manque de méthodes d'attribution causale formelles pour retracer des échecs de génération spécifiques vers des origines de données spécifiques, et la contamination des référentiels reste une menace persistante pour l'intégrité de l'évaluation.

Importance et revendications

L'article revendique d'être la première revue systématique de la littérature à combler explicitement le fossé entre la qualité des données d'entraînement et la qualité du code généré. Son importance réside dans :

Établissement d'un cadre unifié : Fournir un vocabulaire et une taxonomie cohérents qui résolvent la fragmentation de la littérature existante, permettant une comparaison systématique des problèmes de qualité.
Formalisation de la causalité : Aller au-delà de la corrélation pour cartographier des mécanismes de propagation spécifiques, permettant aux chercheurs et aux praticiens de retracer les échecs de génération vers leurs origines dans les ensembles de données.
Orientation de la gouvernance future : Affirmer que des LLM fiables pour le code ne peuvent être obtenus par la seule amélioration de l'architecture des modèles. Au contraire, la communauté doit adopter des stratégies de curation de données intégrée et d'évaluation continue qui traitent la qualité des données comme le levier principal de la fiabilité logicielle.

Les auteurs concluent que si l'« ingénierie de l'attelage » (par exemple, RAG, utilisation d'outils) offre une compensation au moment du déploiement, elle ne remplace pas la nécessité de données d'entraînement de haute qualité. La fiabilité future dépend du passage d'interventions disjointes et spécifiques à une étape à des pipelines de qualité de bout en bout qui assurent une traçabilité bidirectionnelle entre les corpus d'entraînement et les artefacts générés.