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 Verified.
Обука на решењима: Пошто велики гранични модели могу да усвајају информације из своје обуке, важно је да никада не буду обучавани на проблемима и решењима на којима се евалуирају. То је слично дељењу задатака и решења за предстојећи тест са ученицима пре теста — можда неће запамтити одговор, али ће ученици који су раније видели одговоре сигурно бити успешнији од оних који нису. SWE-bench проблеми потичу из депоа отвореног кода које многи добављачи модела користе у сврхе обуке. У нашој анализи открили смо да су сви гранични модели које смо тестирали могли да репродукују оригиналну исправку грешке коју је написао човек и која је коришћена као референтна основна истина, познату као златна закрпа, или дословне појединости из описа проблема за одређене задатке, што указује да су сви они током обуке видели бар неке од проблема и решења.

Такође смо нашли доказе да модели који су током обуке видели проблеме имају већу вероватноћу да успеју, јер имају додатне информације потребне да прођу недовољно прецизиране тестове.

То значи да побољшања на SWE-bench Verified више не одражавају смислена побољшања стварних способности модела за развој софтвера. Уместо тога, она све више одражавају колико је модел био изложен реперу током обуке. Зато смо престали да пријављујемо SWE-bench Verified резултате и препоручујемо да и други програмери модела ураде исто.

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

Позадина

Оригинална SWE-bench⁠(отвара се у новом прозору) евалуација објављена је 2023. Сваки проблем потиче из решеног GitHub issue-а у једном од 12 Python депоа отвореног кода и упарен је са одговарајућим захтевом за преглед измена (PR). Да би се утврдило да ли је измена кода коју је генерисао модел исправна, сваки проблем долази са два скупа тестова:

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

Модел не види тестове. Он мора да произведе измену кода само на основу оригиналног текста issue-а и стања депоа пре исправке. Пролази проблем само ако сви тестови прођу након што се измена кода примени.

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

Неки јединични тестови били су претерано специфични или неусклађени са задатком, па су исправне исправке могле бити одбачене.
Многи описи задатака били су недовољно прецизирани, што је могло довести до више ваљаних тумачења — док су тестови покривали само једно од њих.
У зависности од подешавања окружења (на пример 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.

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

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

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 увео, заједно са конкретним именом датотеке и метода које је дотакао, већ и да дословно цитира inline коментар који је био део 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

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

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

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```

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

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, и ниједан модел није могао да произведе потпуну дословну златну закрпу.

Наставићемо да улажемо у оригиналне, приватно ауторисане репере и тражимо помоћ од индустрије и академске заједнице да учине исто. У GDPVal⁠, задатке приватно пишу доменски стручњаци, што смањује ризик од изложености, а решења холистички оцењују обучени рецензенти. Овај приступ захтева много ресурса, али је све неопходнији за мерење стварних побољшања способности.

2026.

Аутор

OpenAI

Наставите са читањем

Прикажи све

Better memory for a more helpful ChatGPT

Јача основа за меморију у услузи ChatGPT

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

Представљамо нове могућности за GPT-Rosalind

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

Јачање отпорности друштва уз Rosalind Biodefense

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