Как ИИ-агент превращает научную статью в рабочий код

Когда ИИ пишет код по статье, он слишком часто «срезает углы»

Представьте задачу: вы даёте ИИ научную статью по машинному обучению и просите собрать по ней целый репозиторий. Не один файл, а нормальный проект: модель, загрузку данных, обучение, оценку, скрипты запуска. На бумаге всё звучит логично. На практике ИИ почти всегда начинает упрощать.

Где-то теряется важная деталь алгоритма. Где-то один файл ожидает тензор в одном формате, а другой выдаёт в другом. В итоге код выглядит правдоподобно, но метод из статьи уже другой.

Именно эту проблему решает работа PaperCompiler. Авторы предлагают смотреть на перевод статьи в код как на компиляцию спецификации. Сначала система вытаскивает из статьи требования. Потом привязывает их к конкретным файлам и интерфейсам. И только после этого пишет код.

Звучит как бюрократия для ИИ-агента. Но такой слой обвязки, похоже, и нужен, если вы хотите получить репозиторий, который сохраняет логику метода.

Что проваливают обычные пайплайны

Авторы начинают с наблюдения, которое хорошо знакомо всем, кто пробовал агенты для программирования на длинных задачах. Между чтением статьи и генерацией кода обычно есть промежуточный шаг: план, краткое резюме, список задач, рассуждение модели. Проблема в том, что следующий шаг пайплайна может это резюме проигнорировать, пересказать по-своему или упростить.

В такой схеме теряется главное: какие именно требования из статьи нельзя ослаблять.

Три подхода к переводу статьи в код: обычные ИИ-агенты, специализированные пайплайны и схема PaperCompiler со спецификацией на уровне репозитория.

PaperCompiler строится вокруг простой идеи:

🟠 Статья должна превращаться в явную спецификацию

🟠 Каждое важное требование нужно привязать к месту в репозитории, где оно реализуется

🟠 Связи между файлами надо определить до генерации кода, а не надеяться, что модель сама догадается

Это важно, потому что большая часть ошибок в таких задачах — не в синтаксисе. Ошибки семантические. Код может запускаться, но уже не соответствовать статье.

Что такое PaperCompiler

PaperCompiler — это пайплайн генерации репозитория по статье, где центральную роль играет спецификация. Авторы делят работу на три больших шага.

Первый шаг — заземление статьи. Система превращает статью в структурированное описание того, что вообще нужно реализовать: основную модель, обработку данных, обучение, оценку, внешние зависимости. При этом она не просто делает краткое резюме, а отмечает статус каждого факта:

🟣 Подтверждено статьёй

🟣 Выведено по косвенным признакам

🟣 Делегировано внешнему источнику, например другому репозиторию или протоколу

🟣 Не решено явно

В обычных ИИ-пайплайнах все такие вещи часто смешиваются. Здесь система хотя бы знает, что она взяла из статьи, а что достроила сама.

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

🟠 Что должно быть сохранено без упрощений

🟠 Какие замены запрещены

🟠 Какой файл за что отвечает

🟠 Какие артефакты один модуль производит, а другой потребляет

🟠 Какие ограничения нужно держать между файлами

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

Общий пайплайн PaperCompiler: разбор статьи, сборка спецификации, распределение ответственности по файлам и генерация репозитория по зависимостям.

Если коротко, то вместо одного большого промта «сделай репозиторий по статье» авторы делают так, чтобы агент для программирования работал по контрактам.

Показательный пример: когда алгоритм незаметно упрощают

В статье есть кейс с работой Universal Neural Functionals. Там важная часть метода — построение базисных элементов по всем допустимым разбиениям. Если оставить только один кандидат, метод меняется.

Обычный пайплайн на базе PaperCoder в этом примере как раз делает такое упрощение: по сути, оставляет один вариант разбиения и выкидывает большую часть базиса. Снаружи код всё ещё похож на нужный. Но внутри это уже другая реализация.

PaperCompiler удерживает это требование и генерирует код, который действительно перебирает допустимые разбиения и собирает соответствующие блоки базиса.

Кейс Universal Neural Functionals: обычный пайплайн схлопывает важное правило алгоритма, а PaperCompiler сохраняет перечисление допустимых разбиений.

Это наглядный пример того, о чём вообще статья. Ошибка здесь не в том, что модель забыла строчку. Ошибка в том, что на уровне смысла алгоритм стал проще, чем требует статья.

Для научного кода это критично. Особенно если потом кто-то будет использовать такой репозиторий как основу для экспериментов или как «репродукцию» метода.

Как это оценивали

Авторы тестировали систему на 90 статьях из Paper2CodeBench и дополнительного набора P2C-Ex. Это статьи с ICLR, ICML и NeurIPS 2024. Сравнение шло не только с общими мультиагентными системами вроде ChatDEV и MetaGPT, но и со специализированными системами перевода статьи в код: PaperCoder, AutoP2C и AutoReproduce.

Оценка была в трёх режимах:

🟣 Без эталонного кода — судья видит только статью

🟣 P2C-Ex — более подробная безэталонная оценка

🟣 С эталонным кодом — судья сравнивает генерацию с авторским репозиторием

Последний режим особенно интересен. Именно он лучше всего показывает, насколько система действительно попала в детали реализации, а не просто собрала убедительный фасад.

Что получилось в числах

Против главного сравнимого базового метода, PaperCoder, новый подход улучшает среднюю оценку:

🟠 с 4.562 до 4.777 в безэталонной оценке

🟠 с 4.535 до 4.728 на P2C-Ex

🟠 с 3.647 до 4.152 в оценке по авторскому коду

Главная цифра здесь — последняя. Это относительное улучшение на 13,8% именно в режиме, где сложнее всего спрятать смысловые ошибки.

Выжимка по цифрам

🟣 Лучший прирост — в сравнении с авторской реализацией

🟣 13,8% относительного улучшения в самом строгом режиме

🟣 PaperCompiler лучше сохраняет детали метода, а не только внешний вид репозитория

Доли побед по отдельным статьям на подмножестве из десяти работ: PaperCompiler чаще обходит AutoP2C, AutoReproduce и PaperCoder, особенно при сравнении с авторским кодом.

Если перевести это на человеческий язык: PaperCompiler лучше не только в том, чтобы написать полный набор файлов. Он лучше в том, чтобы не исказить сам метод.

Авторы отдельно анализируют и типы ошибок. У PaperCompiler заметно падает доля тяжёлых замечаний от оценщика:

🟣 Тяжёлые ошибки: с 13,2% до 6,1%

🟣 Алгоритмические упрощения: с 28,0% до 24,6%

🟣 Пропущенные ключевые компоненты: с 12,3% до 6,8%

🟣 Несовпадения в протоколе оценки: с 13,4% до 8,4%

То есть прогресс не только в среднем балле, но и в характере провалов. Репозитории реже оказываются «вроде похожими, но с критической поломкой внутри».

Выжимка по результатам

🟠 Лучший прирост — там, где сравнивают с авторской реализацией

🟠 Меньше тяжёлых ошибок почти вдвое

🟠 Меньше пропусков ключевых частей метода

🟠 Меньше расхождений между файлами и этапами пайплайна

Почему это работает

Интереснее всего тут не сама прибавка в баллах, а механизм.

PaperCompiler делает три вещи, которых часто не хватает агентам для программирования:

🟣 Явно фиксирует требования, которые нельзя ухудшать

🟣 Назначает хозяина для каждого требования — какой файл отвечает за реализацию

🟣 Описывает передачу артефактов между файлами до генерации кода

Это звучит почти как обычная инженерия. В этом и смысл. Многие пайплайны перевода статьи в код до сих пор полагаются на то, что LLM удержит всё в голове: детали метода, структуру проекта, зависимости, ограничения интерфейсов. На коротких задачах это иногда работает. На репозиториях — уже нет.

Авторы ещё проводят абляции, то есть по очереди выключают части системы. Самое заметное падение качества происходит, когда убирают согласование требований и контракты на уровне файлов. Именно эти два слоя сильнее всего влияют на совпадение с авторским кодом.

Это важно. Прогресс здесь идёт не от того, что системе просто дали больше токенов. AutoP2C, например, тратит сопоставимый объём токенов, но всё равно заметно проигрывает. Значит, решает не только бюджет, а способ организации информации в пайплайне.

Где остаются проблемы

PaperCompiler не решает задачу полностью.

Во-первых, система в основном опирается на текстовый разбор статьи. Если важная деталь живёт в сложной схеме, визуальном примере или диаграмме архитектуры, пайплайн может её не восстановить.

Во-вторых, спецификация помогает на этапе генерации, но не даёт формальной гарантии корректности. Репозиторий может быть хорошо собран структурно, но всё равно провалиться на внешних зависимостях, редких кейсах работы или исполняемости.

В-третьих, у PaperCompiler немного выросло число замечаний по API и схемам данных. То есть система лучше держит метод, но всё ещё может ошибаться на более мелкой стыковке интерфейсов.

Наконец, подход дороже по вычислениям. В среднем он тратит 1,71 миллиона токенов на репозиторий против 0,98 миллиона у PaperCoder. Но в абсолютных деньгах это, по оценке авторов, всё ещё умеренная цена за заметный прирост качества.

Где ограничения заметнее всего

🟣 Текстовый разбор может пропускать смысл из схем и диаграмм

🟣 Спецификация не гарантирует корректность исполнения

🟣 Ошибки в API и схемах данных всё ещё остаются

🟣 Подход требует больше вычислений и токенов

Почему это важно

Качество длинной задачи всё чаще упирается не в модель, а в обвязку вокруг неё.

Когда задача маленькая, можно надеяться на один хороший промт. Когда задача — это репозиторий по научной статье, нужно уже не только уметь писать код, но и удерживать обязательства:

🟠 что именно сказано в статье;

🟠 что мы додумали сами;

🟠 что нельзя упрощать;

🟠 где в проекте это должно жить;

🟠 кто и что передаёт между файлами.

Это касается не только перевода статьи в код. Та же логика важна для ИИ-агентов в аналитике, робототехнике, автоматизации исследований и больших задачах по программированию. Чем длиннее пайплайн, тем дороже стоит потеря смысла между шагами.

Вывод

Чтобы переводить статьи в код точнее, мало дать модели больше контекста и больше токенов. Нужно сначала собрать спецификацию на уровне репозитория, а уже потом писать файлы.

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

Если вы хотите, чтобы ИИ не просто генерировал правдоподобный код, а действительно воспроизводил метод, без таких спецификаций дальше будет трудно.