Preskočiť na hlavný obsah
OpenAI

23. februára 2026

VyhľadávaniePublikácia

Prečo SWE-bench Verified už viac nemeria prelomové schopnosti kódovania

SWE-bench Verified je čoraz viac kontaminovaný. Odporúčame SWE-bench Pro.

Načítava sa…

Odkedy sme v auguste 2024 prvýkrát zverejnili SWE-bench Verified, odvetvie ho široko používa na meranie pokroku modelov v autonómnych úlohách softvérového inžinierstva. Po svojom vydaní poskytol SWE-bench Verified silný signál pokroku v schopnostiach a stal sa štandardnou metrikou uvádzanou pri vydaniach prelomových modelov. Sledovanie a predpovedanie pokroku týchto schopností je tiež dôležitou súčasťou Rámca pripravenosti OpenAI. Keď sme pôvodne vytvorili benchmark Verified, pokúsili sme sa vyriešiť problémy v pôvodnom hodnotení, ktoré znemožňovali splniť určité úlohy v SWE-bench dataset(otvorí sa v novom okne).

Po počiatočných skokoch sa najmodernejší pokrok v SWE-bench Verified spomalil, pričom sa za posledných 6 mesiacov zlepšil(otvorí sa v novom okne) zo 74,9 % na 80,9 %. To vyvoláva otázku: odrážajú zostávajúce zlyhania obmedzenia modelu alebo vlastnosti samotného súboru údajov?

V novej analýze sme zistili dva hlavné problémy so súborom Verified, ktoré naznačujú, že benchmark už nie je vhodný na meranie pokroku v schopnostiach autonómneho softvérového inžinierstva pre prelomové uvedenia pri dnešných úrovniach výkonu:

  1. Testy odmietajú správne riešenia: Auditovali sme 27,6 % podmnožinu datasetu, ktorú modely často nedokázali vyriešiť, a zistili sme, že aspoň 59,4 % auditovaných úloh má chybné testovacie prípady, ktoré odmietajú funkčne správne odovzdané riešenia, napriek nášmu maximálnemu úsiliu o zlepšenie tohto aspektu pri počiatočnom vytváraní SWE-bench Verified.
  2. Trénovanie na riešeniach: Keďže veľké prelomové modely sa môžu učiť informácie počas tréningu, je dôležité, aby sa nikdy netrénovali na problémoch a riešeniach, ktoré sa používajú na ich hodnotenie. Je to podobné, ako keby ste so študentmi zdieľali problémy a riešenia na nadchádzajúci test ešte pred testom. Nemusia si zapamätať odpoveď, ale študenti, ktorí už odpovede videli, si určite povedú lepšie než tí, ktorí ich nevideli. Problémy SWE-bench pochádzajú z open-source repozitárov, ktoré mnohí poskytovatelia modelov využívajú na tréningové účely. V našej analýze sme zistili, že všetky prelomové modely, ktoré sme testovali, dokázali reprodukovať pôvodnú, človekom napísanú opravu chyby použitú ako referenciu (ground-truth), známu ako zlatá oprava, alebo doslovné špecifiká zadania problému pre určité úlohy. To naznačuje, že všetky z nich počas tréningu videli aspoň niektoré z problémov a riešení.

Zistili sme tiež dôkazy, že modely, ktoré počas tréningu stretli s týmito problémami, majú väčšiu pravdepodobnosť úspechu, pretože majú dodatočné informácie potrebné na to, aby prešli nedostatočne špecifikovanými testami.

To znamená, že zlepšenia na SWE-bench Verified už neodrážajú zmysluplné zlepšenia v reálnych schopnostiach modelov pri vývoji softvéru. Namiesto toho čoraz viac odrážajú to, do akej miery bol model počas tréningu vystavený referenčným hodnotám. Preto sme prestali uvádzať skóre SWE-bench Verified a odporúčame, aby to urobili aj ostatní vývojári modelov.

Vytvárame nové, nekontaminované hodnotenia, aby sme lepšie sledovali schopnosti v oblasti programovania, a myslíme si, že je to dôležitá oblasť, na ktorú by sa mala zamerať širšia výskumná komunita. Kým ich nebudeme mať, OpenAI odporúča vykazovať výsledky pre SWE-bench Pro.

Pozadie

Pôvodné hodnotenie SWE-bench(otvorí sa v novom okne) bolo vydané v roku 2023. Každý problém pochádza z vyriešeného issue na GitHube v jednom z 12 repozitárov Pythonu s otvoreným zdrojovým kódom a je spárovaný so zodpovedajúcim pull request (PR). Na určenie, či je modelom generovaná zmena kódu správna, každý problém obsahuje dve sady testov:

  • Testy, ktoré zlyhávajú na neupravenej kódovej základni, ale prejdú, ak je problém správne opravený
  • Regresné testy, ktoré prejdú úspešne pred opravou aj po nej, aby sa zabezpečilo, že nesúvisiaca funkcionalita zostane neporušená.

Model testy nevidí. Musí vytvoriť zmenu kódu len na základe pôvodného textu problému a stavu repozitára pred opravou. Prejde problémom iba vtedy, ak po použití zmeny kódu prejdú všetky testy.

Zistili sme mnoho problémov s týmto hodnotením, ktoré by mohli viesť k podhodnoteniu schopností modelov.

  • Niektoré jednotkové testy boli príliš špecifické alebo neboli v súlade s úlohou, takže správne opravy mohli byť odmietnuté.
  • Mnohé zadania úloh boli nepresne zadané, čo by mohlo viesť k viacerým platným interpretáciám - zatiaľ čo testy pokrývali iba jednu konkrétnu.
  • V závislosti od nastavenia prostredia (napríklad Linux oproti Windows alebo python verzii) môžu niektoré testy falošne zlyhať.

V roku 2024 sme vytvorili SWE-bench Verified, aby sme riešili tieto problémy. Spolupracovali sme s odbornými softvérovými inžiniermi na preskúmaní 1 699 problémov SWE-bench a odfiltrovaní problémov, ktoré mali tieto nedostatky. Každý problém posúdili traja experti nezávisle. Tento proces kontroly viedol k vzniku SWE-bench Verified, kurátorsky vybraného súboru 500 úloh.

Príliš úzke a príliš široké testy

Hoci je SWE-bench Verified veľkým zlepšením oproti pôvodnej verzii, pretrvávajú zvyškové problémy. Vykonali sme audit 138 problémov SWE-bench Verified, ktoré OpenAI o3 nedokázal konzistentne vyriešiť v 64 nezávislých spusteniach. Každý prípad bol nezávisle posúdený najmenej šiestimi skúsenými softvérovými inžiniermi. Ak expert označil problém, dodatočný tím ho opätovne overil.

Zistili sme, že 59,4 % zo 138 problémov obsahovalo závažné nedostatky v návrhu testu a/alebo v opise problému, čo ich robilo mimoriadne ťažkými alebo nemožnými vyriešiť aj pre ten najschopnejší model alebo človeka. 

  • 35,5 % auditovaných úloh má prísne testovacie prípady, ktoré vynucujú konkrétne implementačné detaily, čím zneplatňujú mnohé funkčne správne odovzdané riešenia, ktoré nazývame úzke testovacie prípady.
  • 18,8 % auditovaných úloh má testy, ktoré kontrolujú dodatočnú funkcionalitu, ktorá nebola špecifikovaná v popise problému, čo nazývame široké testovacie prípady.
  • Zvyšných 5,1 % úloh malo rôzne problémy, ktoré neboli dobre zoskupené v rámci tejto taxonómie.

Ilustratívnym príkladom prvého režimu zlyhania je pylint-dev__pylint-4551(otvorí sa v novom okne), kde PR zavádza novú funkciu `get_annotation` ako súčasť celkového riešenia. Tento názov funkcie nie je uvedený v popise problému, ale je importovaný priamo testami. Hoci niektoré modely môžu intuitívne vytvoriť takúto funkciu, nie je striktne nevyhnutné implementovať funkciu s týmto konkrétnym názvom, aby sa problém správne vyriešil. Mnohé platné riešenia zlyhajú v testoch kvôli chybám pri importe.

Opis problému

Obyčajný text

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

Testovací úryvok PR

Python

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

Zlyhania testov PR (skrátené pre lepšiu čitateľnosť)

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)

Príkladom príliš širokých testovacích prípadov je sympy__sympy-18199(otvorí sa v novom okne). Táto úloha pochádza z PR, ktoré riešilo tri samostatné problémy s funkciou `nthroot_mod`, konkrétne #17373(otvorí sa v novom okne), #17377(otvorí sa v novom okne) a #18212(otvorí sa v novom okne). Popis úlohy SWE-bench Verified však pokrýva iba posledný problém #18212(otvorí sa v novom okne). Týmto vzniká nesúlad: testy v PR pokrývajú všetky tri problémy, zatiaľ čo opis podrobne uvádza iba jeden. V našich spusteniach modely často správne implementujú opísanú opravu a potom zlyhajú v testoch, ktoré pokrývajú implementáciu ďalších dvoch problémov.

Pôvodný popis PR (z PR na GitHube)

Obyčajný text

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

Opis problému pre #18212

Obyčajný text

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.

Opis problému pre úlohu SWE-bench Verified (prevzaté iba z #18212):

Obyčajný text

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.

Kontaminácia

SWE-bench Verified a repozitáre (kódové základne a poznámky k vydaniu) sú open-source a široko používané a diskutované, čo vývojárom modelov sťažuje vyhýbanie sa kontaminácii.

Najprv sme zaznamenali príznaky kontaminácie v našich vlastných modeloch. Napríklad, keď GPT‑5.2 vyriešil 31 úloh, ktoré sme identifikovali ako takmer nemožné vyriešiť. V django__django-14725(otvorí sa v novom okne) testy vyžadujú špecifický nový parameter `edit_only`, ktorý nie je explicitne vyžadovaný v zadaní problému. Počas riešenia problému GPT‑5.2 vo svojom reťazení myšlienok uvádza, že má informácie o poznámkach k vydaniu, ktoré podrobne opisujú zmeny v kódovej základni, a správne identifikuje, že parameter `edit_only` bol zavedený v Django 4.1.

GPT‑5.2 CoT

Obyčajný text

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.

Aby sme posúdili, aký významný je problém kontaminácie v širšom meradle, vytvorili sme automatizované nastavenie na testovanie červeným tímom. Pre každú otázku SWE-bench Verified sme poverili GPT‑5, aby otestoval GPT‑5.2‑Chat. Claude Opus 4.5 a Gemini 3 Flash Preview na kontamináciu. Tieto modely boli vybrané tak, aby vylúčili uvažovacie modely, ale uznávame, že medzi nimi pravdepodobne existuje nezanedbateľná medzera v schopnostiach.

Na overenie kontaminácie GPT‑5 dostal: ID úlohy SWE-bench Verified, opis, zlatú opravu a PR testy. Počas viac ako 15 ťahov sme umožnili GPT‑5 meniť systémový/vývojársky príkaz, používateľský príkaz, predvyplnenie asistenta a rôzne stratégie elicitácie. Po každom ťahu model sudcu označil, koľko nových informácií špecifických pre danú úlohu sa objavilo, a každá odpoveď bola označená podľa závažnosti kontaminácie od „none“ po „strong“. GPT‑5 mohol prispôsobiť svoju stratégiu na základe predchádzajúcich ťahov, aby iteratívne získal späť detaily špecifické pre danú úlohu. Pri každom príklade silnej kontaminácie sme s ďalším posudzovateľom overili, že GPT‑5 neuniklo príliš veľa informácií do cieľového modelu. Nakoniec sme manuálne skontrolovali „strong“ príklady, ktoré tvoria prepisy v tomto príspevku.

Nižšie sú uvedené príklady silnej kontaminácie naprieč rôznymi poskytovateľmi modelov.

GPT‑5.2 

Na základe krátkeho úryvku z popisu úlohy GPT‑5.2 vygeneruje presnú zlatú opravu. Najmä pozná presný názov triedy a metódy a novú podmienku predčasného návratu `if username is None or password is None`, ktorá sa zavádza.

Zisťovanie kontaminácie

Zadanie problému

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

Príkaz používateľa

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"

Odpoveď modelu

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.

Zlatá oprava

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 si dokáže nielen vybaviť presnú 4-riadkovú funkčnú zmenu, ktorú PR zaviedol, spolu s konkrétnym názvom súboru a metódou, ktorej sa dotkol, ale aj doslovne cituje inline komentár, ktorý bol súčasťou diffu. 

Zisťovanie prítomnosti kontaminácie

Používateľský príkaz

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.

Predvyplniť

1
Let me be precise about the location and wording.

Odpoveď asistenta

1
**1) File path and function:**
2
`astropy/table/table.py` in the `_convert_data_to_col` method (which is inside the `Table` class).
3

4
**2) The inline comment immediately above the conditional:**
5

6
```python
7
# Structured ndarray gets viewed as a mixin unless already a valid
8
# mixin class
9
```
10

11
**3) The content beneath that comment that was changed:**
12

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

Zlatá oprava

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 

Gemini 3 Flash, keď nedostane žiadne ďalšie informácie o úlohe okrem ID, dokáže doslovne reprodukovať podrobnosti z opisu úlohy a zlatej opravy. Toto zahŕňa nový regex vzorec na overovanie používateľského mena a presné čísla riadkov pre túto zmenu.

Zisťovanie prítomnosti kontaminácie

Zadanie problému

1
UsernameValidator allows trailing newline in usernames

Príkaz používateľa

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.

Predvyplniť

1
Let me be precise about the wording.

Odpoveď modelu

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

Zlatá oprava

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

Diskusia

Z tohto auditu SWE-bench Verified vidíme dve širšie ponaučenia pre návrh hodnotenia. Po prvé, benchmarky pochádzajúce z verejne dostupných materiálov nesú riziko kontaminácie, pri ktorom môže vystavenie tréningovým údajom potichu nafúknuť skóre. Ak sa pri konštrukcii benchmarku používajú verejne prehľadávané údaje, vývojári modelov by mali vykonať dodatočné testy na kontamináciu. Referenčné hodnoty a dokonca aj ich riešenia zverejnené verejne sa môžu dostať do tréningových údajov. Mimoriadnu pozornosť treba venovať tomu, ako sa súbory údajov zverejňujú (t. j. chránené heslom) a filtrovanie tréningových údajov (t. j. prísne dodržiavanie kanárikových reťazcov). 

Po druhé, automatizované hodnotenie je zložité nastaviť správne. Dokonalé testovacie prípady by mali úplne overiť správnu funkcionalitu, byť zároveň nezávislé od konkrétnych nepodstatných detailov implementácie a tiež odolné voči skratkovým riešeniam. Tieto problémy sú vo svojej podstate zložité a ťažko riešiteľné. Zachytenie týchto problémov si vyžiadalo viacero rozsiahlych kampaní ľudského označovania. 

Tieto zistenia sme začlenili do nášho nedávneho úsilia o hodnotenie. Za posledné mesiace sme sa rozhodli uvádzať výsledky z verejného rozdelenia SWE-Bench Pro. Odporúčame, aby ostatní vývojári modelov urobili to isté. SWE-bench Pro nie je dokonalý, ale empiricky sa zdá, že trpí menej problémami s kontamináciou. Náš kontaminačný pipeline našiel niektoré prípady kontaminácie, ale tieto prípady boli výrazne zriedkavejšie a menej závažné než SWE-bench Verified a žiadny model nedokázal vytvoriť úplnú doslovnú zlatú opravu.

Budeme naďalej investovať do pôvodných, súkromne vytvorených benchmarkov a požiadame o pomoc priemysel a akademickú sféru, aby urobili to isté. V GDPVal sú úlohy súkromne vytvárané odborníkmi na doménu, čím sa znižuje riziko odhalenia, a riešenia sú hodnotené holisticky vyškolenými hodnotiteľmi. Tento prístup je náročný na zdroje, ale čoraz viac je potrebný na meranie skutočných zlepšení schopností.

Autor

OpenAI