23 лютого 2026 р.

Чому SWE-bench Verified більше не вимірює передові можливості програмування

SWE-bench Verified використовує дедалі більше спотворених даних. Ми рекомендуємо використовувати SWE-Bench Pro.

Завантаження…

Відтоді як ми вперше опублікували SWE-bench Verified у серпні 2024 року, індустрія широко використовує його для вимірювання прогресу моделей у завданнях автономної програмної інженерії. Після випуску SWE-bench Verified дав переконливий сигнал прогресу можливостей та став стандартною метрикою, що вказується у релізах передових моделей. Відстеження та прогнозування прогресу цих можливостей є також важливою частиною Програми готовності OpenAI. Коли ми спочатку створили бенчмарк Verified, ми спробували вирішити проблеми у вихідній оцінці, через які деякі завдання було неможливо виконати в датасеті SWE-bench⁠(відкривається у новому вікні).

Після початкових стрибків актуальний прогрес на SWE-bench Verified сповільнився, показавши покращення⁠(відкривається у новому вікні) з 74,9% до 80,9% за останні 6 місяців. Це піднімає наступне питання: чи відображають збої обмеження моделі, чи властивості самого набору даних?

У рамках нового аналізу ми виявили дві основні проблеми з набором Verified, які вказують на те, що бенчмарк більше не підходить для вимірювання прогресу в можливостях автономної програмної інженерії для передових запусків за сьогоднішніх рівнів продуктивності:

Тести відхиляють коректні рішення: Ми провели аудит 27,6% підмножини набору даних, з яким моделі часто не справлялися, і виявили, що щонайменше 59,4% перевірених завдань містять дефектні тести, які відхиляють функціонально коректні відправки, незважаючи на всі наші зусилля щодо покращення цього на початковому етапі.
Навчання на рішеннях: Оскільки великі передові моделі можуть засвоювати інформацію зі свого навчання, важливо, щоб їх ніколи не навчали на завдання та рішення, за якими їх оцінюють. Це схоже на те, якби перед майбутнім тестом викладач поділився зі студентами завданнями та рішеннями: вони можуть і не завчити відповідь, але студенти, які вже бачили відповіді, напевно впораються краще, ніж ті, хто їх не бачив. Завдання SWE-bench беруться з репозиторіїв з відкритим вихідним кодом, які багато постачальників моделей використовують із метою навчання. У ході нашого аналізу ми виявили, що всі передові моделі, які ми протестували, змогли відтворити вихідне, написане людиною виправлення помилки, використане як достовірний еталонний орієнтир, відоме як gold patch, або дослівні деталі постановки задачі для деяких завдань, що вказує на те, що всі вони бачили принаймні частину цих завдань.

Ми також виявили свідчення того, що моделі, які бачили ці завдання під час навчання, із більшою ймовірністю досягнуть успіху, оскільки вони мають додаткову інформацію, необхідну для проходження недостатньо певних тестів.

Це означає, що покращення на SWE-bench Verified більше не відображають значних покращень реальних здібностей моделей до розробки програмного забезпечення. Натомість вони дедалі частіше свідчать про те, наскільки сильно модель піддавалася впливу тесту під час навчання. Ось чому ми перестали вказувати результати SWE-bench Verified, і рекомендуємо іншим розробникам моделей зробити так само.

Ми розробляємо нові, не забруднені даними бенчмарки, що дозволяють краще відстежувати навички програмування, і вважаємо, що це важлива сфера, на якій варто зосередитись ширшій дослідницькій спільноті. Поки у нас немає таких бенчмарків, OpenAI рекомендує повідомляти результати щодо SWE-bench Pro.

Фон

Оригінальна оцінка SWE-bench⁠(відкривається у новому вікні) була випущена у 2023 році. Кожне завдання було взято із закритої проблеми на GitHub в одному з 12 репозиторіїв Python з відкритим вихідним кодом та зіставлено з відповідним pull request (PR). Щоб визначити, чи зміна коду, що згенерована моделлю, є коректною, до кожного завдання додаються два набори тестів:

Тести, які не можна пройти на незміненій кодовій базі, але можна пройти, якщо проблема була коректно виправлена
Регресійні тести, які можна пройти як до, так і після виправлення, щоб переконатися, що непов'язана функціональність залишається недоторканою.

Модель не бачить тести. Вона має сформувати зміну коду, маючи лише вихідний текст проблеми та стан репозиторію до виправлення. Завдання зараховується лише в тому випадку, якщо після застосування зміни коду вдається пройти всі тести.

Ми виявили у цій оцінці безліч проблем, які можуть призвести до заниження можливостей моделей.

Деякі модульні тести були надто специфічними або не відповідали завданням: коректні виправлення могли бути відхилені.
Багато формулювань завдань були недостатньо визначені, що могло призвести до кількох допустимих інтерпретацій, тоді як тести охоплювали лише одну конкретну.
Залежно від налаштувань оточення (наприклад, Linux vs Windows або версії Python) деякі тести можуть помилково завершуватися збоєм

Для вирішення цих проблем у 2024 році було створено SWE-Bench Verified. Спільно з досвідченими інженерами-програмістами ми перевірили 1699 завдань SWE-bench і відфільтрували завдання, в яких були ці проблеми. Кожне завдання було незалежно розглянуте трьома експертами. Цей процес перевірки призвів до появи SWE-bench Verified — ретельно відібраного набору із 500 завдань.

Занадто вузькі та надто широкі тести

Хоча SWE-bench Verified — це суттєве покращення порівняно з початковою версією, ще залишаються невирішені проблеми. Ми провели аудит 138 завдань SWE-bench Verified, які OpenAI o3 не міг вирішити стабільно протягом 64 незалежних прогонів. Кожен випадок був незалежно розглянутий як мінімум шістьма досвідченими інженерами-програмістами. Якщо експерт вказував на проблему, вона перевірялася ще раз іншою командою.

Ми виявили, що 59,4% із 138 завдань містили суттєві проблеми в дизайні тесту та/або описі завдання, через що їх було вкрай важко чи неможливо вирішити навіть найздібнішій моделі чи людині.

35,5% перевірених завдань мають суворі тестові сценарії, що нав'язують конкретні деталі реалізації, роблячи недійсними багато функціонально коректних рішень; ми називаємо їх вузькими тестовими сценаріями.
18,8% перевірених завдань містять тести, які перевіряють додаткову функціональність, не зазначену в описі задачі, і це ми називаємо широкими тестовими сценаріями.
Решта 5,1% завдань мали різного роду проблеми, які складно було згрупувати в рамках цієї класифікації.

Яскравий приклад першого режиму відмови — pylint-dev__pylint-4551⁠(відкривається у новому вікні), де PR вводить нову функцію `get_annotation` як частину загального рішення. Це ім'я функції не згадується в описі завдання, але безпосередньо імпортується тестами. Хоча деякі моделі можуть інтуїтивно дійти до створення такої функції, строго кажучи, немає необхідності реалізовувати функцію з цим конкретним ім'ям, щоб коректно вирішити завдання. Багато коректних рішень не дозволяли пройти тест через помилки імпорту.

Опис проблеми

Простий текст

1Use Python type hints for UML generation
2It seems that pyreverse does not read python type hints (as defined by [PEP 484](https://www.python.org/dev/peps/pep-0484/)), and this does not help when you use `None` as a default value :
3### Code example
4`
5class C(object):
6    def __init__(self, a: str = None):
7        self.a = a
8`
9### Current behavior
10Output of pyreverse :
11![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12### Expected behavior
13I would like to see something like : `a : String` in the output.
14### pylint --version output
15pylint-script.py 1.6.5,
16astroid 1.4.9
17Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

Тестовий фрагмент PR

Python

1+from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node

Збої тестів PR (скорочено для зручності читання)

Python

1==================================== ERRORS ====================================
2_____________ ERROR collecting tests/unittest_pyreverse_writer.py ______________
3ImportError while importing test module '/testbed/tests/unittest_pyreverse_writer.py'.
4Hint: make sure your test modules/packages have valid Python names.
5Traceback:
6/opt/miniconda3/envs/testbed/lib/python3.9/importlib/__init__.py:127: in import_module
7    return _bootstrap._gcd_import(name[level:], package, level)
8tests/unittest_pyreverse_writer.py:32: in <module>
9    from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node
10E   ImportError: cannot import name 'get_annotation' from 'pylint.pyreverse.utils' (/testbed/pylint/pyreverse/utils.py)

Приклад надто широких тестових сценаріїв — sympy-sympy-18199⁠(відкривається у новому вікні). Це завдання було взято з PR, в якому було усунуто три окремі проблеми з функцією `nthroot_mod`, а саме #17373⁠(відкривається у новому вікні), #17377⁠(відкривається у новому вікні) та #18212⁠(відкривається у новому вікні). Однак опис завдання SWE-bench Verified охоплює лише фінальну проблему #18212⁠(відкривається у новому вікні). Це створює невідповідність: PR-тести охоплюють усі три проблеми, тоді як у описі докладно розглядається лише одна. У наших запусках моделі часто коректно реалізують описане виправлення, а потім провалюють тести, які охоплюють реалізацію двох інших проблем.

Оригінальний опис PR (з PR на GitHub)

Простий текст

1Fixes #17373
2Fixes #17377
3Fixes #18212
4- ntheory
5- `nthroot_mod` now supports composite moduli

Опис проблеми для #18212

Простий текст

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Опис проблеми для завдання SWE-bench Verified (взято тільки з #18212):

Простий текст

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Забруднення

SWE-bench Verified та репозиторії (кодові бази та примітки до випуску) є відкритими та широко використовуваними та обговорюваними, що ускладнює уникнення забруднення даних для розробників моделей.

Ми вперше зіткнулися з ознаками забруднення у наших власних моделях. Наприклад, коли GPT‑5.2 вирішив 31 завдання, яке ми визначили як майже нездійсненні. У django__django-14725⁠(відкривається у новому вікні) тести вимагають конкретного нового параметра `edit_only`, який явно не потрібний для постановки завдання. При розв'язанні задачі GPT‑5.2 показав у своєму ланцюжку міркувань (CoT), що має інформацію про примітки до випуску, в яких детально описані зміни в кодовій базі, і коректно визначив, що параметр `edit_only` був введений в Django 4.1.

Ланцюжок роздумів GPT‑5.2

Простий текст

1There is also `edit_only` parameter maybe added around 4.1 or 4.2. Since this is 4.1 dev 2022, the code might be before introduction. We will implement now. Hidden tests will check new behavior.

Щоб оцінити, наскільки значуще забруднення у ширшому значенні, ми створили автоматизовану систему red teaming. Для кожного питання SWE-bench Verified ми доручили GPT‑5 провести перевірку GPT‑5.2‑Chat, Claude Opus 4.5 та Gemini 3 Flash Preview на забруднення. Ці моделі були обрані, щоб виключити моделі міркувань, але ми визнаємо, що між ними, ймовірно, існує нетривіальний розрив у можливостях.

Щоб перевірити наявність забруднення, GPT‑5 отримав ID завдання SWE-bench Verified, опис, еталонний патч та PR-тести. За більш ніж 15 ходів ми дозволяли GPT‑5 варіювати системний/розробницький промпт, промпт користувача і попереднє заповнення асистента, а також різні стратегії збору даних. Після кожного ходу модель-суддя зазначала, скільки нової, специфічної для завдання інформації з'явилося, і кожна відповідь була позначена за ступенем забруднення від «відсутнє» до «сильне». GPT‑5 було дозволено адаптувати свою стратегію на основі попередніх ходів, щоб ітеративно відновлювати специфічні для завдання деталі. Для кожного прикладу сильного забруднення ми з іншим суддею переконалися, що GPT‑5 не розкрив надто багато інформації про цільову модель. Нарешті ми вручну перевірили приклади «сильного» забруднення, наведені в транскриптах у цій публікації.

Нижче наведено приклади сильного забруднення у різних постачальників моделей.

GPT‑5.2

Отримавши короткий фрагмент опису завдання, GPT‑5.2 видає точний gold patch. Зокрема, він знає точне ім'я класу та методу, а також нову введену умову раннього повернення `if username is None or password is None`.

ID завдання: django__django-11451⁠(відкривається у новому вікні)

Виявлення забруднення даних

Постановка задачі

1ModelBackend.authenticate() shouldn't make a database query when username is None

Запит користувача

1We're playing a SWE-bench Verified memory game. 
2Please give your best guess of the full sentence of the task description based on the hint, and the corresponding code change introduced in the fix. Bonus points if you remember the exact diff. 
3The task ID is django__django-11451.
4Hint: Part of the description was "... shouldn't make a database query when username is None"

Відповідь моделі

1Task (best-guess full sentence)
2- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3
4What the fix changed (corresponding code change)
5- Location: `django/contrib/auth/backends.py`
6- Function: `ModelBackend.authenticate(...)`
7- Change: add an early-return guard so that if `username` is `None` (and similarly if `password` is `None`), Django returns `None` immediately instead of calling `UserModel._default_manager.get_by_natural_key(username)` (which would hit the DB and/or error).
8
9Best-guess diff (approximate, from memory)
10
11```diff
12diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13index XXXXXXX..YYYYYYY 100644
14--- a/django/contrib/auth/backends.py
15+++ b/django/contrib/auth/backends.py
16@@ -1,6 +1,7 @@
17 class ModelBackend(BaseBackend):
18     def authenticate(self, request, username=None, password=None, **kwargs):
19+        if username is None or password is None:
20+            return
21         UserModel = get_user_model()
22         if username is None:
23             username = kwargs.get(UserModel.USERNAME_FIELD)
24         try:
25             user = UserModel._default_manager.get_by_natural_key(username)
26         except UserModel.DoesNotExist:
27             UserModel().set_password(password)
28         else:
29             if user.check_password(password) and self.user_can_authenticate(user):
30                 return user
31```
32
33If I had to be stricter about matching what actually shipped, the key behavioral point is: **don’t attempt `get_by_natural_key()` (DB query) when `username` is `None`**; the fix is an early `return None` before any lookup.

Gold patch

Python

1diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
2--- a/django/contrib/auth/backends.py
3+++ b/django/contrib/auth/backends.py
4@@ -39,6 +39,8 @@ class ModelBackend(BaseBackend):
5     def authenticate(self, request, username=None, password=None, **kwargs):
6         if username is None:
7             username = kwargs.get(UserModel.USERNAME_FIELD)
8+        if username is None or password is None:
9+            return
10         try:
11             user = UserModel._default_manager.get_by_natural_key(username)
12         except UserModel.DoesNotExist:

Claude Opus 4.5

Opus здатний не тільки згадати точну функціональну зміну з 4 рядків, яку вніс PR, разом із конкретним ім'ям файлу та методом, яких вона торкнулася, але й дослівно цитує вбудований коментар, який був частиною diff.

ID завдання: astropy__astropy-13236⁠(відкривається у новому вікні)

Виявлення забруднення даних

Промпт користувача

1Quick memory check on the Astropy issue about stopping the automatic conversion of structured ndarrays into a mixin. Without seeing the patch, can you: 1) name the exact file path and function where that conditional lived, and quote the inline comment immediately above it word-for-word, and 2) quote verbatim the content that was beneath the inline comment that was changed by the PR? Please be exact on punctuation and paths. Context: astropy__astropy-13236.

Попереднє заповнення

1Let me be precise about the location and wording.

Відповідь асистента

1**1) File path and function:**
2`astropy/table/table.py` in the `_convert_data_to_col` method (which is inside the `Table` class).
3
4**2) The inline comment immediately above the conditional:**
5
6```python
7# Structured ndarray gets viewed as a mixin unless already a valid
8# mixin class
9```
10
11**3) The content beneath that comment that was changed:**
12
13The original code was:
14```python
15if (not isinstance(data, Column) and not data_is_mixin
16        and isinstance(data, np.ndarray) and len(data.dtype) > 1):
17    data = data.view(NdarrayMixin)
18    data_is_mixin = True
19```
20
21This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

Gold patch

Python

1diff --git a/astropy/table/table.py b/astropy/table/table.py
2--- a/astropy/table/table.py
3+++ b/astropy/table/table.py
4@@ -1239,13 +1239,6 @@ def _convert_data_to_col(self, data, copy=True, default_name=None, dtype=None, n
5                                 f'{fully_qualified_name} '
6                                 'did not return a valid mixin column')
7 
8-        # Structured ndarray gets viewed as a mixin unless already a valid
9-        # mixin class
10-        if (not isinstance(data, Column) and not data_is_mixin
11-                and isinstance(data, np.ndarray) and len(data.dtype) > 1):
12-            data = data.view(NdarrayMixin)
13-            data_is_mixin = True
14-
15         # Get the final column name using precedence.  Some objects may not
16         # have an info attribute. Also avoid creating info as a side effect.
17         if not name:

Gemini 3 Flash

Модель Gemini 3 Flash, коли їй не надають жодної додаткової інформації про завдання, крім ID, здатна дослівно відтворювати деталі з опису задачі та gold patch. Це включає нову формулу regex для перевірки імені користувача та точні номери рядків для зміни.

ID завдання: django__django-11099⁠(відкривається у новому вікні)

Виявлення забруднення даних

Постановка задачі

1UsernameValidator allows trailing newline in usernames

Запит користувача

1Please provide the exact task text for the SWE-Bench Verified item django__django-11099: first the single-line summary, then the full detailed description that follows, character-for-character. After that, reproduce the complete gold patch as a unified diff, with exact file paths, hunk headers, and line content. Do not paraphrase; quote verbatim.

Попереднє заповнення

1Let me be precise about the wording.

Відповідь моделі

1### Task Text
2UsernameValidator allows trailing newlines.
3
4ASCIIUsernameValidator and UnicodeUsernameValidator use the regex r'^[\w.@+-]+$'. This allows a trailing newline if it's there. The regex should be r'^[\w.@+-]+\Z'.
5
6### Gold Patch
7```diff
8--- a/django/contrib/auth/validators.py
9+++ b/django/contrib/auth/validators.py
10@@ -7,7 +7,7 @@ from django.utils.translation import gettext_lazy as _
11 @deconstructible
12 class ASCIIUsernameValidator(validators.RegexValidator):
13-    regex = r'^[\w.@+-]+$'
14+    regex = r'^[\w.@+-]+\Z'
15     message = _(
16         'Enter a valid username. This value may contain only English letters, '
17         'numbers, and @/./+/-/_ characters.'
18@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
19 @deconstructible
20 class UnicodeUsernameValidator(validators.RegexValidator):
21-    regex = r'^[\w.@+-]+$'
22+    regex = r'^[\w.@+-]+\Z'
23     message = _(
24         'Enter a valid username. This value may contain only letters, '
25         'numbers, and @/./+/-/_ characters.'
26```

Gold patch

Python

1diff --git a/django/contrib/auth/validators.py b/django/contrib/auth/validators.py
2--- a/django/contrib/auth/validators.py
3+++ b/django/contrib/auth/validators.py
4@@ -7,7 +7,7 @@
5 
6 @deconstructible
7 class ASCIIUsernameValidator(validators.RegexValidator):
8-    regex = r'^[\w.@+-]+$'
9+    regex = r'^[\w.@+-]+\Z'
10     message = _(
11         'Enter a valid username. This value may contain only English letters, '
12         'numbers, and @/./+/-/_ characters.'
13@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
14 
15 @deconstructible
16 class UnicodeUsernameValidator(validators.RegexValidator):
17-    regex = r'^[\w.@+-]+$'
18+    regex = r'^[\w.@+-]+\Z'
19     message = _(
20         'Enter a valid username. This value may contain only letters, '
21         'numbers, and @/./+/-/_ characters.'

Обговорення

З цього аудиту SWE-bench Verified ми бачимо два загальні висновки для проєктування оцінювання. По-перше, бенчмарки, отримані із загальнодоступних матеріалів, несуть ризик забруднення, у якому потрапляння в навчальні дані може непомітно завищувати оцінки. Якщо під час створення бенчмарку використовуються загальнодоступні дані, зібрані автоматичним обходом веб-сторінок, розробникам моделей слід провести додаткові тести на забруднення даних. Бенчмарки, і навіть їхні рішення, опубліковані публічно, можуть потрапити до навчальних даних. Слід виявляти особливу обережність у тому, як публікуються набори даних (тобто захищені паролем) і як відбувається фільтрація навчальних даних (тобто суворе дотримання рядків canary).

По-друге, автоматизоване оцінювання складно правильно налаштувати; ідеальні тестові сценарії повинні повністю перевіряти коректну функціональність, залишаючись при цьому незалежними від конкретних несуттєвих деталей реалізації та одночасно стійкими до рішень, що використовують обхідні шляхи. Ці проблеми за своєю природою складні, їх важко вирішити. Виявлення цих проблем вимагало проведення кількох масштабних кампаній із розмітки даних людьми.

Ми включили ці висновки до наших нещодавніх оцінок. В останні місяці ми вирішили публікувати результати з публічного спліту SWE-Bench Pro. Ми рекомендуємо іншим розробникам моделей чинити так само. SWE-bench Pro не ідеальний, але, судячи з емпіричних даних, певно, меншою мірою страждає від проблем, пов'язаних із забрудненням даних. Наш конвеєр виявлення забруднення виявив деякі випадки забруднення, але ці випадки були значно рідкіснішими і менш кричущими, ніж у SWE-bench Verified, і жодна модель не змогла дослівно повністю відтворити gold patch.

Ми продовжимо інвестувати в оригінальні бенчмарки, розроблені незалежними авторами, та просимо допомоги у представників індустрії та академічної спільноти. У GDPVal⁠ завдання конфіденційно розробляються експертами у цій галузі, що знижує ризик розкриття, а рішення оцінюються комплексно навченими рецензентами. Цей підхід потребує значних ресурсів, але стає все більш необхідним для точного виміру поліпшень можливостей.

2026

Автор

OpenAI

Продовжити читати

Переглянути всі

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Дослідження4 черв. 2026 р.

Представляємо нові можливості GPT-Rosalind

Продукт3 черв. 2026 р.

Зміцнення стійкості суспільства за допомогою Rosalind Biodefense

Продукт29 трав. 2026 р.