Модель не менялась, набор задач тоже. Но стоило снять ограничения на ресурсы — результат вырос на шесть процентных пунктов. Разбираемся, почему в бенчмарках агентов CPU, память и тайм-ауты становятся частью оценки — и какие данные должны прилагаться к месту в рейтинге.
Представим, что два ИИ-агента, использующие одну и ту же LLM, набрали в бенчмарке 54% и 57%. Кажется, второй лучше: три процентных пункта — вполне заметный отрыв. Но что, если одного агента запускали с жестким лимитом по памяти, а другому разрешили кратковременно выходить за границы базовой конфигурации?
В этом году Anthropic опубликовала исследование инфраструктурного шума в бенчмарках для ИИ-агентов, которые пишут и запускают код. На Terminal-Bench 2.0 разница между самой строгой и неограниченной конфигурациями достигла шести процентных пунктов. Это больше, чем типичный разрыв между соседними позициями в верхней части рейтинга.
Работа интересна не только конкретными цифрами. Она показывает более фундаментальную проблему: бенчмарки измеряют не модель в вакууме, а всю систему, в которой эта модель действует.
Для тех, кто хочет прочитать оригинал. Автор: Gian Segato, Anthropic. Quantifying infrastructure noise in agentic coding evals.
Почему обычный тест и тест агента — не одно и то же
В статическом бенчмарке модель получает вопрос и возвращает ответ. Среда на результат не влияет: ответ сверяют с эталоном. Агент работает иначе, он:
изучает репозиторий,
редактирует файлы,
запускает компилятор и тесты,
устанавливает зависимости,
создаёт дочерние процессы,
читает результаты и меняет решение,
повторяет этот цикл до успеха или тайм-аута.
На каждом шаге агент зависит от среды. Если не хватит памяти, установка пакета оборвется. Маленький CPU замедлит сборку и тесты, а значит, за отведенное время агент успеет меньше итераций. Среда здесь — не пассивная оболочка, а часть процесса решения.
Поэтому два агента с разными лимитами проходят, по сути, разные тесты, даже если модель и задачи у них одинаковые.
Что обнаружила Anthropic
Anthropic запускала Terminal-Bench 2.0 в Google Kubernetes Engine и заметила две интересные вещи: результаты не совпадали с официальным рейтингом, а до 6% задач падали из-за ошибок подов. Большинство этих сбоев не имело отношения к тому, способна ли модель решить задачу.
Причина оказалась в способе применения лимитов. Начиная с версии 2.0, Terminal-Bench указывает рекомендуемые CPU и RAM для каждой задачи. Но указать лимиты на ресурсы и единообразно их соблюдать — разные вещи.
Что я имею в виду? У контейнера два отдельных параметра: гарантированный объем ресурсов и жесткий потолок, при превышении которого контейнер принудительно завершается. В конфигурации Anthropic оба параметра равнялись спецификации задачи.
Запаса не было, и даже кратковременный всплеск потребления памяти убивал контейнер по OOM. Однако официальный рейтинг Terminal-Bench считается у другого провайдера песочниц. Он мягче: допускает временное превышение лимитов ради стабильности. Одна и та же спецификация на разной инфраструктуре давала разные результаты.
Эксперимент: шесть конфигураций
Чтобы оценить масштаб эффекта, команда прогнала Terminal-Bench 2.0 в шести конфигурациях: от строгой 1x, где спецификация задачи служит и гарантией, и потолком, до варианта вовсе без лимитов. Модель, агент и набор задач во всех прогонах были одинаковыми.
Результаты делятся на две группы.
От 1x до 3x росла надежность среды, а не результат. Доля инфраструктурных ошибок снизилась с 5,8% до 2,1% (p < 0,001), но итоговая успешность менялась в пределах шума (p = 0,40). По данным видно, что большинство задач, падавших при 1x, агент провалил бы и так: он упирался в лимит, еще не найдя верного пути к решению.
После 3x ресурсы начали помогать решать задачи. От 3x до конфигурации без лимитов инфраструктурных ошибок стало меньше еще на 1,6%, а успешность выросла почти на 4%. Успешность здесь растет быстрее, чем падают ошибки: агент получает возможность применять подходы, которые без запаса ресурсов просто не работают.
Итог между крайними точками: +6% к успешности, а доля инфраструктурных ошибок упала с 5,8% до 0,5%.
Основной вывод воспроизвели и на других моделях Anthropic: эффект повторился, лишь величина различалась. На моделях других компаний картина, судя по всему, похожая, но строго это не проверяли.
Эффект проверили и на SWE-bench: 227 задач, по 10 запусков на каждую, объем памяти — до 5x от базового. Успешность снова монотонно росла с объемом RAM, но слабее: разница между 1x и 5x составила 1,54%. Это ожидаемо, ведь задачи SWE-bench в среднем легче по ресурсам. Однако и здесь выделение ресурсов влияет на результат.
Ресурсы меняют то, что измеряет бенчмарк
Ключевой вывод — важен не только размер прироста, но и его природа.
До 3x дополнительные ресурсы «лечат» нестабильность среды: сглаживают кратковременные пики и убирают ложные падения. Тест становится надежнее, но не легче. Именно это негласно делает песочница официального рейтинга.
Выше 3x ресурсы уже меняют суть теста. Жесткие лимиты вознаграждают экономные стратегии: компактный код и минимум зависимостей. Щедрые лимиты вознаграждают тех, кто решает задачу «в лоб» тяжелыми инструментами: ставит крупные библиотеки, запускает дорогие процессы, гоняет требовательные к памяти тесты.
Хорошо это видно на задаче bn-fit-modify — подгонке байесовской сети. Некоторые модели первым делом ставят привычный стек для анализа данных: pandas, networkx, scikit-learn. При щедрых лимитах это работает. При жестких под исчерпывает память прямо во время установки — агент не успевает написать ни строчки решения. Есть и экономный путь: реализовать нужную математику на стандартной библиотеке Python. Часть моделей выбирает его сразу, часть — нет.
Ни одна стратегия не правильнее другой: и умение работать экономно, и умение использовать все доступные ресурсы стоит проверять. Проблема в другом: если свести обе в одно число и не указать конфигурацию, станет непонятно, что именно измеряли и насколько результат переносится на реальные условия. Задачи rstan-to-pystan и compile-compcert, например, заметно выигрывают от запаса памяти.
Другие источники шума
Ресурсы — не единственная скрытая переменная. В некоторых конфигурациях заметную роль начинают играть лимиты времени. В принципе на итоговый результат может повлиять любой элемент системы: состояние кластера, характеристики железа, даже пропускная способность исходящего трафика.
Anthropic также наблюдала, что процент прохождения колеблется в зависимости от времени суток — вероятно, из-за того, что задержки API меняются с нагрузкой и инцидентами. Формально этот эффект не измеряли, но он хорошо иллюстрирует проблему: граница между «способностями модели» и «поведением инфраструктуры» размыта сильнее, чем кажется по одному числу в рейтинге.
Разработчик модели может подавить часть этого шума с помощью выделенного железа. Внешним исследователям это сделать гораздо сложнее.
Что предлагают авторы
Идеал — запускать каждую оценку в одинаковых условиях. Причем одинаковыми должны быть обе части системы: и среда, где агент выполняет задачи (контейнеры, CPU, память, лимиты), и инфраструктура инференса — серверы, на которых работает сама модель и от которых зависит скорость ее ответов. На практике это не всегда возможно: внешний исследователь обращается к модели через API и не управляет чужими серверами. Поэтому авторы предлагают более достижимые меры.
Задавать два параметра вместо одного. Для каждой задачи указывать и гарантированный объем ресурсов, и жесткий потолок. Один фиксированный параметр не оставляет запаса, и кратковременные всплески зашумляют оценку. Раздельные параметры защищают от ложных OOM и при этом не дают раздуть результат безлимитными ресурсами.
Калибровать промежуток эмпирически. Разрыв между нижней и верхней границей должен быть таким, чтобы результаты на обеих укладывались в шум. Для Terminal-Bench 2.0 таким компромиссом стал потолок 3x: инфраструктурных ошибок стало примерно втрое меньше, а прирост результата остался в пределах шума. Для другого бенчмарка множитель будет другим, поэтому его нужно публиковать вместе с результатами.
Усреднять по времени. Публичные оценки стоит прогонять в разное время и в разные дни, чтобы сгладить колебания инфраструктуры.
Считать ресурсы экспериментальной переменной. Конфигурацию нужно документировать и контролировать так же строго, как формат промпта или температуру. Мейнтейнерам бенчмарков мало публиковать рекомендуемые ресурсы — нужно еще описывать, как именно эти лимиты применяются.
Как теперь воспринимать рейтинги
На основе значений бенчмарков и рейтингов часто принимают решения — например, какую модель использовать. Но позиция в рейтинге выглядит точнее, чем есть на самом деле: значение бенчмарка оценивает не только модель, но и условия, в которых ее запускали, а условия эти обычно не публикуют.
Авторы предлагают простое практическое правило: пока методика распределения ресурсов не стандартизирована, к разнице меньше 3% стоит относиться скептически, если условия запуска не опубликованы и не совпадают.
Бенчмарки агентов остаются полезными, но число в рейтинговой таблице является условным и по сути представляет собой зашумленную оценку. Разница в два или три процентных пункта может отражать преимущество той или иной конфигурации ресурсов, а не самой модели в целом.
Поэтому рядом с результатом должны находиться не только название модели и место в рейтинге, но и описание среды, лимитов и статистической методики. Пока этого нет, небольшие отрывы лучше воспринимать как повод для дополнительной проверки, а не как доказанный разрыв в возможностях. Отрыв в пару пунктов может означать реальное превосходство модели, особенности условий запуска или и то и другое сразу, и без описания конфигурации отличить одно от другого нельзя.
