Preskočite na glavni sadržaj
OpenAI

23. februar 2026.

IstraživanjePublikacija

Zašto SWE-bench Verified više ne mjeri granične sposobnosti kodiranja

SWE-bench Verified je sve više kontaminiran. Preporučujemo SWE-bench Pro.

Učitavanje…

Otkako smo prvi put objavili SWE-bench Potvrđeno u augustu 2024., industrija ga je široko koristila za mjerenje napretka modela na autonomnim zadacima softverskog inženjeringa. Nakon objave, SWE-bench Verified pružio je snažan signal napretka sposobnosti i postao standardna metrika koja se navodi u objavama graničnih modela. Praćenje i predviđanje napretka ovih sposobnosti također je važan dio OpenAI-jevog Okvira pripravnosti. Kada smo prvobitno kreirali Verified benchmark, pokušali smo riješiti probleme u originalnoj evaluaciji koji su određene zadatke činili nemogućim za izvršiti u SWE-bench dataset(otvara se u novom prozoru).

Nakon početnih skokova, najsavremeniji napredak na SWE-bench Potvrđeno usporio je, poboljšavajući(otvara se u novom prozoru) se sa 74,9% na 80,9% u posljednjih 6 mjeseci. Ovo postavlja pitanje: da li preostali neuspjesi odražavaju ograničenja modela ili svojstva samog skupa podataka?

U novoj analizi, pronašli smo dva velika problema sa skupom Verified koji ukazuju na to da mjerilo više nije prikladno za mjerenje napretka u autonomnim sposobnostima softverskog inženjeringa za granična lansiranja na današnjim nivoima performansi:

  1. Testovi odbacuju ispravna rješenja: Revidirali smo podskup od 27,6% skupa podataka koji modeli često nisu uspijevali riješiti i utvrdili da najmanje 59,4% revidiranih problema ima neispravne testne slučajeve koji odbacuju funkcionalno ispravne predaje, uprkos našim najboljim naporima da ovo poboljšamo u početnom kreiranju SWE-bench Verified.
  2. Obuka o rješenjima: Budući da veliki granični modeli mogu učiti informacije iz svoje obuke, važno je da se nikada ne treniraju na problemima i rješenjima na kojima se procjenjuju. Ovo je slično dijeljenju problema i rješenja za predstojeći test s učenicima prije testa - možda neće zapamtiti odgovor, ali učenici koji su ranije vidjeli odgovore sigurno će se bolje snaći od onih koji nisu. Problemi SWE-bench dolaze iz open-source repozitorija koje mnogi pružatelji modela koriste za obuku. U našoj analizi otkrili smo da su svi granični modeli koje smo testirali mogli reproducirati originalnu, ljudski napisanu ispravku greške korištenu kao referencu tačne vrijednosti, poznatu kao zlatna zakrpa, ili doslovne specifičnosti izjave o problemu za određene zadatke, što ukazuje na to da su svi oni tokom obuke vidjeli barem neke od problema i rješenja.

Također smo pronašli dokaze da su modeli koji su vidjeli probleme tokom obuke vjerovatnije uspješni, jer imaju dodatne informacije potrebne da prođu nedovoljno precizno definirane testove.

To znači da poboljšanja na SWE-bench Verified više ne odražavaju značajna poboljšanja u stvarnim sposobnostima modela za razvoj softvera. Umjesto toga, oni sve više odražavaju koliko je model bio izložen mjerilu tokom obuke. Zbog toga smo prestali prijavljivati SWE-bench Verified rezultate i preporučujemo da i drugi developeri modela učine isto.

Gradimo nove, nekontaminirane evaluacije kako bismo bolje pratili sposobnosti kodiranja, i smatramo da je ovo važno područje na koje se treba fokusirati za širu istraživačku zajednicu. Dok ih ne budemo imali, OpenAI preporučuje izvještavanje o rezultatima za SWE-bench Pro.

Pozadina

Originalna SWE-bench(otvara se u novom prozoru) evaluacija objavljena je 2023. godine. Svaki problem potiče iz riješenog GitHub problema u jednom od 12 Python repozitorija otvorenog koda i uparen je s odgovarajućim pull requestom (PR). Da biste utvrdili da li je promjena koda koju je generirao model ispravna, svaki problem dolazi s dva skupa testova:

  • Testovi koji ne prolaze na neizmijenjenoj kodnoj bazi, ali prolaze ako je problem ispravno riješen
  • Regresioni testovi koji prolaze i prije i nakon popravka kako bi se osiguralo da nepovezana funkcionalnost ostane netaknuta.

Model ne vidi testove. Mora proizvesti promjenu koda, uzimajući u obzir samo originalni tekst problema i stanje repozitorija prije ispravke. Problem prolazi samo ako svi testovi prođu nakon što se primijeni promjena koda.

Otkrili smo mnoge probleme s tom evaluacijom koji bi mogli dovesti do podcjenjivanja sposobnosti modela.

  • Neki jedinični testovi su bili previše specifični ili neusklađeni sa zadatkom, pa su ispravne ispravke mogle biti odbijene.
  • Mnoge izjave o zadacima bile su nedovoljno specificirane, što bi moglo dovesti do više valjanih tumačenja - dok su testovi pokrivali samo jedno specifično.
  • Ovisno o postavci okruženja (na primjer Linux u odnosu na Windows ili verzija Pythona), neki testovi bi mogli lažno pasti

Kreirali smo SWE-bench Potvrđeno 2024. kako bismo riješili ove probleme. Saradili smo sa stručnim softverskim inženjerima kako bismo pregledali 1.699 SWE-bench problema i uklonili one koji su imali ove probleme. Svaki problem su nezavisno pregledala tri stručnjaka. Ovaj proces pregleda rezultirao je SWE-bench Potvrđeno, pažljivo odabranim skupom od 500 problema.

Previše uski i previše široki testovi

Iako je SWE-bench Verified veliko poboljšanje u odnosu na početnu verziju, preostali problemi i dalje postoje. Proveli smo reviziju 138 SWE-bench Potvrđeno problema koje OpenAI o3 nije dosljedno riješio tokom 64 nezavisna pokretanja. Svaki slučaj je nezavisno pregledalo najmanje šest iskusnih softverskih inženjera. Ako je stručnjak označio problem, dodatni tim ga je ponovo provjerio.

Utvrđeno je da je 59,4% od 138 problema sadržavalo materijalne nedostatke u dizajnu testa i/ili opisu problema, što ih je činilo izuzetno teškim ili nemogućim za rješavanje čak i za najsposobniji model ili čovjeka. 

  • 35,5% revidiranih zadataka ima stroge testne slučajeve koji nameću specifične detalje implementacije, čineći mnoge funkcionalno ispravne podneske nevažećim, što nazivamo uskim testnim slučajevima.
  • 18,8% revidiranih zadataka ima testove koji provjeravaju dodatnu funkcionalnost koja nije bila navedena u opisu problema, što nazivamo širokim testnim slučajevima.
  • Preostalih 5,1% zadataka imalo je razne probleme koji nisu bili dobro grupisani u ovoj taksonomiji.

Ilustrativan primjer prvog načina otkaza je pylint-dev__pylint-4551(otvara se u novom prozoru), gdje PR uvodi novu funkciju `get_annotation` kao dio ukupnog rješenja. Ovo ime funkcije nije spomenuto u opisu problema, ali ga testovi direktno uvoze. Iako neki modeli mogu intuitivno doći do toga da kreiraju takvu funkciju, nije strogo neophodno implementirati funkciju s ovim konkretnim nazivom da bi se problem ispravno riješio. Mnoga važeća rješenja ne prolaze testove zbog grešaka pri uvozu.

Opis problema

Običan tekst.

1
Use Python type hints for UML generation
2
It 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
`
5
class C(object):
6
def __init__(self, a: str = None):
7
self.a = a
8
`
9
### Current behavior
10
Output of pyreverse :
11
![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12
### Expected behavior
13
I would like to see something like : `a : String` in the output.
14
### pylint --version output
15
pylint-script.py 1.6.5,
16
astroid 1.4.9
17
Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

PR test isječak

Python

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

Neuspjesi PR testova (skraćeno radi čitljivosti)

Python

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

Primjer preširokih testnih slučajeva je sympy__sympy-18199(otvara se u novom prozoru). Ovaj zadatak je preuzet iz PR-a koji je rješavao tri različita problema s funkcijom `nthroot_mod`, konkretno #17373(otvara se u novom prozoru), #17377(otvara se u novom prozoru) i #18212(otvara se u novom prozoru). Opis za zadatak SWE-bench Verified, međutim, pokriva samo konačni problem #18212(otvara se u novom prozoru). Ovo stvara nesklad: PR testovi pokrivaju sva tri problema, dok opis detaljno navodi samo jedan. U našim izvođenjima, modeli često ispravno implementiraju opisani popravak, a zatim padnu na testovima koji pokrivaju implementaciju za druga dva problema.

Originalni opis PR-a (iz GitHub PR-a)

Običan tekst.

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

Opis problema za #18212

Običan tekst.

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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.

Opis problema za SWE-bench potvrđeni zadatak (preuzeto samo iz #18212):

Običan tekst.

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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.

Kontaminacija

SWE-bench Verified i repozitoriji (baze koda i bilješke o izdanju) su open-source, široko korišteni i često diskutovani, što otežava izbjegavanje kontaminacije za developere modela.

Prvo smo naišli na znakove kontaminacije u našim vlastitim modelima. Na primjer, kada je GPT‑5.2 riješio 31 zadatak za koje smo utvrdili da ih je gotovo nemoguće riješiti. U django__django-14725(otvara se u novom prozoru) testovi zahtijevaju specifičan novi parametar `edit_only` koji nije izričito zahtijevan u izjavi o problemu. Tokom rješavanja problema, GPT‑5.2 u svom lancu razmišljanja pokazuje da ima informacije o napomenama o izdanju koje detaljno opisuju promjene u bazi koda, i ispravno identifikuje da je parametar `edit_only` uveden u Django 4.1.

GPT‑5.2 CoT

Običan tekst.

1
There 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.

Kako bismo procijenili koliko je kontaminacija značajna u širem smislu, kreirali smo automatizirani red-teaming setup. Za svako pitanje SWE-bench Potvrđeno, zadužili smo GPT‑5 da ispituje GPT‑5.2‑Chat, Claude Opus 4.5 and Gemini 3 Flash Preview za kontaminaciju. Ovi modeli su odabrani kako bi se isključili modeli rezonovanja, ali priznajemo da vjerovatno postoji netrivijalan jaz u sposobnostima između njih.

Kako bi se ispitala kontaminacija, GPT‑5 je primio: ID zadatka SWE-Bench Potvrđeno, opis, zlatnu zakrpu i PR testove. Tokom više od 15 poteza, dozvolili smo GPT‑5 da varira sistemski/developerski upit, korisnički upit i predfil asistenta te različite strategije elicitacije. Nakon svakog poteza, sudijski model je označio koliko se pojavilo novih informacija specifičnih za zadatak, a svaki odgovor je označen prema ozbiljnosti kontaminacije od „nema“ do „jaka“. GPT‑5 je imao mogućnost da prilagodi svoju strategiju na osnovu prethodnih koraka kako bi iterativno povratio detalje specifične za zadatak. Za svaki primjer snažne kontaminacije, provjerili smo s drugim sudijom da GPT‑5 nije procurio previše informacija ciljnom modelu. Konačno, ručno smo pregledali „jake“ primjere koji čine transkripte u ovom postu.

U nastavku su primjeri značajne kontaminacije kod različitih pružalaca modela.

GPT‑5.2 

S obzirom na kratak isječak iz opisa zadatka, GPT‑5.2 daje tačnu zlatnu zakrpu. Posebno, zna tačan naziv klase i metode, kao i novi uslov ranog povratka `if username is None or password is None` koji je uveden.

Elicitacija kontaminacije

Izjava o problemu

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

Upit korisnika

1
We're playing a SWE-bench Verified memory game.
2
Please 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.
3
The task ID is django__django-11451.
4
Hint: Part of the description was "... shouldn't make a database query when username is None"

Odgovor modela

1
Task (best-guess full sentence)
2
- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3

4
What 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

9
Best-guess diff (approximate, from memory)
10

11
```diff
12
diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13
index 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

33
If 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.

Zlatna zakrpa

Python

1
diff --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 je u stanju ne samo da se prisjeti tačne funkcionalne promjene od 4 linije koju je PR uveo, zajedno s konkretnim nazivom datoteke i metodom koje je dotakao, već i doslovno citira inline komentar koji je bio dio diffa. 

Elicitacija kontaminacije

Upit korisnika

1
Quick 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.

Prethodno popunjavanje

1
Let me be precise about the location and wording.

Odgovor asistenta

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

13
The original code was:
14
```python
15
if (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

21
This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

Zlatna zakrpa

Python

1
diff --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, kada ne dobije nikakve dodatne informacije o zadatku osim ID-a, u stanju je doslovno iznijeti detalje iz opisa zadatka i gold patcha. Ovo uključuje novu regex formulu za validaciju korisničkog imena i tačne brojeve linija za promjenu.

Elicitacija kontaminacije

Izjava o problemu

1
UsernameValidator allows trailing newline in usernames

Upit korisnika

1
Please 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.

Prethodno popunjavanje

1
Let me be precise about the wording.

Odgovor modela

1
### Task Text
2
UsernameValidator allows trailing newlines.
3

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

Zlatna zakrpa

Python

1
diff --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.'

Diskusija

Iz ove revizije SWE-bench Verified, vidimo dvije šire pouke za dizajn evaluacije. Prvo, referentni testovi preuzeti iz javno dostupnog materijala nose rizik od kontaminacije, pri čemu izloženost podacima za obuku može neprimjetno napuhati rezultate. Ako se javno indeksirani podaci koriste u izradi benchmarka, programeri modela trebaju provesti dodatne testove na kontaminaciju. Mjerila, pa čak i njihova rješenja, javno objavljena mogu završiti u podacima za obuku. Potrebno je posvetiti dodatnu pažnju i načinu na koji se skupovi podataka objavljuju (npr. zaštićeno lozinkom) i filtriranje podataka za obuku (npr. strogo pridržavanje canary stringova). 

Drugo, automatizirano bodovanje je nezgodno ispravno uraditi; savršeni testni slučajevi trebali bi u potpunosti verifikovati ispravnu funkcionalnost, pri čemu su i agnostični prema specifičnim nevažnim detaljima implementacije i također robusni na prečice u rješenjima. Ovi problemi su inherentno složeni i teško ih je riješiti. Otkrivanje ovih problema zahtijevalo je više opsežnih kampanja ljudskog označavanja. 

Ugradili smo ove nalaze u naše nedavne napore evaluacije. U posljednjim mjesecima odlučili smo izvještavati o rezultatima iz javne podjele SWE-Bench Pro. Preporučujemo da i drugi programeri modela urade isto. SWE-bench Pro nije savršen, ali se empirijski čini da manje pati od problema s kontaminacijom. Naš pipeline za kontaminaciju je pronašao neke slučajeve kontaminacije, ali su ti slučajevi bili značajno rjeđi i manje ozbiljni nego u SWE-bench Verified, i nijedan model nije bio u stanju da proizvede potpunu doslovnu zlatnu zakrpu.

Nastavit ćemo ulagati u originalne, privatno izrađene benchmarke i tražiti pomoć od industrije i akademske zajednice da učine isto. U GDPVal, zadatke privatno kreiraju stručnjaci za domenu, čime se smanjuje rizik od izloženosti, a rješenja se ocjenjuju holistički od strane obučenih recenzenata. Ovaj pristup je resursno intenzivan, ali sve potrebniji za mjerenje stvarnih poboljšanja sposobnosti.

Autor

OpenAI