Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследовательские агенты заметно хуже продолжают чужую работу, чем выполняют изолированное задание с чистого листа. В новом ARE-bench лучший агент полностью справился только с 66,2% задач, хотя работа не рецензирована и числа получили сами авторы. Для выбора модели теперь недостаточно проверить итоговый файл или успешный запуск: нужно учитывать прежние решения и состояние всего проекта.
Чистое рабочее пространство скрывает ошибки
Обычный бенчмарк даёт агенту самостоятельную цель и подготовленный набор файлов. В действующем проекте запрос обычно относится только к очередному шагу: исправить упавший эксперимент, обновить таблицу или переписать раздел статьи. При этом остаются в силе решения из предыдущих обсуждений, а рядом лежат старые версии, временные файлы и неудачные попытки.
Агент может формально выполнить текущий запрос, но нарушить научный смысл работы. Например, программа снова запускается, однако использует другую разметку данных или незаметно меняет функцию потерь. Проверка только факта запуска засчитает такую работу, хотя исследователь уже не продолжает прежний эксперимент.
Это видно в задаче по ремонту обучения CylindFormer. Два запуска восстановили обучение с ненулевой функцией потерь и обновлением параметров, но один прошёл 20 из 20 пунктов проверки, а второй — 16 из 20. Во втором случае агент изменил обработку координат, правила разметки пересечений и две функции потерь, хотя остальная поставка выглядела завершённой.
Так возникает разрыв между технической работоспособностью и корректным продолжением исследования. Файл создан, код исполняется, отчёт приложен — но метод уже не тот, который был согласован раньше.
Как ARE-bench восстанавливает контекст проекта
ARE-bench включает 75 задач из реальных сессий исследователей и охватывает семь этапов работы: от обзора литературы и проектирования до запуска экспериментов, анализа и написания текста. Для каждой задачи авторы выбирают конкретный запрос внутри сессии, а не превращают весь проект в одну самостоятельную цель.
Инструкция состоит из трёх частей. Фон кратко фиксирует прежние решения, которые всё ещё действуют. Требования описывают текущий запрос, ожидаемые материалы и условия приёмки. Раздел о среде перечисляет доступные ресурсы и ограничения запуска.
Рабочее пространство восстанавливают на момент перед запросом без уборки. В нём остаются черновики, ошибочно названные файлы, остановленные запуски и материалы, которые создал агент на предыдущих шагах. Поэтому модель должна не только написать решение, но и определить, какие артефакты актуальны.
Результат проверяют по двоим спискам критериев. Первый покрывает явную поставку и общие нормы: создан ли нужный файл, запускается ли программа, приложен ли отчёт. Второй добавляет требования из истории и рабочего пространства: сохранены ли прежние методические решения, использованы ли нужные данные и не заменён ли актуальный файл устаревшим.
Каждый критерий даёт бинарный результат, а задача считается полностью выполненной, только если пройдены все пункты. При этом список не предписывает конкретную реализацию: альтернативное решение засчитывают, если оно достигает согласованного результата и сохраняет смысл проекта.
Для выбора агента нужен тест на собственном проекте
Когда учитывали только поставку и общие нормы, три модели проходили примерно 69% задач. После добавления требований из истории и рабочего пространства результат тех же поставок падал до диапазона от 28,4% до 40%. Контекст не просто снижал оценки, но и сильнее разделял модели, которые выглядели почти одинаково при поверхностной проверке.
Проектирование и запуск экспериментов входили в число самых трудных этапов для каждой модели. Рейтинг также зависел от вида работы: модель могла хорошо писать код, но хуже готовить текст статьи. Поэтому единый итоговый балл не заменяет проверку на том этапе, который агент будет выполнять в продукте.
Для команд, которые внедряют исследовательского агента, работа меняет схему приёмки. В испытательный набор стоит включать снимки незавершённых проектов со старыми файлами, предыдущими решениями и частично выполненными запусками. Критерии лучше разделять на текущую поставку, унаследованные ограничения и корректность изменений в существующих материалах.
ARE-bench не задаёт универсальный рейтинг моделей. Сессии могут неравномерно представлять проекты и инструменты, восстановление среды иногда теряет исходный контекст, а критерии составляют люди. Кроме того, GPT-6.1-Sol запускали через Codex, остальные модели — через Claude Code, поэтому сравнение отражает одновременно свойства модели и исполнительной среды.
Если агент получает только отдельные задания в подготовленном репозитории, результаты ARE-bench меняют немногое. Если он должен продолжать длительный проект после людей или других агентов, проверка на чистых задачах систематически пропускает главный класс ошибок: формально правильную поставку, которая нарушает уже принятые решения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
