Co-écrit avec @VaishShrivas
Nous avons appris aux agents CLI à prédire les réponses du terminal pendant le RL, en plus de la perte GRPO habituelle sur les actions. Le changement est minuscule : même déroulement et même passage avant, mais on arrête de masquer les tokens de sortie du terminal. L'effet est énorme : toutes les évaluations s'améliorent, et les modèles obtenus apprennent mesurablement comment le terminal se comporte.
Les agents CLI peuvent apprendre un modèle du terminal gratuitement — et l'utiliser pour mieux agir !
C'est ECHO : un objectif hybride qui s'entraîne sur les deux côtés de l'interaction : ce que l'agent écrit, et ce que le terminal écrit en retour.
Consultez l'article complet, et le code basé sur SkyRL.
Si vous êtes trop pressé pour lire cet article en entier, voici ce que nous avons découvert :
- Le RL standard pour agents jette la réponse de l'environnement. GRPO s'entraîne sur les tokens d'action et masque les réponses du terminal, même si elles sont déjà dans le contexte, passent déjà à travers le modèle et sont des signaux de vérité terrain sur la façon dont les actions de l'agent ont affecté l'environnement.
- ECHO corrige cela en s'entraînant sur les deux côtés de l'interaction. Il conserve la perte GRPO habituelle sur les tokens d'action et ajoute une simple perte d'entropie croisée sur l'environnement pour les tokens de sortie du terminal. C'est quelques lignes de code par-dessus n'importe quel entraîneur GRPO. Même déroulement et même passage avant, juste un masque différent sur les logits.
- ECHO fonctionne, et c'est gratuit ! ECHO améliore Qwen3-8B, OpenThinker-Agent-v1-SFT et Qwen3-14B sur tous les benchmarks que nous avons testés. ECHO s'entraîne également jusqu'à 2,3× plus vite pour atteindre les mêmes performances. TerminalBench-2.0 pass@1 double presque à la fois en 8B (2,7 → 5,2) et en 14B (5,2 → 10,8).
- ECHO enseigne la dynamique du terminal ! Sur des trajectoires mises de côté, l'entropie croisée des tokens d'environnement chute fortement avec ECHO et bouge à peine avec le GRPO pur. Preuve directe qu'ECHO apprend au modèle comment le terminal répond réellement. Les mêmes checkpoints qui prédisent mieux les sorties du terminal résolvent également plus de tâches.
- ECHO peut remplacer un enseignant expert. À partir d'un Qwen3-8B de base sans démonstrations d'experts, ECHO atteint presque ce que GRPO après SFT sur des démonstrations d'experts obtient.
- ECHO permet aux agents de s'améliorer eux-mêmes sans récompenses de vérificateur ! Sans aucune récompense de vérificateur, ECHO (sans aucun GRPO) permet à l'agent de continuer à s'améliorer simplement en agissant dans l'environnement et en prédisant ce qui se passe.
Tout a commencé par une simple question : si chaque commande produit une réponse du terminal, pourquoi le RL ne s'entraîne-t-il que sur la commande ?
Vaish a fait tout le travail pour le découvrir. J'ai contribué avec une expérience de labyrinthe ridicule*, une opinion ferme sur le titre, et en disant « putain » quand elle m'a montré le premier résultat. Merci à Ahmed Awadallah de nous avoir donné l'espace — et les GPU — pour poursuivre des idées comme celle-ci, même lorsqu'elles ne sont au départ qu'une démangeaison de recherche.
À noter : la première exécution en cluster d'ECHO a été lancée le 29 mars 😊
Ce travail a été réalisé chez AI Frontiers, un laboratoire de recherche boutique au sein de Microsoft Research.
Comment apprendre en continu ?
La première fois que cette idée est apparue, elle était motivée par une simple question sur l'auto-amélioration et l'apprentissage continu. Comment un agent peut-il s'améliorer simplement en agissant dans le monde ?
Vaish et moi parlions depuis l'automne dernier de l'auto-amélioration des agents CLI, c'est-à-dire ce que signifierait s'améliorer en interagissant avec l'environnement (alias le terminal), en particulier sans vérificateur.
Le RL sans vérificateur est un problème sur lequel les gens travaillent depuis des années, et la plupart des tentatives se heurtent au même problème : d'où vient la supervision, s'il n'y a pas de récompense ?
À peu près au même moment, un tweet stupide de ma part a conduit à un appel avec @willccbb discutant à nouveau de l'apprentissage continu. Pendant cette conversation, je me souviens avoir dit quelque chose de stupide comme ça :
Peut-être que l'apprentissage continu consiste à s'entraîner sur tout ce que l'environnement vous renvoie en réponse à vos actions.
Cela devrait apprendre quelque chose au modèle, non ?
Il s'avère que oui !
Le monde est une fonction de perte !
Lorsqu'un agent agit dans un environnement, la réponse de l'environnement à cette action est toujours vraie.
Un exemple du monde physique : si vous actionnez un interrupteur, la lumière s'allume, ou elle ne s'allume pas. Si elle ne s'allume pas, c'est une réponse légitime : cela vous dit quelque chose sur l'ampoule, le câblage, le disjoncteur, etc. Quoi qu'il en soit, ce qui revient est un petit fragment d'information sur la façon dont le monde a changé à cause de vos actions. Vous n'êtes pas exposé au mécanisme complet du fonctionnement de l'électricité, des interrupteurs et des ampoules, mais vous voyez le résultat. La lumière s'est-elle allumée ? Et cela suffit pour commencer à construire un modèle mental de la façon dont actionner les interrupteurs allume les lumières.
Le terminal fonctionne un peu de la même manière.
La sortie après une commande bash est un petit résumé de la façon dont l'état de l'ordinateur/conteneur a changé après l'exécution de la commande. Vous voyez stdout, stderr, les codes de sortie, les listes de fichiers, etc. Vous ne voyez pas l'état du noyau ni l'arborescence des processus ni rien de très détaillé.
Ce que vous voyez en retour est une projection de faible dimension de ce qui s'est passé en arrière-plan, ce qui est également ce que l'agent CLI utilisera pour choisir la prochaine action vers la tâche qu'il essaie d'accomplir. Et comme pour l'interrupteur, cela suffit pour construire un modèle mental — ou si vous voulez, un modèle du monde — de la façon dont le système se comporte.
Le meilleur, c'est que la sortie du terminal, qui est à nouveau un reflet de la façon dont l'état du système a changé, est un signal de supervision, calculé pour vous, à chaque tour, gratuitement.
Cool !
Le problème est que le RL agent standard (par exemple GRPO dans SkyRL) ne propage les gradients qu'à travers les tokens d'action et ignore les tokens de sortie du terminal. Malgré le fait que la sortie du terminal soit déjà dans le contexte. Le modèle y prête attention, le passage avant calcule des logits pour elle, et pourtant l'entraîneur la masque de la perte.
Quel gaspillage de bons tokens 😊
Alors, et si nous ne le faisions pas ?
Le modèle est déjà conditionné sur ces tokens. Il produit déjà une distribution de probabilité sur eux. Ajouter une perte d'entropie croisée ne coûte pratiquement rien.
Et si nous le faisons… le modèle a une raison d'apprendre comment le terminal se comporte réellement et peut donc construire, à l'intérieur de lui-même, un modèle implicite du système sur lequel il agit. Pour prédire ce que ls retournera, le modèle doit suivre quels fichiers il vient de créer, ce qui se trouve où, etc.
Comme Ilya l'a dit :
Bien prédire le token suivant signifie que vous comprenez la réalité sous-jacente qui a conduit à la création de ce token.
Dans notre contexte, cela signifierait : un agent qui est bon pour prédire les sorties du terminal a, dans un sens petit mais réel, construit un modèle implicite du terminal.
Alors, comment faire pour que l'agent prédise les sorties du terminal ?
ECHO : Apprendre un modèle du monde sans payer pour cela
Un déroulement d'agent CLI entrelace déjà deux flux de tokens : les tokens d'action de l'agent et les tokens d'observation de l'environnement. Le GRPO standard n'applique la perte que sur les tokens d'action.
C'est particulièrement gaspilleur car les récompenses du terminal sont rares, retardées et binaires. Dans notre configuration Qwen3-8B, pour de nombreuses tâches, moins de 15 % des déroulements sur politique sont réussis. Mais les trajectoires échouées ne sont pas des données inutiles : elles contiennent toujours des listes de fichiers, des erreurs, des journaux, des traces de pile, des sorties grep et d'autres conséquences des commandes de l'agent.
Notre méthode est la façon la plus embarrassante simple d'apprendre de ces conséquences 😊
Nous ajoutons une perte d'entropie croisée normalisée par la longueur sur les tokens d'observation de l'environnement, en plus de la perte GRPO standard sur les tokens d'action. ECHO est l'objectif hybride :
où Actions sont les positions des actions de l'agent et Observations sont les positions des sorties du terminal.
Quelques détails techniques :
- ECHO apprend sur politique. Au lieu de s'entraîner sur un ensemble figé de transcriptions du terminal provenant du modèle de base ou d'un enseignant, ECHO apprend à partir des réponses du terminal produites par le modèle actuel pendant le RL. À mesure que l'agent s'améliore, il explore de nouvelles parties de l'environnement et reçoit une supervision fraîche à partir de nouvelles transitions action → observation. De meilleures politiques induisent de meilleurs retours ; une meilleure prédiction des retours donne à la politique de meilleurs a priori sur les actions. Une boucle ! Amusant, non ?
- Dans l'objectif conjoint, λ compte. S'il est très petit, la perte d'environnement ne façonne pas beaucoup le modèle. S'il est trop grand, la politique peut optimiser pour des sorties prévisibles au lieu de l'avancement de la tâche. Il faut trouver un équilibre !
- Les tokens cibles comptent. Nous nous entraînons sur la sortie réelle du terminal, pas sur les avertissements du harnais. Les avertissements sont faciles à mémoriser ; le signal utile est la réponse réelle du terminal — noms de fichiers, traces de pile et messages d'erreur.
Alors, quel est le coût ?
Un lecteur avisé pourrait demander :
La passe arrière n'est-elle pas plus chère si vous rétropropagez des gradients à plus de positions de tokens ?
Presque pas. La partie chère de la rétropropagation est les multiplications matricielles à travers les couches d'attention et MLP, et elles s'exécutent sur la même séquence de tokens, peu importe quelles positions de sortie contribuent à la perte. Les logits à chaque position de réponse sont déjà calculés pour GRPO. Le masque d'action et le masque d'observation ne font que rassembler différents sous-ensembles pour différents termes de perte.
Arrêtons-nous une seconde : nous avons ajouté une perte de modélisation du monde, et le coût est pratiquement ZÉRO ! Pas de déroulements supplémentaires, de modèle enseignant, ni de passage avant supplémentaire.
ECHO aide-t-il à entraîner un meilleur agent CLI ?
Nous avons réalisé la comparaison la plus propre possible sur des tâches de terminal multi-tours : mêmes modèles, même recette GRPO, mêmes tâches, même budget de tours et de déroulements, même nombre d'étapes d'entraînement. Récompense = 1 si l'agent réussit les cas de test après n tours, 0 s'il échoue.
La seule différence est de savoir si les tokens de sortie du terminal entrent également dans la perte.
Les courbes roses sont ECHO et les courbes sarcelles sont GRPO. Sur toutes les tailles de modèle et les tranches d'évaluation, la réponse est la même : ajouter la prédiction de l'environnement rend l'agent nettement meilleur.
ECHO améliore constamment les performances sur les trois ensembles de validation retenus — les courbes roses se séparent des courbes sarcelles dès le début et restent généralement au-dessus.
ECHO apprend également beaucoup plus vite : ECHO atteint les performances de GRPO à 500 étapes sur Terminal-Bench Lite 280 étapes plus tôt ! Un gain de vitesse de 2,3× et il continue de monter 😊
Ces résultats confirment notre intuition derrière ECHO. GRPO s'entraîne uniquement avec des récompenses de résultat rares et binaires. Pour des domaines difficiles comme les tâches de terminal où le taux de réussite est faible pour les petits modèles, cela se traduit par peu ou pas de signal pour de nombreuses tâches.
ECHO rend l'entraînement beaucoup plus efficace en termes d'échantillons en transformant les actions échouées en supervision. Même lorsqu'une action ne résout pas la tâche, la réponse du terminal apprend toujours au modèle ce que cette action a causé ! Et prédire les conséquences des actions échouées peut aider l'agent à en choisir de meilleures.
Si vous préférez voir les chiffres sur toutes les évaluations, même histoire sous forme de tableau :
Regardez la dernière ligne de chaque bloc : ECHO. TerminalBench-2.0 pass@1 double presque à l'échelle 8B (2,7 → 5,2) et 14B (5,2 → 10,8). Et surtout, cela ne vient pas de données supplémentaires, de déroulements, d'un modèle enseignant ou d'un vérificateur différent. Le déroulement contenait déjà la réponse du terminal. ECHO apprend simplement à partir de cela.
« Les performances doublent presque sans coût supplémentaire » est une phrase que l'on lit très rarement dans toute une carrière de recherche 😊.
ECHO bat nettement les performances de GRPO sur tous les benchmarks et toutes les tailles de modèle, est beaucoup plus efficace en termes d'échantillons et ne coûte pratiquement rien. Vous apprenez un modèle du monde à mesure que votre politique s'améliore, ce qui l'aide à s'améliorer plus vite.
Les sceptiques pourraient toutefois objecter : apprenez-vous vraiment un modèle du monde ?
Voyons cela !
ECHO apprend-il réellement la dynamique du terminal ?
Nous allons nuancer un peu ici car la communauté de la modélisation du monde peut être un peu intense.
Nous ne prétendrons pas qu'ECHO apprend un modèle du monde au sens le plus fort. Mais nous affirmerons qu'ECHO entraîne une politique dont les états cachés ont absorbé quelque chose sur la façon dont le terminal se comporte, et dont la capacité à prédire ce que le terminal fera s'est mesurablement améliorée.
Si vous inversez la citation d'Ilya, vous obtenez une version plus falsifiable. Pour notre contexte, cela ressemblerait à ceci :
Si le modèle a appris la dynamique du terminal, il doit être bon pour prédire la sortie du terminal.
Parce qu'il n'y a pas d'autre moyen d'attribuer systématiquement une probabilité élevée aux bons tokens. Un modèle qui est un meilleur prédicteur est, en termes informationnels, un meilleur compresseur du système qu'il prédit.
La question devient donc empirique : ECHO rend-il réellement le modèle un meilleur prédicteur de la sortie du terminal ?
Oui. Et de beaucoup.
Pour rendre ce test propre, nous utilisons un modèle enseignant plus fort, Qwen 3 32B (non utilisé dans nos entraînements) pour générer des trajectoires pour chacun de nos ensembles de validation. Ensuite, nous avons évalué nos politiques de départ, les politiques entraînées avec GRPO et les politiques entraînées avec ECHO, et mesuré à quel point chaque modèle était « surpris » par les tokens de sortie du terminal résultants.
Le motif est le même sur chaque panneau : GRPO modifie à peine l'entropie croisée des tokens d'environnement par rapport à la politique de départ. ECHO la réduit fortement.
Donc nous ne dirons pas modèle du monde avec un grand M. Mais nous dirons ceci :
ECHO produit des politiques qui sont mesurablement meilleures pour compresser la dynamique du terminal, sur des trajectoires qu'elles n'ont pas générées.
Ce qui est la version opérationnelle de l'affirmation que fait le titre, et la version qui est entièrement défendable.
Résultat surprenant 1 : ECHO réduit la dépendance au SFT expert
Une recette courante pour le RL d'agent est : d'abord cloner le comportement de trajectoires expertes d'un modèle plus fort, puis lancer le RL. C'est particulièrement courant pour les agents de terminal, où la récompense est rare et l'espace d'action est vaste.
Dans notre contexte, la baseline SFT expert est OpenThoughts-Agent-v1-SFT (OT-SFT) : Qwen3-8B affiné sur des démonstrations d'agent terminal générées par un enseignant GLM-4.6 plus fort.
Nous avons donc demandé : quelle part de ce bénéfice du SFT expert ECHO peut-il récupérer sans cloner le comportement de l'enseignant ?
ECHO peut-il vous permettre d'ignorer le SFT expert ? Dans notre contexte, en grande partie oui !
Cette figure compare trois exécutions : GRPO pur sur le modèle de base, ECHO sur le modèle de base, et GRPO sur le modèle SFT (SFT + GRPO). Par rapport à l'écart entre GRPO et SFT+GRPO (par exemple le gain apporté par le SFT), ECHO récupère 104 % du gain sur ITD, 89 % sur Terminal Bench Lite (TBLite) et 50 % sur TerminalBench-2.0 (TB2) pass@1.
Le résultat suggère qu'une grande partie de la valeur du SFT expert pourrait provenir de l'apprentissage d'un a priori d'interaction, pas seulement d'un a priori de stratégie experte. Les démonstrations expertes montrent à la fois comment se comporter comme un agent terminal — inspecter les fichiers, exécuter des tests, suivre les traces, etc. — et ce qu'un expert ferait dans des états spécifiques. ECHO n'imite pas ces choix d'experts. Au lieu de cela, il entraîne le modèle à prédire les conséquences terminales de ses propres actions, afin qu'il apprenne quelles commandes exposent un état utile, quelles erreurs sont diagnostiques et quels tokens de sortie du terminal signalent un progrès. De meilleures stratégies peuvent ensuite émerger par l'interaction plutôt que par l'imitation.
Cela aide également à interpréter la répartition des benchmarks. Sur ITD et TBLite, ECHO atteint presque le niveau du SFT expert, ce qui suggère qu'une grande partie de l'avantage du SFT y provient d'un meilleur modèle de l'interaction avec le terminal. Sur TB2, ECHO récupère encore 50 % substantiels de l'écart sans démonstrations. L'écart restant est cohérent avec le fait que TB2 est plus difficile et distributionnellement plus éloigné de l'ensemble d'entraînement.
Nous ne traiterions pas cela comme un plafond fixe : un entraînement plus large ou plus long sur des tâches de type TB2 devrait améliorer encore l'agent.
Donc le message à retenir n'est pas que le SFT expert est obsolète, mais qu'une grande partie de ce que le SFT expert apporte peut être un meilleur modèle de l'interaction avec le terminal, et que cette partie peut être apprise directement à partir de l'environnement.
En résumé : Le terminal est l'enseignant !
Résultat surprenant 2 : Des étincelles d'auto-amélioration sans récompenses
Jusqu'à présent, ECHO était un GRPO avec une perte auxiliaire sur l'environnement. Le vérificateur dit toujours à l'agent s'il a résolu la tâche, et GRPO met à jour le modèle sur les tokens d'action. Donc configuration RL standard, avec un petit terme supplémentaire.
Mais si ECHO apprend réellement quelque chose à la politique sur le comportement du terminal, alors peut-être que nous n'avons pas du tout besoin du signal du vérificateur.
Nous demandons : Que se passe-t-il si nous désactivons le vérificateur ? Aucune récompense à apprendre, juste ceci :
C'est-à-dire que le modèle agit, observe, et se met à jour uniquement en prédisant les sorties du terminal comme conséquence de ses propres actions.
Cela semble ne pas devoir améliorer les performances de la tâche. Il n'y a pas d'étiquette indiquant quelle action était bonne. Si la politique s'améliore, cela doit être parce que le fait d'apprendre à prédire le terminal remodèle indirectement les a priori d'action de la politique.
Nous avons donc essayé !
Nous avons pris notre meilleur checkpoint Qwen3-8B+ECHO, supprimé complètement le terme GRPO, et entraîné pendant 100 étapes supplémentaires sur des tâches mises de côté en utilisant uniquement la perte d'entropie croisée sur l'environnement. La question était de savoir si le modèle pouvait s'améliorer sur des tâches OOD qu'il n'avait jamais vues auparavant, uniquement en interagissant avec l'environnement et en prédisant ce qui revenait.
Cette idée insensée a-t-elle fonctionné ? En quelque sorte, oui !
Sur val100 (dans la distribution) : +3,8 points de pourcentage. Sur ITD : +5,2 pp. Sur PyTerm (un ensemble OOD retenu de tâches terminales centrées sur Python) : +10,0 pp après filtrage des trajectoires d'appels d'outils propres.
L'entraînement sur l'environnement uniquement améliore la politique lorsque la sortie du terminal est une supervision utile. Sans signal de récompense, le modèle s'entraîne uniquement à prédire les sorties causées par ses propres actions, donc les gains dépendent du fait que ces sorties exposent une dynamique utile.
Sur val100, qui est proche du mélange d'entraînement, le gain est réel mais faible : +3,8 pp avant saturation. La politique a déjà appris la plupart des dynamiques locales pendant l'entraînement ECHO.
Sur ITD, la politique de départ plus faible produit des trajectoires bruitées — commandes invalides, erreurs d'analyse, boucles sans issue. Le filtrage sur les déroulements propres débruite le signal et donne +5,2 pp.
Les trajectoires propres seules ne suffisent cependant pas. Le même filtrage n'a pas constamment amélioré TBLite, tandis que PyTerm a démarré avec un taux de réussite similaire mais s'est amélioré avec la même recette — suggérant que le goulot d'étranglement n'est pas seulement la force de la politique. La différence clé est la richesse des observations : les tâches Python donnent un retour d'information dense lié aux actions — code → trace → correction — tandis que les tâches terminales plus larges révèlent l'état plus indirectement via les fichiers, les configurations et les configurations en plusieurs étapes.
Nous croyons que l'adaptation sans vérificateur est possible : une fois que le RL a produit un modèle d'exploration décent, l'agent peut parfois continuer à s'améliorer à partir des seules conséquences — mais seulement lorsque ses déroulements sont propres et que le retour du terminal est informatif. C'est CE qui est surprenant. Pas que l'agent s'améliore parfaitement, mais qu'il s'améliore du tout, à partir de rien d'autre que d'agir et de prédire ce qui revient.
Où cela nous mène
La leçon centrale d'ECHO est simple : les déroulements d'agents contiennent plus de supervision que la simple récompense finale, et nous devrions l'utiliser.
Chaque commande qu'un agent exécute produit une réponse du terminal — stdout, erreurs, traces, fichiers, journaux, etc. — et le RL standard n'utilise ces tokens que comme contexte pour l'action suivante. ECHO les transforme en cibles d'entraînement. Pas de modèle enseignant, de déroulements supplémentaires ou de modèle du monde séparé nécessaires. Nous arrêtons simplement de jeter les tokens d'environnement qui sont déjà dans la transcription.
Ce petit changement a conduit à trois résultats surprenants : de meilleures performances RL, une dépendance bien moindre au SFT expert, et dans certains contextes, une auto-amélioration sans vérificateur à partir de la seule interaction avec l'environnement. Nous ne pensons pas que cela rende les récompenses ou les démonstrations obsolètes. Les trajectoires expertes enseignent encore la stratégie et les vérificateurs fournissent le signal le plus propre au niveau de la tâche. Mais ECHO suggère qu'entre « imiter l'expert » et « attendre la récompense rare », il existe une source dense et sous-utilisée de supervision : les conséquences des propres actions de l'agent.
L'idée plus large est une continuation de la prédiction auxiliaire qui a une longue histoire en RL, et des travaux récents ont relancé les objectifs de modélisation du monde pour les agents LLM, par exemple, Agent Learning via Early Experience utilise le signal action-conséquence comme étape pré-RL, VAGEN ajoute une récompense de modélisation du monde pour les agents VLM, RWML pré-entraîne sur la prédiction de l'état suivant, et CWM entraîne un modèle de code sur des trajectoires d'observation-action. ECHO est la version en ligne, dans la boucle RL, et adaptée au CLI de cette même idée.
Jusqu'où cette idée peut-elle aller ?
La prochaine étape est de rendre ce signal d'environnement plus puissant — et de tester jusqu'où il se généralise. ECHO utilise les sorties brutes du terminal car elles sont déjà dans le déroulement, mais la meilleure cible d'apprentissage pourrait être une représentation plus propre et plus compacte : des résumés ou des vues de l'état pertinentes pour la tâche. Aussi : sur quelles observations devrions-nous nous entraîner ? Quand devrions-nous filtrer les trajectoires ? Comment devrions-nous pondérer la prédiction de l'environnement par rapport à l'optimisation de la politique ? La même idée peut-elle fonctionner au-delà des terminaux : pour les agents navigateurs, les systèmes multi-outils, les agents de codage à long horizon, ou les assistants orientés utilisateur où les suivis, les corrections et les préférences sont une autre forme de retour d'interaction ?
Notre pari est que partout où un agent agit et que le monde répond en tokens, ces tokens de réponse — ou de meilleures représentations de ceux-ci — devraient faire partie du signal d'apprentissage. ECHO est la version la plus simple de cette idée à laquelle nous pouvions penser, et nous soupçonnons qu'une certaine forme de prédiction de token d'environnement deviendra standard dans les entraîneurs RL d'agents d'ici la fin 2026.
Consultez l'article complet, et le code basé sur SkyRL.
Essayez ECHO et dites-nous à quelle vitesse votre agent s'est entraîné.
Note : entraîner un modèle de monde de labyrinthe sur mon ordinateur portable… en quelque sorte
Vous vous souvenez quand j'ai dit que j'avais « contribué à une expérience de labyrinthe ridicule » ? Voici l'expérience de labyrinthe ridicule.
Le dispositif était une version miniature d'ECHO : un labyrinthe en grille dans un terminal minuscule. L'agent (un transformateur de 10M en boucle) émet une direction — haut, bas, gauche, droite — et le terminal répond avec l'endroit où se trouve l'agent par rapport à ses « voisins » (il s'agit essentiellement d'une recherche de chemin dans une grille 2D), et la distance jusqu'à la destination. Donc le déroulement ressemble exactement (pour de petites valeurs d'exactement) à un déroulement d'agent CLI, juste beaucoup plus simple 😊 : action → réponse de l'environnement → action → réponse de l'environnement, etc.
J'ai testé deux conditions sur un transformateur de 10M de paramètres entraîné à partir de zéro : 1) entraînement uniquement sur les tokens d'action, 2) entraînement sur les tokens d'action et la réponse du terminal (voisins, distance, etc.). Tous entraînés sur des labyrinthes frais de 6×6 / 7×7 / 8×8.
Est-ce que ce truc de labyrinthe est un article dans Nature ? Non. Mais : je pense qu'il y a un point que j'ai fait valoir et qui continue de se généraliser.
Presque toute idée propre a un microcosme : une version réduite que vous pouvez exécuter sur un ordinateur portable en une soirée et qui vous dit si l'idée mérite d'être mise à l'échelle.
Le labyrinthe n'a pas prouvé qu'ECHO fonctionnerait. Il m'a donné assez de conviction pour envoyer un message Teams à Vaish au lieu d'oublier l'idée. Il s'est avéré que Vaish tournait autour de la même idée de manière indépendante et lorsque sa première exécution en cluster est revenue avec des résultats, j'étais ravi et vraiment surpris. Le labyrinthe ECHO avait laissé entendre que la direction était bonne, mais il n'aurait pas pu prédire le doublement des scores TerminalBench, la récupération de la majeure partie du SFT expert, ni l'auto-amélioration sans récompenses. C'étaient les résultats de Vaish. « Résoudre en quelque sorte un labyrinthe 6×6 » et « doubler les scores sur TerminalBench » sont des états épistémiques très différents.
Mais le but de cet addendum n'est pas que le portable remplace l'expérience sur le cluster. Le but est que la plupart de mes idées sont erronées et que l'expérience sur le portable (avec l'aide de Claude Code et Codex) me dit lesquelles abandonner avant qu'elles ne fassent perdre du temps à quelqu'un d'autre. De temps en temps, une idée survit, et quand c'est le cas, elle peut peut-être mériter le temps et les GPU d'un collaborateur.
ECHO en fait partie.
