23 tháng 2, 2026

Tại sao SWE-bench Verified không còn đo lường khả năng mã hóa biên giới

SWE-bench Verified ngày càng bị ô nhiễm. Chúng tôi đề xuất SWE-bench Pro.

Đang tải…

Kể từ khi chúng tôi công bố SWE-bench Verified lần đầu tiên vào tháng 8 năm 2024, ngành công nghiệp đã sử dụng rộng rãi công cụ này để đo lường tiến độ của các mô hình trong các nhiệm vụ kỹ thuật phần mềm tự động. Sau khi được phát hành, SWE-bench Verified đã cung cấp một tín hiệu mạnh mẽ về sự tiến bộ năng lực và trở thành một chỉ số tiêu chuẩn được báo cáo trong các bản phát hành mô hình tiên phong. Việc theo dõi và dự báo tiến độ phát triển các năng lực này cũng là một phần quan trọng trong Khung chuẩn bị của OpenAI. Khi chúng tôi tạo điểm chuẩn Đã xác minh ban đầu, chúng tôi đã cố gắng giải quyết các vấn đề trong đánh giá ban đầu khiến một số nhiệm vụ nhất định không thể hoàn thành trong tập dữ liệu SWE-Bench⁠(mở trong cửa sổ mới).

Sau những bước nhảy vọt ban đầu, tiến bộ hiện đại trên SWE-Bench Verified đã chậm lại, cải thiện⁠(mở trong cửa sổ mới) từ 74.9% lên 80.9% trong 6 tháng qua. Điều này đặt ra câu hỏi: các lỗi còn lại có phản ánh các hạn chế của mô hình hoặc thuộc tính của chính tập dữ liệu không?

Trong một phân tích mới, chúng tôi đã tìm thấy hai vấn đề chính với bộ Đã xác minh cho thấy điểm chuẩn không còn phù hợp để đo lường tiến độ về khả năng kỹ thuật phần mềm tự động cho các lần ra mắt ở mức hiệu suất hiện nay:

Các bài kiểm thử loại bỏ các lời giải đúng: Chúng tôi đã kiểm tra một tập con 27,6% của bộ dữ liệu mà các mô hình thường không giải được và nhận thấy rằng ít nhất 59,4% các bài toán được kiểm tra có các trường hợp kiểm thử bị lỗi, loại bỏ các bài nộp đúng về mặt chức năng, bất chấp những nỗ lực tốt nhất của chúng tôi trong việc cải thiện điều này trong quá trình tạo ban đầu của SWE-bench Verified.
Đào tạo trên các giải pháp: Vì các mô hình tiên phong lớn có thể học thông tin từ quá trình đào tạo của chúng, điều quan trọng là chúng không bao giờ được đào tạo trên các vấn đề và giải pháp mà chúng được đánh giá. Điều này giống như chia sẻ các vấn đề và giải pháp cho một bài kiểm tra sắp tới với học sinh trước bài kiểm tra - họ có thể không ghi nhớ câu trả lời nhưng những sinh viên đã xem câu trả lời trước đó chắc chắn sẽ làm tốt hơn những người không có bài kiểm tra. Các bài toán SWE-bench được lấy từ các kho lưu trữ mà nhiều nhà cung cấp mô hình sử dụng cho mục đích huấn luyện. Trong phân tích của mình, chúng tôi nhận thấy rằng tất cả các mô hình tiên phong mà chúng tôi đã thử nghiệm đều có thể tái tạo bản sửa lỗi ban đầu, do con người viết được sử dụng làm tham chiếu sự thật cơ sở, được gọi là bản vá vàng, hoặc nguyên văn tuyên bố vấn đề cụ thể cho một số nhiệm vụ nhất định, chỉ ra rằng tất cả chúng đều đã nhìn thấy ít nhất một số vấn đề và giải pháp trong quá trình đào tạo.

Chúng tôi cũng tìm thấy bằng chứng cho thấy các mô hình đã nhìn thấy các vấn đề trong quá trình đào tạo có nhiều khả năng thành công hơn, bởi vì họ có thêm thông tin cần thiết để vượt qua các bài kiểm tra chưa được xác định.

Điều này có nghĩa là những cải tiến trên SWE-bench Verified không còn phản ánh những cải tiến có ý nghĩa trong khả năng phát triển phần mềm trong thế giới thực của các mô hình. Thay vào đó, chúng ngày càng phản ánh mức độ mô hình đã tiếp xúc với điểm chuẩn tại thời điểm đào tạo. Đây là lý do tại sao chúng tôi đã ngừng báo cáo điểm số Swe-Bench Verified và chúng tôi khuyên các nhà phát triển mô hình khác cũng nên làm như vậy.

Chúng tôi đang xây dựng các đánh giá mới, không bị ô nhiễm để theo dõi tốt hơn khả năng mã hóa và chúng tôi nghĩ rằng đây là một lĩnh vực quan trọng cần tập trung vào đối với cộng đồng nghiên cứu rộng lớn hơn. Cho đến khi chúng tôi có những điều đó, OpenAI khuyên bạn nên báo cáo kết quả cho SWE-Bench Pro.

Bối cảnh

Đánh giá ban đầu của SWE-bench⁠(mở trong cửa sổ mới) đã được phát hành vào năm 2023. Mỗi vấn đề được lấy từ một sự cố đã được giải quyết trên GitHub trong một trong 12 kho lưu trữ Python mã nguồn mở và được ghép nối với pull request (PR) tương ứng. Để xác định xem một thay đổi mã được tạo ra từ mô hình có chính xác hay không, mỗi bài toán đều đi kèm với hai bộ kiểm thử:

Các thử nghiệm không thành công trên cơ sở mã chưa sửa đổi nhưng vượt qua nếu sự cố được khắc phục chính xác
Các bài kiểm tra hồi quy vượt qua cả trước và sau khi sửa lỗi để đảm bảo chức năng không liên quan vẫn còn nguyên vẹn.

Mô hình không nhìn thấy các bài kiểm tra. Nó phải tạo ra một thay đổi mã nguồn chỉ dựa trên văn bản lỗi ban đầu và trạng thái của kho lưu trữ trước khi sửa lỗi. Vấn đề chỉ được coi là vượt qua nếu tất cả các bài kiểm tra đều đạt sau khi thay đổi mã được áp dụng.

Chúng tôi tìm thấy nhiều vấn đề với đánh giá đó có thể dẫn đến việc báo cáo kém khả năng của các mô hình.

Một số bài kiểm tra đơn vị quá cụ thể hoặc không phù hợp với nhiệm vụ nên các bản sửa lỗi chính xác có thể bị từ chối.
Nhiều câu lệnh nhiệm vụ không được xác định rõ ràng, điều này có thể dẫn đến nhiều cách giải thích hợp lệ - trong khi các bài kiểm tra chỉ bao gồm một câu lệnh cụ thể.
Tùy thuộc vào thiết lập môi trường (ví dụ Linux vs Windows hoặc phiên bản python), một số thử nghiệm có thể thất bại nghiêm trọng

Chúng tôi đã tạo ra SWE-bench Verified vào năm 2024 để giải quyết những vấn đề này. Chúng tôi đã hợp tác với các kỹ sư phần mềm chuyên gia để xem xét 1.699 vấn đề trên SWE-bench và lọc ra những vấn đề có các lỗi này. Mỗi vấn đề đều được ba chuyên gia xem xét độc lập. Quá trình đánh giá này dẫn đến SWE-bench Verified, một tập hợp gồm 500 vấn đề được quản lý.

Các bài kiểm tra quá hẹp và quá rộng

Mặc dù SWE-bench Verified là một cải tiến đáng kể so với phiên bản ban đầu, vẫn còn một số vấn đề tồn đọng. Chúng tôi đã tiến hành kiểm tra 138 bài toán đã được xác minh bằng SWE-bench mà OpenAI o3 không giải quyết được một cách nhất quán trong 64 lần chạy độc lập. Mỗi trường hợp đều được ít nhất sáu kỹ sư phần mềm giàu kinh nghiệm xem xét độc lập. Nếu một chuyên gia phát hiện ra vấn đề, vấn đề đó sẽ được một nhóm khác kiểm tra lại.

Chúng tôi nhận thấy rằng 59,4% trong số 138 bài toán chứa các vấn đề vật chất trong thiết kế thử nghiệm và/hoặc mô tả vấn đề, khiến chúng trở nên cực kỳ khó hoặc không thể giải quyết ngay cả đối với mô hình hoặc con người có khả năng nhất.

35,5% các tác vụ được kiểm toán có các trường hợp kiểm thử nghiêm ngặt buộc phải tuân theo các chi tiết triển khai cụ thể, khiến nhiều bài nộp đúng về mặt chức năng bị vô hiệu, mà chúng tôi gọi là các trường hợp kiểm thử hẹp.
18.8% các tác vụ được kiểm toán có các bài kiểm thử kiểm tra thêm chức năng bổ sung không được nêu trong mô tả vấn đề, mà chúng tôi gọi là các trường hợp kiểm thử rộng.
5,1% nhiệm vụ còn lại có các vấn đề linh tinh không được nhóm tốt với phân loại này.

Một ví dụ minh họa về chế độ thất bại đầu tiên là pylint-dev__pylint-4551⁠(mở trong cửa sổ mới), trong đó PR giới thiệu một hàm mới 'get_annotation' như một phần của giải pháp tổng thể. Tên hàm này không được đề cập trong mô tả vấn đề, nhưng được nhập trực tiếp bởi các bài kiểm tra. Mặc dù một số mô hình có thể tự động tạo ra một hàm như vậy, nhưng việc triển khai một hàm có tên cụ thể như vậy không hoàn toàn cần thiết để giải quyết vấn đề một cách chính xác. Nhiều giải pháp hợp lệ không vượt qua các bài kiểm tra lỗi nhập.

Mô tả vấn đề

Văn bản thuần túy

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

Đoạn thử nghiệm PR

Python

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

Lỗi kiểm tra PR (bị cắt ngắn để dễ đọc)

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)

Một ví dụ về trường hợp kiểm thử quá rộng là sympy__sympy-18199⁠(mở trong cửa sổ mới). Nhiệm vụ này được lấy từ một PR đã giải quyết ba vấn đề riêng biệt với hàm `nthroot_mod`, cụ thể là #17373⁠(mở trong cửa sổ mới), #17377⁠(mở trong cửa sổ mới), và #18212⁠(mở trong cửa sổ mới). Tuy nhiên, mô tả cho tác vụ SWE-bench Đã xác minh chỉ bao gồm vấn đề cuối cùng #18212⁠(mở trong cửa sổ mới). Điều này tạo ra sự không phù hợp: các bài kiểm tra PR bao gồm cả ba vấn đề, trong khi mô tả chỉ chi tiết một vấn đề. Trong các lần chạy thử nghiệm của chúng tôi, các mô hình thường thực hiện chính xác bản sửa lỗi đã mô tả, nhưng sau đó lại thất bại trong các bài kiểm tra bao gồm việc thực hiện cho hai vấn đề còn lại.

Mô tả PR gốc (từ GitHub PR)

Văn bản thuần túy

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

Mô tả vấn đề cho #18212

Văn bản thuần túy

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.

Mô tả vấn đề cho tác vụ SWE-bench Verified (chỉ lấy từ #18212):

Văn bản thuần túy

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.

Rò rỉ dữ liệu

SWE-bench Verified và các kho lưu trữ (cơ sở mã và ghi chú phát hành) đều là mã nguồn mở và được sử dụng và thảo luận rộng rãi, điều này làm cho việc tránh Rò rỉ dữ liệu trở nên khó khăn cho các nhà phát triển mô hình.

Lần đầu tiên chúng tôi gặp phải dấu hiệu rò rỉ dữ liệu trong các mô hình của chính chúng tôi. Ví dụ như khi GPT‑5.2 giải quyết được 31 nhiệm vụ mà chúng tôi xác định là gần như không thể giải quyết. Trong django__django-14725⁠(mở trong cửa sổ mới) các bài kiểm thử yêu cầu một tham số mới cụ thể `edit_only` mà đề bài không nêu rõ là bắt buộc. Trong khi giải quyết vấn đề, GPT‑5.2 cho thấy trong chuỗi tư duy của mình rằng nó có thông tin về ghi chú phát hành nêu chi tiết các thay đổi đối với cơ sở mã và xác định chính xác rằng tham số 'edit_only' đã được giới thiệu trong Django 4.1.

GPT‑5.2 CoT

Văn bản thuần túy

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.

Để đánh giá mức độ rò rỉ dữ liệu một cách tổng quát hơn, chúng tôi đã tạo ra một hệ thống kiểm thử đội đỏ (red team) tự động. Đối với mỗi câu hỏi đã được xác minh trên SWE-bench, chúng tôi đã giao nhiệm vụ cho GPT‑5 để kiểm tra GPT‑5.2‑Chat, Claude Opus 4.5 và Gemini 3 Flash Preview cho rò rỉ dữ liệu. Các mô hình này được lựa chọn để loại trừ các mô hình suy luận, nhưng chúng tôi thừa nhận rằng có thể tồn tại một khoảng cách năng lực đáng kể giữa chúng.

Để kiểm tra tình trạng rò rỉ dữ liệu, GPT‑5 đã nhận được: ID, mô tả, bản vá lỗi chuẩn và các bài kiểm tra PR của tác vụ đã được xác minh bởi SWE-bench. Hơn 15 lượt, chúng tôi cho phép GPT‑5 thay đổi lời nhắc hệ thống/nhà phát triển, lời nhắc người dùng và điền sẵn trợ lý và các chiến lược gợi ý khác nhau. Sau mỗi lượt, một mô hình thẩm phán dán nhãn có bao nhiêu thông tin mới về nhiệm vụ cụ thể xuất hiện và mỗi phản hồi được gắn nhãn mức độ nghiêm trọng của rò rỉ dữ liệu từ “không có” đến “mạnh”. GPT‑5 được phép điều chỉnh chiến lược của mình dựa trên các lượt chơi trước đó để khôi phục lặp đi lặp lại các chi tiết cụ thể của nhiệm vụ. Đối với mỗi trường hợp rò rỉ dữ liệu mạnh, chúng tôi đã xác minh với một người đánh giá khác rằng GPT‑5 không làm rò rỉ quá nhiều thông tin cho mô hình mục tiêu. Cuối cùng, sau đó chúng tôi đã xem xét thủ công các ví dụ “mạnh mẽ” tạo nên bảng điểm trong bài đăng này.

Dưới đây là các ví dụ về sự rò rỉ dữ liệu mạnh mẽ giữa các nhà cung cấp mô hình khác nhau.

GPT‑5.2

Với một đoạn trích ngắn từ mô tả tác vụ, GPT‑5.2 xuất ra chính xác bản vá gold. Đặc biệt, nó biết chính xác tên lớp và phương thức, và điều kiện trả về sớm mới `nếu tên người dùng là Không có hoặc mật khẩu là None` được giới thiệu.

ID tác vụ: django__django-11451⁠(mở trong cửa sổ mới)

Khơi gợi rò rỉ dữ liệu

Trình bày vấn đề

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

Lời nhắc của người dùng

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"

Phản hồi của mô hình

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.

Bản vá vàng

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 không chỉ có thể nhớ lại sự thay đổi chức năng 4 dòng chính xác mà PR đã giới thiệu, cùng với tên tệp và phương thức cụ thể mà nó chạm vào, mà còn trích dẫn nguyên văn nhận xét nội tuyến là một phần của diff.

ID tác vụ: astropy__astropy-13236⁠(mở trong cửa sổ mới)

Khơi gợi rò rỉ dữ liệu

Câu lệnh người dùng

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.

Điền sẵn

1Let me be precise about the location and wording.

Phản hồi của trợ lý

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

Bản vá vàng

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, khi không được cung cấp thêm thông tin liên quan đến nhiệm vụ ngoài ID, có thể xuất các chi tiết nguyên văn từ mô tả nhiệm vụ và bản vá vàng. Điều này bao gồm công thức regex mới để xác thực tên người dùng và số dòng chính xác cho thay đổi.

ID tác vụ: django__django-11099⁠(mở trong cửa sổ mới)

Khơi gợi rò rỉ dữ liệu

Trình bày vấn đề

1UsernameValidator allows trailing newline in usernames

Lời nhắc của người dùng

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.

Điền sẵn

1Let me be precise about the wording.

Phản hồi của mô hình

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

Bản vá vàng

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

Thảo luận

Từ cuộc kiểm toán SWE-bench Verified này, chúng tôi thấy hai bài học rộng hơn cho thiết kế đánh giá. Đầu tiên, các điểm chuẩn có nguồn gốc từ tài liệu có sẵn công khai có nguy cơ rò rỉ dữ liệu, trong đó việc tiếp xúc với dữ liệu đào tạo có thể âm thầm thổi phồng điểm số. Nếu dữ liệu được thu thập công khai được sử dụng trong việc xây dựng mô hình chuẩn, các nhà phát triển mô hình nên thực hiện thêm các thử nghiệm để kiểm tra sự sai lệch. Điểm chuẩn, và thậm chí các giải pháp của họ, được đăng công khai có thể kết thúc trong dữ liệu đào tạo. Cần hết sức cẩn trọng cả trong cách đăng tải các bộ dữ liệu (ví dụ: được bảo vệ bằng mật khẩu) và lọc dữ liệu đào tạo (tức là tuân thủ nghiêm ngặt các chuỗi canary).

Thứ hai, việc chấm điểm tự động rất khó để thực hiện chính xác; các trường hợp kiểm thử hoàn hảo cần phải xác minh đầy đủ chức năng chính xác, vừa không quan tâm đến các chi tiết triển khai không quan trọng, vừa phải đủ mạnh mẽ để chống lại các giải pháp rút gọn. Những vấn đề này vốn dĩ rất phức tạp và khó giải quyết. Việc phát hiện ra những vấn đề này đòi hỏi nhiều chiến dịch dán nhãn thủ công quy mô lớn.

Chúng tôi đã kết hợp những phát hiện này vào các nỗ lực đánh giá gần đây của chúng tôi. Trong những tháng qua, chúng tôi đã chọn báo cáo kết quả từ việc chia tách công khai của SWE-Bench Pro. Chúng tôi khuyên các nhà phát triển mô hình khác làm tương tự. SWE-bench Pro không hoàn hảo, nhưng theo kinh nghiệm thực tế thì nó ít bị ảnh hưởng bởi các vấn đề rò rỉ dữ liệu hơn. Quy trình phát hiện rò rỉ dữ liệu của chúng tôi đã tìm thấy một số trường hợp rò rỉ dữ liệu, nhưng các trường hợp này hiếm hơn đáng kể và ít nghiêm trọng hơn so với SWE-bench Verified, và không có mô hình nào có thể tạo ra một verbatim gold patch hoàn chỉnh.

Chúng tôi sẽ tiếp tục đầu tư vào các tiêu chuẩn đánh giá độc đáo, do tư nhân tự biên soạn và kêu gọi sự hỗ trợ từ ngành công nghiệp và giới học thuật để cùng thực hiện điều tương tự. Tại GDPVal⁠, các nhiệm vụ được soạn thảo riêng bởi các chuyên gia trong lĩnh vực đó, giảm thiểu rủi ro bị lộ thông tin, và các giải pháp được đánh giá toàn diện bởi các chuyên gia được đào tạo. Phương pháp này tốn nhiều nguồn lực, nhưng ngày càng cần thiết để đo lường những cải thiện năng lực thực sự.

2026

Tác giả

OpenAI

Hãy tiếp tục xem

Xem tất cả

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Nghiên cứu4 thg 6, 2026

Giới thiệu các năng lực mới của GPT-Rosalind

Sản phẩm3 thg 6, 2026

Tăng cường khả năng phục hồi xã hội với Rosalind Biodefense

Sản phẩm29 thg 5, 2026