Pebrero 23, 2026

Bakit hindi na sinusukat ng SWE-bench Verified ang mga frontier sa kakayahan sa pag-code

Ang SWE-bench Verified ay lalong nagiging kontaminado. Inirerekomenda namin ang SWE-bench Pro.

Naglo-load…

Mula nang una naming inilathala ang SWE-bench Verified noong Agosto 2024, malawak na itong ginagamit ng industriya upang sukatin ang pag-usad ng mga modelo sa mga awtonomong gawain sa software engineering. Pagkatapos nitong ilabas, nagbigay ang SWE-bench Verified ng matatag na senyales ng pag-usad sa kakayahan at naging pamantayang sukatan na iniuulat sa mga paglabas ng mga frontier na modelo. Ang pagsubaybay at pagtataya ng pag-unlad ng mga kakayahang ito ay isa ring mahalagang bahagi ng Preparedness Framework ng OpenAI. Noong una naming ginawa ang Verified benchmark, sinubukan naming lutasin ang mga isyu sa orihinal na pagsusuri kaya naging imposebleng matapos ang ilang gawain sa SWE-bench dataset⁠(magbubukas sa bagong window).

Pagkatapos ng mga unang pagsubok, bumagal ang state-of-the-art na pag-usad ng SWE-bench Verified, bumuti⁠(magbubukas sa bagong window) mula 74.9% hanggang 80.9% sa nakalipas na anim na buwan. Itinataas nito ang tanong: Ang mga natitirang pagkabigo ba ay sumasalamin sa mga limitasyon ng modelo o sa mga katangian ng dataset mismo?

Sa isang bagong pagsusuri, nakakita kami ng dalawang pangunahing isyu sa Verified set na nagpapahiwatig na hindi na angkop ang benchmark para sukatin ang pag-usad sa mga kakayahan sa awtonomong software engineering para sa paglulunsad ng mga frontier sa mga antas ng pagganap ngayon:

Tinatanggihan ng mga test ang mga tamang solusyon: In-audit namin ang 27.6% na subset ng dataset na madalas hindi masolusyunan ng mga modelo at natuklasan namin na hindi bababa sa 59.4% ng mga na-audit na problema ay may mga depektibong test case na tumatanggi sa mga submission na gumagana nang tama, sa kabila ng aming pinakamahusay na pagsisikap na pagbutihin ito sa paunang paglikha ng SWE-bench Verified.
Pagsasanay sa mga solusyon: Dahil ang malalaking frontier na mga modelo ay maaaring makaalam ng impormasyon mula sa kanilang pagsasanay, mahalaga na hindi sila kailanman sinasanay sa mga problema at solusyon kung saan sila sinusuri. Ito ay katulad ng pagbabahagi ng mga problema at solusyon para sa paparating na pagsusulit sa mga estudyante bago ang pagsusulit - maaaring hindi nila kabisaduhin ang sagot pero ang mga estudyanteng nakakita na ng mga sagot dati ay tiyak na mas gagaling kaysa sa mga wala. Ang mga problema sa SWE-bench ay kinukuha mula sa mga open-source repository na ginagamit ng maraming provider ng modelo para sa mga layunin ng pagsasanay. Sa aming pagsusuri, nalaman namin na ang lahat ng frontier na modelo na sinubukan namin ay nagawang muling buuin ang orihinal, isinulat ng tao na bug fix na ginamit bilang pinakawastong reperensya, na kilala bilang gold patch, o ang mga letra por letrang detalye ng pahayag ng problema para sa ilang gawain, na nagpapahiwatig na nakita na ng lahat ng ito ang hindi bababa sa ilan sa mga problema at solusyon habang nagsasanay.

Nakakalap din kami ng ebidensya na ang mga modelong nakakita ng mga problema habang nagsasanay ay ang mga mas magtatgumpay, dahil mayroon silang karagdagang impormasyong kailangan upang makapasa sa mga underspecified na test.

Ibig sabihin nito, ang mga pagpapabuti sa SWE-bench Verified ay hindi na sumasalamin sa makabuluhang pagpapabuti sa mga kakayahan ng mga modelo sa tunay na mundo sa pagbuo ng software. Sa halip, lalo nilang sinasalamin kung gaano kalaki ang pagkakalantad ng modelo sa benchmark noong panahon ng pagsasanay. Ito ang dahilan kung bakit tumigil na kami sa pag-uulat ng mga score ng SWE-bench Verified, at inirerekomenda naming gawin din ito ng iba pang mga developer ng modelo.

Bumubuo kami ng mga bagong, hindi kontaminadong pagsusuri para mas mahusay na masubaybayan ang mga kakayahan sa pagko-code, at sa tingin namin ay mahalagang pagtuunan ito ng mas malawak na komunidad ng pananaliksik. Hanggang sa makuha namin ang mga iyon, inirerekomenda ng OpenAI ang pag-uulat ng mga resulta para sa SWE-bench Pro.

Background

Ang orihinal na SWE-bench⁠(magbubukas sa bagong window) na pagsusuri ay inilabas noong 2023. Ang bawat problema ay nagmula sa isang nalutas na GitHub issue sa isa sa 12 open-source Python repository at ipinares sa kaukulang pull request (PR). Upang matukoy kung tama ang isang pagbabago sa code na binuo ng modelo, ang bawat problema ay may kasamang dalawang set ng mga test:

Mga test na pumpapalya sa hindi binagong codebase ngunit pumapasa kapag tama ang pagkakaayos sa isyu
Mga regression test na pumapasa bago at pagkatapos ng pag-aayos upang matiyak na nananatiling buo ang hindi kaugnay na functionality.

Hindi nakikita ng modelo ang mga pagsusuri. Kailangan nitong makabuo ng pagbabago sa code gamit lamang ang orihinal na teksto ng isyu at ang estado ng repository bago ang pag-aayos. Pumapasa lang ito sa problema kung pumapasa ang lahat ng pagsubok pagkatapos mailapat ang pagbabago sa code.

Nakakita kami ng maraming isyu sa pagsusuring iyon na maaaring humantong sa hindi sapat na pag-uulat ng kakayahan ng mga modelo.

Ang ilang pagsubok sa yunit ay masyadong tiyak o hindi nakaayon sa gawain kaya maaaring tanggihan ang mga tamang pag-aayos.
Maraming pahayag ng gawain ang hindi gaanong tinukoy, na maaaring humantong sa maraming wastong interpretasyon - habang isang partikular na interpretasyon lang ang sinaklaw ng mga test.
Depende sa setup ng environment (halimbawa Linux vs Windows, o ang python na bersyon), maaaring pumalya nang hindi sinasadya ang ilang test

Ginawa namin ang SWE-bench Verified noong 2024 para tugunan ang mga isyung ito. Nakipagtulungan kami sa mga ekspertong software engineer para suriin ang 1,699 na SWE-bench na problema at salain ang mga problemang may ganitong mga isyu. Ang bawat problema ay magkakahiwalay na sinuri ng tatlong eksperto. Ang prosesong ito ng pagrepaso ay nagresulta sa SWE-bench Verified, isang piniling hanay mula sa 500 problema.

Mga test na masyadong makitid at masyadong malapad

Bagama’t malaking pagbuti ang SWE-bench Verified kumpara sa unang bersyon, may natitira pang mga isyu. Nagsagawa kami ng audit sa 138 SWE-bench Verified na problema na hindi palaging nalulutas ng OpenAI o3 sa loob ng 64 na magkakahiwalay na pag-run. Ang bawat kaso ay independiyenteng sinuri nang hindi bababa sa anim na bihasang software engineer. Kung may na-flag na isyu ang isang eksperto, muli itong binerepika ng karagdagang team.

Natuklasan namin na 59.4% ng 138 problema ay naglalaman ng mahahalagang isyu sa in test na disenyo at/o paglalarawan ng problema, na nagiging dahilan upang maging napakahirap o imposibleng lutasin ang mga ito kahit para sa pinaka-may kakayahang modelo o tao.

35.5% sa mga na-audit na gawain ay may mahihigpit na test case na nagpapatupad ng mga partikular na detalye ng implementasyon, na nagpapawalang-bisa sa maraming pagsusumiteng tama naman ang paggana, na tinatawag naming mga kaso sa makitid na test.
18.8% sa mga na-audit na gawain ay may mga test na nagsusuri ng karagdagang pungsyonalidad na hindi tinukoy sa paglalarawan ng problema, na tinatawag naming mga kaso sa malapad na test.
Ang natitirang 5.1% ng mga gawain ay may sari-saring isyu na hindi maayos na naipangkat sa taksonomiyang ito.

Isang ilustratibong halimbawa ng unang mode ng pagpalya ay ang pylint-dev__pylint-4551⁠(magbubukas sa bagong window), kung saan ipinapakilala ng PR ang isang bagong kakayahan na `get_annotation` bilang bahagi ng pangkalahatang solusyon. Ang pangalan ng function na ito ay hindi nabanggit sa paglalarawan ng problema, pero direktang ini-import ng mga test. Bagama’t maaaring mahinuha ng ilang mga modelo na gumawa ng ganitong kakayahan, hindi mahigpit ang pangangailangan sa pagpapatupad ng kakayahan na may ganitong partikular na pangalan upang maayos na matugunan ang problema. Maraming wastong solusyon ang pumapalya sa mga test dahil sa mga error sa pag-import.

Paglalarawan ng problema

Plain Text

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

Snippet ng PR test

Python

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

Mga pagkabigo sa pagsubok sa PR (pinutol para sa mas madaling pagbabasa)

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)

Isang halimbawa ng masyadong malalawak na kaso ng test ay ang sympy__sympy-18199⁠(magbubukas sa bagong window). Ang gawaing ito ay nagmula sa isang PR na tumugon sa tatlong magkakahiwalay na isyu sa kakayahan na `nthroot_mod`, partikular #17373⁠(magbubukas sa bagong window), #17377⁠(magbubukas sa bagong window), at #18212⁠(magbubukas sa bagong window). Gayunpaman, ang paglalarawan para sa SWE-bench Verified na task ay sumasaklaw lamang sa huling isyu #18212⁠(magbubukas sa bagong window). Lumilikha ito ng hindi pagtutugma: sinasaklaw ng mga pagsusulit sa PR ang lahat ng tatlong isyu, habang ang paglalarawan ay nagdedetalye lang ng isa. Sa aming mga pag-run, madalas na tama na naipapatupad ng mga modelo ang inilarawang pag-aayos at pagkatapos ay pumapalya sa mga pagsubok na sumasaklaw sa pagpapatupad para natitirang dalawang isyu.

Orihinal na paglalarawan ng PR (mula sa GitHub PR)

Plain Text

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

Paglalarawan ng Problema para sa #18212

Plain Text

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.

Paglalarawan ng Problema para sa SWE-bench Verified na gawain (kinuha lamang mula sa #18212):

Plain Text

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.

Kontaminasyon

Ang SWE-bench Verified at ang mga repository (mga code base at release note) ay parehong open-source at malawakang ginagamit at tinatalakay, na nagpapahirap sa pag-iwas sa kontaminasyon para sa mga developer ng modelo.

Una naming nasagupa ang mga senyales ng kontaminasyon sa sarili naming mga modelo. Halimbawa, nang nalutas ng GPT‑5.2 ang 31 gawain na natukoy naming halos imposibleng malutas. Sa django__django-14725⁠(magbubukas sa bagong window) nangangailangan ang mga test ng partikular na bagong parameter na `edit_only` na hindi hayagang kinailangan ng pahayag ng problema. Habang nilulutas ang problema, ipinapakita ng GPT‑5.2 sa chain-of-thought nito na mayroon itong impormasyon tungkol sa mga release note na nagdedetalye ng mga pagbabago sa codebase, at tama nitong natutukoy na ang `edit_only` na parameter ay ipinakilala sa Django 4.1.

GPT‑5.2 CoT

Plain Text

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.

Para masuri kung gaano kalawak ang epekto ng kontaminasyon, gumawa kami ng naka-automate na setup para sa red-teaming. Para sa bawat tanong sa SWE-bench Verified, inatasan namin ang GPT‑5 na magsagawa ng pagsusuri sa GPT‑5.2‑Chat, Claude Opus 4.5 at Gemini 3 Flash Preview para sa kontaminasyon. Pinili ang mga modelong ito upang ibukod ang mga nangangatuwirang modelo, ngunit kinikilala namin na malamang na may hindi maliit na agwat sa kakayahan sa pagitan nila.

Upang magsiyasat para sa kontaminasyon, natanggap ng GPT‑5 ang: ID, paglalarawan, gold patch, at mga PR test ng SWE-bench Verified task. Sa mahigit 15 pag-ikot, pinayagan naming baguhin ng GPT‑5 ang prompt ng system/developer, prompt ng user, at assistant prefill at iba’t ibang estratehiya ng pag-elicit. Pagkatapos ng bawat pag-ikot, nilagyan ng label ng isang judge na modelo kung gaano karaming bagong impormasyong partikular sa gawain ang lumitaw at ang bawat tugon ay nilagyan ng label para sa tindi ng kontaminasyon mula “wala” hanggang “matindi.” Pinayagan ang GPT‑5 na iakma ang diskarte nito batay sa mga naunang pag-ikot upang paulit-ulit na mabawi ang mga detalyeng partikular sa gawain. Para sa bawat halimbawa ng matinding kontaminasyon, binerepika namin kasama ng isa pang hukom na hindi nag-leak ang GPT‑5 ng masyadong maraming impormasyon sa target na modelo. Sa wakas, mano-mano naming sinuri ang mga “matinding” halimbawa na bumubuo sa mga transcript sa post na ito.

Narito ang mga halimbawa ng matinding kontaminasyon sa iba't ibang provider ng modelo.

GPT‑5.2

Kapag binigyan ng maikling snippet mula sa paglalarawan ng gawain, inilalabas ng GPT‑5.2 ang eksaktong gold patch. Sa partikular, alam nito ang eksaktong pangalan ng uri at paraan, at ang bagong early return condition `if username is None or password is None` na ipinakilala.

ID ng gawain: django__django-11451⁠(magbubukas sa bagong window)

Pagkuha ng kontaminasyon

Pahayag ng problema

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

Prompt ng user

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"

Tugon ng modelo

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.

Gold patch

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

Hindi lang naaalala ng Opus ang eksaktong 4 na linyang pungsyonal na pagbabago na ipinakilala ng PR, kasama ang partikular na filename at paraan na nadaanan nito, kundi binabanggit din nito letra por letra ang inline na komento na bahagi ng diff.

ID ng gawain: astropy__astropy-13236⁠(magbubukas sa bagong window)

Pagkuha ng kontaminasyon

Prompt ng User

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.

Prefill

1Let me be precise about the location and wording.

Sagot ng Assistant

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

Gold patch

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

Kapag walang binigay na karagdagang impormasyon tungkol sa gawain bukod sa ID, nagagawang maglabas ng Gemini 3 Flash ng letra por letrang detalye mula sa paglalarawan ng gawain at sa gold patch. Kabilang dito ang bagong regex na pormula para sa pagpapatunay ng username at ang eksaktong mga numero ng linya para sa pagbabago.

ID ng gawain: django__django-11099⁠(magbubukas sa bagong window)

Pagkuha ng kontaminasyon

Pahayag ng problema

1UsernameValidator allows trailing newline in usernames

Prompt ng user

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.

Prefill

1Let me be precise about the wording.

Tugon ng modelo

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

Gold patch

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

Talakayan

Mula sa audit na ito ng SWE-bench Verified, nakikita natin ang dalawang mas malawak na aral para sa disenyo ng pagsusuri. Una, ang mga benchmark na nagmula sa mga materyal na available sa publiko ay may panganib ng kontaminasyon, kung saan ang pagkakalantad sa data ng pagsasanay ay maaaring tahimik na magpalobo ng mga score. Kung gagamitin ang data na na-crawl sa publiko sa pagbuo ng benchmark, dapat magsagawa ang mga developer ng modelo ng mga karagdagang pagsusuri para sa kontaminasyon. Ang mga benchmark, at maging ang mga solusyon nito, na nai-post sa publiko ay maaaring mapunta sa data ng pagsasanay. Dapat mag-ingat nang husto kapwa sa kung paano ipinopost ang mga dataset (ibig sabihin, (protektado ng password) at pag-filter sa data ng pagsasanay (ibig sabihin. mahigpit na pagsunod sa canary strings).

Pangalawa, mahirap gawing tama ang awtomatikong pagmamarka; dapat ganap na beripikahin ng mga perpektong test case ang tamang pagganap, na parehong hindi nakadepende sa mga tiyak na hindi mahalagang detalye ng implementasyon at matatag din laban sa mga shortcut na solusyon. Ang mga problemang ito ay likas na kumplikado at mahirap lutasin. Ang pagtukoy sa mga problemang ito ay nangangailangan ng maraming malalawak na kampanya ng pagla-label ng tao.

Isinama namin ang mga natuklasang ito sa aming mga kamakailang pagsisikap sa pagsusuri. Sa mga nakalipas na buwan, pinili naming iulat ang mga resulta mula sa pampublikong split ng SWE-Bench Pro. Inirerekomenda naming gawin din ito ng iba pang mga developer ng modelo. Hindi perpekto ang SWE-bench Pro, pero batay sa empirikal na ebidensya, tila mas kaunti ang problema nito sa kontaminasyon. Nakakita ang aming pipeline ng kontaminasyon ng ilang kaso ng kontaminasyon, ngunit ang mga kasong ito ay mas bihira at hindi gaanong malubha kung ihahambing sa SWE-bench Verified, at walang modelo ang nakapaglabas ng kumpleto at letra por letrang gold patch.

Patuloy kaming mamumuhunan sa mga orihinal, pribadong inakdang benchmark at hihingi ng tulong mula sa industriya at akademya upang gawin din ang ganito. Sa GDPVal⁠, ang mga gawain ay pribadong isinulat ng mga dalubhasa sa larangan, na nagpapababa ng panganib ng pagkakalantad, at ang mga solusyon ay sinusuri nang holistiko ng mga sinanay na tagasuri. Ang pamamaraang ito ay nangangailangan ng maraming mapagkukunan, ngunit lalong kinakailangan upang sukatin ang mga tunay na pagpapahusay sa mga kakayahan.

2026

May-akda

OpenAI

Magpatuloy sa pagbabasa

Tingnan lahat

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

PananaliksikHun 4, 2026

Ipinapakilala ang mga bagong kakayahan sa GPT-Rosalind

ProduktoHun 3, 2026

Pagpapalakas ng panlipunang katatagan gamit ang Rosalind Biodefense

ProduktoMay 29, 2026