Éliminer les hallucinations dans le code de l'IA Examens

Hallucinations : Un gros problème pour les développeurs

Les grands modèles de langage (LLM) sont incroyablement puissants, mais ils sont également connus pour leurs hallucinations. Chez Korbit, nous en avons fait l'expérience directe lors du développement de notre réviseur de code GenAI. Notre système analysait les demandes de téléchargement contenant des dizaines de milliers de lignes de code afin de détecter les bogues potentiels. Mais nous avons rapidement remarqué un énorme problème : de nombreux problèmes signalés n'étaient pas de vrais bogues, mais des hallucinations.

Ces faux positifs n'ont pas seulement fait perdre du temps aux développeurs, ils ont aussi érodé la confiance dans les revues de code automatisées. De toute évidence, il s'agissait d'un problème que nous devions prendre à bras-le-corps.

Définir clairement les hallucinations

Pour traiter les hallucinations, nous avons d'abord dû les définir rigoureusement. Nous avons passé des semaines à examiner, collecter et annoter manuellement des centaines de problèmes détectés dans des demandes d'extraction Python, JavaScript et TypeScript du monde réel - couvrant tout, des nouvelles fonctionnalités aux tâches de refactorisation en passant par les corrections de bogues. Nous avons inclus à la fois notre propre code et divers référentiels open-source pour garantir un ensemble de données représentatif.

Au cours de cet examen approfondi, une question fondamentale s'est posée : Qu'est-ce qu'une hallucination ?

Il est évident que si un LLM génère des absurdités, telles que des bibliothèques imaginaires, des fonctions inexistantes ou des problèmes fabriqués de toutes pièces, il s'agit d'une hallucination.

Mais de nombreux cas sont également tombés dans une zone grise. Par exemple, supposons que le LLM identifie un bogue de boucle infinie dans une fonction appelée func_ab(...), mais que la fonction réelle s'appelle func_abc(...). Le LLM a fait une faute de frappe mineure, mais le bogue sous-jacent de la boucle infinie qu'il a signalé est réel. S'agit-il encore d'une hallucination, ou devrions-nous la considérer comme valide et exploitable ?

Un autre scénario subtil est celui où le LLM signale un problème qui est techniquement exact mais qui ne peut être résolu compte tenu du contexte du projet. Imaginons un service web ancien qui doit utiliser des points d'extrémité HTTP non cryptés (par exemple, parce que certains clients ont signé un contrat avec cette exigence d'API exacte il y a de nombreuses années). Un LLM pourrait suggérer de passer à HTTPS - une recommandation technique parfaitement valable - mais les développeurs ne peuvent tout simplement pas l'appliquer en raison de contraintes externes. Dans ce scénario, l'étiqueter comme un bogue serait trompeur et gaspillerait les efforts des développeurs.

Cette constatation nous a amenés à réaliser que la "précision technique" ne suffisait pas à elle seule. Ce qui comptait tout autant, voire plus, c'était l'actionnabilité : un développeur compétent pouvait-il comprendre clairement le problème et faire quelque chose pour y remédier ?

Revenons donc à nos exemples précédents :

• En ce qui concerne la faute de frappe dans le nom de la fonction, les développeurs comprendraient facilement le problème et sauraient exactement comment le résoudre, ce qui le rendrait exploitable et donc valide (ou du moins partiellement valide).
  
  
• En ce qui concerne le scénario HTTP immuable, bien que techniquement correct, le problème ne peut être résolu dans le contexte, ce qui en fait une hallucination.

Un schéma d'annotation pour les hallucinations

Sur la base de notre analyse, nous avons créé un schéma d'annotation pratique pour classer les questions de manière cohérente :

• Résoluble : Un développeur compétent peut comprendre le problème et prendre les mesures appropriées.
• Impossible à résoudre : Un développeur compétent ne peut pas comprendre le problème ou ne peut pas agir sur une partie de celui-ci compte tenu de la description et du contexte de son dépôt et de son projet.
• Inconnu : le contexte est insuffisant pour qu'un annotateur puisse classer le problème en toute confiance.

Il convient de noter qu'une question est classée comme "résoluble" même si elle ne l'est qu'en partie.

Ce que nos données révèlent

En appliquant ce schéma à notre ensemble de données, nous avons découvert plusieurs modèles critiques :

• Jusqu'à 30 % des problèmes signalés étaient des hallucinations, avec des variations significatives selon la langue et le dépôt. Comme prévu, les hallucinations constituaient un problème majeur !
  
  
• La plupart des hallucinations ont été facilement repérées par les annotateurs et les réviseurs humains, mais seulement après avoir perdu un temps précieux. Cela signifie qu'elles n'étaient pas trop complexes (par exemple, la plupart d'entre elles pouvaient être identifiées en examinant uniquement la fonction et la classe en cours).
  
  
• Les hallucinations résultent généralement d'un manque de contexte suffisant (le LLM ne dispose pas d'informations essentielles) ou d'un contexte trop important (le LLM est submergé par un énorme fichier d'entrée et se déconcentre).
  
  
• Différents modèles ont montré des types distincts de comportements d'hallucination. Par exemple, le modèle GPT-4o d'OpenAI a régulièrement signalé un problème de "journalisation manquante" dans de nombreuses fonctions sans tenir compte de la pile d'appels de la fonction (par exemple, les fonctions parentes où la journalisation pourrait avoir lieu). Les modèles d'Anthropic, cependant, n'ont pas montré ce même schéma.

Notre voie à suivre : Ensembles tenant compte du contexte

Cette analyse complète a guidé nos prochaines étapes : construire un système de détection des hallucinations plus intelligent et mieux adapté au contexte. C'est ainsi que nous avons commencé à enquêter :

• Chaîne de pensée : Application de la technique de la chaîne de pensée pour amener le MLD à mieux raisonner sur des questions complexes et à se concentrer sur les informations les plus importantes.
• Systèmes agentiques : Collecte dynamique d'un contexte pertinent supplémentaire à partir des fichiers de code source afin de garantir que les gestionnaires d'apprentissage à distance disposent précisément des informations nécessaires.
  
  
• Ensembles LLM : Combinaison de plusieurs modèles LLM pour la vérification croisée des problèmes, la réduction des biais liés à un seul modèle et l'augmentation de la précision globale.

En intégrant ces approches, nos expériences ont déjà montré une réduction de près de 80 % des hallucinations, ce qui constitue une avancée significative pour rendre les examens de code alimentés par l'IA plus fiables, plus exploitables et plus dignes de confiance.

Dans la deuxième partie, nous verrons exactement comment nous avons construit notre système d'ensemble de chaînes de pensée, en présentant les stratégies concrètes qui nous ont permis d'obtenir ces résultats remarquables.