Рекурсивне самовдосконалення в штучних інтелектуальних агентах: що насправді показують експерименти
Уважний аналіз машин Геделя, STOP, агента Геделя, SICA, дарвінівської машини Геделя, SEAL та гіперагентів, а також способів визначення того, чи справді самооптимізуючийся агент покращується.
Джерела: Can Artificial Intelligence Design a Better Artificial Intelligence?
Зараз звернення до агента для кодування з проханням виправити помилку у вашому додатку є звичайною практикою: він відкриває файли, редагує кілька рядків та запускає набір тестів. Якщо замінити це завдання на „покращення програмного забезпечення, яке ви використовуєте для виконання цієї роботи“, то метою стає сам агент: як він знаходить файли, які інструменти використовує, як відновлюється після невдалої спроби та чи може отримана версія забезпечити подальше покращення. Саме це останнє питання є суттю рекурсивного самопокращення (RSI). У цій статті розрізняють самомодифікацію та справжнє самопокращення, розглядаються основні експерименти та їхні результати, а також наводиться набір запитань та простий план експерименту для самостійної оцінки таких тверджень.
Самомодифікація, самопокращення та рекурсія
Запит у моделі про перевірку її відповіді може дати кращу відповідь, але це не робить модель більш здатною до виконання наступних завдань. Змінюється лише цей один результат. Щоб чітко міркувати про RSI, потрібно розрізняти три рівні:
- Самомодифікація: якась частина системи змінюється.
- Самопокращення: ця зміна приносить вимірюваний користь.
- Рекурсивне самопокращення: нова здатність посилює саме той механізм, який забезпечує подальші покращення.
Конкретний приклад допомагає. Якщо агент краще шукає файли, він легше виконує завдання; це є самопокращенням. Якщо та сама покращена здатність до пошуку також допомагає йому розуміти власну базу коду, що покращує здатність до самостійної редагування, то цей ефект повертається у процес покращення; це і є рекурсивною частиною.
Також важливо, на що посилається термін „саме воно“. Розгорнута система ШІ рідко є лише моделлю мови. Модель знаходиться всередині інструментів, пам’яті, інструкцій до роботи та коду для оркестрації, і ця навколишня система може суттєво змінюватися, поки ваги залишаються незмінними. Еволюція в цьому зовнішньому шарі все одно є еволюцією, але будь-яке твердження про самосупершенству має вказувати, який саме шар змінився: ваги, код агента, запити, інструменти чи сам процес покращення.
Машина Геделя: доведіть користь перед змінами
Машина Геделя, запропонована Юргеном Шмідхубером, є класичною математичною моделлю. Система може переписувати будь-яку частину власного програмного забезпечення, включаючи компонент, який шукає доведення, але лише після того, як вона доведе, що така заміна підвищує очікувану корисність відповідно до визначених цілей та припущень.
Ця гарантія є вужчою, ніж здається. Вона не обіцяє, що кожна зміна буде корисною у реальному світі за будь-яких умов; вона діє лише стосовно обраних аксіом, моделі середовища та визначення корисності. Знаходження формального доведення того, що певна модифікація є корисною, також може бути дуже складним з комп’ютерної точки зору.
Тому більшість сучасних експериментів обирають емпіричний підхід: замість того, щоб заздалегідь доводити корисність зміни, вони запускають модифіковану систему та вимірюють її продуктивність. Це набагато практичніше, але перекладає тягар оцінки на інших. Очевидне наступне запитання — чи справді те, що вимірюється, є саме тим видом розвитку, який нас цікавить.
ЗАПИНКА: використання інструменту покращення на самому собі
Самоосвітній оптимізатор (STOP) починається з „покращувача“ — програми, яка викликає мовну модель для пропонування та оцінки покращень інших програм. Потім цей покращувач застосовується до власного вихідного коду, а оновлений варіант використовується у наступному циклі для отримання подальших покращень.
Важливим висновком є те, що цей цикл поводиться по-різному у різних моделях. З GPT-4 середня продуктивність зростала з кожною ітерацією; у GPT-3.5 та Mixtral — знижувалась. Оскільки основна мовна модель ніколи не змінюється, автори чітко зазначають, що їхня робота не є повноцінним RSI.
Урок для практиків простий: ітерації процесу не гарантують прогресу. Слабкий метод покращення, застосований до самого себе, може так само легко підсилювати власні помилки з кожною спробою.
Gödel Agent: переписування власної логіки агента
Gödel Agent дозволяє моделі мови змінювати логіку міркувань та код поведінки агента під час виконання. Його оцінюють за розумінням прочитаного, математикою та відповідями на запитання, засновані на знаннях; оптимізація проводиться на наборі для перевірки, а результати роботи агента вимірюються на окремому тестовому наборі, що є правильним способом уникнення налаштувань під конкретний тест.
Ключові цифри потрібно уважно аналізувати, оскільки різні варіанти працюють за різних умов. У проекті MGSM Meta Agent Search показує точність 53,4%, а обмежений варіант на основі Gödel — 64,2%, що є порівнянням однакових умов. Необмежений варіант без Gödel досягає 90,6%, але він працює за іншими обмеженнями, тому його не слід представляти як наступний крок у цьому ж порівнянні.
З технічної точки зору більш значущим є не сам результат, а вибір дизайну: метод, який використовує агент для розв’язання проблем, сам по собі стає програмним забезпеченням, яке можна шукати та модифікувати.
SICA: агент для програмування, який редагує власну базу коду
Самосвійний агент для програмування (SICA) уточнює це питання. Агент модифікує власний код, і кожна нова версія оцінюється за ефективністю виконання завдань, часом, необхідним для цього, та витратами.
На 50 випадково обраних завданнях з бази SWE-bench Verified продуктивність підвищилась з 17% у першій ітерації до максимуму 53% у 14-й ітерації, а у останній ітерації залишилась на рівні 51%. Іншими словами, покращення не було монотонним. Автори оцінюють, що 15 ітерацій коштували приблизно 7 000 доларів на використання API.
Два фактори зменшують значущість цього результату. По-перше, автори зазначають, що п’ятихвилинний ліміт на кожне завдання міг занизити початковий рівень, а більша частина покращень спостерігалась завдяки швидшим інструментам редагування файлів, які дозволяли агентові виконати більше роботи в межах цього ж ліміту. По-друге, покращення, які виявив агент, схожі на звичайну роботу з інструментами: точні операції з редагуванням замість переписування цілих файлів, а також пошук функцій та класів через аналіз синтаксичного дерева коду замість пошуку у звичайному тексті.
Усе це не робить результат тривіальним, але перехід від 17% до 53% не означає, що загальний рівень інтелекту системи майже подвоївся. Була виміряна лише продуктивність у одному конкретному наборі завдань за певного часового ліміту, і більша частина покращень — це саме те, що людський інженер міг би додати до набору інструментів кодуючого агента.
Машина Дарвіна-Геделя: архів замість однієї рядка
Машина Дарвіна-Геделя (DGM) відмовляється від ідеї єдиного ланцюга версій. Вона зберігає архів варіантів агентів та дозволяє новим гілкам розвиватися з будь-якого з них. Варіант, який сьогодні має нижчий рейтинг, все ще може бути предком пізнішої, більш корисної зміни, що і є елементом відкритого розвитку, закладеним у назві.
Згідно з документом версії v3, до досягнутих покращень належать зростання від 20% до 50% у оцінці підмножини SWE-bench та від 14,2% до 30,7% у повному тесті Polyglot. У дослідженні також проводяться експерименти з перенесенням знань із інших моделей та тестів, які не використовувалися під час розробки. Це свідчить про те, що частина покращень може застосовуватися не лише до завдань розробки, хоча вони ще не демонструють широкого покращення в усіх сферах. Як і у випадку з іншими роботами на рівні агентів, базові моделі залишаються незмінними; еволюціонує лише програмне забезпечення агентів, створене навколо них.
Ціна також є важливим фактором. Автори оцінюють вартість одного запуску DGM на тестовому майданчику SWE-bench приблизно у 22 000 доларів, на відміну від приблизно 10 000 доларів за кожен запуск базової версії. Тому експерименти, спрямовані на визначення внеску окремих компонентів, не дають повної відповіді на питання, чи все одно DGM буде кращим за рівним бюджетом.
Найбільш корисний висновок стосується стратегії пошуку: відкидання кожної версії, яка свідчить про регрес, може перекрити шлях до кращої системи, адже хороші рішення іноді досягаються через менш ефективні проміжні кроки.
Коли змінюються ваги чи алгоритми покращення
Hyperagents долає іншу обмеженість. Він поєднує агента завдання та мета-агента, який його редагує, у одну програму для редагування, щоб механізм, який забезпечує подальші вдосконалення, можна було змінити самостійно. Автори повідомляють, що деякі з цих вдосконалень мета-рівня передаються між сферами завдань та накопичуються протягом кількох виконань. Разом ці дослідження переносять дискусію від питання „Чи може ШІ редагувати власний код?“ до питання „Наскільки далеко він може вдосконалити процес свого розвитку?“
Чотири запитання до будь-якого твердження про „покращення“
Коли крива самовдосконалення піднімається, варто запитати, що саме піднялося.
Краще в якому аспекті?
Точність може зрости, водночас з нею зростають і витрати та затримки. Такий компроміс, який підходить для дослідницьких цілей, може бути неприйнятним у продукті, тому потрібно враховувати всі показники, а не лише основний.
Краще у яких завданнях?
Покращення у завданнях, які постійно використовуються для вибору наступної версії, є менш переконливими доказами, ніж покращення у фінальному тесті, до якого не торкалися під час розробки. Кожного разу, коли результат тесту впливає на наступне рішення щодо вибору, процес починає спрямовуватися до відповідності саме цьому тесту.
Яка версія краща?
Архів, який зберігає найкращий результат, буде показувати зростаючу лінію „найкращого на сьогодні“, навіть якщо більшість нових кандидатів є гіршими. Перевіряйте розподіл кандидатів, а не лише максимальне значення.
Чи покращується здатність до самовдосконалення?
Вирішення більшої кількості завдань може свідчити про кращу здатність до самовдосконалення, але це різні показники. Більш переконливий експеримент перевіряє, чи створює нова версія кращі наступні версії, ніж її попередник, за тих самих обмежень.
Ці запитання не призначені для того, щоб заперечувати прогрес. Вони допомагають точно визначити, що таке прогрес, щоб можна було його розпізнати.
Експеримент з самовдосконаленням, який ви можете провести
Реалістичним початком для окремого розробника чи невеликої команди є не те, щоб відкрити всю систему для самостійної модифікації, а обрати один вузький інструмент розробки та суворо обмежити його функції. Візьмемо, наприклад, інструмент для генерації тестів для кодової бази на Java:
- Виправте те, що не можна змінити: інструмент не повинен модифікувати код програми чи тести оцінювання.
- Визначте те, що можна змінити: лише його власну стратегію сканування файлів, його інструкції та процес генерації тестів.
Розглядайте це як проектування експерименту, а не як обіцянку результатів. Використання відкритих моделей чи безкоштовних квот може знизити витрати на їх роботу, але нижчі витрати не доводять корисності змін. Спочатку шукайте чітко вимірюваний позитивний ефект, і лише після цього розширюйте масштаби. Та сама дисципліна оцінки застосовується до будь-якого агента, який ви випускаєте; наш посібник щодо обмежених агентських циклів у TypeScript охоплює аспекти їх керування під час виконання.
Кращі агенти — це не вибух інтелекту
Чи може ШІ проектувати кращий ШІ? У вищезазначених експериментах — так, у певному сенсі: системи ШІ допомогли створити більш здатних агентів, і кілька з них застосували цей процес до власного програмного забезпечення. Однак не показано ланцюга вдосконалень, який прискорюється з кожною ітерацією, узагальнюється на різних доменах та працює незалежно від рішень людини-проектувальника. Відкидання цих досліджень як „просто інженерії запитів“ призводить до неправильного розуміння справжніх результатів; називання цього початком експлозії інтелекту — це перебільшення.
Ключові висновки
- Завжди запитуйте, який шар змінився: ваги, код агента, запити, інструменти чи сам засіб вдосконалення.
- Формальні гарантії, такі як ті, що існують у машині Геделя, діють лише в межах їхніх припущень; емпіричні підходи замінюють доведення на оцінку, тож якість оцінки вирішує все.
Справжня проблема полягає не у тому, щоб дозволити ШІ змінювати власний код, а у тому, щоб надійно довести, що така зміна є справжнім прогресом, та перенести цей прогрес у наступний етап вдосконалення.