Персонализирани AI агенти и тестът RRSI за преносимост
Персонализираните AI агенти направиха още една крачка към по-безопасно самоусъвършенстване на 2026-09-29, когато Google Research, заедно с UNC-Chapel Hill, Stanford и Washington University in St. Louis, публикуваха RRSI като open-source. Пускането е важно, защото повечето цикли за подобрение на агенти се представят по-добре върху собствения си бенчмарк, но по-слабо при обобщаване извън него. Според анализа на MarkTechPost за публикацията, RRSI запазва теглата на модела непроменени и вместо това позволява на агента да преработва промпти, инструменти, памет, control flow и подагенти при изрична регуларизация.
Защо персонализираните AI агенти обръщат внимание на RRSI?
Краткият отговор е, че RRSI адресира практическо тясно място в разработката на AI агенти: екипите често успяват да подобрят агент в лабораторна среда, но тези печалби изчезват, когато работният процес се промени или тестовият набор се разшири. Google Research позиционира RRSI като начин да се подобрява заобикалящата система, а не самият базов модел. Това е съществено за enterprise екипите, защото промяната на промпти, маршрутизацията на инструменти и политиките за памет обикновено е по-евтина и по-бърза от fine-tuning на модел, особено когато стекът вече работи през доставчици, достъпни чрез LiteLLM или cloud слоеве като Vertex AI.
Изследователската рамка също е показателна. Това не е потребителско демо или пускане на нов модел. Това е опит цикли за саморедактиране на агенти да станат по-надеждни чрез ограничаване на начина, по който цикълът търси подобрения. За екипи, които изграждат production работни потоци, това се свързва много по-пряко с решенията по имплементация, отколкото със съревнование между frontier модели.
Защо самоусъвършенстващите се персонализирани AI агенти обикновено се пренастройват към бенчмарка?
Повечето системи за самоусъвършенстване повтарят един и същ модел: предлагат промяна, тестват я върху фиксиран evolve набор, запазват победителя и повтарят. С времето цикълът научава бенчмарка почти толкова добре, колкото и самата задача. В статията за RRSI са посочени три режима на провал: пренастройване към конкретния бенчмарк, преследване на шум и натрупване на сложност.
Пренастройването към конкретния бенчмарк е най-очевидният риск. Ако агентът вижда сходни задачи отново и отново, може да започне да кодира особеностите им в промптите или логиката на инструментите. Преследването на шум е по-фино: дадена промяна може да изглежда по-добра само защото вариацията в оценяването е висока. Натрупването на сложност е дългосрочният данък. Агентите добавят проверки, подагенти и правила за памет по-бързо, отколкото ги премахват, така че цената в токени расте, докато качеството на преноса се задържа.
Точно тук много enterprise AI интеграции подценяват проблема. Първата версия на агента често се проваля, защото е прекалено проста. Петата версия често се проваля, защото е станала прекалено усложнена за дебъгване. Затова въпросът при имплементация не е само дали агентът се подобрява, а дали се подобрява достатъчно чисто, за да издържи на оперативна промяна.
Как RRSI регулира самоусъвършенстването, без да променя теглата на модела?
RRSI оставя всеки основен компонент редактиран, но ограничава процеса на търсене. От страната на предложенията използва annealed budget за редакции: в ранните рундове могат да се комбинират няколко промени, докато по-късно процесът се насочва към една-единствена проследима редакция. Системата също така записва всеки кандидат в evidence ledger, който следи компонент, хипотеза, diff, промяна в оценката и промяна в разхода, така че неуспешните идеи да се повтарят по-рядко.
При селекцията правилата са по-строги. Leakage critic отхвърля логика, специфична за бенчмарка, още преди оценяването. Noise-adjusted прагът проверява дали видимото подобрение надхвърля вариацията, измерена върху непроменената базова линия. Правило за разхода изисква допълнителният inference разход да бъде оправдан от измерено представяне. Pruning премахва компоненти, които вече не допринасят.
На практика това означава, че системата се държи по-малко като сляпо търсене и повече като контролирана итерация. Това е важно за екипи, които оценяват услуги за AI имплементация: най-устойчивите печалби при персонализирани AI интеграции обикновено идват от по-добра контролна логика и по-строга оценка, а не от добавяне на още една агентна роля във всеки спринт.
Какво всъщност показват резултатите от бенчмарковете?
Основният извод не е само, че оценките върху evolve набора са се подобрили, а че са се подобрили и резултатите върху held-out наборите. При Terminal-Bench 2.1 evolve split се повишава от 74.2% до 80.2%. При SWE-bench Verified, който системата не е използвала за селекция, представянето се покачва от 82.0% до 83.8%. Според резюмето на MarkTechPost за публикацията и шестте held-out split-а са се подобрили.
Резултатите извън дистрибуцията са може би още по-силен сигнал. JobBench нараства с 4.7 пункта, GDPval с 3.5, а APEX-Agents с 3.7. При Harvey LAB evolve split се подобрява с 1.1, докато held-out split се покачва с 2.3. Този модел е важен, защото подсказва, че RRSI не просто „изстисква“ бенчмарка по-агресивно.
Има и сигнал за разхода. Докладът посочва, че agentic workspace инстанцията е използвала 2.42 милиона policy токена на опит при RRSI спрямо 3.80 милиона при нерегулирана еволюция. Независимо дали намалението е описано като 30% или 36% според различния източник, посоката е ясна: регуларизацията не само е подобрила преноса, но и е намалила загубите при търсене.
Как RRSI се сравнява с Meta-Harness, AETH, THE и HarnessX?
Сравнението е по-малко впечатляващо, ако единствената цел е максимален резултат върху evolve split. В таблицата, цитирана от изследователите, Meta-Harness води при Harvey LAB evolve performance с 93.0, докато RRSI достига 90.5. Това е важна уговорка. RRSI не е най-добрият метод, ако екипът търси най-големия скок, специфичен за бенчмарка.
Предимството му се вижда при преноса. Средната стойност извън дистрибуцията в публикацията поставя RRSI на 43.6 спрямо базовото H0 с 39.7, докато близките методи се групират по-скоро между 38.0 и 40.6. С други думи, RRSI се отказва от част от потенциала върху evolve набора в замяна на по-силно обобщаване.
Този компромис вероятно ще раздели пазара на персонализирани AI агенти на два лагера. Изследователските екипи, които гонят по-добри позиции в класации, може да предпочетат по-агресивно търсене. Enterprise операторите, които управляват AI workflow automation в реални системи, обикновено ще се интересуват повече от стабилност при промяна, проследимост на редакциите и ограничен ръст на токените.
Защо подходът със „замразен“ модел е важен за архитектурата на AI интеграциите?
Запазването на теглата фиксирани променя икономиката и тежестта по governance при AI automation agents. Замразеният модел позволява на екипите да тестват архитектурни промени, без да отварят отново целия цикъл по трениране на модела. Това може да съкрати времето за итерация, да улесни rollback и да направи сравненията по-чисти.
Подходът също така съответства на реалността при внедряването днес. Много организации не обучават собствени frontier модели; те оркестрират търговски API, вътрешни инструменти и retrieval системи. В този контекст архитектурата на AI интеграцията е самият продукт. Стекът от промпти, графът от инструменти, retry логиката, обхватът на паметта и evaluation harness често имат по-голямо значение от разликата между един premium API и друг на ниво базов модел.
Затова RRSI е по-полезно да се чете като оперативен модел за enterprise AI интеграции, а не като твърдение, че самоусъвършенстващите се агенти вече са решен проблем. Рамката може да се внедрява като изследователски код под Apache 2.0, изисква Python 3.10+ и приема всеки LiteLLM model string. Но използването в production все пак зависи от локални evals, политики при отказ и domain-specific условия за спиране.
Какво трябва да направят следващо екипите, които изграждат персонализирани AI агенти?
Практичната следваща стъпка не е масово внедряване. Тя е тесен пилот, при който работният процес е измерим, цената на грешката е ниска до умерена, а evolve наборът може ясно да се отдели от held-out тестовете. Помощници за софтуерно инженерство, агенти за вътрешно маршрутизиране на знания и ограничени работни потоци в професионални услуги са по-добри първи кандидати от клиентски взаимодействия с висока волатилност.
Три метрики са по-важни от водещия резултат в бенчмарка. Първо, held-out пренос: подобрява ли се представянето при задачи, спрямо които агентът не е бил селектиран? Второ, токен ефективност: идват ли печалбите при стабилен или нарастващ разход за всяка успешно завършена задача? Трето, drift на сложността: добавя ли системата повече движещи се части, отколкото операторите могат да обяснят?
Неочевидният урок от RRSI е, че самоусъвършенстването може първо да стане полезно като дисциплина по поддръжка, а не като автономност. На екипите не им трябват агенти, които пренаписват всичко. Нужни са им агенти, които предлагат малки, проследими промени и приемат, че много от тези промени трябва да бъдат отхвърлени. Това е по-тясна амбиция, но е много по-близо до начина, по който реално се изграждат надеждни enterprise системи.
Къде това най-вероятно ще има най-голямо значение през следващите 12 месеца?
Най-ясното краткосрочно въздействие е върху разработката на AI агенти за coding, research и operations работни потоци, при които оценяването може да се повтаря евтино. Тези домейни вече имат структурирани задачи, измерими резултати и достатъчно историческа вариация, за да се оценяват граници на шума. Това ги прави естествен кандидат за цикли в стил RRSI.
Втората зона на въздействие е изборът на доставчик. Купувачите на услуги за AI имплементация все по-често ще питат не само дали доставчикът може да изгради персонализирани AI агенти, а и как тези агенти се подобряват след внедряване. Пазарът се движи от еднократно внедряване към управлявана итерация. В такава среда методи, които документират редакциите, ограничават загубите при търсене и изчистват остарялата логика, ще изглеждат по-надеждни от методи, които просто отчитат по-добър демо резултат.
Засега основният въпрос за наблюдение е прост: дали независими екипи могат да възпроизведат печалбите в преноса извън първоначалния набор от бенчмаркове. Ако това се потвърди, RRSI ще има значение по-малко като изследователски акроним и повече като модел за проектиране на production агентни системи.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn