23 Februari 2026

Mengapa SWE-bench Verified tidak lagi mengukur kemampuan pengodean terdepan

SWE-bench Verified makin terkontaminasi. Kami merekomendasikan SWE-bench Pro.

Memuat…

Sejak kami pertama kali menerbitkan SWE-bench Verified pada Agustus 2024, industri telah banyak menggunakannya untuk mengukur kemajuan model dalam tugas rekayasa perangkat lunak otonom. Setelah dirilis, SWE-bench Verified memberikan sinyal kuat tentang kemajuan kapabilitas dan menjadi metrik standar yang dilaporkan dalam rilis model terdepan. Melacak dan memperkirakan kemajuan kemampuan ini juga merupakan bagian penting dari Kerangka Kerja Kesiapan OpenAI. Saat kami pertama kali membuat tolok ukur Verified, kami berupaya menyelesaikan masalah dalam evaluasi asli yang membuat tugas tertentu mustahil untuk diselesaikan dalam dataset SWE-bench⁠(terbuka di jendela baru).

Setelah lonjakan awal, kemajuan mutakhir pada SWE-bench Verified telah melambat, meningkat⁠(terbuka di jendela baru) dari 74,9% menjadi 80,9% dalam 6 bulan terakhir. Hal ini menimbulkan pertanyaan: apakah kegagalan yang tersisa mencerminkan keterbatasan model atau sifat dari kumpulan data itu sendiri?

Dalam analisis baru, kami menemukan dua masalah utama pada set Verified yang menunjukkan bahwa tolok ukur tersebut tidak lagi cocok untuk mengukur kemajuan kemampuan rekayasa perangkat lunak otonom untuk peluncuran terdepan pada tingkat kinerja saat ini:

Tes menolak solusi yang benar: Kami mengaudit 27.6% subset dari dataset yang sering gagal diselesaikan oleh model dan menemukan bahwa setidaknya 59.4% dari masalah yang diaudit memiliki kasus uji yang cacat yang menolak pengajuan yang secara fungsional benar, meskipun kami telah berupaya sebaik mungkin untuk memperbaiki hal ini dalam pembuatan awal SWE-bench Verified.
Pelatihan pada solusi: Karena model terdepan yang besar dapat mempelajari informasi dari pelatihannya, penting agar model tersebut tidak pernah dilatih pada masalah dan solusi yang dievaluasi. Ini mirip dengan membagikan soal dan solusi untuk tes yang akan datang kepada siswa sebelum tes - mereka mungkin tidak menghafal jawabannya, tetapi siswa yang sudah pernah melihat jawabannya tentu akan lebih baik daripada mereka yang belum. Masalah SWE-bench bersumber dari repositori sumber terbuka yang digunakan banyak penyedia model untuk tujuan pelatihan. Dalam analisis kami, kami menemukan bahwa semua model terdepan yang kami uji mampu mereproduksi perbaikan bug asli yang ditulis manusia dan digunakan sebagai referensi ground-truth, yang dikenal sebagai gold patch, atau secara verbatim spesifik pernyataan masalah untuk tugas tertentu, yang menunjukkan bahwa semuanya telah melihat setidaknya beberapa masalah dan solusi selama pelatihan.

Kami juga menemukan bukti bahwa model yang telah melihat masalah tersebut selama pelatihan lebih mungkin berhasil, karena mereka memiliki informasi tambahan yang diperlukan untuk lulus tes yang kurang terdefinisi.

Ini berarti bahwa peningkatan pada SWE-bench Verified tidak lagi mencerminkan peningkatan yang signifikan dalam kemampuan pengembangan perangkat lunak dunia nyata model. Sebaliknya, hal tersebut semakin mencerminkan seberapa banyak model terpapar pada tolok ukur saat pelatihan. Inilah alasan kami telah berhenti melaporkan skor SWE-bench Verified, dan kami merekomendasikan agar pengembang model lain juga melakukan hal yang sama.

Kami sedang membangun evaluasi baru yang tidak terkontaminasi untuk melacak kemampuan pengodean dengan lebih baik, dan kami menilai ini sebagai area penting untuk menjadi fokus bagi komunitas riset yang lebih luas. Sampai kami memilikinya, OpenAI merekomendasikan pelaporan hasil untuk SWE-bench Pro.

Latar belakang

Evaluasi SWE-bench⁠(terbuka di jendela baru) asli dirilis pada tahun 2023. Setiap masalah bersumber dari isu GitHub yang telah diselesaikan di salah satu dari 12 repositori Python sumber terbuka dan dipasangkan dengan pull request (PR) yang sesuai. Untuk menentukan apakah perubahan kode yang dihasilkan model sudah benar, setiap masalah dilengkapi dengan dua set pengujian:

Pengujian yang gagal pada basis kode yang tidak dimodifikasi tetapi lulus jika masalahnya diperbaiki dengan benar
Tes regresi yang lulus baik sebelum maupun setelah perbaikan untuk memastikan fungsionalitas yang tidak terkait tetap utuh.

Model tidak melihat tes. Model harus menghasilkan perubahan kode hanya berdasarkan teks masalah asli dan keadaan repositori sebelum perbaikan. Masalah hanya dianggap selesai jika semua uji lulus setelah perubahan kode diterapkan.

Kami menemukan banyak masalah dengan evaluasi tersebut yang dapat menyebabkan pelaporan yang kurang akurat atas kapabilitas model.

Beberapa uji unit terlalu spesifik atau tidak selaras dengan tugas sehingga perbaikan yang benar dapat ditolak.
Banyak pernyataan tugas yang kurang terperinci, yang dapat menyebabkan beberapa interpretasi yang sama-sama valid - sementara tes hanya mencakup interpretasi tertentu.
Tergantung pada konfigurasi lingkungan (misalnya Linux vs Windows, atau versi Python), beberapa tes dapat gagal secara tidak terduga

Kami membuat SWE-bench Verified pada tahun 2024 untuk mengatasi masalah ini. Kami bekerja sama dengan insinyur perangkat lunak ahli untuk meninjau 1.699 masalah SWE-bench dan menyaring masalah yang memiliki isu-isu ini. Setiap masalah ditinjau oleh tiga pakar secara independen. Proses peninjauan ini menghasilkan SWE-bench Verified, sekumpulan 500 masalah yang dikurasi.

Pengujian yang terlalu sempit dan terlalu lebar

Meskipun SWE-bench Verified merupakan peningkatan besar dibandingkan versi awal, masalah yang tersisa tetap ada. Kami melakukan audit terhadap 138 masalah SWE-bench Verified yang tidak secara konsisten diselesaikan oleh OpenAI o3 selama 64 run independen. Setiap kasus ditinjau secara independen oleh setidaknya enam teknisi perangkat lunak berpengalaman. Jika seorang ahli menandai masalah, masalah tersebut diverifikasi ulang oleh tim tambahan.

Kami menemukan bahwa 59,4% dari 138 masalah mengandung isu material dalam desain pengujian dan/atau deskripsi masalah, sehingga membuatnya sangat sulit atau mustahil bahkan bagi model atau manusia yang paling mampu untuk menyelesaikannya.

35,5% dari tugas yang diaudit memiliki kasus uji yang ketat yang menegakkan detail implementasi tertentu, sehingga membatalkan banyak pengajuan yang secara fungsional benar, yang kami sebut kasus uji sempit.
18,8% dari tugas yang diaudit memiliki tes yang memeriksa fungsionalitas tambahan yang tidak disebutkan dalam deskripsi masalah, yang kami sebut kasus uji yang luas.
5.1% tugas lainnya memiliki masalah lain yang tidak terkelompok dengan baik dalam taksonomi ini.

Contoh ilustratif dari mode kegagalan pertama adalah pylint-dev__pylint-4551⁠(terbuka di jendela baru), di mana PR memperkenalkan fungsi baru `get_annotation` sebagai bagian dari solusi keseluruhan. Nama fungsi ini tidak disebutkan dalam deskripsi masalah, tetapi diimpor langsung oleh pengujian. Meskipun beberapa model mungkin secara intuitif membuat fungsi semacam itu, tidak sepenuhnya diperlukan untuk menerapkan fungsi dengan nama spesifik ini agar dapat menangani masalah dengan benar. Banyak solusi yang valid gagal dalam pengujian karena kesalahan impor.

Deskripsi masalah

Teks polos

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

Cuplikan uji PR

Python

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

Kegagalan uji PR (dipotong untuk keterbacaan)

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)

Contoh kasus uji yang terlalu luas adalah sympy__sympy-18199⁠(terbuka di jendela baru). Tugas ini bersumber dari sebuah PR yang menangani tiga masalah berbeda pada fungsi `nthroot_mod`, yaitu #17373⁠(terbuka di jendela baru), #17377⁠(terbuka di jendela baru), dan #18212⁠(terbuka di jendela baru). Namun, deskripsi untuk tugas SWE-bench Verified hanya mencakup masalah terakhir #18212⁠(terbuka di jendela baru). Ini menimbulkan ketidaksesuaian: tes PR mencakup ketiga masalah, sementara deskripsinya hanya merinci satu masalah. Dalam pengujian kami, model sering kali mengimplementasikan perbaikan yang dijelaskan dengan benar lalu gagal pada pengujian yang mencakup implementasi untuk dua masalah lainnya.

Deskripsi PR asli (dari PR GitHub)

Teks polos

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

Deskripsi Masalah untuk #18212

Teks polos

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.

Deskripsi Masalah untuk tugas SWE-bench Verified (hanya diambil dari #18212):

Teks polos

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.

Kontaminasi

SWE-bench Verified dan repositori (basis kode dan catatan rilis) keduanya bersifat sumber terbuka serta digunakan dan dibahas secara luas, yang membuat penghindaran kontaminasi menjadi sulit bagi pengembang model.

Kami pertama kali menemukan tanda-tanda kontaminasi dalam model kami sendiri. Sebagai contoh, ketika GPT‑5.2 menyelesaikan 31 tugas yang kami identifikasi sebagai hampir mustahil untuk diselesaikan. Dalam django__django-14725⁠(terbuka di jendela baru) pengujian memerlukan parameter baru tertentu `edit_only` yang tidak secara eksplisit diwajibkan oleh pernyataan masalah. Saat menyelesaikan masalah, GPT‑5.2 menunjukkan dalam rantai pemikiran bahwa ia memiliki informasi tentang catatan rilis yang merinci perubahan pada basis kode, dan dengan benar mengidentifikasi bahwa parameter `edit_only` diperkenalkan di Django 4.1.

GPT‑5.2 CoT

Teks polos

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.

Untuk menilai seberapa signifikan kontaminasi secara lebih luas, kami membuat pengaturan red-teaming otomatis. Untuk setiap pertanyaan SWE-bench Verified, kami menugaskan GPT‑5 untuk menguji sebuah GPT‑5.2‑Chat, Claude Opus 4.5 dan Gemini 3 Flash Preview untuk kontaminasi. Model-model ini dipilih untuk mengecualikan model penalaran, tetapi kami mengakui bahwa kemungkinan ada kesenjangan kemampuan yang tidak sepele di antara keduanya.

Untuk memeriksa kontaminasi, GPT‑5 menerima: ID, deskripsi, patch gold, dan pengujian PR dari tugas SWE-bench Verified. Selama lebih dari 15 putaran, kami membiarkan GPT‑5 untuk mengubah prompt sistem/pengembang, prompt pengguna, dan pengisian awal asisten, serta strategi penggalian informasi yang berbeda. Setelah setiap putaran, model juri memberi label seberapa banyak informasi tugas-spesifik yang baru muncul, dan setiap respons diberi label tingkat kontaminasi dari “tidak ada” hingga “kuat.” GPT‑5 diizinkan untuk menyesuaikan strateginya berdasarkan giliran sebelumnya untuk secara iteratif memulihkan detail spesifik tugas. Untuk setiap contoh kontaminasi yang kuat, kami memverifikasi dengan juri lain bahwa GPT‑5 tidak membocorkan terlalu banyak informasi ke model target. Terakhir, kami kemudian meninjau secara manual contoh “strong” yang membentuk transkrip dalam postingan ini.

Di bawah ini adalah contoh kontaminasi yang signifikan di berbagai penyedia model.

GPT‑5.2

Diberikan cuplikan singkat dari deskripsi tugas, GPT‑5.2 menghasilkan patch emas yang persis sama. Secara khusus, ini mengetahui nama class dan method yang tepat, serta kondisi early return baru `if username is None or password is None` yang diperkenalkan.

ID Tugas: django__django-11451⁠(terbuka di jendela baru)

Pemeriksaan kontaminasi

Pernyataan masalah

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

Prompt pengguna

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"

Respons model

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.

Patch unggulan

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 tidak hanya mampu mengingat perubahan fungsional 4 baris yang tepat yang diperkenalkan PR, beserta nama file dan metode spesifik yang disentuhnya, tetapi juga mengutip secara verbatim komentar inline yang merupakan bagian dari diff.

ID Tugas: astropy__astropy-13236⁠(terbuka di jendela baru)

Pemeriksaan kontaminasi

Prompt Pengguna

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.

Isi otomatis

1Let me be precise about the location and wording.

Respons Asisten

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

Patch unggulan

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, ketika tidak diberi informasi lebih lanjut mengenai tugas selain ID, mampu mengeluarkan detail verbatim dari deskripsi tugas dan patch gold. Ini mencakup formula regex baru untuk validasi nama pengguna dan nomor baris yang tepat untuk perubahan tersebut.

ID Tugas: django__django-11099⁠(terbuka di jendela baru)

Pemeriksaan kontaminasi

Pernyataan masalah

1UsernameValidator allows trailing newline in usernames

Prompt pengguna

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.

Isi otomatis

1Let me be precise about the wording.

Respons model

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

Patch unggulan

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

Diskusi

Dari audit SWE-bench Verified ini, kita melihat dua pelajaran yang lebih luas untuk desain evaluasi. Pertama, tolok ukur yang bersumber dari materi yang tersedia untuk umum membawa risiko kontaminasi, di mana paparan data pelatihan dapat secara diam-diam menggelembungkan skor. Jika data yang dikumpulkan secara publik digunakan dalam pembuatan tolok ukur, pengembang model harus melakukan uji tambahan untuk mendeteksi kontaminasi. Tolok ukur, dan bahkan solusinya, yang diposting secara publik dapat berakhir dalam data pelatihan. Perlu kehati-hatian ekstra baik dalam cara dataset diposting (i.e. dilindungi kata sandi) dan pemfilteran data pelatihan (i.e. kepatuhan ketat terhadap canary strings).

Kedua, pemberian skor otomatis sulit untuk dilakukan dengan benar; kasus uji yang sempurna harus sepenuhnya memverifikasi fungsionalitas yang benar, baik agnostik terhadap detail implementasi spesifik yang tidak penting maupun juga tangguh terhadap solusi pintas. Masalah-masalah ini pada dasarnya kompleks dan sulit diselesaikan. Menemukan masalah-masalah ini memerlukan beberapa kampanye pelabelan manusia yang ekstensif.

Kami telah menggabungkan temuan-temuan ini ke dalam upaya evaluasi terbaru kami. Dalam beberapa bulan terakhir, kami memilih untuk melaporkan hasil dari split publik SWE-Bench Pro. Kami merekomendasikan agar pengembang model lainnya melakukan hal yang sama. SWE-bench Pro tidak sempurna, tetapi secara empiris tampaknya lebih sedikit mengalami masalah kontaminasi. Pipeline kontaminasi kami menemukan beberapa kasus kontaminasi, tetapi kasus-kasus ini secara signifikan lebih jarang dan kurang parah dibandingkan SWE-bench Verified, dan tidak ada model yang mampu menghasilkan patch gold verbatim yang lengkap.

Kami akan terus berinvestasi dalam tolok ukur orisinal yang ditulis secara privat dan meminta bantuan dari industri dan akademisi untuk melakukan hal yang sama. Di GDPVal⁠, tugas ditulis secara privat oleh pakar domain, sehingga mengurangi risiko paparan, dan solusi dinilai secara holistik oleh penilai terlatih. Pendekatan ini memerlukan banyak sumber daya, tetapi semakin diperlukan untuk mengukur peningkatan kemampuan yang sesungguhnya.

2026

Penulis

OpenAI

Terus membaca

Lihat semua

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Riset4 Jun 2026

Memperkenalkan kemampuan baru untuk GPT-Rosalind

Produk3 Jun 2026

Memperkuat ketahanan masyarakat dengan Rosalind Biodefense

Produk29 Mei 2026