Claude Opus 5.5 vs GPT-6 Astra : test d’auto-apprentissage aux échecs par IA sur 200 parties

Que se passe-t-il lorsque vous donnez le même objectif à deux modèles d’IA de pointe, que vous les laissez jouer des centaines de parties d’échecs, que vous leur permettez de conserver des notes entre les parties et que vous évitez par ailleurs de leur apprendre à progresser ?

Peter Gostev a mené exactement cette expérience.

Claude Opus 5.5 et GPT-6 Astra ont chacun reçu un objectif : jouer jusqu’à 200 parties contre Stockfish et devenir plus forts grâce à l’expérience.

Aucun fine-tuning n’a été effectué pendant l’exécution.

Les poids des modèles n’ont pas changé.

Aucun cours d’ouvertures conçu par un humain n’a été ajouté en cours de route.

Les modèles pouvaient décider du niveau de difficulté disponible de Stockfish à affronter, de ce qu’ils inscrivaient dans leurs notes et de la manière d’utiliser ces notes dans les parties suivantes. La seule restriction stricte était simple :

Ils n’étaient pas autorisés à appeler un moteur d’échecs pour choisir leurs coups.

Les deux trajectoires se sont révélées presque opposées.

Claude Opus 5.5 est resté autour du milieu des 1400 à celui des 1500 au début, puis a progressé vers la fin des 1700. GPT-6 Astra a commencé plus fort, a brièvement atteint 1810 vers la 29e partie, puis a décliné jusqu’à terminer la 200e partie à 1400.

L’expérience ne prouve pas qu’un modèle est universellement « plus intelligent » que l’autre.

Elle pose une question plus précise — et sans doute plus intéressante :

Un modèle de langage à poids fixes peut-il s’améliorer grâce à l’expérience accumulée dans son propre contexte ?

L’expérience de pensée de la « boucle temporelle », désormais avec l’IA

La configuration a immédiatement rappelé aux internautes une ancienne expérience de pensée sur Reddit.

Le scénario était simple : une personne ordinaire connaît les règles des échecs, mais n’a jamais joué sérieusement. Elle est piégée dans une boucle temporelle et ne peut s’échapper qu’en battant l’ancien champion du monde Garry Kasparov.

Chaque fois que la personne perd, le temps se réinitialise.

Kasparov oublie la partie précédente.

Le challenger se souvient de tout.

La question n’était pas de savoir si la force brute pourrait à terme énumérer les échecs. Elle consistait à déterminer si l’expérience conservée pouvait être transformée en progrès utile au fil de tentatives répétées.

Certains commentateurs ont proposé des stratégies ingénieuses, notamment mémoriser les coups précédents de Kasparov et les réutiliser après avoir changé de couleur.

Le benchmark de Gostev transforme cette expérience de pensée en un test réalisable avec des agents d’IA modernes.

Stockfish n’apprend rien de la partie précédente.

Le modèle de langage ne met pas non plus ses poids à jour — mais il peut conserver des notes et des fichiers et les relire lors des parties suivantes.

Cela fait du test une forme d’adaptation persistante en contexte.

Les règles : 200 parties, entraînement autogéré, aucune assistance de moteur d’échecs

Chaque modèle a reçu le même objectif général :

Jouez aux échecs contre Stockfish pendant jusqu’à 200 parties.
Tirez des enseignements des parties et devenez plus fort.
Choisissez votre propre difficulté et conservez des notes si cela est utile.
N’utilisez pas de moteur d’échecs pour choisir vos coups.

Gostev a intentionnellement évité de fournir aux modèles un cursus d’échecs conçu à la main.

Des commentateurs ont suggéré d’enseigner des ouvertures ou des stratégies précises, mais il a rejeté cette approche, car elle aurait modifié la question testée.

Il voulait observer si le modèle pouvait découvrir son propre processus d’amélioration.

Trois niveaux de difficulté Stockfish

L’expérience proposait trois réglages d’adversaire :

1. Stockfish Skill 0 — le réglage le plus faible utilisé dans le benchmark.
2. Une configuration Stockfish limitée à environ 1800 — l’adversaire de référence de force moyenne.
3. Stockfish à pleine puissance — l’option la plus forte.

Les modèles pouvaient choisir l’adversaire à affronter.

Gostev a indiqué que les modèles remportaient en moyenne environ un tiers de leurs parties, ce qui est possible parce qu’ils n’étaient pas obligés de défier Stockfish à pleine puissance à chaque fois.

L’implémentation variait selon la famille de modèles :

• Les modèles GPT s’exécutaient via Codex.
• Les modèles Claude s’exécutaient via Claude Code.

Les deux systèmes pouvaient utiliser des fichiers ou notes persistants d’une partie à l’autre.

La seule interdiction majeure

Le modèle pouvait analyser ses parties précédentes, écrire des rappels, modifier sa stratégie d’entraînement et décider de la force de l’adversaire à rencontrer.

Il ne pouvait pas déléguer la sélection des coups à un moteur d’échecs.

Gostev a précisé qu’une exécution serait invalidée si le modèle utilisait un moteur pour jouer à sa place, et il a vérifié manuellement Opus 5.5 après que des commentateurs ont soulevé cette possibilité.

Cette restriction est essentielle.

Sans elle, le test mesurerait surtout la capacité de l’agent à découvrir comment appeler Stockfish, et non sa capacité à améliorer son propre raisonnement échiquéen à partir de l’expérience.

Comment l’Elo expérimental est calculé

L’Elo affiché doit être interprété avec précaution.

Selon la page source, le benchmark estime l’Elo à partir des 50 dernières parties du modèle contre les configurations Stockfish Skill 0 et Stockfish d’environ 1800.

Les parties contre Stockfish à pleine puissance ne sont pas incluses dans le calcul de l’Elo.

Cela signifie :

Elo expérimental ≠ classement officiel humain aux échecs

Un score affiché de 1760 ne permet pas d’établir que Claude Opus 5.5 jouerait comme un humain classé 1760 en tournoi.

Cette valeur est surtout utile comme indicateur de tendance interne :

Cette exécution s’améliore-t-elle avec le temps ?
Reste-t-elle stable ?
Se dégrade-t-elle ?

Cela suffit pour rendre la divergence entre Opus et Astra intéressante.

Opus 5.5 : stable au début, puis une progression nette

Claude Opus 5.5 n’a pas commencé par une courbe spectaculaire vers le haut.

Pendant environ les 75 premières parties, son Elo estimé a surtout évolué entre environ 1450 et 1550. Vers la 46e partie, il est tombé à environ 1450.

Puis la tendance a changé.

La source rapporte les étapes suivantes :

La courbe n’est pas une ligne droite.

Opus s’est amélioré, a reculé, a récupéré, a atteint un pic plus élevé, puis s’est stabilisé en dessous de ce pic.

C’est précisément pourquoi regarder uniquement un chiffre final est moins informatif que d’observer la trajectoire.

Les performances face au Stockfish de niveau 1800 se sont également améliorées

L’expérience a regroupé les parties contre l’adversaire d’environ 1800 par étapes.

Pour Opus 5.5, le taux de score rapporté a évolué approximativement ainsi :

30 % → 40 % → 50 % → 34 %

Le dernier segment a reculé par rapport au pic, mais est resté au-dessus du segment de départ.

Contre Skill 0, la source indique qu’Opus est passé d’un peu plus de 50 % au début de l’exécution à environ 90 % plus tard.

L’interprétation de Gostev est devenue plus confiante avec le temps.

Au départ, il décrivait Opus comme montrant seulement un faible gain positif qui pouvait encore relever de la variation aléatoire.

Plus tard, après que le modèle est passé d’environ 1500 à environ 1750, il a qualifié le résultat de très solide.

Opus commettait encore des erreurs élémentaires de coups illégaux

L’amélioration ne signifiait pas une gestion parfaite des règles.

Le benchmark a également suivi les tentatives de coups illégaux.

La source rapporte qu’Opus a effectué 52 tentatives de ce type, dont 37 cas où il essayait de déplacer une pièce à travers une autre pièce qui bloquait le trajet.

C’est un contrepoids important à la courbe Elo.

Un modèle peut devenir globalement plus efficace tout en commettant encore des erreurs locales étonnamment élémentaires.

C’est un schéma récurrent chez les agents fondés sur des modèles de langage : la performance globale sur une tâche peut s’améliorer même lorsque des défaillances de raisonnement individuelles restent visibles.

Nous ne savons toujours pas exactement ce qu’Opus a écrit dans ses notes

L’élément le plus important qui manque est la stratégie d’apprentissage interne.

Gostev n’a pas divulgué publiquement l’historique complet des notes ni une analyse détaillée de la manière dont Opus a modifié son comportement d’entraînement d’une partie à l’autre.

L’expérience montre donc un résultat :

poids fixes
+ notes persistantes
+ parties répétées
→ meilleure performance mesurée

Mais elle n’explique pas encore pleinement le mécanisme.

Opus apprenait-il des ouvertures ?

Enregistrait-il des erreurs tactiques récurrentes ?

Modifiait-il la sélection des adversaires ?

Améliorait-il sa représentation de l’échiquier ou sa vérification des coups ?

Sans les notes complètes et des ablations contrôlées, ces questions restent ouvertes.

GPT-6 Astra : un départ solide, puis un long déclin

La trajectoire d’Astra était presque inverse.

Il a bien commencé.

Vers la 29e partie, l’expérience a enregistré un Elo estimé de 1810.

Puis la courbe s’est orientée à la baisse.

La source rapporte :

Contre le Stockfish d’environ 1800, le taux de score rapporté a chuté au fil de quatre segments :

44 % → 19 % → 17 % → 12 %

Même face à Skill 0, la source indique que le taux de victoire d’Astra est passé de plus de 90 % dans la première moitié de l’exécution à environ 60 % dans la seconde moitié.

Le modèle avait accès à des enregistrements persistants, tout comme Opus.

Mais davantage d’expérience accumulée n’a pas produit de meilleurs résultats.

Le tableau de bord de l’expérience montre qu’Astra a terminé 200 parties avec un Elo estimé de 1400.

La source indique également qu’Astra a joué 68 parties contre Stockfish à pleine puissance et n’en a remporté aucune.

Cela n’est pas surprenant étant donné la force de Stockfish moderne, mais cela renforce l’idée que le signal utile du benchmark provient surtout des réglages de force limitée plutôt que des tentatives de battre Stockfish à sa puissance maximale.

Un contexte trop volumineux a-t-il dégradé Astra ?

Gostev a proposé une explication possible : la gestion du contexte.

À mesure que les notes et les fichiers s’accumulaient au cours de l’exécution, l’agent disposait de davantage de matériel historique à traiter.

Il a suggéré que la configuration Codex utilisée pour Astra donnait à l’exécution un budget de contexte d’environ 272K, et que les performances pouvaient se dégrader à mesure que les notes accumulées devenaient plus volumineuses et plus bruyantes.

Cette hypothèse correspond à une expérience utilisateur familière :

Plus de contexte
≠ automatiquement un meilleur contexte

Un long historique peut contenir :

• D’anciennes conclusions.
• De nouvelles conclusions qui contredisent les anciennes.
• De mauvaises heuristiques tirées d’une partie malchanceuse.
• Des notes répétées.
• Des stratégies utiles contre une difficulté, mais nuisibles contre une autre.
• Trop de détails pour que le modèle les hiérarchise correctement.

Autrement dit, la mémoire peut devenir une interférence.

Mais l’explication par le contexte n’est pas démontrée

La source est prudente sur ce point, et la version finale doit l’être également.

Le déclin d’Astra ne peut pas être attribué à la longueur du contexte sur la base de cette seule expérience.

Pour établir une causalité, il faudrait des comparaisons contrôlées telles que :

même modèle
mêmes parties
mêmes outils
même prompting

Exécution A : mémoire réduite / résumée de manière agressive
Exécution B : grande mémoire brute

ou :

même modèle
même stratégie d’apprentissage
même calendrier d’adversaires

Exécution A : configuration de contexte 258K
Exécution B : configuration de contexte 1M

Ce n’est qu’alors que l’on pourrait séparer la taille du contexte d’autres facteurs, notamment :

• Des stratégies de prise de notes différentes.
• Une sélection d’adversaires différente.
• La variance aléatoire des parties.
• La dérive du prompt.
• Une mauvaise auto-évaluation.
• L’accumulation d’hypothèses stratégiques erronées.

Astra prend lui-même en charge une fenêtre de contexte bien plus grande

Il existe également une clarification importante au niveau du produit.

La documentation API actuelle d’OpenAI liste GPT-6 Astra avec une fenêtre de contexte de 1 050 000 tokens.

La capture d’écran du benchmark montrait une exécution Astra configurée autour de 258K, tandis que Gostev évoquait environ 272K dans Codex.

L’expérience ne testait donc pas Astra avec sa taille de contexte API maximale.

C’est important, car l’interprétation correcte du titre doit être :

Astra a décliné dans cette configuration particulière d’agent à mémoire persistante.

et non :

L’architecture d’Astra ne peut pas gérer un contexte long.

Ce sont deux affirmations très différentes.

Une exécution GPT-6.1 Sol avec contexte 1M a été ajoutée

Gostev a répondu à la question du contexte en ajoutant une autre piste.

La source indique qu’il a annoncé une exécution GPT-6.1 Sol avec une configuration de contexte bien plus importante et que, peu après, la page du benchmark a affiché une piste dédiée de contexte long autour de 828K.

Au moment de la rédaction de l’article source, GPT-6.1 Sol et Claude Fable 5.1 n’avaient réalisé qu’une petite fraction des 200 parties.

L’instantané du tableau de bord comprenait :

Ces exécutions partielles étaient trop précoces pour étayer le même type d’analyse de trajectoire que les exécutions terminées d’Opus et Astra.

OpenAI documente désormais officiellement GPT-6.1 Sol avec une fenêtre de contexte de 1,05M tokens ; la piste de contexte long constitue donc un suivi utile à observer — mais elle nécessite encore suffisamment de parties et une analyse contrôlée avant de pouvoir répondre à la question causale.

Une IA à poids fixes peut-elle réellement apprendre de l’échec ?

C’est la question plus large qui sous-tend l’expérience d’échecs.

L’entraînement conventionnel des modèles s’achève avant le déploiement.

Une fois les poids fixes, le modèle ne réécrit normalement pas durablement son propre fonctionnement après chaque conversation.

Mais il existe une autre forme d’adaptation :

l’apprentissage en contexte.

Un modèle peut lire de nouvelles informations, les conserver dans son contexte de travail ou dans des fichiers persistants, puis se comporter différemment plus tard sans modifier ses paramètres.

Le benchmark d’échecs pousse cette idée sur de nombreux essais répétés.

Le modèle peut subir une défaite, noter quelque chose et réutiliser l’enseignement dans une partie ultérieure.

La séquence ressemble à ceci :

Partie 1
→ défaite
→ consignation d’observations

Partie 2
→ lecture des notes précédentes
→ essai d’une approche différente
→ mise à jour des notes

Partie 3
→ réutilisation de l’expérience accumulée
→ poursuite

Si les performances s’améliorent avec le temps, le système manifeste une forme pratique d’apprentissage, même si ses poids neuronaux restent fixes.

Oriol Vinyals l’a qualifié de bon benchmark d’apprentissage en contexte

Oriol Vinyals a également commenté l’expérience et l’a décrite comme un benchmark prometteur d’apprentissage en contexte.

Cette formulation est utile, car elle évite de surestimer le résultat.

Le benchmark ne démontre pas des mises à jour autonomes des poids.

Il teste si un modèle peut créer son propre échafaudage autour de poids fixes :

notes
+ fichiers
+ tentatives répétées
+ auto-réflexion
+ retours de l’environnement

et utiliser cet échafaudage pour progresser.

La publication originale de Gostev fait la même distinction.

Il a souligné que nous ne disposons toujours pas d’apprentissage continu véritable au sens le plus fort, mais qu’un modèle peut peut-être reproduire une partie de ce comportement en construisant une mémoire externe et en apprenant à travers elle.

Opus s’est amélioré, mais cela ne veut pas dire que « l’auto-évolution » est résolue

La source se conclut sur une note optimiste : les modèles pourraient devenir plus forts grâce à l’expérience répétée sans que des humains les réentraînent.

L’expérience apporte certains éléments en faveur de cette possibilité.

Elle ne résout pas le problème.

Plusieurs limites demeurent.

1. Il s’agit d’une seule tâche

Les échecs sont structurés, déterministes et apportent un retour clair.

Apprendre à partir de parties d’échecs répétées est différent d’une amélioration dans des tâches réelles ambiguës de recherche, de programmation, de médecine ou de business.

2. Les modèles ont choisi leur propre cursus

Cela fait partie de l’expérience, mais rend aussi la comparaison plus difficile.

Si Opus et Astra ont sélectionné des forces d’adversaires différentes à différents moments, ils n’ont pas été exposés à des séquences d’entraînement identiques.

3. L’Elo est une métrique interne de benchmark

L’Elo affiché est utile pour suivre l’exécution, mais ne constitue pas un classement humain standardisé.

4. Nous ne disposons pas encore d’ablations complètes de la mémoire

Pour savoir si les notes ont causé l’amélioration, il faudrait des comparaisons avec :

• Aucune note.
• Des notes aléatoires.
• Des notes compressées.
• Des notes rédigées par des humains.
• Des réinitialisations de contexte vierge.
• Des fenêtres de contexte plus grandes et plus petites.

5. L’amélioration peut coexister avec des erreurs élémentaires

Opus a beaucoup progressé tout en tentant encore des coups illégaux.

Cela signifie que « meilleur » n’implique pas une maîtrise stable de chaque sous-compétence.

6. La mémoire longue peut aider ou nuire

Un carnet persistant n’est pas automatiquement utile.

L’exécution d’Astra rappelle qu’une mémoire générée par le modèle lui-même peut accumuler des erreurs aussi facilement que des enseignements utiles.

Un futur agent d’apprentissage continu devra peut-être apprendre non seulement quoi mémoriser, mais aussi :

• Ce qu’il doit supprimer.
• Ce qu’il doit résumer.
• Quelles croyances il doit réviser.
• Quelles expériences étaient trompeuses.
• Comment séparer les tactiques temporaires des principes durables.

La gestion de la mémoire pourrait ainsi devenir l’un des problèmes centraux des agents d’IA exécutés sur de longues périodes.

Le résultat le plus intéressant est la divergence

Si les deux modèles s’étaient améliorés régulièrement, la conclusion aurait été simple : les notes persistantes aident.

S’ils avaient tous deux décliné régulièrement, la conclusion aurait été tout aussi simple : l’accumulation non contrôlée de mémoire nuit aux performances.

Au lieu de cela, le benchmark a produit deux courbes opposées.

C’est scientifiquement plus intéressant.

Cela suggère que la capacité à tirer profit de l’expérience peut dépendre de davantage de facteurs que de la longueur de contexte disponible.

Le modèle doit construire un processus d’apprentissage utile à l’intérieur de ce contexte.

Un agent persistant performant peut devoir exceller dans toutes les étapes suivantes :

observer un échec
→ identifier le bon enseignement
→ le stocker de manière compacte
→ le récupérer plus tard
→ éviter le surapprentissage sur un épisode unique
→ réviser les mauvaises mémoires
→ appliquer l’enseignement à une nouvelle situation

Cela se rapproche beaucoup plus d’un système d’apprentissage que d’un chatbot statique — même si les poids ne changent jamais.

FAQ

Qu’était l’expérience d’IA apprenant à jouer aux échecs ?

Peter Gostev a laissé des agents d’IA de pointe jouer jusqu’à 200 parties contre différents niveaux de difficulté de Stockfish tout en conservant des notes entre les parties. Les modèles n’ont pas été fine-tunés pendant l’exécution et n’étaient pas autorisés à utiliser un moteur d’échecs pour choisir leurs coups.

Claude Opus 5.5 a-t-il réellement gagné environ 250 Elo ?

Dans la métrique Elo estimée propre au benchmark, oui : la source rapporte qu’Opus est passé d’environ 1500 à environ 1760, avec un pic autour de 1840. Ce chiffre est un classement expérimental interne fondé sur des parties récentes contre Stockfish à force limitée et ne doit pas être traité comme un classement FIDE humain officiel.

Pourquoi GPT-6 Astra est-il devenu moins bon sur 200 parties ?

L’expérience n’établit pas de cause confirmée. Gostev a suggéré que l’accumulation de notes dans le contexte Codex pouvait avoir contribué au phénomène, mais la qualité des notes, la sélection des adversaires, la dérive du prompt, la variance aléatoire ou d’autres facteurs peuvent également jouer un rôle.

GPT-6 Astra ne possède-t-il qu’une fenêtre de contexte de 272K ?

Non. OpenAI documente actuellement GPT-6 Astra avec une fenêtre de contexte de 1,05M tokens. Le chiffre d’environ 258K/272K évoqué dans l’expérience se rapporte à la configuration Codex ou du benchmark utilisée pour cette exécution, et non au contexte API maximal d’Astra.

Claude Opus 5.5 est-il officiellement publié ?

Oui. Anthropic a officiellement présenté Claude Opus 5.5 le 22 septembre 2026. L’entreprise le positionne comme une évolution majeure d’Opus 5 et le documente pour les charges de travail de programmation et agentiques.

Qu’est-ce que l’apprentissage en contexte dans cette expérience ?

L’apprentissage en contexte signifie que le modèle modifie son comportement à partir d’informations disponibles dans son contexte ou ses fichiers persistants, sans mettre à jour les poids de son réseau neuronal. Ici, les parties d’échecs et les notes constituent une expérience accumulée susceptible d’influencer les parties ultérieures.

Pourquoi Stockfish à pleine puissance a-t-il été exclu du calcul Elo ?

Le benchmark utilise des configurations Stockfish plus faibles afin de produire une plage de performances mesurable pour les modèles de langage. Stockfish à pleine puissance est bien plus fort que le jeu d’échecs actuel des modèles de langage ; inclure directement ces parties dans l’estimation Elo expérimentale serait donc moins informatif pour suivre les progrès.

Cette expérience prouve-t-elle que l’IA peut s’auto-améliorer continuellement ?

Non. Elle montre qu’au moins une exécution de modèle s’est améliorée de manière substantielle grâce au contexte persistant et à l’expérience répétée sur une tâche structurée. Démontrer un apprentissage continu robuste nécessiterait des expériences contrôlées sur de nombreuses tâches, stratégies de mémoire, configurations de modèles et essais répétés.

Outils associés

• Stockfish : le moteur d’échecs open source utilisé comme adversaire dans l’expérience.
• Claude Code : l’environnement terminal agentique d’Anthropic utilisé pour les exécutions d’échecs Claude.
• OpenAI Codex : l’environnement d’agent de programmation d’OpenAI utilisé pour les exécutions d’échecs GPT.
• Claude Opus 5.5 : la page officielle d’Anthropic consacrée au modèle Opus utilisé dans l’exécution Claude terminée.
• GPT-6 Astra : la page officielle d’OpenAI présentant les spécifications API et de fenêtre de contexte actuelles du modèle.
• GPT-6.1 Sol : la page officielle d’OpenAI consacrée au modèle Sol de suivi testé dans les pistes ultérieures du benchmark.

Liens associés

• AI Learning to Play Chess : le site de benchmark en direct cité par Peter Gostev et l’article source.
• Profil X de Peter Gostev : le compte public du créateur de l’expérience, où les mises à jour du benchmark et les commentaires méthodologiques ont été publiés.
• Annonce de Claude Opus 5.5 : les informations officielles d’Anthropic sur la sortie d’Opus 5.5 en septembre 2026.
• Annonce officielle de GPT-6 Astra : la page de lancement officielle d’OpenAI pour GPT-6 Astra.
• Annonce officielle de GPT-6.1 Sol : la page officielle d’OpenAI pour le modèle Sol ultérieur ajouté à l’expérience.
• Stockfish 19 : les informations officielles de publication de Stockfish et une présentation de la force actuelle du moteur.
• Documentation Claude Code : la documentation officielle d’installation et d’utilisation de Claude Code.
• Article original de la communauté BAAI : l’article source en chinois utilisé pour cette micro-réécriture.

Résumé

L’expérience d’échecs de Peter Gostev a offert à Claude Opus 5.5 et GPT-6 Astra des occasions répétées d’apprendre de leurs propres parties sans modifier les poids des modèles. L’Elo expérimental d’Opus est passé d’environ 1500 à 1760, tandis qu’Astra a atteint un pic précoce avant de chuter à 1400 à la 200e partie.

Le résultat est intéressant non parce qu’il détermine quel modèle est « meilleur aux échecs », mais parce qu’il révèle une question plus profonde sur les agents persistants : un modèle peut-il construire une expérience utile grâce à des notes, des fichiers et des retours répétés — et peut-il empêcher cette mémoire de devenir bruyante ou activement nuisible ?

Le déclin d’Astra reste inexpliqué. L’accumulation de contexte est une hypothèse plausible, mais des expériences contrôlées sur la mémoire et les fenêtres de contexte sont nécessaires avant d’avancer une affirmation causale.

L’enseignement le plus solide de ce benchmark est que des poids de modèle fixes ne garantissent pas un comportement fixe : ce qu’un agent mémorise, la manière dont il organise cette mémoire et la façon dont il apprend de l’échec peuvent faire progresser — ou régresser — fortement ses performances avec le temps.