2026. február 23.

Miért nem méri már az SWE-bench Verified az élvonalbeli kódolási képességeket?

A SWE-bench Verified egyre szennyezettebb. Az SWE-bench Pro használatát javasoljuk.

Betöltés…

Amióta 2024 augusztusában először publikáltuk az SWE-bench Verified benchmarkot, az iparágban elterjedt a használata a modellek autonóm szoftvermérnöki feladatok esetén történő fejlődésének mérésére. A megjelenést követően a SWE-bench Verified erős jelzést adott a képességek fejlődéséről, és az élvonalbeli modellkiadások jelentéseiben szereplő standard mérőszámmá vált. Az e képességek nyomon követése és előrejelzése terén elért előrehaladás szintén fontos része az OpenAI felkészültségi keretrendszerének. Amikor először létrehoztuk a Verified benchmarkot, megpróbáltuk megoldani az eredeti értékelésben felmerülő problémákat, amelyek bizonyos feladatok elvégzését ellehetetlenítették az SWE-bench adathalmazban⁠(új ablakban nyílik meg).

A kezdeti gyors előrelépéseket követően az SWE-bench Verified benchmarkkal kapcsolatos legmagasabb színvonalú fejlesztések lelassultak, az előző 6 hónapban 74,9%-ról 80,9%-ra javulva⁠(új ablakban nyílik meg). Ez felveti a kérdést: a fennmaradó hibák a modell korlátait tükrözik, vagy inkább magának az adathalmaznak a tulajdonságait?

Egy új elemzés során két jelentős problémát azonosítottunk a Verified halmazban, amelyek arra utalnak, hogy a benchmark a mai teljesítményszintek mellett már nem alkalmas az autonóm szoftvermérnöki képességek során elért előrehaladás mérésére az élvonalbeli bevezetések esetén:

A tesztek a helyes megoldásokra fals negatív eredményt adnak: Auditáltuk az adathalmaznak a modellek által gyakran nem megoldható 27,6%-os részhalmazát, és azt találtuk, hogy az auditált feladatok legalább 59,4%-ában hibás tesztesetek szerepelnek, amelyek fals eredményt adnak a funkcionálisan helyes beküldésekre, hiába próbáltuk ezt javítani az SWE-bench Verified első létrehozásakor.
Megoldásokon való betanítás: Mivel a nagy élvonalbeli modellek a betanításuk során információkat tanulhatnak meg, fontos, hogy soha ne az őket kiértékelő feladatokon és megoldásokon legyenek betanítva. Ez olyan, mintha a dolgozat előtt megosztanád a diákokkal a közelgő dolgozat feladatait és megoldásait – lehet, hogy nem magolják be a választ, de azok a diákok, akik már látták a válaszokat, biztosan jobban fognak teljesíteni, mint azok, akik nem. A SWE-bench problémák olyan nyílt forráskódú adattárakból származnak, amelyeket sok modellszolgáltató betanítási célokra használ. Elemzésünk során azt találtuk, hogy az összes általunk tesztelt élvonalbeli modell képes volt reprodukálni a valós referenciaként használt eredeti, ember által írt hibajavítást (arany javítás), illetve bizonyos feladatok esetében szó szerint a probléma megállapításának konkrét részleteit, ami arra utal, hogy a betanítás során mindegyikük találkozott már legalább néhány problémával és megoldással.

Azt is megállapítottuk, hogy azok a modellek, amelyek a betanítás során már látták a problémákat, nagyobb valószínűséggel járnak sikerrel, mert rendelkeznek a nem kellő alapossággal meghatározott tesztek teljesítéséhez szükséges további információkkal.

Ez azt jelenti, hogy a SWE-bench Verified teljesítményében elért javulások már nem tükrözik a modellek valós szoftverfejlesztési képességeinek érdemi javulását. Ehelyett egyre inkább azt tükrözik, hogy a modell milyen mértékben volt kitéve a benchmarknak a betanítási idő alatt. Ezért hagytuk abba a SWE-bench Verified pontszámok jelentését, és azt javasoljuk, hogy más modellfejlesztők is kövessék ezt a példát.

Új, nem szennyezett értékeléseket készítünk a kódolási képességek jobb nyomon követéséhez, és úgy gondoljuk, hogy ez egy olyan fontos terület, amellyel érdemes foglalkoznia a tágabb kutatói közösségnek. Amíg ezek nem állnak rendelkezésre, az OpenAI az SWE-bench Pro eredményeinek jelentését javasolja.

Háttér

Az eredeti SWE-bench⁠(új ablakban nyílik meg) kiértékelést 2023-ban adták ki. Minden probléma a 12 nyílt forráskódú Python-adattár egyikében található, megoldott GitHub-esetből származik, és a hozzá tartozó pull requesttel (PR) van párosítva. Annak eldöntésére, hogy a modell által generált kódmódosítás helyes-e, minden probléma két tesztkészlettel rendelkezik:

Olyan tesztek, amelyek a módosítatlan kódbázison sikertelen (fail), a hiba megfelelő kijavítása esetén pedig sikeres (pass) eredményt adnak
Regressziós tesztek, amelyek a javítás előtt és után is sikeresen lefutnak, biztosítva, hogy a nem kapcsolódó funkciók érintetlen maradjanak.

A modell nem látja a teszteket. Kódmódosítást kell előállítania, kizárólag az eredeti hibaleírás szövege és az adattár javítás előtti állapota alapján. Egy probléma megoldását csak akkor tekinti sikeresnek, ha a kódmódosítás alkalmazása után az összes teszt sikeres.

Számos olyan problémát találtunk az értékeléssel kapcsolatban, amelyek a modellek képességeinek alulbecsléséhez vezethetnek.

Egyes unit tesztek túl-specifikáltak voltak vagy nem illeszkedtek megfelelően a feladathoz, ezért a helyes javítások is sikertelen eredményt adtak.
Számos feladatleírás alulspecifikált volt, ami több érvényes interpretációt is lehetővé tett – miközben a tesztek csak egy adott értelmezést fedtek le.
A környezet beállításától (például a Linux, a Windows, vagy a python verziója) függően egyes tesztek tévesen sikertelen eredményt adhatnak

Az SWE-bench Verified benchmarkot 2024-ben hoztuk létre ezeknek a problémáknak a kezelésére. Szakértő szoftvermérnökökkel együttműködve 1 699 SWE-bench problémát tekintettünk át, és kiszűrtük azokat, amelyek ezeket a hibákat tartalmazták. Minden problémát három szakértő vizsgált át egymástól függetlenül. Ez a felülvizsgálati folyamat eredményezte az SWE-bench Verified benchmarkot, egy gondosan összeállított, 500 problémából álló készletet.

Túlságosan szűk és túlságosan tág tesztek

Bár a SWE-bench Verified nagy előrelépés a kezdeti verzióhoz képest, maradtak még benne problémák. 138 SWE-bench Verified problémát auditáltunk, amelyeket az OpenAI o3 modell 64 egymástól független futtatás során nem tudott konzisztensen megoldani. Minden egyes esetet egymástól függetlenül legalább hat tapasztalt szoftvermérnök vizsgált felül. Ha egy szakértő problémát jelzett, azt egy további csapat újraellenőrizte.

Azt találtuk, hogy a 138 probléma 59,4%-a lényeges hibákat tartalmazott a tesztdizájnban és/vagy a feladatleírásban, ami rendkívüli módon megnehezítette vagy akár lehetetlenné is tette a megoldásukat még a legképzettebb modell vagy ember számára is.

Az auditált feladatok 35,5%-a szigorú teszteseteket használ, amelyek konkrét implementációs részleteket kényszerítenek ki, és emiatt sok funkcionálisan helyes megoldást érvénytelenítenek; ezeket szűk teszteseteknek nevezzük.
Az auditált feladatok 18,8%-ában olyan tesztek találhatók, amelyek a feladatleírásban nem szereplő további funkcionalitást ellenőriznek; ezeket tág teszteseteknek nevezzük.
A fennmaradó 5,1% feladat vegyes jellegű problémákat tartalmazott, amelyek nem illeszkedtek jól ebbe a taxonómiába.

Az első hibamód egy szemléltető példája a pylint-dev__pylint-4551⁠(új ablakban nyílik meg), ahol a PR egy új `get_annotation` függvényt vezet be az átfogó megoldás részeként. Ez a függvénynév nem szerepel a probléma leírásában, hanem közvetlenül a tesztek importálják. Bár egyes modellek intuitívan létrehozhatnak egy ilyen függvényt, nem feltétlenül szükséges pontosan ezzel a névvel definiált függvényt implementálni a probléma helyes megoldásához. Sok érvényes megoldás importálási hibák miatt elbukik a teszteken.

Problémaleírás

Egyszerű szöveg

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-tesztrészlet

Python

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

PR teszthibák (az olvashatóság kedvéért csonkolva)

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élda a túl széles tesztesetekre: sympy__sympy-18199⁠(új ablakban nyílik meg). Ez a feladat egy pull requestből (PR) származik, amely az `nthroot_mod` függvény három különálló problémáját kezelte, nevezetesen a #17373⁠(új ablakban nyílik meg), a #17377⁠(új ablakban nyílik meg) és a #18212⁠(új ablakban nyílik meg) számú problémákat. A SWE-bench Verified feladatleírása azonban csak a következő végső hibát fedi le: #18212⁠(új ablakban nyílik meg). Ez inkonzisztenciát okoz: a PR tesztjei mindhárom problémát lefedik, miközben a leírás csak az egyiket részletezi. A futtatásaink során a modellek gyakran helyesen implementálják a leírt javítást, majd elbuknak azokon a teszteken, amelyek a másik két probléma implementációját ellenőrzik.

Eredeti PR-leírás (a GitHub PR-ből)

Egyszerű szöveg

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

#18212 számú probléma leírása

Egyszerű szöveg

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 task problémaleírása (csak #18212-től):

Egyszerű szöveg

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.

Szennyeződés

A SWE-bench Verified és az adattárak (kódbázisok és kiadási megjegyzések) egyaránt nyílt forráskódúak, és széles körben használt és aktívan tárgyalt anyagok, ami megnehezíti a szennyeződés elkerülését a modellfejlesztők számára.

Először a saját modelljeinkben észleltük a szennyeződés jeleit. Például a GPT‑5.2 megoldott 31 olyan feladatot, amit szinte megoldhatatlanként tartottunk számon. A django__django-14725⁠(új ablakban nyílik meg) esetében a tesztek egy konkrét új `edit_only` paramétert igényelnek, amelyet a feladatleírás nem ír elő egyértelműen. A probléma megoldása közben a GPT‑5.2 a gondolatmenetében arra utal, hogy vannak információi a kiadási megjegyzésekről, amelyek a kódbázis változásait részletezik, és helyesen azonosítja, hogy az `edit_only` paramétert a Django 4.1 modellben került bevezetésre.

GPT‑5.2 CoT

Egyszerű szöveg

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.

Annak érdekében, hogy szélesebb körben felmérjük, hogy mennyire jelentős a szennyezettség, létrehoztunk egy automatizált „piros csapatos tesztelés” rendszert. Minden egyes SWE-bench Verified kérdésnél a GPT‑5‑öt bíztuk meg azzal, hogy szennyezettség szempontjából tesztelje a GPT‑5.2‑Chat, a Claude Opus 4.5 és a Gemini 3 Flash Preview modelleket. Ezeket a modelleket úgy választottuk ki, hogy kizárjuk az érvelési modelleket, ugyanakkor elismerjük, hogy a közöttük meglévő képességbeli különbség valószínűleg nem elhanyagolható.

A szennyezettség vizsgálatához a GPT‑5 megkapta az SWE-bench Verified feladat azonosítóját, leírását, az arany javítást és a PR-teszteket. 15 körön keresztül engedélyeztük a GPT‑5‑nek, hogy változtassa a rendszer/fejlesztői utasítást, a felhasználói utasítást és az asszisztens előzetes kitöltését, valamint a különböző előhívási stratégiákat. Minden forduló után egy bírói modell megcímkézte, hogy mennyi új, feladatspecifikus információ jelent meg, és minden választ a szennyeződés súlyossága szerint „none” (nincs) értéktől a „strong” (erős) értékig osztályozott. A GPT‑5 számára engedélyezett volt, hogy a korábbi fordulók alapján adaptálja a stratégiáját, és iteratív módon visszanyerje a feladatspecifikus részleteket. A súlyos szennyezettség minden egyes példájánál egy másik bíróval ellenőriztük, hogy a GPT‑5 nem szivárogtatott-e túl sok információt a célmodell felé. Végül manuálisan is átnéztük az ebben a bejegyzésben szereplő átiratokat alkotó „strong” példákat.

Az alábbiakban példák láthatók a különböző modellszolgáltatók közötti jelentős szennyezettségre.

GPT‑5.2

A feladatleírásból származó rövid részlet alapján a GPT‑5.2 a pontos arany javítást adja meg kimenetként. Különösen fontos, hogy ismeri a pontos osztály- és metódusnevet, valamint a bevezetett új korai visszatérési feltételt: `if username is None or password is None`.

Feladatazonosító: django__django-11451⁠(új ablakban nyílik meg)

Szennyezettség feltárása

Problémameghatározás

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

Felhasználói utasítás

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"

Modellválasz

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.

Arany javítás

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

Az Opus nemcsak a PR által bevezetett pontos, négysoros funkcionális módosítást képes felidézni, a konkrét fájlnévvel és érintett metódussal együtt, hanem szó szerint idézi a diff részét képező inline megjegyzéseket is.

Feladatazonosító: astropy__astropy-13236⁠(új ablakban nyílik meg)

Szennyezettség feltárása

Felhasználói utasítás

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.

Előkitöltés

1Let me be precise about the location and wording.

Asszisztens válasza

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

Arany javítás

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

A Gemini 3 Flash, amikor a feladatról az azonosítón kívül semmilyen további információt nem kap, szó szerint vissza tudja adni a feladatleírás és az arany javítás részleteit. Ez magában foglalja a felhasználónév-ellenőrzéshez használt új regex képletet és a módosítás pontos sorszámait.

Feladatazonosító: django__django-11099⁠(új ablakban nyílik meg)

Szennyezettség feltárása

Problémameghatározás

1UsernameValidator allows trailing newline in usernames

Felhasználói utasítás

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.

Előkitöltés

1Let me be precise about the wording.

Modellválasz

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

Arany javítás

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

Beszélgetés

Az SWE-bench Verified auditjából két általánosabb tanulság rajzolódik ki a kiértékelés tervezésére vonatkozóan. Először is, a nyilvánosan elérhető anyagokból származó benchmarkok szennyezettségi kockázatot hordoznak, mivel a betanítási adatoknak való kitettség észrevétlenül megnövelheti a pontszámokat. Ha a benchmark összeállításához nyilvánosan feltérképezett adatokat használnak, a modell fejlesztőinek további teszteket kell végezniük a szennyeződés ellenőrzésére. A nyilvánosan közzétett benchmarkok, sőt azok megoldásai is, bekerülhetnek a betanítási adatokba. Alapos körültekintéssel kell eljárni mind az adathalmazok publikálásának módjában (pl. jelszóval védett hozzáférés), mind a betanítási adatok szűrésében (pl. a canary string alapú szűrés következetes alkalmazása).

Másodszor, az automatizált kiértékelés nehéz feladat; az ideális teszteseteknek teljes körűen igazolniuk kell a helyes működést, miközben függetlennek kell maradniuk a nem lényeges implementációs részletekkel szemben, és egyben ellenállónak kell lenniük a kerülő jellegű megoldások esetében. Ezek a problémák eleve összetettek és nehezen megoldhatók. Az ilyen problémák kiszűrése több, kiterjedt humán annotációs kampányt igényelt.

Ezeket a megállapításokat beépítettük a legutóbbi értékelési folyamataikba. Az elmúlt hónapokban úgy döntöttünk, hogy a SWE-Bench Pro nyilvános adatszeletéből származó eredményeket jelentjük. Azt javasoljuk, hogy más modellfejlesztők is tegyenek így. A SWE-bench Pro nem tökéletes, de a tapasztalatok alapján úgy tűnik, kevésbé kitett a szennyezettségi problémáknak. Szennyezési folyamatunk során találtunk néhány szennyeződési esetet, de ezek az esetek az SWE-bench Verified által végzett vizsgálatoknál lényegesen ritkábbak és kevésbé kirívóak voltak, és egyetlen modell sem tudott teljes, szó szerinti arany javítást létrehozni.

Továbbra is invesztálunk eredeti, privát módon készített benchmarkokba, és arra kérjük az iparági és akadémiai szereplőket, hogy tegyenek hasonlóan. A GDPVal⁠ esetében a feladatokat területi szakértők privát módon készítik, ami csökkenti az expozíciós kockázatot, a megoldásokat pedig képzett felülvizsgálók értékelik holisztikus szemléletben. Ez a megközelítés erőforrás-igényes, de egyre inkább szükséges a valódi képességfejlődés méréséhez.

2026

Szerző

OpenAI

Olvass tovább

Összes megtekintése

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Kutatások2026. jún. 4.

Új funkciók bevezetése a GPT-Rosalindbe

Termék2026. jún. 3.

A társadalmi reziliencia erősítése a Rosalind Biodefense segítségével

Termék2026. máj. 29.