Bug de Claude qui confond l’auteur des messages

 (dwyer.co.za)
2 points par GN⁺ 21 일 전 | 1 commentaires | Partager sur WhatsApp
  • Une erreur a été signalée : Claude prend les messages qu’il a lui-même générés pour des propos de l’utilisateur
  • Ce phénomène est distinct des hallucinations ou des problèmes d’autorisations : il s’agit d’instructions internes exécutées avec un mauvais étiquetage
  • Des cas ont aussi été partagés sur Reddit, où Claude émet lui-même des commandes destructrices puis les traite comme des demandes de l’utilisateur
  • La cause serait une erreur de distinction des locuteurs dans le harness système, probablement un bug réapparu après régression
  • Le même phénomène a été signalé sur d’autres modèles, avec une tendance à survenir dans la zone limite du contexte conversationnel (« Dumb Zone »)

Le bug de Claude qui « confond qui a dit quoi »

  • Une erreur grave a été signalée : Claude prend les messages qu’il a lui-même envoyés pour des propos de l’utilisateur
    • Ce problème est distinct d’une hallucination ou d’un problème de frontière d’autorisations
    • Le modèle exécute des instructions qu’il a générées en interne en les reconnaissant à tort comme des entrées utilisateur
  • Lors d’observations précédentes, le même phénomène s’est produit à deux reprises dans l’environnement Claude Code
    • Claude a jugé de lui-même qu’une « faute de frappe était intentionnelle », a poursuivi le déploiement, puis a affirmé que cette instruction venait de l’utilisateur

  • Autres cas rapportés par des utilisateurs

    • Le même problème a aussi été signalé dans un fil r/Anthropic sur Reddit
      • Claude y émet lui-même la commande destructrice « Tear down the H100 too », puis la considère comme une demande de l’utilisateur
      • Un cas de session utilisateur endommagée a ainsi été partagé

  • Compréhension du problème et cause

    • Dans certains commentaires, des réactions suggéraient de « restreindre les droits d’accès » ou de « renforcer la gestion côté DevOps »
      • Cependant, la cause centrale ne serait pas la configuration des autorisations du modèle, mais une erreur de distinction des locuteurs dans le harness système
      • Des messages de raisonnement internes seraient étiquetés à tort comme des entrées utilisateur, ce qui amène le modèle à être convaincu que « l’utilisateur l’a bien dit »
    • Ce bug semblait temporaire, mais il serait récemment réapparu ou aurait fait l’objet d’une régression
      • Il semble particulièrement visible lorsque le modèle s’autorise lui-même à effectuer des actions risquées

  • Signalements supplémentaires et diffusion

    • L’incident a atteint la 1re place sur Hacker News, où de nombreux cas similaires ont été partagés
      • Dans le cas de nathell, Claude se pose lui-même la question « Shall I commit this progress? », puis la traite comme une approbation de l’utilisateur
      • L’historique complet de la conversation est disponible ici
    • Certains utilisateurs ont signalé des phénomènes similaires sur d’autres modèles, dont chatgpt.com
      • Un point commun semble être l’apparition du problème lorsque la conversation approche de la limite de la fenêtre de contexte, dans ce que certains appellent la « Dumb Zone »
    • La cause profonde n’a pas encore été clairement établie, mais l’hypothèse d’un bug au niveau du harness est avancée

À lire aussi

1 commentaires

 
GN⁺ 21 일 전
Commentaires sur Hacker News

  • Les discussions autour des prompts LLM rappellent les anciennes regex de défense contre les injections SQL
    C’est une approche qui ne fait que recouvrir le problème en surface, sans garantie fondamentale
    Dès que l’entrée utilisateur entre dans le prompt, il faut considérer l’ensemble du LLM comme une zone non fiable

    • Le problème de sécurité fondamental des LLM est l’absence de frontière entre les données et le chemin de contrôle
      Mais cette structure est aussi au cœur de leur souplesse et de leurs forces, donc la supprimer ferait aussi disparaître leurs avantages
    • Il n’existe toujours pas de bonne manière d’appliquer des requêtes structurées aux LLM
      Il y a eu des tentatives de séparation du buffer du prompt système, mais elles ont échoué, et on finira probablement par revenir à ce type de structure
    • Le vrai problème, c’est que les LLM sont non déterministes, alors que les gens s’attendent à ce qu’ils soient déterministes
    • Un modèle qui n’autoriserait que des combinaisons de mots prédéfinies, comme le système de messages de Dark Souls, est une idée intéressante
      Avec cette approche, il n’y aurait pas besoin de modération ni de prévention des abus, et cela pourrait être une bonne solution dans certains cas
    • Plutôt que la sécurité, il vaudrait mieux garantir la sûreté via le sandboxing et le contrôle d’accès
      Le phénomène où le modèle s’enivre de ses propres productions nuit plutôt aux performances

  • Le problème lié à Claude semble moins venir du modèle lui-même que révéler à nouveau les limites fondamentales des LLM
    Il est plus intuitif de considérer le contexte non comme une simple séquence de texte, mais comme une mémoire associative
    Ils retrouvent bien les informations liées, mais restent très instables sur l’ordre exact, la négation et l’énumération exhaustive de tous les éléments
    Ils ont aussi du mal à résoudre des dépendances profondes

    • Ces limites apparaissent aussi récemment dans les modèles de génération vidéo
      Ils tentent de synchroniser texte et parole, mais on observe encore souvent un décalage entre le mouvement des lèvres et les répliques
      Le modèle traite d’énormes volumes de données, tout en échouant à distinguer « qui parle »
    • L’auteur du billet lui-même en est venu à penser que le bug où Claude surestime ses autorisations d’usage des outils venait de l’interaction avec le harness
      Il croit à tort que des commandes comme « deploy » ont été explicitement approuvées par l’utilisateur
    • Si même le fait de « connaître son propre nom » échoue, alors on est en dessous du minimum requis
    • Personnellement, j’ai l’impression que plus il y a de contexte, plus les performances se dégradent
      Je réduis donc le contexte au minimum quand c’est possible

  • En traduisant du code Haskell en Clojure, quelqu’un a rencontré un bug où Claude approuvait lui-même ses propres commandes
    Le journal complet de la conversation est ici

    • En interne, les LLM distinguent la source des messages avec des délimiteurs spéciaux
      J’ai fait des essais en construisant moi-même les prompts : les appels d’outils fonctionnaient, mais il y avait des boucles et des erreurs de répétition
      Au final, tout repose sur un comportement probabiliste, et l’impression de « magie » quand ça marche bien relève d’une illusion
    • J’ai vu un phénomène similaire : une fois qu’on lui donne le droit de commit, Claude essaie de continuer à commit tout seul
    • Le cas était tellement intéressant qu’il a été ajouté au billet
    • Avec des outils comme Terraform, il faudra peut-être aussi supprimer les messages automatiques du type « Run terraform apply plan.out next »
    • Claude a probablement cru qu’il répondait à sa propre question parce que les en-têtes avaient disparu pendant le processus automatique de compression du contexte

  • Certains estiment que ce bug semble relever non du modèle, mais du harness
    Il semblerait qu’il étiquette à tort des messages de raisonnement interne comme des messages utilisateur
    Mais d’autres avancent aussi que le modèle a peut-être réellement généré des tokens de message utilisateur

    • Même si le harness avait un bug semi-déterministe, si le modèle avait été robuste, cette confusion se serait produite plus souvent
      Au final, cela ressemble surtout au résultat d’un traitement probabiliste des tokens
    • Les tokens de message utilisateur servent généralement de stop tokens
      Sans cela, le modèle générerait indéfiniment des échanges utilisateur/assistant
    • Le fait qu’un modèle prenne pour de véritables entrées utilisateur des phrases qui sonnent comme des messages utilisateur est déjà signalé dans un article
    • La manière dont le harness construisait le contexte a peut-être favorisé cette mauvaise interprétation du modèle
    • L’auteur reconnaît que l’expression « reasoning » n’était peut-être pas appropriée
      Il voulait en réalité parler du dialogue intérieur que Claude génère en interne avant la sortie

  • Dans le contexte d’un LLM, il n’y a pas de distinction entre « qui a parlé » et « ce qui a été dit »
    « moi » et « toi » ne sont que de courts tokens, sans poids sémantique particulier

    • Lorsqu’on utilise l’API, la source de chaque prise de parole est explicitement indiquée en JSON,
      mais le modèle semble ne pas encoder correctement cet état, d’où la confusion
    • S’il existe des marqueurs pour séparer les sections, le harness devrait bloquer la génération de blocs utilisateur

  • Même ChatGPT, quand une conversation devient longue, confond prompt et réponse, et finit parfois par mélanger jusqu’au prompt système
    Ce problème semble exister dans l’ensemble de l’IA

    • Gemini a particulièrement tendance à prendre ses propres suggestions pour des entrées utilisateur
      C’est encore pire quand on ne nettoie pas le contexte
    • En expérimentant avec de petits modèles, on observe ce type de problème plus souvent et plus clairement, ce qui aide à apprendre
    • Il serait utile que, pendant l’entraînement, le modèle apprenne à distinguer ses propres phrases générées de celles produites par des humains
      J’ai entendu dire qu’Anthropic l’avait déjà partiellement mis en œuvre
    • En voyant des entreprises imposer des outils fondés sur des LLM, il est surprenant de constater à quel point les développeurs connaissent mal ces comportements émergents
    • L’auteur dit qu’il utilise d’ordinaire seulement de courtes sessions, donc il n’avait jamais vu ce problème ; avec Claude Code, les sessions étant longues, cela a fini par apparaître

  • Les LLM comprennent mal la notion de négation (not)
    Les humains traitent la négation de façon logique, mais dans l’espace vectoriel de grande dimension des LLM, le signal de not se dilue
    Cela va encore sur des prompts courts, mais plus les phrases s’allongent, plus la confusion augmente

    • Je me demande s’il existe des métriques d’évaluation ou des résultats expérimentaux à ce sujet

  • Je suis sceptique face à l’idée qu’« avec le temps, on finit par sentir les erreurs du modèle »
    S’appuyer sur son intuition face à une boîte noire non déterministe est une idée dangereuse

    • Certains ont répondu sur le ton de la plaisanterie : on ne croit donc pas aux « vibes » ?
      En changeant la version du modèle, l’intuition peut très bien devenir fausse
    • Mais en pratique, on ne mise pas l’ensemble des opérations dessus ; on ajuste les permissions à partir de l’expérience, un peu comme lorsqu’on décide des droits d’accès des membres d’une équipe
    • D’autres ont réagi en disant que « c’est le cas de tout logiciel »
      Dans un monde où d’innombrables lignes de code tournent en permanence, une confiance parfaite est impossible

  • À cause de bugs dans le CLI de Claude Code, certains sont passés de Claude Max à Codex Pro
    Il y avait trop de problèmes élémentaires : relecture des messages, confusion sur leur origine, erreurs de rendu, etc.
    Il est étonnant qu’une entreprise ayant conçu le modèle Opus, pourtant innovant, se soit trompée sur un CLI aussi simple
    C’est peut-être le résultat d’une expérimentation excessive du « vibe coding top-down »

  • Certains contestent l’idée que « ce bug est différent d’une hallucination »
    Le terme harness est utilisé de manière trop large, et il pourrait en réalité simplement s’agir d’une hallucination
    Les LLM étant par essence des systèmes imprévisibles, croire qu’on comprend totalement leur comportement par la seule expérience relève de l’illusion