Jäta vahele ja mine põhisisu juurde
OpenAI

23. veebruar 2026

TeadustööVäljaanne

Miks SWE-bench Verified ei mõõda enam tipptasemel kodeerimisvõimekust

SWE-bench Verified on üha rohkem saastunud. Soovitame SWE-bench Pro.

Laadimine…

Alates sellest, kui avaldasime esmakordselt SWE-bench kinnitatud 2024. aasta augustis, on valdkond seda laialdaselt kasutanud, et mõõta mudelite arengut autonoomsete tarkvaratehnika ülesannete täitmisel. Pärast selle avaldamist andis SWE-bench Verified tugeva signaali võimekuse edenemisest ja sai tipptasemel mudelite väljalasetes raporteeritavaks standardmõõdikuks. Nende võimekuste edenemise jälgimine ja prognoosimine on samuti oluline osa OpenAI Valmisoleku raamistikust. Kui me algselt lõime Verifiedi võrdlusaluse, püüdsime lahendada algse hindamise probleeme, mis muutsid teatud ülesanded SWE-bench dataset(avaneb uues aknas)is võimatuks.

Pärast esialgseid hüppeid on tipptasemel edasiminek SWE-bench Verifiedil aeglustunud, paranedes(avaneb uues aknas) viimase 6 kuu jooksul 74,9%-lt 80,9%-le. See tõstatab küsimuse: kas ülejäänud ebaõnnestumised peegeldavad mudeli piiranguid või andmestiku enda omadusi?

Uues analüüsis leidsime Verified komplektis kaks suurt probleemi, mis viitavad sellele, et võrdlusalus ei sobi enam tipptasemel lansseerimiste puhul autonoomse tarkvaratehnika võimekuse arengu mõõtmiseks tänaste jõudlustasemete juures.

  1. Testid lükkavad õiged lahendused tagasi: me auditeerisime 27,6% andmestiku alamhulgast, mida mudelid sageli ei suutnud lahendada, ja leidsime, et vähemalt 59,4% auditeeritud ülesannetest on vigaste testjuhtumitega, mis lükkavad funktsionaalselt õiged esitused tagasi, hoolimata meie parimatest pingutustest seda SWE-bench Verifiedi loomisel parandada.
  2. Lahenduste koolitus: kuna suured tipptasemel mudelid võivad oma koolitusest teavet õppida, on oluline, et neid ei koolitataks kunagi probleemide ja lahenduste peal, mille põhjal neid hinnatakse. See on sarnane sellega, kui jagada õpilastega enne eelseisvat testi testiga seotud probleeme ja lahendusi – nad ei pruugi vastust pähe õppida, kuid õpilased, kes on vastuseid varem näinud, saavad kindlasti paremini hakkama kui need, kes ei ole. SWE-bench probleemid pärinevad avatud lähtekoodiga varamutest, mida paljud mudelipakkujad kasutavad koolituse eesmärgil. Meie analüüsis leidsime, et kõik testitud tipptasemel mudelid suutsid reprodutseerida algse, inimese kirjutatud veaparanduse, mida kasutati tõepärase viitena (ground-truth reference) ja mida tuntakse kuldpaigana (gold patch), või teatud ülesannete puhul sõna-sõnalt probleemikirjelduse spetsiifikat, mis viitab sellele, et kõik neist on koolituse käigus näinud vähemalt mõningaid probleeme ja lahendusi.

Leidsime ka tõendeid selle kohta, et mudelid, mis on koolituse käigus probleeme näinud, on suurema tõenäosusega edukad, sest neil on määratlemata testide läbimiseks vajalik lisateave.

See tähendab, et SWE-bench Verifiedi parandused ei kajasta enam sisulisi parandusi mudelite reaalse maailma tarkvaraarenduse võimekuses. Selle asemel peegeldavad need üha enam seda, kui palju mudel koolituse ajal mõõdupuuga kokku puutus. Seetõttu oleme lõpetanud SWE-bench Verified skooride raporteerimise ning soovitame, et teised mudeliarendajad teeksid samuti.

Me loome uusi, saastamata hindamisi, et paremini jälgida kodeerimisvõimekusi, ning usume, et see on oluline valdkond, millele laiemal teaduskogukonnal tasub keskenduda. Kuni meil need on, soovitab OpenAI raporteerida tulemusi SWE-bench Pro jaoks.

Taust

Algne SWE-benchi(avaneb uues aknas) hindamine avaldati 2023. aastal. Iga probleem pärineb lahendatud GitHubi probleemist ühes 12 avatud lähtekoodiga Pythoni varamus ja on seotud vastava pull requestiga (PR). Et teha kindlaks, kas mudeli genereeritud koodimuudatus on korrektne, on iga probleemiga kaasas kaks testikomplekti:

  • Testid, mis ebaõnnestuvad muutmata koodibaasis, kuid õnnestuvad, kui sa parandad probleemi õigesti
  • Regressioonitestid, mis läbivad nii enne kui ka pärast parandust, et tagada mitteseotud funktsionaalsuse säilimine.

Mudel ei näe teste. See peab looma koodimuudatuse, kasutades ainult algset probleemi teksti ja varamu olekut enne parandust. See läbib probleemi ainult siis, kui pärast koodimuudatuse rakendamist läbivad kõik testid.

Leidsime selle hindamisega seoses palju probleeme, mis võiksid viia mudelite võimekuse alaraporteerimiseni.

  • Mõned üksusetestid olid liiga spetsiifilised või ülesandega mittevastavuses, mistõttu võidi õiged parandused tagasi lükata.
  • Paljud ülesande kirjeldused olid ebapiisavalt täpsustatud, mis võis viia mitme kehtiva tõlgenduseni – samal ajal kui testid hõlmasid ainult üht konkreetset.
  • Sõltuvalt keskkonna seadistusest (näiteks Linux vs Windows või pythoni versioonist) võivad mõned testid ekslikult ebaõnnestuda

Lõime 2024. aastal SWE-bench kinnitatud, et neid probleeme lahendada. Töötasime koos ekspertidest tarkvarainseneridega, et vaadata üle 1,699 SWE-bench probleemi ja filtreerida välja probleemid, millel esinesid need probleemid. Iga probleem vaadati kolme eksperdi poolt sõltumatult läbi. See ülevaatusprotsess andis tulemuseks SWE-bench kinnitatud, kureeritud 500 probleemi kogumi.

Liiga kitsad ja liiga laiad testid

Kuigi SWE-bench Verified on algse versiooniga võrreldes suur edasiminek, püsivad alles probleemid. Viisime läbi auditi 138 SWE-bench Verified ülesande kohta, mida OpenAI o3 ei lahendanud järjepidevalt 64 sõltumatu käituse jooksul. Iga juhtum vaadati sõltumatult üle vähemalt kuue kogenud tarkvarainseneri poolt. Kui ekspert märkis probleemi, kontrollis täiendav meeskond selle uuesti üle.

Leidsime, et 59,4% 138 probleemist sisaldas olulisi puudusi testi ülesehituses ja/või probleemi kirjelduses, muutes need äärmiselt raskeks või võimatuks lahendada isegi kõige võimekamale mudelile või inimesele. 

  • 35,5% auditeeritud ülesannetest on rangete testjuhtumitega, mis nõuavad konkreetseid teostusüksikasju, muutes paljud funktsionaalselt õiged esitused kehtetuks; neid nimetame kitsasteks testjuhtumiteks.
  • 18,8% auditeeritud ülesannetest on testid, mis kontrollivad täiendavat funktsionaalsust, mida probleemikirjelduses ei olnud täpsustatud, mida me nimetame laiadeks testjuhtumiteks.
  • Ülejäänud 5,1% ülesannetest esines mitmesuguseid probleeme, mida ei olnud selle taksonoomiaga hästi rühmitatud.

Esimese tõrkerežiimi näide on pylint-dev__pylint-4551(avaneb uues aknas), kus PR lisab uue funktsiooni `get_annotation` osana lahendusest. Seda funktsiooni nime ei mainita probleemi kirjelduses, aga testid impordivad selle otse. Kuigi mõned mudelid võivad intuitiivselt luua sellise funktsiooni, ei ole probleemi lahendamiseks rangelt vajalik teha funktsiooni just selle konkreetse nimega. Paljud kehtivad lahendused kukuvad testid läbi impordivigade tõttu.

Probleemi kirjeldus

Lihtne tekst

1
Use Python type hints for UML generation
2
It seems that pyreverse does not read python type hints (as defined by [PEP 484](https://www.python.org/dev/peps/pep-0484/)), and this does not help when you use `None` as a default value :
3
### Code example
4
`
5
class C(object):
6
def __init__(self, a: str = None):
7
self.a = a
8
`
9
### Current behavior
10
Output of pyreverse :
11
![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12
### Expected behavior
13
I would like to see something like : `a : String` in the output.
14
### pylint --version output
15
pylint-script.py 1.6.5,
16
astroid 1.4.9
17
Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

PR testkood

Python

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

PR-testi ebaõnnestumised (loetavuse huvides kärbitud)

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)

Liiga laiad testjuhtumid on näiteks sympy__sympy-18199(avaneb uues aknas). See ülesanne pärines PR-ist, mis käsitles `nthroot_mod` funktsiooniga seotud kolme eraldiseisvat probleemi, täpsemalt #17373(avaneb uues aknas), #17377(avaneb uues aknas) ja #18212(avaneb uues aknas). SWE-bench Verified ülesande kirjeldus hõlmab aga ainult lõplikku probleemi #18212(avaneb uues aknas). See tekitab vastuolu: PR-testid katavad kõik kolm probleemi, samas kui kirjeldus käsitleb ainult üht. Meie katsetustes rakendavad mudelid sageli kirjeldatud paranduse õigesti ja seejärel kukuvad läbi testides, mis katavad ülejäänud kahe probleemi implementatsiooni.

Algne PR-i kirjeldus (GitHubi PR-ist)

Lihtne tekst

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

Probleemi kirjeldus #18212 jaoks

Lihtne tekst

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

3
When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Probleemi kirjeldus SWE-bench Verified ülesande jaoks (võetud ainult #18212-st):

Lihtne tekst

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

3
When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Saastatus

SWE-bench Verified ja varamud (koodibaasid ja väljalaskemärkmed) on mõlemad avatud lähtekoodiga ning laialdaselt kasutusel ja arutatud, mis teeb saastumise vältimise mudeli arendajatele keeruliseks.

Me kohtasime esmakordselt saastumise märke omaenda mudelites. Näiteks kui GPT‑5.2 lahendas 31 ülesannet, mille me tuvastasime olevat peaaegu võimatu lahendada. Failis django__django-14725(avaneb uues aknas) nõuavad testid konkreetset uut parameetrit `edit_only`, mida probleemikirjeldus selgesõnaliselt ei nõua. Probleemi lahendamise käigus näitab GPT‑5.2 oma mõttekäigus, et tal on teavet väljalaskemärkmete kohta, mis kirjeldavad koodibaasi muudatusi, ning tuvastab õigesti, et parameeter `edit_only` võeti kasutusele Django 4.1-s.

GPT‑5.2 mõttekäik

Lihtne tekst

1
There is also `edit_only` parameter maybe added around 4.1 or 4.2. Since this is 4.1 dev 2022, the code might be before introduction. We will implement now. Hidden tests will check new behavior.

Et hinnata, kui ulatuslikult oluline saastumine on, lõime automatiseeritud lööktestimise seadistuse. Iga SWE-bench Verified küsimuse jaoks palusime GPT‑5‑l sondeerida GPT‑5.2‑Chat'i, Claude Opus 4.5 ja Gemini 3 Flash eelvaade saastumise jaoks. Need mudelid valiti selleks, et välistada arutlusmudelid, kuid tunnistame, et nende vahel on tõenäoliselt märkimisväärne võimekuse lõhe.

Saastumise tuvastamiseks sai GPT‑5: SWE-bench Verified ülesande ID, kirjelduse, gold patch’i ja PR testid. Rohkem kui 15 käigu jooksul lasime GPT‑5‑l varieerida süsteemi-/arendaja viipa, kasutaja viipa ja assistendi eeltäitmist ning erinevaid esilekutsumisstrateegiaid. Pärast iga vooru märkis kohtuniku mudel, kui palju uut ülesandespetsiifilist teavet ilmus, ja iga vastus märgistati saastatuse raskusastme järgi vahemikus “none” kuni “strong.” GPT‑5‑l lubati kohandada oma strateegiat varasemate voorude põhjal, et iteratiivselt taastada ülesandepõhised üksikasjad. Iga tugeva saastumise näite puhul kontrollisime teise kohtunikuga, et GPT‑5 ei lekitanud sihtmudelile liiga palju teavet. Lõpuks vaatasime seejärel käsitsi läbi „tugevad“ näited, millest koosnevad selle postituse transkriptsioonid.

Allpool on näited tugevast saastumisest erinevate mudelipakkujate seas.

GPT‑5.2 

Kui sa annad ülesande kirjeldusest lühikese katke, siis GPT‑5.2 väljastab täpse kuldse paranduse. Eelkõige teab see täpset klassi ja meetodi nime ning uut varajase tagastuse tingimust `if username is None or password is None`, mis on lisatud.

Saastatuse esiletoomine

Probleemikirjeldus

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

Kasutajaviip

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"

Mudeli vastus

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.

Kuldne parandus

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 suudab mitte ainult meenutada PR-i sisse viidud täpset 4-line funktsionaalset muudatust koos konkreetse failinime ja meetodiga, mida see puudutas, vaid tsiteerib ka sõna-sõnalt diffi osaks olnud reasisest kommentaari. 

Saastatuse esiletoomine

Kasutajaviip

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.

Eeltäitmine

1
Let me be precise about the location and wording.

Assistendi vastus

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

Kuldne parandus

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 

Kui Gemini 3 Flashile ei anta ülesande kohta peale ID lisateavet, suudab see kuvada ülesande kirjelduse ja kuldse paranduse üksikasju sõna-sõnalt. See hõlmab uut regex-valemit kasutajanime valideerimiseks ja muudatuse täpseid reanumbreid.

Saastatuse esiletoomine

Probleemikirjeldus

1
UsernameValidator allows trailing newline in usernames

Kasutajaviip

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.

Eeltäitmine

1
Let me be precise about the wording.

Mudeli vastus

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

Kuldne parandus

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

Arutelu

Sellest SWE-bench Verifiedi auditist näeme hindamiskujunduse jaoks kahte laiemat õppetundi. Esiteks kaasneb avalikult kättesaadavast materjalist pärinevate võrdlusmõõdikutega saastumisrisk, kus kokkupuude koolitusandmetega võib vaikselt tulemusi üles paisutada. Kui võrdlusaluse koostamisel kasutatakse avalikult indekseeritud andmeid, peaksid mudeli arendajad tegema saastumise tuvastamiseks täiendavaid teste. Võrdlusanalüüsid ja isegi nende lahendused, mis on avalikult postitatud, võivad sattuda treeningandmetesse. Erilist hoolt tuleks kanda nii selles, kuidas andmekogumeid postitatakse (s.t. parooliga kaitstud) ja koolitusandmete filtreerimine (s.t. canary stringide range järgimine). 

Teiseks on automatiseeritud hindamine keeruline; ideaalsed testjuhtumid peaksid täielikult kontrollima funktsionaalsust, olles sõltumatud ebaolulistest detailidest ja vastupidavad otseteelahendustele. Need probleemid on keerulised ja neid on raske lahendada. Nende probleemide leidmine nõudis mitut ulatuslikku märgendamiskampaaniat. 

Oleme need järeldused kaasanud oma hiljutistesse hindamispingutustesse. Viimastel kuudel oleme otsustanud raporteerida tulemusi SWE-Bench Pro avalikust jaotusest. Soovitame teistel mudeli arendajatel teha sama. SWE-bench Pro ei ole täiuslik, kuid empiiriliselt näib see kannatavat vähem saastumisega seotud probleemide all. Meie saastumise tuvastamise torustik leidis mõned saastumise juhtumid, kuid need juhtumid olid märkimisväärselt haruldasemad ja vähem rängad kui SWE-bench Verifiedis ning ükski mudel ei suutnud luua täielikku sõna-sõnalt vastavat gold patch’i.

Jätkame investeerimist algupärastesse, eraviisiliselt koostatud võrdlusmõõdikutesse ja palume tööstuselt ja akadeemilistelt ringkondadelt abi, et teha sama. GDPVal-is on ülesanded domeeniekspertide poolt privaatselt koostatud, vähendades kokkupuute riski, ja lahendusi hinnatakse terviklikult koolitatud hindajate poolt. See lähenemine on ressursimahukas, kuid üha vajalikum, et mõõta tõelisi võimekuste paranemisi.

Autor

OpenAI