23. února 2026

Proč SWE-bench Verified už neměří hraniční schopnosti v programování

SWE-bench Verified je stále více kontaminovaný. Doporučujeme SWE-bench Pro.

Načítání…

Od doby, kdy jsme v srpnu 2024 poprvé publikovali SWE-bench Verified, jej odvětví široce používá k měření pokroku modelů v autonomních úlohách softwarového vývoje. Po svém vydání znamenal SWE-bench Verified silný signál pokroku ve schopnostech a stal se standardní metrikou uváděnou při vydáních špičkových modelů. Sledování a předpovídání pokroku těchto schopností je také důležitou součástí rámce připravenosti OpenAI. Když jsme původně vytvořili benchmark Verified, pokusili jsme se vyřešit problémy v původním hodnocení, které znemožňovaly splnit některé úlohy v datové sadě SWE-bench⁠(otevře se v novém okně).

Po počátečním skokovém zlepšení se špičkový pokrok na SWE-bench Verified zpomalil a zlepšil se⁠(otevře se v novém okně) ze 74,9 % na 80,9 % za posledních 6 měsíců. To vyvolává otázku: odrážejí zbývající selhání omezení modelu nebo vlastnosti samotné datové sady?

V nové analýze jsme objevili dva zásadní problémy se sadou Verified, které naznačují, že benchmark už není vhodný k měření pokroku v autonomních schopnostech softwarového vývoje pro uvedení na trh při dnešních úrovních výkonu:

Testy odmítají správná řešení: Provedli jsme audit 27,6 % podmnožiny datové sady, kterou modely často nedokázaly vyřešit, a zjistili jsme, že navzdory našemu nejlepšímu úsilí o zlepšení při počátečním vytvoření SWE-bench Verified minimálně 59,4 % auditovaných úloh má chybné testovací případy, které odmítají funkčně správná odevzdání.
Trénování na řešeních: Vzhledem k tomu, že se velké špičkové modely mohou ze svého tréninku naučit informace, je důležité, aby nikdy nebyly trénovány na problémech a řešeních, na kterých jsou hodnoceny. Je to podobné, jako kdybyste studentům před testem sdělili problémy a řešení k nadcházejícímu testu. Možná si odpověď nezapamatují, ale studenti, kteří už odpovědi viděli, si určitě povedou lépe než ti, kteří je neviděli. Problémy SWE-bench pocházejí z open-source úložišť, která mnoho poskytovatelů modelů používá pro účely trénování. V naší analýze jsme zjistili, že všechny testované špičkové modely byly schopny reprodukovat původní, lidsky napsanou opravu chyby použitou jako referenční bod, známý jako zlatá záplata, nebo doslovné specifikace problémového tvrzení pro určité úkoly, což naznačuje, že všechny se během trénování setkaly s alespoň některými problémy a jejich řešeními.

Také jsme zjistili, že modely, které se s problémy setkaly během trénování, mají větší šanci na úspěch, protože mají k dispozici dodatečné informace potřebné k úspěšnému absolvování nedostatečně specifikovaných testů.

To znamená, že zlepšení v testu SWE-bench Verified již neodrážejí smysluplná zlepšení schopností modelů vyvíjet software v reálném světě. Místo toho stále více odrážejí, jak moc byl model během trénování vystaven srovnávacímu testu. Proto jsme přestali uvádět skóre SWE-bench Verified a doporučujeme, aby to dělali také ostatní vývojáři modelů.

Vytváříme nová, nekontaminovaná hodnocení, abychom mohli lépe sledovali schopnosti v programování, a myslíme si, že je to důležitá oblast, na kterou by se měla zaměřit širší výzkumná komunita. Dokud je nebudeme mít, OpenAI doporučuje reportovat výsledky pro SWE-bench Pro.

Pozadí

Původní hodnocení SWE-bench⁠(otevře se v novém okně) bylo vydáno v roce 2023. Každý problém pochází z vyřešeného problému na GitHubu v jednom z 12 open-source Python úložišť a je spárován s odpovídajícím pull requestem (PR). Chcete-li určit, zda je změna kódu vygenerovaná modelem správná, každý problém obsahuje dvě sady testů:

Testy, které selžou na neupravené kódové základně, ale projdou, pokud je problém správně opraven
Regresní testy, které projdou jak před, tak po opravě, aby se zajistilo, že nesouvisející funkce zůstane nedotčena.

Model nevidí testy. Musí vytvořit změnu kódu pouze na základě původního textu problému a stavu úložiště před opravou. Projde problémem pouze tehdy, pokud po aplikování změny kódu projdou všechny testy.

Zjistili jsme mnoho problémů s tímto hodnocením, které by mohly vést k podhodnocení schopností modelů.

Některé jednotkové testy byly příliš konkrétní nebo nebyly v souladu s úkolem, takže správné opravy mohly být odmítnuty.
Mnohá zadání úkolů byla nedostatečně specifikovaná, což mohlo vést k více platným interpretacím, zatímco testy pokrývaly jen jednu konkrétní.
V závislosti na nastavení prostředí (například Linux vs Windows nebo verze pythonu) mohou některé testy falešně selhat

V roce 2024 jsme pro řešení těchto problémů vytvořili SWE-bench Verified. Spolupracovali jsme s odbornými vývojáři softwaru na revizi 1 699 problémů SWE-bench a odfiltrování problémů, které měly tyto potíže. Každý problém byl přezkoumán nezávisle třemi odborníky. Tento kontrolní proces vyústil v SWE-bench Verified, kurátorsky vybranou sadu 500 problémů.

Příliš úzké a příliš rozsáhlé testy

Přestože SWE-bench Verified představuje velké zlepšení oproti původní verzi, přetrvávají zbytkové problémy. Provedli jsme audit 138 problémů s SWE-bench Verified, které OpenAI o3 nedokázal konzistentně vyřešit během 64 nezávislých spuštění. Každý případ byl nezávisle posouzen nejméně šesti zkušenými softwarovými inženýry. Pokud odborník označil problém, byl znovu ověřen dalším týmem.

Zjistili jsme, že 59,4 % ze 138 problémů obsahovalo závažné nedostatky v návrhu testu a/nebo v popisu problému, díky čemuž byly extrémně obtížné neboje nešlo vyřešit i tím ten nejschopnějším modelem nebo člověkem.

35,5 % auditovaných úloh má přísné testovací případy, které vynucují konkrétní detaily implementace, čímž zneplatňují mnoho funkčně správných odeslání, kterým říkáme úzké testovací případy.
18,8 % auditovaných úloh má testy, které kontrolují dodatečnou funkcionalitu, jež nebyla specifikována v popisu problému. Proto je nazýváme široké testovací případy.
Zbývajících 5,1 % úkolů mělo různé problémy, které nebyly v rámci této taxonomie dobře seskupené.

Ilustrativním příkladem prvního režimu selhání je pylint-dev__pylint-4551⁠(otevře se v novém okně), kde PR zavádí novou funkci `get_annotation` jako součást celkového řešení. Tento název funkce není uveden v popisu úlohy, ale je importován přímo testy. I když některé modely mohou intuitivně vytvořit takovou funkci, není striktně nutné implementovat funkci s tímto konkrétním názvem, aby se problém správně vyřešil. Mnoho platných řešení selže v testech kvůli chybám při importu.

Popis problému

Prostý text

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)]

Testovací úryvek PR

Python

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

Selhání testů PR (zkráceno pro čitelnost)

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)

Příkladem příliš širokých testovacích případů je sympy__sympy-18199⁠(otevře se v novém okně). Tento úkol pocházel z PR, které řešilo tři samostatné problémy s funkcí `nthroot_mod`, konkrétně #17373⁠(otevře se v novém okně), #17377⁠(otevře se v novém okně) a #18212⁠(otevře se v novém okně). Popis úlohy SWE-bench Verified však pokrývá pouze poslední problém #18212⁠(otevře se v novém okně). To vytváří nesoulad: testy v PR pokrývají všechny tři problémy, zatímco popis podrobně uvádí pouze jeden. V našich bězích modely často správně implementují popsanou opravu a pak selžou v testech, které pokrývají implementaci dalších dvou problémů.

Původní popis PR (z GitHub PR)

Prostý text

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

Popis problému pro #18212

Prostý text

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.

Popis problému pro úlohu SWE-bench Verified (pouze převzato z #18212):

Prostý text

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.

Kontaminace

SWE-bench Verified a úložiště (kódové základny a poznámky k vydání) jsou obojí open-source a široce používané a diskutované, což ztěžuje vyhnout se kontaminaci pro vývojáře modelů.

Nejprve jsme zaznamenali známky kontaminace v našich vlastních modelech. Například když GPT‑5.2 vyřešil 31 úloh, které jsme identifikovali jako téměř nemožné vyřešit. V django__django-14725⁠(otevře se v novém okně) testy vyžadují konkrétní nový parametr `edit_only`, který není v zadání problému výslovně vyžadován. Při řešení problému GPT‑5.2 ve svém myšlenkovém řetězci ukazuje, že má informace o poznámkách k vydání, které podrobně popisují změny v kódové základně, a správně identifikuje, že parametr `edit_only` byl zaveden v Django 4.1.

GPT‑5.2 CoT

Prostý text

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.

Abychom posoudili, jak významná je kontaminace v širším měřítku, vytvořili jsme automatizované nastavení pro red-teaming. U každé otázky SWE-bench Verified jsme pověřili GPT‑5, aby prověřil GPT‑5.2‑Chat, Claude Opus 4.5 a Gemini 3 Flash Preview pro kontaminaci. Tyto modely byly vybrány tak, aby vyloučily modely s uvažováním, ale uznáváme, že mezi nimi pravděpodobně existuje nezanedbatelná mezera ve schopnostech.

Aby se prověřila kontaminace, GPT‑5 obdržel ID, popis, referenční záplatu ch a PR testy úlohy SWE-bench Verified. Během více než 15 tahů jsme umožnili GPT‑5 měnit systémový/developerský prompt, uživatelský prompt, předvyplnění asistenta a různé strategie elicitation. Po každém tahu judge model označil, kolik nových informací specifických pro daný úkol se objevilo, a každá odpověď byla označena podle závažnosti kontaminace od „žádná“ po „silná“. GPT‑5 měl povoleno přizpůsobovat svou strategii na základě předchozích tahů, aby iterativně získal zpět detaily specifické pro daný úkol. U každého příkladu silné kontaminace jsme s dalším hodnotitelem ověřili, že GPT‑5 neuniklo do cílového modelu příliš mnoho informací. Nakonec jsme pak ručně zkontrolovali „silné“ příklady, které tvoří přepisy v tomto příspěvku.

Níže jsou uvedeny příklady silné kontaminace napříč různými poskytovateli modelů.

GPT‑5.2

Na základě krátkého úryvku z popisu úlohy GPT‑5.2 vypíše přesnou opravu (gold patch). Zejména zná přesný název třídy a metody a novou podmínku pro předčasný návrat `if username is None or password is None`, která je zavedena.

ID úkolu: django__django-11451⁠(otevře se v novém okně)

Vyvolání kontaminace

Zadání problému

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

Prompt uživatele

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"

Odpověď modelu

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.

Zlatá oprava

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 je schopný si nejen vybavit přesnou čtyřřádkovou funkční změnu, kterou PR zavedlo, spolu s konkrétním názvem souboru a metodou, které se dotklo, ale také doslova cituje inline komentář, který byl součástí diffu.

ID úkolu: astropy__astropy-13236⁠(otevře se v novém okně)

Vyvolání kontaminace

Prompt uživatele

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.

Předvyplnit

1Let me be precise about the location and wording.

Odpověď 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
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

Zlatá oprava

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, pokud nedostane žádné další informace o úkolu kromě ID, dokáže doslovně vypsat podrobnosti z popisu úkolu a z referenčního patchu. To zahrnuje nový regulární výraz pro ověřování uživatelského jména a přesná čísla řádků pro tuto změnu.

ID úkolu: django__django-11099⁠(otevře se v novém okně)

Vyvolání kontaminace

Zadání problému

1UsernameValidator allows trailing newline in usernames

Prompt uživatele

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.

Předvyplnit

1Let me be precise about the wording.

Odpověď modelu

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

Zlatá oprava

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

Diskuse

Z tohoto auditu SWE-bench Verified vidíme dvě širší poučení pro návrh evaluací. Nejprve, benchmarky pocházející z veřejně dostupných materiálů nesou riziko kontaminace, kdy vystavení trénovacím datům může tiše uměle navýšit skóre. Pokud se při konstrukci benchmarku používají veřejně procházená data, měli by vývojáři modelů provést dodatečné testy na kontaminaci. Srovnávací testy, a dokonce i jejich řešení, zveřejněné veřejně mohou skončit v trénovacích datech. Zvláštní pozornost by měla být věnována jak tomu, jak jsou datové sady zveřejňovány (tj. chráněno heslem) a filtrování trénovacích dat (tj. přísné dodržování kanárkových řetězců).

Za druhé, automatizované skórování je obtížné nastavit správně; dokonalé testovací případy by měly plně ověřit správnou funkčnost, být jak nezávislé na konkrétních nepodstatných detailech implementace, tak i robustní vůči zkratkovitým řešením. Tyto problémy jsou ze své podstaty složité a obtížně řešitelné. Odhalení těchto problémů vyžadovalo několik rozsáhlých kampaní lidského štítkování.

Tato zjištění jsme začlenili do našich nedávných hodnoticích aktivit. V posledních měsících jsme se rozhodli reportovat výsledky z veřejného rozdělení SWE-Bench Pro. Doporučujeme, aby ostatní vývojáři modelů postupovali stejně. SWE-bench Pro není dokonalý, ale empiricky se zdá, že trpí méně problémy s kontaminací. Náš pipeline pro detekci kontaminace našel některé případy kontaminace, ale tyto případy byly výrazně vzácnější a méně závažné než u SWE-bench Verified a žádný model nedokázal vytvořit kompletní doslovnou gold patch.

Budeme i nadále investovat do původních, soukromě vytvořených benchmarků a požádáme o pomoc průmysl i akademickou sféru, aby dělaly totéž. V GDPVal⁠ jsou úkoly soukromě vytvářeny odborníky v dané doméně, čímž se snižuje riziko vystavení, a řešení jsou hodnocena holisticky vyškolenými hodnotiteli. Tento přístup je náročný na zdroje, ale je stále nezbytnější pro měření skutečných zlepšení schopností.

2026

Autor

OpenAI

Pokračuj ve čtení

Zobrazit vše

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Výzkum4. 6. 2026

Představujeme nové schopnosti GPT-Rosalind

Produkt3. 6. 2026

Posilování odolnosti společnosti s biologickou ochranou Rosalind

Produkt29. 5. 2026