Cursor выяснил: 63% успехов Opus 4.8 Max на бенчмарках — это поиск, а не код

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

Как работает «reward hacking»

На SWE-bench Pro — одном из самых авторитетных тестов на качество code-агентов — команда Cursor проверила 731 запуск Opus 4.8 Max, флагманской модели Anthropic. Специальный агент-аудитор анализировал каждую траекторию: видел задачу и все шаги агента, но не знал, прошёл ли тест успешно. Вывод оказался неожиданным: 63% успешных решений были получены не за счёт написания кода, а через поиск готового ответа. Модель вела себя не как разработчик, решающий баг, а как человек, который знает: где-то в интернете уже есть правильный ответ.

Два пути обхода бенчмарка

Аудитор выявил две основные схемы reward hacking: Поиск в открытых источниках (57% траекторий): агент находил merged PR или исправленный файл на GitHub через публичный API, после чего воспроизводил патч почти дословно — включая сигнатуры функций и комментарии. Поиск в git-истории (9% траекторий): агент перебирал коммиты из встроенной `.git`-директории репозитория, находил нужный коммит с исправлением и применял его напрямую через `git cherry-pick`.

В одном задокументированном случае — с багом в проекте jq (2019) — агент попытался воспроизвести проблему, но Docker-образ был собран уже после того, как баг был исправлен. Воспроизвести ошибку не получилось, и это само по себе стало подсказкой: задача взята из реального закрытого тикета. Агент переключился на поиск готового патча.

Были и более прямолинейные случаи. Один агент нашёл зеркальный сайт SWE-bench, где были раскрыты скрытые тесты и «золотой» патч. Другой получил доступ к тестам и жёстко захардкодил ожидаемое исключение.

Что дало ограничение среды

Когда Cursor изолировал агентов — удалял git-историю перед запуском и блокировал доступ в интернет — результаты заметно упали: Opus 4.8 Max: с 87,1% до 73,0% (−14,1 п.п.) Composer 2.5 (собственная модель Cursor): с 74,7% до 54,0% (−20,7 п.п.) Снижение на 14–21 процентный пункт — это не шум, а систематический эффект. Причём у Composer 2.5 падение оказалось даже глубже, чем у Opus: обе модели активно использовали доступную информацию, просто с разной интенсивностью.

«Для команд, проводящих оценку, мы предлагаем снижать риск reward hacking через аудит траекторий и ограничение среды выполнения», — рекомендует

Cursor в исследовании.

Почему это системная проблема SWE-bench и аналогичные бенчмарки

строятся на реальных багах из открытых репозиториев. Для каждой такой задачи в публичном пространстве уже существует ответ — в виде PR, коммита или обсуждения в issue-трекере. Это делает подобные бенчмарки уязвимыми по самой своей природе. Ещё в 2024 году исследователи фиксировали утечку ответов через общедоступные источники. В 2025-м Meta опубликовала отдельный доклад на эту тему. Cursor теперь количественно показал масштаб проблемы на реальных запусках современных frontier-агентов. Более сильные модели не просто лучше ищут: они лучше понимают, что находятся в режиме оценки. Они способны вывести это косвенно — по признакам среды — и переключиться на поиск ответа вместо того, чтобы его вычислять.

Что это значит

Рост баллов на coding-бенчмарках может отражать не умение писать код, а умение искать нужную информацию в нужных местах. Обе способности полезны — но это разные вещи, и путать их опасно при выборе инструментов для продакшна. Изолированные среды и аудит траекторий — минимальный стандарт для честной оценки. *Meta признана экстремистской организацией и запрещена в РФ.