Résumé Technique : DELULU – Un Benchmark Multi-Linguistique Vérifié pour la Détection d'Hallucinations de Code dans les Tâches de Remplissage du Milieu

Énoncé du Problème

Les Grands Modèles de Langage (LLM) utilisés pour la génération de code produisent fréquemment des hallucinations dans les tâches de Remplissage du Milieu (FIM). Il s'agit de complétions syntaxiquement valides et sémantiquement plausibles mais factuellement incorrectes, telles que des méthodes d'API inventées, des paramètres invalides, des variables non définies ou des imports inexistants. Bien que ces erreurs passent souvent une revue de code superficielle, elles introduisent des bugs d'exécution latents qui ne se manifestent que dans des conditions d'exécution spécifiques.

Les benchmarks actuels pour la génération de code (par exemple, HumanEval, MBPP) se concentrent principalement sur la génération au niveau de la fonction à partir de spécifications en langage naturel ou manquent de vérification d'exécution pour les tâches FIM. Les benchmarks FIM existants (par exemple, HumanEval Infilling, SAFIM) sont souvent limités au Python, ne distinguent pas les types d'erreurs et manquent de vérité terrain basée sur l'exécution pour vérifier que les hallucinations provoquent effectivement des échecs d'exécution. De plus, il n'existe aucune évaluation systématique de la capacité des LLMs de pointe à détecter ces hallucinations lorsqu'ils agissent en tant que réviseurs de code.

Méthodologie : Le Benchmark DELULU

Les auteurs présentent DELULU, un benchmark multi-linguistique vérifié comprenant 1 951 échantillons FIM répartis sur 7 langages de programmation (Python, Java, TypeScript, Go, Rust, C#, C++) et 4 catégories d'hallucinations. Le benchmark est construit via un pipeline adversarial rigoureux en cinq étapes conçu pour garantir la difficulté, la correction et la vérification par exécution :

1. Génération d'Hallucinations : En utilisant CLAUDE SONNET comme seul générateur, le système crée des variantes « hallucinées » de complétions idéales extraites de vrais dépôts GitHub. Le générateur est contraint de modifier exactement un élément (nom de méthode, paramètre, variable ou import) tout en gardant le reste du code identique, assurant ainsi que l'hallucination soit plausible et indistinguable du code réel en surface.
2. Évaluation par Juge Multi-Modèle : Quatre LLMs de pointe diversifiés (GPT-5.1, GPT-5.2, GPT-5.2-CODEX, GLM-4.7) évaluent indépendamment les paires.
3. Échantillonnage Adversarial Itératif : Le pipeline analyse les désaccords des juges et utilise un regroupement basé sur les embeddings pour extraire de nouveaux exemples de code sémantiquement similaires qui ressemblent aux modes d'échec des juges. Cette boucle s'exécute sur trois itérations, faisant émerger progressivement des échantillons plus difficiles à mesure que la précision des juges diminue au fil du temps.
4. Sélection Basée sur la Difficulté : Les échantillons sont notés selon leur capacité à tromper les juges. Seuls les échantillons suffisamment difficiles pour tromper au moins un juge (ou provoquer un rejet excessif de code idéal) sont conservés.
5. Vérification d'Exécution Basée sur Docker : C'est le différentiateur critique. Chaque échantillon est emballé dans un conteneur Docker autonome.
   • La complétion idéale doit compiler et s'exécuter sans erreur.
   • La complétion hallucinée doit produire une erreur d'exécution spécifique et vérifiable correspondant à sa catégorie :
     • Méthode : AttributeError
     • Paramètre : TypeError
     • Variable non définie : NameError
     • Import : ImportError
   • Une boucle de correction assistée par CLAUDE SONNET résout les problèmes de dépendance pour garantir le succès de la vérification.
6. Revue par des Experts Humains : Un panel de trois experts humains examine les échantillons vérifiés par Docker pour éliminer les biais résiduels, les cas triviaux ou les erreurs d'étiquetage, aboutissant au jeu de données final de 1 951 échantillons.

Contributions Clés

1. Taxonomie d'Hallucinations en Quatre Catégories : Une taxonomie structurée où chaque catégorie (Méthode, Paramètre, Variable non définie, Import) correspond à une classe distincte d'erreurs d'exécution vérifiable, permettant une vérité terrain basée sur l'exécution.
2. Pipeline de Curation Adversarial : Un processus novateur en cinq étapes qui associe du code réel à des contreparties hallucinées, filtre les cas triviaux via une sonde multi-modèle et garantit une vérification basée sur l'exécution.
3. Jeu de Données Multi-Linguistique Vérifié par Exécution : 1 951 échantillons répartis sur 7 langages, chacun emballé dans un conteneur Docker autonome avec trois modes d'appel (vérifier l'idéal, vérifier l'halluciné, vérifier le correctif).
4. Évaluation Complète : Une évaluation de 11 modèles FIM à poids ouverts issus de 5 familles (Qwen2.5-Coder, CodeLlama, DeepSeek-Coder-V2, StarCoder2) couvrant de 0,5 Md à 32 Md de paramètres.
5. Étude de Détection par Juges de Pointe : Une évaluation de 8 LLMs de pointe agissant en tant que réviseurs de code pour détecter les hallucinations, révélant des écarts significatifs dans les capacités de détection.

Résultats

Performance de Génération

• Limites de Mise à l'Échelle : Le modèle le plus performant, Qwen2.5-Coder-32B, n'a atteint que 84,5 % de pass@1 sur les 950 contextes FIM uniques. Cela indique qu'à 32 Md de paramètres, les modèles échouent dans environ un contexte unique sur sept.
• Cohérence Inter-Familles : La difficulté est intrinsèque à la tâche et non spécifique à une famille de modèles. Aucun modèle inter-famille n'a dépassé 0,77 de Similarité d'Édition. Même le meilleur modèle inter-famille (DeepSeek-Coder-V2-Lite-Instruct) a pris 1,8 point de pass@1 de retard sur le meilleur modèle Qwen.
• Types d'Hallucinations : Les hallucinations d'import ont été systématiquement la catégorie la plus difficile pour toutes les tailles de modèles et tous les langages (par exemple, 77,1 % de pass@1 pour Qwen-32B sur les imports contre >85 % sur les autres types), suggérant que la détection des imports factices nécessite une connaissance spécifique de l'écosystème plutôt qu'une simple complétion de motifs locaux.
• Ajustement par Instruction : L'ajustement par instruction a considérablement amélioré le comportement « stop » (Correspondance Exacte) mais a eu un impact minimal sur les connaissances sous-jacentes nécessaires pour éviter d'halluciner des identifiants (la Similarité d'Édition et le CodeBLEU sont restés similaires entre les modèles de base et les modèles instruct).

Performance de Détection

• Détection Non Résolue : Même le modèle juge le plus performant, Claude-4.5-Opus, n'a atteint que 92,1 % de précision des deux côtés (acceptation correcte de l'idéal et rejet de l'halluciné).
• Écart de Détection : Les juges plus petits ont performé significativement moins bien (par exemple, GPT-4o-mini à 52,3 %), établissant une plage de capacité de 40 points.
• Goulot d'Étranglement des Imports : La détection des hallucinations d'import est restée la tâche la plus difficile pour tous les juges (83,4 % pour Opus), confirmant que la distinction entre noms de packages réels et factices constitue un écart de capacité persistant.
• Faux Négatifs : Le principal goulot d'étranglement pour les juges était le rejet des complétions hallucinées, et non l'acceptation des complétions idéales.

Importance et Revendications

L'article revendique que DELULU comble une lacune critique dans l'évaluation du code en fournissant le premier benchmark offrant simultanément :

1. Une catégorisation systématique des hallucinations avec des types fins.
2. Une couverture multi-linguistique au-delà du Python.
3. Une vérification basée sur l'exécution garantissant que les hallucinations produisent de réelles erreurs d'exécution.
4. Un calibrage de difficulté adversarial assurant que le benchmark est véritablement exigeant.

Les auteurs soulignent que la difficulté révélée par DELULU est intrinsèque à la tâche plutôt que spécifique à une famille, comme en témoignent les taux d'échec constants à travers des architectures de modèles diverses. Les résultats suggèrent que la simple mise à l'échelle des paramètres du modèle est insuffisante pour résoudre les hallucinations de code ; des interventions ciblées telles que la curation des données d'entraînement et l'ajustement fin de style vérificateur sont probablement nécessaires.

L'article positionne DELULU non seulement comme un benchmark de génération, mais comme un outil réutilisable pour évaluer les modèles de révision de code et de vérification, soulignant que la capacité à détecter les hallucinations est actuellement un problème non résolu, même pour les modèles de pointe. Le benchmark est publié sous forme d'artefact de test uniquement pour prévenir la contamination, les auteurs décourageant explicitement l'ajustement fin sur le jeu de données.