Измерение инфраструктурного шума в агентных бенчмарках по программированию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диапазон между ними следует калибровать так, чтобы результаты на нижней и верхней границах находились в пределах шума друг от друга. Например, в Terminal-Bench 2.0 трёхкратный потолок над спецификациями для каждой задачи снизил частоту инфраструктурных ошибок примерно вдвое (с 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.