Mange selvforbedrende agent‑løkker ender med at lære prøven udenad. De bliver kloge på testens vaner, ikke på jobbet. Google Cloud AI Research og partnere har nu open‑sourcet RRSI, Regularized Recursive Self‑Improvement, der forsøger at bryde mønsteret ved at regulere selve måden, en agent ændrer sit eget “harness” på. Ifølge den offentliggjorte præsentation og dækningen hos MarkTechPost er koden ude som et forskningsframework, ikke et kommercielt produkt, og der rapporteres forbedringer, som overlever til hold‑out og out‑of‑distribution benchmarks.
Udgivelsen flytter fokus fra finetuning af modelvægte til formning af det omkringliggende driftslag: prompts, værktøjskald, hukommelse, kontrolflow. Små, målrettede ændringer her slår ofte endnu en finetuning‑runde. RRSI forsøger at systematisere det – med indbyggede bremser mod at overpasse til et specifikt benchmark.
Hvad RRSI faktisk er
RRSI lader en agent foreslå og afprøve ændringer i centrale komponenter i sit harness – prompter, værktøjer, hukommelseslag, kontrolflow og sub‑agenter – mens selve modelvægtene forbliver frosne. Efter hver runde evalueres kandidater, og en bedre variant vælges som ny base, men med regler der holder udviklingen i snor. Simpelt i idé, krævende i udførelse.
I modsætning til klassiske evolutionære loops nøjes RRSI ikke med at score og vælge. Det begrænser hvor meget der må ændres pr. runde, hvordan kredit gives, hvor søgningen fortsætter, og hvornår en ændring afvises som lækage eller støj. Målet er forklarlige forbedringer, som er nemme at rulle tilbage.
Hvorfor overfitting opstår i selvforbedring
Ifølge forskningsmaterialet peges der på tre failure modes: benchmark‑specifik tilpasning, støjjagt og akkumuleret kompleksitet. Førstnævnte lærer idiosynkrasier frem for kompetence. Støjjagt opstår, når tilfældige udsving forveksles med fremskridt. Kompleksitet vokser, fordi små fixes sjældent fjernes igen.
Alle tre rammer hårdt i produktion, hvor opgaver skifter over tid. Hvis et framework ikke demonstrerer transfer til opgaver uden for selve forbedringssløjfen, er gevinsten tynd. RRSI adresserer netop dette – ikke perfekt, men som erklæret mål.
Forslagssiden i RRSI
Et annealed edit budget styrer, hvor mange ændringer en kandidat må indeholde. Tidligt er budgettet bredt; senere skærpes det, så man kan pege på præcis, hvad der gav effekten. Det gør attribution enklere og mindsker risikoen for skjult lækage i klumpede ændringer.
Der logges evidence‑aware credit: hver kandidat får en post med komponent, hypotese, diff, scoreændring og omkostningsændring. Proposeren slår op i denne log og undgår ideer, der allerede er falsificeret. Flader fremdriften ud inden for støj, flyttes søgebudgettet struktureret til uafprøvede komponenter, så energien ikke brændes af på én promptfil, mens værktøjsvalget står urørt.
Udvælgelsessiden i RRSI
Udvælgelsen bruger en leakage critic til at afvise kandidater med benchmarks eller opgavespecifikke artefakter, før de overhovedet scores. Dernæst kræver en noise‑adjusted floor, at gevinster overstiger den målte varians på den uændrede baseline. Små plusser under støjgulvet tæller ikke.
En cost rule fører regnskab med inference‑tokens og kræver tilsvarende større gevinster af dyrere kandidater. Når komponenter ikke længere bidrager, prunes de. Færre bevægelige dele mindsker risikoen for kompleksitet, der vokser uhæmmet. Intuitionerne minder om klassisk regularisering: stramt editbudget (L0), pruning (L1) og cost‑regel (L2).
Hvad tallene siger indtil videre
Ifølge de rapporterede resultater forbedrer RRSI Terminal‑Bench 2.1 på evolve‑split fra 74,2 til 80,2 procent, mens SWE‑bench Verified – som ikke bruges i udvælgelsen – løftes fra 82,0 til 83,8. Der meldes også gevinster på tværs af out‑of‑distribution benchmarks: JobBench +4,7, GDPval +3,5 samt forbedringer på APEX‑Agents. EngDesign og Frontier‑Eng nævnes med pæne løft, og Harvey LAB får både evolve‑ og held‑out‑plusser.
Der er en fodnote: Tokenforbruget falder, men formuleringerne varierer. På den agentiske workspace‑instans rapporteres 2,42 millioner policy‑tokens pr. forsøg for RRSI mod 3,80 millioner for ureguleret evolution. Abstraktet omtaler det som 30 procent færre tokens, mens projektsiden nævner 36 procent. Forskellen er lille, men værd at få afklaret i dokumentationen.
Tekniske krav og standardopsætning
Projektet frigives, ifølge kildedækningen, under Apache 2.0 med Python 3.10 eller nyere. Koden skulle acceptere en vilkårlig LiteLLM model‑string, mens standardindstillingerne peger mod Claude Opus 4.8 på Vertex AI. Det har konsekvenser for infrastrukturvalg, governance og prisstyring, inklusive dataplacering. Afklaring tidligt er klogt – defaults har det med at blive hængende.
Afhængigheder, miljøvariabler og eksempler i README afgør, om første run lykkes. Her tabes let dage, hvis versionsspænder er uklare. Råd: frys versionsnumre i en examples/requirements.txt, og dokumentér den præcise LiteLLM model‑string, så reproduktion ikke afhænger af en kollegas shell‑historik.
Hvad det betyder i praksis
Gevinsten er tempo. At kunne ændre prompts, værktøjsvalg, hukommelseslag og kontrolflow uden at røre modelvægte giver hurtigere iterationer, lavere risiko og ofte lavere omkostning. Et værktøj kan skiftes i én runde, en prompt kan splittes i system vs. user, en sub‑agent kan få et smallere mandat. Og logikken ender i en ledger, så rollback er enkelt.
Men sløjfen kræver sunde test‑sæt, klare hold‑out‑benchmarks og en fælles definition af “godt nok” til at blive basis. Ellers siver kompleksitet ind trods pruning. Økonomien skal også være eksplicit: med cost‑reglen bør teams føre token‑regnskab pr. ændring og pr. komponent – ikke kun pr. run.
Drift, infrastruktur og økonomi
Opsæt Python 3.10+ i et isoleret miljø, peg LiteLLM på jeres foretrukne leverandør, og beslut om standarden skal være Vertex AI med Claude Opus 4.8 eller noget andet. Valget styrer latency, pris og compliance. Dokumentér beslutningen – og hvordan man skifter senere.
Tokenforbrug er ikke en detalje. Definér månedlige budgetter per agent og per forbedringsrunde. Gem ledger‑data – komponent, hypotese, diff, scoreændring, omkostningsændring – i et append‑only format. Ikke kun til audit, men for at gøre fremtidige proposers klogere. Få runder med god logging slår mange uden.
Governance og sporbarhed
Evidence‑aware logging er grundlæggende. Uden den kan en lækage glide igennem og først opdages i produktion. Minimum: versionsstemplede komponenter, diff‑lagring, score‑ og variansmålinger, cost‑posteringer og reviewer‑noter. Indfør en fast regel: ingen promotion til basis uden menneskelig gennemlæsning, når ændringen rører kontrolflow eller værktøjsadgang.
Adskil adgang: hvem må redigere proposeren, og hvem må ændre selection‑regler. Det forhindrer, at noise‑gulvet udhules for at “vinde” point. Automatisér rollback‑punkter efter hver N runder – og test dem.
Begrænsninger og åbne spørgsmål
Uafhængig reproduktion er endnu ikke dokumenteret bredt. Nøgletesten bliver, om andre ser lignende OOD‑gevinster på egen infrastruktur, egne modeller og værktøjsstakke. Derudover er det åbent, hvor repræsentative de valgte held‑out‑splits er for virkelige OOD‑scenarier. Særlige domæner kan afvige markant.
Der er også behov for klarhed om præcis målemetode for tokens, inklusiv om policy‑tokens og værktøjskald opgøres separat, og hvordan retrier tælles. Og på sikkerheds‑/governance‑siden: hvor robuste er lækage‑checkene, hvis en promptændring implicit spejler benchmarkens struktur? Automatiseret forbedring fjerner ikke behovet for aktive vagter.
Sammenligning med nærliggende metoder
I materialeoversigten sammenlignes RRSI med rammer som Meta‑Harness, AHE og beslægtede observability‑drevne loops. Ifølge den rapporterede tabel matches start‑harness, policy, evolve‑split og kandidatbudget, hvilket gør tallene mere fair. Meta‑Harness ser stærkere ud på et enkelt evolve‑split, mens RRSI har den mest konsekvente OOD‑gevinst – den vigtigere kvalitet i denne niche.
Essensen: RRSI leverer regler og regnskaber, som andre metoder ofte overlader til brugeren. Det er mindre spekulativt i hurtige point og mere troværdigt, når opgaverne skifter.
Tjekliste før I trykker på start
- Hent repo og læs licensfilen. Bekræft Apache 2.0 og Python 3.10+ i setup.
- Fastlås miljø og registrer den nøjagtige LiteLLM model‑string. Notér standarden og hvorfor.
- Etabler et evolve‑sæt og mindst ét uafhængigt held‑out‑sæt. Dokumentér overlap‑checks.
- Aktivér evidence‑aware logging: komponent, hypotese, diff, scoreændring, cost‑ændring.
- Definér tokenbudget pr. runde og pr. komponent. Stop run, hvis budget brydes.
- Opsæt noise‑måling på baseline før første runde. Ellers er gulvet meningsløst.
- Kræv menneskelig review for ændringer i kontrolflow og værktøjsadgang.
- Planlæg rollback‑punkter for hver N runder. Test dem.
Hvem bør involveres
AI‑platformteamet til miljø og omkostningsstyring. Produkt‑ og domain‑owners til at vurdere, om “forbedring” hjælper brugere. Sikkerhedsfolk til adgang og værktøjsgrænser. Og nogen med statistikbriller til at vurdere varians og effekter over tid. De bedste resultater kommer, når rollerne deler et fælles dashboard og en enkel beslutningsregel.
Pragmatisk detalje: gem ledgeren i et læsbart format og lav en ét‑klik diff‑viewer til prompts og kontrolflow. Når tempoet stiger, vinder løsningen, der gør det nemt at sige ja/nej på fem minutter.
Hvad man ikke skal gøre
Undgå at optimere hele forløbet på ét benchmark, uanset hvor vigtigt det føles. Det giver flotte kurver og skuffer i brug. Lad være med at åbne editbudgettet sent for at “fange” en uforklarlig sidste gevinst. Og mål ikke succes alene på evolve‑score uden at se på OOD og cost‑kurverne.
Pas desuden på utilsigtet bias. En leakage‑critic hjælper, men er ikke ufejlbarlig. Hvis en kandidat fletter en kundespecifik liste af specialtilfælde ind, kan den hjælpe ét sted – og hæmme andre. Her er menneskelig bedømmelse stadig den bedste guardrail.
Kilder og verifikationsnoter
Oplysningerne her bygger primært på den offentlige omtale af RRSI og sammenfatninger fra MarkTechPost. De nævnte benchmarks, tal og mekanismer bør verificeres direkte i forskningspapirets Tabel 1, metodeafsnit, ablationer og eventuelt appendix, samt mod projektets README og licensfil. Der er en rapporteret uoverensstemmelse i tokensparet procenttal (30 vs. 36), som bør afklares i endelig dokumentation eller via issues i repo.
Følgende punkter kræver særlig tjek ved adoption: at koden ligger under Apache 2.0; at Python‑kravet er 3.10+; at LiteLLM model‑strings accepteres som lovet; at default peger mod Claude Opus 4.8 på Vertex AI; at de tre failure‑modes er defineret som benchmark‑specifik tilpasning, støjjagt og kompleksitetsakkumulation; og at proposer‑ og selection‑mekanismerne (annealed edit budget, evidence‑aware credit, structured exploration, leakage critic, noise‑adjusted floor, cost rule, pruning) er implementeret som beskrevet, inkl. loggingfelter og måleprocedurer for varians.
Konklusion
RRSI sigter mod at gøre selvforbedrende agenter mindre skrøbelige og mere overførbare. De rapporterede OOD‑gevinster og lavere tokenforbrug peger i den rigtige retning, mens kravene til god hygiejne – logging, hold‑outs, omkostningsdisciplin – er fornuftige og håndterbare. Næste skridt er uafhængige replikationer på egne stacks og opgaver.
Indtil da er det en teknisk relevant udgivelse med håndtag, man kan tage i brug nu. Forskellen mærkes først, når man kører den.
