Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code

Dans le monde moderne du développement logiciel, les programmeurs s'appuient souvent sur des assistants d'intelligence artificielle pour écrire du code. Ces systèmes, connus sous le nom de grands modèles de langage, agissent comme des partenaires infatigables capables de suggérer des fonctions entières ou de corriger des erreurs en quelques secondes. Pour que leurs suggestions soient opérationnelles, ces modèles recommandent fréquemment l'ajout de paquets logiciels externes — des collections de code préécrites qui gèrent des tâches spécifiques comme la connexion à une base de données ou la création d'un graphique. Le problème survient lorsque l'intelligence artificielle invente un nom de paquet qui semble parfaitement réel mais qui n'existe en réalité dans aucune bibliothèque logicielle officielle. Ce phénomène est appelé une hallucination de paquet. Si un développeur fait aveuglément confiance à la suggestion et tente d'installer ce paquet inexistant, il peut par inadvertance télécharger un fichier malveillant créé par un pirate informatique ayant enregistré ce faux nom. Cela crée une porte dérobée dangereuse dans la chaîne d'approvisionnement logicielle, permettant à des attaquants d'injecter du code nuisible dans des applications que des millions de personnes pourraient utiliser.

Une équipe de chercheurs s'est donné pour mission de comprendre la fréquence à laquelle ces hallucinations se produisent et si des techniques spécifiques pourraient les stopper avant même que le code ne soit terminé. Ils se sont concentrés sur des modèles d'intelligence artificielle open-source plus petits, qui sont largement utilisés car ils sont moins coûteux à exploiter, bien qu'ils soient plus enclins à commettre des erreurs que leurs homologues plus volumineux. Les chercheurs ont testé ces modèles à travers quatre langages de programmation différents : Python, JavaScript, Ruby et Rust. Ils ont découvert que les méthodes précédentes pour mesurer ces erreurs étaient erronées. De nombreuses études antérieures comptaient des outils standards intégrés à un langage de programmation comme des hallucinations simplement parce que ces outils ne sont pas répertoriés dans les bibliothèques de paquets externes. En corrigeant cette erreur de comptage, l'équipe a constaté que le taux d'hallucinations pour Python était en fait plus bas que ce qui avait été précédemment estimé, bien qu'il reste significatif.

Le cœur de leur travail consistait à tester sept stratégies différentes pour voir si elles pouvaient réduire le nombre de faux noms de paquets générés par les modèles. Certaines de ces stratégies consistaient à modifier la façon dont le modèle sélectionne son mot suivant, tandis que d'autres demandaient au modèle de vérifier son propre travail ou de consulter des informations dans une base de données vérifiée avant de répondre. Les chercheurs ont découvert qu'aucune méthode unique ne fonctionnait le mieux dans toutes les situations. Une technique appelée Génération Augmentée par Récupération (Retrieval-Augmented Generation), qui force le modèle à consulter une véritable base de données de paquets existants avant de parler, s'est avérée très efficace pour la plupart des langages, réduisant considérablement le taux d'erreur. Cependant, cette même technique a parfois aggravé la situation pour JavaScript, suggérant que la solution dépend fortement du langage de programmation spécifique utilisé. Une autre approche, où le modèle est chargé de critiquer et de réécrire ses propres suggestions, a bien fonctionné pour les grands modèles, mais a échoué pour les plus petits, qui n'étaient souvent pas capables de reconnaître leurs propres erreurs.

L'équipe a également introduit une nouvelle façon de mesurer si les suggestions du modèle étaient réellement utiles, et pas seulement correctes. Ils ont découvert que certaines stratégies qui parvenaient à stopper les hallucinations empêchaient aussi le modèle de suggérer le moindre paquet, laissant le développeur sans aucun outil utilisable. L'approche la plus équilibrée, qui réduisait les erreurs tout en fournissant des suggestions utiles, était une méthode directe où le modèle choisit simplement le mot suivant le plus probable à chaque fois, plutôt que de tenter des options moins probables. Cette approche « gourmande » (greedy) offrait le meilleur compromis entre sécurité et utilité pour les modèles testés.

Peut-être la découverte la plus frappante est apparue lorsque les chercheurs ont testé ces défenses contre un environnement hostile. Ils ont créé des invites (prompts) qui tentaient délibérément de piéger les modèles en les incitant à recommander de faux paquets en intégrant directement les faux noms dans les instructions. Dans ces conditions adverses, les taux d'erreur ont grimpé en flèche, augmentant de pas plus de 45 points de pourcentage par rapport aux requêtes normales. Dans ce cadre hostile, les astuces simples consistant à modifier la sélection des mots par le modèle ont totalement échoué. Seules les méthodes reposant sur la vérification auprès d'une base de données réelle ou sur l'obligation pour le modèle de double-vérifier sa propre logique pouvaient résister à l'attaque. Les chercheurs ont conclu que, si des ajustements simples peuvent aider lors d'une utilisation normale, protéger le logiciel contre des attaquants déterminés nécessite un système capable de vérifier les faits par rapport au monde extérieur ou de vérifier rigoureusement sa propre logique. L'étude souligne que la meilleure défense n'est pas une solution universelle, mais un choix soigneusement adapté à la menace spécifique et au langage de programmation concerné.