Che cos'è RSI-Jev? Un ciclo auto-migliorante che costruisce modelli decisionali in stile Jev

RSI-Jev è un progetto di ricerca aperto di terze parti che costruisce modelli decisionali System One in stile Jev, e il modello di cui parla questa pagina è il suo rilascio 4B, RSI-Jev v6.0-VL, datato 2026-10-06. È realizzato da Shanghua Gao (@gasvn), con Sufian (@SufianTA) accreditato nei ringraziamenti del repository, e non è il Jev di TypeSafe né è affiliato a TypeSafe AI — la riga di licenza del progetto dice esattamente questo. L'idea alla base è abbastanza limitata da poter essere enunciata in una frase: poni una domanda tipizzata su un documento, una chat o un'immagine — sì/no, scegli-uno-di-k, valuta-secondo-una-rubrica — e un singolo forward pass restituisce una probabilità calibrata per ogni opzione. Non viene generato nulla, quindi non ci sono token di ragionamento da spendere, e nessuno viene speso. v6.0-VL non è il primo rilascio del progetto; è il settimo in dodici giorni, ed è la cosa più importante da capire al riguardo, perché l'informazione utile qui è nella forma della linea piuttosto che in un singolo checkpoint.

Una cosa va detta prima di qualsiasi numero, perché li data tutti. v6.0-VL è stato in testa alla fila per esattamente un giorno. Il 2026-10-07 alle 07:56 UTC — questa mattina — il progetto ha pubblicato RSI-Jev v6.1-VL, che è v6.0-VL mediato, peso 0,5 ciascuno, con un secondo fine-tune dello stesso Qwen3.5-4B-Base addestrato su altri dati, e che totalizza 50,98 sul kit Decision Index 0.3 del progetto contro il 46,23 di v6.0-VL su quello stesso kit. Non è stato addestrato nulla dopo la media. La sua calibrazione è peggiore di quella di v6.0-VL, e la sua stessa scheda lo dice. Quel rilascio è reale e attuale; questa pagina non lo riguarda. Ogni cifra riportata di seguito è letta dal record di rilascio di v6.0-VL, datato 2026-10-06, e laddove un conteggio si è spostato da allora — il conteggio dei rilasci, il conteggio degli esperimenti — questa pagina fornisce sia la cifra come era per v6.0-VL sia la cifra come si legge oggi.

Anche ciò che RSI-Jev non è merita di essere detto subito, perché due delle tre ovvie supposizioni sono sbagliate. Non è un prodotto ospitato che puoi chiamare oggi tramite un'API generica, e non è erogato da OrcaRouter — il nostro catalogo riporta l'id rsi-jev, nessun id shgao e nessuna model card per esso. L'unica cosa che abbiamo è il modello di cui questo progetto copia il contratto HTTP: il Jev commerciale di TypeSafe, che eroghiamo come typesafe/jev-1.13 sull'endpoint systemone. Di quei due, uno lo usi, e l'altro lo scarichi e lo servi da te. Tutto ciò che segue proviene dal repository del progetto, dalle release card e dalla documentazione di serving, consultati il 2026-10-07, e dove un numero è del progetto stesso anziché una misurazione esterna, questa pagina dice di chi è.

Cosa fa in realtà la cosa

Il progetto si descrive in una riga come "un sistema di ricerca che si auto-migliora ricorsivamente e che costruisce modelli System One in stile Jev", e gli artefatti che produce sono decisori anziché generatori. Gli si passa uno stato — un documento, una trascrizione di chat, una transazione e, nelle versioni con visione, fino a quattro immagini — e una o più domande tipizzate con criteri denominati. Restituisce, per ogni domanda, una probabilità per ogni opzione. Tre tipi di domanda coprono lo spazio, e sono quelli definiti dall'API di TypeSafe:

• il nuovo — un giudizio vero/falso, restituito come una singola probabilità, senza distribuzione e senza valore di confidenza, corrispondente esattamente alla forma della risposta di riferimento.

• scelta — scegli una tra un insieme di opzioni etichettate, restituita con la distribuzione di probabilità completa e una statistica di confidenza.

• punteggio — valuta secondo una rubrica ordinata, restituito come indice a base zero ponderato per probabilità nei livelli, oltre alla legenda e alla distribuzione.

Poiché non esiste una fase di generazione, non c'è una seconda chiamata al modello né campionamento. Una decisione su un documento che il modello ha già letto è per costruzione un'operazione a basso costo, e la stima fornita dal progetto stesso per quel costo — «circa 10 ms» — appartiene alla sua epoca 2B, non alla release attuale; i valori misurati per v6.0-VL sono riportati più avanti.

Due fatti sulla proprietà contano più di qualsiasi altra cosa in questa pagina. RSI-Jev non è opera di TypeSafe e TypeSafe non lo ha avallato. La riga della licenza, citata integralmente: "Codice: MIT. Pesi: Apache-2.0, seguendo il modello base; alcune fonti di addestramento per immagini sono non commerciali, elencate su ciascuna scheda del modello. Non affiliato a TypeSafe AI." E la relazione va in una sola direzione: il progetto copia deliberatamente il formato di trasmissione di Jev, e lo dichiara, perché un server compatibile è il punto. "Jev-style" è l'espressione del progetto stesso per il tipo di modello che costruisce. Il Jev di TypeSafe è un modello diverso, chiuso e commerciale, e i due non sono la stessa cosa sotto un nome più breve.

All'interno del modello attuale: una torre Qwen da 4B con tre uscite

RSI-Jev v6.0-VL è una torre Qwen3.5-4B-Base con la torre messa a punto e una testa decisionale addestrata in cima. Questa è l'intera architettura — non c'è alcuna miscela di esperti, nessun router e nessun secondo modello. Esegue l'intero modello base, ed è per questo che il suo numero di parametri è 4,69B e non qualcosa di più piccolo: 3,57B risiedono nei 32 strati del decoder, 0,64B negli embedding dei token, 0,33B nella torre visiva, 0,05B nella testa decisionale principale e 0,10B nelle due teste di uscita anticipata. Il checkpoint rilasciato è autonomo e di 9,7 GB in bf16.

Tre teste decisionali sono collegate, ai livelli 16, 20 e 32 della base, e sono il meccanismo alla base di tutto ciò per cui è nota la release attuale. Una quarta uscita al livello 12 è stata costruita, misurata e scartata — "L'uscita del livello 12 ha perso contro la cascata dal 16 in ogni confronto e non è nel pacchetto" — quindi tre vengono rilasciate e quattro no. Le uscite leggono una copia distaccata del loro livello, un dettaglio che il progetto ha scoperto a proprie spese: rimettere a punto le teste su un tronco le cui uscite erano state collegate durante l'addestramento non aveva recuperato l'accuratezza dei livelli profondi, quindi è stato il distaccarle a ripristinare la profondità.

Un numero, qui, è il modo più semplice per fraintendere il progetto. Tutto fino a v3.0 incluso era un modello 2B basato su Qwen3.5-2B-Base, e quella è la linea di discendenza, non il modello attuale. v4.0-VL era 2B, v5.0-VL ha ridotto un modello a 3B, e v6.0-VL è 4B. Una pagina che definisce il modello RSI-Jev attuale come 2B è indietro di tre release.

Il loop è il vero progetto

I modelli sono l'output; ciò che viene costruito è il processo. Il progetto afferma che «il loop che esegue la ricerca è la prossima versione di AutoScientists», il sistema auto-organizzante di team di agenti pubblicato dal laboratorio Zitnik di Harvard, e funziona come quella frase lascia intendere. Gli agenti AI propongono ipotesi, registrano le loro previsioni prima di spendere tempo GPU, eseguono gli esperimenti e mandano in pensione i propri campioni quando le prove lo indicano. Due conteggi lo rendono concreto. Alla data del 2026-10-07, il titolo in cima al repository annuncia otto rilasci in tredici giorni, da v1.0 a v6.1-VL; per il rilascio stesso di v6.0-VL del 2026-10-06 recitava sette rilasci in dodici giorni, ognuno addestrato, valutato e documentato dal loop. E il conteggio degli esperimenti, che era a 471 quando è stato pubblicato il rilascio di questa pagina, oggi recita 496 — ognuno documentato, fallimenti inclusi. Entrambi i conteggi appartengono al progetto, ed entrambi si muovono.

La disciplina è ciò che dà senso a quei numeri, e il progetto la elenca apertamente. I limiti inferiori nulli vengono misurati anziché presunti — bracci dimostrabilmente identici al controllo, verificati tramite l'identità dell'oggetto prima di qualsiasi tempo GPU, così che la differenza tra essi costituisce il rumore di fondo e una differenza inferiore a tale scarto non è un risultato. Le previsioni vengono registrate prima dell'esecuzione, così una versione che manca il proprio obiettivo viene rilasciata come un fallimento invece di essere silenziosamente ritagliata. Gli artefatti vengono verificati: un checkpoint viene ricaricato dal disco e rivalutato, e pubblicato solo se riproduce le previsioni per domanda della sua esecuzione di addestramento, cosa che entrambi i checkpoint v1.0 fanno a 1,0000. La contaminazione è "verificata anziché asserita". E i fallimenti vengono rilasciati, inclusi quelli che hanno ucciso il campione del progetto stesso.

Che cosa sia un contributo, nelle parole stesse del progetto dalla sua guida ai contributi: "Un contributo qui di solito è una misurazione, non una patch." Il registro pubblicato è conservato come una catena anziché come un'istantanea — "versions/ conserva una scheda per release, tutte, su main per sempre… Quella catena È il progetto" — ed è per questo che i numeri di una vecchia release possono essere verificati rispetto a ciò che il progetto dice di essi in seguito, e perché l'unica correzione discussa di seguito è visibile anziché silenziosa.

Cosa ha cambiato v6.0-VL: spende profondità invece di token

Il meccanismo della release attuale è un'impostazione chiamata effort, e controlla qualcosa di insolito: quante layer del modello può usare una richiesta. Poiché le head si trovano a tre profondità, una domanda facile può ricevere risposta al layer 16 e una domanda difficile può arrivare fino a tutti i 32. low si ferma al layer 16, medium a 20, high a 32, e auto risponde alla prima uscita la cui probabilità calibrata supera la soglia di quell'uscita. Latenza mediana per richiesta sul campione Decision Index, misurata su un H200 in bf16: 23 ms a low, 27 ms a medium, 40 ms a high, e 40 ms per il valore predefinito non impostato. Queste sono le misurazioni del progetto sul proprio hardware e non vanno combinate con i numeri GB10 della documentazione di serving, che si riferiscono a una macchina diversa.

Il comportamento misurato di auto è la parte interessante: sulla suite di quindici benchmark del progetto, il 20% delle domande si ferma allo strato 16, il 46% allo strato 20 e il 34% arriva fino a 32, con una media di 23,3 strati su 32. Una singola soglia fissa dà una media di 20,9, e fermarsi troppo tardi è ciò che una singola soglia ti offre. auto non è un compromesso sulla qualità, e vale la pena dirlo perché di solito è proprio questo che è un'impostazione adattiva: registra la riga migliore della suite fra tutte le impostazioni (0,771 contro 0,770 di quella predefinita), la riga migliore di MMLU-Pro (0,444 contro 0,440) e la migliore calibrazione finale (ECE 0,024 contro 0,036). L'unico punto in cui high vince è il set di hold-out, 0,702 contro auto a 0,696. Alcuni compiti peggiorano in modo misurabile con la profondità — BANKING77 di 0,035, il confronto di didascalie del New Yorker di 0,060 — ed è per questo che il livello di impegno è una scelta che spetta al chiamante anziché una regola che il server impone.

Il risultato che ha reso questo un rilascio anziché un esperimento si trova sul Decision Index 0.2.1 pubblico del progetto, dove il punteggio è passato da 38,38 per v5.0-VL a 46,24 per v6.0-VL in un solo rilascio. Nella classifica pubblica datata 2026-09-28, è il punteggio più alto tra i modelli 4B e qualsiasi cosa di dimensioni inferiori, e il 14º su 71 in totale; la voce successiva di quella dimensione è JPT-4B a 43,04. I rilasci precedenti su questa linea fanno parte della genealogia e non sono il modello attuale: v5.0-VL (2026-10-02) ha ridotto il modello ai primi 20 dei 32 layer e gli ha fatto dire "sconosciuto" quando una domanda non ha risposta; v4.0-VL (2026-10-01) è stato il primo a leggere le immagini; e v3.0 (2026-09-28) è il rilascio in cui l'apprendimento per rinforzo (RL) ha aiutato per la prima volta, tramite una ricompensa di ranking listwise — NDCG@5 su 16 candidati — che ha aumentato R@1 del reranking da 0,192 a 0,308 rispetto al suo genitore supervisionato, a un costo di 0,0028 sulla suite. È qui che inizia la storia di RL del progetto, e ormai è a tre rilasci di distanza.

I numeri, con le avvertenze che si portano dietro

Il valore principale del Decision Index 0.2.1 per v6.0-VL è 46,24, in un'esecuzione completa in cui tutte le 150.759 richieste della suite hanno ricevuto risposta: conoscenza 28,8, linguaggio 46,2, recupero 55,5, strumenti 65,8, arti 37,1. La suite di quindici benchmark registra 0,770, il set tenuto da parte 0,698, MMLU-Pro 0,440, e l'ECE finale 0,024 con auto. Due avvertenze devono stare nello stesso respiro di quelle cifre, perché senza di esse i numeri traggono in inganno.

Il primo è un taglio nella suite. Il task interno della suite open_jev_ood si sovrapponeva a 579 righe di addestramento, quindi il suo valore è stato gonfiato di una quantità sconosciuta; da v6.0-VL in poi il progetto riporta la suite senza di esso, a 0,770. Lo 0,764 di v5.0-VL lo includeva, e la scheda di v6.0-VL riformula quella release come 0,763 senza di esso. Le due cifre non sono comparabili, e se le si confronta bisogna usare lo 0,763 riformulato e dire che è quello che si sta facendo. Il set held-out, MMLU-Pro e BBH non presentano sovrapposizioni e non sono interessati. Un audit correlato ha trovato circa 1.000 elementi delle righe di test del kit Decision Index nei corpora di addestramento — ANLI 274, RouterBench-GSM8K 90, ARC 5 e testo di query BRIGHT/ToolRet senza etichette, circa lo 0,3% delle righe del kit — e un ricalcolo del punteggio senza di essi sposta l'indice di al massimo 0,04 sul campione del progetto. Questa è una correzione al record di v5.0-VL, pubblicata nella scheda di v6.0-VL, ed è la regola di contaminazione del progetto stesso a costargli un numero.

Il secondo è di chi è questo benchmark. Il Decision Index è la board pubblica di RSI-Jev stesso, non un verdetto di terze parti, e 46.24 è un punteggio su quella board. Non è confrontabile con nulla che TypeSafe abbia pubblicato, perché i due numeri non provengono dallo stesso harness, e nessuno ha eseguito un confronto diretto indipendente tra RSI-Jev e Jev 1.13. Ciò che si può dire è strutturale anziché numerico: uno è un modello commerciale ospitato sull'endpoint di un fornitore, e l'altro è un checkpoint che scarichi e servi da te.

Due ulteriori elementi di contesto fanno parte del set. Il progetto dichiara esplicitamente che «dieci dei quindici benchmark contribuiscono in qualche forma ai dati di addestramento, quindi nessuno di questi numeri è zero-shot»; l'insieme held-out è il confronto che viene tenuto fuori, e persino esso «è tenuto fuori dall'addestramento, non sigillato rispetto alla ricerca». E v6.0-VL ha eseguito 97 bracci sulla propria linea — 93 se si escludono i quattro audit dei dati — che è la scala di ricerca che ha prodotto un salto di 7,86 punti su quell'indice.

Parla il formato wire di Jev, con quattro differenze che un chiamante dovrebbe conoscere

La superficie di compatibilità è il motivo per cui questo progetto esiste nella forma in cui si presenta. La stessa forma di richiesta ({state, model, questions}), gli stessi tre tipi di domanda con le stesse forme dei criteri, le stesse forme delle risposte, lo stesso numero di domande per richiesta, da 1 a 64, gli stessi involucri di errore e la stessa statistica di confidenza — il picco, (K · p_max − 1) / (K − 1), limitato a 0..1. L'affermazione del progetto stesso su quella superficie è che "qualsiasi cosa scritta per Jev funziona con questo senza modifiche", e il server documenta ciò che è copiato e ciò che non lo è, il che è più utile dell'affermazione.

• Il prompt e il readout sono suoi. RSI-Jev è un modello base con una testa di readout addestrata, servito con l'encoder con cui è stato addestrato, perché usare il prompt del riferimento "porterebbe il modello fuori dalla sua distribuzione di addestramento". Il contratto wire è la superficie di compatibilità; il prompt no.

• Le chiavi delle opzioni sono visibili al modello. Il riferimento le nasconde, quindi rinominare una chiave non può dimostrabilmente modificare una risposta lì. Qui invece può, e il server lo segnala onestamente come option_keys_visible_to_model: true.

• I criteri devono essere stringhe o null. Un criterio strutturato — un oggetto — viene rifiutato con un 422, perché nessuna release è stata addestrata su di esso. Questo è l'unico punto in cui una richiesta che il riferimento accetta non verrà eseguita qui.

• Non si taglia nulla. Il serving accetta fino a 32.768 token di testo più il budget per le immagini, e una richiesta più lunga viene rifiutata con un 422 che lo dichiara esplicitamente, invece di essere troncata in silenzio. Il valore di 2.048 token che compare nelle schede più vecchie è la lunghezza sulla quale i modelli sono stati addestrati, non un limite di serving, e descrivere un troncamento silenzioso a 2.048 come comportamento attuale è sbagliato.

I conteggi delle opzioni differiscono con un ampio margine a favore del serving: fino a 5.120 opzioni per domanda (RSIJEV_MAX_ANSWERS), contro 160 in addestramento e 64 ammesse dal riferimento. Non citare 160 come limite massimo del serving. Una cosa è nuova nelle risposte di v6.0-VL anziché ereditata: ogni risposta indica quale livello ha risposto, in usage.depth, insieme alla confidenza calibrata, così che una decisione adattiva possa essere verificata a posteriori. Le immagini sono un'estensione che il riferimento non ha — da una a quattro per richiesta, come URL di dati base64, con lo stato che si riferisce a ciascuna tramite un marcatore letterale.

Dove un lettore può effettivamente eseguirlo e dove non può

RSI-Jev è un download. Il progetto include il proprio server, che parla quell'API compatibile con Jev, e il percorso documentato è un pip install dal repository seguito dal suo comando serve con l'alias del checkpoint e un'impostazione di effort. I pesi risiedono su Hugging Face sotto l'organizzazione shgao, rilasciati sotto Apache-2.0 seguendo il modello di base, con una questione aperta che il progetto stesso dichiara: cinque delle fonti di addestramento per immagini sono non commerciali o solo per ricerca, e "se i pesi addestrati su dati non commerciali ereditino quei termini non è stabilito". Il codice è MIT.

L'hardware non è il vincolo. Il progetto si sviluppa su un HP ZGX Nano, una macchina NVIDIA GB10 di cui attribuisce il merito a HP e NVIDIA, e il server gira su qualsiasi GPU CUDA, su Apple Silicon o su una CPU semplice — l'ultima delle quali la documentazione stima a 733 ms per una singola domanda sulla CPU Arm del GB10 stesso, quindi utilizzabile più che veloce.

Ciò che non fa è comparire in un catalogo generale di modelli, ed è qui che dobbiamo essere precisi riguardo alla nostra posizione. RSI-Jev non è su OrcaRouter e non esiste una scheda modello verso cui instradarlo. Ciò che serviamo è il Jev commerciale di TypeSafe, typesafe/jev-1.13, sull'endpoint dedicato systemone, raggiungibile con una POST a /v1/systemone anziché con la forma chat-completions di OpenAI — le stesse forme di richiesta e risposta che questo progetto implementa, dal modello di cui copia il contratto. Tutto il rapporto è questo: i due parlano lo stesso protocollo, noi ne serviamo uno e l'altro lo esegui tu. Se hai già una chiave con noi, la forma di chiamata di Jev 1.13 è una rotta di prima classe su un'unica API per oltre 200 modelli con 0% di markup (prezzo di listino del fornitore passato tal quale, quindi i tagli di prezzo dei vendor sono attivi qui lo stesso giorno) — il che conta per il confronto in un modo specifico. Una pagina come questa è economica da mettere in pratica se puoi prima provare il contratto commerciale e solo dopo decidere se eseguire da te un checkpoint aperto da 4B valga il lavoro operativo.

Come leggere RSI-Jev il 2026-10-07

Le debolezze che il progetto pubblica sono specifiche quanto i suoi risultati, e le date contano. Test esterni di v2.1 hanno rilevato che il modello propende per l'opzione più severa o costosa nelle scelte ordinate e nei punteggi delle rubriche, raramente sceglie "unknown" quando il documento non può rispondere, e risponde in modo incoerente a una domanda e alla sua negazione. Le release successive hanno indirizzato i dati verso il caso "unknown" — KoBBQ unknown-when-ambiguous è passato a 0,891 in v4.0-VL, 0,932 in v5.0-VL e 0,918 / 0,939 in v6.0-VL — e la scheda di v6.0-VL ammette candidamente che i miglioramenti sono venuti dai dati anziché dalla profondità, e che il 10% delle domande che andrebbe al layer 32 e si fermerebbe a 16 o 20 è la fascia in cui la policy di profondità sta ancora tirando a indovinare. Il reranking ha ancora molta strada da fare: l'ordine di retrieval di hippo-memory stesso segna 0,484 R@1 e resta davanti allo 0,308 raggiunto dal modello in v3.0, un valore che da allora il progetto non ha più sostenuto di aver colmato. L'evidenza RL è un singolo seed, e v3.0 "di per sé non ha un controllo SFT appaiato". I corpora di addestramento e i set di sviluppo della policy non sono pubblici, quindi le fasi non possono essere rieseguite dal solo repository, e il builder del corpus di reranking — circa 96 GB di memoria — non è stato rieseguito end to end.

Traction, rilevata lo stesso giorno: 73 stelle, 5 fork, 0 issue aperte, 7 release GitHub. Questi numeri cambiano ogni giorno, e un repository vecchio di tre settimane non è un progetto consolidato, qualunque sia la sua cadenza di rilascio. Il riassunto onesto è che RSI-Jev è uno degli sforzi di ricerca più leggibili in questo angolo del settore — una catena di release datate, misurate, a volte perdenti, con la ricerca pubblicata insieme ai punteggi — e uno dei meno verificati in modo indipendente, poiché quasi ogni numero su questa pagina proviene dal progetto stesso e nessun soggetto esterno ne ha fatto un benchmark rispetto al modello commerciale con cui è compatibile.

Quello a cui prestare attenzione non è la prossima release, perché con questa cadenza ce ne sarà una entro pochi giorni; è se qualcosa al di fuori del progetto inizia a misurare. Le due cose che cambierebbero il quadro sono un benchmark indipendente eseguito sui checkpoint pubblicati e un confronto tra modelli decisionali che metta sia il 4B open sia il modello hosted di TypeSafe attraverso un unico harness. Nessuna delle due esiste oggi. Finché non ne esisterà una, il modo utile di leggere un punteggio come 46.24 è come un'affermazione ben documentata da parte di un progetto che registra le proprie previsioni in anticipo e rilascia i rami che hanno fallito — il che è una traccia probatoria più solida della maggior parte, e comunque non un risultato di terze parti.