SWE-bench появился в октябре 2023 года как бенчмарк по реальным GitHub-issue: модель получает текст проблемы и снимок репозитория, а затем должна сгенерировать патч, который проходит скрытые тесты. 13 августа 2024 года OpenAI вместе с авторами бенчмарка из Princeton выпустила SWE-bench Verified — подмножество из 500 вручную отобранных задач, призванное убрать неясные формулировки, спорные тесты и проблемы окружения. Исторически это важная версия: в 2024–2025 годах её часто использовали как публичную метрику для coding-агентов, но по сообщению OpenAI от 23 февраля 2026 года компания перестала считать её надёжным индикатором frontier-возможностей. Поэтому ниже — разбор не «вечного стандарта», а конкретного этапа эволюции оценки ИИ-программистов.
Коротко
- Оригинальный SWE-bench — это набор из 2294 задач по реальным issue и pull request из 12 популярных Python-репозиториев GitHub.
- SWE-bench Verified сохранил ту же постановку задачи, но отфильтровал исходный тестовый набор до 500 задач после ручной проверки части исходного тест-сета и перевёл оценку на более воспроизводимый Docker-harness.
- Главная идея Verified была не в том, чтобы «поднять баллы», а в том, чтобы убрать задачи, где правильное решение может быть наказано плохими тестами, неясной формулировкой или нестабильным окружением.
- Для практиков важнее не абсолютный процент, а протокол: разные документы считают результаты на полном наборе из 500 задач, на внутренне валидированном поднаборе из 477 задач, с разными scaffold и числом попыток.
- Как исторический бенчмарк Verified полезен; как единственная метрика выбора coding-агента — уже нет, поскольку OpenAI позже указала на остаточные дефекты тестов и загрязнение обучающими данными.
Контекст: что такое SWE-bench Verified и зачем он понадобился
Авторы оригинального SWE-bench из Princeton предложили бенчмарк, который уходит от коротких задач на автодополнение функции и проверяет более реалистичный сценарий: надо понять issue, найти нужные места в кодовой базе, изменить код и не сломать существующее поведение. В официальной статье и на сайте SWE-bench говорится, что исходный набор включает 2294 задачи, собранные из 12 популярных Python-репозиториев.
Одна задача в SWE-bench строится из пары «issue + уже смёрженный PR». Из PR извлекают тесты, которые до исправления падают, а после — проходят. Модель тестов не видит: она получает только текст issue и состояние репозитория до фикса. На выходе нужен патч.
Именно эта постановка сделала SWE-bench важным для индустрии. Он ближе к реальной работе разработчика, чем изолированные алгоритмические задачки: здесь есть длинный контекст, навигация по репозиторию, скрытые критерии проверки и риск регрессий. Но у такого реализма есть цена: ошибки в данных и в тестах тоже становятся более «реальными».
OpenAI в анонсе Verified прямо перечисляла три причины для переработки исходного теста: часть issue была недоописана, часть unit-тестов могла отвергать функционально верные решения, а часть окружений было трудно стабильно поднять для оценки. Отсюда и возник SWE-bench Verified — не новая задача, а очищенная версия уже популярного бенчмарка.
Метод: как устроен SWE-bench Verified
На уровне интерфейса для модели SWE-bench Verified почти не меняет исходную задачу. Агент по-прежнему получает текст issue и кодовую базу, должен сгенерировать патч, после чего harness применяет патч и запускает тесты. По статье SWE-bench и по более позднему объяснению OpenAI, задача считается решённой только если проходят и тесты, которые должны были починиться, и регрессионные тесты, проверяющие, что старое поведение не сломано.
Ключевое изменение в Verified — фильтрация самих задач. В августовском посте OpenAI и в более позднем февральском разборе говорится, что команда вручную просмотрела 1699 случайно выбранных задач из тестового набора SWE-bench и на этой основе сформировала итоговый Verified-набор из 500 задач. Каждую задачу независимо смотрели несколько аннотаторов, а при отборе пытались убрать три класса проблем: неясные постановки, несправедливые тесты и дефекты окружения.
Вторая важная часть — инфраструктура оценки. OpenAI отдельно подчёркивала, что вместе с авторами SWE-bench участвовала в разработке нового evaluation harness на Docker. Практический смысл здесь простой: если тест зависит от ручной настройки или нестабильной локальной среды, вы измеряете не только модель, но и случайности окружения. Контейнеризация не решает все проблемы, но уменьшает шум.
Если перевести это на язык практики, Verified проверяет четыре вещи одновременно:
- умеет ли система понять issue без подсказки в виде тестов;
- умеет ли она ориентироваться в кодовой базе уровня репозитория, а не отдельной функции;
- может ли внести правку в формате реального патча;
- сохраняет ли она прежнее поведение, а не только «выбивает зелёный тест» на целевой ошибке.
Это уже не просто оценка модели как текстового автодополнителя. Это оценка связки «модель + scaffold + инструменты + harness».
Результаты: что показал Verified и почему цифры часто путают
Самый важный эффект Verified в 2024 году состоял не в том, что он дал «красивое число», а в том, что после очистки задач результаты перестали выглядеть настолько заниженными. В исходной статье SWE-bench лучший результат среди рассмотренных авторами baseline в режиме BM25 retrieval показывал Claude 2 — 1.96% решённых задач. На сайте самого бенчмарка эта цифра повторяется как стартовая baseline-оценка релиза октября 2023 года.
В анонсе Verified OpenAI сообщала, что GPT-4o решает 33.2% задач на SWE-bench Verified; в примечании к посту этот результат привязан к версии gpt-4o-2024-05-13. Позже в OpenAI o1 System Card эта же цифра повторяется для GPT-4o как результат на полном наборе из 500 задач, тогда как остальные модели в том документе считались уже на поднаборе n=477 из-за проблем инфраструктуры.
Отсюда следует практическое правило: headline-числа по SWE-bench Verified нельзя сравнивать без чтения сносок. Ниже — краткая таблица, какие цифры чаще всего смешивают в один ряд, хотя это разные протоколы.
| Источник | Что именно считали | Публичный результат | Как читать |
|---|---|---|---|
| Оригинальная статья SWE-bench и официальный сайт SWE-bench | Исходный SWE-bench, режим BM25 retrieval | Claude 2: 1.96% resolved | Это baseline релиза октября 2023 года на полном исходном тесте, а не результат для Verified. |
| Пост OpenAI Introducing SWE-bench Verified и OpenAI o1 System Card | Полный SWE-bench Verified, 500 задач; для GPT-4o в посте OpenAI указан вариант gpt-4o-2024-05-13 |
GPT-4o: 33.2% | Это один из самых цитируемых результатов Verified, но он относится к конкретному scaffold и полному набору из 500 задач. |
| OpenAI GPT-4o System Card и сноска в OpenAI o1 System Card | Внутренне валидированный поднабор SWE-bench Verified, n=477 |
GPT-4o: 19% pass@1 | Это уже другой evaluation setup: другой поднабор и другой документ. Сравнивать 19% и 33.2% как «ухудшение» некорректно. |
Есть и ещё один слой путаницы: SWE-bench — это бенчмарк не только моделей, но и scaffold. OpenAI прямо писала, что производительность сильно зависит от внешней агентной обвязки. Поэтому рост баллов мог означать не только улучшение базовой модели, но и лучшее планирование, поиск по репозиторию, retries, патч-ревью или оркестрацию инструментов.
Интерпретация
Если смотреть на Verified без хайпа, его историческая заслуга в другом: он нормализовал для индустрии мысль, что «умение программировать» для LLM надо мерить не только по коротким задачам, но и по работе с целым репозиторием, скрытыми тестами и риском регрессий. Это был важный шаг от code completion к агентному software engineering.
В то же время Verified закрепил и другой сдвиг: бенчмарк начал мерить не «чистую модель», а систему. Когда в протоколе важны навигация по репозиторию, стратегия правок, число попыток и работа с окружением, leaderboard неизбежно становится соревнованием agent scaffold.
Наш комментарий
На наш взгляд, SWE-bench Verified полезнее всего читать как переходный бенчмарк. Он показал, что исходный SWE-bench действительно недооценивал часть систем из-за качества самих задач. Но он же показал и вторую вещь: как только бенчмарк становится публичным стандартом, на него начинают оптимизировать не только модели, но и всю обвязку, а затем — и обучающие данные. Иными словами, Verified был важным шагом к более реалистичной оценке, но не конечной точкой.
Для инженера это означает простое правило. Если вы видите score на SWE-bench Verified, спрашивайте не только «сколько процентов», но и:
- какой именно поднабор использовался — 500 или 477 задач;
- какой scaffold стоял вокруг модели;
- сколько было попыток на задачу;
- это локальный прогон, публичный leaderboard или результат из system card;
- какова дата оценки и не обучалась ли система на тех же публичных репозиториях.
Ограничения и критика
Первое ограничение встроено в саму постановку. SWE-bench Verified проверяет сценарий «issue → patch → hidden tests» на популярных Python-репозиториях. Это уже ближе к реальной разработке, чем короткие задачки, но всё ещё не полный цикл software engineering: тут почти нет уточнения требований, общения с командой, ревью, декомпозиции неопределённой задачи или продуктового контекста.
Второе ограничение — зависимость от тестов. И статья SWE-bench, и последующие документы OpenAI опираются на автоматическую проверку через тесты, а значит бенчмарк неизбежно чувствителен к качеству этих тестов. Если тесты слишком узкие, они отвергают правильный функционально патч. Если слишком широкие или неполные, они могут пропускать сомнительное решение.
Третье ограничение — публичность данных. Ещё в 2024 году OpenAI предупреждала, что статический набор задач из публичных GitHub-репозиториев может быть загрязнён обучающими данными. 23 февраля 2026 года компания пошла дальше и заявила, что больше не использует SWE-bench Verified для frontier-оценок, ссылаясь на два класса проблем: остаточные дефекты тестов и contamination, то есть попадание задач и решений в тренировочные данные моделей.
Четвёртое ограничение — несопоставимость протоколов. Даже внутри официальных документов OpenAI рядом существуют результаты на полном наборе из 500 задач и на внутренне валидированном поднаборе из 477 задач. Добавьте к этому разницу в scaffold, retries и harness — и становится понятно, почему сравнение «модель A набрала X%, модель B набрала Y%» без методологической сноски мало что значит.
Наконец, есть ограничение зрелости самого benchmark ecosystem. Verified попытался починить проблемы оригинала, но позже оказалось, что и очищенный набор не свободен от артефактов. Для практиков это не повод выбросить все публичные бенчмарки, а напоминание: любой один тест со временем насыщается и начинает хуже мерить реальный прогресс.
Заключение
SWE-bench Verified был важным этапом в развитии оценки ИИ-программистов: он перевёл разговор от «умеет ли модель дописать функцию» к «может ли система исправить реальную проблему в репозитории и не сломать остальной код». Но его нужно читать исторически и протокольно. Это не универсальная шкала качества coding-агента, а конкретный бенчмарк августа 2024 года со своими допущениями, улучшениями и позднее выявленными дефектами.
Если вам нужен короткий вывод для практики, он такой: SWE-bench Verified полезен как источник задач, абляций и исторических сравнений, но слаб как единственная метрика выбора production-системы для разработки.
Источники
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024 conference paper)
- SWE-bench — official benchmark overview
- Introducing SWE-bench Verified | OpenAI
- SWE-bench Verified — official benchmark overview
- SWE-bench Lite — official benchmark overview
- GitHub – SWE-bench/SWE-bench: SWE-bench: Can Language Models Resolve Real-world Github Issues?
- GPT-4o System Card
- OpenAI o1 System Card
- Why SWE-bench Verified no longer measures frontier coding capabilities | OpenAI
FAQ
Чем SWE-bench Verified отличается от оригинального SWE-bench?
Постановка задачи та же: issue, снимок репозитория, скрытые тесты и требование сгенерировать патч. Разница в том, что Verified — это вручную отфильтрованное подмножество исходного теста, созданное для удаления задач с неясными формулировками, плохими тестами и проблемами окружения.
Почему для GPT-4o встречаются и 33.2%, и 19%?
Потому что это разные протоколы. 33.2% — публичный результат OpenAI на полном Verified-наборе из 500 задач в посте об анонсе. 19% — результат из GPT-4o System Card на внутренне валидированном поднаборе из 477 задач и в другом evaluation setup.
Можно ли использовать SWE-bench Verified для выбора coding-агента в продакшен?
Только как один из сигналов. Он полезен для сравнения issue-resolution сценариев, но не покрывает полный цикл разработки, чувствителен к scaffold и публичности данных, а потому не должен быть единственным критерием.
Почему OpenAI отказалась от этой метрики?
По сообщению самой компании, к 2026 году SWE-bench Verified перестал надёжно измерять frontier-возможности из-за contamination и остаточных дефектов тестов. OpenAI рекомендовала смотреть на более новые coding-eval вместо того, чтобы продолжать сравнивать модели только по Verified.