Новые бенчмарки для AI-кодинга: что проверяют Program-Bench, SRE-Bench и Code Migration

Коротко: эти бенчмарки проверяют инженерное мышление

Program-Bench, SRE-Bench и Code Migration смещают фокус оценки AI-кодинга с генерации функции по ясному условию на работу с неизвестной или неполной системой. В заявленном фокусе Program-Bench модель восстанавливает поведение программы по бинарному файлу и наблюдаемым результатам, SRE-Bench проверяет понимание работающего приложения без исходного кода, а Code Migration оценивает перенос рабочего решения на другой язык с сохранением его поведения.

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

Это важная граница интерпретации. В доступных материалах нет подтвержденных протоколов и численных результатов Program-Bench, SRE-Bench и Code Migration, поэтому дальше разбирается их заявленный класс задач, инженерная ценность и ограничения сравнения.

Главное изменение: проверяется работа с поведением системы, а не с текстом программы

Обычная coding-задача начинается с формального условия. Например, требуется написать функцию, которая принимает массив чисел и возвращает отсортированный результат. Набор тестов заранее определяет, что считать правильным ответом.

В задаче на неизвестную систему исходные данные устроены иначе. У модели может быть бинарный файл, исполняемое приложение, ограниченный интерфейс или исходный код на одном языке, который требуется перенести на другой. Скрытые требования приходится восстанавливать по входам, выходам, ошибкам и состоянию среды.

Рабочая последовательность здесь включает четыре шага:

1. зафиксировать доступные артефакты и ограничения;
2. подобрать информативные входные данные;
3. сравнить наблюдаемое поведение с гипотезой;
4. проверить результат на обычных, ошибочных и пограничных сценариях.

Такой процесс ближе к инженерному исследованию. Модель должна объяснить, почему система ведет себя определенным образом, и подтвердить это повторяемым экспериментом.

Почему один высокий балл не превращает LLM в автономного инженера

Любой benchmark измеряет поведение агента внутри заранее заданных границ. На итоговый score влияют доступный контекст, набор инструментов, количество попыток, лимит времени, подготовка окружения и способ проверки результата.

В рабочем проекте появляются дополнительные факторы: неполная документация, расхождение между тестовой и production-средой, закрытые сервисы, нестабильные зависимости, требования безопасности и цена ошибки. Удачный порт в песочнице может нарушить контракт соседнего сервиса. Верное объяснение локальной ошибки не дает права менять production без review и rollback.

Поэтому результат бенчмарка нужно читать как сигнал о конкретном навыке. Score отвечает на вопрос «как модель справилась с этим классом задач при этих условиях», но не на вопрос «можно ли передать ей весь жизненный цикл инженерной работы».

Почему привычных бенчмарков для оценки LLM в кодинге уже недостаточно

Популярные coding-бенчмарки остаются полезными. Они дают воспроизводимую задачу, формальный критерий и возможность сравнивать версии моделей. Проблема возникает, когда результат из одного класса тестов трактуют как универсальную оценку разработчика.

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

LiveCodeBench и задачи с явно заданной целью

LiveCodeBench относится к классу тестов, где модель получает формулировку задачи и должна выдать решение, которое проходит автоматическую проверку. Такой формат удобен для сравнения: правильность можно выразить через pass rate, а повторяемость зависит от ясности условий и стабильности harness.

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

Для олимпиадного алгоритма это преимущество методики. Для легаси-кода часть инженерной сложности исчезает еще до начала работы. Program-Bench и Code Migration переносят эту сложность внутрь задания: модель должна разобраться с имеющимся поведением или сохранить его при смене среды.

Terminal-Bench и агентная работа в окружении

Terminal-Bench добавляет к генерации кода действия в терминале. Агент может читать файлы, запускать команды, редактировать проект, собирать программу и проверять тесты. Это ближе к рабочему циклу, чем ответ в одном блоке текста.

Однако вывод зависит от конкретной среды. Разрешенные команды, установленные пакеты, структура репозитория, лимиты времени и автоматическая проверка меняют сложность одного и того же задания. Доступ к терминалу сам по себе не означает, что агент умеет исследовать неизвестное приложение или безопасно менять инфраструктуру.

Практическая сторона оценки Terminal-Bench подробно разобрана в статье о том, как оценивать кодинг-агентов без гигантских бенчмарков. Для собственного сравнения полезно учитывать токены, latency, стабильность и стоимость успешного решения, а не смотреть на одно место в лидерборде.

Что остается между задачей и реальным проектом

Между формализованной задачей и рабочей системой лежат несколько источников риска:

• неявные контракты, которые не описаны в README;
• исторические исключения и временные обходы, ставшие частью поведения;
• различия между документацией и фактическими ответами приложения;
• зависимости, конфигурация и ограничения инфраструктуры;
• закрытые сервисы, права доступа и сетевые политики;
• стоимость ошибки для данных, пользователей и доступности сервиса.

Новый benchmark может проверять один или несколько таких навыков. Ни один набор задач автоматически не закрывает весь разрыв между песочницей и production.

Program-Bench: что это и зачем модели восстанавливать поведение по бинарнику

Program-Bench в заявленном фокусе относится к задачам программного reverse engineering. Модель получает бинарный файл или доступ к наблюдаемому поведению программы и должна построить совместимую версию. Такой сценарий отличается от синтеза кода с нуля: исходная логика уже существует, но ее намерения и структура скрыты.

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

Что должна сделать модель: наблюдать, формулировать гипотезу, проверять

Практическая цепочка для такой задачи может выглядеть так:

1. Инвентаризация. Модель фиксирует формат бинарника, доступные точки запуска, аргументы, файлы конфигурации и ограничения среды.
2. Эксперименты. Она подает короткие и контрастные входы: пустое значение, минимальный размер, повторяющиеся элементы, некорректный формат.
3. Наблюдение. Записываются stdout, stderr, код возврата, созданные файлы, время выполнения и изменения состояния.
4. Гипотеза. Наблюдения превращаются в правило обработки данных, а не в единичное описание результата.
5. Проверка. Новые входы должны подтвердить правило. Если результат расходится, гипотезу требуется уточнить.
6. Совместимая версия. Реализуется поведение с теми же форматами ответа, ошибками и существенными ограничениями.

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

Почему бинарник не раскрывает намерения разработчика

Бинарный файл показывает исполняемое поведение и часть технических следов. Он не возвращает автоматически исходные комментарии, смысл имен, архитектурные причины, полный набор типов, скрытые зависимости и все условия запуска.

Здесь полезна аналогия с реверс-инжинирингом детали. 3D-сканирование собирает геометрию видимой поверхности, но не восстанавливает само по себе номинальные размеры, допуски, замысел конструктора и скрытые элементы. Для разных целей нужны разные измерения: оптический сканер, контактные измерения, КИМ, микрометр, нутромер или компьютерная томография.

Программный reverse engineering устроен иначе, но логика ограничения похожа: наблюдаемое поведение не равно полному описанию внутренней системы. Аналогия помогает отделить измеренный факт от предположения о том, почему система устроена именно так.

На практике сначала нужно определить требуемый результат. Им может быть совместимый CLI-интерфейс, библиотека с теми же ошибками, отчет о поведении или версия для другой среды. Формулировка «сделать копию» слишком расплывчата для надежной проверки.

Где высокий результат может вводить в заблуждение

Процент успешных решений Program-Bench нельзя переносить на анализ произвольного коммерческого ПО без ответов на несколько вопросов:

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

Детерминированная консольная утилита с коротким API и сервис, который зависит от сети, базы данных и времени, создают разный уровень неопределенности. Один score не сообщает, где именно находится тестируемый сценарий на этой шкале.

SRE-Bench: что это и как оценивать понимание приложения без исходников

SRE-Bench в заявленном фокусе проверяет способность понять работу реального приложения при отсутствии исходного кода. SRE здесь означает Site Reliability Engineering, то есть инженерную работу с надежностью, диагностикой и поведением сервисов.

Задача такого типа ближе к расследованию системы, чем к написанию алгоритма. Модель должна связать действия пользователя, ответы интерфейса, ошибки, состояние приложения и доступные сигналы в проверяемое объяснение.

От запуска приложения к модели его поведения

Исследование можно разложить на последовательность наблюдений:

1. выполнить базовую операцию и зафиксировать нормальный результат;
2. изменить один параметр и сравнить ответ;
3. повторить действие в другой последовательности;
4. проверить ошибочный ввод и восстановление после ошибки;
5. выделить зависимость от конфигурации, состояния или внешнего сервиса;
6. повторить сценарий, чтобы отделить закономерность от случайного сбоя.

Например, исчезновение записи после перезапуска может объясняться кешем, отложенной записью, неверным подключением к базе или особенностью интерфейса. Наблюдение фиксирует симптом. Причину подтверждает только эксперимент, который различает эти гипотезы.

Для отдельного контекста диагностики полезен разбор IssueBench и оценки агента-диагноста. Он показывает, почему качество диагностики нужно раскладывать на отдельные критерии, а не сводить к одному ответу «проблема найдена».

Почему здесь особенно важны неполные данные

Приложение может скрывать состояние, часть логов может быть недоступна, а тестовая конфигурация может отличаться от рабочей. Внешний API способен возвращать нестабильные ответы. Документация может описывать желаемое поведение, тогда как пользователи зависят от исторического исключения.

Надежное решение должно разделять три уровня:

• факт: операция с конкретными входами дала конкретный ответ;
• гипотеза: причиной может быть определенная зависимость или переход состояния;
• проверка: дополнительный эксперимент подтвердил или опроверг гипотезу.

Такая дисциплина нужна и человеку, и AI-агенту. Уверенный текст без повторяемого шага проверки не превращается в диагностику.

Что SRE-Bench не обязан доказывать

Понимание приложения в подготовленной среде не равно безопасному реагированию на инцидент в production. Для реальной эксплуатации нужны отдельные проверки:

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

Бенчмарк может измерить анализ сигналов и качество объяснения. Политику изменений, ответственность и безопасность среды он заменяет только в том случае, если эти критерии прямо включены в протокол, чего нельзя предполагать без первичного описания.

Code Migration benchmark: проверка сохранения смысла при переносе кода

Code Migration benchmark оценивает перенос работающего кода с исходного языка или платформы на целевой язык с сохранением требуемого поведения. Перевод синтаксиса здесь служит лишь промежуточным действием. Функционально корректный порт должен сохранить контракты, ошибки, форматы данных и взаимодействие с соседними компонентами.

Синтаксически корректный код может пройти компилятор и все равно изменить смысл программы. Различия в типах, исключениях, асинхронности и библиотеках часто проявляются только на редких входах или под нагрузкой.

Что именно нужно сохранить при миграции

Перед переносом следует составить список наблюдаемых контрактов:

• публичные функции, параметры и возвращаемые значения;
• форматы JSON, CSV, сообщений и файлов;
• коды ошибок, тексты исключений и условия их возникновения;
• порядок операций и побочные эффекты;
• поведение на пустых, больших, поврежденных и граничных данных;
• таймауты, требования к памяти и ограничения производительности;
• интеграции с базами, очередями, файловой системой и внешними API.

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

Типичные места, где ломается эквивалентность

Набор рисков зависит от исходного и целевого языка, но несколько классов ошибок встречаются регулярно:

• Типизация: неявное приведение строк, чисел и булевых значений может давать другой результат.
• Пустые значения: null, None, undefined и аналогичные значения отличаются правилами сравнения и распространения.
• Числа: целочисленное переполнение, точность с плавающей запятой и деление требуют отдельной проверки.
• Исключения: порядок перехвата, тип ошибки и момент ее возникновения могут измениться.
• Асинхронность: порядок завершения операций, отмена и обработка гонок зависят от runtime.
• Память: время жизни объектов, копирование и освобождение ресурсов устроены по-разному.
• Кодировки и время: Unicode, локаль, часовые пояса и переход на летнее время способны менять output.
• Библиотеки: похожее имя пакета не гарантирует совпадение поведения и ограничений.

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

Как проверить, что миграция действительно удалась

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

Полезны четыре группы тестов:

1. Позитивные: типовые входы и ожидаемые успешные ответы.
2. Негативные: поврежденные данные, пропущенные поля, неверные типы и недоступные зависимости.
3. Граничные: пустые значения, максимальные размеры, нулевые и отрицательные числа, повторные вызовы.
4. Интеграционные: реальные форматы сообщений, транзакции, таймауты и порядок взаимодействия.

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

Program-Bench, SRE-Bench и Code Migration против LiveCodeBench и Terminal-Bench

Эти названия описывают разные измеряемые способности. LiveCodeBench фокусируется на решении формализованной задачи, Terminal-Bench добавляет действия в подготовленной среде, Program-Bench проверяет восстановление поведения, SRE-Bench связывает наблюдения работающего приложения, а Code Migration проверяет сохранение контрактов при переносе.

Таблица ниже показывает разницу в постановке. Она не ранжирует бенчмарки по сложности и не утверждает, что один формат заменяет другой.

Какие способности измеряет каждый тип задач

Удобно разделять способности на пять групп:

• синтез: написать код по явной спецификации;
• инструментальная работа: выполнить действия в терминале и собрать проект;
• вывод по наблюдениям: восстановить поведение программы без исходников;
• диагностика: связать сигналы приложения в проверяемую модель;
• адаптация: перенести рабочее решение и сохранить его смысл.

Эти способности пересекаются, но не совпадают. Агент, который хорошо редактирует репозиторий, может плохо выбирать эксперименты для черного ящика. Модель с сильным синтаксическим переводом может пропустить изменение семантики null-значений или исключений.

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

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

Допустим, одна модель получила 70 процентов на задачах с готовыми unit-тестами, а другая, 55 процентов на задачах с ограниченным наблюдением приложения. Эти числа не отвечают на вопрос, какая модель лучше для миграции конкретного сервиса. Они описывают разные наблюдения.

Публичные цифры хорошо иллюстрируют эту проблему. Для GLM-5.3 приводились значения 28,3 на Terminal Bench 3.0, 66,9 на DeepSWE, 28,5 на Agents' Last Exam и 1769 на GDPVal-AA. Сам набор показателей не объясняет устройство каждого теста и не доказывает качество модели на Program-Bench, SRE-Bench или Code Migration.

Как читать результаты новых AI coding-бенчмарков без лишних выводов

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

Сначала методология, затем лидерборд

Проверяйте benchmark в такой последовательности:

1. Источник и версия. Кто выпустил набор, когда обновлялись задачи, доступен ли репозиторий и можно ли повторить запуск.
2. Формулировка. Что получает модель: условие, исходный код, бинарник, интерфейс, логи или несколько артефактов.
3. Контекст. Какой объем файлов и инструкций доступен, есть ли скрытое состояние и внешние зависимости.
4. Инструменты и права. Может ли агент запускать команды, обращаться к сети, менять файлы и повторять эксперименты.
5. Попытки. Сколько раз модель может исправить решение, как обрабатываются таймауты и частичные результаты.
6. Метрика. Проверяется pass rate, точное совпадение, набор контрактов, ручная оценка или комбинация критериев.
7. Цена и время. Сколько токенов, вызовов и секунд требуется на успешную попытку.
8. Утечки. Есть ли риск, что задачи или решения попали в обучающие данные модели.

Воспроизводимость иногда полезнее впечатляющей цифры. Закрытый протокол с одним score плохо подходит для решения о модели, если его нельзя сопоставить с собственным стеком и повторить на безопасной среде.

Отдельный риск связан с тем, что модель может распознавать знакомый формат теста. Для обсуждения расхождения между benchmark-оценками и практической работой пригодится разбор model card и evaluation awareness.

Вопросы, которые стоит задать перед выбором модели

Перед выбором LLM или AI-агента для инженерной задачи ответьте на пять вопросов:

• Похожи ли тестовые задачи на наш стек, легаси-код и типичные сбои?
• Нужно ли передавать модели закрытый код, внутренние логи или данные пользователей?
• Есть ли локальный режим или изолированная среда для чувствительных материалов?
• Можно ли повторить основной сценарий с эталонными тестами и ограниченными правами?
• Кто проверяет изменения и отвечает за решение перед отправкой в рабочую систему?

Для локальной LLM добавляются ограничения GPU, VRAM, скорости инференса и длины контекста. Большая модель может лучше удерживать многофайловую задачу, но ее стоимость и latency могут сделать агент неудобным для частых итераций. Маленькая модель может оказаться выгоднее на узком сценарии с хорошими тестами.

Цифры Terminal-Bench, DeepSWE или другого набора помогают сформировать список кандидатов. Для выбора между ними нужны собственные проверки на унаследованном коде, диагностике тестового сервиса и ограниченной миграции.

Практический вывод: бенчмарки помогают выбрать сценарий для пилота

Program-Bench, SRE-Bench и Code Migration расширяют представление о coding-способностях модели. Они направляют внимание на восстановление поведения, работу с неполным контекстом и сохранение смысла при переносе. Такой фокус ближе к отдельным инженерным операциям, чем тест на написание изолированной функции.

Используйте benchmark как фильтр и источник гипотезы. Решение о применении принимайте после контролируемой проверки на собственном сценарии.

Какой пилот даст больше информации, чем общий score

Выберите один повторяемый кейс с четким критерием успеха:

1. изолированный модуль легаси-кода с закрытым набором тестов;
2. ограниченная миграция одной библиотеки или сервиса;
3. диагностика тестового приложения без доступа к исходникам;
4. восстановление поведения небольшой утилиты с фиксированными входами.

Подготовьте безопасную среду и эталонные проверки. Измеряйте факт прохождения тестов, число итераций, стоимость токенов, время решения, количество ручных исправлений и качество объяснения. Для Program-Bench добавьте негативные и пограничные входы. Для SRE-Bench фиксируйте, какие выводы подтверждены наблюдением. Для Code Migration сравнивайте исходную и целевую версии на одинаковых данных.

Контроль человека, review, тесты, журнал действий и ограниченные права обязательны для чувствительных систем. Benchmark может подсказать, где AI-агент полезен уже сейчас. Готовность к самостоятельной работе доказывает только стабильный результат на вашей среде и под вашей ответственностью.

Подписаться на канал