SWE-Bench признан benchmaxxed: что это значит для оценки моделей

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

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

В r/LocalLLaMA на этой неделе появился разбор, в котором собраны несколько независимых наблюдений. У моделей с высоким SWE-Bench Verified часто проседает качество на новых, не входящих в датасет issue из реальных репозиториев. Закрытые модели OpenAI и Anthropic при тестировании на private hold-out, который собрал Scale AI, показывают gap в 15–25 процентных пунктов вниз по сравнению с публичной ветвью бенчмарка. Открытые модели гонятся за лидербордом и делают то же самое, иногда менее аккуратно.

Параллельно вышла arXiv-работа «Investigating Test Overfitting on SWE-bench» от группы IBM Research (Toufique Ahmed и соавторы). Она формально показывает то, что сообщество называло «benchmaxxing»: системы решения issue overfit'ятся под автогенерированные тесты, технически проходят их, но при этом ломают реальную функциональность. Это первое эмпирическое исследование test overfitting в этой постановке, и его выводы устраняют последние сомнения, что речь идёт о системной проблеме, а не о точечных кейсах.

Как это устроено

Чтобы понять, что именно сломалось, нужно держать в голове, как SWE-Bench работает изнутри. Бенчмарк берёт реальные issue из публичных GitHub-репозиториев (Django, sympy, scikit-learn, ещё штук десять) и просит модель сгенерировать патч, который чинит проблему. Проверка — прогон тестов, которые шли вместе с этой issue. Если тесты зелёные, задача засчитывается.

Проблема в том, что весь датасет — публичный. Включая патчи. Включая тесты. Это значит, что любая модель, которая видела GitHub issues после 2023, де-факто видела ответы. Авторы бенчмарка пытались решить это через cutoff даты, но cutoff обходится через перепарсинг репозиториев, через цитирование в обсуждениях, через прокси-сигналы вроде названий функций.

Дальше начинается индустриальная сторона. Лидеры всегда хвастаются цифрой по SWE-Bench Verified — это «верифицированная» подвыборка из ~500 задач. На фоне $100M+ раундов под «лучшую кодинг-модель» получить +5 пунктов на этом бенчмарке стоит миллионов в evaluation budget. И это создаёт прямой стимул специально подмешивать в обучение варианты, близкие к задачам в датасете.

Что говорит свежая работа

IBM Research в статье фокусируется не на утечках обучения, а на более тонкой проблеме — test overfitting в момент решения. В современных issue-resolution системах модель часто сама генерирует тесты под задачу (потому что в реальных issue их обычно нет), а потом итеративно правит код, пока эти тесты не пройдут. Получается замкнутый цикл, где система оптимизирует код под тесты, которые сама же написала.

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

Сочетание двух эффектов — утечки и test overfitting — даёт суммарную картину: SWE-Bench Verified score 70%+ у топ-моделей (что было невообразимо два года назад) уже не означает, что модель «решает большинство реальных issue». Он означает, что она хорошо проходит конкретный набор тестов на конкретной выборке.

Что предлагают делать

В r/LocalLLaMA сошлись на нескольких механиках. Первая — приватные seed'ы. Кто-то делает свой неопубликованный набор похожих задач и регулярно прогоняет на нём модели. Если на приватном сете цифра проседает на 15+ пунктов относительно публичного — модель overfit'ится. Scale AI ведёт такой private hold-out, у Anthropic есть свой внутренний.

Вторая — сдвиг к свежим issue. Запускать модель на issue, открытых в репозитории после её cutoff даты. Это менее автоматизированный процесс — нужно вручную проверять, что в обсуждении не утекли намёки на решение, — но это даёт более честную метрику.

Третья — пересборка бенчмарков с акцентом на широкие тесты. Вместо «пройти 3 авто-теста» — «пройти 50 тестов, включая регрессионные на функционал, который issue не упоминает». Это резко поднимает планку и убивает test overfitting как стратегию.

Авторы статьи IBM предлагают более радикальный путь — не оценивать решение issue по тестам вообще, а использовать LLM-as-judge с расширенным контекстом, который сравнивает патч с исходной формулировкой issue. Это дорого, но честнее.

Что это значит для индустрии

Главный пострадавший — это рынок, который последние полтора года продавал «GPT-5 решает 75% реальных задач программистов» и «Claude Opus 4.7 — лидер в SWE-Bench». Эти заявления не были ложью технически, но теперь их интерпретация становится более узкой: модель проходит специфический бенчмарк, не обязательно — реальные задачи.

Для разработчиков это значит, что выбор инструмента нельзя строить по лидербордам. Личное тестирование на собственной кодовой базе становится единственно надёжной метрикой. То же говорят люди, которые делают AI-coding продукты вроде Cursor или Claude Code — они давно перестали ориентироваться на SWE-Bench и используют внутренние benchmark'и на собственных задачах.

Для академического сообщества это сигнал, что любой публичный бенчмарк живёт примерно 18–24 месяца перед тем, как его «дрессированно» обходят. Это не уникально для SWE-Bench — то же случилось с MMLU, GSM8k, HumanEval. Это системная проблема методологии оценки.

Для регуляторов это аргумент в пользу обязательных независимых evaluation'ов. Если модель попадает в продакшн в медицине, юриспруденции или критической инфраструктуре, нельзя полагаться на цифры, которые компания приводит сама — нужен внешний аудит на закрытых датасетах.

Куда движется оценка кодинговых моделей

Тренд последних шести месяцев — переход от статичных бенчмарков к live-evaluation. SWE-Bench Live, Aider Polyglot, RepoBench-Plus — все они работают по принципу «новые задачи каждый месяц, старые — переключаются в архив». Это сложнее воспроизводить, но это снимает проблему утечек.

Параллельно растёт интерес к agentic-benchmark'ам — где модель не просто генерирует патч, а должна провести полный цикл от чтения кода до запуска тестов и исправления ошибок. Здесь меньше места для overfitting'а, потому что задача длиннее и многошаговее. Но и оценка дороже, и воспроизводимость ниже.

В будущем, скорее всего, лидерборды разделятся на две части. «Статичные» — для маркетинга и сравнения, с признанием, что они benchmaxxed. И «приватные / live» — для настоящих решений о развёртывании. Если индустрия не сделает этот шаг сама, его сделают регуляторы.

Выводы

История SWE-Bench — это не история про мошенничество одной компании. Это история про то, как любой публичный бенчмарк, на котором завязаны деньги, неизбежно дрессируется. Это закон Гудхарта применительно к ML: «когда мера становится целью, она перестаёт быть хорошей мерой».

Что делать читателю прямо сейчас. Если вы выбираете кодинговую модель — не смотрите на SWE-Bench score, попробуйте на своём проекте. Если вы делаете продукт на LLM — заведите свой внутренний benchmark из задач, которые модель никогда не видела. Если вы исследователь — публикуйте результаты на нескольких evaluation'ах сразу, включая приватный.

Что ожидать дальше — резкое смещение акцентов в академических публикациях с «новый SOTA на SWE-Bench» на «оценка на private + live». На уровне индустрии — больше usage-based метрик: сколько issue реально закрылось, сколько PR прошли code review, сколько багов поймали. Это ближе к бизнес-реальности и дальше от benchmark-маркетинга.