Rekursiv självförbättring, förklarad genom ett projekt som faktiskt gör det

"Rekursiv självförbättring" är en av de där fraserna som oftast används för att betyda en känsla. Definierad utan mystik är den snävare än så och mer intressant: ett system som föreslår sitt eget nästa experiment, kör det och behåller eller avvecklar resultatet enligt en i förväg fastställd regel, där resultaten matar nästa runda. Rekursionen är inte magi och den är inte obegränsad — det är en loop med en poängsättningsfunktion, och dess kvalitet avgörs helt av hur ärligt den poängsättningsfunktionen tillämpas. RSI-Jev, det öppna tredjepartsprojektet som bygger Jev-liknande System One-beslutsmodeller, är ett sällsynt fall där du kan läsa loopen i stället för att argumentera om den: varje hypotes, varje misslyckad arm och varje utgåva publiceras med sina siffror, och repot dateras dag för dag. Modellen som den här sidan använder som sitt genomarbetade exempel är RSI-Jev v6.0-VL, en typad beslutsmodell på 4B som publicerades 2026-10-06, vilket ligger inom den senaste veckan. Det är inte TypeSafe:s Jev och inte associerat med TypeSafe AI — projektets egen licensrad säger precis det, och det vi serverar på OrcaRouter är den andra, typesafe/jev-1.13, på vår systemone-slutpunkt.

Ett förtydligande innan ordet "självförbättrande" får någon verkan, följt av ett datum. Detta är inte en modell som skriver om sig själv utan gräns, och inget på den här sidan bör läsas så. Loopen i fråga skriver om ett recept: den föreslår en träningsändring, registrerar vad den förväntar sig att ändringen ska göra, spenderar GPU-tid och behåller sedan antingen ändringen eller antecknar varför den förlorade. Modellen är ett Qwen3.5-4B-Base-torn med tränade beslutshuvuden — en fast arkitektur tränad av ett fast träningsskript, där sökningen sker över data, mål och stadier. Loopen kör sina egna experiment och pensionerar sina egna mästare. Människor bestämmer vad som är värt att mäta. Och datumet: v6.0-VL publicerades 2026-10-06, och projektet har publicerat ytterligare en utgåva sedan dess — linjen rör sig ungefär dagligen, och siffrorna på den här sidan är de som hör till utgåvan som nämns här, daterade där de lästes. Det är värt att säga inledningsvis på en sida vars ämne är en loop som fortsätter att köra.

Vad termen betyder, sagt utan omsvep

Rensar man frasen till sin kärna finns det tre delar, och alla är vanliga. För det första ett sökrum: mängden av saker som skulle kunna ändras. För det andra en poängsättare: något som säger huruvida en ändring hjälpte. För det tredje en logg: vad som prövades, vad som hände och vad som kastades bort. Ett system utför rekursiv självförbättring när utdata från omgång N är indata till omgång N+1 i alla tre av dessa, utan att en människa på nytt härleder sökrummet eller på nytt beslutar om tröskelvärdet varje gång.

Det som de flesta texter i ämnet hoppar över är den andra delen, och det är där hela frågan bor. En loop med en svag poängsättare optimerar poängsättaren. Den kommer att producera en monotont stigande linje och ett system som har lärt sig formen på sitt eget prov. Det misslyckandet kräver varken illvilja eller en bugg – det är vad som händer som standard när samma tal både väljer och rapporterar. Så när du läser ett påstående om att något system är självförbättrande är den användbara frågan aldrig ”hur mycket bättre blev det”. Den är ”vem satte ribban, när, och kunde den flyttas efter att resultatet hade setts.”

De populära versionerna av detta begrepp – de som rankar för termen i dag – är mestadels framåtblickande: Wikipedias artikel beskriver ett system som skriver om sin egen kod i riktning mot en ”intelligensexplosion”, och den bredare bevakningen tenderar att handla om huruvida den tidslinjen är närmare eller längre bort än prognosen. Det är ett legitimt argument, och det går inte att besvara med de bevis som någon för närvarande har. Det som går att besvara är den mindre frågan, nämligen om en sluten slinga av det slag som beskrevs ovan kan byggas och fås att följa sina egna regler just nu. För det slår ett projekt med offentliga artefakter ett decennium av spekulation, och det är vad resten av sidan handlar om.

Slutet, inte bara iterativt: fem mekanismer

En loop är inte sluten bara för att den upprepas. Många automatiserade pipelines upprepas utan att någonsin slutas, eftersom en pipeline som kan justera sin tröskel efter att ha sett resultatet gör något kategoriskt annorlunda än en som inte kan. RSI-Jevs egna regler är ovanligt tydliga när det gäller skillnaden, och de kan läsas som definitioner snarare än som ett manifest. Fem av dem gör det mesta av arbetet.

Prediktioner registreras före körningen. En hypotes skrivs ned med vilken siffra den förväntar sig ska röra sig och hur mycket, innan GPU-tid spenderas. En version som missar sin egen ribba levereras som ett misslyckande i stället för att tyst göras om. Detta är mekanismen som hindrar loopen från att bli en maskin för att skriva efterhandsförklaringar, och den kostar något verkligt: registret innehåller poster vars enda innehåll är att någon hade fel i registret.

Nollgolv mäts, de antas inte. Teamet kör armar som bevisligen är identiska med kontrollen – verifierade genom objektidentitet innan någon GPU-tid – och spridningen mellan dessa armar är brusgolvet. En skillnad som är mindre än det golvet är inte ett resultat, hur det än ser ut. Projektets egen ribba speglar detta: i deras interna svit är tröskeln +0,006, med en standardavvikelse per frö på ett enskilt benchmark på 0,011–0,016, så skillnader under det på ett enskilt benchmark är inga fynd. Det mesta av bruset i den här branschen är uppmätt, inte statistiskt.

En hållout-uppsättning förbrukas så snart den har lästs. Varje utgåva läser hållout-uppsättningen en gång, så två utgåvor kan fortfarande jämföras på lika villkor — och eftersom läsningen förbrukar den, låser varje utgåva fast nästa utgåvas jämförelse. Projektets egen formulering är värd att bevara intakt: hållout-uppsättningen "hålls utanför träningen, inte förseglad från sökningen." Det är en kontroll av memorering, inte en garanti för nyhet. Och själva siffran för sviten har ett hål i sig som projektet publicerade: en intern uppgift överlappade flera hundra träningsrader, så från v6.0-VL och framåt rapporteras sviten utan den — 0.770 — och v5.0-VL:s tidigare 0.764 angavs i stället som 0.763 utan den. Det är den revideringen som är poängen. En siffra blåstes upp, orsaken hittades, och den äldre utgåvans kort rättades i stället för att lämnas orört.

Misslyckanden släpps, inklusive de som dödade projektets egen förkämpe. Repositoriets rubriksiffror, lästa 2026-10-08, hänger samman: åtta utgåvor på tretton dagar, och hundratals experiment dokumenterade med misslyckandena inkluderade. Ett negativt resultat behandlas som produkten. Bidragsguiden är rakt på sak om varför — den dyra delen av en sökning är inte att köra vinnaren, utan att köra förlorarna, så ett väl mätt negativt resultat utifrån tar bort en gren och är värt mer än ett litet positivt.

Releasekedjan är projektet. Ett kort per release, alla av dem, permanent på huvudgrenen. Varje kort bär siffrorna för sin egen release, så att en versions hastighet och kalibrering aldrig skriver över en annans. Projektet anger skälet direkt: den kedjan är det enda sättet att se om en självförbättrande loop förbättras. Allt annat – receptet, skripten, den fastnålade stacken – innehåller bara den aktuella releasen, eftersom den motsatta regeln skulle göra det omöjligt att avgöra vad som är aktuellt. En publicerad checkpoint bär sin egen kod så att gamla releaser förblir körbara utan gamla grenar.

Vad disciplinen kostar, och vad den ger

Två berättelser ur protokollet är den ärliga motvikten till ordet ”självförbättrande”, eftersom båda är fall där loopens egna regler gjorde arbetet både långsammare och bättre samtidigt.

Den första är buggen bakom v1.0. Att hitta den krävde sju registrerade negativa resultat. Var och en av de sju var en åtgärd på optimerarsidan som minskade en träningsinstabilitet utan att eliminera den, eftersom orsaken var ett precisionsmisstag långt ifrån optimeraren – och den slutliga rättningen var en enda rad. Inte ett av de sju var värt att publicera var för sig. Tillsammans är de det som gjorde att orsaken överhuvudtaget gick att hitta, och det är hela argumentet för att registrera och behålla negativa resultat: deras värde är gemensamt, inte individuellt.

Det andra är mindre smickrande, och projektet publicerar det ändå, i en fotnot. En tidig försöksarm misslyckades med exakt ett skyddsräcke – MMLU-Pro hamnade 0,026 under ribban mot en gräns på 0,020 – och loggades som avvisad. Körningsansvarige vidgade då gränsen till 0,030, med motiveringen att MMLU-Pro är ett skydd mot glömska snarare än ett mål, och försöksarmen bekräftades på fyra nya slumpfrön och blev nästa release. Det ursprungliga avslaget lämnades kvar i loggen, tillsammans med projektets egen kommentar att en ribba flyttas efter att man sett resultatet är en sådan sak som en läsare borde kunna komma på projektet med.

Den fotnoten är det mest användbara stycket i kodförrådet för alla som försöker bedöma den här typen av påståenden i verkligheten. En ribba som flyttades är inte bevis för ond tro — motiveringen som ges är försvarbar, och den utvidgade ribban måste sedan överleva fyra nya frön. Men en ribba som flyttades i tysthet är en loop som inte längre är sluten, och skillnaden mellan de två är helt och hållet huruvida det skrevs ned. Den allmänna regeln som projektet enades om efteråt är den som är värd att föra över till andra system: en nära-miss som misslyckas med exakt ett skyddsvillkor får en diagnos och en riktad reparation i stället för att kastas — och om reparationen misslyckas blir den en återvändsgränd med en anteckning.

Hur ofta loopen är fel: fjorton uppsättningar, två behölls

Här är siffran att hålla fast vid. Genom utgåvan som läser bilder räknar projektet fjorton uppsättningar för förstärkningsinlärning och 63 belönings­tränade armar. Två behölls.

Varje uppsättning bedömdes mot en övervakad kontroll som tränats på samma objekt under samma antal steg, vilket är jämförelsen som gör antalet meningsfullt – en RL-arm som slår en baslinje som den aldrig behövde matcha bevisar ingenting. De lärorika förlusterna, med projektets egna ord:

• RL för binär korrekthet — sannolikhetsutdatan kollapsade till 0 och 1. Att belöna handlingen att välja rätt snarare än ärligheten i de rapporterade oddsen driver en fördelning mot hörnen, och en beslutsmodell vars konfidens alltid är total är värdelös för det som beslutsmodeller är till för.

• Proper-score RL, rekonstruktionen av Laya-liknande målfunktion — fungerade bra vid 300 steg, divergerade vid 1 500. Stabilt medan det inte gjorde särskilt mycket, och instabilt precis när det började spela roll.

• RLCR — lika i noggrannhet, sämre rå kalibrering. Den köpte ingen förmåga och betalade för det i den enda egenskap som modellen finns för att tillhandahålla.

• Bandit RLCD, där endast det valda alternativets utfall avslöjas — inte bättre än övervakad träning på samma återkoppling. Projektet lade ner sitt eget förregistrerade test här: armen var tvungen att slå övervakad träning på minst två av fyra kalibreringsmått och vann ett.

Vinnaren, och anledningen till att den vann, är det mest överförbara fyndet på sidan. Det är en listvis belöning – rangordningskvalitet mätt över ordningen hos många separat poängsatta kandidater, i stället för att behandla var och en isolerat. Omrankningens recall vid den första positionen gick från 0,192 för den övervakade föräldern till 0,308, med vinster och förluster i ett parat test. Projektets förklaring är inte en historia om finjustering: ett träningsmål per objekt poängsätter varje kandidat för sig, och ingen enskild etikett kodar kvaliteten hos en ordning över kandidater. Där belöningen sa något som etiketterna inte kan uttrycka, slog RL den övervakade träningen på samma rader. Där den inte gjorde det, matchade den övervakade träningen den.

Det generaliserar till en regel om när den här typen av loop överhuvudtaget kan hitta något. Med en gold label till hands är den förväntade policy-gradient-uppdateringen lika med gradienten för en övervakad förlust — projektets egen formulering — så en "RL-arm" som poängsätts mot märkta beslut är egentligen en förlustdesignarm. Och förändringar på förlustnivå flyttade den interna sviten med högst 0,002, medan ny data flyttade den med 0,13. Läst tillsammans: loopens hävstång låg aldrig i målfunktionen. Den låg i vad som mättes och vad som matades in.

Vilket är det ärliga svaret på en fråga som en läsare med rätta ställer. RL-upplägg åberopas på andra håll som bevis om självförbättring i allmänhet; här är de bevis om en loop för beslutsuppgifter. Det listvisa resultatet är ett enda seed, och det säger projektet självt: den parade jämförelsen mellan RL och övervakad träning kördes på en annan förälder än den som släppet tillämpade den på, och det släppet "har ingen matchad övervakad kontroll." Ett fynd med det förbehållet är värt mer än ett utan, och det är därför sidan du läser inte generaliserar det.

Där människan sitter

Projektet är explicit, och det explicita är det intressanta: loopen kör sina egna experiment och pensionerar sina egna mästare, men den avgör inte vad som är värt att mäta, och den upptäcker inte på egen hand när ett tal är tekniskt sett sant och praktiskt sett vilseledande. Det gör människor.

Två av projektets egna regler finns eftersom någon satte sig emot. MMLU-Pro-skyddet utökades i stället för att låta en nära-miss kasseras. Seedkravet skalas nu med effektstorleken i stället för att lägga fyra seeds på varje skillnad — eftersom bekräftelseseeden, det enda tal som en arm inte valdes utifrån, är den bärande, och att lägga beräkningskraft på skillnader man redan kan se ger ingenting. En av utgåvorna i kedjan började som en vägran att stryka en arm som hade misslyckats med ett skydd. Projektet tackar de personer som skickade den återkopplingen vid namn, i tackavsnittet.

Så "självförbättrande" beskriver här mitten av loopen, inte hela loopen. Loopen är en sökning som körs utan att en människa vevar. Människan sitter fortfarande högst upp i loopen och väljer målet och längst ned och läser resultatet kritiskt — vilket är precis det arrangemang som hindrar loopen från att bli en maskin för att bekräfta sina egna preferenser. Varje redogörelse för rekursiv självförbättring som utelämnar den platsen beskriver ett annat system än detta, och förmodligen ett hypotetiskt sådant.

Vad projektets egna siffror inte visar

Disciplinen ovan är bara värd att beskriva om dess gränser anges i samma andetag, och RSI-Jevs protokoll anger dem för sin egen del.

• Det är ett projekt, en modellstorlek i taget, en seed. Den publicerade checkpointen är från en enda seed, fastställd i förväg som primär snarare än vald för att få bäst poäng. RL-beviset är en seed.

• Det handlar om beslutsuppgifter, inte generering: en ja/nej-fråga, en välj-en-av-k-fråga eller en fråga där man betygsätter enligt en bedömningsmall, över ett dokument, en chatt eller en bild, besvarad i ett enda framåtpass med en kalibrerad sannolikhet per alternativ. Ingenting genereras, så det finns inga resonemangstokens att göra av med. Det loopen visar här är att den kan förbättra en scorer av den formen.

• En del av det är inte reproducerbart enbart från repositoriet. Träningskorpusarna och policyutvecklingsuppsättningarna är inte offentliga, och projektet säger det rakt ut i release-kortet: "stegen kan inte köras om enbart från detta repository." En korpusbyggare behöver cirka 96 GB minne och kördes inte om från början till slut.

• Inte allt går att kontrollera över huvud taget. Den interna sviten hölls aldrig helt undanhållen. Av de femton riktmärkena bidrar tio med träningsdata i någon form, så ingen av dessa siffror är zero-shot — den undanhållna uppsättningen är den jämförelse som hålls undan, och det är den enda.

Och de externa delarna har sin egen ärrvävnad. En granskning efter en utgåva fann ungefär tusen poster av den offentliga benchmark-satsens testrader i träningskorpusarna – omkring 0,3 % av satsens rader, där det största enskilda bidraget var några hundra rader från en källa. Vid ompoängsättning utan dem förändras indexet med högst 0,04. Den korrigeringen publicerades i kortet för nästa utgåva i stället för att tyst tillämpas, enligt den regel som projektet formulerar som "ingen kontaminering, kontrollerad snarare än påstådd". Det är en regel som kostar dem ett tal, och det är den enda typen av regel som är värd att ha.

Var du faktiskt kan köra det — och var du inte kan

Inget här serveras av OrcaRouter. Vår katalog innehåller inget RSI-Jev-id och inget modellkort för det, och det kommer inte att finnas något förrän någon serverar det. RSI-Jev installeras från sitt eget repo och kör sin egen server, som talar Jev-API:t: du pekar en befintlig Jev-klient mot den och ändrar bas-URL:en. Det körs på Linux, Windows och macOS, på en CUDA-GPU, Apple Silicon eller vanlig CPU.

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.

Om det du vill är att sätta en beslutsmodell som den här bakom en applikation är routingfrågan åtskild från modellfrågan, och det är den delen som avgör om experimentet är värt att köra över huvud taget. OrcaRouter är ett API för 200+ modeller utan påslag — leverantörens listpris förs vidare oförändrat, så en leverantörs prisändring blir ditt pris samma dag — plus automatisk failover och ett routing-DSL för att komponera flera modeller till ett enda anrop. För en loop-modell som du ännu inte kan anropa via ett allmänt API spelar det roll på ett specifikt sätt: det innebär att de alternativa kandidater som du skulle jämföra den mot redan ligger bakom en enda nyckel, och jämförelsen är en konfigurationsändring snarare än en andra integration.

Delen värd att behålla

Anledningen till att skriva om rekursiv självförbättring genom ett projekt som detta, snarare än genom argumentet om huruvida det leder någonstans dramatiskt, är att loopens regler är den överförbara delen och spekulationen inte är det. Registrerade förutsägelser, uppmätta nollgolv, förbrukade undanhållna datamängder, publicerade misslyckanden, en oföränderlig releasekedja: inget av dessa är en egenskap hos en superintelligens. De är egenskaper hos ett labb som bestämde sig för att vara granskningsbart, och de är tillgängliga för alla team som bedriver automatiserad sökning i dag, i vilken skala som helst, på vilken modell som helst.

Läst på det sättet är det intressanta påståendet i RSI-Jevs protokoll inte poängen. Det är att loopens egen liggare säger att den hade fel långt oftare än den hade rätt — två behållna recept av fjorton uppsättningar, sju negativa resultat för att hitta en enradig bugg, en ribba som flyttades och skrevs ned — och att projektet publicerade liggaren. En ökning från 38,38 till 46,24 på ett offentligt index i en release är en kuriositet utan misslyckandena bredvid sig. Det är misslyckandena som gör att siffran betyder något.

Vilken är den ärliga hållningen till själva termen. Frågan är inte huruvida ett system kan förbättra sig självt. Det är huruvida förbättringen mäts av något som skulle kunna ha sagt nej. Där den separationen är verklig och nedskriven är loopen värd att läsa. Där den inte är det är en stigande linje en beskrivning av en poängsättare, inte av ett system som blir bättre – och ingen mängd rekursion åtgärdar det.