Infrastruttura per la ricerca sull’RSI: esecuzione e valutazione di agenti che si auto-migliorano

Un agente di ricerca modifica uno strumento di ricerca nel proprio codice. Risolve un’attività su cui prima falliva. Ora riesce a risolverne altre? La versione migliorata sa trovare un’altra modifica utile? Per capirlo occorre modificare programmi, eseguire esperimenti e confrontare ripetutamente i risultati. Beeuni fornisce un computer su cui gli agenti possono svolgere questo lavoro con il tuo codice, i tuoi strumenti e i tuoi script di valutazione.

L’auto-miglioramento ricorsivo, o RSI, studia se un sistema può migliorare sé stesso, compreso il modo in cui produce ulteriori miglioramenti. Negli esperimenti sugli agenti può significare modificare codice, istruzioni o strumenti, verificare il cambiamento e usare una versione riuscita per il tentativo successivo. Un esperimento su uno strumento di ricerca ci permetterà di spiegare concretamente come Beeuni aiuta durante tutto il processo.

Fornisci a Beeuni il codice e una domanda precisa

Collega il repository che contiene l’agente e i suoi test. Spiega a Beeuni come installarlo, quale comando avvia la valutazione e quale parte può modificare. Una buona prima domanda è circoscritta: lo strumento di ricerca può restituire la funzione utile senza inviare l’intero file al modello?

La domanda di ricerca determina cosa può modificare l’agente. Puoi studiare se istruzioni diverse migliorano la pianificazione, se una nuova ricerca evita letture inutili o se una diversa gestione della memoria aiuta nelle attività successive. Tieni distinguibili questi esperimenti. Modificare i pesi del modello richiede un altro esperimento, con il proprio metodo di addestramento e le relative risorse di calcolo.

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuni può leggere l’implementazione, eseguire i comandi di installazione e lanciare i test nel terminale. Se manca una dipendenza o un test si interrompe, l’agente può leggere l’errore e cercarne la causa. Tu puoi seguire il lavoro nella sessione e aprire i file prodotti.

Prova lo strumento originale prima di sostituirlo

Chiedi prima a Beeuni di eseguire l’agente senza modificarlo. Registra quali attività riescono, quali falliscono e gli errori. Se il tuo programma di test misura l’uso del modello, le chiamate agli strumenti o la durata, conserva anche questi dati. Avrai risultati concreti da confrontare con quelli della versione modificata.

Lascia poi che l’agente modifichi lo strumento di ricerca e ripeta lo stesso comando. Mantieni invariati modello, elenco delle attività e limiti. Chiedigli di spiegare ogni risultato cambiato, con il relativo log. Vale la pena esaminare un calo dei token consumati, ma anche un nuovo errore dovuto a risultati di ricerca più brevi che omettono codice importante.

Sono file che chiedi all’agente di produrre con i tuoi script. Beeuni non fornisce il benchmark di ricerca e non decide cosa conta come miglioramento. Tu fornisci le attività e il codice che assegna i punteggi; l’agente aiuta a eseguirli e a esaminare i risultati.

Scegli la modifica successiva in base agli errori

Supponiamo che la nuova versione funzioni bene con file piccoli, ma fallisca quando una funzione ne richiama una ausiliaria in un altro file. Chiedi a Beeuni di esaminare quel test, trovare il contesto mancante e proporre una modifica mirata. Potresti aggiungere ai risultati i nomi delle funzioni collegate, invece di tornare a restituire tutti i file per intero.

Esamina la modifica e il report prima di accettarli. Poi esegui i test su altre attività. Risolvere l’esempio che ha motivato la modifica dice meno che riuscire su attività a cui l’agente non ha adattato il codice. Tieni i test per il punteggio finale fuori dai file che l’agente può modificare.

Lo stesso metodo funziona con un agente che usa il browser. Fornisci a Beeuni un’applicazione di test e un’attività, per esempio trovare un ordine e modificarne la nota di consegna. Può usare il browser, controllare il risultato e conservare le prove di un errore. Ripristina i dati dell’applicazione prima di confrontare un’altra versione, così entrambe partono dallo stesso ordine.

Organizza esperimenti ripetuti con il tuo programma

Negli esperimenti ripetuti, il controllore è il programma che organizza i cicli. Sceglie una versione dell’agente, richiede una modifica, avvia i test e decide cosa provare dopo. Il candidato è la versione modificata sottoposta a test in quel ciclo. Il controllore può usare API o SDK TypeScript per avviare e consultare sessioni Beeuni. Le regole di selezione restano nel tuo codice di ricerca.

Ogni sessione ha il proprio ambiente di esecuzione. Puoi provare due implementazioni di uno strumento senza che sovrascrivano gli stessi file o le stesse dipendenze. Il programma nel computer deve partire dalla revisione di codice prevista. Se uno script carica il codice solo all’avvio, riavvialo dopo una modifica affinché il test usi davvero la nuova implementazione.

Parti da una piccola coda di esperimenti. Imposta nel controllore limiti ai tentativi, alle sessioni simultanee, alla durata e all’uso del modello. Quando raggiunge un limite, fai interrompere il lavoro interessato e verifica che i processi siano terminati. Queste regole stabiliscono quanta ricerca può fare l’esperimento prima di scegliere una versione.

Prova ogni versione in condizioni confrontabili

Un agente che potesse leggere le risposte corrette o modificare i test potrebbe alzare il punteggio senza eseguire meglio l’attività. Calcola il punteggio finale separatamente, tieni le risposte nascoste fuori dai file accessibili all’agente e impediscigli di modificare il codice di valutazione. Beeuni può eseguire i test di sviluppo e raccogliere i risultati; il tuo programma di valutazione può assegnare i punteggi separatamente. Negli esperimenti con il browser, ripristina i dati condivisi dell’applicazione tra le versioni: anche un nuovo computer vede i record lasciati nella stessa applicazione esterna.

Confronta attività riuscite, errori, durata, chiamate agli strumenti e uso del modello, quando il programma di test li registra. Mantieni confrontabili le attività, le impostazioni del modello e i limiti di esecuzione. Ripeti i risultati incerti. Una modifica può leggere meno token ma perdere una funzione ausiliaria, oppure superare più test con molte più chiamate al modello. Il report deve rendere visibile questo compromesso.

Conta anche il costo per trovare la modifica. Registra separatamente i tentativi usati per proporre e testare le versioni e il costo di esecuzione della versione scelta. Un agente può costare meno per attività ma aver richiesto una ricerca costosa per scoprirlo. Entrambe le misure contano nel valutare l’esperimento.

Conserva i dettagli necessari a spiegare un tentativo fallito

Un’attività fallita e un’API del modello non disponibile richiedono interventi diversi. Chiedi a Beeuni di conservare errori e log originali prima di riassumerli. I risultati possono distinguere risposte sbagliate, dipendenze mancanti, errori nelle richieste al modello e limiti di tempo esauriti. Decidi quali errori giustificano un altro tentativo, invece di ripeterli tutti senza segnalarlo finché il test non passa.

Salva le revisioni di codice originale e modificata, le istruzioni, i comandi di avvio, le dipendenze, le versioni dei test e del codice di valutazione e i risultati per attività. Registra da quale versione precedente deriva ogni modifica. Beeuni può scrivere questo resoconto accanto alla modifica e ai log, così potrai esaminare perché una versione è stata scelta o scartata.

Salva le modifiche e i report utili nel tuo repository o archivio prima di eliminare il computer dell’esperimento. Potrai risalire da un risultato al codice e al comando che lo hanno prodotto, anche per i tentativi scartati.

Verifica se migliorano anche i successivi tentativi di miglioramento

Dopo aver scelto una versione, valutala su attività che non hanno guidato le modifiche. Usala poi per cercare altri miglioramenti e confronta questi tentativi con quelli dell’agente originale. Trova più spesso modifiche utili, richiede meno tentativi o produce meno regressioni con lo stesso budget? Risolvere più attività è un risultato. Migliorare il processo che produce i miglioramenti successivi è l’ulteriore domanda che la ricerca RSI deve affrontare.

Lo studio sulla Darwin Gödel Machine esplora agenti che modificano il proprio codice e verificano i cambiamenti. Self-Refine studia la revisione di una risposta tramite feedback, senza ulteriore addestramento. La distinzione aiuta a definire l’esperimento: vuoi migliorare una risposta, il modo di lavorare dell’agente o la sua capacità di trovare il miglioramento successivo? Beeuni aiuta a modificare codice, eseguire comandi e analizzare i risultati. Tu progetti il metodo di ricerca. Se occorre addestrare un modello, consulta la guida per eseguire un fine-tuning con Beeuni.

Per provare la modifica allo strumento di ricerca, parti da un repository e da un comando di test funzionante. La guida Computer spiega come esaminare l’ambiente e l’output dei processi mentre Beeuni lavora.