Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Yunhao Liu, Hong Phuc Pham и Jaehong Yoon предложили PaperCompiler — систему, которая перед генерацией репозитория преобразует содержание научной статьи в формальную спецификацию; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, точность соответствия реализации исходному методу выросла относительно PaperCoder на 13,8%. Результат важен командам, которые автоматизируют перенос исследовательских методов в код и должны сохранять логику алгоритма между несколькими файлами.
Что сделали
Обычный конвейер переноса статьи в код сначала составляет свободный план или краткое изложение, а затем передаёт его агенту-разработчику. Авторы считают это местом потери информации: генератор может сократить алгоритм, независимо определить несовместимые интерфейсы или пропустить условие, которое было важно для оценки метода.
PaperCompiler заменяет свободный план промежуточной спецификацией репозитория. Сначала система извлекает из статьи сведения, влияющие на реализацию: состав метода, обработку данных, обучение, выполнение и протокол оценки. Для каждого требования сохраняются ссылка на фрагмент статьи, назначение и статус. Статусы разделяют прямо подтверждённые сведения, инженерные выводы, детали из внешних материалов и нерешённые вопросы. Длинные листинги, шаблоны запросов и схемы вывода сохраняются без пересказа в отдельном реестре.
Затем требования согласуются между собой. Для критичных частей метода система записывает не только ожидаемое поведение, но и запрещённые упрощения. Например, реализация не должна заменять полный перебор допустимых элементов одним примером, если от этого меняется алгоритм.
После этого PaperCompiler проектирует структуру репозитория. Каждое требование получает файл-владельца, а передаваемые между файлами артефакты — производителей и потребителей. Из этой схемы собираются локальные контракты: публичные интерфейсы, обязанности файла, входные и выходные данные, зависимости и ограничения.
Код генерируется в порядке зависимостей. Уже созданные пути, API и схемы считаются зафиксированными, а требования последующих файлов используются как условия совместимости. При этом генератор сохраняет свободу в локальных инженерных решениях, которые статья не определяет.
Что показали
Авторы проверили систему на 90 статьях из Paper2CodeBench и Paper2Code-Extra. В сопоставимых запусках PaperCompiler и PaperCoder получали одинаково разобранные исходные статьи и использовали o3-mini для генерации.
Наиболее заметная разница появилась при оценке по авторским репозиториям. Такой режим позволяет искать расхождения, которые трудно обнаружить только по тексту статьи: пропущенные компоненты, изменённый алгоритм или несовместимую передачу данных между модулями.
Доля замечаний высокой серьёзности в оценках авторов снизилась с 13,2% до 6,1%. Анализ отдельных случаев связывает улучшение с двумя частями конвейера: согласованием требований на уровне метода и переносом этих требований в контракты конкретных файлов. Удаление этих частей чаще приводило к заглушкам, неполным блокам модели и замене специализированной логики универсальной.
У результата есть вычислительная цена. PaperCompiler расходовал в среднем 1,71 млн токенов на репозиторий против 0,98 млн у PaperCoder. По использованным авторами тарифам o3-mini это соответствовало диапазону от 1,88 до 7,51 доллара за репозиторий в зависимости от соотношения входных и выходных токенов.
Ограничения
Работа измеряет соответствие сгенерированного репозитория статье и, когда он доступен, авторскому коду. Она не показывает, что полученные реализации полностью воспроизводят заявленные в исходных статьях экспериментальные результаты или готовы к эксплуатации без ручной проверки.
Основные оценки выставляет модель-оценщик, а анализ ошибок опирается на её замечания с последующей ручной классификацией. Поэтому метрики отражают выбранные протоколы проверки, а не независимый аудит корректности каждой реализации.
Масштаб ограничен набором исследовательских работ по машинному обучению. В работе нет проверки на статьях из других инженерных областей или на крупных производственных репозиториях с существующей архитектурой, миграциями и требованиями совместимости.
Сравнение с PaperCoder проведено в согласованных условиях, но с разным расходом токенов. Авторы приводят AutoP2C с близким расходом как аргумент против объяснения результата одним бюджетом, однако для AutoReproduce агрегированные данные о токенах в таблице отсутствуют. Это не позволяет полностью отделить эффект спецификации от различий в вычислительном процессе между всеми системами.
Что это значит
Для команд, которые строят перенос статей в код как повторяемый процесс, работа меняет прежде всего архитектуру конвейера, а не выбор LLM. Между извлечением сведений и генерацией кода появляется самостоятельный слой спецификаций: реестр доказательств, список обязательных свойств метода, владельцы требований и контракты межфайловых артефактов.
Такой слой полезен, если результатом должен быть поддерживаемый репозиторий, а не демонстрационный сценарий в одном файле. Он делает видимыми решения, которые иначе остаются внутри рассуждений агента: где реализуется требование, какой модуль создаёт артефакт, кто его потребляет и какое упрощение недопустимо. Эти записи можно проверять до дорогой генерации и использовать при повторном запуске отдельных этапов.
Планы не обязательно менять командам, которым достаточно быстро получить прототип и вручную восстановить пропущенные детали. Для конвейеров с минимальным участием инженера вывод практичнее: свободный план стоит считать недостаточным интерфейсом между анализом статьи и написанием кода. При этом результаты PaperCompiler пока дают основание испытать спецификацию на собственном наборе статей, но не отказываться от выполнения тестов, сверки с авторским кодом и экспертного просмотра.
Источники
Иллюстрация: рисунок из статьи «PaperCompiler: Faithful Paper-to-Code Generation via Repository-Level Specification Compilation», Yunhao Liu, Hong Phuc Pham, Jaehong Yoon, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
