Éliminer les hallucinations dans les examens du code de l'IA II

Récapitulation : L'importance des hallucinations

Dans la première partie, nous avons étudié les raisons pour lesquelles les hallucinations représentent un tel défi lorsque l'on travaille avec de grands modèles de langage (LLM), que ce soit pour générer un nouveau code ou pour examiner un code existant afin d'y déceler des bogues potentiels. Nous avons passé des semaines à annoter et à analyser manuellement des centaines de problèmes générés par l'IA, en créant un cadre d'annotation axé sur l'actionnabilité :

• 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.

Cette évaluation rigoureuse nous a permis d'identifier plusieurs schémas récurrents dans les hallucinations :

• Souvent, les hallucinations se sont produites lorsque les MFR n'avaient pas de contexte crucial.
• Inversement, trop de contexte non pertinent pourrait submerger le LLM et entraîner des erreurs.
• Les erreurs varient d'un modèle à l'autre.

Ces résultats nous ont orientés vers le développement de systèmes agentiques plus intelligents, dotés d'un meilleur raisonnement, qui intègrent dynamiquement le bon contexte et utilisent plusieurs LLM en tant qu'ensemble pour des évaluations plus précises.

Règle n° 1 : commencer simplement

Chez Korbit, la première règle de construction avec les LLM est la suivante : Commencez toujours par la simplicité.

(En fait, la règle n° 1 consiste à définir correctement le problème - mais nous avons abordé ce point en détail dans la première partie, lorsque nous avons analysé et étiqueté des centaines de questions).

Au lieu de plonger prématurément dans des solutions complexes comme la collecte de contexte multi-sauts (par exemple, en sautant à travers les fichiers dans la base de code) ou les lensembles de LLM, nous avons décidé d'aborder d'abord le problème de l'hallucination avec une approche extrêmement simple : par l'ingénierie de l'invite. Notre objectif : construire un détecteur d'hallucination efficace en utilisant une invite LLM soigneusement construite.

L'approche initiale : Le LLM en tant que juge

Nous avons commencé par une stratégie simple connue sous le nom de méthode "LLM-as-a-judge", inspirée par une recherche académique récente (Zheng et al., 2023). Dans cette configuration, un LLM examine et évalue les résultats d'un autre LLM en temps réel, servant de gardien qui classifie les problèmes détectés.

Notre demande initiale (présentée dans le tableau suivant) a été conçue pour déterminer rapidement si un problème signalé par l'examinateur de code était une hallucination ou non :

Tableau 1. Première invite du programme LLM

Vous êtes un ingénieur logiciel senior travaillant avec une équipe d'ingénieurs logiciels.

Vous utilisez un grand modèle linguistique pour l'examen initial des fichiers dans les demandes d'extraction. 

Le modèle de langage étendu examine les fichiers de la demande d'extraction et tente d'y trouver des problèmes. Certains des problèmes trouvés par le modèle de langage étendu sont des hallucinations. 

Si le problème ne pose pas de réel problème dans le développement ou l'exécution du code, ou si le problème dépend fortement d'un contexte externe au fichier, le problème est considéré comme une hallucination.

Votre tâche consiste à examiner les questions trouvées par le grand modèle linguistique et à détecter les hallucinations.

Les informations suivantes vous seront fournies :

- Description de la question

- Exemple de code d'émission

- Fichier de code source

...

‍

Malheureusement, cette invite n'a pas répondu aux attentes. Lors des tests effectués avec le GPT-4, il n'a détecté que 19 % des hallucinations, soit à peine mieux que les devinettes aléatoires, tout en classant à tort 10 % des problèmes valables dans la catégorie des hallucinations. Il semble que le modèle ne comprenait pas la tâche ou le code source, ou qu'il ne se concentrait pas correctement sur le contexte fourni.

En réfléchissant à notre analyse précédente, nous avons identifié un problème central : trop de contexte. Le fait de fournir au LLM un fichier source complet l'a submergé, ce qui a rendu difficile un raisonnement ciblé.

Affiner l'incitation : L'incitation à la chaîne de pensée (CoT)

Pour remédier à ces lacunes, nous avons expérimenté une technique appelée " chaîne de pensée" (CoT ), une approche de raisonnement structuré dont l'efficacité a été démontrée dans diverses tâches de LLM. La CoT encourage les modèles à réfléchir explicitement aux étapes intermédiaires, améliorant ainsi leur raisonnement sur des entrées complexes et longues.

Nous avons adapté une variante simple de CoT, avec des questions-réponses, pour aider le modèle à se concentrer sur les informations nécessaires à l'évaluation d'un problème. La méthode comporte trois étapes :

1. Générer trois questions simples sur le problème signalé.
2. Répondez à ces questions en examinant l'extrait de code fourni et le fichier source correspondant.
3. Évaluer la question de manière explicite comme "question valable", "hallucination" ou "indéterminée".

De manière cruciale, nous avons permis au LLM de fournir la réponse "Indéterminé", signalant une faible confiance ou un contexte insuffisant. Il s'agit d'un élément clé pour éviter les classifications arbitraires et potentiellement incorrectes, permettant aux systèmes en aval de gérer efficacement les cas incertains.

La chaîne de pensée (CoT) améliore considérablement les résultats

Cette invite CoT affinée a permis d'améliorer considérablement nos résultats en matière de détection des hallucinations :

• Le GPT-4 identifie désormais correctement 45 % des hallucinations, soit plus du double de notre taux de détection initial.
  
  
• Le nombre de faux positifs a été réduit à seulement 9 % (c'est-à-dire que seulement 9 % des non-hallucinations ont été classées à tort comme "hallucinations"), ce qui a permis de réduire le nombre de questions valables écartées à tort.

Trois enseignements essentiels tirés de nos expériences en matière d'idées-forces

Nos expériences approfondies en la matière ont permis de dégager trois points essentiels :

1. Le raisonnement structuré est essentiel :
   Le fait de demander au LLM de générer explicitement ses propres questions intermédiaires et d'y répondre a permis d'améliorer considérablement les performances par rapport aux invites à une seule étape.
   
   
2. Évitez les étiquettes ambiguës :
   Les réponses binaires telles que "Vrai/Faux" ont semé la confusion. L'utilisation d'étiquettes explicites - "Question valable", "Hallucination" et "Indéterminé" - a aidé le LLM à fournir des évaluations plus claires et plus précises.
   
   
3. Accepter l'incertitude avec "Indéterminé" :
   Le fait de permettre au MLD d'indiquer l'incertitude a réduit de manière significative les erreurs forcées, ce qui a permis de passer plus facilement à un flux de travail agentique en vue d'une enquête contextuelle plus poussée.
   
   

Comment fonctionne le détecteur d'hallucinations (exemple d'exercice)

Voici l'invite de détection des hallucinations affinée à laquelle nous sommes parvenus après de nombreuses expérimentations :

Tableau 2. Invitation à la formation continue LLM

Vous êtes un ingénieur logiciel senior travaillant avec une équipe d'ingénieurs logiciels.

Vous utilisez un grand modèle linguistique pour l'examen initial des fichiers dans les demandes d'extraction.

Le modèle de langage étendu examine les fichiers de la demande d'extraction et tente d'y trouver des problèmes.

Les hallucinations font partie des problèmes détectés par le modèle de langage étendu.

Votre tâche consiste à examiner les questions trouvées par le grand modèle linguistique et à détecter les hallucinations.

Les informations suivantes vous seront fournies :

- Description de la question

- Exemple de code d'émission

- Fichier de code source

Vous devez d'abord lire la description du problème et l'extrait de code du problème pour générer trois questions simples qui vous aideront à évaluer le problème. Par exemple, si le problème mentionne que la fonction calculate_sum est définie deux fois, une question simple pourrait être "combien de définitions de la fonction calculate_sum existe-t-il dans le fichier de code source ?

Une fois que vous avez généré ces trois questions simples, examinez le fichier du code source pour trouver les réponses et notez-les. Puis, sur la base de vos réponses, déterminez s'il s'agit d'une hallucination.

Si vous n'êtes pas sûr d'une question ou si vous ne disposez pas d'un contexte suffisant pour l'évaluer, qualifiez cette question d'indéterminée. Pour le label indéterminé, veuillez fournir la raison pour laquelle vous pensez qu'il s'agit d'une question indéterminée.

Voici les informations qui vous aideront à déterminer si le problème est réel ou s'il s'agit d'une hallucination :

- Issue description: {feedback}

- Issue code snippet: {diff}

- Source code file: {source_code_file}

Structurer la sortie comme un json valide :

    "question_1" : "La première question que vous générez",

    "answer_1" : "Votre réponse à la question_1",

    "question_2" : "La deuxième question que vous générez",

    "answer_2" : "Votre réponse à la question_2",

    "question_3" : "La troisième question que vous générez",

    "answer_3" : "Votre réponse à la question_3",

    "évaluation" : " Question valable " ou " Hallucination " ou " Indéterminé ".

‍

La meilleure façon de comprendre le fonctionnement du système est de prendre un exemple.

Voici un exemple d'une question évaluée pour l'hallucination par l'invite :

‍

‍

Ce problème est clairement une hallucination selon notre définition. La méthode "outdate_pr_comments" est en effet déclarée deux fois dans la base de code, mais une fois en tant que méthode de la classe de base (qui est censée être implémentée plus tard) et une seconde fois dans la classe enfant (qui hérite de la classe de base et définit correctement l'implémentation). Il n'y a pas de problème à résoudre ici. Le développeur n'a aucune action à entreprendre, il s'agit donc d'une hallucination au sens de la définition ci-dessus.

‍

Examinons maintenant le résultat de Claude 3.5 Sonnet :

‍

Tableau 3. Claude 3.5 Sortie Sonnet

Voici mon évaluation du problème dans le format JSON structuré :

    "question_1" : "Combien de fois la méthode outdate_pr_comments est-elle définie dans la classe GithubRepositoryClient ?",

    "answer_1" : "La méthode outdate_pr_comments est définie une fois dans la classe GithubRepositoryClient",

    "question_2" : "La première définition de outdate_pr_comments est-elle une méthode vide ?",

    "answer_2" : "Non, il n'y a qu'une seule définition de outdate_pr_comments et elle n'est pas vide. Elle contient du code pour minimiser les commentaires en utilisant l'API GraphQL de GitHub.",

    "question_3" : "La méthode outdate_pr_comments existante posera-t-elle des problèmes d'override ?",

    "answer_3" : "Non, puisqu'il n'y a qu'une seule définition de outdate_pr_comments, il n'y aura pas de problème d'override",

    "évaluation" : "Hallucination"

‍

Claude détermine correctement qu'il s'agit d'une hallucination. Il dit que la fonction n'est définie qu'une seule fois dans cette classe (ce qui est également correct, puisque la deuxième définition se trouve dans la classe de base, qui est une classe différente), et il conclut que cela ne posera aucun problème.

‍

Dans la troisième partie de cette série, nous verrons comment nous avons construit notre système d'ensemble et comment il a pu tirer parti de l'extraction dynamique du contexte à travers les fichiers de la base de code pour détecter et supprimer près de 80 % de toutes les hallucinations. 

‍