Les hallucinations dans le code sont la forme la moins dangereuse des erreurs de LLM

• De nombreux développeurs perdent confiance après avoir subi des hallucinations en utilisant des LLM pour écrire du code
  • Il est courant qu’un LLM invente des méthodes ou des bibliothèques inexistantes
  • Mais, dans le code, les hallucinations sont le type d’hallucination le moins dangereux
• Le cas le plus dangereux est lorsque le LLM introduit des erreurs qui ne sont pas immédiatement détectées par le compilateur ou l’interpréteur
  • Une méthode hallucinée provoque une erreur dès l’exécution, ce qui la rend facile à repérer
  • On peut aussi corriger automatiquement le problème en renvoyant le message d’erreur au LLM
• Contrairement aux hallucinations dans le texte classique, le code permet une vérification factuelle par l’exécution
• Les LLM avec correction automatique des erreurs
  • Des outils comme ChatGPT Code Interpreter et Claude Code exécutent le code généré par le LLM, détectent les erreurs et les corrigent eux-mêmes
  • Évaluer du code écrit par un LLM sans même l’exécuter est inefficace
• Certains développeurs rejettent la technologie entière simplement parce que le LLM a généré des méthodes hallucinées
  • Mais pour l’utiliser efficacement, l’apprentissage et l’expérimentation sont indispensables
  • L’auteur étudie l’écriture de code assistée par l’IA depuis plus de deux ans, et continue encore à apprendre de nouvelles techniques
• Les tests manuels du code sont indispensables
  • Ce n’est pas parce que le code s’exécute correctement qu’il se comporte comme prévu
  • Ni la revue de code ni les tests automatisés ne suffisent à valider complètement l’exactitude du code
  • Il est indispensable de l’exécuter et de le vérifier soi-même
  • Le code généré par un LLM peut inspirer une fausse confiance parce qu’il est très lisible
  • Il en va de même pour le code écrit par des humains : il ne faut pas lui faire confiance avant de l’avoir exécuté soi-même
• Comment réduire les hallucinations
  • Utiliser un autre modèle : choisir un modèle disposant de davantage de données d’entraînement sur une plateforme donnée
    • Exemples : Claude 3.7 Sonnet (avec thinking mode activé), OpenAI o3-mini-high, GPT-4o (avec Python Code Interpreter)
  • Exploiter le contexte : même si le LLM ne connaît pas une bibliothèque donnée, il peut apprendre les motifs à partir d’exemples de code fournis
    • Cela s’est récemment révélé efficace avec la fonction d’intégration GitHub de Claude
  • Choisir des technologies stables : plus une bibliothèque est ancienne, plus il est probable que le LLM la maîtrise bien
    • S’appuyer sur la philosophie Boring Technology
• L’importance de la revue de code
  • L’auteur réfute l’argument selon lequel « si je dois relire tout le code écrit par un LLM, autant l’écrire moi-même, ce sera plus rapide »
  • Ce type de remarque peut aussi révéler un manque de compétence en revue de code
  • Relire du code généré par un LLM peut être une excellente occasion de progresser
• Bonus : le retour de Claude 3.7 Sonnet
  • L’auteur a demandé à Claude 3.7 Sonnet de relire un brouillon de billet de blog en mode « extended thinking mode »
  • Il lui a demandé de vérifier « si la logique de cet article est convaincante, quels points pourraient être améliorés et quels éléments manquent »
  • Claude a aidé à adoucir le ton du brouillon
  • Lien vers la conversation de feedback avec Claude

[GN⁺]

Discussion sur Hacker News

• L’auteur était d’accord avec le billet précédent, mais pas avec celui-ci

  • Il s’oppose à l’idée que « si je dois relire tout le code écrit par un LLM, il est plus rapide que je l’écrive moi-même »
  • Il n’est pas d’accord avec l’affirmation selon laquelle on n’investit pas assez dans la capacité à lire, comprendre et relire le code d’autrui
  • La relecture dépend de l’expertise et de la fiabilité de l’auteur, et relire une contribution anonyme est différent
  • Il est important d’inférer et de comparer l’intention et l’approche du code, et dans le cas d’un LLM, cette portée est limitée
  • La motivation est importante, et tous les développeurs n’aiment pas forcément faire de la revue de code
  • Le code d’un LLM n’a pas de dimension sociale, et les changements doivent être relus par quelqu’un d’autre

• Même si le code généré par un LLM fonctionne bien, si l’on n’en est pas l’auteur, il est difficile d’y déceler des bugs ou des défauts logiques

  • Si l’on considère le développement non comme l’implémentation d’un plan bien conçu mais comme l’assemblage de pièces, alors il y a de quoi s’inquiéter qu’un algorithme assemble ces pièces par simple conjecture
  • Un LLM ne prend pas les risques qu’un humain peut accepter, et il peut ne pas comprendre le sens d’un bloc de code dans un contexte donné

• Le code généré par un LLM est propre, mais fait passer plus de temps en QA et en travail de nettoyage

  • Ce n’est pas parce que le code fonctionne bien et ne contient pas d’erreurs qu’il fait la bonne chose
  • Exécuter et tester le code ne suffit pas à prouver sa justesse ; il faut raisonner logiquement

• The Primeagen et Casey Muratori examinent la sortie des derniers générateurs de code par LLM

  • Il faudrait leur donner des tâches bien représentées dans les données d’entraînement du LLM pour que le développement soit facile
  • En pratique, le développement itératif converge vers du code inutile, et le LLM cesse progressivement de faire des progrès

• Une autre catégorie d’erreur négligée par Simon est l’hallucination où le modèle oublie une fonctionnalité

  • Le côté négatif d’oublier des fonctionnalités clés est plus difficile à gérer que le côté positif d’un code qui compile
  • La fonctionnalité peut légèrement varier selon du code supposé se trouver en dehors de la fenêtre de conversation / de contexte

• Les méthodes hallucinées sont un petit obstacle, et lorsqu’on s’en plaint, on suppose que les gens ont passé un temps minimal à apprendre à utiliser efficacement le système

  • C’est une hypothèse très erronée, et les gens voient les hallucinations et se disent : « s’il n’arrive même pas à faire correctement les choses les plus simples de manière cohérente, on ne peut pas lui faire confiance pour des tâches plus difficiles »

• L’hallucination en elle-même n’est pas le plus grand risque posé par les LLM

  • Le risque plus grave est qu’un chatbot puisse convaincre des humains de se faire du mal
  • Des cas de ce type ont déjà eu lieu, et il ne souhaite pas partager d’idées sur ce qui pourrait être encore plus dangereux

• Ce n’est moins risqué que dans le contexte limité des erreurs de compilation

  • Il serait encore plus contrarié si, pour éviter l’effort de chercher une vraie solution, un programmeur inventait une bibliothèque entière
  • Si l’on considère l’hallucination comme un simple ralentissement, on sous-estime ce que les LLM devraient réellement accomplir

• Obtenir de bons résultats avec un LLM demande beaucoup d’efforts

  • Cela permet de percer le battage médiatique à jour
  • On peut se demander à quoi servent vraiment les LLM et ce qu’on est censé en attendre s’il faut des années d’apprentissage pour obtenir des résultats non fiables

• Expérience d’écriture de code pour trouver la clinique « principale » d’un patient dans un centre médical

  • Il fallait trouver le rendez-vous le plus récent en ne prenant en compte que les rendez-vous cliniques
  • S’il n’y avait pas de rendez-vous clinique, il fallait alors trouver le rendez-vous le plus récent, tous types confondus
  • Il a écrit le code en triant les données, mais ChatGPT a interprété le tri à l’envers pendant la documentation
  • C’est une erreur bien pire que « le code ne s’exécute pas »