Разбор бенчмарка CyberGym: что на самом деле измеряет оценка E2E

Оценка CyberGym, которая распространена шире всего — число из поста о запуске, то, которое сравнивают между моделями, — это доля успешных задач по 131 отфильтрованной задаче, где успех означает, что агент создал входные данные proof-of-concept, которые приводят к сбою непропатченной сборки C/C++, написал патч, останавливающий этот сбой, и не сломал написанные разработчиками проекта тесты. В сводке BenchLM MiMo-V2.6-Flash лидирует с 95,1%, а MiMo-V2.6-Pro — с 94,0%, при этом DeepSeek-V4.1-Flash отстаёт на несколько пунктов и находится в верхней части диапазона восьмидесятых. Почти никто из тех, кто цитирует эту таблицу, не упоминает три вещи, от которых зависит, сопоставимы ли эти числа: бенчмарк существует более чем в одной реализации, большинство строк — это самоотчёты провайдеров, а не независимые прогоны, и самый интересный этап фиксируется, но не учитывается. Это тот же стандарт указания источников, который архив инцидентов ИИ применяет к своим собственным записям — утверждение без источника не является результатом — и корпус CyberGym не соответствует ему чаще, чем можно судить по его репутации.

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

Задача: найти, воспроизвести, исправить — ничего не сломав.

CyberGym происходит из Berkeley Center for Responsible, Decentralized Intelligence, и его замысел намеренно узок. Каждая задача нацелена на уязвимость памяти в широко используемом open-source-проекте на C/C++. Агент должен найти ошибку, написать входные данные proof-of-concept, вызывающие сбой sanitizer'а, а затем исправить код так, чтобы сбой больше не воспроизводился, — при этом собственные тесты проекта должны продолжать проходить. Именно в этой последовательности весь смысл. Бенчмарк, который просил бы только «найти ошибку», вознаграждал бы распознавание паттернов; требование рабочего входного файла, вызывающего сбой, и не ломающего тесты патча заставляет агента замкнуть цикл от подозрения к продемонстрированному дефекту и к исправлению.

RDI размещает этот бенчмарк внутри более широкой обсерватории, которая отслеживает кибервозможности ИИ на этапах атаки и защиты, и на эту рамку стоит обратить внимание: CyberGym — лишь один инструмент на стенде, наряду с ExploitGym и сквозным вариантом. Если читать его как отдельный лидерборд, этот контекст теряется, и это одна из причин, почему цифры плохо переносятся.

Четыре этапа, три из которых приносят баллы

Правило начисления баллов — наименее освещаемая часть бенчмарка, потому что именно здесь правдоподобно звучащая оценка может разойтись с тем, что произошло в действительности.

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

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

Как были выбраны 131 задача — и как это влияет на оценку

{{1}}Исходный набор данных{{/1}} больше, чем {{2}}оцениваемый набор{{/2}}, и фильтрация — самый мощный рычаг влияния на сопоставимость. {{3}}Набор данных RDI{{/3}} содержит 920 уязвимостей в 139 проектах с открытым исходным кодом, взятых из Google's OSS-Fuzz. {{4}}Сквозной вариант{{/4}}, используемый сторонними трекерами, сужает его до 131 задачи — по одной на проект; задачи отбираются по сложности, при этом исключаются задачи с утечками оракула или ограничениями совместимости с песочницей.

Отсюда напрямую следуют три последствия. Во-первых, одна задача на проект означает, что оценка определяется широтой, а не глубиной: агент, показывающий средние результаты по многим проектам, превзойдёт того, кто отличен на трёх, — это обоснованный выбор дизайна и иное измерение, нежели «сколько уязвимостей этот агент способен исправить». Во-вторых, исключение утечек из оракула убирает задачи, где ответ можно обнаружить из среды, а не вывести рассуждением, поэтому оставшийся набор сложнее в определённом смысле — он убирает лазейки, а не лёгкие задачи. В-третьих, бюджет в 90 минут на задачу в песочнице, созданной из OSS-Fuzz-образа проекта, является частью определения успеха, а не деталью, потому что значительная доля реальной работы над уязвимостями ограничена именно такого рода условиями, и агенты, зависящие от неограниченного исследования, здесь потерпят неудачу, тогда как в других местах добьются успеха.

Любое сравнение, игнорирующее правило выбора задачи, сравнивает два разных теста, которые лишь случайно совпадают по названию.

Две реализации, и почему они не обязаны совпадать

Именно здесь кроется большая часть путаницы. CyberGym-E2E существует и как бенчмарк RDI, и как реализация, запускаемая сторонним оценщиком, и нет гарантии, что эти два варианта дадут одинаковое число для одной и той же модели. Документация самого оценщика говорит об этом прямо: в его реализации используется отфильтрованный набор из 131 задачи, по одной на проект, отобранных по сложности, и каждая задача запускается в изолированной песочнице, собранной из OSS-Fuzz-образа проекта, с использованием собственного каркаса агента и бюджетом в 90 минут на задачу.

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

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

Честно читая таблицу трекера

Таблица, с которой сталкивается большинство людей, — это вторичная сводка, и она сама указывает своё происхождение — что и полезно, если прочитать эту пометку. Из 29 строк 7 взяты у владельца бенчмарка или из независимого прогона, 21 — самоотчёты провайдеров, и одна — вторичный отчёт. В сводке прямо сказано, что таблица приведена для справки и по ней не составляется рейтинг, а также рекомендуется читать её с осторожностью, поскольку большинство строк — самоотчёты. Её собственное примечание о насыщении — самая полезная строка на странице: три верхние позиции разнесены примерно на 70 пунктов, тогда как десять верхних укладываются примерно в 10, поэтому таблица всё ещё различает модели — но не на верхнем краю диапазона, где упорядочивание слабо различимо.

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

Та же осторожность применима в обратном направлении к ловушке, которую этот бенчмарк ставит перед читателями: отсутствие строки CyberGym у модели не означает, что она набрала ноль. Она не измерялась в этом стенде — это другое утверждение. Трактовка отсутствия как провала — это то, как таблица перестаёт быть измерением и становится лидербордом.

Что означает и что не означает высокая оценка для защитника

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

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

Это не значитчто агент понимает вашу кодовую базу, вашу модель угроз или ваше развёртывание. Задачи взяты из публичных таргетов OSS-Fuzz с известной эталонной уязвимостью и набором тестов, который сообщает агенту, закончил ли он работу. В продакшен-коде нет такого оракула. Это также не значит, что агент найдёт именно этот баг, а не какой-то баг: этап 4 существует потому, что они расходятся, и этап 4 не засчитывается.

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

Что нужно спросить, прежде чем доверять цифре CyberGym

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

• Какая реализация? Бенчмарк RDI или отфильтрованный вариант стороннего оценщика. Если в отчёте это не указано, число ни с чем не сопоставимо.

• Чей прогон? Независимая оценка или самоотчёт поставщика. В сводной таблице это указывается для каждой строки; в большинстве маркетинговых материалов — нет.

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

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

• Какой набор задач? 131 задача по одной на проект, выбранная по сложности, — это обычный набор; другой фильтр — это другой тест.

Cybergym — хорошо построенный бенчмарк для сложной реальной задачи, и его устройство интереснее, чем его таблица лидеров. Этапы показывают, что должен был сделать агент; фильтрация показывает, что именно отражает счёт; харнесс показывает, кому принадлежит заслуга. Число, которое сопровождается этими тремя компонентами, действительно полезно. Число, которое появляется само по себе, — это пресс-релиз со знаком процента.