Почему результаты тестов ИИ-моделей для программирования могут быть обманчивыми

Когда разработчики выбирают ИИ-модель для написания кода, они часто смотрят на таблицы рейтингов (leaderboards). Разница между лидерами обычно составляет всего несколько процентов. Казалось бы, эти цифры точно показывают, какая модель лучше программирует. Но новое исследование Anthropic показывает: дело не только в самой модели.

Оказалось, что настройки серверов, на которых проводятся тесты, могут изменить результаты на 6 процентных пунктов, а это больше, чем разница между первым и вторым местом в рейтинге!

Что такое агентные тесты для программирования

Традиционные тесты для ИИ просто проверяют ответ модели - правильный он или нет. Но современные тесты для программирования (SWE-bench, Terminal-Bench) работают иначе:

• ИИ получает полноценную рабочую среду
• Пишет код, запускает тесты
• Устанавливает нужные программы
• Исправляет ошибки в несколько попыток

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

Суть проблемы: мощность сервера имеет значение

Представьте двух программистов, решающих одну задачу. Один работает на мощном компьютере с 32 ГБ оперативной памяти, а другой на старом ноутбуке с 4 ГБ. Очевидно, что первый сможет запускать более «тяжёлые» программы и библиотеки. То же самое происходит с ИИ-моделями.

Как проводился эксперимент

Исследователи Anthropic запустили один и тот же тест (Terminal-Bench 2.0) на одной модели Claude, но с разными настройками сервера:

1. Строгий режим (1x) - минимум ресурсов, строго по спецификации теста
2. Средние режимы (2x-3x) - в 2-3 раза больше памяти и процессора
3. Без ограничений - неограниченные ресурсы

Результаты удивили

От 1x до 3x: Результаты практически не изменились (+0.8%), но количество технических сбоев упало с 5.8% до 2.1%. Это означает, что дополнительные ресурсы просто помогли избежать «вылетов» программы из-за нехватки памяти.

От 3x до неограниченных ресурсов: Здесь началось интересное - успешность выросла на 4 процентных пункта! Почему? ИИ получил возможность использовать более «прожорливые» подходы к решению задач:

• Устанавливать большие библиотеки данных
• Запускать несколько процессов одновременно
• Проводить объёмные тесты

Пример из реального теста

Одна из задач требовала работы с байесовскими сетями. Некоторые модели сразу пытались установить полный набор инструментов для анализа данных (pandas, networkx, scikit-learn).

• При щедрых ресурсах это работало отлично
• При ограниченных программа «падала» ещё до написания кода решения

При этом существовал более экономный способ - написать математику с нуля, используя только стандартные библиотеки Python. Некоторые модели выбирали его, другие - нет. И конфигурация сервера определяла, какой подход окажется успешным.

Что это меняет для измерений

Получается, что:

• Строгие ограничения поощряют модели, пишущие быстрый и экономичный код
• Щедрые ресурсы дают преимущество моделям, использующим мощные готовые инструменты

Оба подхода имеют право на существование, но если их не различать, то непонятно, что именно мы измеряем: способность модели оптимизировать код или её умение использовать все доступные ресурсы?

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

Ресурсы сервера - не единственная проблема. На результаты могут влиять:

• Время суток - скорость API меняется в зависимости от нагрузки
• Лимиты времени на выполнение задачи
• Скорость интернета для загрузки библиотек
• Общее состояние дата-центра

Исследователи заметили, что результаты одного и того же теста меняются в разное время дня. Причина - колебания скорости работы серверов API.

Рекомендации для честных тестов

Anthropic предлагает следующее:

1. Указывать два параметра вместо одного

Сейчас тесты часто указывают одно точное значение ресурсов (например, «4 ГБ RAM»). Лучше указывать:

• Гарантированный минимум (например, 4 ГБ)
• Максимальный лимит (например, 12 ГБ)

Это даёт запас для временных всплесков использования памяти, но не позволяет бесконтрольно раздувать ресурсы.

2. Публиковать полную конфигурацию

Таблицы рейтингов должны указывать не только результат, но и условия теста:

• Мощность сервера
• Лимиты времени
• Версию используемого ПО

3. Проводить тесты многократно

Запуск теста в разное время суток и усреднение результатов помогает нейтрализовать случайные колебания.

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

Компании и разработчики принимают решения на основе этих рейтингов: какую модель использовать, какую API покупать. Если разница в 2% может быть просто результатом более мощного сервера, а не лучшей модели - это проблема.

Практические выводы и заключение

Для пользователей:

• Разница менее 3% в рейтингах может быть просто шумом
• Смотрите не только на цифры, но и на условия тестирования

Для создателей тестов:

• Документируйте конфигурацию серверов
• Стандартизируйте методологию
• Публикуйте не только результаты, но и условия

Для лабораторий ИИ:

• Относитесь к настройкам ресурсов как к важной части эксперимента
• Указывайте их наравне с температурой генерации и форматом промптов

Лидерство в рейтинге с отрывом в несколько процентов может означать действительно лучшую модель. А может означать просто более мощный сервер для тестирования.

Пока методология тестирования не стандартизирована, к небольшим различиям в результатах стоит относиться скептически. Как говорят исследователи: «Разница в несколько пунктов может означать технологический прорыв, а может просто более мощную виртуальную машину».

Статья основана на исследовании Anthropic, проведённом командой Gian Segato с участием Nicholas Carlini, Jeremy Hadfield, Mike Merrill и Alex Shaw.