Een gegenereerde titelkaart met als kop 'Recursieve zelfverbetering, uitgelegd' en als ondertitel 'Een gesloten lus is een gescoorde lus, en de scoring is de hele kwestie', boven een rij van drie afgeronde kaarten met de tekst 'Voorspellingen geregistreerd vóór de run', 'Null-ondergrenzen gemeten, niet aangenomen' en 'Mislukkingen worden uitgeleverd, inclusief die van de kampioen'; een voettekst luidt 'Uitgewerkt voorbeeld: RSI-Jev v6.0-VL, gepubliceerd op 2026-10-06; het eigen record van het project, gelezen op 2026-10-08.', met minimale platte lijniconen en het OrcaRouter-logo samengesteld in de rechteronderhoek.
Guides & Insights

Recursieve zelfverbetering, uitgelegd aan de hand van een project dat het daadwerkelijk doet

Auteur

Magnus Corvin

Publicatiedatum

Nieuwste modellen · 20Bekijk alle modellen →
Benchmarks: Artificial Analysis · dagelijks bijgewerkt
Terug naar alle berichten

"Recursieve zelfverbetering" is een van die uitdrukkingen die meestal worden gebruikt om een gevoel aan te duiden. Zonder mystiek gedefinieerd is het smaller dan dat en interessanter: een systeem dat zijn eigen volgende experiment voorstelt, het uitvoert, en het resultaat behoudt of buiten gebruik stelt volgens een vooraf vastgelegde regel, waarbij de resultaten de volgende ronde voeden. De recursie is geen magie en is niet onbegrensd — het is een lus met een scoringsfunctie, en de kwaliteit ervan wordt volledig bepaald door hoe eerlijk die scoringsfunctie wordt toegepast. RSI-Jev, het open project van derden dat Jev-achtige System One-beslissingsmodellen bouwt, is een zeldzaam geval waarin je de lus kunt lezen in plaats van erover te discussiëren: elke hypothese, elke mislukte arm en elke release wordt met de bijbehorende cijfers gepubliceerd, en de repository wordt dag per dag gedateerd. Het model dat deze pagina als uitgewerkt voorbeeld gebruikt is RSI-Jev v6.0-VL, een 4B getypeerd beslissingsmodel dat op 2026-10-06 is gepubliceerd, wat binnen de laatste week valt. Het is niet de Jev van TypeSafe en niet gelieerd aan TypeSafe AI — de eigen licentieregel van het project zegt precies dat, en wat wij bij OrcaRouter serveren is de andere, typesafe/jev-1.13, op ons systemone-endpoint.

Eén verduidelijking voordat het woord "zelfverbeterend" enig werk doet, gevolgd door één datum. Dit is geen model dat zichzelf onbeperkt herschrijft, en niets op deze pagina moet zo worden gelezen. De lus in kwestie herschrijft een recept: hij stelt een trainingswijziging voor, registreert wat hij verwacht dat die wijziging doet, besteedt GPU-tijd, en behoudt de wijziging vervolgens of noteert waarom ze verloor. Het model is een Qwen3.5-4B-Base-toren met getrainde beslissingskoppen — een vaste architectuur die door een vast trainingsscript wordt getraind, waarbij de zoektocht plaatsvindt over data, doelstellingen en stadia. De lus voert zijn eigen experimenten uit en zet zijn eigen kampioenen uit dienst. Mensen bepalen wat het meten waard is. En de datum: v6.0-VL is gepubliceerd op 2026-10-06, en het project heeft sindsdien nog een release gepubliceerd — de lijn beweegt ongeveer dagelijks, en de cijfers op deze pagina zijn de cijfers die bij de hier genoemde release horen, gedateerd waar ze zijn gelezen. Dat is de moeite waard om vooraf te zeggen op een pagina waarvan het onderwerp een lus is die maar blijft draaien.

Wat de term betekent, platweg gesteld

Haal de frase uit elkaar en er zijn drie onderdelen, alle drie heel gewoon. Ten eerste, een zoekruimte: de verzameling dingen die veranderd zouden kunnen worden. Ten tweede, een scorer: iets dat aangeeft of een verandering hielp. Ten derde, een verslag: wat is geprobeerd, wat er gebeurde, en wat is weggegooid. Een systeem doet aan recursieve zelfverbetering wanneer de output van ronde N de input is voor ronde N+1 in alle drie die onderdelen, zonder dat een mens telkens de zoekruimte opnieuw afleidt of de drempel opnieuw bepaalt.

Wat de meeste teksten over dit onderwerp overslaan, is het tweede deel, en daar zit de hele vraag. Een lus met een zwakke scorer optimaliseert de scorer. Die levert een monotoon stijgende lijn op en een systeem dat de vorm van zijn eigen examen heeft geleerd. Dat falen vereist geen kwaadwilligheid of een bug — het is wat standaard gebeurt wanneer hetzelfde getal zowel selecteert als rapporteert. Dus wanneer je een bewering leest dat een of ander systeem zichzelf verbetert, is de nuttige vraag nooit "hoeveel beter is het geworden." Het is "wie heeft de lat gelegd, wanneer, en kon die verschuiven nadat het resultaat was gezien."

De populaire versies van dit concept — de versies die vandaag op de term ranken — zijn grotendeels toekomstgericht: Wikipedia's lemma beschrijft een systeem dat zijn eigen code herschrijft richting een "intelligentie-explosie", en de bredere berichtgeving gaat er meestal over of die tijdlijn dichterbij of verder weg ligt dan voorspeld. Dat is een legitiem argument, en het is onbeantwoordbaar met het bewijs dat iemand momenteel heeft. Wat wel beantwoordbaar is, is de kleinere vraag: of een gesloten lus zoals hierboven beschreven nu gebouwd en aan zijn eigen regels gehouden kan worden. Daarvoor verslaat één project met openbare artefacten een decennium aan speculatie, en daar gaat de rest van deze pagina over.

Gesloten, niet louter iteratief: vijf mechanismen

Een lus is niet gesloten omdat hij zich herhaalt. Tal van geautomatiseerde pijplijnen herhalen zich zonder ooit gesloten te zijn, omdat een pijplijn die zijn drempel kan aanpassen nadat hij het resultaat heeft gezien, iets categorisch anders doet dan een die dat niet kan. De eigen regels van RSI-Jev zijn ongewoon expliciet over het verschil, en ze kunnen worden gelezen als definities in plaats van als een manifest. Vijf ervan doen het meeste werk.

Voorspellingen worden geregistreerd voordat de run plaatsvindt. Een hypothese wordt opgeschreven met het getal dat ze verwacht te laten bewegen en met hoeveel, voordat er GPU-tijd aan wordt besteed. Een versie die haar eigen lat niet haalt, wordt als een mislukking opgeleverd in plaats van stilletjes opnieuw bijgesteld. Dit is het mechanisme dat voorkomt dat de lus een machine wordt om post-hocverklaringen te schrijven, en het kost iets wezenlijks: het verslag bevat vermeldingen waarvan de enige inhoud is dat iemand zwart op wit ongelijk had.

Nulvloeren worden gemeten, niet aangenomen. Het team draait armen die aantoonbaar identiek zijn aan de controle — geverifieerd via objectidentiteit vóór enige GPU-tijd — en de spreiding tussen die armen is de ruisvloer. Een verschil kleiner dan die vloer is geen resultaat, hoe het er ook uitziet. De lat die het project zelf aanlegt, weerspiegelt dit: op de interne suite is de drempel +0,006, met een standaardafwijking per seed op één benchmark van 0,011–0,016, dus verschillen op één enkele benchmark die daaronder liggen, zijn geen bevindingen. De meeste ruis in dit vakgebied wordt gemeten, niet statistisch.

Een held-outset is opgebruikt zodra die wordt gelezen. Elke release leest de held-outset één keer, dus twee releases kunnen nog steeds op gelijke voet worden vergeleken — en omdat het lezen ervan de set opgebruikt, bevriest elke release de vergelijking van de volgende. De eigen formulering van het project is het waard om intact te houden: de held-outset "wordt buiten de training gehouden, niet afgesloten van de zoektocht." Het is een controle op memorisatie, geen garantie van nieuwheid. En de suite-score zelf bevat een gat dat het project heeft gepubliceerd: een interne taak overlapte met enkele honderden trainingsrijen, dus vanaf v6.0-VL wordt de suite zonder die taak gerapporteerd — 0,770 — en de eerdere 0,764 van v5.0-VL werd zonder die taak opnieuw vermeld als 0,763. Die herziene vermelding is waar het om gaat. Een getal was opgeblazen, de oorzaak werd gevonden, en de kaart van de oudere release werd gecorrigeerd in plaats van ongemoeid gelaten.

Mislukkingen worden verscheept, inclusief de gevallen die de eigen kampioen van het project hebben geveld. De headline-cijfers van de repository, gelezen op 2026-10-08, vormen één geheel: acht releases in dertien dagen, en honderden experimenten die zijn opgeschreven met de mislukkingen inbegrepen. Een negatief resultaat wordt als het product behandeld. De handleiding voor bijdragers is bot over waarom — het dure deel van een zoektocht is niet het uitvoeren van de winnaar, maar het uitvoeren van de verliezers, dus een goed gemeten negatief van buitenaf verwijdert een tak en is meer waard dan een kleine positieve uitkomst.

De release-keten is het project. Één kaart per release, allemaal, permanent op de main branch. Elke kaart draagt de cijfers van zijn eigen release, zodat de snelheid en kalibratie van de ene versie nooit die van een andere overschrijven. Het project vermeldt de reden rechtstreeks: die keten is de enige manier om te zien of een zelfverbeterende lus daadwerkelijk verbetert. Al het andere — het recept, de scripts, de vastgezette stack — bevat alleen de huidige release, want de tegenovergestelde regel zou het onmogelijk maken om te zien wat actueel is. Een gepubliceerd checkpoint draagt zijn eigen code, zodat oude releases uitvoerbaar blijven zonder oude branches.

A screenshot of the subject project's own GitHub repository page, Shanghua-Gao / RSI-Jev, showing the repository description 'Typed-decision models (noul / choice / score) trained by a self-improving loop of AI agents - checkpoints, the code that produced them, and every version that failed', the sidebar counters 80 stars, 5 forks and 1 watching, 198 commits and 8 releases, the newest release headed 'RSI-Jev v6.1-VL 4B', an MIT license line, the topic tags ai-agents, autonomous-research, decision-model, jev, recursive-self-improvement, system-one and typed-decisions, and the merge commit 'Merge pull request #33 from Shanghua-Gao/release-v6.1-vl' at the top of the commit list.

Wat de discipline kost, en wat het oplevert

Twee verhalen uit het verslag zijn het eerlijke tegenwicht voor het woord 'self-improving', want beide zijn gevallen waarin de eigen regels van de loop het werk tegelijk langzamer en beter maakten.

De eerste is de bug achter v1.0. Het vinden ervan kostte zeven geregistreerde negatieve resultaten. Elk van de zeven was een oplossing aan de optimizerzijde die een trainingsinstabiliteit verminderde zonder die weg te nemen, omdat de oorzaak een precisiefout was die nergens in de buurt van de optimizer lag — en de uiteindelijke oplossing was één regel. Geen van de zeven was op zichzelf publicatiewaardig. Samen maakten ze de oorzaak überhaupt vindbaar, en dat is het hele argument om negatieve resultaten te registreren en te bewaren: hun waarde is gezamenlijk, niet individueel.

Het tweede is minder flatteus en het project publiceert het toch, in een voetnoot. Een vroege arm zakte voor precies één guard — MMLU-Pro kwam 0,026 onder de lat uit tegen een limiet van 0,020 — en werd gelogd als afgewezen. De run-eigenaar verruimde de limiet vervolgens naar 0,030, op grond van het argument dat MMLU-Pro een guard tegen vergeten is en geen doel, en de arm werd bevestigd op vier nieuwe seeds en werd de volgende release. De oorspronkelijke afwijzing bleef in het log staan, met het commentaar van het project zelf dat een lat die na het zien van het resultaat wordt verzet, precies het soort ding is waarop een lezer het moet kunnen betrappen.

Die voetnoot is de nuttigste alinea in de repository voor iedereen die dit soort beweringen in het wild probeert te beoordelen. Een lat die is verschoven, is geen bewijs van kwade trouw — de gegeven redenering is verdedigbaar, en de verruimde lat moest daarna vier nieuwe seeds doorstaan. Maar een lat die in stilte is verschoven, is een lus die niet langer gesloten is, en het verschil tussen die twee zit hem volledig in de vraag of het is opgeschreven. De algemene regel waar het project daarna op uitkwam, is de regel die het waard is om naar andere systemen mee te nemen: een bijna-misser die precies één guard niet doorstaat, krijgt een diagnose en een gerichte reparatie in plaats van te worden weggegooid — en als de reparatie mislukt, wordt het een doodlopende weg met een vastlegging.

Hoe vaak de lus verkeerd is: veertien setups, twee behouden

Dit is het getal om vast te houden. In de release die afbeeldingen leest, telt het project veertien reinforcement-learning-opstellingen en 63 met beloning getrainde armen. Twee werden behouden.

Elke opstelling werd afgezet tegen een gesuperviseerde controle die op dezelfde items gedurende hetzelfde aantal stappen was getraind, en dat is de vergelijking die de telling betekenisvol maakt — een RL-arm die een baseline verslaat die hij nooit hoefde te evenaren, bewijst niets. De leerzame verliezen, in de eigen woorden van het project:

• Binaire correctheids-RL — de kansuitvoer is ingestort tot 0 en 1. Het belonen van de daad van het juist kiezen in plaats van de eerlijkheid van de gerapporteerde odds duwt een verdeling naar de hoeken, en een beslissingsmodel waarvan het vertrouwen altijd totaal is, is nutteloos voor datgene waarvoor beslissingsmodellen dienen.

• Proper-score-RL, de reconstructie van de Laya-achtige doelstelling — ging goed bij 300 stappen, divergeerde bij 1.500. Stabiel terwijl het niet veel deed, en instabiel precies toen het ertoe begon te doen.

• RLCR — qua nauwkeurigheid gelijk, slechtere ruwe kalibratie. Het leverde geen extra capaciteit op en betaalde daarvoor met de enige eigenschap waarvoor het model bestaat.

• Bandit RLCD, waarbij alleen de uitkomst van de gekozen optie wordt onthuld — niet beter dan gesuperviseerd leren op dezelfde feedback. Het project blies hier zijn eigen vooraf geregistreerde test af: de arm moest op ten minste twee van de vier kalibratiemetrieken beter zijn dan gesuperviseerd leren en won er één.

De winnaar, en de reden dat hij won, is de meest overdraagbare bevinding op de pagina. Het is een lijstgewijze beloning — rangschikkingskwaliteit gemeten over de volgorde van vele afzonderlijk gescoorde kandidaten, in plaats van ze afzonderlijk te behandelen. Herrankschikkingsrecall op de eerste positie ging van 0,192 voor de gesuperviseerde ouder naar 0,308, met winsten en verliezen op een gepaarde test. De uitleg van het project is geen afstemmingsverhaal: een trainingsdoel per item scoort elke kandidaat afzonderlijk, en geen enkel label codeert de kwaliteit van een volgorde over kandidaten. Waar de beloning iets zei dat de labels niet kunnen uitdrukken, versloeg RL de gesuperviseerde training op dezelfde rijen. Waar dat niet het geval was, evenaarde de gesuperviseerde training het.

Dat generaliseert tot een regel over wanneer dit soort lus überhaupt iets kan vinden. Met een gold label in de hand is de verwachte policy-gradientupdate gelijk aan de gradiënt van een supervised loss — de eigen formulering van het project — dus een 'RL-arm' die tegen gelabelde beslissingen wordt afgezet, is in feite een loss-design-arm. En wijzigingen op loss-niveau verschoven de interne suite met hoogstens 0,002, terwijl nieuwe data die met 0,13 verschoven. Samengelezen: de hefboomwerking van de lus zat nooit in de doelstelling. Die zat in wat er werd gemeten en wat erin werd gestopt.

Wat het eerlijke antwoord is op een vraag die een lezer terecht stelt. RL-opstellingen worden elders aangehaald als bewijs voor zelfverbetering in het algemeen; hier zijn ze bewijs voor één lus op beslissingstaken. Het listwise-resultaat is één seed, en het project zegt dat ook: de gepaarde RL-versus-supervised vergelijking werd uitgevoerd op een andere parent dan degene waarop de release die vergelijking heeft toegepast, en die release "heeft geen gematchte gesuperviseerde controle". Een bevinding met dat voorbehoud eraan verbonden is meer waard dan een zonder, en daarom generaliseert de pagina die u leest het niet.

Waar de mens zit

Het project is expliciet, en dat expliciete is het interessante eraan: de lus draait zijn eigen experimenten en fasert zijn eigen kampioenen uit, maar hij bepaalt niet wat de moeite waard is om te meten, en hij merkt niet zelf op wanneer een getal technisch waar en praktisch misleidend is. Dat doen mensen.

Twee van de eigen regels van het project bestaan omdat iemand tegengas gaf. De MMLU-Pro-guard werd verruimd in plaats van een bijna-goede uitkomst te laten sneuvelen. De seed-vereiste schaalt nu mee met de effectgrootte in plaats van vier seeds aan elk verschil te besteden — want de bevestigingsseed, dat ene getal waarop een arm niet is geselecteerd, is de dragende factor, en rekenkracht besteden aan verschillen die je al kunt zien levert niets op. Een van de releases in de keten begon als een weigering om een arm te schrappen die één guard niet had doorstaan. Het project noemt de mensen die die feedback stuurden bij naam in de dankbetuiging.

Dus ‘zelfverbeterend’ beschrijft hier het midden van de lus, niet de hele lus. De lus is een zoekproces dat draait zonder dat een mens aan de zwengel draait. De mens staat nog steeds bovenaan de lus om het doel te kiezen en onderaan om het resultaat kritisch te lezen — en dat is precies de opzet die voorkomt dat de lus een machine wordt om zijn eigen voorkeuren te bevestigen. Elke beschouwing over recursieve zelfverbetering die die plaats weglaat, beschrijft een ander systeem dan dit, en waarschijnlijk een hypothetische variant.

Wat de eigen cijfers van het project niet laten zien

De discipline hierboven is alleen het beschrijven waard als haar grenzen in één adem worden vermeld, en de geschiedenis van RSI-Jev vermeldt die zelf.

• Het is één project, één modelgrootte tegelijk, één seed. Het gepubliceerde checkpoint is van één enkele seed, vooraf vastgelegd als primair in plaats van gekozen omdat het het beste scoorde. Het RL-bewijs is één seed.

• Het zijn beslissingstaken, geen generatie: een ja/nee-vraag, een keuze uit k opties of een beoordeling aan de hand van een rubric over een document, een chat of een afbeelding, beantwoord in één forward pass met een gekalibreerde waarschijnlijkheid per optie. Er wordt niets gegenereerd, dus er zijn geen reasoning-tokens om te besteden. Wat de loop hier demonstreert, is dat hij een scorer van die vorm kan verbeteren.

• Een deel ervan is niet reproduceerbaar op basis van alleen de repository. De trainingscorpora en de beleidsontwikkelingssets zijn niet openbaar, en het project zegt dat duidelijk in de release card: "de stadia kunnen niet opnieuw worden uitgevoerd op basis van alleen deze repository." Eén corpusbouwer heeft ongeveer 96 GB geheugen nodig en is niet van begin tot eind opnieuw uitgevoerd.

• Niet alles is überhaupt controleerbaar. De interne suite is nooit volledig achtergehouden. Van de vijftien benchmarks leveren er tien in een of andere vorm trainingsdata, dus geen van die cijfers is zero-shot — de achtergehouden set is de vergelijking die wordt achtergehouden, en die is de enige.

En de externe onderdelen hebben hun eigen littekenweefsel. Een audit na één release vond ongeveer duizend items van de testrijen van de publieke benchmarkkit in de trainingscorpora — ongeveer 0,3% van de rijen van de kit, waarbij de grootste afzonderlijke bijdrage een paar honderd rijen uit één bron was. Zonder die items opnieuw gescoord, verschuift de index met ten hoogste 0,04. Die correctie werd gepubliceerd in de kaart van de volgende release in plaats van stilletjes toegepast, onder de regel die het project formuleert als "geen contaminatie, gecontroleerd in plaats van beweerd." Het is een regel die hun een getal kost, en dat is het enige soort regel dat de moeite waard is.

Waar je het daadwerkelijk kunt uitvoeren — en waar niet

Niets hier wordt door OrcaRouter geserveerd. Onze catalogus bevat geen RSI-Jev-id en geen modelkaart ervoor, en die komt er niet totdat iemand het serveert. RSI-Jev wordt geïnstalleerd vanuit zijn eigen repository en draait zijn eigen server, die de Jev API spreekt: je richt een bestaande Jev-client erop en wijzigt de basis-URL. Het draait op Linux, Windows en macOS, op een CUDA-GPU, Apple Silicon of een gewone 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.

A generated single-column scoreboard headed 'RSI-Jev - the loop's own ledger', with six rows reading 'Predictions: registered before the run', 'Null floors: measured from identical arms', 'Held-out set: read once, then spent', 'Failures: published, including the champion's', 'Release chain: one card per release, on main forever' and 'RL setups kept: 2 of 14, each judged against a matched control'; a footer reads 'All figures from the project's own record, read 2026-10-08.'

Als je een beslissingsmodel zoals dit achter een applicatie wilt zetten, staat de routeringsvraag los van de modelvraag, en het is het onderdeel dat bepaalt of het experiment überhaupt de moeite waard is om uit te voeren. OrcaRouter is één API voor 200+ modellen met 0% markup — de lijstprijs van de provider wordt doorgegeven, dus een prijswijziging van een leverancier is dezelfde dag jouw prijs — plus automatische failover en een routing-DSL voor het combineren van meerdere modellen in één aanroep. Voor een loopmodel dat je nog niet via een algemene API kunt aanroepen, maakt dat op een specifieke manier uit: het betekent dat de alternatieve kandidaten waarmee je het zou benchmarken al achter één sleutel zitten, en dat de vergelijking een configuratiewijziging is in plaats van een tweede integratie.

A screenshot of OrcaRouter's own model page for typesafe/jev-1.13 showing the left navigation, a PERFORMANCE panel with prefill and decode lines, the heading 'Jev 1.13' with the provider line 'typesafe', the price fields $0.11 prefill and $0.36 decode per million tokens, a benchmark box with MED 0.3, Response Trust 0.784, Structured Output 0.964, Refusal Correctness 1.0 and Consistency 0.59, an accuracy-versus-cost scatter with a 'Jev 1.13' marker, an 'Individual Runs' table, API and Agent curl snippets pointing at the systemone endpoint, the OrcaRouter logo and a sign-up button.

Het deel dat het bewaren waard is

De reden om over recursieve zelfverbetering te schrijven via een project als dit, in plaats van via het argument over de vraag of het ergens dramatisch naartoe leidt, is dat de regels van de lus het overdraagbare deel zijn en de speculatie niet. Geregistreerde voorspellingen, gemeten nulniveaus, verbruikte held-out sets, gepubliceerde mislukkingen, een onveranderlijke releaseketen: niets daarvan is een eigenschap van een superintelligentie. Het zijn eigenschappen van een lab dat besloot controleerbaar te zijn, en ze zijn beschikbaar voor elk team dat vandaag geautomatiseerde zoekprocessen draait, op elke schaal, met elk model.

Zo gelezen is de interessante bewering in het record van RSI-Jev niet de score. Het is dat het grootboek van de loop zelf zegt dat die het veel vaker fout dan goed had — twee behouden recepten uit veertien setups, zeven negatieve resultaten om een bug van één regel te vinden, een balk die bewoog en werd opgeschreven — en dat het project het grootboek publiceerde. Een stijging van 38,38 naar 46,24 op een openbare index in één release is een curiositeit zonder de mislukkingen ernaast. Het zijn de mislukkingen die het getal iets laten betekenen.

Dat is de eerlijke positie ten aanzien van de term zelf. De vraag is niet of een systeem zichzelf kan verbeteren. Het is of de verbetering wordt gemeten door iets dat nee had kunnen zeggen. Waar die scheiding echt is en opgeschreven staat, is de lus het lezen waard. Waar dat niet zo is, is een stijgende lijn een beschrijving van een scorer, niet van een systeem dat beter wordt — en geen enkele hoeveelheid recursie lost dat op.