Ръководство за RRSI от Google Research: Овладяване на самоусъвършенстващи се ИИ агенти

В този урок реализираме RRSI (Regularized Recursive Self-Improvement) — метод, който позволява на агент с LLM да пренаписва собствения си х harness, подсказки, инструменти, памет, контролен поток и подагенти около замразен модел, без х harness-ът да се преобучава върху задачите, върху които се развива. Пълният цикъл на RRSI създава чернови на промените с Claude Opus във Vertex AI и ги оценява в Docker бенчмаркове, което не може да се изпълни в безплатен notebook. Частта от RRSI, която действително носи идеята на статията — правилата, определящи кои предложени промени да бъдат запазени — е обикновен Python и именно нея ще задвижим директно. Инсталираме пакета от официалното хранилище, разглеждаме неговия оценител, калибрираната му шумова граница, двата клона на алгоритъма за селекция, постепенно намаляващия бюджет за промени, детерминистичния екран за изтичане на информация и историята на промените, а след това включваме симулиран агент в собствения интерфейс Domain на RRSI. Тъй като сами изградихме симулираната среда, знаем истинския ефект от всяка промяна, което ни позволява да проверим решенията на RRSI спрямо реалността и да ги сравним с нерегулирано търсене, което просто запазва всичко с най-висока оценка.

Инсталираме RRSI от хранилището google-research, като фиксираме към commit-а, спрямо който е написан този notebook, тъй като пакетът не е публикуван в PyPI. Единствената му зависимост е клиентът на Anthropic, който ролите за търсене използват за извикване на Claude, но ние няма да го използваме. След това отпечатваме съпоставянето, документирано от самото хранилище, между символите в статията и функциите, които ги реализират: емпиричната оценка и оценката на разходите в evaluate, шумовата граница в calibrate, Algorithm 2 в selection, постепенно намаляващия бюджет за промени в schedule, екрана за изтичане на информация в critic и историята на промените с нейните обобщения за резултатност, премахване, застой и изследване в history. RRSIConfig съдържа хиперпараметрите от статията, а всяка функция по-долу го получава точно както в реалния цикъл.

RRSI измерва две числа за всеки harness: S — наградата, усреднена за всеки опит на всяка задача, и C — средния брой policy токени на опит. TaskResult записва опитите за една задача и ги агрегира. Детайлът, който си струва да бъде пренесен във всеки агентски оценител, е начинът, по който се обработват липсващите опити. Когато кандидат се срине на най-трудната задача, оценител, който премахва липсващите опити, отчита 0.750 и създава впечатление за подобрение. В същото време RRSI отчита всеки липсващ опит като нулева награда с пълния знаменател и отчита същите 0.500, както преди, така че кандидатът не може да изглежда по-добър, като унищожава опитите, които са му трудни. Претеглените награди обхващат набори, оценявани по рубрика, като Harvey LAB, където S се превръща в дела на всички изпълнени критерии, а не в средната стойност на средните оценки по задачи.

Преди едно правило да може да различи реалното подобрение от случайността, то трябва да знае колко може да се промени оценката на един harness сама по себе си. Създаваме малък симулиран агент, чийто успех за всяка задача е логистична функция на умението на harness-а минус трудността на задачата, и оценяваме непроменения начален harness шест пъти върху четиридесет задачи с по два опита: оценките се различават с 0.113, въпреки че нищо не се е променило. calibrate превръща повторните оценки на един и същ harness в delta — два пъти стандартното отклонение на разликата между два запуска. При 80 опита delta е приблизително 0.108, а при 3200 опита спада до около 0.013, в диапазона, посочен в статията за нейните инстанции (0.004 до 0.020). За целите на селекцията всяко подобрение, по-малко от delta, е неразличимо от повторно стартиране на същия harness.

Algorithm 2 е реализиран като чисти функции, така че можем да му подадем кандидати и да прочетем причините му дословно. Фиксираме текущия кандидат при S 0.630 и 10 000 токена, най-добрата досега оценка 0.640 и delta 0.020, след което прекарваме осем кандидати през judge. Кандидат под прага — най-добрата досега оценка минус delta — се отхвърля незабавно. Подобрение, по-голямо от delta, трябва да компенсира допълнителните токени според правилото, че относителната промяна в разходите остава под 0.10 плюс 40 пъти подобрението; подобрение от 6 процентни пункта при 20% повече токени се приема, а подобрение от 3 процентни пункта при 150% повече токени — не. В рамките на шумовата граница оценките се третират като равни и решава оформена оценка от 100 пъти подобрението минус 15 пъти промяната в разходите, плюс малък бонус за структурен компонент, който никога не е бил приеман. Така RRSI приема кандидат D, който е получил по-ниска оценка от текущия кандидат, но струва 20% по-малко токени, а нов подагент прекъсва равенството, което промяна в подсказката със същата оценка не би направила. Защитата на домейна налага вето независимо от оценката.

select_round прилага judge към всеки кандидат в рунда и запазва най-високо оценения допустим кандидат. Подаваме му скъпия кандидат, малко по-лошия, но по-евтин кандидат, и кандидат, който критикът вече е отхвърлил. Кандидатът с най-висока оценка губи, защото неговото подобрение от три процентни пункта не компенсира 150% повече токени; отхвърленият от критика кандидат изобщо не стига до оценяване, а победителят понижава оценката на текущия кандидат с половин пункт, като същевременно намалява разхода за токени с една пета. Детайлът, който запазва тази схема безопасна, е S*, което може само да се увеличава: прагът е закотвен към най-добрата измерена оценка, а не към текущия кандидат, така че поредица от замени „по-евтино, но малко по-лошо“ не може постепенно да отдалечи оценката в продължение на много рундове.

От страната на предложенията регуляризацията контролира начина, по който се създават промените, а не кои от тях се запазват. edit_budget реализира L0 бюджета за промени от статията: косинусова схема от b_max към b_min, която по подразбиране позволява до четири координирани промени за кандидат през първите осем рунда, три през следващите пет и две през последните седем. Закръглянето нагоре във формулата означава, че бюджетът достига минималната си стойност от едва при t = T — една стъпка след края на изпълнението, което лесно може да се пропусне при четене на уравнението. Тъй като всяка промяна в пакет наследява еднократното измерване на пакета, именно намаляващият бюджет прави историята в края на изпълнението проследима до по-малко компоненти. Бюджетът ограничава броя промени, които се движат заедно, но никога не ограничава механизмите, които harness-ът може в крайна сметка да съдържа.

Критикът проверява всяка разлика между версиите на кандидата, преди да бъдат изразходвани средства за оценяване, и работи на два слоя. Първият е детерминистична предварителна проверка срещу общ шаблон за идентификационни данни и собствения списък със забрани на домейна; с шаблони за идентификатори на задачи от набора за развитие и пътища към оценителя тя отхвърля промяна, която запаметява отговора за task_007, промяна, която прочита очаквания резултат, промяна, изтичаща API ключ, и празна промяна — всичко това без извикване на модел. Чиста промяна преминава към втория слой: преглед на намерението от Claude. Тук notebook-ът показва реален проблем: когато RRSI_VERTEX_PROJECTS не е зададена, rrsi.llm.generate изчислява индекс по модул на броя проекти извън try блока и предизвиква ZeroDivisionError, така че полезната грешка за настройване на конфигурацията никога не се достига. Разглеждаме и начина, по който промените се маркират: normalize запазва деклариран компонент само когато разликата съдържа доказателства за него, така че промяна в подсказката не може да се представи за ново умение, за да спечели бонуса за новост, а неправилно обозначена промяна в управлението на контекста се маркира според действителното си съдържание.

History записва по един JSONL запис за всяка промяна, а цикълът извежда от него четири обобщения. Множеството от изпробвани компоненти изключва промените, отхвърлени от критика, тъй като те никога не са били измервани. Текущата резултатност g_t е най-доброто измерено подобрение за всеки компонент в последните n_prune рунда, а всеки компонент, чиято скорошна резултатност не е положителна, влиза в множеството за премахване B_t, заедно с механизмите от този компонент, които все още присъстват в текущия кандидат; в нашата история това маркира промяна в подсказката, приета в нулевия рунд, която оттогава не е дала резултат. Флагът за застой се активира, когато оценката се е променила с по-малко от delta през последните w рунда, а изследването след това генерира указанието, което подаващият предложения получава, като запазва място за кандидати от компоненти, които изпълнението никога не е използвало. Тъй като подаващият предложения се обуславя от цялата тази информация, опровергана хипотеза не се генерира повторно.

RRSI сам по себе си не стартира агенти и не оценява резултати; това прави адаптерът Domain, а същият интерфейс се използва от инстанциите за програмиране, работно пространство и инженеринг в статията. Реализираме такъв адаптер за симулирания агент: разделяне на задачите за развитие и задачите за проверка, метод run, който чете harness-а от файлове под корена на работното дърво и записва резултатите от опитите в директория за изпълнения, метод score, който ги прочита обратно като обекти TaskResult, както и шаблоните на критика и сигналите за компонентите на домейна. След това собствената функция evaluate на RRSI оценява началния harness чрез адаптера, а второто ѝ извикване за същата задача прочита съхранените опити, вместо да ги изпълнява отново — безопасността при възстановяване, изисквана от договора.

Сега изпълняваме цялата страна за селекция като търсене: двадесет рунда, по два кандидата на рунд, пакети с размер според постепенно намаляващия бюджет, промени, маркирани чрез normalize, кандидати, проверени от precheck и оценени чрез адаптера, победители, избрани чрез select_round, и всеки резултат, записан в History в реда, използван от цикъла на RRSI. Скриптираният подаващ предложения генерира пет вида промени, чиито реални ефекти познаваме: обикновено полезни общи промени, изтичащи промени, които запаметяват отговори от задачите за развитие, инертни конфигурационни промени, скъпи подагенти, които помагат малко навсякъде при 1.5 пъти повече токени, и по-евтино компресиране на контекста. Сравняваме три правила за приемане върху един и същ поток от кандидати при осем начални стойности: greedy запазва най-добрата оценка, ако тя се е повишила; critic only добавя проверка за изтичане на информация; а RRSI добавя Algorithm 2 с калибрирана delta. Greedy достига най-високата оценка върху неизползваните за обучение данни — 0.681 срещу 0.616 за RRSI — но запаметява около десет отговора и почти утроява разхода за токени. RRSI не запаметява нито един, завършва с около наполовина по-нисък разход за токени (1.53 пъти началния harness срещу 2.97 пъти) и използва с една трета по-малко оценки. Най-полезният резултат е разделянето на разликата между набора за развитие и неизползваните данни: изборът на най-добрата от шумни оценки увеличава всяка схема с около девет пункта — нещо, което никое правило в този цикъл не премахва. В същото време критикът елиминира почти целия компонент, свързан със запаметяването.

Първият ни оценител беше шумен и delta беше калибрирана от него, така че предпазливостта на RRSI в стъпка 10 отразяваше оценителя, а не самия метод. Повтаряме сравнението с по-големи набори за развитие и повече опити. Когато оценителят става по-прецизен, delta спада от 0.096 до 0.025, а оценката на RRSI върху неизползваните данни се повишава от 0.616 до 0.759, докато нерегулираното търсене при най-прецизната настройка използва 6.5 пъти повече токени от RRSI. Greedy все още получава по-висока оценка, а notebook-ът обяснява защо: тази симулирана среда няма намаляваща възвръщаемост, така че всеки допълнителен подагент, натрупан от greedy, продължава да купува по-висока точност — най-благоприятният възможен сценарий за разходи. RRSI разменя част от тази оценка за ограничен разход на токени, липса на запаметени отговори и по-малко пропилени оценки, като размерът на компромиса се определя от delta, която той измерва, вместо да изисква от вас.

Обобщението отпечатва резултата на един ред, върнат от всеки раздел, ясно посочва какво не моделира миниатюрният пример — промени, които подобряват набора за развитие, но влошават различен набор, за което са предназначени LLM критикът и разделянето на неизползвани данни в статията, както и подаващ предложението, който чете историята — и след това насочва към изпълнение на реална инстанция, добавяне на домейн и повторно вземане на решение за съхранен рунд с различна delta, без повторно изпълнение.

В заключение разгледахме RRSI по линията, където действително се намира идеята на статията — правилата, определящи кои промени запазва един самоусъвършенстващ се агент — и ги изпълнихме офлайн на CPU, без модел или API ключ. Оценителят отказва да възнагради срив, шумовата граница се измерва, а не се избира, и Algorithm 2 се оказва по-фин от простото „отхвърляй шумните подобрения“: той никога не позволява оценката да падне под най-добрата наблюдавана стойност минус шумовата граница, изисква реалното подобрение да компенсира допълнителните токени, а в рамките на границата умишлено предпочита по-евтиния harness, дори когато е получил малко по-ниска оценка. Проверката на тези правила спрямо среда, чиято реалност контролирахме, беше най-информативната част: детерминистичният критик премахна почти цялото запаметяване, преди да бъде изразходвана каквато и да е оценка; Algorithm 2 задържа разхода за токени многократно под този на нерегулираното търсене; но нито един от двата подхода не премахна увеличението, породено от избора на най-добрата от шумни оценки — това може да направи само повторното измерване върху невиждани задачи. Честната уговорка е също толкова ясна: в среда, в която токените винаги купуват по-висока точност, нерегулираното търсене получава по-висока оценка. Следователно стойността на регуляризацията на RRSI зависи от това колко скъпи са токените и колко би ви струвал изтекъл отговор, а notebook-ът ви дава инструментите да измерите и двете върху собствения си оценител.

Разгледайте ПЪЛНИЯ КОД тук. Цялата заслуга е на изследователя на този проект. Също така можете да ни последвате в Twitter и не забравяйте да се присъедините към нашия ML SubReddit с над 150 хил. членове и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? Вече можете да се присъедините към нас и в Telegram.