SWE-bench: как читать рейтинг кодинг-агентов и не обмануться

Когда Anthropic, OpenAI или очередная стартап-команда выкатывает новую модель, в анонсе почти наверняка мелькнёт строчка вида «X% на SWE-bench Verified». Это стало отраслевым стандартом: если раньше модели меряли на HumanEval и MMLU, то способность агента чинить реальный код теперь принято показывать именно здесь. Проблема в том, что за одним названием прячется несколько разных наборов задач, разные условия запуска и разные способы посчитать успех — и проценты из двух пресс-релизов часто просто несопоставимы.

Что такое SWE-bench

SWE-bench — это набор задач, собранных из реальных issue и pull request в популярных Python-репозиториях на GitHub (django, scikit-learn, sympy, matplotlib и других). Каждая задача устроена так: агенту дают состояние репозитория и текст issue, а он должен сгенерировать патч, который решает проблему. Правильность проверяется не человеком и не другой моделью, а прогоном тестов из того самого PR, в котором задачу когда-то закрыли живые разработчики.

Это ключевое отличие от бенчмарков вроде HumanEval, где модель пишет одну функцию по докстрингу. Здесь агенту нужно ориентироваться в чужой кодовой базе на десятки тысяч строк, найти нужные файлы, понять контекст и внести изменение, которое не сломает остальное. Задача ближе к тому, что делает инженер поддержки, чем к олимпиадному программированию.

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

Почему версий несколько

Оригинальный SWE-bench вышел с несколькими тысячами задач, но у него быстро нашли слабые места: часть задач была решаема некорректно, часть — практически нерешаема из-за неполного описания, а тесты иногда проходили по причинам, не связанным с патчем. Отсюда выросли производные наборы.

• SWE-bench (full) — исходный полный набор задач. Большой, шумный, редко используется в анонсах напрямую.
• SWE-bench Lite — уменьшенная подвыборка для более быстрого и дешёвого прогона.
• SWE-bench Verified — подмножество задач, вручную проверенных инженерами на корректность и решаемость. Именно эту версию чаще всего цитируют в заголовках.
• SWE-bench Multimodal — задачи с визуальным контекстом (например, баги во фронтенде, где важен скриншот).

Когда кто-то говорит «мы взяли 70% на SWE-bench», первый вопрос — на какой именно версии. Результат на Verified и на full — это разные числа для одной и той же системы, и Verified почти всегда выше, потому что из него убрали нерешаемый мусор.

Почему цифры нельзя сравнивать в лоб

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

На что смотреть, прежде чем верить числу:

1. Версия набора. Verified, Lite или full — это разные знаменатели.
2. Что за scaffold. Собственная агентная система вендора, открытый фреймворк или «голая» модель без агента.
3. Бюджет попыток. Один прогон или лучший из нескольких (pass@k). Разрешено ли агенту гонять тесты и итерироваться.
4. Какая метрика. Обычно это доля задач, где итоговый патч прошёл все тесты (resolved rate).
5. Кто считал. Официальный лидерборд с проверкой сабмишена или график из презентации самого вендора.

Метрика, которая на самом деле важна

Основная цифра SWE-bench — % resolved, доля задач, где сгенерированный патч прошёл скрытые тесты. Она не учитывает, красивый ли код, не сломал ли патч что-то за пределами тестов и сколько это стоило по токенам. Поэтому высокий процент — необходимое, но не достаточное условие «хорошего инженера». Стоимость прогона на задачу и время всё чаще указывают рядом, и для практика они не менее важны, чем сам процент.

Как выглядит сравнение

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

Загрязнение данных

Отдельная головная боль — data contamination. Задачи SWE-bench взяты из публичных репозиториев, которые с высокой вероятностью попали в обучающую выборку крупных моделей. Если модель во время обучения «видела» правильный PR, она может воспроизвести его не потому, что рассуждает, а потому что помнит. Авторы бенчмарка и независимые команды работают над свежими наборами задач, датированными после cutoff-даты моделей, но полностью проблему это не снимает. Это ещё одна причина не читать разницу в один-два процентных пункта между двумя системами как реальное превосходство.

Что с этого практику

Если вы выбираете кодинг-агента для работы, а не пишете научную статью, извлеките из рейтинга следующее:

• Смотрите на порядок величины, а не на десятые доли процента: разница между 40% и 65% что-то значит, между 64% и 65% — почти нет.
• Проверяйте, тестируется ли связка целиком или голая модель. В реальной работе вы всё равно пользуетесь агентом (Cursor, Claude Code, Copilot и подобными), а не сырым API.
• Бенчмарк — Python-центричный. Если вы пишете на Go, Rust или фронтенде, результат SWE-bench переносится на вашу задачу лишь косвенно.
• Гоняйте собственную мини-выборку задач из вашего репозитория. Ни один публичный рейтинг не заменит проверки на вашем коде и вашем стиле ревью.

SWE-bench — честная попытка мерить агентов на реальном коде, и в этом его ценность. Но проценты из заголовков стоит читать как показания на спидометре чужой машины: полезно, чтобы понять класс, бесполезно, чтобы предсказать, как поедете вы.