SWE-Bench Pro V2 вышла в сентябре 2026 года. Это набор реальных инженерных задач из GitHub-репозиториев, где лучший результат на публичном наборе составил 99,4% в конфигурации Opus 5 с Claude Code (разбор релиза). Цифра выглядит как финишная прямая: почти сто процентов, дальше расти некуда.
Интереснее другое. Рекорд стал возможен после того, как переписали сам экзамен. Аудит OpenAI, опубликованный 8 июля 2026 года, показал, что около 30% заданий исходного набора могут быть сломаны, а приведение набора в порядок потребовало 23 инженеров и 404 часов работы. Сообщество сначала починило измерительный прибор и только потом получило красивое число.
Дальше по порядку: как устроена задача SWE-bench, какие дефекты нашли в заданиях, что именно правили, какие ограничения добавили в протокол V2, почему 99,4% плохо различает лидеров и что с этим делают Hard split и подход METR.
Оговорка по источникам. Публично доступный разбор релиза подтверждает выход V2 в сентябре 2026 года, рекорд 99,4%, состав исходного SWE-Bench Pro (1865 задач из 41 репозитория), типы дефектов заданий и масштаб ревизии: 23 инженера и 404 часа. Доля дефектных заданий и разбивка по исключённым и отредактированным задачам взяты из аудита OpenAI и документации V2; это вендорский анализ, независимого воспроизведения полного аудита не было. Детали протокола, Hard split и метрика METR подтверждены официальной документацией бенчмарка и публикациями METR, но с оговорками, которые указаны в соответствующих разделах.
Что такое SWE-Bench Pro V2 и что показал рекорд 99,4%
SWE-Bench Pro собирает задачи из реальных GitHub-репозиториев: баг-репорты, обсуждения, коммиты. Исходная версия содержала 1865 задач из 41 репозитория. V2 держит ту же идею после ревизии: часть заданий вычистили, часть переформулировали, протокол оценки ужесточили.
Заявленный максимум публичного набора, 99,4%, держит связка Opus 5 с Claude Code. Это модель плюс агентная обвязка, а не модель в вакууме, и деталь важная: в SWE-bench результат всегда принадлежит конфигурации «модель + harness», а не одной весовой матрице. Тот же Opus 5 в другой обвязке покажет другое число, и это нормально для жанра.
Для контекста: на публичном лидерборде V2 Claude Opus 5 (Claude Code) xhigh показывает 99,4%, Kimi K3 — 97,7%, GPT-Astra — 96,9% на полном наборе из 642 заданий (публикация Scale Labs). Отрыв лидера от второго места — 1,7 процентного пункта, и это уже вопрос, который стоит держать в голове до разговора про Hard split.
Как устроена задача SWE-bench: репозиторий, тесты и итоговый патч
Механика простая и потому жёсткая. Агент получает репозиторий в определённом состоянии и текстовое описание проблемы. Дальше он делает то, что делал бы разработчик: читает файлы, разбирает код, запускает тесты, меняет проект. Оценивается не ход рассуждений и не красота комментариев, а итоговый патч: проходит он тесты или нет.
Отсюда растут все проблемы с качеством заданий. Как только единственным судьёй становятся тесты, любой дефект в них превращается в дефект метрики. Тест, который не покрывает суть бага, засчитывает пустышку. Тест, который требует условий, не описанных в задаче, валит корректное решение. Красивое рассуждение агента тут никого не спасает.
Что было сломано в исходном SWE-Bench Pro: типы дефектных заданий
Аудит OpenAI в июле 2026 года дал неприятный результат: примерно каждое третье задание исходного набора содержало дефект. Автоматический фильтр пометил 286 из 731 задания как потенциально сломанные, а человеческая кампания аннотации выявила 249 заданий (34,1%) как сломанные; на основе этих проверок OpenAI оценила долю дефектных заданий примерно в 30% (обзор аудита). Три класса проблем из разбора релиза выглядят так.
Тест отвергает работающий код. Агент нашёл корректное исправление, но проверка требует дополнительного условия, которого нет в тексте задачи. Формально патч решает баг, фактически он не проходит. Агент получает ноль за правильный ответ.
Тест принимает неполное исправление. Обратная ситуация: проверка ловит только часть симптомов. Агент латает поверхность, тесты зеленеют, реальная причина остаётся. Неполный фикс засчитывается как успех.
Ответ можно найти в интернете. Задача оказывается настолько узнаваемой, что готовый патч лежит в открытом доступе: в issue, в форке, в обсуждении. Проверяется качество поиска, а не инженерия.
| Дефект | Что происходит | Как влияет на метрику |
|---|---|---|
| Тест отвергает работающий код | Корректный патч не проходит проверку | Занижает результат |
| Тест принимает неполное исправление | Частичный фикс засчитывается как успех | Завышает результат |
| Ответ доступен в сети | Задача проверяет поиск вместо инженерии | Искажает смысл замера |
Аналогия из материала хорошо передаёт масштаб. Представьте, что вы наняли программиста, дали ему 100 задач из реальных проектов и получили 99 правильных решений. Впечатляюще, пока не выяснится, что часть экзаменационных заданий составлена неправильно.
Дефекты работают в обе стороны. Нельзя сказать, что старый набор просто завышал результат или просто занижал его: он измерял что-то не то, и в какую сторону сместилась ошибка, зависело от конкретной задачи. Сравнивать модели по такому набору можно, но вывод «модель A лучше модели B» на дефектных заданиях не держится.
Тема качества тестов всплывает и в других агентных замерах, и там она меняет результат сильнее, чем кажется. В эксперименте с 25 техниками тестирования агент дал 40,5% полностью успешных прогонов на TDD против 45,1% на дифференциальном тестировании (разбор методики). Разница в 4,6 процентного пункта на ровном месте показывает: тест это часть измерительного инструмента, а не нейтральный фон.
Ревизия бенчмарка в цифрах: 642 задания, 23 инженера, 404 часа
Масштаб работы в документации V2 задан конкретными числами, и они не совпадают с формулировками из ранних пересказов.
| Показатель | Значение |
|---|---|
| Заданий в исходном SWE-Bench Pro | 1865 из 41 репозитория |
| Заданий в v1, от которых шла ревизия | 731 |
| Исключено как невалидные или неисправимые | 89 |
| Осталось валидированных заданий в V2 | 642 в 11 репозиториях |
| Переписано формулировок задач | 529 |
| Пересмотрено тестовых патчей | 214 |
| Пересмотрено эталонных патчей | 38 |
| Исправлено зависимостей в образах | 211 |
| Инженеров | 23 |
| Часов работы | 404 |
89 и 642 в сумме дают ровно 731, то есть ревизия шла от 731 задания v1: 89 отбросили, оставшиеся 642 прошли сквозную перевалидацию (отчёт о релизе). Формулировка «480 заданий названо исправленными» в документации не подтверждается: там фигурируют 529 переписанных формулировок, 214 тестовых и 38 эталонных патчей. Числа 731 и 1865 относятся к разным версиям набора, поэтому противоречия здесь нет: 1865 — исходный SWE-Bench Pro, 731 — та версия, от которой считали ревизию V2.
Арифметика по людям даёт 404 / 23 ≈ 17,6 часа на инженера. Если считать по восемь часов в день, выходит больше двух полных смен на человека. Это не «пробежаться глазами по диффу», и это только авторы правок: проверка исправленных задач шла отдельным контуром.
Почему правка задания сложнее его написания. Нужно восстановить замысел автора: что именно он хотел проверить. Дальше перепроверить тесты на соответствие тексту задачи. И убедиться, что задача решаема по описанию, без знания эталонного патча. Написание задания занимает минуты, восстановление сломанного — часы.
Зачем исправленные задачи перепроверяли разработчики, решая их только по описанию
Схема валидации простая. Разработчик получает текст задачи и репозиторий, без эталонного патча, без подсказок и без комментариев автора. Если задача решается по описанию, формулировка корректна. Если человек не понимает, что от него хотят, дефект остался.
Это прямая защита от главной болезни исходного набора: тестов, которые требуют неописанных условий или противоречат тексту. Автоматическая проверка здесь не работает: программно не определить, что тест проверяет не то, что написано в постановке.
Ограничение тоже очевидное. Ручная валидация дорогая и не масштабируется линейно: каждая новая задача требует человека, а не прогона скрипта. 404 часа не разовая аномалия, а цена качества данных, которую придётся платить при каждом следующем расширении набора. Ровно этот масштаб и подтверждает публичный разбор релиза.
Что изменилось в протоколе оценки SWE-Bench Pro V2
Описание V2 называет два ужесточения протокола. Каждое закрывает конкретный способ получить высокий процент не тем путём, которым его получают в реальной разработке.
Сетевой доступ агента ограничен обращениями к модельному API. Раньше агент мог тянуть из сети зависимости, документацию и, что важнее, готовые решения. Теперь канал утечки ответа перекрыт: остаётся работа с тем, что есть в репозитории.
Финальные патчи повторно применяют и тестируют в чистом контейнере. Это отсекает подмену зависимостей и кэша: агент не может «дожать» тесты правками окружения вместо реального исправления кода.
Граница честности: протокол закрывает известные векторы, а не все будущие. И ограничение сети делает условия менее реалистичными, чем работа живого разработчика, у которого есть доступ к документации и Stack Overflow. V2 отвечает на вопрос «решает ли агент задачу по репозиторию», а не «решает ли он её в тех же условиях, что человек».
Почему чистый контейнер — ключевая деталь, а не формальность
Если тесты прогоняются в окружении, которое агент успел изменить, у него есть несколько обходных путей. Подменить версию библиотеки на ту, где тест проходит. Подсунуть заглушку вместо модуля. Использовать закэшированный результат предыдущего прогона вместо реального выполнения.
Повторный прогон в чистом контейнере воспроизводит ситуацию «свежий клон репозитория плюс твой патч». Именно так работает реальный CI и именно так выглядит проверка любого пул-реквеста. Аналогия из code review: патч, который проходит только на машине автора, рабочим не считается, каким бы зелёным ни был лог.
Почему 99,4% — плохая метрика для сравнения лидеров
Эффект потолка. Когда несколько конфигураций упираются в 99% и выше, разница между ними лежит в пределах шума: одно-два задания меняют картину. Метрика перестаёт различать модели ровно в тот момент, когда рынку нужно сравнение.
Арифметика при 642 заданиях. Одно задание это около 0,16 процентного пункта. Разница между 99,4% и 97,7% — это примерно 11 задач. Разница в полпроцента между двумя лидерами — три-четыре задачи, что легко объясняется вариативностью прогонов, температурой, порядком вызовов инструментов и версией harness.
Что реально говорит высокий процент: агент уверенно решает этот класс задач. Чего он не говорит: какой агент лучше. Для выбора инструмента нужен второй сигнал, а лучше третий. Похожая проблема есть у любого бенчмарка на реальных задачах разработки: пока он заявлен, но не раскрыт, выводы по нему строить не на чем (разбор Real-SWE и его ограничений).
Hard split: 51 сложное задание как второй сигнал
Hard split это подмножество из 51 задания, выделенное отдельно от общего набора. Критерий формирования: задание провалили как минимум два из пяти семейств моделей в рамках заблокированного протокола, и каждое из них проходит с эталонным патчем и проваливается с пустым патчем (документация набора). Три задания, позже признанные неоднозначными, из подмножества исключили.
Механика: сложные задачи снимают потолок. Когда конфигурация упирается в 99% на общем наборе, разница видна только там, где задачи требуют многошаговых правок, понимания чужого кода и аккуратной работы с тестами. На таком подмножестве обнажаются различия в стратегиях: один агент дольше исследует репозиторий, другой быстрее пишет патч и чаще ошибается.
Ограничение прямое: 51 задание это маленькая выборка. Одно задание здесь весит около 2 процентных пунктов. Точный разброс результатов на Hard split вроде 52,9%–98,0% в доступных источниках не подтверждён: подтверждены только размер подмножества и критерий его формирования. Поэтому Hard split стоит читать как индикатор направления, а не как точный рейтинг. Смотреть надо на оба числа сразу: общий результат показывает, что класс задач освоен, Hard split показывает, кто впереди на сложном крае.
Подход METR и task-completion time horizon как альтернатива подсчёту решённых задач
Идея альтернативы: измерять не долю решённых задач, а длину задачи, которую агент доводит до конца с заданной надёжностью. Метрика называется task-completion time horizon и выражается во времени выполнения той же задачи человеком: сколько часов или минут работы специалиста агент закрывает автономно (описание метрики METR).
Как её считают. Сначала METR оценивает время выполнения каждой задачи экспертом-человеком. Затем для каждого агента подбирает логистическую кривую вероятности успеха в зависимости от длительности задачи и находит точку пересечения кривой с порогом успеха — 50% или 80%. 50%-й горизонт — это длительность, при которой агент, по прогнозу, добьётся успеха в половине случаев.
Логика простая. Доля решённых задач насыщается: рано или поздно набор упирается в потолок, и различия исчезают. Горизонт времени так не упирается, потому что задачи можно удлинять: больше файлов, больше шагов, больше зависимостей. Чем больше горизонт, тем более автономна система. По данным METR, эта метрика экспоненциально росла последние 6 лет с временем удвоения около 7 месяцев (публикация METR).
Ограничения тоже нужно называть. Горизонт зависит от методики оценки времени человеком: разные эксперты дают разные оценки одной задачи. Он чувствителен к типу задач: горизонт в правке документации и в отладке гонки потоков сравнивать бессмысленно. Страница горизонтов METR больше не обновляется активно, а измерения выше 16 часов ненадёжны при текущем наборе задач. И горизонт не заменяет проверку качества патча: агент может «закрыть» длинную задачу формально, а результат всё равно придётся смотреть глазами.
Как читать бенчмарки AI-агентов после истории с SWE-Bench Pro V2
Пять вопросов к любому бенчмарку агентов, которые экономят время при выборе инструмента.
- Когда и как ревизовался набор заданий. Был ли независимый аудит, сколько задач исключили, кто проверял исправления. Если набор не ревизовался ни разу, доля дефектных заданий неизвестна, и это уже риск.
- Что именно измеряется. Патч и тесты, время выполнения, стоимость успешного решения. Число без метрики не значит ничего.
- Есть ли сложное подмножество и какой на нём разброс. Общий результат 99% плюс отдельный Hard split говорят о системе больше, чем одна строка в таблице.
- Как ограничен сетевой доступ и воспроизводится ли окружение. Чистый контейнер, повторный прогон патча, фиксированные версии зависимостей. Без этого высокий процент может быть артефактом настройки.
- Достаточна ли выборка для заявленной разницы. 51 задание не различает 96% и 98%. На маленьком подмножестве разница в две задачи не повод менять инструмент.
Практический вывод для выбора: 99,4% на публичном наборе это повод присмотреться к конфигурации Opus 5 с Claude Code, а не доказательство её превосходства. Смотреть стоит на Hard split, на условия протокола и на собственные задачи. Готовый каркас для такого мини-набора с harness, автоматическими проверками и метриками стоимости описан в разборе Terminal Bench 4.0 (как собрать свой evaluation-набор), а логика трёх наборов задач и ускорения итераций разобрана в методологии Deep Agents (Harbor, τ³-bench, ContextBench).
Цена качества данных измеряется человеко-часами. В случае SWE-Bench Pro V2 это 23 инженера и 404 часа, потраченные до того, как появилась первая строчка с 99,4%. Любой бенчмарк, который показывает красивое число без истории о ревизии заданий, заслуживает как минимум вопроса: что в нём чинили и чинили ли вообще.