Quantifying infrastructure noise in agentic coding evals

Агентные бенчмарки программирования, такие как SWE-bench и Terminal-Bench, широко используются для сравнения возможностей передовых моделей в области программной инженерии — при этом лидеры таблиц зачастую разделены лишь несколькими процентными пунктами. Эти баллы нередко воспринимаются как точные измерения относительных возможностей моделей и всё чаще влияют на решения о том, какие модели использовать в продакшене. Однако мы обнаружили, что одна лишь конфигурация инфраструктуры способна порождать различия, превышающие эти отрывы. В наших внутренних экспериментах разрыв между конфигурациями с наибольшим и наименьшим объёмом ресурсов на Terminal-Bench 2.0 составил 6 процентных пунктов (p < 0.01).

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

Разработчики бенчмарков начали это учитывать. Например, Terminal-Bench 2.0 в последнем релизе указывает рекомендуемые значения CPU и RAM для каждой задачи. Однако указать ресурсы — не то же самое, что обеспечить их единообразное применение. Более того, мы выяснили, что сама методология применения ограничений может менять то, что бенчмарк в действительности измеряет.

Как мы к этому пришли

Мы запускаем Terminal-Bench 2.0 на кластере Google Kubernetes Engine. В процессе калибровки мы заметили, что наши баллы не совпадают с официальной таблицей лидеров, а доля инфраструктурных ошибок оказалась неожиданно высокой: до 6 % задач падали из-за ошибок подов, большинство из которых не имели отношения к способности модели решать задачи.

Расхождение в баллах объяснялось способом применения ограничений. Наша реализация на Kubernetes трактовала спецификации ресурсов для каждой задачи одновременно как нижний порог и жёсткий потолок: контейнеру гарантировался указанный объём ресурсов, но при превышении он немедленно уничтожался. Среды выполнения контейнеров задают ресурсы через два отдельных параметра: гарантированное выделение — ресурсы, зарезервированные заранее, — и жёсткий лимит, при превышении которого контейнер уничтожается. Когда оба параметра равны, запаса на кратковременные всплески нет: мгновенный скачок потребления памяти может вызвать OOM-kill контейнера, который в ином случае завершился бы успешно. Чтобы это компенсировать, таблица лидеров Terminal-Bench использует другого провайдера песочниц, чья реализация мягче: она допускает временное превышение лимитов без уничтожения контейнера, отдавая приоритет стабильности инфраструктуры.

Этот результат поставил более масштабный вопрос: насколько конфигурация ресурсов влияет на оценки бенчмарков?

Чтобы количественно оценить влияние инфраструктуры, мы запустили Terminal-Bench 2.0 в шести конфигурациях ресурсов — от строгого применения спецификаций для каждой задачи (1×), где они выступают одновременно нижним порогом и потолком, до полностью неограниченного режима. Всё остальное оставалось неизменным: та же модель Claude, тот же каркас, тот же набор задач.

В наших экспериментах доля успешных решений росла вместе с запасом ресурсов. Это в первую очередь объяснялось монотонным снижением доли инфраструктурных ошибок на каждом шаге — с 5,8 % при строгом ограничении до 0,5 % в неограниченном режиме. Падение между строгим ограничением и запасом 3× (с 5,8 % до 2,1 %) было статистически значимым при p < 0.001. Чем больше запас, тем меньше контейнеров уничтожается за превышение выделенных ресурсов.

В диапазоне от 1× до 3× баллы успешности колеблются в пределах шума (p = 0.40). Большинство задач, падавших при 1×, провалились бы в любом случае — мы наблюдали это в данных. Агент исследует, упирается в ресурсное ограничение и вытесняется, но он и не был на пути к правильному решению.

Однако начиная примерно с 3× эта тенденция меняется: доля успешных решений растёт быстрее, чем снижается доля инфраструктурных ошибок.

В диапазоне от 3× до неограниченного режима инфраструктурные ошибки снижаются ещё на 1,6 процентного пункта, тогда как доля успешных решений подскакивает почти на 4 процентных пункта. Дополнительные ресурсы позволяют агенту пробовать подходы, которые работают только при щедром выделении: подтягивать тяжёлые зависимости, запускать ресурсоёмкие подпроцессы, прогонять требовательные к памяти наборы тестов. При неограниченных ресурсах суммарный прирост относительно 1× составляет +6 процентных пунктов (p < 0.01). На границе возможностей задачи вроде rstan-to-pystan и compile-compcert значительно повышают долю успеха при увеличении запаса памяти.

Как это влияет на измерения

Примерно до 3× от спецификаций Terminal-Bench дополнительные ресурсы устраняют проблемы надёжности инфраструктуры, а именно — кратковременные всплески потребления ресурсов. Провайдер песочниц, которым пользуются разработчики Terminal-Bench, делает это неявно за кулисами: бенчмарк становится стабильнее, но не проще.

Однако выше отметки 3× дополнительные ресурсы начинают активно помогать агенту решать задачи, которые он не мог решить раньше, а значит, лимиты фактически меняют то, что измеряет бенчмарк. Жёсткие ограничения непреднамеренно вознаграждают крайне эффективные стратегии, тогда как щедрые лимиты более снисходительны и поощряют агентов, способных лучше использовать все доступные ресурсы.

Агент, который пишет компактный, эффективный код очень быстро, покажет хорошие результаты при жёстких ограничениях. Агент, который «ломит» решения тяжёлыми инструментами, преуспеет при щедрых лимитах. Оба подхода — вполне легитимные объекты тестирования, но если свести их в единый балл без указания конфигурации ресурсов, различия — а вместе с ними и применимость к реальным задачам — становится трудно интерпретировать.

В задаче bn-fit-modify из Terminal-Bench, требующей подгонки байесовской сети, первым шагом некоторых моделей является установка стандартного стека для Data Science на Python: pandas, networkx, scikit-learn и все их зависимости. При щедрых лимитах это работает. При жёстких — под исчерпывает память ещё на этапе установки, до того как агент напишет хоть одну строку кода решения. Более экономная стратегия существует (реализовать математику с нуля, используя только стандартную библиотеку), и некоторые модели по умолчанию выбирают именно её. Другие — нет. У разных моделей разные подходы по умолчанию, и конфигурация ресурсов определяет, какие из этих подходов оказываются успешными. Мы воспроизвели основной результат на разных моделях Anthropic. Направление эффекта было одинаковым, а величина варьировалась. Те же тенденции, по-видимому, справедливы и для моделей, отличных от Claude, но мы не проводили их строгого тестирования.

Мы также проверили, сохраняется ли этот паттерн на бенчмарках за пределами Terminal-Bench, проведя перекрёстный эксперимент на SWE-bench. Мы варьировали общий объём доступной оперативной памяти до 5× от базового значения на 227 задачах с 10 запусками каждая. Эффект подтвердился, хотя его величина оказалась меньше: баллы снова монотонно росли с увеличением RAM, но при 5× были лишь на 1,54 процентного пункта выше, чем при 1×. Задачи SWE-bench менее ресурсоёмки, поэтому меньший эффект ожидаем, но это показывает, что выделение ресурсов не является нейтральным и здесь.

Другие источники дисперсии

Выделение ресурсов — не единственная скрытая переменная. В определённых конфигурациях свою роль начинают играть и временны́е лимиты.

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

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

Наши рекомендации

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

Учитывая, как среды выполнения контейнеров реально управляют ресурсами — через гарантированное выделение и отдельный порог принудительного завершения, — мы рекомендуем, чтобы бенчмарки указывали оба параметра для каждой задачи, а не одно фиксированное значение. Единая точная спецификация приравнивает гарантированное выделение к порогу уничтожения, не оставляя запаса: кратковременных всплесков памяти, которые мы задокументировали при 1×, достаточно, чтобы дестабилизировать бенчмарк. Разделение двух параметров позволяет дать контейнерам достаточно пространства для манёвра, чтобы избежать ложных OOM-kill, сохраняя при этом жёсткий потолок, предотвращающий завышение баллов.

Зазор между ними следует калибровать так, чтобы баллы при нижнем и верхнем пороге укладывались в пределы шума. Например, в Terminal-Bench 2.0 потолок в 3× от спецификаций для каждой задачи снизил долю инфраструктурных ошибок примерно на две трети (с 5,8 % до 2,1 %, p < 0.001), при этом прирост баллов оставался скромным и вполне в пределах шума (p = 0.40). Это разумный компромисс: инфраструктурный вмешивающийся фактор в значительной мере нейтрализован, а осмысленная ресурсная нагрузка сохранена. Конкретный множитель будет различаться в зависимости от бенчмарка и распределения задач и поэтому должен указываться, но сам принцип эмпирической калибровки универсален.

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

Эти результаты имеют практические последствия за пределами инфраструктуры оценки. Баллы бенчмарков всё чаще используются как входные данные для принятия решений, однако это возросшее внимание (и зависимость) не всегда сопровождается соответствующей строгостью в проведении и документировании тестов. На сегодняшний день преимущество в 2 пункта на таблице лидеров может отражать реальное различие в возможностях — а может означать, что один бенчмарк запускался на более мощном оборудовании, или даже в более удачное время суток, или и то и другое. Без публикации (или стандартизации) конфигураций сетапа извне это трудно определить, если только заинтересованные стороны не приложат дополнительные усилия для воспроизведения объективных результатов в идентичных условиях.

Для лабораторий вроде Anthropic это означает, что конфигурация ресурсов для агентных бенчмарков должна рассматриваться как полноценная экспериментальная переменная — документироваться и контролироваться с той же строгостью, что формат промпта или температура семплирования. Для разработчиков бенчмарков публикация рекомендуемых спецификаций ресурсов (как это делает Terminal-Bench 2.0) — важный шаг вперёд, а указание методологии применения ограничений закрыло бы выявленный нами пробел. А для всех, кто использует результаты бенчмарков, ключевой вывод таков: небольшие различия в баллах агентных бенчмарков несут в себе больше неопределённости, чем подразумевает точность представленных чисел — особенно с учётом того, что некоторые вмешивающиеся факторы просто слишком сложно контролировать.

Пока методология ресурсного обеспечения не стандартизирована, наши данные свидетельствуют, что различия на таблицах лидеров менее 3 процентных пунктов заслуживают скептицизма до тех пор, пока конфигурация бенчмарка не задокументирована и не выровнена. Наблюдаемый разброс в умеренном диапазоне конфигураций ресурсов на Terminal-Bench составляет чуть менее 2 процентных пунктов. Наивные биномиальные доверительные интервалы уже охватывают 1–2 процентных пункта; инфраструктурные вмешивающиеся факторы, которые мы здесь документируем, накладываются поверх этого, а не внутри него. На крайних точках диапазона выделения ресурсов разброс достигает 6 пунктов.

Преимущество в несколько пунктов может сигнализировать о реальном разрыве в возможностях — а может быть просто результатом более мощной виртуальной машины.

Благодарности

Автор — Gian Segato. Особая благодарность Nicholas Carlini, Jeremy Hadfield, Mike Merrill и Alex Shaw за их вклад. Эта работа отражает совместные усилия нескольких команд, занимающихся оценкой агентов для программирования. Заинтересованных кандидатов, желающих внести свой вклад, приглашаем подавать заявки на anthropic.com/careers.