Pereiti prie pagrindinio turinio
OpenAI

2026 m. vasario 23 d.

Moksliniai tyrimaiPublikacija

Kodėl „SWE-bench Verified“ nebeįvertina priešakinių programavimo gebėjimų

„SWE-bench Verified“ tampa vis labiau užterštas. Rekomenduojame naudoti „SWE-bench Pro“.

Įkeliama...

Nuo tada, kai 2024 m. rugpjūčio mėn. pirmą kartą paskelbėme „SWE-bench Verified“, pramonė jį plačiai naudoja siekdama išmatuoti modelių pažangą atliekant autonominės programinės įrangos inžinerijos užduotis. Po išleidimo „SWE-bench Verified“ suteikė stiprų gebėjimų pažangos signalą ir tapo standartine metrika, skelbiama išleidžiant priešakinius modelius. Šių gebėjimų pažangos stebėjimas ir prognozavimas taip pat yra svarbi „OpenAI“ Pasirengimo sistemos dalis. Iš pradžių kurdami „Verified“ lyginamąjį indeksą, bandėme išspręsti pradinio vertinimo problemas, dėl kurių tam tikrų užduočių buvo neįmanoma atlikti naudojant „SWE-bench“ duomenų rinkinį(atsidaro naujame lange).

Po pradinių šuolių pažangiausio lygio „SWE-bench Verified“ rezultatai sulėtėjo, per pastaruosius šešis mėnesius pagerėję(atsidaro naujame lange) nuo 74,9 proc. iki 80,9 proc. Kyla klausimas: ar likusios nesėkmės atspindi modelio apribojimus, ar paties duomenų rinkinio savybes?

Atlikę naują analizę, nustatėme dvi pagrindines „Verified“ rinkinio problemas, rodančias, kad lyginamasis indeksas nebetinkamas matuoti autonominės programinės įrangos inžinerijos gebėjimų pažangą priešakiniams pristatymams, esant dabartiniam našumo lygiui.

  1. Testai atmeta teisingus sprendimus: atlikome 27,6 proc. duomenų rinkinio dalies, kurių modeliams dažnai nepavykdavo išspręsti, auditą ir nustatėme, kad mažiausiai 59,4 proc. audituotų problemų turi ydingų testavimo atvejų, kurie atmeta funkciškai teisingus pateikimus, nepaisant mūsų dėtų visų pastangų tai pagerinti pradiniame „SWE-bench Verified“ kūrimo etape.
  2. Mokymas naudojant sprendimus: kadangi dideli priešakiniai modeliai gali išmokti informaciją iš savo mokymo, svarbu, kad jie niekada nebūtų mokomi naudojant problemas ir sprendimus, pagal kuriuos yra vertinami. Tai panašu į būsimo testo problemų ir sprendimų pasidalijimą su mokiniais prieš testą – jie gali neįsiminti atsakymo, bet mokiniai, kurie anksčiau matė atsakymus, tikrai pasieks geresnių rezultatų nei tie, kurie jų nematė. „SWE-bench“ problemos gaunamos iš atvirojo kodo saugyklų, kurias daugelis modelių teikėjų naudoja mokymo tikslais. Atlikę analizę nustatėme, kad visi mūsų išbandyti priešakiniai modeliai sugebėjo atkurti pradinį, žmogaus parašytą klaidos ištaisymą, naudojamą kaip etaloną, žinomą kaip etaloninę pataisą, arba pažodžiui pateikti konkrečias užduoties formuluotes, o tai rodo, kad visi jie per mokymą matė bent dalį problemų ir sprendimų.

Taip pat radome įrodymų, kad modeliai, matę problemas per mokymą, dažniau pasiekia rezultatų, nes turi papildomos informacijos, reikalingos išlaikyti nepakankamai apibrėžtus testus.

Tai reiškia, kad „SWE-bench Verified“ rezultatų pagerėjimas neatspindi reikšmingo modelių realių programinės įrangos kūrimo gebėjimų pagerėjimo. Vietoj to, tai vis labiau atspindi, kiek modelis buvo susidūręs su lyginamuoju indeksu per mokymą. Todėl nustojome skelbti „SWE-bench Verified“ rezultatus ir rekomenduojame kitiems modelių kūrėjams padaryti tą patį.

Kuriame naujus, neužterštus vertinimus, siekdami geriau sekti programavimo gebėjimus, ir manome, kad tai yra svarbi sritis, į kurią turėtų susitelkti platesnė tyrėjų bendruomenė. Kol jų neturime, „OpenAI“ rekomenduoja skelbti „SWE-bench Pro“ rezultatus.

Fonas

Pradinis „SWE-bench“(atsidaro naujame lange) vertinimas buvo išleistas 2023 m. Kiekviena problema gaunama iš išspręstos „GitHub“ problemos vienoje iš 12 atvirojo kodo „Python“ saugyklų ir susiejama su atitinkama išsiuntimo užklausa (PR). Norint nustatyti, ar modelio sugeneruotas kodo pakeitimas yra teisingas, prie kiekvienos problemos pateikiami du testų rinkiniai:

  • Testai, kurie nepavyksta nemodifikuotoje kodo bazėje, bet pavyksta teisingai išsprendus problemą
  • Regresijos testai, kurie išlaikomi tiek prieš išsprendžiant problemą, tiek po to, siekiant užtikrinti, kad nesusijusios funkcijos liktų nepakitusios.

Modelis nemato testų. Jis turi sugeneruoti kodo pakeitimą, gavęs tik pradinį problemos tekstą ir saugyklos būseną prieš išsprendžiant problemą. Jis problemą išsprendžia tik tada, jei pritaikius kodo pakeitimą išlaikomi visi testai.

Šiame vertinime nustatėme daug problemų, dėl kurių modelių gebėjimai gali būti nepakankamai įvertinti.

  • Kai kurie vienetiniai testai buvo pernelyg specifiški arba neatitiko užduoties, todėl teisingi sprendimai galėjo būti atmesti.
  • Daugelis užduočių formuluočių buvo nepakankamai apibrėžtos, o tai galėjo lemti kelias pagrįstas interpretacijas, kai testai apėmė tik vieną konkrečią.
  • Atsižvelgiant į aplinkos sąranką (pavyzdžiui, „Linux“ ar „Windows“, arba „Python“ versiją), kai kurie testai galėjo atsitiktinai nepavykti

Siekdami išspręsti šias problemas, 2024 m. sukūrėme „SWE-bench Verified“. Bendradarbiaudami su patyrusiais programinės įrangos inžinieriais peržiūrėjome 1 699 „SWE-bench“ problemas ir išfiltravome tas, kurios turėjo šių trūkumų. Kiekvieną problemą nepriklausomai peržiūrėjo trys ekspertai. Šio peržiūros proceso rezultatas – „SWE-bench Verified“, kuruotas 500 problemų rinkinys.

Per siauri ir per platūs testai

Nors „SWE-bench Verified“ yra didelis patobulinimas, palyginti su pradine versija, vis dar lieka problemų. Atlikome 138 „SWE-bench Verified“ problemų, kurių „OpenAI o3“ nuosekliai neišspręsdavo per 64 nepriklausomus vykdymus, auditą. Kiekvieną atvejį nepriklausomai peržiūrėjo bent šeši patyrę programinės įrangos inžinieriai. Ekspertui pažymėjus problemą, ją iš naujo patikrindavo papildoma komanda.

Nustatėme, kad 59,4 proc. iš 138 problemų turėjo esminių testų dizaino ir (arba) problemos aprašymo trūkumų, dėl kurių net ir pajėgiausiam modeliui ar žmogui jas išspręsti buvo itin sunku arba neįmanoma. 

  • 35,5 % audituotų užduočių turi griežtus testavimo atvejus, reikalaujančius konkrečių įgyvendinimo detalių, taip paneigiant daugelį funkciškai teisingų pateikimų, kuriuos mes vadiname siaurais testavimo atvejais.
  • 18,8 % audituotų užduočių turi testus, kuriais tikrinamas papildomas veikimas, nenurodytas problemos aprašyme, kuriuos mes vadiname plataus masto testavimo atvejais.
  • Likusios 5,1 proc. užduočių turėjo įvairių problemų, kurios nebuvo lengvai grupuojamos pagal šią taksonomiją.

Iliustratyvus pirmojo nesėkmės režimo pavyzdys yra pylint-dev__pylint-4551(atsidaro naujame lange), kur išsiuntimo užklausa pristato naują funkciją „get_annotation“ kaip bendro sprendimo dalį. Šis funkcijos pavadinimas neminimas problemos aprašyme, tačiau jis importuojamas tiesiogiai testų. Nors kai kurie modeliai gali intuityviai sukurti tokią funkciją, norint teisingai išspręsti problemą, nėra būtina įdiegti funkciją tokiu konkrečiu pavadinimu. Daugelis tinkamų sprendimų neatitinka testų dėl importavimo klaidų.

Problemos aprašymas

Paprastas tekstas

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

Išsiuntimo užklausos testo fragmentas

Python

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

Išsiuntimo užklausos testo nesėkmės (sutrumpinta dėl skaitomumo)

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)

Per plačių testavimo atvejų pavyzdys yra sympy__sympy-18199(atsidaro naujame lange). Ši užduotis buvo gauta iš išsiuntimo užklausos, kurioje buvo nagrinėjamos trys atskiros problemos, susijusios su funkcija „nthroot_mod“, konkrečiai #17373(atsidaro naujame lange), #17377(atsidaro naujame lange) ir #18212(atsidaro naujame lange). Tačiau „SWE-bench Verified“ užduoties aprašymas apima tik paskutinę problemą #18212(atsidaro naujame lange). Tai sukuria neatitikimą: išsiuntimo užklausų testai apima visas tris problemas, o aprašyme detalizuojama tik viena. Vykdant testus, modeliai dažnai teisingai įdiegia aprašytą pataisą ir tada neišlaiko testų, apimančių kitų dviejų problemų įgyvendinimą.

Pradinis išsiuntimo užklausos aprašymas (iš „GitHub“ išsiuntimo užklausos)

Paprastas tekstas

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

Problemos aprašymas nr. 18212

Paprastas tekstas

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.

„SWE-bench Verified“ užduoties problemos aprašymas (paimtas tik iš nr. 18212)

Paprastas tekstas

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.

Užterštumas

„SWE-bench Verified“ ir saugyklos (kodų bazės bei laidos pastabos) yra atvirojo kodo, plačiai naudojami ir aptariami, todėl modelių kūrėjams sunku išvengti duomenų užterštumo.

Pirmiausia užterštumo požymių pastebėjome savo pačių modeliuose. Pavyzdžiui, kai GPT‑5.2 išsprendė 31 užduotį, kurias nustatėme kaip beveik neįmanomas išspręsti. django__django-14725(atsidaro naujame lange) testai reikalauja specifinio naujo parametro „edit_only“, kurio aiškiai nereikalauja problemos formuluotė. Spręsdamas problemą, GPT‑5.2 savo minčių grandinėje parodo, kad turi informacijos apie laidos pastabas, kuriose išsamiai aprašyti kodų bazės pakeitimai, ir teisingai nustato, kad „edit_only“ parametras buvo įvestas „Django 4.1“ versijoje.

GPT‑5.2 CoT

Paprastas tekstas

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.

Siekdami plačiau įvertinti, koks reikšmingas yra užterštumas, sukūrėme automatizuotą testavimo spragoms nustatyti sąranką. Kiekvienam „SWE-bench Verified“ klausimui pavedėme „OpenAI GPT‑5“ patikrinti „GPT‑5.2‑Chat“, „Claude Opus 4.5“ ir „Gemini 3 Flash Preview“ dėl užterštumo. Šie modeliai buvo pasirinkti siekiant išskirti protavimo modelius, tačiau pripažįstame, kad tarp jų greičiausiai yra nemažas gebėjimų atotrūkis.

Siekdamas ištirti užterštumą, GPT‑5 gavo „SWE-bench Verified“ užduoties identifikatorių, aprašymą, etaloninę pataisą ir išsiuntimo užklausų testus. Per 15 raundų leidome „OpenAI GPT‑5“ keisti sistemos / kūrėjo užklausą, naudotojo užklausą, asistento išankstinį užpildymą ir skirtingas išgavimo strategijas. Po kiekvieno raundo teisėjavimo modelis pažymėjo, kiek atsirado naujos, su užduotimi susijusios informacijos, o kiekvienas atsakymas buvo pažymėtas pagal užterštumo sunkumą nuo „nėra“ iki „stiprus“. GPT‑5 buvo leista pritaikyti savo strategiją pagal ankstesnius raundus, siekiant iteratyviai atkurti konkrečias užduoties detales. Kiekvienam stipraus užterštumo pavyzdžiui su kitu teisėju patikrinome, ar GPT‑5 nenutekino per daug informacijos tiksliniam modeliui. Galiausiai rankiniu būdu peržiūrėjome „stiprius“ pavyzdžius, sudarančius šio įrašo stenogramas.

Toliau pateikti stipraus duomenų užterštumo skirtingų modelių teikėjų sistemose pavyzdžiai.

GPT‑5.2 

Gavęs trumpą fragmentą iš užduoties aprašymo, GPT‑5.2 išveda tikslią etaloninę pataisą. Visų pirma, jis žino tikslų klasės ir metodo pavadinimą ir įvestą naują išankstinio grąžinimo sąlygą if username is None or password is None.

Užterštumo išgavimas

Problemos formuluotė

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

Naudotojo raginimas

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"

Modelio atsakas

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.

Etaloninė pataisa

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“ geba ne tik prisiminti tikslų išsiuntimo užklausos įvestą keturių eilučių funkcinį pakeitimą, nurodydamas konkretų failo pavadinimą ir paveiktą metodą, bet ir pažodžiui cituoja įdėtąjį komentarą, buvusį skirtumų (angl. diff) dalyje.

Užterštumo išgavimas

Naudotojo užklausa

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.

Išankstinis užpildymas

1
Let me be precise about the location and wording.

Asistento atsakas

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

Etaloninė pataisa

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 

Gavęs tik identifikatorių ir jokios papildomos informacijos apie užduotį, „Gemini 3 Flash“ geba pažodžiui pateikti išsamią informaciją iš užduoties aprašymo ir etaloninės pataisos. Tai apima naują reguliariojo reiškinio formulę naudotojo vardui patvirtinti ir tikslius pakeitimo eilučių numerius.

Užterštumo išgavimas

Problemos formuluotė

1
UsernameValidator allows trailing newline in usernames

Naudotojo raginimas

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.

Išankstinis užpildymas

1
Let me be precise about the wording.

Modelio atsakas

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

Etaloninė pataisa

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

Šis „SWE-bench Verified“ auditas atskleidžia dvi platesnes vertinimo dizaino pamokas. Pirma, iš viešai prieinamos medžiagos gauti lyginamieji indeksai kelia duomenų užterštumo riziką, kai dėl mokymo duomenų poveikio rezultatai gali būti nepastebimai padidinti. Kuriant lyginamąjį indeksą naudojant viešai surinktus duomenis, modelių kūrėjai turėtų atlikti papildomus užterštumo testus. Viešai paskelbti lyginamieji indeksai ir net jų sprendimai gali atsidurti mokymo duomenyse. Reikėtų būti ypač atsargiems tiek skelbiant duomenų rinkinius (t. y. apsaugant slaptažodžiu), tiek filtruojant mokymo duomenis (t. y. griežtai laikantis kontrolinių eilučių). 

Antra, sunku užtikrinti tinkamą automatizuotą vertinimą. Tobuli testavimo atvejai turėtų visiškai patikrinti tinkamą veikimą, nebūdami priklausomi nuo konkrečių nesvarbių įgyvendinimo detalių ir būdami atsparūs trumpesniems sprendimams. Šios problemos iš esmės yra sudėtingos ir sunkiai išsprendžiamos. Šioms problemoms nustatyti prireikė kelių didelės apimties žmonių atliekamo žymėjimo kampanijų. 

Šiuos radinius įtraukėme į savo naujausius vertinimo darbus. Pastaraisiais mėnesiais nusprendėme skelbti viešosios „SWE-Bench Pro“ dalies rezultatus. Rekomenduojame kitiems modelių kūrėjams padaryti tą patį. „SWE-bench Pro“ nėra tobulas, bet empiriškai atrodo, kad jis mažiau susiduria su duomenų užterštumo problemomis. Mūsų užterštumo nustatymo konvejeris aptiko keletą užterštumo atvejų, tačiau jie buvo gerokai retesni ir ne tokie akivaizdūs kaip „SWE-bench Verified“, ir nė vienas modelis nesugebėjo pažodžiui sugeneruoti visos etaloninės pataisos.

Toliau investuosime į originalius, privačiai sukurtus lyginamuosius indeksus ir prašysime pramonės bei akademinės bendruomenės pagalbos daryti tą patį. Programoje „GDPVal“ užduotis privačiai kuria srities ekspertai, taip sumažindami poveikio riziką, o sprendimus holistiškai vertina išmokyti tikrintojai. Šis požiūris reikalauja daug išteklių, tačiau jis vis labiau būtinas norint išmatuoti tikrą gebėjimų pagerėjimą.

Autorius

OpenAI