23. februar 2026

Zakaj SWE-bench Verified ne meri več prelomnih zmogljivosti programiranja

Merilo SWE-bench Verified je vse bolj kontaminirano. Priporočamo uporabo merila SWE-bench Pro.

Nalaganje …

Odkar smo avgusta 2024 prvič objavili merilo SWE-bench Verified, se v industriji široko uporablja za merjenje napredka modelov pri avtonomnih nalogah programskega inženiringa. Po izdaji je merilo SWE-bench Verified zagotavljalo močan kazalnik napredka zmogljivosti in postalo standardno merilo, o katerem se poroča pri izdajah prelomnih modelov. Spremljanje in napovedovanje napredka teh zmogljivosti je tudi pomemben del Okvira pripravljenosti družbe OpenAI. Ko smo na začetku ustvarili merilo Verified, smo poskušali odpraviti težave pri prvotnem ocenjevanju, zaradi katerih nekaterih nalog ni bilo mogoče izvesti v podatkovni zbirki SWE-bench⁠(odpre se v novem oknu).

Po začetni skokoviti rasti se je najnovejši napredek na SWE-bench Verified upočasnil, pri čemer je v zadnjih šestih mesecih narastel⁠(odpre se v novem oknu) s 74,9 % na 80,9 %. To odpira vprašanje: ali preostale napake odražajo omejitve modela ali lastnosti samega nabora podatkov?

V novi analizi smo odkrili dve veliki težavi z naborom Verified, ki kažeta, da merilo pri današnjih ravneh zmogljivosti ni več primerno za merjenje napredka pri zmožnostih avtonomnega programskega inženirstva za prelomne izdaje:

Testi zavračajo pravilne rešitve: Revidirali smo 27,6-% podmnožico nabora podatkov, ki je modeli pogosto niso uspeli rešiti, in ugotovili, da ima vsaj 59,4 % revidiranih problemov pomanjkljive testne primere, ki zavračajo funkcionalno pravilne oddaje, kljub našim najboljšim prizadevanjem, da bi to izboljšali pri začetnem oblikovanju merila SWE-bench Verified.
Usposabljanje na rešitvah: Ker se lahko veliki prelomni modeli učijo informacij iz svojega usposabljanja, je pomembno, da se nikoli ne usposabljajo na problemih in rešitvah, na katerih se ocenjujejo. To je podobno, kot če bi z učenci pred testom delili naloge in rešitve za prihajajoči test – morda si ne bodo zapomnili odgovora, vendar bodo učenci, ki so odgovore že videli, zagotovo uspešnejši od tistih, ki jih niso. Problemi merila SWE-bench izvirajo iz odprtokodnih repozitorijev, ki jih številni ponudniki modelov uporabljajo za namene usposabljanja. V naši analizi smo ugotovili, da so bili vsi prelomni modeli, ki smo jih testirali, sposobni reproducirati izvirni, človekov popravek programske napake, uporabljen kot referenca temeljne resnice, znan kot zlati popravek, ali dobesedne podrobnosti opisa problema za določene naloge, kar kaže, da so vsi med usposabljanjem videli vsaj nekatere probleme in rešitve.

Prav tako smo našli dokaze, da so modeli, ki so med usposabljanjem videli probleme, bolj verjetno uspešni, ker imajo dodatne informacije, potrebne za uspešno opravljanje premalo jasno opredeljenih preizkusov.

To pomeni, da izboljšave merila SWE-bench Verified ne odražajo več smiselnih izboljšav v resničnih zmožnostih modelov za razvoj programske opreme. Namesto tega vse bolj odražajo, v kolikšni meri je bil model med usposabljanjem izpostavljen primerjalnemu merilu. Zato smo prenehali poročati o rezultatih SWE-bench Verified in priporočamo, da to storijo tudi drugi razvijalci modelov.

Razvijamo nova, nekontaminirana ocenjevanja za boljše spremljanje zmožnosti programiranja, in menimo, da je to pomembno področje, na katerega bi se morala osredotočiti širša raziskovalna skupnost. Dokler jih ne razvijemo, OpenAI priporoča poročanje rezultatov po merilu SWE-bench Pro.

Ozadje

Prvotno ocenjevanje SWE-bench⁠(odpre se v novem oknu) je bilo izdano leta 2023. Vsak problem izvira iz rešene težave na GitHubu v enem od 12 odprtokodnih repozitorijev Python in je povezana z ustreznim pull requestom (PR). Da bi ugotovili, ali je sprememba kode, ki jo je ustvaril model, pravilna, ima vsaka naloga dva sklopa testov:

Testi, ki ne uspejo na nespremenjeni kodni zbirki, vendar uspejo, če je težava pravilno odpravljena
Regresijski testi, ki so uspešni tako pred popravkom kot po popravku, da se zagotovi, da nepovezana funkcionalnost ostane nedotaknjena.

Model ne vidi testov. Proizvesti mora spremembo kode zgolj na podlagi besedila prvotne težave in stanja repozitorija pred popravkom. Problem uspešno obravnava le, če po uveljavitvi spremembe kode prestane vse teste.

Pri tem ocenjevanju smo odkrili številne težave, ki bi lahko vodile do podcenjevanja zmogljivosti modelov.

Nekateri testi na ravni enote so bili preveč specifični ali neusklajeni z nalogo, zato bi lahko bili pravilni popravki zavrnjeni.
Številne trditve o nalogah so bile premalo natančno določene, kar bi lahko vodilo do več veljavnih interpretacij, medtem ko so testi pokrivali le eno specifično interpretacijo.
Odvisno od nastavitve okolja (na primer Linux v primerjavi z Windows ali različica Python) lahko nekateri testi navidezno odpovejo.

Leta 2024 smo ustvarili merilo SWE-bench Verified, da bi naslovili te težave. V sodelovanju s strokovnimi programskimi inženirji smo pregledali 1,699 problemov SWE-bench in izločili probleme, ki so imeli te težave. Vsak problem so neodvisno pregledali trije strokovnjaki. Rezultat tega postopka pregledovanja je bilo merilo SWE-bench Verified, skrbno izbran nabor 500 problemov.

Preozko in preširoko zastavljeni testi

Čeprav je SWE-bench Verified precej boljši od začetne različice, težave ostajajo še od prej. Izvedli smo revizijo 138 problemov SWE-bench Verified, ki jih OpenAI o3 v 64 neodvisnih zagonih ni dosledno rešil. Vsak primer je neodvisno pregledalo vsaj šest izkušenih programskih inženirjev. Če je strokovnjak odkril in izpostavil težavo, jo je dodatna ekipa znova preverila.

Ugotovili smo, da je 59,4 % od 138 problemov vsebovalo bistvene pomanjkljivosti v zasnovi testa in/ali opisu problema, zaradi česar so bili izjemno težki ali nemogoči za reševanje celo najzmogljivejšemu modelu ali človeku.

35,5 % revidiranih nalog ima stroge testne primere, ki uveljavljajo specifične podrobnosti implementacije, zaradi česar so številne funkcionalno pravilne oddaje neveljavne, kar imenujemo ozko zastavljeni testni primeri.
18,8 % revidiranih nalog ima teste, ki preverjajo dodatno funkcionalnost, ki ni bila navedena v opisu problema, kar imenujemo široko zastavljeni testni primeri.
Preostalih 5,1 % nalog je imelo raznovrstne težave, ki niso bile ustrezno razvrščene po tej taksonomiji.

Primer za ponazoritev prvega neuspešnega načina je pylint-dev__pylint-4551⁠(odpre se v novem oknu), kjer pull request (PR) kot del celotne rešitve uvede novo funkcijo `get_annotation`. To ime funkcije ni omenjeno v opisu problema, vendar ga testi uvozijo neposredno. Čeprav bi nekateri modeli lahko intuitivno ustvarili takšno funkcijo, ni nujno potrebno implementirati funkcije s tem specifičnim imenom, da bi pravilno naslovili problem. Številne veljavne rešitve ne prestanejo testov zaradi napak pri uvozu.

Opis problema

Navadno besedilo

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

Testni izrezek pull requesta

Python

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

Neuspešni testi PR-jev (skrajšano zaradi berljivosti)

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)

Primer preširokih testnih primerov je sympy__sympy-18199⁠(odpre se v novem oknu). Ta naloga je izvirala iz PR-ja, ki je obravnaval tri ločene težave s funkcijo `nthroot_mod`, in sicer #17373⁠(odpre se v novem oknu), #17377⁠(odpre se v novem oknu) in #18212⁠(odpre se v novem oknu). Opis naloge SWE-bench Verified pa zajema le končno težavo #18212⁠(odpre se v novem oknu). To ustvari neskladje: testi PR pokrivajo vse tri težave, medtem ko opis podrobno obravnava le eno. V naših izvedbah modeli pogosto pravilno implementirajo opisani popravek, nato pa ne prestanejo testov, ki pokrivajo implementacijo za drugi dve težavi.

Opis izvirnega pull requesta (iz PR za GitHub)

Navadno besedilo

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

Opis problema za #18212

Navadno besedilo

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.

Opis problema za nalogo SWE-bench Verified (povzeto samo iz #18212):

Navadno besedilo

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.

Kontaminacija

SWE-bench Verified in repozitoriji (kodne zbirke in opombe ob izdaji) so odprtokodni ter široko uporabljeni in obravnavani, kar razvijalcem modelov otežuje izogibanje kontaminaciji.

Znake kontaminacije smo najprej zaznali v naših modelih. Na primer ko je model GPT‑5.2 rešil 31 nalog, za katere smo predhodno menili, da jih je skoraj nemogoče rešiti. V django__django-14725⁠(odpre se v novem oknu) testi zahtevajo določen nov parameter `edit_only`, ki ga opis problema ne zahteva izrecno. Med reševanjem problema model GPT‑5.2 v svoji verigi sklepanja pokaže, da ima informacije o opombah ob izdaji, ki podrobno opisujejo spremembe v kodni zbirki, in pravilno prepozna, da je bil parameter `edit_only` uveden v Django 4.1.

GPT‑5.2 CoT

Navadno besedilo

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.

Za širšo ocenitev obsega kontaminacije smo ustvarili avtomatizirano ureditev za preizkus odpornosti. Za vsako vprašanje SWE-bench Verified smo model GPT‑5 zadolžili, da preizkusi GPT‑5.2‑Chat, Claude Opus 4.5 in Gemini 3 Flash Preview in tako odkrije morebitne znake kontaminacije. Ti modeli so bili izbrani tako, da izključujejo modele sklepanja, vendar priznavamo, da med njimi verjetno obstaja nezanemarljiva vrzel v zmogljivostih.

Za preverjanje kontaminacije je GPT‑5 prejel: ID, opis, zlati popravek in teste PR za nalogo po merilu SWE-bench Verified. V več kot 15 izmenjavah smo modelu GPT‑5 dovolili, da je spreminjal sistemski/razvijalski poziv, uporabniški poziv in predizpolnitev pomočnika ter različne strategije sprožanja. Po vsakem koraku je sodniški model označil, koliko nove, nalogi specifične informacije se je pojavilo, in vsak odgovor je bil označen glede na resnost kontaminacije z oznako od »brez« do »močna«. GPT‑5 je smel prilagoditi svojo strategijo na podlagi prejšnjih izmenjav, da bi iterativno pridobil podrobnosti, specifične za nalogo. Za vsak primer močne kontaminacije smo z drugim sodnikom preverili, da GPT‑5 ni razkril preveč informacij ciljnemu modelu. Nazadnje smo nato ročno pregledali »močne« primere, ki so vključeni v prepisih v tej objavi.

Spodaj so primeri močne kontaminacije med različnimi ponudniki modelov.

GPT‑5.2

Model GPT‑5.2 na podlagi kratkega izseka iz opisa naloge prikaže povsem točni zlati popravek. Zlasti pozna natančno ime razreda in metode ter nov pogoj za zgodnjo vrnitev `if username is None or password is None`, ki je uveden.

ID naloge: django__django-11451⁠(odpre se v novem oknu)

Sprožitev kontaminacije

Izjava o problemu

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

Poziv uporabnika

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"

Odziv modela

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.

Zlati popravek

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 ne zmore le priklicati natančne 4-vrstične funkcionalne spremembe, ki jo je uvedel pull request (PR), skupaj z dejanskim imenom datoteke in metodo, ki se je je dotaknil, temveč tudi dobesedno citira vdelani komentar, ki je bil del ugotovljenih razlik.

ID naloge: astropy__astropy-13236⁠(odpre se v novem oknu)

Sprožitev kontaminacije

Poziv uporabnika

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.

Predizpolnitev

1Let me be precise about the location and wording.

Odziv pomočnika

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

Zlati popravek

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, ko ne dobi nobenih dodatnih informacij o nalogi razen ID-ja, lahko dobesedno izpiše podrobnosti iz opisa naloge in zlatega popravka. To vključuje novo formulo regularnega izraza za preverjanje veljavnosti uporabniškega imena in natančne številke vrstic za spremembo.

ID naloge: django__django-11099⁠(odpre se v novem oknu)

Sprožitev kontaminacije

Izjava o problemu

1UsernameValidator allows trailing newline in usernames

Poziv uporabnika

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.

Predizpolnitev

1Let me be precise about the wording.

Odziv modela

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

Zlati popravek

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

Razprava

Iz te revizije merila SWE-bench Verified smo se naučili dveh širših lekcij na področju oblikovanja ocenjevanj. Kot prvo, primerjalna merila, pridobljena iz javno dostopnih gradiv, prinašajo tveganje kontaminacije, pri čemer lahko izpostavljenost podatkom za usposabljanje neopazno lažno izboljša rezultate. Če se pri izdelavi primerjalnega merila uporabljajo javno preiskovani podatki, bi morali razvijalci modelov izvesti dodatne teste za ugotavljanje kontaminacije. Javno objavljena primerjalna merila in celo njihove rešitve lahko končajo v podatkih za usposabljanje. Posebno pozornost velja nameniti načinu objave naborov podatkov (tj. zaščiteno z geslom) in filtriranju podatkov za usposabljanje (tj. dosledno upoštevanje »kanarčkovih« nizov).

Drugič, avtomatizirano ocenjevanje je težko pravilno izvesti; popolni testni primeri bi morali preveriti pravilnost delovanja v celoti, pri čemer morajo biti tako neodvisni od specifičnih nepomembnih podrobnosti implementacije kot tudi odporni pred hitrimi rešitvami prek bližnjic. Ti problemi so po svoji naravi zapleteni in jih je težko rešiti. Za odkrivanje teh problemov je bilo potrebnih več obsežnih kampanj označevanja, ki so ga izvedli ljudje.

Te ugotovitve smo vključili v naša nedavna prizadevanja na področju ocenjevanja. V zadnjih mesecih smo se odločili za poročanje o rezultatih iz javne razvejitve SWE-Bench Pro. Drugim razvijalcem modelov priporočamo, da storijo enako. SWE-bench Pro ni popoln, vendar se empirično zdi, da ima manj težav s kontaminacijo. Naš cevovod za odkrivanje kontaminacije je našel nekaj primerov kontaminacije, vendar so bili ti primeri bistveno redkejši in manj problematični kot pri merilu SWE-bench Verified, in noben model ni bil sposoben ustvariti popolnega dobesednega zlatega popravka.

Še naprej bomo vlagali v izvirne, zasebno pripravljene primerjalne teste in k temu bomo pozvali tudi industrijo in akademske kroge. V GDPVal⁠ naloge zasebno pripravljajo področni strokovnjaki, kar zmanjšuje tveganje izpostavljenosti, rešitve pa celovito ocenjujejo usposobljeni ocenjevalci. Ta pristop je zahteven glede virov, vendar je vse bolj nujen za merjenje resničnih izboljšav zmogljivosti.

2026

Avtor

OpenAI

Berite naprej

Prikaži vse

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Raziskave4. jun. 2026

Introducing new capabilities to GPT-Rosalind

Izdelek3. jun. 2026

Krepitev družbene odpornosti z Rosalind Biodefense

Izdelek29. maj 2026