Vad är RSI-Jev? En självförbättrande loop som bygger beslutsmodeller i Jev-stil

RSI-Jev är ett öppet forskningsprojekt från tredje part som bygger Jev-liknande beslutsmodeller av System One-typ, och modellen som den här sidan handlar om är dess 4B-släpp, RSI-Jev v6.0-VL, daterat 2026-10-06. Den är skriven av Shanghua Gao (@gasvn), med Sufian (@SufianTA) krediterad i repositoriets tackavsnitt, och den är inte TypeSafe:s Jev och inte associerad med TypeSafe AI — projektets egen licensrad säger exakt det. Idén bakom den är tillräckligt snäv för att kunna uttryckas i en mening: ställ en fråga av en given typ om ett dokument, en chatt eller en bild — ja/nej, välj ett av k, betygsätt enligt bedömningsmall — och en framåtpassning returnerar en kalibrerad sannolikhet för varje alternativ. Ingenting genereras, så det finns inga resonemangstokens att spendera, och inga spenderas. v6.0-VL är inte projektets första släpp; det är dess sjunde på tolv dagar, vilket är det enskilt viktigaste att förstå om den, eftersom den användbara informationen här ligger i linjens form snarare än i någon enskild checkpoint.

En sak måste sägas innan några siffror nämns, eftersom den daterar dem alla. v6.0-VL var först i kön i exakt en dag. Den 7 oktober 2026 kl. 07:56 UTC – i morse – publicerade projektet RSI-Jev v6.1-VL, som är ett medelvärde av v6.0-VL, vikt 0,5 vardera, med en andra finjustering av samma Qwen3.5-4B-Base tränad på annan data, och som får 50,98 på projektets Decision Index 0.3-kit mot v6.0-VL:s 46,23 på samma kit. Inget tränades efter medelvärdet. Dess kalibrering är sämre än v6.0-VL:s, och dess eget kort säger det. Den utgåvan är verklig och aktuell; den här sidan handlar inte om den. Varje siffra nedan är hämtad från v6.0-VL:s släpppost, daterad den 6 oktober 2026, och där ett antal har ändrats sedan dess – släppantalet, experimentantalet – ger den här sidan både siffran så som den var för v6.0-VL och siffran så som den lyder i dag.

Vad RSI-Jev inte är är också värt att ta upp tidigt, eftersom två av de tre uppenbara antagandena är fel. Det är inte en hostad produkt som du kan anropa idag via ett allmänt API, och det tillhandahålls inte av OrcaRouter – vår katalog innehåller inget rsi-jev-id, inget shgao-id och inget modellkort för det. Det enda vi har är modellen vars HTTP-kontrakt det här projektet kopierar: TypeSafe:s kommersiella Jev, som vi tillhandahåller som typesafe/jev-1.13 på systemone-endpointen. En av dessa två anropar du, och den andra laddar du ner och serverar själv. Allt nedan kommer från projektets eget repository, releasekort och serveringsdokumentation, läst den 2026-10-07, och när en siffra är projektets egen i stället för en extern mätning, säger den här sidan vems den är.

Vad grejen faktiskt gör

Projektet beskriver sig självt på en rad som "ett rekursivt självförbättrande forskningssystem som bygger Jev-liknande System One-modeller", och artefakterna det producerar är beslutsfattare snarare än generatorer. Du ger det ett tillstånd – ett dokument, en chattutskrift, en transaktion, och i visionsutgåvorna upp till fyra bilder – och en eller flera typade frågor med namngivna kriterier. Det returnerar, för varje fråga, en sannolikhet för varje alternativ. Tre frågetyper täcker utrymmet, och de är de som TypeSafe-API:et definierar:

• den nya — en sann/falsk bedömning, returnerad som en enda sannolikhet, utan fördelning och utan konfidensvärde, som exakt matchar referensens svarsform.

• val — välj ett av en uppsättning märkta alternativ, som returneras med hela sannolikhetsfördelningen och ett konfidensmått.

• poäng — betygsätt enligt en ordnad bedömningsmatris, returneras som ett sannolikhetsviktat nollbaserat index i nivåerna, plus teckenförklaringen och fördelningen.

Eftersom det inte finns något genereringssteg finns det inget andra modellanrop och ingen sampling. Ett beslut om ett dokument som modellen redan har läst är en billig operation av konstruktion, och projektets egen uppgift om den kostnaden – "cirka 10 ms" – tillhör dess 2B-era, inte den aktuella utgåvan; de uppmätta siffrorna för v6.0-VL anges längre ner.

Två fakta om ägandeförhållanden spelar större roll än något annat på den här sidan. RSI-Jev är inte TypeSafe:s arbete och TypeSafe har inte ställt sig bakom det. Licensraden, citerad i sin helhet: "Kod: MIT. Vikter: Apache-2.0, i enlighet med basmodellen; vissa källor för bildträning är icke-kommersiella och anges på varje modellkort. Inte associerad med TypeSafe AI." Och relationen är enkelriktad: projektet kopierar medvetet Jevs wire-format och säger det, eftersom en kompatibel server är själva poängen. "Jev-style" är projektets egen fras för den typ av modell det bygger. TypeSafe:s Jev är en annan, sluten, kommersiell modell, och de två är inte samma sak under ett kortare namn.

I den aktuella modellen: ett 4B Qwen-torn med tre utgångar

RSI-Jev v6.0-VL är ett Qwen3.5-4B-Base-torn där tornet är finjusterat och ett tränat beslutshuvud ligger ovanpå. Det är hela arkitekturen – det finns ingen mixture of experts, ingen router och ingen andra modell. Den kör hela basmodellen, vilket är anledningen till att dess parameterantal är 4,69 B och inte något mindre: 3,57 B ligger i de 32 decoderlagren, 0,64 B i tokeninbäddningarna, 0,33 B i visionstornet, 0,05 B i det huvudsakliga beslutshuvudet och 0,10 B i de två early-exit-huvudena. Den släppta checkpunkten är fristående och 9,7 GB i bf16.

Tre beslutshuvuden är fästa, vid lager 16, 20 och 32 i basen, och de är mekanismen bakom allt som den aktuella utgåvan är känd för. En fjärde utgång vid lager 12 byggdes, mättes och droppades – "Utgången vid lager 12 förlorade mot kaskaden från 16 i varje jämförelse och finns inte i paketet" – så tre levereras och fyra gör det inte. Utgångarna läser en frånkopplad kopia av sitt lager, en detalj som projektet upptäckte den hårda vägen: att trimma om huvuden på en stam vars utgångar hade varit anslutna under träningen hade inte återställt de djupa lagrens noggrannhet, så att koppla bort dem är det som återställde djupet.

Ett nummer här är det lättaste sättet att misstolka projektet. Allt fram till och med v3.0 var en 2B-modell på Qwen3.5-2B-Base, och det är härstamningen, inte den nuvarande modellen. v4.0-VL var 2B, v5.0-VL skalade ner en modell till 3B, och v6.0-VL är 4B. En sida som kallar den nuvarande RSI-Jev-modellen för 2B ligger tre utgåvor efter.

Loopen är det faktiska projektet

Modellerna är resultatet; det som byggs är processen. Projektet säger att ”loopen som driver forskningen är nästa version av AutoScientists”, det självorganiserande agentteam-system som publicerats av Zitnik-labbet vid Harvard, och det fungerar så som den meningen antyder. AI-agenter föreslår hypoteser, registrerar sina förutsägelser innan de spenderar GPU-tid, kör experimenten och pensionerar sina egna champion-modeller när bevisen säger till. Två räknemått gör det konkret. Läst den 2026-10-07 lyder repositoriets rubrik: åtta släpp på tretton dagar, från v1.0 till v6.1-VL; för v6.0-VL:s eget släpp den 2026-10-06 stod det sju släpp på tolv dagar, vart och ett tränat, utvärderat och dokumenterat av loopen. Och antalet experiment, som låg på 471 när den här sidans släpp publicerades, står i dag på 496 — vart och ett dokumenterat, inklusive misslyckanden. Båda räknemåtten är projektets egna, och båda ändras.

Disciplinen är det som får dessa siffror att betyda något, och projektet listar den rakt på sak. Nollgolv mäts snarare än antas — armar som bevisligen är identiska med kontrollen, verifierade genom objektidentitet innan någon GPU-tid, så att spridningen mellan dem är brusgolvet och en skillnad som är mindre än den spridningen är inte ett resultat. Förutsägelser registreras före körningen, så en version som missar sin egen ribba levereras som ett misslyckande i stället för att i tysthet klippas om. Artefakter verifieras: en checkpoint laddas om från disk och poängsätts på nytt, och publiceras endast om den reproducerar sin träningskörnings per-fråga-förutsägelser, vilket båda v1.0-checkpointarna gör vid 1.0000. Kontaminering "kontrolleras snarare än påstås". Och misslyckanden levereras, inklusive de som dödade projektets egen mästare.

Vad ett bidrag är, med projektets egna ord från dess bidragsguide: "Ett bidrag här är vanligtvis en mätning, inte en patch." Det utgivna underlaget bevaras som en kedja snarare än som en ögonblicksbild – "versions/ behåller ett kort per utgåva, alla, på main för alltid… Den kedjan ÄR projektet" – vilket är varför en gammal utgåvas siffror kan kontrolleras mot vad projektet säger om dem senare, och varför den enda rättelse som diskuteras nedan är synlig i stället för tyst.

Vad v6.0-VL ändrade: den spenderar djup i stället för tokens

Den aktuella versionens mekanism är en inställning som kallas ansträngning, och den styr något ovanligt: hur många lager av modellen en begäran får använda. Eftersom huvudena sitter på tre djup kan en enkel fråga besvaras vid lager 16 och en svår fråga kan köra alla 32. låg stannar vid lager 16, medel vid 20, hög vid 32, och auto svarar vid den första utgången vars kalibrerade sannolikhet överstiger den utgångens tröskel. Medianlatens per begäran i Decision Index-urvalet, mätt på en H200 i bf16: 23 ms vid låg, 27 ms vid medel, 40 ms vid hög, och 40 ms för standardvärdet när inget är inställt. Detta är projektets egna mätningar på dess egen hårdvara och de bör inte blandas samman med serveringsdokumentationens GB10-siffror, som är en annan maskin.

Det uppmätta beteendet för auto är det intressanta: i projektets svit med femton benchmarks stannar 20 % av frågorna vid lager 16, 46 % vid lager 20 och 34 % fortsätter till 32, vilket ger ett genomsnitt på 23,3 av 32 lager. En enda fast tröskel ger i genomsnitt 20,9, och överstoppning är vad en enda tröskel ger dig. auto är ingen kvalitetskompromiss, vilket är värt att påpeka eftersom det är vad en adaptiv inställning brukar vara: den redovisar den bästa svitraden av alla inställningar (0,771 mot 0,770 för standardinställningen), den bästa MMLU-Pro-raden (0,444 mot 0,440) och den bästa slutliga kalibreringen (ECE 0,024 mot 0,036). Det enda stället high vinner är den separata testmängden, 0,702 mot autos 0,696. Vissa uppgifter blir mätbart sämre med djupet – BANKING77 med 0,035, New Yorker-bildtextmatchning med 0,060 – vilket är anledningen till att ansträngningsnivån är ett val som anroparen gör i stället för en regel som servern påtvingar.

Resultatet som gjorde detta till en release snarare än ett experiment finns på projektets offentliga Decision Index 0.2.1, där poängen gick från 38,38 för v5.0-VL till 46,24 för v6.0-VL i en och samma release. På den offentliga resultattavlan daterad 2026-09-28 är det den högsta poängen bland 4B-modeller och allt mindre, och 14:e av 71 totalt; nästa post i den storleken är JPT-4B på 43,04. De tidigare releaserna på den här linjen är härstamning och inte den aktuella modellen: v5.0-VL (2026-10-02) skar ned modellen till de första 20 av 32 lager och fick den att säga "unknown" när en fråga inte har något svar; v4.0-VL (2026-10-01) var den första som läser bilder; och v3.0 (2026-09-28) är releasen där förstärkningsinlärning först hjälpte, via en listvis rangordningsbelöning — NDCG@5 över 16 kandidater — som lyfte omrangordningen R@1 från 0,192 till 0,308 mot dess övervakade förälder till en kostnad av 0,0028 på sviten. Det är där projektets RL-historia börjar, och det är tre releaser tillbaka nu.

Siffrorna, med de förbehåll som följer med dem.

Decision Index 0.2.1-huvudresultatet för v6.0-VL är 46,24, vid en fullständig körning där alla 150 759 förfrågningar i sviten besvarades: kunskap 28,8, språk 46,2, hämtning 55,5, verktyg 65,8, konst 37,1. Sviten med femton benchmarks visar 0,770, den undanhållna mängden 0,698, MMLU-Pro 0,440 och slutlig ECE 0,024 med automatik. Två förbehåll måste sägas i samma andetag som dessa siffror, för utan dem är siffrorna vilseledande.

Det första är en borttagning i sviten. Den interna svituppgiften open_jev_ood överlappade 579 träningsrader, så dess resultat var uppblåst med en okänd mängd; från och med v6.0-VL rapporterar projektet sviten utan den, vid 0,770. v5.0-VLs 0,764 var med den, och v6.0-VLs kort anger den utgåvan på nytt som 0,763 utan den. De två siffrorna är inte jämförbara, och om du ändå jämför dem måste du använda den på nytt angivna 0,763 och säga att det är vad du gör. Den held-out-uppsättningen, MMLU-Pro och BBH, har ingen överlappning och påverkas inte. En relaterad granskning fann omkring 1 000 poster bland Decision Index-kitets testrader i träningskorpusarna — ANLI 274, RouterBench-GSM8K 90, ARC 5 och BRIGHT/ToolRet-frågetext utan etiketter, ungefär 0,3 % av kitets rader — och att poängsätta om utan dem flyttar indexet med högst 0,04 i projektets urval. Det är en rättelse av v5.0-VLs resultat, publicerad i v6.0-VLs kort, och det är projektets egen kontamineringsregel som kostar det en siffra.

Det andra är vems benchmark detta är. Decision Index är RSI-Jevs egen offentliga resultattavla, inte ett tredjepartsutlåtande, och 46,24 är en poäng på den tavlan. Den är inte jämförbar med något som TypeSafe har publicerat, eftersom de två siffrorna inte kommer från samma testramverk, och ingen har genomfört en oberoende direkt jämförelse mellan RSI-Jev och Jev 1.13. Det som kan sägas är strukturellt snarare än numeriskt: den ena är en hostad kommersiell modell på en leverantörs endpoint, och den andra är en checkpoint som du laddar ner och serverar själv.

Ytterligare två kontextbitar hör till uppsättningen. Projektet är tydligt med att "tio av de femton benchmarkarna bidrar med träningsdata i någon form, så inget av dessa tal är zero-shot"; den undanhållna uppsättningen är den jämförelse som hålls undan, och inte ens den "hålls undan från träningen, inte förseglad från sökningen". Och v6.0-VL körde 97 armar på sin egen linje – 93 om de fyra datagranskningarna lämnas utanför – vilket är den skala av sökning som gav ett hopp på 7,86 punkter i det indexet.

Det talar Jevs wire-format, med fyra skillnader som en anropare bör känna till

Kompatibilitetsytan är anledningen till att detta projekt finns i den form det har. Samma förfrågningsform ({state, model, questions}), samma tre frågetyper med samma kriterieformer, samma svarsformer, samma 1 till 64 frågor per förfrågan, samma felkuvert och samma konfidensstatistik – toppvärdet, (K · p_max − 1) / (K − 1), begränsat till 0..1. Projektets eget påstående om den ytan är att "allt som skrivits mot Jev fungerar mot detta utan ändringar", och servern dokumenterar vad som kopieras och vad som inte gör det, vilket är mer användbart än påståendet.

• Prompten och utläsningen är dess egna. RSI-Jev är en basmodell med ett tränat utläsningshuvud, serverad med den encoder den tränades med, eftersom användandet av referensens prompt "skulle föra modellen bort från dess träningsfördelning". Trådkontraktet är kompatibilitetsytan; prompten är det inte.

• Alternativnycklar är synliga för modellen. Referensen döljer dem, så att byta namn på en nyckel kan bevisligen inte ändra ett svar där. Här kan det göra det, och servern rapporterar detta ärligt som option_keys_visible_to_model: true.

• Kriterier måste vara strängar eller null. Ett strukturerat kriterium – ett objekt – avvisas med 422, eftersom ingen utgåva har tränats på ett sådant. Det här är den enda platsen där en begäran som referensen accepterar inte kommer att köras här.

• Inget klipps bort.Serveringen tar upp till 32 768 texttokens plus bildbudgeten, och en längre begäran avvisas med en 422 som säger det i stället för att tyst trunkeras. Siffran 2 048 token som förekommer i de äldre korten är den längd som modellerna var tränade på, inte en serveringsgräns, och att beskriva en tyst trunkering till 2 048 som nuvarande beteende är fel.

Antalet alternativ skiljer sig kraftigt till fördel för serving: upp till 5 120 alternativ per fråga (RSIJEV_MAX_ANSWERS), mot 160 i träning och 64 som referensen tillåter. Ange inte 160 som taket för serving. En sak är ny i v6.0-VL:s svar snarare än ärvd: varje svar rapporterar vilket lager som svarade, i usage.depth, tillsammans med den kalibrerade konfidensen, så att ett adaptivt beslut kan granskas i efterhand. Bilder är en utökning som referensen inte har — en till fyra per begäran, som base64-data-URL:er, där tillståndet refererar till var och en med en bokstavlig markör.

Där en läsare faktiskt kan köra det, och där de inte kan.

RSI-Jev är en nedladdning. Projektet levererar sin egen server, som talar det Jev-kompatibla API:et, och den dokumenterade vägen är en pip-installation från repositoryt följd av dess serve-kommando med checkpoint-aliaset och en effort-inställning. Vikterna ligger på Hugging Face under organisationen shgao, släppta under Apache-2.0 i linje med basmodellen, med en öppen fråga som projektet självt anger: fem av bildträningskällorna är icke-kommersiella eller endast för forskning, och "huruvida vikter tränade på icke-kommersiell data ärver dessa villkor är inte avgjort." Koden är MIT.

Hårdvaran är inte begränsningen. Projektet utvecklas på en HP ZGX Nano, en NVIDIA GB10-maskin som det tackar HP och NVIDIA för, och servern körs på vilken CUDA-GPU som helst, på Apple Silicon eller på en vanlig CPU – det sista alternativet uppskattar dokumentationen till 733 ms för en enda fråga på GB10:s egen Arm-CPU, alltså användbar snarare än snabb.

Det den inte gör är att dyka upp i en allmän modellkatalog, och det är här vi måste vara precisa om vår egen position. RSI-Jev finns inte på OrcaRouter och det finns inget modellkort för den att dirigera till. Det vi tillhandahåller är TypeSafe:s kommersiella Jev, typesafe/jev-1.13, på den dedikerade systemone-endpointen, nådd med en POST till /v1/systemone snarare än OpenAI:s chat-completions-form — samma förfrågnings- och svarsformer som detta projekt implementerar, från modellen vars kontrakt den kopierar. Det är hela relationen: de två talar samma protokoll, vi tillhandahåller en av dem och du kör den andra själv. Om du redan har en nyckel hos oss är anropsformen för Jev 1.13 en förstklassig rutt på ett API för 200+ modeller med 0 % påslag (leverantörens listpris förs vidare, så leverantörens prissänkningar slår igenom här samma dag) — vilket spelar roll för jämförelsen på ett specifikt sätt. En sida som den här är billig att agera på om du kan prova det kommersiella kontraktet först och först därefter avgöra om det är värt det operativa arbetet att köra en öppen 4B-checkpoint själv.

Hur man läser RSI-Jev den 2026-10-07

De svagheter som projektet publicerar är lika specifika som dess resultat, och datumen spelar roll. Extern testning av v2.1 fann att modellen tenderar mot det allvarligare eller dyrare alternativet vid ordnade val och kriteriepoäng, sällan väljer "okänt" när dokumentet inte kan svara, och besvarar en fråga och dess negation inkonsekvent. Senare utgåvor riktade data mot "okänt"-fallet — KoBBQ okänt-när-tvetydigt nådde 0.891 vid v4.0-VL, 0.932 vid v5.0-VL och 0.918 / 0.939 vid v6.0-VL — och v6.0-VL-kortet är uppriktigt om att vinsterna kom från data snarare än från djup, och att de 10 % av frågorna som skulle gå till lager 32 och stanna vid 16 eller 20 är där djuppolicyn fortfarande gissar. Omrankning har längre kvar att gå: hippo-memorys egen hämtningsordning får 0.484 R@1 och ligger fortfarande före de 0.308 som modellen nådde vid v3.0, en siffra som projektet inte har hävdat sig ha stängt sedan dess. RL-beviset är ett enda seed, och v3.0 "har själv ingen matchad SFT-kontroll." Träningskorpusarna och policyns utvecklingsuppsättningar är inte offentliga, så stegen kan inte köras om enbart från arkivet, och omrankningskorpusbyggaren — cirka 96 GB minne — kördes inte om från början till slut.

Genomslag, avläst samma dag: 73 stjärnor, 5 forks, 0 öppna ärenden, 7 GitHub-releaser. De ändras dagligen, och ett tre veckor gammalt repo är inte ett etablerat projekt, oavsett dess utgivningstakt. Den ärliga sammanfattningen är att RSI-Jev är en av de mer läsbara forskningsinsatserna i den här delen av fältet — en kedja av daterade, uppmätta, ibland förlorande releaser med sökningen publicerad vid sidan av poängen — och en av de minst självständigt verifierade, eftersom nästan varje siffra på den här sidan är dess egen och ingen utomstående part har benchmarkat det mot den kommersiella modell som det är kompatibelt med.

Det man bör hålla ögonen på är inte nästa release, för i den här takten kommer en sådan inom några dagar; det är om något utanför projektet börjar mäta. De två saker som skulle förändra bilden är en oberoende benchmarkkörning på de publicerade checkpoints och en jämförelse av beslutsmodeller som kör både den öppna 4B:n och TypeSafes hostade modell genom en och samma testbänk. Inget av dem finns i dag. Fram till dess att något av dem gör det är det användbara sättet att läsa en poäng som 46.24 att betrakta den som ett väldokumenterat påstående från ett projekt som registrerar sina förutsägelser i förväg och släpper de armar som misslyckades — vilket är en starkare beviskedja än de flesta, och fortfarande inte ett tredjepartsresultat.