Le modèle Claude d'Anthropic fait face à des défis techniques en matière de génération de code et de fiabilité des agents

Anthropic fait face à de multiples défis techniques concernant ses modèles Claude. La génération de code souffre d'une réduction de la liberté due à des contraintes d'insertion de filigranes ; le mécanisme de pensée adaptative de Sonnet 5 permet à un même modèle d'ajuster différents niveaux d'investissement computationnel, brouillant les frontières des capacités de la gamme de produits ; bien que le contexte de 1M semble suffisant, lors de conversations longues avec un Agent, le modèle n'utilise efficacement qu'environ 20 à 30 % du contexte, après quoi il entre en état de confusion et oublie des éléments ; lors de la compression du contexte, il est difficile de distinguer quelles informations restent valides, et les hypothèses temporaires peuvent être erronément transformées en faits ; après que l'Agent modifie activement l'environnement, le modèle commence à analyser les nouvelles erreurs qu'il a créées plutôt que le problème initial. L'article souligne que la fiabilité des Agents longs dépend de plus en plus de la clarté de l'état, de la vérifiabilité des actions et de la capacité à revenir en arrière en cas d'erreur, plutôt que de la simple performance en une seule étape du modèle.

Auteur et source de l'article : Leifengwang

Ce qui est plus problématique que la baisse des performances du modèle, c’est que le modèle soit encore en cours d’amélioration, tandis que les utilisateurs commencent à le trouver de moins en moins efficace.

Anthropic a récemment eu un peu ce goût-là.

Ces derniers jours, un post sur X a regroupé plusieurs mécontentements typiques de Claude ces derniers temps : des balises lisibles par machine commencent à être ajoutées aux textes et au code, l'expérience réelle de Sonnet 5 ne suit pas la hype des mises à jour du modèle, Fable 5 est vendu plus cher, mais il est difficile de percevoir clairement en quoi il est supérieur à Opus 5 ; un autre retour plus percutant indique que le contexte de Fable 5 n'est utilisé qu'à environ 20 %–30 %, après quoi ses performances commencent à chuter.

Ces quatre éléments semblent sans lien apparent : l’un ressemble à un problème de mécanisme de génération, l’autre à un problème de capacité du modèle, le troisième à un problème de tarification, et le quatrième semble tout simplement provenir d’un dysfonctionnement du contexte long.

Mais vu le stack technologique actuel de Claude, elles sont bloquées à cinq endroits très précis : comment le modèle génère les sorties, combien de calculs il est disposé à consacrer lors de l'inférence, pourquoi les modèles deviennent de plus en plus difficiles à hiérarchiser, pourquoi le contexte long commence à échouer avant d'être pleinement utilisé, et pourquoi les capacités observées dans les expériences sont souvent réduites lorsqu'elles sont appliquées à des tâches d'agent réelles.

Ainsi, le problème récent d'Anthropic n'est peut-être pas simplement une « dégradation du modèle ». C'est plutôt que, plus Claude devient puissant, la génération, le calcul, le contexte et l'exécution des agents commencent à se ralentir mutuellement.

01

Les balises lisibles par machine sont intégrées dans le texte normal ; la difficulté technique réside dans le fait de conserver des signaux stables tout en minimisant l'impact sur la qualité de génération. Dans le code, ce problème devient nettement plus complexe, car la distribution des jetons dans le langage naturel et dans le code n'est pas la même.

Article : https://arxiv.org/pdf/2301.10226

Le langage naturel présente souvent plusieurs candidats sémantiquement proches. Un même sens peut être exprimé avec des mots différents ou un ordre modifié, ce qui laisse au modèle une certaine redondance de génération à de nombreux endroits. Une approche courante du watermarking de texte consiste à exploiter cette redondance en modifiant légèrement les probabilités d'échantillonnage entre plusieurs tokens acceptables, afin d'accumuler des régularités statistiques sur une longueur suffisante.

Le code contient de nombreux emplacements à faible entropie. Après la déclaration d'une variable, les références ultérieures ne peuvent presque utiliser qu'un seul et même nom ; les champs JSON, les guillemets et les parenthèses sont soumis à des contraintes structurelles strictes ; les paramètres de fonction doivent respecter l'interface ; dans les chemins, expressions régulières, SQL et commandes Shell, un seul changement de token peut modifier directement le comportement.

Du point de vue de la distribution de probabilité, ces positions sont souvent très pointues. Le token correct occupe une probabilité élevée, tandis que les autres candidats ne sont pas simplement une autre expression, mais peuvent être erronés. Ainsi, la limitation fondamentale rencontrée par le watermarquage de code est en réalité sa capacité de codage.

Si une position ne permet qu'une seule sortie raisonnable, elle offre peu de place pour intégrer des signaux supplémentaires ; si le système n'incorpore des marqueurs que dans des positions à haute entropie, il rencontre des problèmes de code court, de proportion élevée de tokens structurés et de positions insuffisantes exploitables.

Il existe donc un compromis direct entre la détectabilité, la qualité de génération et la résistance à la modification : un signal trop faible est difficile à détecter, des contraintes trop fortes peuvent nuire à la génération correcte, tandis que conserver la capacité de détection après une mise en forme ou une réécriture locale nécessite une plus grande redondance du signal.

Anthropic n'a pas rendu public comment les balises de texte de Claude modifient l'échantillonnage, donc on ne peut pas attribuer directement les variations de qualité de Claude Code à un algorithme de marquage spécifique.

Ce qui est certain, c’est une autre évolution : la génération de code assume de plus en plus de contraintes. En plus de la correction sémantique et de l’exécution, il peut devoir respecter des protocoles d’outils, des formats structurés, des règles de sécurité et des balises d’origine, alors que le code lui-même a bien moins de liberté pour intégrer ces contraintes supplémentaires que le langage naturel.

02

Les changements apportés par la pensée adaptative de Sonnet 5 ne se limitent pas à faire réfléchir le modèle un peu plus longtemps.

Avant, il était facile de comprendre Sonnet, Opus et Fable comme quelques points de capacité fixes. Maintenant, avec l'ajout de effort, le même modèle peut se situer dans différents intervalles de calcul au moment de l'inférence ; le modèle lui-même ne représente plus pleinement la quantité de capacité réellement déployée pour une requête.

Lien de référence : https://platform.claude.com/docs/en/build-with-claude/effort

Ce changement est particulièrement visible dans l'Agent de codage. Lorsqu'il confronté à un bug, Claude doit non seulement générer une solution de modification, mais aussi décider quels fichiers lire, quelle chaîne d'appels suivre, combien d'hypothèses candidates conserver, s'exécuter des tests, continuer à vérifier les dépendances, et quand considérer que les preuves sont suffisantes.

Ces actions peuvent être considérées comme un arbre de recherche. Un investissement calculatoire plus faible signifie couper plus tôt les branches et formuler plus rapidement un jugement ; un investissement plus élevé permet au modèle de continuer à rechercher et à valider, réduisant ainsi la probabilité d'effectuer une action directement en l'absence de preuves suffisantes.

Lien de référence : https://platform.claude.com/docs/en/build-with-claude/effort

Therefore effort does not regulate mere thinking length, but rather the extent of the search space allowed for an Agent task. This directly alters Anthropic’s model hierarchy.

If a regular coding task is already easy for Opus, increasing effort will likely allow Opus to quickly enter the performance plateau. Even with a stronger base model, Fable has little remaining difficulty to convert into a noticeable experience gap.

L'utilisateur doit payer la différence de prix entre les modèles dès le début de la demande. Ainsi, ce qui rend Fable plus susceptible de démontrer sa valeur, ce ne sont pas les interprétations de code habituelles, les refacturations à petite échelle ou le débogage courant, mais plutôt les bibliothèques de code inconnues, la planification en plusieurs étapes, les opérations à travers plusieurs outils, l'exécution autonome prolongée, ainsi que les tâches nécessitant une récupération après une erreur.

Lien de référence : https://www.anthropic.com/news/claude-opus-5

Cela signifie que ce que les modèles avancés vendent est en train de changer. Ils ne vendent plus seulement « la réponse la plus forte de cette boucle », mais une fiabilité supplémentaire dans un trajet plus complexe.

Le problème est que cet avantage ne se manifeste que si la tâche est suffisamment longue ; une fois la tâche prolongée, les capacités du modèle ne sont plus le seul facteur déterminant, et l'état du contexte commence à occuper une place centrale.

03

Voir un contexte de 1M peut facilement le faire interpréter comme une grande mémoire de travail, donc il semble très contre-intuitif que Claude commence à omettre, répéter ou entrer en état de confusion après avoir utilisé seulement 200K ou 300K tokens.

Mais la fenêtre de contexte mesure la capacité, pas la cohérence d'état. Une session d'agent longue n'est pas un document statique, mais un historique d'exécution en constante augmentation.

Lien de référence : https://platform.claude.com/docs/en/build-with-claude/context-windows

Un fichier peut être modifié plusieurs fois ; un bogue a d'abord été identifié comme un problème de cache, puis découvert comme provenant de la concurrence ; un test peut d'abord échouer, puis réussir, puis échouer à nouveau à cause d'une nouvelle modification. Le contenu ancien n'est pas automatiquement supprimé lorsqu'il change d'état ; le nouveau contenu est simplement ajouté en continu à la suite.

Le problème ici ne se limite plus à la récupération. Le modèle doit non seulement trouver des informations pertinentes par rapport à la tâche en cours, mais aussi déterminer si ces informations sont toujours valables.

Les anciennes fonctions et les nouvelles fonctions sont très similaires, et les anciens journaux de test ainsi que les nouveaux journaux de test contiennent de nombreux mêmes tokens ; les analyses déjà réfutées peuvent également être hautement pertinentes sur le plan sémantique par rapport au problème actuel. Trouver ces contenus n'est pas difficile pour l'Attention, la difficulté réside dans la détermination de leurs relations de couverture.

Les bases de données peuvent maintenir l'état actuel grâce à des numéros de version, des horodatages de mise à jour, des transactions et des champs explicites ; le contexte en langage naturel ne possède généralement pas cette structure. Il ressemble davantage à un journal en mode ajout uniquement, et le modèle doit lui-même déduire l'état actuel du monde à partir de l'ordre des événements.

Lien de référence : https://platform.claude.com/docs/en/build-with-claude/context-windows

Ainsi, la complexité des longs contextes ne correspond pas simplement au pourcentage de tokens occupés. Un document statique de 250K tokens peut être beaucoup plus facile à traiter qu'une historique d'Agent de 250K tokens, car ce dernier contient de nombreux objets modifiés, des jugements intermédiaires, des résultats d'outils et des états déjà obsolètes.

L'historique des pensées augmentera encore cette complexité. La session ne conserve pas seulement « ce qui s'est produit », mais peut également inclure « pourquoi cette décision a été prise à ce moment-là ». Si un raisonnement initial repose sur une hypothèse ultérieurement réfutée, ce raisonnement peut tout de même continuer à participer aux jugements suivants en raison de sa forte pertinence par rapport à la question actuelle.

Ainsi, la véritable limite d'un contexte de 1M ne réside pas seulement dans la quantité d'informations qu'il peut contenir, mais dans la capacité du modèle à rester stable et à récupérer la version actuelle lorsque de plus en plus de versions historiques du même objet apparaissent.

04

Au fur et à mesure que le contexte continue de croître, la compaction semble être une solution naturelle : raccourcir l'historique ancien et continuer l'exécution. Toutefois, la compaction dans les scénarios d'agent n'est pas la même chose qu'un résumé classique.

Lors de la résumé d'un article, omettre un exemple n'affecte généralement que l'intégrité des informations ; en revanche, lors de la compression de la trajectoire d'un agent, omettre une contrainte encore valide peut modifier directement le chemin d'exécution suivant.

Lien de référence : https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

Parce que la compaction ne doit pas déterminer « quels contenus sont importants », mais « quels contenus sont encore valables maintenant ». Un historique peut contenir simultanément des tâches terminées, des jugements ultérieurement annulés, des contraintes d'interface encore en vigueur, des résultats de tests expirés et des correctifs temporaires. Le compactor doit réorganiser ces états temporels en une représentation permettant de poursuivre le travail lors du prochain cycle.

Si « on soupçonne actuellement que le problème provient du cache » est réduit à « le problème provient du cache », une hypothèse temporaire devient un fait ; si une solution déjà abandonnée est toujours incluse dans le résumé, les agents suivants pourraient réexécuter l'ancien chemin ; si une contrainte cruciale n'est pas incluse dans le résumé, le modèle ne la verra même plus par la suite.

Ainsi, l'indicateur clé de la compaction n'est pas le taux de compression, mais la fidélité d'état. C'est aussi la raison pour laquelle Git, les tests, les fichiers de tâches, la mémoire et les handoffs structurés deviennent de plus en plus importants dans les agents à long terme.

Ils ne se contentent pas d’augmenter les informations auxquelles le modèle a accès, mais transforment certains états nécessitant une validité à long terme, en les déplaçant depuis l’historique en langage naturel vers des systèmes externes. Git identifie la version actuelle du code, les tests fournissent des résultats vérifiables, les fichiers de tâches enregistrent l’état d’avancement, et l’état structuré distingue les conclusions actuelles des tentatives antérieures.

Le contexte peut conserver un historique riche, mais ne peut pas assumer à long terme la totalité de la gestion d'état.

Lien de référence : https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

Les questions précédentes peuvent toujours être comprises comme la manière dont le modèle traite les entrées. L'agent va plus loin, car il modifie activement l'environnement.

Dans un chat normal, une erreur du modèle reste généralement dans le texte de sortie. L'agent peut modifier le code, exécuter des commandes, installer des dépendances, ajuster les configurations, puis lire les nouveaux résultats générés par ces actions.

Ainsi, l'erreur ne se limite plus à une mauvaise interprétation, mais devient un changement d'environnement. Supposons que Claude ait mal identifié un bogue comme un problème de cache, modifiant ainsi la logique de cache, le mécanisme de nouvelle tentative et plusieurs points d'appel. Des anomalies nouvelles apparaissent ensuite lors des tests.

Ces anomalies sont réelles, mais elles ne proviennent pas naturellement du bogue initial ; elles ont été créées par les modifications de la précédente itération. Cela amène l’Agent dans un mode d’échec très particulier : le modèle commence à analyser la distribution de données qu’il a lui-même créée.

Lien de référence : https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

S'il peut identifier que « ces nouvelles erreurs sont apparues après la dernière modification », il peut effectuer un retour arrière et réexaminer l'hypothèse initiale ; sans établir ce lien de causalité, on risque de continuer à traiter les nouvelles erreurs comme des problèmes indépendants, en les corrigeant un par un.

À ce stade, chaque opération locale peut être justifiée, mais l'ensemble du trajet de la tâche s'est éloigné du problème initial. Ainsi, la fiabilité des longs agents ne peut pas être évaluée uniquement sur la base du taux de précision par étape. Ce qui est plus crucial, c'est que le système soit capable de détecter, d'attribuer et de récupérer après l'entrée d'une erreur dans l'environnement.

Git diff peut indiquer au modèle quelles modifications viennent d'être apportées, les tests peuvent vérifier si un comportement a été altéré, les points de contrôle et les rollback peuvent limiter la propagation des erreurs, et un évaluateur indépendant peut fournir une vérification supplémentaire en dehors de l'explication du modèle lui-même.

Le rôle de ces composants est essentiellement d'ajouter une capacité de correction en boucle fermée à l'Agent.

Lien de référence : https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

Beaucoup de benchmarks mesurent : le modèle, avec un environnement initialisé, peut-il accomplir la tâche ? Les agents réels ajoutent une couche de difficulté supplémentaire : l’environnement change constamment en fonction des actions du modèle lui-même. Ainsi, deux modèles ayant des taux de réussite finaux similaires peuvent offrir des expériences totalement différentes.

Un modèle peut être très précis au début, mais une fois qu'il fait une erreur, il continue de corriger le long de la mauvaise voie ; un autre modèle n'est pas nécessairement nettement plus fort à chaque étape, mais il parvient plus rapidement à détecter qu'une modification a créé un nouveau problème, puis effectue un retour en arrière et choisit une autre voie.

Il est difficile de distinguer ces deux comportements en ne regardant que la fin. Si la tâche de l'agent s'allonge, les indicateurs les plus pertinents deviendront : la quantité d'états clés conservés après compaction, la capacité à identifier les étapes ayant introduit une erreur après une modification erronée, la cohérence continue entre l'état interne de la tâche et l'environnement réel à mesure que les appels d'outils augmentent, ainsi que le coût nécessaire pour revenir sur la bonne voie après un écart.

Ces indicateurs ne mesurent pas la pertinence d'une seule réponse, mais la capacité d'une trajectoire à rester contrôlable.

En résumé, les plusieurs types de problèmes récemment révélés par Anthropic se situent à différents niveaux. Une fois regroupés, ces problèmes commencent à modifier les limites technologiques de Claude.

Avant, il s'agissait plutôt de demander si le modèle pouvait résoudre une question particulière ; aujourd'hui, le défi plus difficile est un autre : après plusieurs heures d'exécution de la tâche, des dizaines d'appels d'outils, plusieurs compressions d'état et de multiples modifications de code, le système peut-il encore maintenir une version fiable du monde actuel ?

Les capacités du modèle continuent de croître, ne pouvant qu'élever la limite de chaque jugement. La capacité d'un long Agent à fonctionner de manière stable dépend de plus en plus d'une autre série de compétences : l'état est-il clair, les actions sont-elles vérifiables, les erreurs sont-elles réversibles ?