Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Повторный запуск ML-эксперимента стал надёжнее, когда найденные исправления, команды и настройки сохранили для следующего агента. Работа University of Waterloo и Google, которая пока не рецензирована и содержит замеры самих авторов, показывает рост средней доли успешных запусков с 76,4% до 92,6%. Расходы следующего агента на API при этом снизились в среднем на 19,7%, но подготовку пакета в эту экономию не включали.
Воспроизводимость проверяли не по совпавшему числу
Авторы собрали ReproBridge-Bench: 1 029 задач из 387 экспериментов, опубликованных в 36 статьях. Для каждой задачи пять специалистов независимо получили эталонные результаты, начиная с одной зафиксированной версии исходного репозитория.
Задача описывала набор данных, конфигурацию модели, процедуру обучения или оценки и итоговую метрику. Если статья и код расходились, приоритет получало описание из статьи. Эталонные прогоны учитывали естественный разброс результатов, поэтому от агента не требовали буквально повторить одну опубликованную цифру.
Одного близкого значения было недостаточно. Отдельный агент-аудитор проверял, что результат появился после нового запуска нужного эксперимента, а не был взят из старого файла, подменён другой метрикой или получен по сокращённой процедуре. Отчёт связывал итоговую цифру с командами, конфигурацией, исходными файлами и способом подсчёта.
Sonnet 4.6, Sonnet 5, Opus 5 и Gemini 3.8 Flash получали либо исходный репозиторий, либо подготовленный пакет. Каждый запуск начинался в свежей сессии: агент не видел работу создателя пакета, скрытые эталонные измерения и результаты других моделей.
Код и окружение дали основной выигрыш
ReproBridge превращает найденный способ запуска в четыре связанных компонента. Первый — исправленный код с недостающей поддержкой экспериментов. Второй — окружение с совместимыми зависимостями, сценариями загрузки данных и контрольным запуском из чистой командной оболочки.
Третий компонент — отдельные команды запуска, которые связывают задачу с конфигурацией, выходными файлами и подсчётом метрики. Они также разделяют быстрые проверки и полноценные прогоны, чтобы агент не выдал диагностический результат за итоговый.
Четвёртый — руководство с причинами принятых решений. В нём фиксируют расхождения между статьёй и кодом, исправленные ошибки, правила повторов, способ объединять результаты и известные чувствительные места. Так следующий исполнитель получает не только рабочую команду, но и объяснение, почему она выглядит именно так.
Когда авторы по одному убирали компоненты, результат ухудшался во всех случаях. Самые большие потери вызвало удаление исправленного кода или описания окружения. Руководство и команды запуска дали меньший, но самостоятельный вклад: оставшиеся файлы не всегда позволяли агенту восстановить нужную процедуру.
Подготовленный пакет также уменьшил зависимость результата от выбранной модели. Разрыв между лучшей и худшей моделью сократился с 21,6 до 3,9 процентного пункта, а каждая из проверенных моделей превысила 90% успешных запусков. Значит, хорошо оформленный эксперимент частично компенсирует различия в способности агентов разбираться в сыром репозитории.
Планы стоит менять там, где эксперимент запускают повторно
Для команды, которая строит внутреннюю платформу экспериментов, работа предлагает менять единицу поставки. Репозитория и файла с общими инструкциями недостаточно: полезнее выпускать проверяемый пакет из кода, зафиксированного окружения, отдельных команд запуска и журнала решений.
Такой пакет следует собирать во время первого успешного воспроизведения, пока исправления и причины выбора ещё доступны. ReproBridge делит эту работу на описание ожидаемого результата, настройку и запуск, а затем проверку и упаковку. Каждый итоговый показатель должен вести к конкретному выходному файлу, а каждая правка — к объяснению и списку затронутых задач.
Экономический вывод уже уже технического. Сократились только расходы последующих сессий на API. В расчёт не вошли создание и сопровождение пакета, независимая проверка, работа GPU и участие специалистов, поэтому окупаемость зависит от числа повторных запусков.
Проверка охватывала выбранные статьи с доступным официальным кодом и посильными требованиями к вычислениям. Пакеты повторно использовали программные агенты, а не исследователи без их помощи. Результат подтверждает ценность стандартизированной передачи эксперимента между агентами, но не измеряет экономию человеческого времени и не доказывает научную корректность самого эксперимента.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
