Инфраструктурный шум: почему бенчмарки ИИ-агентов зависят от ресурсов
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Исследование Anthropic показало, что различия в выделении CPU и памяти могут менять результаты тестов ИИ-агентов на 6 процентных пунктов. Авторы призывают публиковать конфигурацию среды вместе с рейтингами, так как текущие цифры отражают не только возможности модели, но и условия ее запуска.
Без учета инфраструктурных факторов сравнение моделей по бенчмаркам становится ненадежным, что искажает выбор инструментов для разработки.
В мире оценки искусственного интеллекта сложился парадокс: две системы, использующие одну и ту же языковую модель, могут показать разницу в результатах до шести процентных пунктов исключительно из-за различий в вычислительных ресурсах. Исследователи из Anthropic опубликовали работу, в которой детально разбирают феномен «инфраструктурного шума» при тестировании ИИ-агентов, способных писать и запускать код. На платформе Terminal-Bench 2.0 разница между самой строгой конфигурацией с жесткими лимитами и неограниченной средой оказалась значительнее, чем типичный разрыв между соседними позициями в верхней части рейтингов. Это ставит под сомнение саму суть сравнения моделей, если не учитывать среду их выполнения.
В отличие от статических тестов, где модель просто отвечает на вопрос, агент взаимодействует с реальной операционной системой: он устанавливает зависимости, запускает компиляторы и создает дочерние процессы. Каждый из этих шагов зависит от доступной памяти и скорости процессора. Если ресурса не хватает, установка пакета может прерваться, а сборка — замедлиться, что приведет к исчерпанию тайм-аута до завершения задачи. Таким образом, среда перестает быть пассивной оболочкой и становится активным участником процесса решения. Два агента с разными лимитами ресурсов фактически проходят разные тесты, даже если набор задач и базовая модель у них идентичны.
Команда Anthropic провела эксперимент на базе Google Kubernetes Engine, запустив Terminal-Bench 2.0 в шести различных конфигурациях. Результаты показали интересную динамику: при увеличении ресурсов от базового уровня до трехкратного прироста (3x) основная польза заключалась не в улучшении качества решений, а в повышении стабильности среды. Доля инфраструктурных ошибок снизилась с 5,8% до 2,1%, однако общая успешность задач оставалась статистически неизменной. Это свидетельствует о том, что многие сбои при жестких лимитах были ложными: агент упирался в потолок ресурсов, не успев найти верный путь к решению.
Ситуация меняется после отметки 3x. Дальнейшее увеличение ресурсов начинает напрямую влиять на способность агента решать сложные задачи. От трехкратного до неограниченного режима успешность выросла почти на четыре процентных пункта, а доля ошибок упала до 0,5%. В совокупности это дало прирост в шесть процентов. Эффект воспроизвели и на других моделях компании, хотя величина различалась. На более простых задачах из набора SWE-bench влияние ресурсов было слабее — всего 1,54% разницы между минимальным и пятикратным лимитом памяти, что логично объясняется меньшими требованиями этих задач к ресурсам.
Ключевой вывод исследования заключается в том, что ресурсы меняют саму природу измеряемого. Жесткие лимиты вознаграждают экономные стратегии: написание компактного кода и использование стандартных библиотек. Щедрые же лимиты позволяют применять «тяжелые» инструменты: устанавливать крупные фреймворки вроде pandas или scikit-learn, которые могут исчерпать память при установке в ограниченном режиме. Ни одна из стратегий не является объективно правильной, но их эффективность зависит от условий. Сведение этих разных подходов к одному числу в рейтинге без указания конфигурации делает результат непереносимым на реальные условия работы.
Помимо ресурсов, на результаты влияют и другие факторы: задержки API, состояние кластера и даже время суток, когда проводится тестирование. Anthropic отмечает, что процент прохождения задач может колебаться в зависимости от нагрузки на инфраструктуру. Поскольку внешние исследователи не могут контролировать серверы инференса, они предлагают ряд практических мер для повышения прозрачности. Во-первых, необходимо разделять гарантированный объем ресурсов и жесткий потолок, чтобы избежать ложных срабатываний OOM (Out of Memory). Во-вторых, множитель запаса ресурсов должен калиброваться эмпирически для каждого конкретного бенчмарка.
Авторы исследования рекомендуют рассматривать конфигурацию ресурсов как экспериментальную переменную, которую нужно документировать так же строго, как параметры промпта или температуру генерации. Пока методика распределения ресурсов не стандартизирована, к разнице в результатах меньше трех процентов стоит относиться скептически, если условия запуска не опубликованы. Бенчмарки остаются полезным инструментом, но цифры в рейтинговых таблицах следует воспринимать как зашумленные оценки, а не как абсолютную истину о способностях модели. Для принятия взвешенных решений необходимо требовать от разработчиков полного описания среды, в которой проводились тесты.