Auto-miglioramento ricorsivo, spiegato attraverso un progetto che lo mette davvero in pratica

"L'auto-miglioramento ricorsivo" è una di quelle frasi che vengono per lo più usate per indicare una sensazione. Definito senza mistica, è più ristretto di così e più interessante: un sistema che propone il proprio prossimo esperimento, lo esegue e mantiene o ritira il risultato secondo una regola fissata in anticipo, con i risultati che alimentano il turno successivo. La ricorsione non è magia e non è illimitata — è un ciclo con una funzione di punteggio, e la sua qualità è interamente determinata da quanto onestamente viene applicata quella funzione di punteggio. RSI-Jev, il progetto aperto di terze parti che costruisce modelli decisionali System One in stile Jev, è un raro caso in cui puoi leggere il ciclo invece di discuterne: ogni ipotesi, ogni braccio fallito e ogni rilascio viene pubblicato con i suoi numeri, e il repository è datato giorno per giorno. Il modello che questa pagina usa come esempio pratico è RSI-Jev v6.0-VL, un modello decisionale tipizzato da 4B pubblicato il 2026-10-06, che rientra nell'ultima settimana. Non è il Jev di TypeSafe e non è affiliato a TypeSafe AI — la riga di licenza del progetto lo dice esattamente, e quello che serviamo su OrcaRouter è l'altro, typesafe/jev-1.13, sul nostro endpoint systemone.

Un chiarimento prima che la parola "self-improving" faccia un qualche lavoro, seguito da una data. Questo non è un modello che riscrive se stesso senza limiti, e nulla su questa pagina va letto in quel modo. Il ciclo in questione riscrive una ricetta: propone una modifica all'addestramento, registra che cosa si aspetta che quella modifica faccia, spende tempo GPU e poi o mantiene la modifica o annota perché è andata perduta. Il modello è una torre Qwen3.5-4B-Base con teste decisionali addestrate — un'architettura fissa addestrata da uno script di addestramento fisso, con la ricerca che avviene su dati, obiettivi e fasi. Il ciclo esegue i propri esperimenti e manda in pensione i propri campioni. Le persone decidono che cosa vale la pena misurare. E la data: v6.0-VL è stato pubblicato il 2026-10-06, e da allora il progetto ha pubblicato un ulteriore rilascio — la linea avanza all'incirca ogni giorno, e le cifre di questa pagina sono quelle allegate al rilascio qui nominato, datate nel momento in cui sono state lette. Vale la pena dirlo subito, su una pagina il cui soggetto è un ciclo che continua a girare.

Che cosa significa il termine, detto senza mezzi termini

Riduci la frase all'osso e restano tre parti, tutte ordinarie. Primo, uno spazio di ricerca: l'insieme delle cose che potrebbero essere cambiate. Secondo, un valutatore: qualcosa che dice se un cambiamento ha aiutato. Terzo, un registro: ciò che è stato provato, ciò che è successo e ciò che è stato scartato. Un sistema sta facendo auto-miglioramento ricorsivo quando l'output del round N è l'input del round N+1 in tutte e tre queste parti, senza che un essere umano ricavi di nuovo lo spazio di ricerca o decida di nuovo la soglia ogni volta.

Ciò che gran parte degli scritti sull'argomento salta è la seconda parte, ed è lì che risiede l'intera questione. Un ciclo con un valutatore debole ottimizza il valutatore. Produrrà una linea monotonicamente crescente e un sistema che ha imparato la forma del proprio esame. Quel fallimento non richiede malizia né un bug: è ciò che accade per impostazione predefinita quando lo stesso numero serve sia a selezionare sia a riportare. Quindi, quando leggi un'affermazione secondo cui un sistema si auto-migliora, la domanda utile non è mai "quanto è migliorato". È "chi ha fissato l'asticella, quando, e poteva spostarsi dopo che il risultato era stato visto".

Le versioni popolari di questo concetto — quelle che oggi si posizionano per il termine — sono per lo più orientate al futuro: la voce di Wikipedia descrive un sistema che riscrive il proprio codice verso una "esplosione di intelligenza", e la trattazione più ampia tende a chiedersi se quella tempistica sia più vicina o più lontana di quanto previsto. È un argomento legittimo, e impossibile da confutare con le prove di cui chiunque disponga attualmente. Ciò a cui si può rispondere è la questione più piccola, ovvero se un ciclo chiuso del tipo descritto sopra possa essere costruito e mantenuto fedele alle proprie regole già adesso. Per questo, un progetto con artefatti pubblici vale più di un decennio di speculazioni, ed è di questo che si occupa il resto della pagina.

Chiuso, non solo iterativo: cinque meccanismi

Un ciclo non è chiuso perché si ripete. Molte pipeline automatizzate si ripetono senza mai essere chiuse, perché una pipeline che può regolare la propria soglia dopo aver visto il risultato fa qualcosa di categoricamente diverso da una che non può. Le regole di RSI-Jev sono insolitamente esplicite riguardo alla differenza, e possono essere lette come definizioni anziché come un manifesto. Cinque di esse fanno la maggior parte del lavoro.

Le previsioni vengono registrate prima dell'esecuzione. Un'ipotesi viene messa per iscritto con il numero che prevede di spostare e di quanto, prima che venga speso tempo GPU. Una versione che non raggiunge la propria soglia viene rilasciata come un fallimento invece di essere silenziosamente rimaneggiata. Questo è il meccanismo che impedisce al ciclo di diventare una macchina per scrivere spiegazioni a posteriori, e costa qualcosa di reale: il registro contiene voci il cui unico contenuto è che qualcuno ha avuto torto nero su bianco.

Le soglie di rumore nullo si misurano, non si presumono. Il team esegue bracci dimostrabilmente identici al controllo — verificati tramite identità dell'oggetto prima di qualsiasi tempo GPU — e la dispersione tra quei bracci è il livello di rumore di fondo. Una differenza inferiore a quella soglia non è un risultato, qualunque cosa sembri. L'asticella del progetto stesso lo riflette: sulla sua suite interna la soglia è +0,006, con una deviazione standard per seme su un singolo benchmark di 0,011–0,016, quindi le differenze su singolo benchmark al di sotto di tale valore non sono scoperte. La maggior parte del rumore in questo settore è misurata, non statistica.

Un set di hold-out si esaurisce nel momento in cui viene letto. Ogni rilascio legge il set di hold-out una volta, quindi due rilasci possono comunque essere confrontati su un piano di parità — e poiché leggerlo lo esaurisce, ogni rilascio congela il confronto del successivo. Vale la pena mantenere intatta la formulazione del progetto stesso: il set di hold-out "è tenuto fuori dall'addestramento, non sigillato rispetto alla ricerca". È un controllo sulla memorizzazione, non una garanzia di novità. E il valore stesso della suite ha una falla che il progetto ha pubblicato: un task interno si sovrapponeva a diverse centinaia di righe di addestramento, quindi da v6.0-VL in poi la suite viene riportata senza di esso — 0,770 — e il precedente 0,764 di v5.0-VL è stato riformulato come 0,763 senza di esso. Quella riformulazione è il punto. Un numero si stava gonfiando, la causa è stata trovata, e la scheda del rilascio più vecchio è stata corretta invece di essere lasciata com'era.

I fallimenti vengono pubblicati, compresi quelli che hanno ucciso il campione del progetto stesso. I numeri di punta del repository, letti il 2026-10-08, sono tutti d'un pezzo: otto rilasci in tredici giorni e centinaia di esperimenti documentati, fallimenti inclusi. Un risultato negativo è trattato come il prodotto. La guida per i contributori è schietta sul perché: la parte costosa di una ricerca non è eseguire il vincitore, ma eseguire i perdenti, quindi un negativo ben misurato che arriva dall'esterno elimina un ramo e vale più di un piccolo positivo.

La catena delle release è il progetto. Una scheda per release, tutte quante, sul branch main in modo permanente. Ogni scheda porta i numeri della propria release, così la velocità e la calibrazione di una versione non sovrascrivono mai quelle di un'altra. Il progetto dichiara direttamente la ragione: quella catena è l'unico modo per vedere se un ciclo di auto-miglioramento sta migliorando. Tutto il resto — la ricetta, gli script, lo stack bloccato — porta solo la release corrente, perché la regola opposta renderebbe impossibile capire cosa è corrente. Un checkpoint pubblicato porta con sé il proprio codice, così le vecchie release restano eseguibili senza vecchi branch.

Quanto costa la disciplina, e quanto rende

Due storie tratte dal registro sono l'onesto contrappeso alla parola «auto-migliorante», perché entrambe sono casi in cui le regole stesse del ciclo hanno reso il lavoro più lento e migliore allo stesso tempo.

Il primo è il bug dietro v1.0. Trovarlo ha richiesto sette risultati negativi registrati. Ognuno dei sette era una correzione lato ottimizzatore che riduceva un'instabilità di addestramento senza eliminarla, perché la causa era un errore di precisione da tutt'altra parte rispetto all'ottimizzatore — e la correzione finale fu una riga. Nessuno dei sette era degno di pubblicazione da solo. Insieme sono ciò che ha reso la causa individuabile, e questo è l'intero argomento a favore della registrazione e della conservazione dei risultati negativi: il loro valore è congiunto, non individuale.

Il secondo è meno lusinghiero e il progetto lo pubblica comunque, in una nota a piè di pagina. Un braccio iniziale ha fallito esattamente una guardia — MMLU-Pro si è attestato 0,026 sotto la soglia rispetto a un limite di 0,020 — ed è stato registrato come respinto. Il responsabile della run ha quindi ampliato il limite a 0,030, con la motivazione che MMLU-Pro è una guardia contro l'oblio piuttosto che un obiettivo, e il braccio è stato confermato su quattro nuovi seed ed è diventato la release successiva. Il rifiuto originale è stato lasciato nel log, con il commento del progetto stesso che una soglia spostata dopo aver visto il risultato è il genere di cosa in cui un lettore dovrebbe poter cogliere il progetto sul fatto.

Quella nota a piè di pagina è il paragrafo più utile del repository per chiunque cerchi di valutare questo tipo di affermazione nel mondo reale. Un'asticella che si è spostata non è prova di malafede — il ragionamento fornito è difendibile, e l'asticella ampliata ha poi dovuto sopravvivere a quattro nuovi seed. Ma un'asticella che si è spostata in silenzio è un ciclo che non è più chiuso, e la differenza tra i due sta interamente nel fatto che sia stato messo per iscritto. La regola generale su cui il progetto si è poi assestato è quella che vale la pena portare in altri sistemi: un quasi-incidente che fallisce esattamente una guardia riceve una diagnosi e una riparazione mirata invece di essere scartato — e se la riparazione fallisce, diventa un vicolo cieco con una registrazione.

Quanto spesso il loop è sbagliato: quattordici configurazioni, due mantenute

Ecco il numero da tenere a mente. Nella release che legge le immagini, il progetto conta quattordici configurazioni di reinforcement learning e 63 bracci addestrati con reward. Due sono stati mantenuti.

Ogni configurazione è stata valutata rispetto a un controllo supervisionato addestrato sugli stessi elementi per lo stesso numero di passi, ed è questo il confronto che rende significativo il conteggio — un braccio RL che batte un baseline che non ha mai dovuto eguagliare non dimostra nulla. Le perdite istruttive, nelle parole stesse del progetto:

• RL sulla correttezza binaria — l'output di probabilità è collassato a 0 e 1. Premiare l'atto di scegliere bene anziché l'onestà delle probabilità riportate spinge una distribuzione verso gli estremi, e un modello decisionale la cui confidenza è sempre totale è inutile per ciò per cui servono i modelli decisionali.

• Proper-score RL, la ricostruzione dell'obiettivo in stile Laya — andava bene a 300 passi, divergeva a 1.500. Stabile mentre non faceva granché, e instabile esattamente quando ha iniziato a contare.

• RLCR — a pari accuratezza, calibrazione grezza peggiore. Non ha acquisito alcuna capacità e l'ha pagata con l'unica proprietà che il modello esiste per fornire.

• Bandit RLCD, dove viene rivelato solo l'esito dell'opzione scelta — non meglio dell'addestramento supervisionato sugli stessi feedback. Il progetto ha qui ucciso il proprio test pre-registrato: il braccio doveva battere l'addestramento supervisionato su almeno due delle quattro metriche di calibrazione e ne ha vinta una.

Il vincitore, e la ragione per cui ha vinto, è il risultato più trasferibile della pagina. Si tratta di una ricompensa listwise — una qualità del ranking misurata sull'ordine di molti candidati valutati separatamente, anziché trattare ciascuno in isolamento. La recall di reranking alla prima posizione è passata da 0,192 per il parent supervisionato a 0,308, con vittorie e sconfitte su un test appaiato. La spiegazione del progetto non è una storia di tuning: un obiettivo di addestramento per elemento valuta ciascun candidato singolarmente, e nessuna singola etichetta codifica la qualità di un ordine tra i candidati. Dove la ricompensa diceva qualcosa che le etichette non possono esprimere, RL ha battuto l'addestramento supervisionato sulle stesse righe. Dove non lo faceva, l'addestramento supervisionato lo ha eguagliato.

Ciò si generalizza in una regola su quando questo tipo di ciclo possa trovare alcunché. Con un'etichetta gold in mano, l'aggiornamento atteso del policy gradient equivale al gradiente di una loss supervisionata — è la formulazione stessa del progetto — quindi un "braccio RL" valutato rispetto a decisioni etichettate è in realtà un braccio di progettazione della loss. E le modifiche a livello di loss hanno spostato la suite interna al massimo di 0,002, mentre nuovi dati l'hanno spostata di 0,13. Lette insieme: la leva del ciclo non è mai stata nell'obiettivo. Era in ciò che veniva misurato e in ciò che veniva immesso.

Il che è la risposta onesta a una domanda che un lettore fa bene a porsi. Le configurazioni RL sono citate altrove come prova dell'auto-miglioramento in generale; qui sono prova di un singolo ciclo su compiti decisionali. Il risultato listwise è un singolo seed, e il progetto lo dichiara: il confronto appaiato tra RL e supervisionato è stato eseguito su un parent diverso da quello a cui la release lo ha applicato, e quella release "non ha un controllo supervisionato appaiato". Un risultato con quell'avvertenza allegata vale più di uno senza, ed è il motivo per cui la pagina che stai leggendo non lo generalizza.

{{1}}Dove{{/1}} si trova {{2}}l'essere umano{{/2}}

Il progetto è esplicito, e l'esplicitazione è la parte interessante: il ciclo conduce i propri esperimenti e manda in pensione i propri campioni, ma non decide cosa valga la pena misurare, e non si accorge da solo quando un numero è tecnicamente vero e praticamente fuorviante. Sono le persone a farlo.

Due delle regole del progetto stesso esistono perché qualcuno ha obiettato. La salvaguardia MMLU-Pro è stata ampliata invece di lasciare scartare un near-miss. Il requisito del seed ora scala con l'ampiezza dell'effetto invece di spendere quattro seed per ogni differenza — perché il seed di conferma, l'unico numero in base al quale un braccio non è stato selezionato, è quello portante, e spendere calcolo su differenze che si vedono già non serve a nulla. Una delle release della catena è nata come rifiuto di eliminare un braccio che aveva fallito una salvaguardia. Il progetto cita per nome le persone che hanno inviato quel feedback, nei ringraziamenti.

Quindi «auto-migliorante» qui descrive la parte centrale del ciclo, non l'intero ciclo. Il ciclo è una ricerca che procede senza che un essere umano giri la manovella. L'umano resta comunque in cima al ciclo, a scegliere l'obiettivo, e in fondo, a leggere criticamente il risultato — ed è proprio questa la configurazione che impedisce al ciclo di diventare una macchina per confermare le proprie preferenze. Qualsiasi resoconto dell'auto-miglioramento ricorsivo che ometta quel posto sta descrivendo un sistema diverso da questo, e probabilmente un sistema ipotetico.

Ciò che i numeri del progetto stesso non mostrano

La disciplina di cui sopra merita di essere descritta solo se i suoi limiti vengono enunciati nello stesso respiro, e il resoconto di RSI-Jev li enuncia da sé.

• È un progetto, una dimensione del modello alla volta, un seed. Il checkpoint pubblicato è di un singolo seed, fissato in anticipo come primario anziché scelto per ottenere il punteggio migliore. L'evidenza RL è un seed.

• Si tratta di compiti decisionali, non di generazione: una domanda sì/no, scegli-uno-di-k o valuta-secondo-una-rubrica su un documento, una chat o un'immagine, a cui si risponde in un unico passaggio in avanti con una probabilità calibrata per opzione. Non viene generato nulla, quindi non ci sono token di ragionamento da spendere. Ciò che il ciclo dimostra qui è che può migliorare un valutatore di quella forma.

• Parte di esso non è riproducibile dal solo repository. I corpora di addestramento e i set di sviluppo delle policy non sono pubblici, e il progetto lo dichiara chiaramente nella scheda di rilascio: "le fasi non possono essere rieseguite dal solo repository". Un generatore di corpus richiede circa 96 GB di memoria e non è stato rieseguito dall'inizio alla fine.

• Non tutto è verificabile in alcun modo. La suite interna non è mai stata completamente tenuta fuori. Dei quindici benchmark, dieci contribuiscono in qualche forma ai dati di addestramento, quindi nessuno di quei numeri è zero-shot — il set held-out è il confronto che viene tenuto fuori, ed è l'unico.

E anche le parti esterne hanno il loro tessuto cicatriziale. Un audit dopo una release ha rilevato nei corpora di addestramento circa mille voci delle righe di test del kit di benchmark pubblico — circa lo 0,3% delle righe del kit, con il contributo singolo più grande pari a qualche centinaio di righe da un'unica fonte. Ricalcolato senza di esse, l'indice si sposta al massimo di 0,04. Quella correzione è stata pubblicata nella scheda della release successiva anziché applicata in silenzio, secondo la regola che il progetto enuncia come «nessuna contaminazione, verificata anziché asserita». È una regola che costa loro un numero, ed è l'unico tipo di regola che valga la pena avere.

Dove puoi effettivamente eseguirlo — e dove non puoi

Qui OrcaRouter non serve nulla. Il nostro catalogo non contiene alcun ID RSI-Jev né una model card per esso, e non ce ne sarà una finché qualcuno non lo servirà. RSI-Jev si installa dal proprio repository e gestisce il proprio server, che parla l'API Jev: punti un client Jev esistente verso di esso e cambi l'URL di base. Funziona su Linux, Windows e macOS, su GPU CUDA, Apple Silicon o una CPU normale.

The one model we do host is the other side of that contract. TypeSafe's Jev 1.13, which we serve as typesafe/jev-1.13, is the commercial decision model whose request and answer shapes RSI-Jev reproduces, and it is reached on our dedicated systemone endpoint rather than through the chat-completions shape. That is the whole relationship, and it is a structural one rather than a quality claim: one is a hosted commercial model on a vendor's endpoint, the other is a checkpoint you download and serve yourself. Nobody has run an independent head-to-head between them, and this page is not going to declare a winner from two different harnesses.

Se quello che vuoi è mettere un modello decisionale come questo dietro un'applicazione, la questione del routing è separata dalla questione del modello, ed è la parte che decide se vale la pena eseguire l'esperimento. OrcaRouter è un'unica API per oltre 200 modelli con 0% di ricarico — il prezzo di listino del provider viene passato tal quale, quindi una variazione di prezzo di un fornitore diventa il tuo prezzo lo stesso giorno — più failover automatico e un DSL di routing per comporre più modelli in un'unica chiamata. Per un loop model che non puoi ancora chiamare tramite un'API generale, questo conta in modo specifico: significa che i candidati alternativi con cui lo confronteresti sono già dietro un'unica chiave, e il confronto è un cambio di configurazione anziché una seconda integrazione.

La parte che vale la pena conservare

Il motivo per cui scrivere di auto-miglioramento ricorsivo attraverso un progetto come questo, invece che attraverso l'argomentazione se conduca da qualche parte di drammatico, è che le regole del ciclo sono la parte trasferibile e la speculazione no. Previsioni registrate, soglie nulle misurate, set di validazione esauriti, fallimenti pubblicati, una catena di rilascio immutabile: nessuna di queste è una proprietà di una superintelligenza. Sono proprietà di un laboratorio che ha deciso di essere verificabile, e sono a disposizione di qualsiasi team che oggi esegua ricerca automatizzata, a qualsiasi scala, su qualsiasi cosa.

Letta in quel modo, l'affermazione interessante nel record di RSI-Jev non è il punteggio. È che il registro del loop stesso dice che ha sbagliato molto più spesso di quanto abbia indovinato — due ricette mantenute su quattordici configurazioni, sette negativi per trovare un bug di una riga, una barra che si è spostata ed è stata annotata — e che il progetto ha pubblicato il registro. Un aumento da 38,38 a 46,24 su un indice pubblico in una sola release è una curiosità senza i fallimenti accanto. Sono i fallimenti a dare un senso al numero.

Qual è la posizione onesta sul termine stesso. La questione non è se un sistema possa migliorare se stesso. È se il miglioramento sia misurato da qualcosa che avrebbe potuto dire di no. Dove quella separazione è reale e messa per iscritto, il ciclo merita di essere letto. Dove non lo è, una linea in ascesa è la descrizione di un valutatore, non di un sistema che sta migliorando — e nessuna quantità di ricorsione lo risolve.