23 февруари 2026 г.

Зошто SWE-bench Verified повеќе не ги мери граничните способности за кодирање

SWE-bench Verified е сè повеќе контаминиран. Го препорачуваме SWE-bench Pro.

Се вчитува...

Откако првпат го објавивме SWE-bench Verified во август 2024, индустријата широко го користи за да го мери напредокот на моделите во автономни задачи за софтверско инженерство. По неговото објавување, SWE-bench Verified обезбеди силен сигнал за напредокот на способностите и стана стандардна метрика што се пријавува во објавувањата на гранични модели. Следењето и предвидувањето на напредокот на овие способности е исто така важен дел од Рамка за подготвеност на OpenAI. Кога првично го создадовме Verified реперот, се обидовме да ги решиме проблемите во оригиналната евалуација што ги правеа одредени задачи невозможни за извршување во SWE-bench dataset⁠(се отвора во нов прозорец).

По почетните скокови, најсовремениот напредок на SWE-bench Verified се забави, подобрувајќи⁠(се отвора во нов прозорец) се од 74,9 % на 80,9 % во последните 6 месеци. Ова го покренува прашањето: дали преостанатите неуспеси ги одразуваат ограничувањата на моделот или својствата на самиот сет на податоци?

Во нова анализа, откривме два големи проблеми со Verified сетот што укажуваат дека реперот повеќе не е соодветен за мерење на напредокот во автономните способности за софтверско инженерство за гранични лансирања на денешните нивоа на перформанси:

Тестовите отфрлаат точни решенија: Ревидиравме подзбир од 27.6% од збирот податоци што моделите често не успеваа да го решат и откривме дека најмалку 59.4% од ревидираните проблеми имаат неисправни тест случаи што отфрлаат функционално точни поднесоци, и покрај нашите најдобри напори да го подобриме ова при почетното создавање на SWE-bench Verified.
Обука на решенија: Бидејќи големите гранични модели можат да научат информации од нивната обука, важно е тие никогаш да не се обучуваат на проблемите и решенијата на кои се евалуираат. Ова е слично на тоа да им споделиш на учениците проблеми и решенија за претстоен тест пред тестот - можеби нема да го запаметат одговорот, но учениците што ги виделе одговорите претходно сигурно ќе се снајдат подобро од оние што не ги виделе. Проблемите на SWE-bench се преземени од open-source репозиториуми што многу даватели на модели ги користат за цели на обука. Во нашата анализа откривме дека сите гранични модели што ги тестиравме беа во можност да ја репродуцираат оригиналната, од човек напишана поправка на грешка што се користеше како референца за точната основа, позната како златна закрпа, или дословните специфики од изјавата за проблемот за одредени задачи, што укажува дека сите тие виделе барем дел од проблемите и решенијата за време на обуката.

Исто така, најдовме докази дека моделите што имале проблеми за време на обуката имаат поголема веројатност да успеат, бидејќи имаат дополнителни информации потребни за да ги положат недоволно специфицираните тестови.

Ова значи дека подобрувањата на SWE-bench Verified повеќе не одразуваат значајни подобрувања во реалните способности на моделите за развој на софтвер. Наместо тоа, тие сè повеќе одразуваат колку моделот бил изложен на реперот за време на обуката. Ова е причината зошто престанавме да известуваме за резултатите на SWE-bench Verified, и препорачуваме и другите програмери на модели да го направат истото.

Градиме нови, неконтаминирани евалуации за подобро следење на способностите за кодирање, и сметаме дека ова е важна област на која треба да се фокусираме за пошироката истражувачка заедница. Додека не ги имаме тие, OpenAI препорачува да се пријавуваат резултати за SWE-bench Pro.

Заднина

Оригиналната евалуација SWE-bench⁠(се отвора во нов прозорец) беше објавена во 2023. Секој проблем е преземен од решено GitHub прашање во еден од 12 Python репозиториуми со отворен код и спарен со соодветниот pull request (PR). За да се утврди дали кодната промена генерирана од модел е точна, секој проблем доаѓа со два сета тестови:

Тестови кои не успеваат на немодифицираната кодна база, но успеваат ако проблемот е правилно поправен
Регресиски тестови што поминуваат и пред и по поправката за да се осигури дека неповрзаната функционалност останува недопрена.

Моделот не ги гледа тестовите. Треба да направи промена во кодот, со оглед на тоа што се дадени само оригиналниот текст на проблемот и состојбата на репозиториумот пред поправката. Поминува проблем само ако поминат сите тестови откако ќе се примени промената на кодот.

Пронајдовме многу проблеми со таа евалуација што би можеле да доведат до недоволно известување за способноста на моделите.

Некои едноставни тестови беа премногу специфични или неусогласени со задачата, па точните поправки можеа да бидат одбиени.н
Многу изјави за задачи беа недоволно дефинирани, што може да доведе до повеќе валидни толкувања - додека тестовите опфаќаа само едно конкретно.
Во зависност од поставувањето на околината (на пример Linux наспроти Windows, или верзијата на python), некои тестови би можеле лажно да не успеат

Го создадовме SWE-bench Verified во 2024 година за да ги решиме овие проблеми. Работевме со експертски софтверски инженери за да прегледаме 1,699 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 (од GitHub PR)

Обичен текст

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 во својот синџир на размислување покажува дека има информации за белешките за изданието што ги опишуваат промените во кодната база, и правилно идентификува дека параметарот `edit_only` е воведен во Django 4.1.

GPT‑5.2 CoT

Обичен текст

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.

За да процениме колку е значајна контаминацијата пошироко, создадовме автоматизирана поставка за тестирање на отпорноста. За секое прашање на 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` што се воведува.

Идентификатор на задача: 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.

Златна закрпа

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.

Идентификатор на задача: 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

Златна закрпа

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 (идентификациски број), е способен да изведе дословни детали од описот на задачата и златната закрпа. Ова ја вклучува новата regex формула за валидација на корисничко име и точните броеви на линии за промената.

Идентификатор на задача: 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```

Златна закрпа

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, гледаме две пошироки поуки за дизајнот на евалуацијата. Прво, реперите добиени од јавно достапни материјали носат ризик од контаминација, при што изложеноста на податоците за обука може тивко да ги надуе резултатите. Ако јавно пребарувани податоци се користат при конструирање на репер, програмерите на моделот треба да спроведат дополнителни тестови за контаминација. Одредниците, па дури и нивните решенија, објавени јавно може да завршат во податоците за обука. Треба да се внимава дополнително и на тоа како се објавуваат збирките на податоци (i.e. заштитено со лозинка) и филтрирање на податоците за обука (т.е. строго придржување до canary низи).

Второ, автоматизираното оценување е тешко да се направи како што треба; совршените тест случаи треба целосно да ја потврдат точната функционалност, притоа да бидат и агностични кон конкретни неважни детали на имплементацијата и исто така робусни на решенија со кратенки. Овие проблеми се инхерентно сложени и тешки за решавање. Откривањето на овие проблеми бараше повеќекратни обемни кампањи за човечко означување.

Ги вклучивме овие наоди во нашите неодамнешни напори за евалуација. Во последните месеци избравме да известуваме за резултатите од јавното разделување на SWE-Bench Pro. Препорачуваме и другите програмери на модели да го направат истото. SWE-bench Pro не е совршен, но емпириски се чини дека има помалку проблеми со контаминација. Нашиот процес за откривање контаминација пронајде некои случаи на контаминација, но овие случаи беа значително поретки и помалку сериозни од SWE-bench Verified, и ниеден модел не беше во можност да произведе целосна дословна златна закрпа.

Ќе продолжиме да инвестираме во оригинални, приватно авторски репери и ќе побараме помош од индустријата и академијата да го направат истото. Во GDPVal⁠, задачите се приватно авторирани од експерти од доменот, со што се намалува ризикот од изложеност, а решенијата се оценуваат холистички од обучени рецензенти. Овој пристап е ресурсно интензивен, но станува сè понеопходен за да се мерат вистинските подобрувања на способностите.

2026

Автор

OpenAI

Продолжи да читаш

Види ги сите

Better memory for a more helpful ChatGPT

Посилна основа за меморијата на ChatGPT

Истражување4 јун. 2026 г.

Воведуваме нови можности во GPT-Rosalind

Производ3 јун. 2026 г.

Зајакнување на општествената отпорност со Rosalind Biodefense

Производ29 мај 2026 г.