De meilleurs modèles, de moins bons outils

 (lucumr.pocoo.org)
1 points par GN⁺ 6 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Dans l’outil edit de Pi, Claude Opus 4.8 et Sonnet 5 ont ajouté, à l’intérieur de edits[], des champs absents du schéma, ce qui a entraîné le rejet des appels ; on observe ainsi que les modèles les plus récents respectent moins bien certains schémas d’outils que les modèles précédents
  • Un appel d’outil consiste pour le modèle à générer du texte sous forme de marqueurs spéciaux et de JSON ; avec un échantillonnage sans contraintes, les conventions apprises peuvent prendre le pas sur le schéma
  • Dans les cas d’échec, oldText et newText étaient eux-mêmes corrects, mais des fausses clés comme requireUnique, oldText2, matchCase ou in_file étaient ajoutées ; le taux de reproduction variait selon l’historique de l’agent et la présence ou non de blocs de thinking
  • Claude Code est un harnais fermé, mais il effectue de nombreuses corrections permissives : nouvelle tentative après un appel invalide, alias de paramètres, correction de types, récupération Unicode, filtrage des clés inconnues, etc. ; il n’utilise pas le mode strict
  • Les appels d’outils strict d’Anthropic ont éliminé ce problème ; si, à mesure que les modèles deviennent plus performants, les schémas d’outils alternatifs deviennent désavantagés, les harnais auront besoin de garanties plus fortes, comme des contraintes grammaticales

Régression observée dans l’outil edit de Pi

  • En suivant une issue Pi, un problème a été découvert : les derniers modèles Claude ajoutent des champs inexistants dans le tableau edits[] lorsqu’ils appellent l’outil edit de Pi
  • Cela ne concerne pas un petit modèle, mais Opus 4.8 ; le même comportement a aussi été confirmé avec Sonnet 5
  • Le même problème n’apparaissait pas avec les modèles Anthropic précédents : les modèles récents à hautes performances se comportent donc moins bien avec ce schéma d’outil précis
  • Fable n’a pas été testé, car le classificateur pourrait abaisser silencieusement la requête vers Opus

Les appels d’outils ressemblent à de la génération de texte

  • Les appels d’outils par les LLM fonctionnent en donnant au modèle l’historique de conversation, le prompt système et la liste des outils disponibles, puis en lui faisant générer un format d’appel dans un grand prompt contenant des marqueurs spéciaux
  • Pour un outil d’édition de fichiers, les arguments attendus peuvent inclure path et un tableau edits, comme ceci
{
  "path": "some/file.py",
  "edits": [
    {
      "oldText": "text to replace",
      "newText": "replacement text"
    }
  ]
}
  • Le harnais valide les arguments, effectue la modification, puis réinjecte le résultat dans le modèle ; en cas d’échec de validation, le modèle voit l’erreur et réessaie généralement
  • Le format interne des modèles Anthropic n’est pas public, mais des marqueurs ANTML ont déjà fuité ou sont apparus dans des communications publiques
  • Ce format ressemble à du XML, mais il s’agit moins de véritable XML que de signaux in-band pratiques pour la tokenisation et l’apprentissage
    • Les paramètres chaîne de caractères de premier niveau peuvent être inclus en ligne
    • Les tableaux d’objets semblent être insérés sous forme sérialisée en JSON

Génération sans contraintes et génération à contraintes grammaticales

  • Il existe globalement deux façons pour un modèle de produire une sortie structurée
    • Demander au modèle de générer du JSON conforme au schéma, puis valider a posteriori
    • Empêcher dès le départ le sampler d’échantillonner du JSON invalide ou une forme non conforme au schéma
  • La deuxième approche est appelée décodage sensible à la grammaire ou décodage contraint ; elle masque les tokens qui violeraient la grammaire
  • Si le schéma n’autorise que oldText et newText, le sampler peut empêcher la génération de clés comme "in_file" ou "type"
  • Sans ce type de contrainte, le modèle génère selon les conventions apprises plutôt qu’en respectant strictement le contrat abstrait

Schémas d’échec réels

  • L’outil edit de Pi utilise un tableau edits, car il prend en charge plusieurs remplacements de chaînes exactes en un seul appel
  • Dans les appels en échec, des champs non autorisés étaient ajoutés comme ci-dessous
{
  "oldText": "...",
  "newText": "...",
  "requireUnique": true
}

{
  "oldText": "...",
  "newText": "...",
  "oldText2": "",
  "newText2": ""
}
  • Les fausses clés observées lors d’expériences répétées étaient variées : type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2, event.0.additionalProperties, etc.
  • Dans les appels invalides confirmés, les payloads oldText et newText étaient corrects au byte près, mais des clés absurdes étaient ajoutées à la fin de l’objet, ce qui entraînait le rejet de l’appel
  • La reproduction dépend fortement du contexte
    • Elle ne se reproduit pas avec un nouveau prompt à un seul tour du type « edit this file »
    • Elle se reproduit avec un historique d’agent dans lequel le modèle a lu le fichier, diagnostiqué le problème puis composé une modification multi-lignes
    • Il fallait disposer de la transcription de Petr Baudis pour la reproduire
    • En poursuivant la session utilisateur concernée, Opus 4.8 échoue avec une probabilité d’environ 20 %
    • Retirer les blocs de thinking de l’historique divise le taux d’échec par deux
    • Activer les appels d’outils strict fait disparaître le problème dans cette exécution

Pourquoi c’est devenu pire

  • L’hypothèse la plus forte est qu’il ne s’agit pas d’une dégradation aléatoire des performances, mais d’un produit de l’apprentissage
  • Les anciens modèles Anthropic ont été entraînés avec certains outils, mais avant que les harnais fournis par les utilisateurs comme Claude Code ne deviennent un objectif clairement établi
  • Les modèles Anthropic récents ont très probablement reçu un post-entraînement incluant Claude Code ou un harnais très similaire ; dans cet environnement, ils ont pu apprendre à la fois des appels d’outils réussis et des erreurs tolérées
  • L’outil edit de Claude Code n’a pas la structure imbriquée edits[] de Pi, mais une structure plate proche de file_path, old_string, new_string et d’un éventuel replace_all
  • Le client Claude Code corrige un nombre important d’erreurs : nouvelle tentative en cas de mauvais usage d’un outil, alias de paramètres, coercition de types, récupération Unicode, filtrage des clés inconnues, etc.
  • Si l’apprentissage par renforcement se déroule dans ce harnais ou dans une simulation de celui-ci, même des appels d’outils légèrement incorrects peuvent accomplir la tâche et obtenir une récompense
  • Quand un autre harnais fournit un outil d’édition de même sens avec un schéma différent, il peut devenir de plus en plus hors distribution du point de vue du modèle
  • À la sortie d’Opus 4.5, celui-ci s’adaptait très bien aux autres outils edit, mais la tendance observée aujourd’hui montre que les schémas d’outils alternatifs peuvent être désavantagés dans un écosystème d’outils particulièrement permissif
  • Il existe un text editor tool documenté, mais Claude Code ne suit pas ce format tel quel, et le fonctionnement interne de Claude Code n’est pas visible puisqu’il s’agit d’un harnais closed source

Le harnais permissif de Claude Code

  • Claude Code est closed source, mais l’examen de code réduit montre qu’il est très tolérant envers les données entrantes
  • Il vérifie si du balisage <invoke a fuité dans le texte visible du modèle et, le cas échéant, émet de la télémétrie avant de réessayer l’appel invalide avec sa propre machine à états
  • Il inclut une récupération des échappements Unicode qui répare les séquences \uXXXX cassées et les lone surrogates dans les valeurs de chaîne
  • Il existe aussi des alias de paramètres propres à chaque outil
    • Edit accepte old_str, old_string, new_str, new_string
    • path est accepté comme alias de file_path
  • Les clés inattendues sont filtrées silencieusement
  • Le mode strict n’est pas utilisé
    • Anthropic applique en mode strict des limites de complexité aux définitions d’outils, ce qui peut faire échouer une requête API
    • C’est probablement la raison pour laquelle Claude Code ne tente pas d’utiliser le mode strict

Mode strict et autres écosystèmes

  • Les modèles et les harnais d’Anthropic sont tous fermés, ce qui rend difficile de savoir si le même problème se produira dans d’autres harnais
  • Les modèles Codex sont eux aussi fermés, mais leur harnais ne l’est pas
  • gpt-oss a été entraîné explicitement pour utiliser le format de réponse harmony d’OpenAI, et de nombreux documents montrent la façon de penser d’OpenAI
  • harmony fait des canaux et des types de contenu d’appel d’outil une partie du format de prompt, et peut inclure des marqueurs comme <|constrain|>json dans le corps de l’appel d’outil
<|start|>assistant<|channel|>commentary to=functions.get_weather
<|constrain|>json<|message|>{"location":"San Francisco"}<|call|>
  • <|constrain|>json permet à la pile d’inférence d’identifier facilement la frontière à partir de laquelle elle doit basculer vers un échantillonnage JSON contraint dans le corps de l’appel d’outil
  • Pour les modèles GPT hébergés, il existe aussi une option permettant de fournir une grammaire LARK pour la grammaire que les outils utilisateur doivent respecter
  • Anthropic semble faire quelque chose de similaire en mode strict, mais avec des paramètres en tableaux imbriqués, le modèle doit générer du JSON contenant de longs contenus de fichiers multi-lignes échappés dans des littéraux de chaîne
  • Les fausses clés apparaissent juste après la fermeture d’une chaîne newText longue de plusieurs centaines de tokens, à un point de forte entropie où le modèle doit choisir entre } et , "..."
  • Opus 4.8 et Sonnet 5 semblent avoir une distribution a priori plus forte sur la forme des appels à l’outil edit, et cette distribution est plus proche du schéma edit plat de Claude Code
  • Le fait que le mode strict d’Anthropic corrige le problème peut s’expliquer par le rejet, côté serveur, de l’échantillonnage de clés non autorisées par la structure du schéma JSON
  • Les modèles Codex testés n’ont pas montré ce type de régression ; la version 5.6, inaccessible, est exclue

Effets sur la conception des harnais

  • Avec les modèles Anthropic, un schéma d’outil n’est pas forcément un contrat abstrait neutre
  • Certaines formes d’outils sont proches de ce qui a été vu pendant le post-entraînement, d’autres en sont éloignées
  • Certaines formes peuvent être faciles dans l’encodage caché du fournisseur, tandis que d’autres fonctionnent difficilement parce qu’elles imposent d’écrire un gros objet JSON échappé dans un tableau imbriqué après de longues chaînes multi-lignes
  • Même si le modèle comprend le schéma, il peut échouer à échantillonner la structure exacte en situation de pression
  • Chez Anthropic, activer l’échantillonnage strict peut faire disparaître ce problème
  • Toutefois, le comportement des modèles récents montre l’impact de l’apprentissage par renforcement sur les modèles, et aller à l’encontre des distributions a priori d’un harnais particulier peut nuire aux meilleures performances possibles
  • Claude Code n’est pas open source et on ne sait pas ce qu’il fait dans l’environnement de RL ; il est donc difficile de supposer que les comportements appris pour Claude Code se transféreront proprement à d’autres outils
  • Plus le post-entraînement se fait à l’intérieur d’un harnais dominant, plus les autres harnais doivent hériter des particularités étranges de ce harnais
  • Le décodage contraint peut impliquer des compromis de qualité, mais si les modèles récents résolvent mieux les tâches tout en devenant moins capables d’émettre fidèlement des schémas d’outils alternatifs, une garantie plus forte devient nécessaire quelque part dans le harnais

À lire aussi

1 commentaires

 
GN⁺ 6 시간 전
Avis sur Lobste.rs

  • Si Fable vous intéresse, je crois comprendre que Fable indique désormais toujours explicitement quand il procède à une rétrogradation.
    Je me suis moi-même fait prendre par le classificateur ; apparemment, « trie les bugs par ordre de gravité » sonnait comme de la recherche en sécurité.

    • Je compte faire quelques tests.
      Je sais qu’ils ont dit qu’ils ne le feraient pas en douce, mais je n’ai pas encore vérifié le mécanisme utilisé pour la rétrogradation.

  • Si cette hypothèse est juste, les conséquences pourraient dépasser les agents de codage.
    Toute application qui dépend d’appels d’outils fiables pourrait subir une dégradation similaire des performances une fois le modèle post-entraîné pour l’environnement d’exécution privilégié d’un fournisseur donné.

  • Pour info, j’ai publié cet article avec le tag ai, pas vibecoding.
    J’ai vraiment du mal à comprendre où se situent les limites de vibecoding sur ce site.
    Cet article concerne bien davantage les LLM de base, l’apprentissage par renforcement et la construction de l’environnement d’exécution qui les entoure.
    Si même ça relève de vibecoding, je ne vois pas bien à quoi sert encore le tag ai.

    • Ici, vibecoding est devenu une énorme lettre écarlate apposée sur tout ce qui touche, ou semble toucher de près ou de loin, à l’IA générative.
      Ces dernières semaines, des billets de blog à l’ambiance vaguement suggestive, des README de grands projets interdisant les contributions de LLM, et même des articles remplis de phrases du type « pas X, mais Y » se sont tous retrouvés tagués vibecoding.
      Personnellement, j’ai complètement renoncé à prêter attention à ce tag, parce que la communauté l’applique de façon tellement réflexe qu’il a perdu toute signification réelle.
      Cela dit, cet article précis porte effectivement, pour ainsi dire, sur des modèles utilisés à cet effet, donc je suis d’accord pour qu’il ait le tag vibecoding.
      En même temps, pour exactement les raisons évoquées, je suis aussi d’accord pour dire que ai ne devrait pas être supprimé. J’aimerais le rajouter, mais pour une raison que j’ignore, l’option n’est pas disponible sur cet article.

  • Rien de surprenant. Le verrouillage fournisseur fait probablement partie du plan.

    • Il y a sans doute aussi une part de réduction des coûts. Si tout le monde utilise Claude Code, le prompt caching s’améliore.
      Dire « si vous payez déjà un abonnement Claude et nous envoyez déjà tout votre code, vous devez aussi absolument utiliser notre UI gratuite, qui n’est peut-être pas un moyen de verrouillage suffisamment fort indépendamment du modèle » ne correspond pas tout à fait à la manière dont le verrouillage fournisseur fonctionne habituellement à l’état pur.

  • Il est logique qu’un modèle fonctionne au mieux dans l’environnement d’exécution sur lequel il a été entraîné, c’est-à-dire celui créé par ses développeurs.
    S’il a subi énormément d’apprentissage par renforcement sur des traces comme celles de Claude Code, je m’attendrais à ce qu’il devienne nettement moins bon dans des environnements d’exécution qui ne se comportent pas comme Claude Code.
    Personnellement, je suis plutôt surpris qu’il semble encore assez bien fonctionner dans des environnements d’exécution tiers comme Pi.
    Le fait que le bug n’apparaisse que très profondément dans les traces d’agent paraît aussi plausible.
    Plus tôt cette année, avec les modèles GPT 5.2 et 5.3, je me suis battu contre un bug où, vers la fin d’une trace, l’agent produisait ls -ლა au lieu de ls -la.
    Je l’ai brièvement consigné ici : https://github.com/openai/codex/issues/7988
    D’après mon expérience, cela ne se produisait là aussi qu’après un enfoncement important dans la trace.
    Dans les longs contextes, le modèle semble clairement ne plus « réfléchir » et revenir à des instincts primitifs.
    C’est probablement à ce moment-là que l’écart entre la distribution d’entraînement du modèle et l’environnement d’exécution, ou les tâches que l’utilisateur impose au modèle, affecte le plus spectaculairement les performances.

    • Le problème n’est pas qu’ils fassent de l’apprentissage par renforcement pour qu’il fonctionne mieux dans leur propre environnement d’exécution.
      Le problème, c’est qu’ils en font tellement qu’il régresse dans d’autres environnements d’exécution par rapport aux versions précédentes.
      À ce stade, il faut commencer à se demander : « est-ce que d’autres formes de surapprentissage ne sont pas aussi en train d’apparaître ? »