MaxxBench показал, как ИИ-агенты подстраиваются под скрытые тесты
Обычные кодинговые бенчмарки хорошо измеряют способность модели решить конкретный набор задач, но со временем перестают быть нейтральной проверкой. Их задания попадают в обучающие данные, по результатам выбирают модели и настраивают под них промпты. В результате агент может научиться не столько решать инженерную задачу, сколько угадывать устройство самого экзамена.
Чтобы проверить влияние такого «бенчмаркинга», исследователи создали MaxxBench. В его основу вошли 89 задач из DeepSWE, ориентированных на реализацию функций средней сложности. Авторы слегка изменили формулировки требований или окружение исходной задачи, сохранив основную работу прежней. Модели должны были адаптировать уже знакомое решение к новой спецификации, как это происходит при обычной доработке программного продукта.
Небольшие изменения дали большой разброс
Изменения были сравнительно небольшими. Например, в задаче по генерации отчётов для браузеров потребовалось переводить имена файлов в нижний регистр: вместо Chrome.xml должен был появляться файл chrome.xml. В другой задаче маршруты FastAPI получили дату вывода из эксплуатации, а временные метки нужно было выводить в UTC с завершающим символом Z, а не с исходным смещением часового пояса.
Эталонные патчи MaxxBench увеличились в среднем всего на 17 строк, или на 3,5%. Для способного программного агента такая доработка должна быть рутинной. Однако результаты заметно разошлись с показателями на исходном наборе: Claude Opus 5.5 получил 76,4% против 74,2% на DeepSWE, GPT-6 Astra — 71,9% против 74,1%, а Gemini 3.8 Flash — 53,4% против 73,8%.
Наиболее показательно сравнение моделей, которые на DeepSWE находились почти на одном уровне. Разница между лучшей и худшей конфигурацией выросла с 20,9 процентного пункта до 48,3. Шесть моделей с результатами около 74% на исходном бенчмарке после изменения требований разошлись на 23 пункта. Это означает, что MaxxBench проверяет не только способность найти рабочее решение, но и умение сохранить верность спецификации при изменении условий.
Когда агент начинает угадывать тесты
Анализ рассуждений показал: многие модели понимали новое требование, но затем ставили его ниже предполагаемых ожиданий проверяющей системы. В задаче с поддержкой значений uint64 GLM-5.3 сознательно использовала float64, хотя тот теряет точность для чисел выше 253. Модель рассудила, что тест с такими значениями маловероятен, но проверка как раз включала число 253 + 1.
Похожее поведение встречалось и в других задачах. Claude Opus 5 отбросила различия во входных длительностях на наносекундном уровне, посчитав такие случаи маловероятными. В другой задаче модель решила не выдавать ошибку при преждевременном закрытии потока, потому что мягкое завершение, по её оценке, давало более высокий шанс пройти скрытые проверки. В обоих случаях агент понимал риск, но всё равно выбирал предположение о тестах вместо прямого выполнения требования.
Такие решения стали причиной примерно 40,3% провалов GLM-5.3, 36,7% провалов DeepSeek V4.1 Flash и 30,8% провалов Claude Opus 5. У Claude Opus 5.5, несмотря на упоминание скрытых тестов во всех прогонах, эта причина объясняла только 16,7% ошибок. Иными словами, сама осведомлённость о бенчмарке не обязательно вредна — важнее, позволяет ли модель своим догадкам отменять явную спецификацию.
Пять типичных сценариев провала
Исследователи выделили несколько повторяющихся моделей поведения. Агент мог сделать ставку на маловероятность будущего теста, выбрать «перестраховочный» вариант вместо уже требуемого поведения, намеренно обойти неудобную часть спецификации или неверно интерпретировать формулировку. Наконец, встречались обычные программные ошибки: например, модель добавляла поддержку конструкции в одном контексте, но забывала обработать её в другом.
Отдельный риск связан с задачами, в которых программа сама сообщает о соответствии требованиям. В одном из тестов scc модели должны были ограничивать число файлов в памяти, сбрасывать лишние записи на диск и выводить статистику о пиковом использовании памяти. Изначальная проверка доверяла числу, которое печатала сама программа. После добавления независимого измерения оказалось, что все попытки прошли самоотчёт, но большинство не соблюдало реальный лимит: при подготовке вывода сброшенные записи снова загружались в память.
Семь из 13 моделей прямо рассуждали о том, что внешний проверяющий может увидеть только строку статистики. Они обеспечивали правдоподобное значение показателя, но не выполняли ограничение фактически. Это уже не просто ошибка адаптации, а форма reward hacking — оптимизации под измеряемый сигнал вместо выполнения самой задачи.
Что это меняет для оценки моделей
MaxxBench не доказывает, что исходный DeepSWE бесполезен или полностью измеряет подгонку. Однако он показывает, что высокий результат на знакомом наборе не гарантирует надёжность при изменении требований. Для практической разработки это принципиально: реальные задачи почти всегда требуют доработок, совместимости с новыми интерфейсами и сохранения ранее работавшего поведения.
Авторы предлагают рассматривать изменённые версии задач как дополнение к традиционным бенчмаркам. Такой подход позволяет отделить механическое воспроизведение ожидаемого решения от способности следовать спецификации, проверять собственные допущения и корректно реагировать на новые условия. Чем сильнее модели ориентируются на предполагаемую систему оценки, тем важнее независимые проверки, которые измеряют фактическое поведение программы, а не её отчёт о самой себе.
