Чи потрібна для зворотного проектування більша модель?

Що змінили сильніші моделі

З серпня 2026 року я досліджував, який обсяг зворотного проектування може виконати агент, маючи доступ до програми та спосіб перевірки її роботи. Більшість мого досвіду отримано від реконструкції ігор, особливо Touhou. Оскільки я змінював моделі, репозиторії зберігали записи про те, що вдалося відновити за кожну сесію.

Значна частина цієї роботи спрямована на точну реконструкцію: ми компілюємо підтримуваний джерело в ланцюжку історичних інструментів із фіксованими версіями та перевіряємо, чи він відтворює цільову функцію. Коли пізніша модель досягає успіху там, де попередня робота зупинилася, зміни джерела показують, що зробило цей прогрес можливим.

Тимчасові змінні потребували часу існування, що збігався

Значна частина логіки функції атаки TH09 вже була реконструйована, але компілятор усе ще зберігав тимчасові результати, відмінні від оригіналу. Проблема, що залишилася, полягала в тому, як довго ці результати залишалися живими та коли їхнє сховище можна було використовувати повторно.

GPT-6-Sol запис сеансу повідомив про цю невідповідність після тестування кількох звичайних механізмів вихідного коду. Коли GPT-6.1-Sol знову дослідив проблему, він запропонував корисну гіпотезу щодо тривалості життя цих тимчасових змінних.

Функція створила тимчасові результати та скопіювала їх у позиції анімації. У C++ тимчасовий результат залишається активним до завершення виразу, який його використовує. Групування реальних операцій в один вираз зберігало ці результати разом, тому компілятор більше не міг повторно використовувати те саме сховище для всіх них.

Один результат все ще ділився пам’яттю зі значенням, яке використовується пізніше для перевірок на конфлікти. Надання цьому значенню власного часу життя вирішило решту накладання. Після кількох цілеспрямованих експериментів чиста повторна компіляція з джерела підтвердила, що повна функція відповідає.

Мені цікаво, як відкриття та випробування підтримували одне одного. Гіпотеза про тривалість життя тимчасових об’єктів дала агенту ШІ новий напрямок. Відгуки компілятора допомогли уточнити цю гіпотезу у вихідному коді, який відповідав.

Інший графік потоку керування

Друга функція TH09 показує, чому цей новий напрямок може мати значення. Тут перешкодою було те, що кілька філій поділилися своєю остаточною роботою. Попередня робота GPT-6.1-Sol мала відповідні частини функції, але гілки все одно з’єднувалися інакше, ніж у оригіналі.

GPT-6-Astra змінив навколишній графік потоку керування. Основні шляхи тепер вели до спільного остаточного оновлення та повернення. У цій вихідній структурі компілятор об’єднав гілки так само, як і в оригіналі. Повна функція відповідала, і окрема перевірка відновлення підтвердила це.

Зміна подання відкрила більш продуктивний простір для пошуку. Обидва випадки дають мені підстави серйозно поставитися до загальної можливості моделі: агент може довго пробувати місцеві варіації, перш ніж знайти кращий спосіб вираження навколишньої роботи.

У той же час пізніші сеанси починалися з попередніх джерел і записаних збоїв. Ця накопичена робота була частиною їхньої переваги. Історія дозволяє нам ознайомитися з відкриттями та їх перевірками; контрольоване порівняння допомогло б відокремити ефект моделі від досвіду, який вона успадкувала.

Ось що робить питання цікавим для мене. Певний прогрес став завдяки пошуку нового представництва. Значна частина роботи, що залишилася, включала тестування різних механізмів вихідного коду на знайомому компіляторі. Наскільки для цього потрібна широка здатність міркувати? Скільки може навчитися модель, постійно працюючи з цим компілятором і кодом?

Чому спеціалізована модель ШІ може працювати добре?

Touhou дає нам конкретну причину очікувати, що цей досвід допоможе. Значна частина ігрового коду походить від того самого автора, ZUN, тому повторювані звички є розумним вихідним припущенням. Репозиторії підтверджують це корисними прикладами: пов’язані цикли та допоміжні механізми надають гіпотези для різних ігор.

Ці вихідні шаблони стають більш конкретними, коли ми включаємо компілятор. За певної версії та набору параметрів невеликі зміни у джерелі можуть призвести до повторюваних відмінностей у машинному коді. Деякі з цих відмінностей напрочуд незрозумілі.

У TH095, наприклад, навіть ім’я локальної змінної могло вплинути на те, де VC7.1 її зберігати. Переміщення його оголошення не вирішило макета сховища. Однак більш рання фонова функція виявила шаблон іменування, який вплинув на вибір компілятора. Це запропонувало більш перспективну гіпотезу для реконструкції Supervisor::LoadDat.

Повторне використання цього шаблону для змінної розміру файлу створило необхідний макет без додавання пам’яті. Тоді повна функція збігалася.

Це дуже конкретна деталь, яку модель ШІ загального призначення може не знати, коли вперше стикається з проблемою. Спеціалізована модель для цього компілятора може побачити багато таких випадків і дізнатися, які варіації вихідного коду варто перевірити в першу чергу.

Можливість особливо чітка в остаточних задачах зіставлення, де ми вже розуміємо поведінку. Тоді ми запитуємо, яку звичайну структуру вихідного коду цей компілятор перетворює на спостережувані інструкції. Спеціалізація може допомогти моделі запропонувати ці форми ефективніше, тоді як ціль все ще визначає, які гіпотези виживуть.

Корисні шаблони повинні зберігати свій контекст. TH08 використовує попередню версію Visual C++, ніж TH095 і TH09. TH04 використовує компілятор, відмінний від епохи DOS. Його реконструкція коду гравця потребувала різних гіпотез щодо шаблонів вихідного коду та того, як скомпільований код зв’язувався у виконуваний файл. Наявність того самого автора дає нам початкове очікування, але кожна ціль говорить нам, чи вона застосовна. Спеціалізована модель повинна розрізняти ці контексти.

Де зберігати цей досвід?

Перш ніж вирішувати навчати цим шаблонам за допомогою моделювання, я б подивився на знання, які ми вже зберігаємо в репозиторії. У попередньому есе я писав про те, що це стало робочою пам’яттю проекту. Ця пам’ять містить уроки компілятора, а також джерело та невдалі експерименти, які зробили їх корисними.

Отримавши цей запис, агент може почати з відомого результату та перевірити, як ми його досягли. Він також може уникнути альтернатив, які вже зазнали невдачі в тому ж контексті. Початкова точка покращується без зміни навчених параметрів моделі.

Під час реконструкції функції TH09 для створення ворогів GPT-6-Luna-max сеанс взяв гіпотезу з відповідного вихідного коду TH08. Цей попередній код пропонував, як організувати цикл і обробляти збої в ньому. Власні свідчення TH09 надали деталі гри. Перебудови з джерела підтвердили, що вся функція відповідає.

«Модель не знала про цю примху компілятора» та «модель не могла її використати» — це різні проблеми. Отримання може вирішити першу, але для того, щоб перетворити цей факт на корисну кандидатуру, все ще потрібно попрацювати. І якщо вихідний код кандидата зазнає невдачі, модель повинна вирішити, що означає результат для її наступної спроби. Знання відповідного шаблону – це лише початок цього процесу.

З цієї причини я б включив у будь-яке порівняння меншу модель ШІ загального призначення з хорошим пошуком. Надання такої ж бібліотеки досвіду допомогло б нам визначити, що додає навчання: краще формування кандидатів, кращі рішення після зворотного зв’язку чи те й інше.

Вивчення наступного корисного експерименту

Я б найбільше хотів вивчити ці рішення після зворотного зв’язку. При агентній реконструкції модель пропонує пояснення та перевіряє його на програму. Навіть якщо вихідний код кандидата не вдається, результат може звузити можливості, що залишилися, і запропонувати більш корисний наступний експеримент.

Знову розглянемо приклад із тимчасовими результатами. Його остаточне джерело показує схему, яка спрацювала, але шлях до цього джерела містить більше інформації. Кожен із наступних експериментів допоміг визначити, що ще потрібно змінити.

Вибрані експерименти з наведеної вище реконструкції функції атаки, згруповані за тим, чому вони нас навчили.

Навчальний запис, який зберігає цю послідовність, може навчити більше, ніж одне лише кінцеве джерело. Він пов’язує кожну запропоновану зміну з результатом спостереження та наступним рішенням. Збереження неефективних варіацій також має значення: вони повідомляють пізнішому агенту, які гіпотези вже були перевірені в цьому контексті.

Я хотів би, щоб модель навчилася використовувати зворотній зв’язок. Нейтральний результат є причиною переглянути варіант; змінена невідповідність може вказувати на іншу причину. Коли локальні редагування перестають бути інформативними, агент повинен мати можливість переглянути вихідне представлення або знову перевірити докази.

Щоб навчитися робити такий вибір, потрібна автономія. Іноді корисним наступним кроком є ​​перевірка іншої функції, що викликає цю функцію, а не компіляція іншого редагування. Жорстка послідовність необхідних переписів усуне цей вибір разом із частиною поведінки, яку ми хочемо, щоб модель навчила.

Чому зворотне проектування цікаве для навчання з підкріпленням

Реконструкція з визначеними межами дає практичне середовище для вивчення цих рішень. Коли версії цілі й компілятора зафіксовані, багато експериментів із вихідним кодом дають швидкий, відтворюваний зворотний зв’язок. Агент може скомпілювати кандидата, перевірити відмінності та вибрати наступний крок.

Навчання з підкріпленням може тренувати цей процес прийняття рішень за допомогою зворотного зв’язку, який він отримує. Кандидат, прийнятий за певною перевіркою, дає нам конкретний результат, а послідовність спроб дозволяє спостерігати, скільки роботи знадобилося для його досягнення.

У цьому напрямку вже є дослідження. LLM4Decompile вивчає моделі, що спеціалізуються на декомпіляції. AutoDecompiler тренує багатоповоротне вдосконалення за допомогою компілятора та відгуків про виконання. Їх дослідження зосереджені на функціональному відновленні. Для цієї роботи я б використав їх як відправну точку для пов’язаного завдання пошуку джерела, яке відповідає історичним результатам компілятора.

Однак, щоб досягти такого чітко визначеного завдання, нам може спочатку знадобитися встановити, якими ресурсами володіє функція, або розробити новий спосіб спостереження за поведінкою програми під час виконання. У TH08, наприклад, різниця зіткнень призвела до того, як оригінальна програма обробляла обчислення з плаваючою комою. Перш ніж агент міг перевірити корисну поправку, він повинен був визначити, що вимірювати.

Це говорить про іншу роль широкофункціональної моделі: допомогти зробити проблему перевіреною в першу чергу. Щойно така перевірка з’явиться, ми зможемо дослідити, наскільки далеко може зайти вивчена політика пошуку з нею.

Коли засіб перевірки помиляється

Коли перевірка використовується для навчання, її охоплення стає частиною навчального середовища. Такий еталон або засіб перевірки я називаю оракулом. Навіть відтворювану відповідь потрібно розуміти в межах того, що вона справді перевіряє.

TH08 показав, як багато можна приховати за межами цього покриття. Деякі реконструйовані функції пройшли точне порівняння з неправильними плаваючими константами. Компаратор скоригував переміщені адреси перед перевіркою інструкцій, але він перевірив значення за цими адресами лише тоді, коли вони були явно записані для перевірки. Інші літеральні посилання можуть пройти без перевірки їхніх значень.

Щоб усунути цю прогалину, ширший аудит виявив неправильні константи у функціях, які вже пройшли перевірку. В одному обчисленні реконструйований вихідний код додав 1.0f, тоді як оригінальний додав 32.0f.

Модель, нагороджена старою перевіркою перевірки, може навчитися виробляти неправильну реконструкцію. Ми не навчали модель RL за допомогою цього засобу перевірки. Помилка, яку ми помітили, була в самій перевірці. Але якби ми використовували це як винагороду, та сама сліпа пляма стала б частиною навчального середовища.

Функціональний тест може мати подібну сліпу пляму. Дослідження з використанням диференціального фаззингу на декомпіляторах LLM виявили поведінкові відмінності поза наданими тестами. Тому ми повинні розуміти проходження тесту з точки зору випадків, які він виконує. Подібним чином збіг інструкцій слід розуміти з точки зору байтів і даних, які він перевіряє.

Перш ніж використовувати будь-який вид перевірки підтвердження як винагороду, я б перевірив його з навмисно неправильними результатами. Я також хотів би зберегти остаточне прийняття окремо від вихідного коду, який агент ШІ може редагувати. Модель повинна пройти перевірку шляхом коректної реконструкції програми. Інакше просте копіювання байтового масиву з цільового об’єкта може обдурити наївну систему підрахунку балів без відновлення корисного вихідного коду.

Поліпшення моделі й поліпшення її засобу перевірки — частини однієї дослідницької проблеми. Що краще модель оптимізує наданий зворотний зв’язок, то важливіше розуміти сам цей зв’язок.

Варте порівняння

За наявності цих перевірок я б почав порівняння з фіксованої сім’ї завдань VC7.1. По-перше, я б визначив базові лінії для сильної моделі ШІ загального призначення та меншої. Додавання знань про репозиторій до меншої моделі покаже, які зміни в пошуку. Звідти контрольована спеціалізація та версія з навчанням RL дозволять нам перевірити, що додає навчання.

Щоб зробити ці порівняння інформативними, кожна модель отримуватиме однакові цільові дані та інструменти. Для порівнянь, пов’язаних із навчанням, я б також залишив базову модель і наявні знання фіксованими. Повторні випробування допомогли б відрізнити надійну стратегію пошуку від альтернативного рішення, яке вдалось випадково.

Потім я б розділив дві початкові умови: реконструкція функції з її інструкцій і закриття кількох останніх відмінностей у підтримуваному джерелі. Спеціалізована модель штучного інтелекту може бути чудовою для другого завдання, тоді як модель загального призначення виконує велику частину роботи, необхідної для її досягнення. Вимірювання їх окремо виявило б такий розподіл роботи.

Для обох завдань потрібні тестові приклади, яких немає ані в навчальних даних, ані в матеріалах для пошуку. Пов’язані ігри Touhou мають спільний код рушія. Якщо відкласти лише одну гру, майже однакові функції все одно можуть потрапити до навчання. Я б натомість відкладав цілі групи спорідненого вихідного коду й виключав їхні перевірені відповіді як із навчальних даних, так і з бібліотеки пошуку.

Для цих прикладів результатом будуть повні, незалежно перевірені збіги. Рівні бюджети для пропозицій кандидатів або спроб компіляції допоможуть порівняти якість пошуку. Вимірювання загального часу та вартості, включаючи компіляцію, покаже, чи забезпечує така якість ефективний робочий процес. Витрати на навчання слід вимірювати окремо.

Обидва вимірювання мають значення. Дешева пропозиція може призвести до дорогого робочого процесу, якщо це спричинить більше компіляцій, які не надають корисної інформації. І навпаки, повільніша модель може бути економнішою, якщо швидше знайде корисний експеримент. Порівняння повинно включати ці витрати.

Підрахунок прийнятих результатів також зберігає проміжний прогрес у перспективі. Один TH09 кандидат для повторного збереження виглядав багатообіцяючим, оскільки скомпільована функція мала очікуваний розмір, але повне порівняння все одно виявило значні відмінності. Зміни в тому, як компілятор впорядковує інструкції, також можуть створити враження, що кандидат ближчий до цілі, не вирішуючи основної проблеми. Така діагностика може керувати наступним експериментом, але я б перевірив будь-яку винагороду за «наближення» до повної перевірки прийняття.

Мені було б цікаво побачити закономірності цих результатів. Якщо спеціалізована модель штучного інтелекту добре справляється зі знайомим сімейством компіляторів, чи збережеться ця перевага після зміни інструментального ланцюжка? І коли обидві моделі штучного інтелекту мають хороший пошук, скільки ще додає навчання? Відповіді допоможуть нам вирішити, де кожен тип моделі є найбільш корисним.

Що це за агент ШІ?

Якщо виявиться, що моделі допомагають на різних етапах, корисною домовленістю може бути широкий агент із доступом до спеціалізованої моделі ШІ. Коли завдання стає звичним пошуком компілятора, воно може запитати спеціалізовану модель AI для кандидатів. Якщо результати перестають мати сенс, ширший агент може повернутися до цільових доказів або дослідити саме вимірювання.

У такій домовленості спеціалізація стає інструментом, який агент може вибрати під час розслідування. Агент зберігає свободу змінювати напрямок, що уможливило попередні прориви.

Це природно випливає з промислових змін, які я описав у попередньому есе. Можливість проводити багато інших експериментів змінює спосіб організації роботи. Це також дає нам привід запитати, які рішення потребують широкого оцінювання, а які покращуються через повторний досвід роботи з певним ремеслом.

Наразі найсильніша універсальна модель заслужила місце в моєму робочому процесі, розв’язавши проблеми, які раніше залишалися нерозв’язаними. Ці успіхи спонукають мене дослідити процес: яка частина залежала від широти її можливостей, а яку могла б виконати модель, навчена саме такої реконструкції?

Репозиторії дають нам спосіб перевірити запитання. Я хотів би використати цей запис для порівняння та побачити, що ми дізнаємося.