23 shkurt 2026

Pse SWE-bench Verified nuk mat më aftësitë avangardë të programimit

SWE-bench Verified po kontaminohet gjithnjë e më shumë. Ne rekomandojmë SWE-bench Pro.

Duke ngarkuar…

Që kur e publikuam për herë të parë SWE-bench Verified në gusht 2024, industria e ka përdorur gjerësisht për të matur përparimin e modeleve në detyra autonome të inxhinierisë softuerike. Pas publikimit të tij, SWE-bench Verified ofroi një sinjal të fortë të përparimit të aftësive dhe u bë një metrikë standarde e raportuar në publikimet e modeleve avangardë. Ndjekja dhe parashikimi i progresit të këtyre aftësive është gjithashtu një pjesë e rëndësishme e Preparedness Framework të OpenAI. Kur e krijuam fillimisht standardin Verified, u përpoqëm të zgjidhnim problemet në vlerësimin origjinal që i bënin disa detyra të pamundura për t’u përmbushur në SWE-bench dataset⁠(hapet në një dritare të re).

Pas kërcimeve fillestare, përparimi i teknologjisë së fundit në SWE-bench Verified është ngadalësuar, duke u përmirësuar⁠(hapet në një dritare të re) nga 74,9% në 80,9% në 6 muajt e fundit. Kjo ngre pyetjen: a pasqyrojnë dështimet e mbetura kufizimet e modelit apo vetitë e vetë datasetit?

Në një analizë të re, gjetëm dy probleme madhore me setin Verified që tregojnë se standardi i referencës nuk është më i përshtatshëm për matjen e progresit në aftësitë e inxhinierisë softuerike autonome për qarkullime avangardë në nivelet e performancës së sotme:

Testet refuzojnë zgjidhje të sakta: Ne audituam një nënbashkësi prej 27,6% të dataset-it që modelet shpesh nuk arrinin ta zgjidhnin dhe zbuluam se të paktën 59,4% e problemeve të audituara kanë raste testimi me të meta që refuzojnë dorëzime funksionalisht të sakta, pavarësisht përpjekjeve tona më të mira për ta përmirësuar këtë gjatë krijimit fillestar të SWE-bench Verified.
Trajnimi mbi zgjidhjet: Meqenëse modelet e mëdha avangardë mund të mësojnë informacion nga trajnimi i tyre, është e rëndësishme që ato të mos trajnohen kurrë mbi problemet dhe zgjidhjet mbi të cilat vlerësohen. Kjo është e ngjashme me ndarjen e problemeve dhe zgjidhjeve për një test të ardhshëm me studentët para testit - ata mund të mos e mësojnë përmendësh përgjigjen, por studentët që i kanë parë përgjigjet më parë sigurisht do të bëjnë më mirë se ata që nuk i kanë parë. Problemet e SWE-bench merren nga depo open-source që shumë ofrues modelesh i përdorin për qëllime trajnimi. Në analizën tonë zbuluam se të gjitha modelet avangardë që testuam ishin në gjendje të riprodhonin rregullimin origjinal të gabimit, të shkruar nga njeriu, të përdorur si referencë e së vërtetës bazë, i njohur si korrigjimi i artë, ose specifikat fjalë për fjalë të deklaratës së problemit për detyra të caktuara, duke treguar se të gjitha ato kanë parë të paktën disa nga problemet dhe zgjidhjet gjatë trajnimit.

Gjetëm gjithashtu prova se modelet që i kanë parë problemet gjatë trajnimit kanë më shumë gjasa të kenë sukses, sepse kanë informacion shtesë të nevojshëm për të kaluar testet e papërcaktuara mirë.

Kjo do të thotë se përmirësimet në SWE-bench Verified nuk pasqyrojnë më përmirësime domethënëse në aftësitë e modeleve për zhvillimin e softuerit në botën reale. Në vend të kësaj, ato pasqyrojnë gjithnjë e më shumë se sa shumë ishte ekspozuar modeli ndaj benchmark-ut në kohën e trajnimit. Kjo është arsyeja pse kemi ndaluar raportimin e rezultateve të SWE-bench Verified dhe rekomandojmë që zhvilluesit e tjerë të model ta bëjnë gjithashtu.

Ne po ndërtojmë vlerësime të reja, të pakontaminuara për të gjurmuar më mirë aftësitë e kodimit, dhe mendojmë se kjo është një fushë e rëndësishme ku duhet të përqendrohemi për komunitetin më të gjerë kërkimor. Derisa t’i kemi ato, OpenAI rekomandon raportimin e rezultateve për SWE-bench Pro.

Sfondi

Vlerësimi origjinal SWE-bench⁠(hapet në një dritare të re) u publikua në 2023. Çdo problem merret nga një çështje e zgjidhur në GitHub në një nga 12 depot me burim të hapur Python dhe shoqërohet me pull request përkatës (PR). Për të përcaktuar nëse një ndryshim i kodit i gjeneruar nga modeli është i saktë, çdo problem vjen me dy grupe testesh:

Teste që dështojnë në bazën e kodit të pamodifikuar, por kalojnë nëse problemi rregullohet saktë
Teste të regresionit që kalojnë si para ashtu edhe pas rregullimit për të siguruar që funksionaliteti i palidhur të mbetet i paprekur.

Modeli nuk i sheh testet. Duhet të prodhojë një ndryshim kodi duke pasur vetëm tekstin origjinal të çështjes dhe gjendjen e depos përpara rregullimit. Ai e kalon një problem vetëm nëse të gjitha testet kalojnë pasi të aplikohet ndryshimi i kodit.

Gjetëm shumë probleme me atë vlerësim që mund të çojnë në nënraportimin e aftësive të modeleve.

Disa teste të njësisë ishin tepër specifike ose të mospërputhura me detyrën, ndaj rregullimet e sakta mund të refuzoheshin.
Shumë deklarata detyrash ishin të nënspecifikuara, gjë që mund të çonte në interpretime të shumta të vlefshme - ndërsa testet mbulonin vetëm një të caktuar.
Në varësi të konfigurimit të mjedisit (për shembull Linux vs Windows, ose versioni i python), disa teste mund të dështojnë gabimisht

Ne krijuam SWE-bench Verified në vitin 2024 për të adresuar këto çështje. Ne punuam me inxhinierë softuerikë ekspertë për të shqyrtuar 1699 probleme të SWE-bench dhe për të filtruar problemet që kishin këto çështje. Çdo problem u shqyrtua nga tre ekspertë të pavarur. Ky proces rishikimi rezultoi në SWE-bench Verified, një grup të përzgjedhur prej 500 problemesh.

Testet shumë të ngushta dhe shumë të gjera

Ndërsa SWE-bench Verified është një përmirësim i madh krahasuar me versionin fillestar, mbeten disa çështje të pazgjidhura. Ne kryem një auditim të 138 problemeve të SWE-bench Verified që OpenAI o3 nuk i zgjidhi në mënyrë të qëndrueshme gjatë 64 ekzekutimeve të pavarura. Çdo rast u rishikua në mënyrë të pavarur nga të paktën gjashtë inxhinierë me përvojë të softuerit. Nëse një ekspert sinjalizonte një problem, ai rishikohej nga një ekip shtesë.

Ne zbuluam se 59,4% e 138 problemeve përmbanin çështje thelbësore në dizajnin e testit dhe/ose përshkrimin e problemit, duke i bërë ato jashtëzakonisht të vështira ose të pamundura për t'u zgjidhur edhe për modelin ose njeriun më të aftë.

35,5% e detyrave të audituara kanë raste të rrepta testimi që imponojnë detaje specifike të implementimit, duke bërë të pavlefshme shumë dorëzime funksionalisht të sakta, të cilat i quajmë raste të ngushta testimi.
18,8% e detyrave të audituara kanë teste që kontrollojnë për funksionalitet shtesë që nuk ishte specifikuar në përshkrimin e problemit, të cilat i quajmë raste të gjera testimi.
5,1% i mbetur e detyrave kishte probleme të ndryshme që nuk ishin grupuar mirë me këtë taksonomi.

Një shembull ilustrues i mënyrës së parë të dështimit është pylint-dev__pylint-4551⁠(hapet në një dritare të re), ku PR prezanton një funksion të ri "get_annotation" si pjesë e zgjidhjes së përgjithshme. Ky emër funksioni nuk përmendet në përshkrimin e problemit, por importohet drejtpërdrejt nga testet. Ndërsa disa modele mund të intuitojnë të krijojnë një funksion të tillë, nuk është rreptësisht e nevojshme të zbatohet një funksion me këtë emër specifik për ta trajtuar saktë problemin. Shumë zgjidhje të vlefshme dështojnë në testet për shkak të gabimeve të importimit.

Përshkrimi i problemit

Tekst i thjeshtë

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

Fragment testimi PR

Python

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

Dështime të testeve të PR (të shkurtuara për lexueshmëri)

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)

Një shembull i rasteve të testimit tepër të gjera është sympy__sympy-18199⁠(hapet në një dritare të re). Kjo detyrë u mor nga një PR që trajtoi tre çështje të veçanta me funksionin "nthroot_mod", konkretisht #17373⁠(hapet në një dritare të re), #17377⁠(hapet në një dritare të re), dhe #18212⁠(hapet në një dritare të re). Megjithatë, përshkrimi për detyrën SWE-bench Verified mbulon vetëm çështjen përfundimtare #18212⁠(hapet në një dritare të re). Kjo krijon një mospërputhje: testet e PR mbulojnë të tre çështjet, ndërsa përshkrimi përfshin vetëm një. Në ekzekutimet tona, modelet shpesh zbatojnë saktë korrigjimin e përshkruar dhe më pas dështojnë në testet që mbulojnë zbatimin për dy çështjet e tjera.

Përshkrimi origjinal i PR (nga GitHub PR)

Tekst i thjeshtë

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

Përshkrimi i problemit për #18212

Tekst i thjeshtë

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.

Përshkrimi i problemit për detyrën SWE-bench Verified (marrë vetëm nga #18212):

Tekst i thjeshtë

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.

Kontaminim

SWE-bench Verified dhe depo (bazat e kodit dhe shënimet e publikimit) janë të dyja open-source dhe gjerësisht të përdorura dhe të diskutuara, gjë që e bën të vështirë shmangien e kontaminimit për zhvilluesit e model.

Ne fillimisht hasëm shenja të kontaminimit në modelet tona. Për shembull, kur GPT‑5.2 zgjidhi 31 detyra që i kishim identifikuar si pothuajse të pamundura për t’u zgjidhur. Në django__django-14725⁠(hapet në një dritare të re) testet kërkojnë një parametër të ri specifik "edit_only" i cili nuk kërkohet në mënyrë të qartë nga deklarata e problemit. Gjatë zgjidhjes së problemit, GPT‑5.2 tregon në zinxhir mendimi se ka informacion rreth shënimeve të publikimit që detajojnë ndryshimet në bazën e kodit, dhe identifikon saktë se parametri "edit_only" u prezantua në Django 4.1.

GPT‑5.2 CoT

Tekst i thjeshtë

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.

Për të vlerësuar sa i rëndësishëm është kontaminimi në një kuptim më të gjerë, krijuam një konfigurim të automatizuar për simulim sulmesh. Për çdo pyetje të SWE-bench Verified, i ngarkuam GPT‑5 detyrën për të testuar një GPT‑5.2‑Chat. Claude Opus 4.5 dhe Gemini 3 Flash Preview për të hetuar kontaminimin. Këto modele u zgjodhën për të përjashtuar modelet e arsyetimit, por ne pranojmë se ka të ngjarë të ekzistojë një hendek i rëndësishëm i aftësive midis tyre.

Për të hetuar kontaminimin, GPT‑5 mori: ID, përshkrimin, patch-in gold dhe testet PR të detyrës SWE-bench Verified. Gjatë mbi 15 radhëve, lejuam që GPT‑5 të ndryshonte kërkesën e sistemit/zhvilluesit, kërkesën e përdoruesit dhe paraplotësimin e asistentit dhe strategji të ndryshme nxitjeje. Pas çdo hapi, një model gjykatës etiketoi sa shumë informacion të ri specifik për detyrën u shfaq dhe çdo përgjigje u etiketua për ashpërsinë e kontaminimit nga "none" në "strong". GPT‑5 u lejua të përshtaste strategjinë e vet bazuar në kthesat e mëparshme për të rikuperuar në mënyrë iterative detaje specifike për detyrën. Për çdo shembull të kontaminimit të fortë, verifikuam me një gjyqtar tjetër që GPT‑5 të mos kishte rrjedhur shumë informacion te modeli i synuar. Së fundi, më pas shqyrtuam manualisht shembujt “strong” që përbëjnë transkriptet në këtë postim.

Më poshtë janë shembuj të kontaminimit të rëndë nëpër ofrues të ndryshëm modelesh.

GPT‑5.2

Duke pasur një fragment të shkurtër nga përshkrimi i detyrës, GPT‑5.2 nxjerr saktësisht përmirësimin e artë. Në veçanti, ai e di emrin e saktë të klasës dhe metodës, si dhe kushtin e ri të kthimit të hershëm "if username is None or password is None" që është prezantuar.

ID e detyrës: django__django-11451⁠(hapet në një dritare të re)

Nxjerrja e kontaminimit

Deklaratë problemi

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

Kërkesë e përdoruesit

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"

Përgjigja e modelit

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.

Përditësim i artë

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 është në gjendje jo vetëm të rikujtojë ndryshimin funksional të saktë me 4 rreshta që PR prezantoi, së bashku me emrin specifik të skedarit dhe metodën që preku, por gjithashtu citon fjalë për fjalë komentin inline që ishte pjesë e ndryshimit.

ID e detyrës: astropy__astropy-13236⁠(hapet në një dritare të re)

Nxjerrja e kontaminimit

Kërkesë e përdoruesit

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.

Paraplotëso

1Let me be precise about the location and wording.

Përgjigjja e Assitant

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

Përditësim i artë

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, kur nuk i jepet asnjë informacion i mëtejshëm lidhur me detyrën përveç ID, është në gjendje të nxjerrë fjalë për fjalë detaje nga përshkrimi i detyrës dhe patch-i gold. Kjo përfshin formulën e re regex për validimin e emrit të përdoruesit dhe numrat e saktë të rreshtave për ndryshimin.

ID e detyrës: django__django-11099⁠(hapet në një dritare të re)

Nxjerrja e kontaminimit

Deklaratë problemi

1UsernameValidator allows trailing newline in usernames

Kërkesë e përdoruesit

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.

Paraplotëso

1Let me be precise about the wording.

Përgjigja e modelit

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

Përditësim i artë

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

Diskutim

Nga ky auditim i SWE-bench Verified, shohim dy mësime më të gjera për dizajnin e vlerësimit. Së pari, benchmark-et e marra nga materiale të disponueshme publikisht mbartin rrezik kontaminimi, ku ekspozimi ndaj të dhënave të trajnimit mund të rrisë në heshtje rezultatet. Nëse të dhënat e kërkuara publikisht përdoren në ndërtimin e standardit, zhvilluesit e modelit duhet të kryejnë teste shtesë për ndotje. Benchmark-et, dhe madje edhe zgjidhjet e tyre, të postuara publikisht mund të përfundojnë në të dhënat e trajnimit. Duhet treguar kujdes i veçantë si në mënyrën se si postohen grupet e të dhënave (i.e. i mbrojtur me fjalëkalim) dhe filtrimi i të dhënave të trajnimit (d.m.th. përmbajtje strikte ndaj canary strings).

Së dyti, vlerësimi i automatizuar është i ndërlikuar për t’u bërë siç duhet; rastet e përsosura të testimit duhet të verifikojnë plotësisht funksionalitetin e saktë, duke qenë si agnostike ndaj detajeve specifike të parëndësishme të implementimit ashtu edhe të qëndrueshme ndaj zgjidhjeve të shkurtra. Këto probleme janë në thelb komplekse dhe të vështira për t'u zgjidhur. Kapja e këtyre problemeve kërkoi fushata të shumta të gjera etiketimi njerëzor.

Ne i kemi përfshirë këto gjetje në përpjekjet tona të fundit të vlerësimit. Në muajt e fundit kemi zgjedhur të raportojmë rezultatet nga ndarja publike e SWE-Bench Pro. Ne rekomandojmë që zhvilluesit e tjerë të modeleve të bëjnë të njëjtën gjë. SWE-bench Pro nuk është i përsosur, por empirikisht duket se vuan më pak nga problemet e kontaminimit. Procesi ynë i zbulimit të ndotjes gjeti disa raste ndotjeje, por këto raste ishin dukshëm më të rralla dhe më pak të rënda se SWE-bench Verified, dhe asnjë model nuk ishte në gjendje të prodhonte një patch të artë të plotë fjalë për fjalë.

Ne do të vazhdojmë të investojmë në standarde krahasimi origjinale, të hartuara privatisht, dhe do të kërkojmë ndihmë nga industria dhe akademia për të bërë të njëjtën gjë. Në GDPVal⁠, detyrat hartohen privatisht nga ekspertë të domenit, duke ulur rrezikun e ekspozimit, dhe zgjidhjet vlerësohen në mënyrë holistike nga vlerësues të trajnuar. Kjo qasje kërkon shumë burime, por është gjithnjë e më e nevojshme për të matur përmirësime të vërteta të aftësive.

2026

Autor

OpenAI

Vazhdo të lexosh

Shiko të gjitha

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Kërkime4 qer 2026

Prezantimi i aftësive të reja në GPT-Rosalind

Produkti3 qer 2026

Forcimi i qëndrueshmërisë shoqërore me Rosalind Biodefense

Produkti29 maj 2026