Langkau ke kandungan utama
OpenAI

23 Februari 2026

PenyelidikanPenerbitan

Mengapa SWE-bench Verified tidak lagi mengukur keupayaan pengekodan perbatasan

SWE-bench Verified semakin tercemar. Kami mengesyorkan SWE-bench Pro.

Memuat…

Sejak kami mula-mula menerbitkan SWE-bench Verified pada Ogos 2024, industri telah menggunakannya secara meluas untuk mengukur kemajuan model dalam tugasan kejuruteraan perisian autonomi. Selepas pelancarannya, SWE-bench Verified memberikan isyarat yang kuat tentang kemajuan keupayaan dan menjadi metrik standard yang dilaporkan dalam pelancaran model perbatasan. Menjejak dan meramalkan kemajuan keupayaan ini juga merupakan bahagian penting dalam Rangka Kerja Kesediaan OpenAI. Apabila kami mula-mula mencipta penanda aras Verified, kami cuba menyelesaikan isu dalam penilaian asal yang menjadikan sesetengah tugasan mustahil untuk diselesaikan dalam set data SWE-bench(dibuka dalam tetingkap baru).

Selepas lonjakan awal, kemajuan terkini pada SWE-bench Verified telah perlahan, meningkat(dibuka dalam tetingkap baru) daripada 74.9% kepada 80.9% dalam 6 bulan yang lalu. Ini menimbulkan persoalan: adakah kegagalan yang selebihnya mencerminkan batasan model atau sifat set data itu sendiri?

Dalam analisis baharu, kami mendapati dua isu utama dengan set Verified yang menunjukkan bahawa penanda aras itu tidak lagi sesuai untuk mengukur kemajuan dalam keupayaan kejuruteraan perisian autonomi bagi pelancaran perbatasan pada tahap prestasi hari ini:

  1. Ujian menolak penyelesaian yang betul: Kami mengaudit subset 27.6% daripada set data yang sering gagal diselesaikan oleh model dan mendapati bahawa sekurang-kurangnya 59.4% daripada masalah yang diaudit mempunyai kes ujian yang cacat yang menolak penyerahan yang betul dari segi fungsi, walaupun kami telah berusaha sedaya upaya untuk menambah baik perkara ini dalam penciptaan awal SWE-bench Verified.
  2. Latihan mengenai penyelesaian: Oleh sebab model perbatasan yang besar boleh mempelajari maklumat daripada latihannya, adalah penting bahawa ia tidak pernah dilatih pada masalah dan penyelesaian yang dinilai ke atasnya. Ini seumpama berkongsi masalah dan penyelesaian untuk ujian yang akan datang dengan pelajar sebelum ujian - mereka mungkin tidak menghafal jawapannya tetapi pelajar yang pernah melihat jawapan sebelum ini pasti akan lebih baik daripada mereka yang tidak. Masalah SWE-bench diperoleh daripada repositori sumber terbuka yang digunakan oleh banyak penyedia model untuk tujuan latihan. Dalam analisis kami, kami mendapati bahawa semua model perbatasan yang kami uji dapat menghasilkan semula pembaikan pepijat asal yang ditulis oleh manusia yang digunakan sebagai rujukan kebenaran asas, yang dikenali sebagai tampalan emas, atau butiran pernyataan masalah verbatim untuk tugas tertentu, yang menunjukkan bahawa kesemuanya telah melihat sekurang-kurangnya sebahagian daripada masalah dan penyelesaian semasa latihan.

Kami juga menemui bukti bahawa model yang telah melihat masalah tersebut semasa latihan lebih berkemungkinan untuk berjaya, kerana ia mempunyai maklumat tambahan yang diperlukan untuk lulus ujian yang tidak ditentukan dengan jelas.

Ini bermakna bahawa penambahbaikan pada SWE-bench Verified tidak lagi mencerminkan penambahbaikan yang bermakna dalam keupayaan pembangunan perisian dunia sebenar model. Sebaliknya, ia semakin mencerminkan sejauh mana model terdedah kepada penanda aras pada masa latihan. Inilah sebabnya kami telah berhenti melaporkan skor SWE-bench Verified, dan kami mengesyorkan agar pembangun model lain turut berbuat demikian.

Kami sedang membina penilaian baharu yang tidak tercemar untuk menjejak keupayaan pengekodan dengan lebih baik, dan kami fikir ini merupakan bidang penting untuk diberi tumpuan bagi komuniti penyelidikan yang lebih luas. Sehingga kami mempunyai perkara tersebut, OpenAI mengesyorkan melaporkan keputusan untuk SWE-bench Pro.

Latar belakang

Penilaian asal SWE-bench(dibuka dalam tetingkap baru) telah dikeluarkan pada tahun 2023. Setiap masalah diperoleh daripada isu GitHub yang telah diselesaikan dalam salah satu daripada 12 repositori Python sumber terbuka dan dipasangkan dengan pull request (PR) yang sepadan. Untuk menentukan sama ada perubahan kod yang dijana oleh model adalah betul, setiap masalah disertakan dengan dua set ujian:

  • Ujian yang gagal pada pangkalan kod yang tidak diubah suai tetapi lulus jika isu itu dibetulkan dengan betul
  • Ujian regresi yang lulus sebelum dan selepas pembaikan untuk memastikan fungsi yang tidak berkaitan kekal utuh.

Model tidak melihat ujian. Ia perlu menghasilkan perubahan kod dengan hanya teks isu asal dan keadaan repositori sebelum pembaikan. Ia hanya melepasi masalah jika semua ujian lulus selepas perubahan kod digunakan.

Kami mendapati banyak isu dengan penilaian itu yang boleh menyebabkan pelaporan yang kurang tepat tentang keupayaan model-model.

  • Sesetengah ujian unit terlalu khusus atau tidak selaras dengan tugas, jadi pembetulan yang betul boleh ditolak.
  • Banyak pernyataan tugas kurang ditentukan, yang boleh membawa kepada pelbagai tafsiran yang sah - sedangkan ujian hanya merangkumi satu tafsiran tertentu.
  • Bergantung pada persediaan persekitaran (contohnya Linux berbanding Windows, atau versi python), sesetengah ujian mungkin gagal secara tersilap

Kami mencipta SWE-bench Verified pada tahun 2024 untuk menangani isu-isu ini. Kami bekerjasama dengan jurutera perisian pakar untuk menyemak 1,699 masalah SWE-bench dan menapis masalah yang mempunyai isu-isu ini. Setiap masalah telah disemak oleh tiga pakar secara bebas. Proses semakan ini menghasilkan SWE-bench Verified, satu set kumpulan 500 masalah.

Ujian yang terlalu sempit dan terlalu luas

Walaupun SWE-bench Verified merupakan penambahbaikan besar berbanding versi awal, isu-isu baki masih wujud. Kami menjalankan audit terhadap 138 masalah SWE-bench Verified yang OpenAI o3 tidak selesaikan secara konsisten merentasi 64 larian bebas. Setiap kes telah disemak secara bebas oleh sekurang-kurangnya enam jurutera perisian berpengalaman. Jika seorang pakar menandakan isu, ia disahkan semula oleh pasukan tambahan.

Kami mendapati bahawa 59.4% daripada 138 masalah mengandungi isu material dalam reka bentuk ujian dan/atau penerangan masalah, menjadikannya amat sukar atau mustahil walaupun untuk model atau manusia yang paling berkeupayaan untuk menyelesaikannya. 

  • 35.5% daripada tugasan yang diaudit mempunyai kes ujian yang ketat yang menguatkuasakan butiran pelaksanaan tertentu, sekali gus membatalkan banyak penyerahan yang betul dari segi fungsi, yang kami panggil kes ujian sempit.
  • 18.8% daripada tugas yang diaudit mempunyai ujian yang memeriksa fungsi tambahan yang tidak dinyatakan dalam penerangan masalah, yang kami panggil kes ujian luas.
  • Baki 5.1% tugas mempunyai isu pelbagai yang tidak dikelompokkan dengan baik mengikut taksonomi ini.

Satu contoh ilustratif bagi mod kegagalan pertama ialah pylint-dev__pylint-4551(dibuka dalam tetingkap baru), di mana PR memperkenalkan fungsi baharu `get_annotation` sebagai sebahagian daripada penyelesaian keseluruhan. Nama fungsi ini tidak disebut dalam penerangan masalah, tetapi diimport secara langsung oleh ujian. Walaupun sesetengah model mungkin secara intuitif mencipta fungsi sedemikian, ia tidak semestinya perlu untuk melaksanakan fungsi dengan nama khusus ini untuk menangani masalah dengan betul. Banyak penyelesaian yang sah gagal ujian disebabkan ralat import.

Keterangan masalah

Teks Biasa

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

Coretan ujian PR

Python

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

Kegagalan ujian PR (dipendekkan untuk memudahkan pembacaan)

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)

Satu contoh kes ujian yang terlalu luas ialah sympy__sympy-18199(dibuka dalam tetingkap baru). Tugas ini diperoleh daripada PR yang menangani tiga isu berbeza dengan fungsi `nthroot_mod`, khususnya #17373(dibuka dalam tetingkap baru), #17377(dibuka dalam tetingkap baru), dan #18212(dibuka dalam tetingkap baru). Walau bagaimanapun, perihalan untuk tugas SWE-bench Verified hanya meliputi isu akhir #18212(dibuka dalam tetingkap baru). Ini mewujudkan ketidakpadanan: ujian PR meliputi ketiga-tiga isu, manakala penerangan memperincikan hanya satu. Dalam percubaan kami, model sering melaksanakan pembetulan yang diterangkan dengan betul dan kemudian gagal ujian yang meliputi pelaksanaan untuk dua isu yang lain.

Penerangan PR asal (daripada PR GitHub)

Teks Biasa

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

Keterangan Masalah untuk #18212

Teks Biasa

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.

Penerangan masalah untuk tugas SWE-bench Verified (hanya diambil daripada #18212):

Teks Biasa

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.

Pencemaran

SWE-bench Verified dan repositori (asas kod dan nota keluaran) kedua-duanya adalah sumber terbuka serta digunakan dan dibincangkan secara meluas, yang menjadikan pengelakan pencemaran sukar bagi pembangun model.

Kami mula-mula menemui tanda-tanda pencemaran dalam model kami sendiri. Sebagai contoh, apabila GPT‑5.2 menyelesaikan 31 tugas yang kami kenal pasti sebagai hampir mustahil untuk diselesaikan. Dalam django__django-14725(dibuka dalam tetingkap baru) ujian memerlukan parameter baharu khusus `edit_only` yang tidak diperlukan secara jelas oleh pernyataan masalah. Semasa menyelesaikan masalah, GPT‑5.2 menunjukkan dalam rentetan fikiran bahawa ia mempunyai maklumat tentang nota keluaran yang memperincikan perubahan pada pangkalan kod dan dengan betul mengenal pasti bahawa parameter `edit_only` telah diperkenalkan dalam Django 4.1.

GPT‑5.2 CoT

Teks Biasa

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.

Untuk menilai sejauh mana pencemaran itu signifikan secara lebih meluas, kami mencipta persediaan proses penyerang automatik. Bagi setiap soalan SWE-bench yang Disahkan, kami menugaskan GPT‑5 untuk menyiasat GPT‑5.2‑Chat, Claude Opus 4.5 dan Gemini 3 Flash Pratonton untuk pencemaran. Model-model ini dipilih untuk mengecualikan model penaakulan, tetapi kami mengakui bahawa berkemungkinan terdapat jurang keupayaan yang bukan kecil antara model-model tersebut.

Untuk menyiasat pencemaran, GPT‑5 menerima: ID, penerangan, tampalan emas, dan ujian PR bagi tugasan SWE-bench Verified. Sepanjang lebih 15 giliran, kami membenarkan GPT‑5 untuk mempelbagaikan prom sistem/pembangun, prom pengguna, dan praisi pembantu serta strategi elisitasi yang berbeza. Selepas setiap giliran, sebuah model hakim melabelkan berapa banyak maklumat baharu khusus tugas yang muncul dan setiap respons dilabelkan untuk tahap pencemaran daripada “none” hingga “strong.” GPT‑5 dibenarkan menyesuaikan strateginya berdasarkan giliran sebelumnya untuk memulihkan butiran khusus tugas secara berulang. Bagi setiap contoh pencemaran yang kuat, kami mengesahkan dengan seorang hakim lain bahawa GPT‑5 tidak membocorkan terlalu banyak maklumat kepada model sasaran. Akhir sekali, kami kemudian menyemak secara manual contoh “kukuh” yang membentuk transkrip dalam siaran ini.

Berikut adalah contoh pencemaran yang kuat merentasi penyedia model yang berbeza.

GPT‑5.2 

Diberikan petikan ringkas daripada penerangan tugasan, GPT‑5.2 menghasilkan tampalan emas yang tepat. Terutamanya, ia mengetahui nama kelas dan kaedah yang tepat, serta syarat pulangan awal baharu `if username is None or password is None` yang diperkenalkan.

Elisitasi pencemaran

Pernyataan masalah

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

Prom pengguna

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"

Respons model

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.

Tampalan emas

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 bukan sahaja mampu mengingati perubahan fungsian 4 baris yang tepat yang diperkenalkan oleh PR, bersama-sama dengan nama fail dan kaedah khusus yang disentuhnya, tetapi juga memetik secara verbatim komen sebaris yang merupakan sebahagian daripada diff. 

Elisitasi pencemaran

Prom pengguna

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.

Praisi

1
Let me be precise about the location and wording.

Tindak balas pembantu

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

Tampalan emas

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, apabila tidak diberikan sebarang maklumat lanjut mengenai tugas selain ID, mampu mengeluarkan butiran secara verbatim daripada penerangan tugas dan tampalan emas. Ini termasuk formula regex baharu untuk pengesahan nama pengguna dan nombor baris yang tepat bagi perubahan tersebut.

Elisitasi pencemaran

Pernyataan masalah

1
UsernameValidator allows trailing newline in usernames

Prom pengguna

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.

Praisi

1
Let me be precise about the wording.

Respons model

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

Tampalan emas

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

Perbincangan

Daripada audit SWE-bench Verified ini, kita melihat dua pengajaran yang lebih luas untuk reka bentuk penilaian. Pertama, penanda aras yang bersumberkan daripada bahan yang tersedia secara umum membawa risiko pencemaran, di mana pendedahan data latihan boleh secara senyap-senyap meningkatkan skor. Jika data yang dirangkak secara umum digunakan dalam pembinaan penanda aras, pembangun model harus menjalankan ujian tambahan untuk pencemaran. Penanda aras, dan juga penyelesaiannya, yang disiarkan secara umum boleh berakhir dalam data latihan. Penjagaan tambahan harus diambil dalam cara set data disiarkan (iaitu dilindungi kata laluan) dan penapisan data latihan (i.e. pematuhan ketat terhadap canary strings). 

Kedua, pemarkahan automatik sukar untuk dilakukan dengan betul; kes ujian yang sempurna sepatutnya mengesahkan sepenuhnya fungsi yang betul, dengan kedua-duanya tidak bergantung pada butiran pelaksanaan tertentu yang tidak penting dan juga teguh terhadap penyelesaian pintasan. Masalah-masalah ini sememangnya rumit dan sukar untuk diselesaikan. Mengesan masalah ini memerlukan pelbagai kempen pelabelan manusia yang meluas. 

Kami telah menggabungkan penemuan ini ke dalam usaha penilaian terkini kami. Dalam beberapa bulan kebelakangan ini kami telah memilih untuk melaporkan keputusan daripada pecahan awam SWE-Bench Pro. Kami mengesyorkan pembangun model lain melakukan perkara yang sama. SWE-bench Pro tidak sempurna, tetapi secara empirikal nampaknya kurang mengalami isu pencemaran. Saluran pengesanan pencemaran kami menemui beberapa kes pencemaran, tetapi kes-kes ini jauh lebih jarang dan kurang teruk berbanding SWE-bench Verified, dan tiada model yang dapat menghasilkan tampalan emas verbatim yang lengkap.

Kami akan terus melabur dalam penanda aras asli yang ditulis secara persendirian dan meminta bantuan daripada industri dan para akademik untuk melakukan perkara yang sama. Dalam GDPVal, tugas ditulis secara peribadi oleh pakar domain, mengurangkan risiko pendedahan dan penyelesaian dinilai secara holistik oleh penyemak terlatih. Pendekatan ini memerlukan banyak sumber, tetapi semakin diperlukan untuk mengukur peningkatan keupayaan yang sebenar.

Penulis

OpenAI