Scritto in collaborazione con @VaishShrivas
Abbiamo insegnato agli agenti CLI a prevedere le risposte del terminale durante l'RL, insieme alla consueta perdita GRPO sulle azioni. La modifica è minima: stesso rollout e forward pass, ma smettiamo di mascherare i token di output del terminale. L'effetto è enorme: tutti i benchmark migliorano e i modelli risultanti imparano in modo misurabile come si comporta il terminale.
Gli agenti CLI possono imparare un modello di terminale gratis — e usarlo per agire meglio!
Questo è ECHO: un obiettivo ibrido che si allena su entrambi i lati dell'interazione: ciò che l'agente scrive e ciò che il terminale risponde.
Date un'occhiata al paper completo e al codice basato su SkyRL.
Se non hai tempo di leggere tutto il post, ecco cosa abbiamo scoperto:
- L'RL standard per agenti scarta la risposta dell'ambiente. GRPO si allena sui token di azione e maschera le risposte del terminale, anche se sono già nel contesto, passano già attraverso il modello e sono segnali di verità fondamentali su come le azioni dell'agente hanno influenzato l'ambiente.
- ECHO risolve il problema allenandosi su entrambi i lati dell'interazione. Mantiene la consueta perdita GRPO sui token di azione e aggiunge una semplice perdita di cross-entropia dell'ambiente sui token di output del terminale. Sono poche righe di codice in più su qualsiasi addestratore GRPO. Stesso rollout e forward pass, solo una maschera diversa sui logit.
- ECHO funziona, ed è gratis! ECHO migliora Qwen3-8B, OpenThinker-Agent-v1-SFT e Qwen3-14B su ogni benchmark che abbiamo testato. ECHO si allena anche fino a 2,3× più velocemente per raggiungere le stesse prestazioni. TerminalBench-2.0 pass@1 quasi raddoppia sia a 8B (2,7 → 5,2) che a 14B (5,2 → 10,8).
- ECHO insegna le dinamiche del terminale! Su traiettorie non viste, la cross-entropia dei token ambientali diminuisce drasticamente con ECHO e si muove a malapena con la GRPO standard. Prova diretta che ECHO insegna al modello come il terminale risponde effettivamente. Gli stessi checkpoint che predicono meglio gli output del terminale risolvono anche più compiti.
- ECHO può sostituire un insegnante esperto. Da una base Qwen3-8B senza dimostrazioni esperte, ECHO eguaglia quasi ciò che GRPO dopo SFT su dimostrazioni esperte ottiene.
- ECHO permette agli agenti di auto-migliorarsi senza ricompense del verificatore! Senza alcuna ricompensa del verificatore, ECHO (senza alcuna GRPO) consente all'agente di migliorare ulteriormente semplicemente agendo nell'ambiente e prevedendo cosa succede.
Tutto è iniziato con una domanda semplice: se ogni comando produce una risposta del terminale, perché l'RL si allena solo sul comando?
Vaish ha fatto tutto il lavoro per capirlo. Io ho contribuito con un esperimento stupido sul labirinto*, un'opinione forte sul titolo e un "cavolo" quando mi ha mostrato i primi risultati. Grazie ad Ahmed Awadallah per averci dato spazio — e GPU — per inseguire idee come questa, anche quando iniziano solo come un prurito di ricerca.
Vale la pena notare: la prima esecuzione cluster per ECHO è stata lanciata il 29 marzo 😊
Questo lavoro è stato svolto presso AI Frontiers, un laboratorio di ricerca boutique all'interno di Microsoft Research.
Come si impara continuamente?
La prima volta che questa idea è emersa era motivata da una semplice domanda sull'auto-miglioramento e l'apprendimento continuo. Come fa un agente a migliorare semplicemente agendo nel mondo?
Io e Vaish ne parlavamo dall'autunno scorso sull'auto-miglioramento negli agenti CLI, cioè cosa significherebbe migliorare interagendo con l'ambiente (ovvero il terminale), specialmente senza un verificatore.
L'RL senza verificatore è un problema su cui le persone lavorano da anni, e la maggior parte dei tentativi incontra lo stesso problema: da dove arriva la supervisione, se non c'è ricompensa?
Più o meno nello stesso periodo, un mio stupido post su Twitter ha portato a una chiamata con @willccbb in cui si parlava di nuovo di apprendimento continuo. Durante questa chiacchierata ricordo di aver detto qualcosa di stupido come:
Forse l'apprendimento continuo significa allenarsi su qualunque cosa l'ambiente ti restituisca come risposta alle tue azioni.
Questo dovrebbe insegnare qualcosa al modello, giusto?
A quanto pare, sì!
Il mondo è una funzione di perdita!
Quando un agente agisce in un ambiente, la risposta dell'ambiente a quell'azione è sempre vera.
Un esempio dal mondo fisico: se azioni un interruttore della luce, la luce si accende oppure no. Se non si accende, quella è una risposta legittima: ti dice qualcosa sulla lampadina, o sul cablaggio, o sul salvavita, ecc. In ogni caso, ciò che torna indietro è un piccolo pezzo di informazione su come il mondo è cambiato a causa delle tue azioni su di esso. Non sei esposto al meccanismo completo di come funzionano elettricità, interruttori e lampadine, ma vedi il risultato. La luce si è accesa? E questo è sufficiente per iniziare a costruire un modello mentale di come azionare gli interruttori accende le luci.
Il terminale funziona più o meno allo stesso modo.
L'output dopo un comando bash è un piccolo riassunto di come lo stato del computer/container è cambiato dopo l'esecuzione del comando. Vedi stdout, stderr, codici di uscita, elenchi di file, ecc. Non vedi lo stato del kernel o l'albero dei processi o qualcosa di super dettagliato.
Ciò che vedi indietro è una proiezione a bassa dimensione di ciò che è successo in background, che è anche ciò che l'agente CLI utilizzerà per scegliere l'azione successiva verso il compito che sta cercando di raggiungere. E come con l'interruttore della luce, questo è un segnale sufficiente per costruire un modello mentale — o se preferisci, un modello del mondo — di come si comporta il sistema.
La parte migliore è che l'output del terminale, che ripeto è un riflesso di come lo stato del sistema è cambiato, è un segnale di supervisione, calcolato per te, a ogni singolo turno, gratis.
Figo!
Il problema è che l'RL standard per agenti (es. GRPO in SkyRL) spinge i gradienti solo attraverso i token di azione e ignora i token di output del terminale. Nonostante il fatto che l'output del terminale sia già nel contesto. Il modello ci presta attenzione, il forward pass calcola i logit per esso, eppure l'addestratore lo maschera dalla perdita.
Che spreco di buoni token 😊
Quindi, e se non lo facessimo?
Il modello è già condizionato su quei token. Produce già una distribuzione di probabilità su di essi. Aggiungere una perdita di cross-entropia non costa praticamente nulla.
E se lo facciamo... il modello ha motivo di imparare come si comporta effettivamente il terminale e può quindi costruire, al suo interno, un modello implicito del sistema su cui sta agendo. Per prevedere cosa restituirà ls, il modello deve tenere traccia di quali file ha appena creato, cosa vive dove, ecc.
Come ha detto Ilya:
Predire bene il token successivo significa comprendere la realtà sottostante che ha portato alla creazione di quel token.
Nel nostro contesto, ciò significherebbe: un agente che è bravo a prevedere gli output del terminale ha, in un senso piccolo ma reale, costruito un modello implicito del terminale.
Quindi come facciamo a far prevedere all'agente gli output del terminale?
ECHO: Impara un modello del mondo senza pagarlo
Il rollout di un agente terminale già intercala due flussi di token: i token di azione dell'agente e i token di osservazione dell'ambiente. La GRPO standard applica la perdita solo sui token di azione.
Questo è particolarmente dispendioso perché le ricompense del terminale sono sparse, ritardate e binarie. Nel nostro contesto con Qwen3-8B, per molti compiti meno del 15% dei rollout on-policy hanno successo. Ma le traiettorie fallite non sono dati falliti: contengono comunque elenchi di file, errori, log, stack trace, output grep e altre conseguenze dei comandi dell'agente.
Il nostro metodo è il modo più imbarazzantemente semplice per imparare da queste conseguenze 😊
Aggiungiamo una perdita di cross-entropia normalizzata per lunghezza sui token di osservazione dell'ambiente, insieme alla perdita GRPO standard sui token di azione. ECHO è l'obiettivo ibrido:
dove Azioni sono le posizioni dei token di azione dell'agente e Osservazioni sono le posizioni dei token di output del terminale.
Alcuni dettagli tecnici:
- ECHO impara on-policy. Invece di allenarsi su un insieme fisso di trascrizioni del terminale del modello base o di un insegnante, ECHO impara dalle risposte del terminale prodotte dal modello corrente durante l'RL. Man mano che l'agente migliora, esplora nuove parti dell'ambiente e riceve nuova supervisione da nuove transizioni azione → osservazione. Politiche migliori inducono feedback migliori; una migliore previsione del feedback fornisce alla politica priori di azione migliori. Un ciclo! Che divertimento, no?
- Nell'obiettivo congiunto, λ è importante. Se è molto piccolo, la perdita dell'ambiente non modella molto il modello. Se è troppo grande, la politica può ottimizzare per output prevedibili invece che per il progresso del compito. Bisogna bilanciare!
- I token target contano. Ci alleniamo sull'output effettivo del terminale, non sugli avvisi dell'harness. Gli avvisi sono facili da memorizzare; il segnale utile è la risposta effettiva del terminale — nomi di file, stack trace e messaggi di errore.
Quindi quanto costa?
Un lettore attento potrebbe chiedere:
il backward pass non è più costoso se si retropropagano i gradienti in più posizioni di token?
Quasi per niente. La parte costosa della backprop sono le moltiplicazioni di matrici attraverso i layer di attenzione e MLP, e queste vengono eseguite sulla stessa sequenza di token indipendentemente da quali posizioni di output contribuiscono alla perdita. I logit in ogni posizione di risposta sono già calcolati per GRPO. La maschera di azione e la maschera di osservazione raccolgono semplicemente diversi sottoinsiemi di essi per diversi termini di perdita.
Fermati un secondo: abbiamo aggiunto una perdita di modellazione del mondo, e il costo è praticamente ZERO! Nessun rollout extra, nessun modello insegnante e nessun forward pass aggiuntivo.
ECHO aiuta ad addestrare un agente CLI migliore?
Abbiamo eseguito il confronto più pulito possibile su compiti terminali multi-turno: stessi modelli, stessa ricetta GRPO, stessi compiti, stesso budget di rollout e turni, stesso numero di passi di addestramento. Ricompensa=1 se l'agente supera i casi di test dopo n turni, 0 se fallisce.
L'unica differenza è se i token di output del terminale entrano anche nella perdita.
Le curve rosa sono ECHO e quelle verde acqua sono GRPO. Attraverso le dimensioni del modello e le fette di valutazione, la risposta è la stessa: aggiungere la previsione dell'ambiente rende l'agente sostanzialmente migliore.
ECHO migliora costantemente le prestazioni su tutti e tre i set di validazione esclusi — le curve rosa si separano da quelle verde acqua all'inizio e generalmente rimangono sopra.
ECHO impara anche sostanzialmente più velocemente: ECHO eguaglia le prestazioni di GRPO a 500 passi su Terminal-Bench Lite ben 280 passi prima! Un aumento di velocità di 2,3x e continua a salire 😊
Questi risultati sostanziano la nostra intuizione alla base di ECHO. GRPO si allena solo con ricompense di risultato binarie e sparse. Per domini difficili come i compiti terminali in cui il tasso di successo è basso per modelli piccoli, questo si traduce in poco o nessun segnale per molti compiti.
ECHO rende l'addestramento molto più efficiente in termini di campioni trasformando le azioni fallite in supervisione. Anche quando un'azione non risolve il compito, la risposta del terminale insegna comunque al modello cosa ha causato quell'azione! E prevedere le conseguenze di azioni fallite può aiutare l'agente a sceglierne di migliori.
Se preferisci vedere i numeri attraverso le valutazioni, stessa storia in forma di tabella:
Guarda l'ultima riga in ogni blocco: ECHO. TerminalBench-2.0 pass@1 quasi raddoppia a 8B (2,7 → 5,2) e 14B (5,2 → 10,8). E, cosa importante, questo non deriva da dati extra, rollout, un modello insegnante o un verificatore diverso. Il rollout conteneva già la risposta del terminale. ECHO impara semplicemente da essa.
"Le prestazioni quasi raddoppiano a costo zero" è una frase che si legge molto raramente in tutta la carriera di ricerca 😊.
ECHO supera sostanzialmente le prestazioni di GRPO su tutti i benchmark e le dimensioni del modello, è molto più efficiente in termini di campioni e non costa praticamente nulla. Impari un modello del mondo mentre la tua politica migliora, il che la aiuta a migliorare più velocemente.
Gli scettici, tuttavia, potrebbero obiettare: impari davvero un modello del mondo?
Vediamo!
ECHO impara effettivamente le dinamiche del terminale?
Faremo un po' di hedging qui perché la folla della modellazione del mondo può diventare un po' intensa.
Non affermeremo che ECHO impari un modello del mondo nel senso più forte. Ma affermeremo che ECHO allena una politica i cui stati nascosti hanno assorbito qualcosa su come si comporta il terminale, e la cui capacità di prevedere cosa farà il terminale è migliorata in modo misurabile.
Se inverti la citazione di Ilya, ottieni una versione più falsificabile. Per il nostro contesto sarebbe qualcosa del genere:
Se il modello ha imparato le dinamiche del terminale, deve essere bravo a prevedere l'output del terminale.
Perché non c'è altro modo per assegnare costantemente un'alta probabilità ai token giusti. Un modello che è un miglior predittore è, in termini informatico-teorici, un miglior compressore del sistema che sta prevedendo.
Quindi la domanda diventa empirica: ECHO rende effettivamente il modello un miglior predittore dell'output del terminale?
Sì. Di molto.
Per rendere questo test pulito, utilizziamo un modello insegnante più forte, Qwen 3 32B (non utilizzato in nessuno dei nostri addestramenti), per generare traiettorie per ciascuno dei nostri set di validazione. Poi abbiamo valutato le nostre politiche di partenza, le politiche addestrate con GRPO e le politiche addestrate con ECHO e misurato quanto "sorpreso" fosse ogni modello dai token di output del terminale risultanti.
Lo schema è lo stesso su ogni pannello: GRPO modifica a malapena la cross-entropia dei token ambientali rispetto alla politica di partenza. ECHO la riduce drasticamente.
Quindi non diremo modello del mondo con la W maiuscola. Ma diremo questo:
ECHO produce politiche che sono misurabilmente migliori nel comprimere le dinamiche del terminale, su traiettorie che non hanno generato.
Che è la versione operativa dell'affermazione che il titolo sta facendo, e la versione che è pienamente difendibile.
Risultato sorprendente 1: ECHO riduce la dipendenza dall'SFT esperto
Una ricetta comune per l'RL degli agenti è: prima clona il comportamento di traiettorie esperte da un modello più forte, poi esegui l'RL. Questo è particolarmente comune per gli agenti terminali, dove la ricompensa è scarsa e lo spazio delle azioni è enorme.
Nel nostro contesto, la baseline SFT esperta è OpenThoughts-Agent-v1-SFT (OT-SFT): Qwen3-8B ottimizzato su dimostrazioni di agenti terminali generate da un insegnante GLM-4.6 più forte.
Quindi ci siamo chiesti: quanto di quel beneficio dell'SFT esperto può ECHO recuperare senza clonare il comportamento dell'insegnante?
ECHO può permetterti di saltare l'SFT esperto? Nel nostro contesto, per lo più sì!
Questa figura confronta tre esecuzioni: GRPO semplice sul modello base, ECHO sul modello base e GRPO sul modello SFT (SFT + GRPO). Rispetto al divario tra GRPO e SFT+GRPO (ad esempio, il guadagno che si ottiene partendo da SFT), ECHO recupera il 104% del guadagno su ITD, l'89% su Terminal Bench Lite (TBLite) e il 50% su TerminalBench-2.0 (TB2) pass@1.
Il risultato suggerisce che gran parte del valore dell'SFT esperto potrebbe derivare dall'insegnare al modello un prior di interazione, non solo un prior di strategia esperta. Le dimostrazioni esperte mostrano sia come comportarsi come un agente terminale — ispezionare file, eseguire test, seguire traceback, ecc. — sia cosa farebbe un esperto in stati specifici. ECHO non imita quelle scelte esperte. Invece, allena il modello a prevedere le conseguenze terminali delle proprie azioni, in modo che impari quali comandi espongono uno stato utile, quali errori sono diagnostici e quali token di output del terminale segnalano progresso. Strategie migliori possono quindi emergere attraverso l'interazione piuttosto che l'imitazione.
Questo aiuta anche a interpretare la suddivisione del benchmark. Su ITD e TBLite, ECHO eguaglia quasi l'SFT esperto, suggerendo che gran parte del vantaggio dell'SFT in quei casi deriva da un modello migliore dell'interazione terminale. Su TB2, ECHO recupera comunque un sostanziale 50% del divario senza dimostrazioni. Il divario rimanente è coerente con il fatto che TB2 è più difficile e distribuzionalmente più lontano dal set di addestramento.
Non tratteremmo questo come un tetto fisso: un addestramento più ampio o più lungo su compiti simili a TB2 dovrebbe migliorare ulteriormente l'agente.
Quindi il punto non è che l'SFT esperto sia obsoleto, ma che gran parte di ciò che l'SFT esperto compra potrebbe essere un modello migliore dell'interazione terminale, e quella parte può essere appresa direttamente dall'ambiente.
In conclusione: Il terminale è l'insegnante!
Risultato sorprendente 2: Scintille di auto-miglioramento senza ricompense
Finora ECHO è stato GRPO con una perdita ambientale ausiliaria. Il verificatore dice ancora all'agente se ha risolto il compito, e GRPO aggiorna il modello sui token di azione. Quindi configurazione RL standard, con un piccolo termine extra.
Ma se ECHO sta genuinamente insegnando alla politica qualcosa su come si comporta il terminale, allora forse non abbiamo affatto bisogno del segnale del verificatore.
Ci chiediamo: Cosa succede se spegniamo il verificatore? Nessuna ricompensa da cui imparare, solo questo:
Cioè il modello agisce, osserva, si aggiorna solo prevedendo gli output del terminale come conseguenza delle proprie azioni.
Questo sembra non dovrebbe migliorare le prestazioni del compito. Non c'è etichetta che dica quale azione è stata buona. Se la politica migliora, deve essere perché imparare a prevedere il terminale rimodella indirettamente i priori di azione della politica.
Quindi ci abbiamo provato!
Abbiamo preso il nostro checkpoint Qwen3-8B+ECHO più forte, rimosso completamente il termine GRPO e addestrato per altri 100 passi su compiti non visti utilizzando solo la perdita di cross-entropia dell'ambiente. La domanda era se il modello potesse migliorare su compiti OOD che non aveva mai visto prima, puramente interagendo con l'ambiente e prevedendo cosa tornava indietro.
Questa idea folle ha funzionato? Più o meno sì!
Su val100 (in-distribution): +3,8 pp. Su ITD: +5,2 pp. Su PyTerm (un set OOD escluso di compiti terminali pesanti in Python): +10,0 pp dopo il filtraggio per traiettorie pulite di tool-call.
L'addestramento solo ambientale migliora la politica quando l'output del terminale è una supervisione utile. Senza alcun segnale di ricompensa, il modello si allena solo per prevedere gli output causati dalle proprie azioni, quindi i guadagni dipendono dal fatto che quegli output espongano dinamiche utili.
Su val100, che è vicino al mix di addestramento, il guadagno è reale ma piccolo: +3,8 pp prima della saturazione. La politica ha già imparato la maggior parte delle dinamiche locali durante l'addestramento ECHO.
Su ITD, la politica di partenza più debole produce traiettorie rumorose — comandi non validi, errori di parsing, loop senza uscita. Filtrare per rollout puliti denoisa il segnale e dà +5,2 pp.
Le traiettorie pulite da sole, tuttavia, non sono sufficienti. Lo stesso filtraggio non ha migliorato costantemente TBLite, mentre PyTerm partiva da un tasso di successo simile ma migliorava con la stessa ricetta — suggerendo che il collo di bottiglia non è solo la forza della politica. La differenza fondamentale è quanto siano informative le osservazioni: i compiti Python danno un feedback denso legato all'azione — codice → traceback → correzione — mentre i compiti terminali più ampi rivelano lo stato più indirettamente attraverso file, configurazioni e setup multi-passo.
Crediamo che l'adattamento senza verificatore sia possibile: una volta che l'RL ha prodotto un modello decente che esplora, l'agente può talvolta continuare a migliorare solo dalle conseguenze — ma solo quando i suoi rollout sono puliti e il feedback del terminale è informativo. Questa È la parte sorprendente. Non che l'agente si auto-migliori perfettamente, ma che si auto-migliori affatto, da nient'altro che agire e prevedere cosa torna indietro.
Dove ci lascia questo
La lezione fondamentale di ECHO è semplice: i rollout degli agenti contengono più supervisione della sola ricompensa finale, e dovremmo usarla.
Ogni comando che un agente esegue produce una risposta del terminale — stdout, errori, trace, file, log, ecc. — e l'RL standard usa quei token solo come contesto per l'azione successiva. ECHO li trasforma in target di addestramento. Nessun modello insegnante, rollout extra o modello del mondo separato necessario. Smettiamo semplicemente di buttare via i token dell'ambiente che sono già nella trascrizione.
Quel piccolo cambiamento ha portato a tre risultati sorprendenti: prestazioni RL più forti, molta meno dipendenza dall'SFT esperto e, in alcuni contesti, auto-miglioramento senza verificatore dalla sola interazione con l'ambiente. Non pensiamo che questo significhi che le ricompense o le dimostrazioni siano obsolete. Le traiettorie esperte insegnano ancora strategia e i verificatori forniscono il segnale più pulito a livello di compito. Ma ECHO suggerisce che tra "imita l'esperto" e "aspetta la ricompensa scarsa", esiste una fonte densa e sottoutilizzata di supervisione: le conseguenze delle azioni dell'agente stesso.
L'idea più ampia è una continuazione della predizione ausiliaria che ha una lunga storia nell'RL, e lavori recenti hanno rivitalizzato gli obiettivi di modellazione del mondo per agenti LLM, ad esempio, Apprendimento dell'Agente tramite Esperienza Precoce usa il segnale azione-conseguenza come fase pre-RL, VAGEN aggiunge una ricompensa di modellazione del mondo per agenti VLM, RWML pre-allena sulla previsione dello stato successivo e CWM allena intermedio un modello di codice su traiettorie osservazione-azione. ECHO è la versione online, nel ciclo RL, specifica per CLI della stessa idea.
Quanto può spingersi questa idea?
Il passo successivo è rendere questo segnale ambientale più potente — e testare quanto generalizza. ECHO usa gli output grezzi del terminale perché sono già nel rollout, ma il target di apprendimento migliore potrebbe essere una rappresentazione più pulita e compatta: riassunti o viste dello stato rilevanti per il compito. Inoltre: Su quali osservazioni dovremmo allenarci? Quando dovremmo filtrare le traiettorie? Come dovremmo pesare la predizione dell'ambiente rispetto all'ottimizzazione della politica? La stessa idea può funzionare oltre i terminali: per agenti browser, sistemi multi-strumento, agenti di codifica a lungo orizzonte o assistenti rivolti all'utente dove follow-up, correzioni e preferenze sono un'altra forma di feedback di interazione?
La nostra scommessa è che ovunque un agente agisca e il mondo risponda in token, quei token di risposta — o rappresentazioni migliori di essi — dovrebbero far parte del segnale di apprendimento. ECHO è la versione più semplice di quell'idea che ci sia venuta in mente, e sospettiamo che qualche forma di previsione dei token ambientali sarà standard negli addestratori RL per agenti entro la fine del 2026.
Date un'occhiata al paper completo e al codice basato su SkyRL.
Provate ECHO e diteci quanto più velocemente si è addestrato il vostro agente.
Nota a piè di pagina: addestrare un modello del mondo del labirinto sul mio portatile... più o meno
Ricordate quando ho detto di aver "contribuito con un esperimento stupido sul labirinto"? Ecco l'esperimento stupido sul labirinto
La configurazione era una versione piccolissima di ECHO: un labirinto a griglia in un minuscolo terminale. L'agente (un trasformatore da 10M in un loop) emette una direzione — su, giù, sinistra, destra — e il terminale risponde con dove si trova l'agente rispetto ai suoi "vicini" (è fondamentalmente un problema di path finding in una griglia 2D) e la distanza dalla destinazione. Quindi il rollout assomiglia esattamente (per piccoli valori di esattamente) a un rollout di un agente CLI, solo molto più semplice 😊: azione→ risposta dell'ambiente → azione → risposta dell'ambiente, ecc.
Ho testato due condizioni su un trasformatore da 10M di parametri addestrato da zero: 1) addestramento solo sui token di azione 2) addestramento sui token di azione e sulla risposta del terminale (vicini, distanza, ecc.). Tutti addestrati su nuovi labirinti 6×6 / 7×7 / 8×8
Questa robetta del labirinto è un paper su Nature? No. Ma: penso che ci sia un punto che ho sempre sostenuto che continua a generalizzare.
Quasi ogni idea pulita ha un microcosmo: una versione ridotta che puoi eseguire su un portatile in una serata che ti dice se l'idea vale la pena di essere scalata.
Il labirinto non ha dimostrato che ECHO avrebbe funzionato. Mi ha dato abbastanza convinzione per inviare un messaggio a Vaish su Teams invece di dimenticare l'idea. Si è scoperto che Vaish stava orbitando attorno alla stessa idea indipendentemente e quando la sua prima esecuzione cluster è tornata con risultati, ne sono stato entusiasta e genuinamente sorpreso. Il labirinto ECHO aveva accennato che la direzione era giusta, ma non avrebbe potuto prevedere il raddoppio dei punteggi di TerminalBench, il recupero della maggior parte dell'SFT esperto o l'auto-miglioramento senza ricompense. Quelli erano i risultati di Vaish. "Risolvere più o meno un labirinto 6×6" e "raddoppiare su TerminalBench" sono stati epistemici molto diversi.
Ma il punto di questo addendum non è che il laptop sostituisca l'esperimento sul cluster. Il punto è che la maggior parte delle mie idee sono sbagliate e l'esperimento sul laptop (con l'aiuto di Claude Code e Codex) mi dice quali abbandonare prima che facciano perdere tempo ad altri. Ogni tanto un'idea sopravvive, e quando lo fa può forse guadagnarsi il diritto al tempo e alle GPU di un collaboratore.
ECHO è una di queste.
