Модели набирали 80% на бенчмарке OpenAI. Оказалось, они просто запомнили решения

Компания OpenAI перестала использовать SWE-bench Verified — один из самых популярных бенчмарков для оценки того, насколько хорошо ИИ справляется с реальными задачами по программированию. Компания сама создала этот бенчмарк в 2024 году.

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

Проблемы нашли две.

Первая — тесты отбраковывают правильные решения. OpenAI проверила 138 задач, которые модели стабильно не решали, и в 59% случаев нашла дефекты в самих тестах. Например, тест требует, чтобы функция называлась get_annotation, хотя в описании задачи это имя вообще не упоминается. Любое корректное решение с другим именем функции падает на импорте.

Вторая — ответы попали в обучающие данные. Все задачи SWE-bench взяты из открытых репозиториев, и эти же репозитории используются при обучении моделей. GPT-5.2 при тестировании воспроизводила оригинальные патчи практически дословно. Claude Opus 4.5 по одному только ID задачи цитировала точные комментарии из кода. Gemini 3 Flash выдавала конкретные regex-формулы и номера строк из патча, которого не видела в промпте.

Получается, рост результатов на SWE-bench Verified в последние месяцы (с 74.9% до 80.9%) отражал не улучшение моделей, а то, насколько хорошо они запомнили решения из тренировочных данных.

OpenAI рекомендует переходить на SWE-bench Pro — более новый бенчмарк, где утечка ответов в обучение пока минимальна. Там лучшие модели набирают около 23% вместо 80%. Разница говорит сама за себя.

Русскоязычное сообщество про AI в разработке

Друзья! Эту новость подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

@python_leader
23.02.2026 23:24 UTC
Первоисточник

Комментарии

@muxa_ru
23.02.2026 18:37 UTC
+4

Ну, да, ЕГЭ на каждый год должно быть с новыми заданиями.

@ThisMan
23.02.2026 18:47 UTC
0

Как будто это не баг, а фича. Может просто взять набор важных типовых задач и обучать обучать обучать модели, пока они не станут справляться с этой задачей максимально качественно. И тема самым мы решим проблемы этих задач

Тогда постепенно, закрывая шагами такие задачи, мы сможем продвинуться к какой-то прикладной пользе

@R0uT3r
24.02.2026 05:57 UTC
0

Слишком много различных задач, слишком долго и слишком дорого обучать. Проще натренировать на общем пуле задач и пусть модель закрывает 90% из них. Да и суть в том, что при вашем подходе модель научится решать один очень специфический кейс, а схожие - нет.

@mrsantak
24.02.2026 10:45 UTC
0

Так нейросети заточенные на конкретные задачи существуют давно. Весь хайп вокруг llm построен именно на их способности решать широкий спектр задач.

@ArZr
23.02.2026 20:01 UTC
+6

Первая — тесты отбраковывают правильные решения. OpenAI проверила 138 задач, которые модели стабильно не решали, и в 59% случаев нашла дефекты в самих тестах.

А ведь OpenAI, анонсируя бенчмарк, рассказывали, что они там всё проверили, чтобы таких вот вещей не было. А тут бах - и порядка 16% бенчмарка, оказывается, не работает.

Например, тест требует, чтобы функция называлась get_annotation, хотя в описании задачи это имя вообще не упоминается. Любое корректное решение с другим именем функции падает на импорте.

То есть, они в принципе ни разу не посмотрели, с какими задачами модель плохо справляется и какие результаты получаются в целом? Или они знали это, но все равно продолжали использовать данный бенчмарк?

Если честно, такое "признание" звучит как сдвиг финишных ворот. OpenAI не может догнать Anthropic и/или показать на SWE Bench-Verified, а потому сразу заклеймили бенчмарк негодным.

@Wesha
24.02.2026 02:27 UTC
0

А ведь OpenAI, анонсируя бенчмарк, рассказывали, что они там всё проверили, чтобы таких вот вещей не было. А тут бах — и порядка 16% бенчмарка, оказывается, не работает.

«Ты это... зря слона ругаешь!» ©

@kryvichh
23.02.2026 22:07 UTC
+2

Это странно. По идее, решением задачи на программирование должно быть не совпадение текста программы с эталоном, а совпадение результатов работы программы с эталонной, на разных входных данных.

@Einherjar
23.02.2026 22:20 UTC
0

Это будет так себе тест, потому что созданная программа может выдать полностью ожидаемый результат, но скажем за О(n!) вместо О(n). 

24.02.2026 00:56 UTC
+2

Время работы - это тоже часть результата.

24.02.2026 07:27 UTC
0

Только оно само по себе плохо годится для оценки качества решения в тестах.

Ну вот условно есть у вас на входе три элемента. Выданная программа обработала их за 6 секунд, пусть это является допустимым эталонным временем. Но рассматривая выданную программу как "черный ящик" вы не можете определить это по 2 секунды на каждый (O(n)) или 1 секунда на 1 элемент, 2 на 2 и 6 на 3 (O(n!)), потому что в обоих случаях на тестовом наборе время будет одинаковое, а в реальности на наборе из 1000 элементов разница окажется на порядки.

И вот вам уже надо тестировать два набора данных и время работы на них - большой и маленький и оценивать зависимость.

А все ради чего? Чтобы дать LLM поимпровизировать с решением? А зачем это в тесте? И это мы еще не учитываем случаи когда программа выдаст корректный результат на тестовом наборе входных данных и некорректный на других, что еще хуже чем просто неоптимальная работа.

25.02.2026 20:58 UTC
0

Никто не обещал, что юнит-тесты должны быть исчерпывающими.

Время проверяется на каких-нибудь синтетических тестах. Стресс-тесты, компонентные и интеграционные...

В спецификации обычно есть пожелания "не тупить более чем nnn мс", и если синтетический тест затупил, то надо раздебажить и по результатам- написать регрессионный тест "чтоб больше никогда". Пусть даже это тупо сложение тысячи чисел за заданный таймаут.