OpenAI нашла, что треть SWE-Bench Pro сломана: что это значит для AI-кодинга

OpenAI отзывает рекомендацию SWE-Bench Pro после аудита задач. Что значит 30% broken tasks для AI-кодинга, leaderboard и внутренних evals компаний.

OpenAI SWE-Bench Pro: график Scale AI о бенчмарке для AI-кодинга

OpenAI нашла, что треть SWE-Bench Pro сломана: что это значит для AI-кодинга

Факты проверены 8 июля 2026 года. OpenAI SWE-Bench Pro теперь стал примером того, как быстро ломается доверие к бенчмарку, когда модели догоняют сам тест. SWE-Bench Pro - это бенчмарк для оценки AI-агентов на реальных задачах программирования. 8 июля 2026 года OpenAI сообщила, что после аудита считает около 30% задач публичного split сломанными и отзывает прежнюю рекомендацию использовать этот бенчмарк.

Главный вывод аудита OpenAI: высокий процент на SWE-Bench Pro может смешивать способность модели писать код с шумом в самих задачах. В этом шуме есть слишком строгие тесты, недоописанные промпты, слабое покрытие и условия, которые ведут модель в неправильную сторону.

Что произошло

OpenAI проверила public split SWE-Bench Pro на 731 задачу. По данным компании, её pipeline отметил 200 задач как broken, то есть 27,4%. Отдельная human annotation campaign нашла 249 таких задач, или 34,1%. Поэтому OpenAI оценивает общую долю сломанных задач примерно в 30%.

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

OpenAI отдельно связывает корректность evals с deployment и safety decisions. Значит, дело не сводится к маркетинговому сравнению моделей. Если оценка способностей искажена, по ней можно принять плохое решение о выпуске модели, уровне ограничений, закупке инструмента или приоритетах исследовательской команды.

Почему это ударило именно по SWE-Bench Pro

SWE-Bench Pro появился как более сложная и реалистичная замена SWE-bench Verified. Scale описывала его как набор из 1 865 задач: 731 public, 858 held-out и 276 commercial. Public split открыт, а held-out и commercial splits должны были снижать риск подгонки под тест.

Идея была понятной: дать AI-агенту задачу из истории реального репозитория, попросить внести изменение и проверить результат тестами. По сравнению со старым SWE-bench Verified задачи в Pro должны были быть длиннее, реалистичнее и ближе к работе агентного coding assistant.

График Scale сравнивает SWE-Bench Verified и SWE-Bench Pro по resolved rate
Scale при запуске показывала SWE-Bench Pro как более сложный набор задач по сравнению с SWE-Bench Verified. Это исторический график запуска, а не текущий рейтинг моделей. Источник: Scale AI.

В феврале 2026 года OpenAI уже писала, что SWE-bench Verified больше не даёт полезного сигнала для frontier coding models. Тогда компания нашла проблемы в Verified и рекомендовала сообществу перейти на SWE-Bench Pro. Июльский аудит неприятен именно этим: бенчмарк, который должен был стать следующей ступенью, сам оказался заметно шумным.

Какие задачи OpenAI считает сломанными

OpenAI выделяет четыре основных типа проблем. Эти категории пригодятся и исследователям бенчмарков, и инженерным командам: почти те же ошибки встречаются во внутренних evals, когда компания быстро собирает набор задач для проверки нового coding agent.

Тип проблемы Что это значит Как искажает score Что проверить во внутренних evals
Overly strict tests Тесты требуют конкретную реализацию, хотя prompt этого не просит. Функционально правильное решение может получить провал. Можно ли решить задачу другим корректным способом и всё равно пройти тесты.
Underspecified prompts Условие не описывает требования, которые потом проверяют hidden tests. Модель проваливает задачу из-за скрытого требования, хотя код мог быть разумным. Поймёт ли опытный разработчик ожидаемое поведение без доступа к тестам.
Low-coverage tests Тесты проверяют слишком узкий кусок нужной функции. Неполное решение может выглядеть успешным. Покрывают ли тесты основные ветки, ошибки и крайние случаи.
Misleading prompt Условие толкает модель к поведению, которое расходится с тестами. Score наказывает модель за следование тексту задачи. Нет ли противоречия между описанием, эталонным патчем и тестами.

Самый наглядный пример в разборе OpenAI - задача OpenLibrary-77c16d5. Prompt показывал один ведущий пробел в Markdown-выводе, а hidden tests требовали два. Модель, которая точно следовала видимому примеру, могла провалиться из-за одного символа. Такой провал мало говорит о способности агента исправлять код, зато много говорит о качестве задания.

Почему высокий score уже нельзя читать без методики

OpenAI пишет, что на public split из 731 задачи frontier models за восемь месяцев выросли с 23,3% до 80,3% pass rate. Без контекста это выглядит как большой скачок качества. После аудита возникает другой вопрос: какая часть роста отражает способность модели, а какая связана с тем, что сильные модели лучше обходят или угадывают особенности конкретного теста.

Мы уже разбирали, почему 100% в бенчмарке ИИ-агентов не всегда означает реальную способность. SWE-Bench Pro добавляет к этой теме более приземлённую проблему. Здесь не нужна прямая лазейка в тестовой среде. Достаточно скрытого требования, узкого теста или условия, которое допускает несколько корректных решений, а проверяющая система признаёт только одно.

Поэтому один leaderboard score стал слишком коротким фактом. Для coding agents нужно смотреть, как собраны задачи, кто проверял тесты, были ли повторные прогоны, насколько scaffold помогает или мешает модели, что считается успехом и как обработаны спорные случаи.

График Scale показывает resolved rate моделей SWE-Bench Pro по языкам JavaScript, Go, TypeScript и Python
Scale при запуске SWE-Bench Pro показывала разбивку resolved rate по языкам. В статье этот график используется как контекст о дизайне Pro, а не как актуальный leaderboard. Источник: Scale AI.

Чем история Pro отличается от старой истории Verified

С Verified главной проблемой были остаточные ошибки в тестах и загрязнение данных: модели могли видеть задачи, решения или связанные фрагменты во время обучения. OpenAI тогда писала, что результаты всё хуже отражают реальную способность к автономной разработке и всё больше зависят от контакта модели с benchmark data.

С Pro акцент другой. OpenAI проверяет качество задач в наборе, который был задуман как более трудный и защищённый. Компания не утверждает, что каждый результат в SWE-Bench Pro ложный. Она говорит жёстче и точнее: существенная доля задач public split даёт плохой сигнал, поэтому прежнюю рекомендацию использовать SWE-Bench Pro нужно отозвать.

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

Что делать командам, которые выбирают coding agent

Публичные бенчмарки не надо выбрасывать. Они помогают быстро понять общий уровень моделей и заметить сдвиги рынка. Но покупать инструмент, менять engineering workflow или допускать агента к критичному коду только по одному score теперь особенно рискованно.

Практичный минимум выглядит так.

  • Соберите private eval из реальных задач вашей команды: баги, миграции, тесты, изменения API, типичные code review замечания.
  • Проверьте каждую задачу вручную: условие, тесты, эталонное решение и альтернативные корректные решения.
  • Запускайте несколько моделей в одном и том же scaffold, иначе в результат попадёт и модель, и обвязка.
  • Смотрите на pass/fail и на путь решения: какие файлы агент нашёл, какие тесты запускал, где застрял.
  • Отделяйте задачи на локализацию кода, написание патча, генерацию тестов и работу с большим контекстом. Мы уже видели на SWE-Explore, что агент может найти нужный файл, но ошибиться на уровне строк и связей внутри кода.
  • Фиксируйте цену повторных прогонов. Для coding agents важны проценты успеха, число попыток, токены, время и вмешательство человека.

Если внутренний eval нужен для safety или compliance-решения, требования должны быть ещё жёстче. Нужны приватные задачи, контроль утечек, независимая проверка тестов и отдельный разбор failures. Иначе компания быстро получит свой маленький SWE-Bench Pro: красивую таблицу, которая плохо отвечает на главный вопрос.

Что не стоит выводить из аудита OpenAI

Первый неверный вывод: «все coding benchmarks бесполезны». Это слишком грубо. Бенчмарки остаются полезным инструментом, если понятно, что именно они меряют и где у них границы.

Второй неверный вывод: «OpenAI доказала, что результаты всех моделей в SWE-Bench Pro ложные». Аудит говорит о сломанных задачах и плохом сигнале в значительной части public split, а не о мошенничестве лабораторий и не о полной недействительности каждого числа.

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

Короткий ответ: что случилось с OpenAI SWE-Bench Pro?

OpenAI провела аудит SWE-Bench Pro и оценила, что около 30% задач public split сломаны. Pipeline компании отметил 200 из 731 задач, human annotation campaign - 249 из 731. После этого OpenAI отозвала прежнюю рекомендацию использовать SWE-Bench Pro.

FAQ

Почему OpenAI отозвала рекомендацию SWE-Bench Pro?

Потому что аудит нашёл существенную долю задач с проблемами в тестах или описании. Такие задачи могут неправильно наказывать корректные решения или засчитывать неполные.

Можно ли теперь доверять coding benchmarks?

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

SWE-Bench Pro полностью непригоден?

OpenAI не формулирует вывод так широко. Компания оценивает около 30% задач public split как broken и советует разработчикам моделей внимательно проверять результаты. Это сильный сигнал против слепого доверия, но не запрет на любое использование данных.

Что использовать вместо одного leaderboard score?

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

Источники и дата проверки

Факты проверены 8 июля 2026 года. Данные о моделях, leaderboard и методиках быстро меняются; численные сравнения нужно перепроверять перед повторным использованием.

Читайте также

Telegram-канал @toolarium