Andrej Karpathy — ex direttore dell’AI di Tesla e co-fondatore di OpenAI — ha rilasciato su GitHub un progetto open source in Python chiamato autoresearch.
In pratica, tramite il codice di Karpathy l’agente AI si comporta come un ricercatore instancabile: prende il file Python che contiene le istruzioni per addestrare un modello AI (cioè le regole su come il modello impara dai dati, la sua architettura, i parametri di training), ci apporta una modifica, testa il risultato per cinque minuti e decide se tenerla o buttarla. Poi ripete il ciclo senza mai fermarsi, senza chiedere permesso. Passano le ore e trovi oltre cento esperimenti completati, ognuno documentato come commit su un branch Git.
Stiamo parlando di solo 630 righe di Python, tre file, un’unica metrica di valutazione. Un minimalismo pensato per permettere all’agente di avere sempre una visione completa del codice che sta modificando.
Il repository ha superato le 8.000 stelle su GitHub in pochi giorni — un segnale che la community tecnica ha colto subito la sostanza di quello che Karpathy ha definito, con il suo solito tono, qualcosa di “metà codice, metà fantascienza, con un pizzico di psicosi“.
Come funziona il loop di Autoresearch
Il cuore di autoresearch è un meccanismo chiamato ratchet: ogni esperimento viene tracciato tramite la metrica val_bpb (validation bits-per-byte), indipendente dalla dimensione del vocabolario. Se il valore scende rispetto alla baseline, la modifica viene salvata su branch e diventa il nuovo punto di partenza. Se peggiora, si esegue git reset e si torna indietro. Il modello, quindi, può solo migliorare — mai regredire.
Il progetto si struttura attorno a tre file con ruoli ben separati:
prepare.pygestisce il preprocessing dei dati e rimane intoccabile dall’agentetrain.pyè il playground vero e proprio, dove risiedono architettura GPT, ottimizzatore e training loopprogram.mdè il file Markdown scritto dallo sviluppatore con le istruzioni ad alto livello
In questa suddivisione c’è un cambio di ruolo: il ricercatore non scrive più Python, scrive istruzioni di testo. L’agente gestisce il ciclo tedioso di modifica-addestramento-valutazione che normalmente consuma ore di lavoro.
Su hardware a 8xH100, l’agente ha eseguito 276 esperimenti in più giorni, ottenendo 29 miglioramenti consolidati. La cosa più interessante è che i benefici rilevati su un modello di dimensione ridotta (depth 12) si sono trasferiti pulitamente a un modello più grande (depth 24) — il che suggerisce che l’agente stia trovando intuizioni architetturali genuine, non semplici artefatti del setup.
Un caso pratico viene da Tobi Lutke, CEO di Shopify. La sera ha applicato il framework a un modello interno da 0,8 miliardi di parametri, si è svegliato dopo otto ore con 37 esperimenti completati e un miglioramento del 19% nella validation score — superando il modello precedente da 1,6B parametri che era stato configurato manualmente. Le sue parole dopo l’esperimento: “Ho imparato più da quella notte che da mesi a seguire ricercatori ML.”
Dall’esecuzione alla progettazione del loop
Autoresearch va visto come un cambiamento strutturale nel ruolo di chi sviluppa e ricerca nel campo del machine learning. Se finora il lavoro del ricercatore ML consisteva nell’eseguire iterazioni — modificare parametri, lanciare run, interpretare risultati — il modello che emerge da questo progetto sposta il valore altrove. L’ingegnere del software non è più colui che aggiusta i parametri, ma solo chi progetta il processo che permette alla macchina di trovare l’ottimo globale.
Autoresearch funziona perché ha una regola semplice per capire se sta andando bene o male: un numero che deve scendere. Ogni esperimento produce un valore, e se quel valore è più basso del precedente, la modifica viene tenuta. Punto.
Questa chiarezza non è scontata. Prova a pensare al tuo lavoro: se dovessi affidare a un agente AI un compito ripetitivo — revisionare documenti, classificare richieste, generare report — come farebbe a sapere se ha fatto un buon lavoro? Ci vuole un criterio preciso e misurabile, non semplicemente “deve essere di qualità” o “deve sembrare corretto”. Ci vuole un numero, una soglia, qualcosa di oggettivo.
Nel caso di autoresearch, Karpathy risolve il problema usando una metrica chiamata val_bpb (validation bits-per-byte). In parole semplici, misura quanto bene il modello riesce a prevedere il testo. Più il numero è basso, più il modello è preciso. È un po’ come misurare gli errori di una previsione meteo: zero errori è impossibile, ma meno ne fai, meglio stai andando.
Il futuro è quello di sistemi che accumulano miglioramenti attraverso centinaia di generazioni, in modi che diventano progressivamente difficili da interpretare per un osservatore umano. Non è la singolarità, ma è qualcosa a cui vale la pena prestare attenzione.
Il repo del progetto autoresearch è disponibile qui.
