💬 NLP

Library Hallucinations in LLM-Generated Code: A Risk Analysis Grounded in Developer Queries

Cet article présente la première étude systématique de la manière dont des variations réalistes de prompts de développeur, telles que des fautes d'orthographe et des noms fictifs, déclenchent des hallucinations de bibliothèques dans le code généré par les LLM, révélant des vulnérabilités significatives et introduisant le benchmark LibHalluBench pour permettre une évaluation et une atténuation reproductibles de ces risques.

Auteurs originaux : Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

Publié 2026-05-20

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

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 ayez un assistant très talentueux, confiant, mais légèrement oublieux, qui est un expert en écriture de code informatique. Vous lui demandez de créer un outil spécifique, et il commence joyeusement à taper. Cependant, cet assistant a une habitude dangereuse : parfois, lorsqu'il ne connaît pas le nom exact de l'outil dont il a besoin, il en invente un. Il crée une bibliothèque (une collection de code préfabriquée) qui n'existe pas, mais il l'écrit avec une telle assurance que vous pourriez ne pas réaliser qu'elle est fictive jusqu'à ce que vous essayiez de l'utiliser et qu'elle échoue.

Ce document plonge en profondeur dans pourquoi cet assistant invente ces outils fictifs, spécifiquement lorsque vous lui donnez des instructions légèrement différentes ou que vous commettez de petites erreurs.

Voici la décomposition de leurs découvertes à l'aide d'analogies simples :

1. Le piège du « Voyage dans le temps »

Les chercheurs ont découvert que si vous demandez à votre assistant un outil « de 2025 » (une année qui n'est pas encore arrivée ou qui dépasse sa formation), l'assistant devient très nerveux et commence à halluciner de manière sauvage.

L'analogie : Imaginez demander à un bibliothécaire un livre publié dans le futur. Au lieu de dire « Je n'ai pas cela », le bibliothécaire pourrait inventer un titre, une couverture et un résumé qui semblent parfaits mais qui n'existent pas.
Le résultat : Lorsqu'on lui demande des bibliothèques « de 2025 », jusqu'à 85 % du temps, l'assistant invente une fausse bibliothèque. Il est terrible pour connaître sa propre « date de coupure des connaissances » (la date à laquelle il a cessé d'apprendre).

2. Le piège de la « Faute de frappe » (Orthographe négligente)

Si vous faites accidentellement une faute de frappe dans le nom d'une vraie bibliothèque, l'assistant ne vous corrige souvent pas. Au lieu de cela, il s'entête et fait semblant que la version mal orthographiée est réelle.

L'analogie : Imaginez demander à un chef « Spagetti » (en oubliant le 'h'). Au lieu de dire « Voulez-vous dire Spaghetti ? », le chef pourrait simplement prendre une boîte étiquetée « Spagetti » sur une étagère qu'il a inventée, ou pire, il pourrait inventer un nouveau plat appelé « Spagetti » qui n'existe pas.
Le résultat :
- Une faute de frappe d'une lettre (comme numpi au lieu de numpy) a entraîné l'utilisation de fausses bibliothèques dans 26 % des cas.
- Un nom de bibliothèque fictif (quelque chose qui semble réel mais ne l'est pas, comme « GaussianTools ») a été accepté et utilisé dans jusqu'à 99 % des cas. L'assistant est si désireux de vous satisfaire qu'il utilisera un outil fictif plutôt que de vous dire qu'il n'existe pas.

3. Le piège de l'« Adjectif » (Ce qui ne fonctionne pas)

Curieusement, si vous demandez une bibliothèque qui est « rapide », « facile » ou « moderne », l'assistant ignore généralement ces mots et choisit simplement une bibliothèque standard et réelle qu'il connaît.

L'analogie : Si vous demandez une « voiture rapide », l'assistant vous donne simplement une Toyota standard. Il n'invente pas une « voiture volante super-rapide » car il sait que ces adjectifs sont vagues.
Le résultat : Les adjectifs comme « rapide » ou « léger » ont rarement provoqué des hallucinations. Le danger provient de contraintes spécifiques (comme des dates) ou d'erreurs (comme des fautes de frappe).

4. Le piège du « Raisonnement » (Penser trop fort)

Les chercheurs ont tenté de résoudre ce problème en demandant à l'assistant de « réfléchir étape par étape » ou de « vérifier vos faits » avant de répondre.

L'analogie : C'est comme dire à un élève nerveux « Respire un grand coup et réfléchis bien à ce problème de mathématiques ». Parfois, cela aide. Mais souvent, l'élève devient simplement plus confiant dans sa mauvaise réponse parce qu'il a passé plus de temps à la justifier.
Le résultat : Ces « astuces » de raisonnement n'ont pas fonctionné de manière cohérente. En fait, elles ont parfois rendu les hallucinations pires. L'assistant expliquait avec assurance pourquoi sa fausse bibliothèque était réelle, rendant plus difficile pour vous de repérer l'erreur.

5. La solution « Outil » (Vérifier l'annuaire téléphonique)

Les chercheurs ont testé la fourniture d'un outil simple à l'assistant : un bouton qui vérifie si une bibliothèque existe réellement dans la base de données officielle (PyPI).

L'analogie : Au lieu que l'assistant devine, vous lui donnez un annuaire téléphonique. S'il dit « J'utiliserai Spagetti », il consulte le livre, voit qu'il n'y est pas, puis dit « Oh, cela n'existe pas ».
Le résultat : Cela a beaucoup aidé, mais ce n'était pas une solution magique. L'assistant oubliait encore parfois de consulter le livre, ou le consultait mais décidait d'ignorer le résultat et d'utiliser le nom fictif de toute façon.

La grande conclusion : LIBHALLUBENCH

Parce que c'est un problème si important, les auteurs ont créé un nouveau test appelé LIBHALLUBENCH.

L'analogie : Pensez-y comme à un « permis de conduire » spécifiquement conçu pour voir si une voiture autonome va halluciner un faux panneau d'arrêt. Il contient des milliers de questions pièges (comme « donnez-moi une bibliothèque de 2025 » ou « utilisez ce nom mal orthographié ») pour tester systématiquement la probabilité que différents modèles d'IA inventent de faux outils.

Pourquoi devriez-vous vous en soucier ?

Si vous êtes un développeur utilisant l'IA pour écrire du code, et que l'IA invente une fausse bibliothèque, votre code plantera lorsque vous essayerez de l'exécuter. Pire encore, si un pirate crée une fausse bibliothèque qui correspond à celle inventée par l'IA (une astuce appelée « slopsquatting »), votre système pourrait être infecté par un logiciel malveillant.

En bref : Les générateurs de code par IA sont excellents, mais ils sont dangereusement confiants lorsqu'ils ne connaissent pas la réponse. Ils inventeront de faux outils pour satisfaire votre demande, surtout si vous demandez quelque chose du futur ou si vous faites une petite faute de frappe. Nous avons besoin de meilleures façons de les empêcher d'inventer des choses.

Résumé technique : Hallucinations de bibliothèques dans le code généré par les LLM

Énoncé du problème

Les modèles de langage de grande taille (LLM) sont devenus incontournables dans le développement logiciel moderne, pourtant ils « hallucinent » fréquemment en inventant des bibliothèques inexistantes. Bien que des recherches antérieures aient reconnu les hallucinations de bibliothèques comme un mode de défaillance, la compréhension de la manière dont ces erreurs se manifestent dans des conditions d'utilisation réalistes reste limitée. Plus précisément, il demeure incertain comment les variations des invites des développeurs — telles que des descriptions en langage naturel, des fautes de frappe utilisateur ou des noms de bibliothèques fabriqués — influencent le taux auquel les LLM génèrent des imports invalides ou des appels invalides à des bibliothèques valides. Ces hallucinations posent des risques significatifs, notamment des builds brisés, des développeurs induits en erreur et une exposition à des menaces de chaîne d'approvisionnement comme le « slopsquatting » (où des attaquants enregistrent des bibliothèques que les LLM hallucinent fréquemment).

Méthodologie

Les auteurs présentent la première étude systématique de l'influence des variations d'invites au niveau utilisateur sur les hallucinations de bibliothèques à travers sept LLM de production diversifiés (GPT-4o-mini, GPT-5-mini, Ministral-8B, Qwen2.5-Coder, Llama-3.3, DeepSeek-V3.1 et Claude-4.5-Haiku).

Conception expérimentale :
L'étude utilise BigCodeBench comme ensemble de données de départ, filtré pour 356 tâches Python utilisant des bibliothèques externes. Les expériences sont divisées en deux catégories principales :

Expérience 1 : Variations linguistiques utilisateur :
- Source de données : Plus de 20 000 questions provenant de Software Recommendations StackExchange (SRSE) ont été analysées pour identifier les descripteurs utilisateurs courants.
- Variations : Les invites ont été modifiées pour inclure des descriptions basées sur des adjectifs (par exemple, « rapide », « léger », « meilleur ») et des descriptions basées sur le temps (par exemple, « de 2023 », « de 2025 »).
- Objectif : Déterminer si les variations en langage naturel déclenchent des hallucinations.
Expérience 2 : Erreurs utilisateur contrôlées :
- Types d'erreurs : L'étude a introduit des erreurs spécifiques dans les invites :
  - Fautes de frappe à un caractère (distance d'édition 1, par exemple numpi pour numpy).
  - Fautes de frappe à plusieurs caractères (distance d'édition 2–8, par exemple graphly pour plotly).
  - Noms/membres factices : Bibliothèques ou membres complètement inexistants générés pour simuler des demandes de suivi suite à des hallucinations précédentes.
- Objectif : Quantifier la robustesse des LLM face aux fautes de frappe et aux entités fabriquées.

Pipeline d'évaluation :

Détection : Le code généré a été analysé à l'aide du module ast de Python. Les noms de bibliothèques ont été vérifiés contre l'Index des paquets Python (PyPI) avec normalisation, et les membres de bibliothèques contre la documentation officielle des dernières versions de bibliothèques.
Métriques : L'étude a mesuré le taux d'hallucination de réponse (RHR) et le taux d'hallucination de tâche (THR).
Enquêtes supplémentaires : Les auteurs ont examiné l'efficacité des stratégies d'ingénierie d'invite (Chaîne de pensée, Retour en arrière, Auto-analyse) et testé la généralisabilité de l'écosystème en utilisant CodeInsight (JavaScript, Rust) et une atténuation augmentée par des outils (vérifications d'existence PyPI).

Résultats clés

1. Sensibilité aux variations d'invite

Adjectifs vs Temps : Les descriptions basées sur des adjectifs (par exemple, « rapide », « open-source ») ont rarement déclenché des hallucinations (taux $\approx$ 0 %). En revanche, les invites basées sur le temps ont été un puissant déclencheur. Les demandes de bibliothèques « de 2025 » ont induit des hallucinations dans jusqu'à 85 % des tâches (spécifiquement pour GPT-4o-mini), un taux significativement plus élevé que les demandes « de 2023 ».
Erreurs utilisateur : Les LLM ont montré une faible robustesse face aux erreurs de nommage.
- Les fautes de frappe à un caractère ont déclenché des hallucinations dans jusqu'à 26 % des tâches.
- Les fautes de frappe à plusieurs caractères ont déclenché des hallucinations dans jusqu'à 79 % des tâches.
- Les noms de bibliothèques factices ont été acceptés dans jusqu'à 99 % des tâches pour certains modèles (par exemple, GPT-5-mini, Ministral-8B), indiquant une tendance à la « sycophancie » où le modèle se conforme à la prémisse incorrecte de l'utilisateur plutôt que de la corriger.

2. Noms de bibliothèques vs Hallucinations de membres

Noms de bibliothèques : Les modèles étaient hautement susceptibles d'halluciner des bibliothèques entières inexistantes lorsqu'ils étaient sollicités avec des erreurs ou des contraintes temporelles.
Membres de bibliothèques : Les hallucinations de membres (fonctions/classes) au sein de bibliothèques valides étaient généralement plus faibles (majoritairement 1 %–5 %) mais toujours présentes. Fait intéressant, les modèles plus récents (GPT-5-mini, DeepSeek-V3.1) ont parfois présenté des taux d'hallucination de membres plus élevés que les anciens, suggérant souvent des fonctions obsolètes sans spécification de version.

3. Atténuation et généralisabilité

Ingénierie d'invite : Des stratégies légères comme la Chaîne de pensée et l'invite de Retour en arrière se sont révélées fiables et ont parfois augmenté les taux d'hallucination en renforçant un raisonnement incorrect. Les vérifications explicites et l'Auto-analyse ont montré plus de promesses mais étaient incohérentes entre les modèles.
Utilisation d'outils : Fournir un outil d'existence PyPI a réduit les hallucinations de manière significative (par exemple, GPT-4o-mini est descendu à <3 % pour les invites basées sur l'année) mais ne les a pas éliminées. Les modèles ont souvent échoué à invoquer l'outil ou ont ignoré les résultats négatifs.
Écosystèmes : Les schémas d'hallucination ont persisté à travers Python, JavaScript et Rust, suggérant que la vulnérabilité n'est pas limitée à un seul langage ou écosystème.

Contributions

Étude systématique : La première analyse fine de l'impact des variations d'invite (langage et erreurs) sur les hallucinations de bibliothèques, révélant que les formulations basées sur le temps et les fautes de frappe sont des déclencheurs critiques.
Lien entre sycophancie et typosquatting : L'article révèle un lien novateur entre le comportement des LLM et les risques de chaîne d'approvisionnement, démontrant que les modèles hallucinent souvent avec assurance des bibliothèques en réponse à de légères fautes de frappe, amplifiant potentiellement les attaques de typosquatting et de slopsquatting.
LIBHALLUBENCH : Introduction d'un nouveau benchmark contenant 4 173 invites étiquetées dérivées de conditions à haut risque (basées sur l'année, la rareté et les erreurs) pour permettre une évaluation reproductible des hallucinations de bibliothèques.
Ressources ouvertes : Publication du code, des sorties complètes des modèles et du benchmark pour soutenir la recherche future et le développement d'atténuations.

Importance et affirmations

L'article soutient que la fragilité des LLM face aux variations naturelles d'invite constitue une vulnérabilité systémique. Les auteurs affirment que :

Les LLM actuels ne peuvent pas être utilisés pour valider les noms de bibliothèques ou les membres, même lorsque les utilisateurs fournissent des noms spécifiques (mais incorrects).
Les demandes courantes des développeurs pour des bibliothèques « à jour » ou « récentes » constituent un vecteur principal d'hallucination, indépendamment des limites de connaissances.
Les stratégies d'atténuation existantes comme la Chaîne de pensée sont insuffisantes pour ce mode de défaillance spécifique.
Le risque va au-delà des simples erreurs de code pour toucher aux menaces de sécurité, car le taux d'acceptation élevé de bibliothèques factices pourrait faciliter l'adoption de paquets malveillants (slopsquatting).

Les auteurs concluent que des défenses robustes nécessitent plus que de l'ingénierie d'invite ; elles nécessitent probablement des changements au niveau du modèle, des mécanismes de vérification externes et un changement dans la manière dont les LLM gèrent l'incertitude concernant la validité des bibliothèques. L'étude souligne que, bien que les résultats soient basés sur des ensembles de données et des modèles spécifiques, les schémas observés suggèrent un problème plus large et systémique dans la génération de code par LLM.