2026. gada 23. februāris

Kāpēc SWE-bench Verified vairs nemēra robežšķirtnes programmēšanas spējas

SWE-bench Verified kļūst arvien piesārņotāks. Mēs iesakām SWE-bench Pro.

Notiek ielāde…

Kopš mēs sākotnēji publicējām SWE-bench Verified 2024. gada augustā, nozare to ir plaši izmantojusi, lai novērtētu modeļu progresu autonomos programmatūras inženierijas uzdevumos. Pēc tā izlaišanas SWE-bench Verified sniedza spēcīgu signālu par spēju progresu un kļuva par standarta metriku, par kuru ziņo robežšķirtnes modeļu izlaidumos. Šo spēju progresa izsekošana un prognozēšana ir arī svarīga OpenAI Sagatavotības satvara daļa. Kad sākotnēji izveidojām Verified etalonu, mēs mēģinājām atrisināt problēmas sākotnējā novērtējumā, kas padarīja noteiktus uzdevumus neiespējamus SWE-bench datu kopā⁠(atveras jaunā logā).

Pēc sākotnējiem lēcieniem progress SWE-bench Verified progress ir palēninājies, pēdējo 6 mēnešu laikā uzlabojoties⁠(atveras jaunā logā) no 74,9% uz 80,9%. Tas rada jautājumu: vai atlikušās kļūmes atspoguļo modeļa ierobežojumus vai pašas datu kopas īpašības?

Jaunā analīzē mēs atklājām divas galvenās problēmas ar Verified kopu, kas liecina, ka etalons vairs nav piemērots, lai mērītu progresu autonomo programmatūras inženierijas spēju jomā robežšķirtnes palaišanām mūsdienu veiktspējas līmeņos:

Testi noraida pareizus risinājumus: mēs auditējām 27,6% apakškopu no datu kopas, kuru modeļi bieži nespēja atrisināt, un konstatējām, ka vismaz 59,4% auditēto uzdevumu ir kļūdaini testa gadījumi, kas noraida funkcionāli pareizus iesniegumus, neskatoties uz mūsu labākajiem centieniem to uzlabot sākotnējā SWE-bench Verified izveidē.
Apmācība ar risinājumiem: Tā kā lieli robežšķirtnes modeļi var apgūt informāciju no apmācības datiem, ir svarīgi, lai tie nekad netiktu apmācīti ar problēmām un risinājumiem, uz kuriem tie tiek novērtēti. Tas ir līdzīgi kā skolēniem iepriekš parādīt gaidāmā kontroldarba uzdevumus un risinājumus – viņi var neatcerēties atbildes no galvas, taču skolēniem, kuri atbildes ir redzējuši iepriekš, noteikti veiksies labāk nekā tiem, kuri tās nav redzējuši. SWE-bench uzdevumi tiek iegūti no atvērtā koda repozitorijiem, kurus daudzi modeļu nodrošinātāji izmanto apmācības nolūkiem. Savā analīzē mēs atklājām, ka visi robežšķirtnes modeļi, kurus testējām, spēja reproducēt oriģinālo, cilvēka rakstīto kļūdas labojumu, kas tika izmantots kā patiesās atbildes atsauces etalons (saukts par "zelta ielāpu"), vai arī burtiski atveidot problēmas izklāsta specifiku noteiktiem uzdevumiem, un tas norāda, ka visi no tiem mācību laikā ir redzējuši vismaz daļu no uzdevumiem un risinājumiem.

Mēs arī atradām pierādījumus, ka modeļiem, kas uzdevumus ir redzējuši apmācības laikā, ir lielāka iespēja gūt panākumus, jo tiem ir papildu informācija, kas nepieciešama, lai izturētu nepietiekami specificētos testus.

Tas nozīmē, ka uzlabojumi SWE-bench Verified vairs neatspoguļo jēgpilnus uzlabojumus modeļu reālās pasaules programmatūras izstrādes spējās. Tā vietā tie arvien vairāk atspoguļo to, cik lielā mērā modelis mācību laikā tika pakļauts etalonam. Tāpēc mēs esam beiguši ziņot par SWE-bench Verified rezultātiem, un mēs iesakām arī citiem modeļu izstrādātājiem rīkoties tāpat.

Mēs veidojam jaunus, nepiesārņotus novērtējumus, lai labāk izsekotu programmēšanas spējas, un mēs uzskatām, ka šī ir svarīga joma, kurai pievērst uzmanību plašākai pētniecības kopienai. Līdz brīdim, kad mums tie būs, OpenAI iesaka ziņot par SWE-bench Pro rezultātiem.

Fons

Sākotnējais SWE-bench⁠(atveras jaunā logā) novērtējums tika laists klajā 2023. gadā. Katrs uzdevums ir iegūts no atrisinātas GitHub problēmas vienā no 12 atvērtā koda Python repozitorijiem un sasaistīts ar atbilstošo pull request (PR). Lai noteiktu, vai modeļa ģenerētā koda izmaiņa ir pareiza, katram uzdevumam ir divas testu kopas:

Testi, kas neiztur pārbaudi nemodificētā kodā, bet iztur, ja problēma ir pareizi izlabota
Regresijas testi, kas iztur pārbaudi gan pirms, gan pēc labojuma, lai nodrošinātu, ka nesaistītā funkcionalitāte paliek neskarta.

Modelis testus neredz. Tam ir jāizveido koda izmaiņas, ņemot vērā tikai sākotnējo uzdevuma tekstu un repozitorija stāvokli pirms labojuma. Tas nokārto uzdevumu tikai tad, ja pēc koda izmaiņu piemērošanas iztur visus testus.

Mēs atklājām daudzas problēmas ar šo novērtējumu, kas varētu novest pie modeļu spēju nepietiekamas novērtēšanas.

Daži vienības testi bija pārāk specifiski vai neatbilda uzdevumam, tāpēc pareizi labojumi varēja tikt noraidīti.
Daudzi uzdevumu izklāsti bija nepietiekami definēti, kas varētu novest pie vairākām derīgām interpretācijām – kamēr testi aptvēra tikai vienu konkrētu.
Atkarībā no vides iestatījumiem (Linux vai Windows, vai Python versijas) daži testi var nepamatoti neizdoties

Mēs izveidojām SWE-bench Verified 2024. gadā, lai risinātu šīs problēmas. Mēs sadarbojāmies ar pieredzējušiem programmatūras inženieriem, lai pārskatītu 1699 SWE-bench uzdevumus un izfiltrētu uzdevumus, kuriem bija šīs problēmas. Katru uzdevumu neatkarīgi pārskatīja trīs eksperti. Šī pārskatīšanas procesa rezultātā tika iegūts SWE-bench Verified – atlasītu 500 uzdevumu kopums.

Pārāk šauri un pārāk plaši testi

Lai gan SWE-bench Verified ir būtisks uzlabojums salīdzinājumā ar sākotnējo versiju, joprojām pastāv problēmas. Mēs veicām auditu 138 SWE-bench Verified uzdevumiem, kurus OpenAI o3 neizdevās konsekventi atrisināt 64 neatkarīgos mēģinājumos. Katru gadījumu neatkarīgi pārskatīja vismaz seši pieredzējuši programmatūras inženieri. Ja eksperts atzīmēja kādu problēmu, to atkārtoti pārbaudīja vēl viena komanda.

Mēs konstatējām, ka 59,4% no 138 uzdevumiem ietvēra būtiskas nepilnības testa izstrādē un/vai uzdevuma aprakstā, padarot tos ārkārtīgi grūti atrisināmus vai pat neiespējamus pat viskompetentākajam modelim vai cilvēkam.

35,5% no auditētajiem uzdevumiem ir stingri testu gadījumi, kas uzspiež konkrētas ieviešanas detaļas, padarot nederīgus daudzus funkcionāli pareizus iesniegumus – to mēs saucam par šauriem testu gadījumiem.
18,8% no auditētajiem uzdevumiem ir testi, kas pārbauda papildu funkcionalitāti, kas nebija norādīta problēmas aprakstā – to mēs saucam par plašaiem testu gadījumiem.
Atlikušie 5,1% uzdevumu bija ar dažādām problēmām, kas nebija labi sagrupētas šajā taksonomijā.

Ilustratīvs pirmā kļūmes veida piemērs ir pylint-dev__pylint-4551⁠(atveras jaunā logā), kur PR kā daļu no kopējā risinājuma ievieš jaunu funkciju `get_annotation`. Šis funkcijas nosaukums nav minēts uzdevuma aprakstā, bet to tieši importē testi. Lai gan daži modeļi varētu intuitīvi izveidot šādu funkciju, nav nepieciešams ieviest funkciju ar tieši šādu nosaukumu, lai pareizi risinātu uzdevumu. Daudzi derīgi risinājumi neiztur testus importēšanas kļūdu dēļ.

Problēmas apraksts

Vienkāršs teksts

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 testa fragments

Python

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

PR testu kļūmes (saīsināts lasāmības labad)

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ārāk plašu testu piemērs ir sympy__sympy-18199⁠(atveras jaunā logā). Šis uzdevums tika iegūts no PR, kas risināja trīs atšķirīgas problēmas ar funkciju `nthroot_mod`, konkrēti #17373⁠(atveras jaunā logā), #17377⁠(atveras jaunā logā) un #18212⁠(atveras jaunā logā). Tomēr SWE-bench Verified uzdevuma apraksts aptver tikai pēdējo uzdevumu #18212⁠(atveras jaunā logā). Tas rada neatbilstību – PR testi aptver visus trīs uzdevumus, kamēr aprakstā ir detalizēti izklāstīts tikai viens. Mūsu izpildēs modeļi bieži pareizi ievieš aprakstīto labojumu un pēc tam neiztur testus, kas aptver ieviešanu pārējo divu problēmu gadījumā.

Sākotnējais PR apraksts (no GitHub PR).

Vienkāršs teksts

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

Uzdevuma apraksts par #18212

Vienkāršs teksts

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 uzdevuma problēmas apraksts (ņemts tikai no #18212):

Vienkāršs teksts

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.

Piesārņojums

SWE-bench Verified un repozitoriji (koda bāzes un laidienu piezīmes) ir gan atvērtā koda, gan plaši izmantoti un apspriesti, kas modeļu izstrādātājiem apgrūtina izvairīšanos no datu piesārņojuma.

Mēs vispirms saskārāmies ar piesārņojuma pazīmēm mūsu pašu modeļos. Piemēram, kad GPT‑5.2 atrisināja 31 uzdevumu, ko mēs bijām identificējuši kā gandrīz neatrisinājumu. Attiecībā uz uzdevumu django__django-14725⁠(atveras jaunā logā) testi prasa konkrētu jaunu parametru `edit_only`, kas nav skaidri prasīts uzdevuma izklāstā. Risinot uzdevumu, GPT‑5.2 savā domu ķēdē parāda, ka tam ir informācija par laidiena piezīmēm, kurās detalizēti aprakstītas izmaiņas koda bāzē, un pareizi identificē, ka parametrs `edit_only` tika ieviests Django 4.1.

GPT‑5.2 CoT

Vienkāršs teksts

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.

Lai novērtētu, cik nozīmīgs piesārņojums ir plašākā mērogā, mēs izveidojām automatizētu sarkanās komandas pārbaudes procesu. Katram SWE-bench Verified jautājumam mēs uzdevām GPT‑5 aptaujāt GPT‑5.2‑Chat, Claude Opus 4.5 un Gemini 3 Flash Preview par piesārņojumu. Šie modeļi tika izvēlēti, lai izslēgtu spriestspējas modeļus, taču mēs atzīstam, ka starp tiem, visticamāk, pastāv būtiska spēju atšķirība.

Lai pārbaudītu piesārņojumu, GPT‑5 saņēma: SWE-bench Verified uzdevuma ID, aprakstu, zelta ielāpu un PR testus. Vairāk nekā 15 kārtu laikā mēs ļāvām GPT‑5 variēt sistēmas/izstrādātāja uzvedni, lietotāja uzvedni un palīga iepriekšējo aizpildījumu, kā arī dažādas identificēšanas stratēģijas. Pēc katra gājiena tiesneša modelis atzīmēja, cik daudz jaunas, uzdevumam specifiskas informācijas parādījās, un katra atbilde tika marķēta pēc piesārņojuma smaguma pakāpes no “nav” to “spēcīgs”. GPT‑5 bija atļauts pielāgot savu stratēģiju, pamatojoties uz iepriekšējām kārtām, lai iteratīvi atgūtu uzdevumam specifiskas detaļas. Katram spēcīga piesārņojuma piemēram mēs ar citu tiesnesi verificējām, ka GPT‑5 mērķa modelim neizpauda pārāk daudz informācijas. Visbeidzot mēs manuāli pārskatījām “spēcīgos” piemērus, kas veido šī ieraksta transkriptus.

Zemāk ir piemēri par spēcīgu piesārņojumu dažādu modeļu nodrošinātāju vidū.

GPT‑5.2

Ja ir dots īss fragments no uzdevuma apraksta, GPT‑5.2 izvada precīzu zelta ielāpu. Jo īpaši tas zina precīzu klases un metodes nosaukumu, kā arī jauno agrīnās atgriešanās nosacījumu `if username is None or password is None`, kas tiek ieviests.

Uzdevuma ID: django__django-11451⁠(atveras jaunā logā)

Piesārņojuma identificēšana

Problēmas apraksts

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

Lietotāja uzvedne

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"

Modeļa atbilde

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.

Zelta ielāps

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 spēj ne tikai atcerēties precīzu 4 rindu funkcionālo izmaiņu, ko ieviesa PR, kā arī konkrēto faila nosaukumu un metodi, ko tas skāra, bet arī burtiski citē iekļauto komentāru, kas bija daļa no diff.

Uzdevuma ID: astropy__astropy-13236⁠(atveras jaunā logā)

Piesārņojuma identificēšana

Lietotāja uzvedne

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.

Iepriekš aizpildīt

1Let me be precise about the location and wording.

Asistenta atbilde

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

Zelta ielāps

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, ja papildus ID nav sniegta nekāda cita informācija par uzdevumu, spēj izvadīt burtisku informāciju no uzdevuma apraksta un zelta ielāpa. Tas ietver jauno regex formulu lietotājvārda validācijai un precīzus rindu numurus izmaiņām.

Uzdevuma ID: django__django-11099⁠(atveras jaunā logā)

Piesārņojuma identificēšana

Problēmas apraksts

1UsernameValidator allows trailing newline in usernames

Lietotāja uzvedne

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.

Iepriekš aizpildīts

1Let me be precise about the wording.

Modeļa atbilde

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

Zelta ielāps

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

Diskusija

No šī SWE-bench Verified audita mēs saskatām divas plašākas mācības novērtējumu izstrādei. Pirmkārt, etalonuzdevumi, kas iegūti no publiski pieejamiem materiāliem, rada piesārņojuma risku, jo saskare ar mācību datiem var nemanāmi mākslīgi paaugstināt rezultātus. Ja etalona izveidē tiek izmantoti publiski pārmeklēti dati, modeļu izstrādātājiem būtu jāveic papildu testi, lai pārbaudītu datu piesārņojumu. Etaloni, un pat to risinājumi, kas padarīti publiski, var nonākt mācību datos. Īpaša piesardzība jāievēro gan attiecībā uz to, kā tiek publicētas datu kopas (t.i., aizsardzība ar paroli), gan apmācības datu filtrēšanā (t.i., stingra marķiervirkņu ievērošana).

Otrkārt, automatizēta vērtēšana ir grūti pareizi īstenojama; ideāliem testa gadījumiem vajadzētu pilnībā verificēt pareizu funkcionalitāti, būt gan agnostiskiem pret konkrētām nesvarīgām ieviešanas detaļām, gan arī izturīgiem pret saīsinātiem risinājumiem. Šīs problēmas pēc būtības ir sarežģītas un grūti atrisināmas. Šo problēmu atklāšanai bija nepieciešamas vairākas apjomīgas cilvēku veiktas marķēšanas kampaņas.

Mēs esam iekļāvuši šos secinājumus savos pēdējā laika novērtēšanas centienos. Pēdējos mēnešos mēs esam izvēlējušies ziņot rezultātus no SWE-Bench Pro publiskās daļas. Mēs iesakām citiem modeļu izstrādātājiem darīt to pašu. SWE-bench Pro nav ideāls, taču empīriski šķiet, ka tas mazāk cieš no piesārņojuma problēmām. Mūsu piesārņojuma noteikšanas process atklāja dažus piesārņojuma gadījumus, taču tie bija ievērojami retāki un mazāk smagi nekā SWE-bench Verified, un neviens modelis nespēja izveidot pilnīgu burtisku zelta ielāpu.

Mēs turpināsim ieguldīt oriģinālos, privāti izstrādātos etalonrādītājos un lūgsim nozares un akadēmiskās vides palīdzību darīt to pašu. Etalonā GDPVal⁠ uzdevumus privāti izstrādā jomas eksperti, samazinot izpaušanas risku, un risinājumus holistiski vērtē apmācīti recenzenti. Šī pieeja prasa daudz resursu, taču ir arvien nepieciešamāka, lai izmērītu patiesus spēju uzlabojumus.

2026

Autors

OpenAI

Turpināt lasīt

Skatīt visu

Better memory for a more helpful ChatGPT

Stiprāks pamats ChatGPT atmiņai

Izpēte2026. g. 4. jūn.

Iepazīstinām ar jaunām GPT-Rosalind iespējām

Produkts2026. g. 3. jūn.

Sabiedrības noturības stiprināšana ar Rosalind Biodefense

Produkts2026. g. 29. maijs