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é :
Cette évaluation rigoureuse nous a permis d'identifier plusieurs schémas récurrents dans les hallucinations :
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.
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.
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é.
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 :
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.
Cette invite CoT affinée a permis d'améliorer considérablement nos résultats en matière de détection des hallucinations :
Nos expériences approfondies en la matière ont permis de dégager trois points essentiels :
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.