۴ اسفند ۱۴۰۴

چرا SWE-bench Verified به اندازه گیری توانمندی‌های کدنویسی در سطح پیشرفته ادامه نمی دهد

SWE-bench Verified به‌طور فزاینده‌ای آلوده می‌شود. ما SWE-bench Pro را توصیه می‌کنیم.

در حال بارگذاری…

از زمانی که ما برای نخستین بار SWE-bench Verified را در اوت 2024 منتشر کردیم، صنعت به‌طور گسترده از آن برای سنجش پیشرفت مدل‌ها در وظایف مهندسی نرم‌افزار خودمختار استفاده کرده است. پس از انتشار آن، SWE-bench Verified سیگنال قدرتمندی از پیشرفت قابلیت‌ها ارائه کرد و به یک معیار استاندارد تبدیل شد که در انتشارهای مدل‌های پیشرو گزارش می‌شود. همچنین ردیابی و پیش‌بینی پیشرفت این قابلیت‌ها بخش مهمی از چارچوب آمادگی OpenAI است. وقتی در ابتدا معیار Verified را ایجاد کردیم، تلاش کردیم مشکلاتی را در ارزیابی اصلی حل کنیم که انجام برخی وظایف را در SWE-bench dataset⁠(در یک پنجره جدید باز می‌شود) غیرممکن می‌کرد.

پس از جهش‌های اولیه، پیشرفت در سطح پیشرفته‌ترین عملکرد در SWE-bench Verified کند شده و طی 6 ماه گذشته از 74.9٪ به 80.9٪ افزایش یافته است⁠(در یک پنجره جدید باز می‌شود). این موضوع این پرسش را مطرح می‌کند: آیا خطاهای باقی‌مانده ناشی از محدودیت‌های مدل هستند یا به ویژگی‌های خودِ مجموعه‌داده مربوط می‌شوند؟

در یک تحلیل جدید، دو مسئلهٔ عمده در مجموعهٔ Verified یافتیم که نشان می‌دهد این معیار دیگر برای سنجش پیشرفت در توانمندی‌های مهندسی نرم‌افزار خودمختار برای نسخه‌های پیشرو در سطوح عملکردی امروز مناسب نیست:

آزمون‌ها راه‌حل‌های صحیح را رد می‌کنند: ما 27.6٪ از مجموعه‌داده را که مدل‌ها اغلب در حل آن ناکام می‌ماندند ممیزی کردیم و دریافتیم که دست‌کم 59.4٪ از مسائلِ بررسی‌شده دارای موارد آزمونِ معیوب هستند که با وجود صحیح بودن عملکردی، ارسال‌ها را رد می‌کنند، این در حالی است که در مرحلهٔ ایجاد اولیهٔ SWE-bench Verified تمام تلاش خود را برای بهبود این موارد به کار گرفته بودیم.
آموزش با استفاده از راه‌حل‌ها: از آنجا که مدل‌های پیشروِ بزرگ می‌توانند اطلاعات را از آموزش خود یاد بگیرند، مهم است که هرگز روی مسائل و راه‌حل‌هایی که با آن‌ها ارزیابی می‌شوند آموزش داده نشوند. این موضوع شبیه به این است که قبل از آزمون، مسائل و راه‌حل‌ها را برای یک آزمونِ پیشِ رو با دانش‌آموزان به اشتراک بگذارید - شاید پاسخ را حفظ نکنند، اما دانش‌آموزانی که قبلاً پاسخ‌ها را دیده‌اند قطعاً بهتر از کسانی که ندیده‌اند عمل خواهند کرد. مسائل SWE-bench از محل نگهداری‌های منبع‌باز تهیه می‌شوند که بسیاری از ارائه‌دهندگان مدل برای اهداف آموزشی از آن‌ها استفاده می‌کنند. در تحلیل خود دریافتیم که تمامی مدل‌های پیشرو که آزمایش کردیم قادر بودند اصلاحِ باگِ اصلیِ نوشته‌شده توسط انسان که به‌عنوان مرجع حقیقتِ مبنا و با نام بخش طلایی شناخته می‌شود، یا جزئیاتِ دقیقِ صورت‌مسئله برای برخی وظایف را بازتولید کنند، این امر نشان می‌دهد که همهٔ آن‌ها دست‌کم با بخشی از مسائل و راه‌حل‌ها در فرایند آموزش مواجه شده‌اند.

همچنین شواهدی یافتیم که نشان می‌دهد مدل‌هایی که این مسائل را در طول آموزش دیده‌اند، احتمال موفقیت بیشتری دارند، زیرا اطلاعات اضافیِ لازم برای گذراندن آزمون‌های کمتر شناخته شده را در اختیار دارند.

این بدان معناست که بهبودها در SWE-bench Verified دیگر بازتاب‌دهندهٔ بهبودهای معنادار در توانایی‌های توسعهٔ نرم‌افزار دنیای واقعیِ مدل‌ها نیستند. در عوض، آن‌ها به‌طور فزاینده‌ای بازتاب‌دهندهٔ این هستند که مدل در زمان آموزش تا چه اندازه در معرض معیار سنجش قرار گرفته است. به همین دلیل است که ما گزارش امتیازهای SWE-bench Verified را متوقف کرده‌ایم و توصیه می‌کنیم سایر توسعه‌دهندگان مدل نیز همین کار را انجام دهند.

ما در حال ساخت ارزیابی‌های جدید و عاری از آلودگی هستیم تا توانایی‌های کدنویسی را بهتر ردیابی کنیم، و فکر می‌کنیم این حوزه برای تمرکز جامعه پژوهشی گسترده‌تر مهم است. تا زمان فراهم شدن این ارزیابی‌ها، OpenAI توصیه می‌کند نتایج را برای SWE-bench Pro گزارش کنید.

پس‌زمینه

ارزیابی اصلی SWE-bench⁠(در یک پنجره جدید باز می‌شود) در سال 2023 منتشر شد. هر مسئله از یک issue حل‌شده GitHub در یکی از 12 محل نگهداری متن‌باز پایتون تهیه شده و با pull request (PR) متناظر جفت شده است. برای تعیین این‌که آیا تغییری که مدل در کد ایجاد کرده صحیح است یا خیر، هر مسئله با دو مجموعه آزمون ارائه می‌شود:

آزمون‌هایی که روی پایگاه کدِ بدون تغییر با شکست مواجه می‌شوند، در صورت رفع صحیح مسئله، با موفقیت اجرا می‌شوند
آزمون‌های رگرسیون که هم پیش از اصلاح و هم پس از آن با موفقیت اجرا می‌شوند تا اطمینان حاصل شود که قابلیت‌های نامرتبط بدون تغییر باقی مانده‌اند.

مدل به تست‌ها دسترسی ندارد. مدل باید تنها بر اساس متن اصلیِ مسئله و وضعیت محل نگهداری پیش از اعمال اصلاح، یک تغییر در کد ایجاد کند. یک مسئله تنها زمانی پذیرفته می‌شود که پس از اعمال تغییرِ کد، همهٔ آزمون‌ها با موفقیت اجرا شوند.

ما در آن شیوهٔ ارزیابی مشکلات متعددی یافتیم که می‌توانند باعث شوند توانایی مدل‌ها کمتر از واقع نشان داده شود.

برخی از تست‌های واحد بیش از حد خاص بودند یا با وظیفه ناهمسو بودند، بنابراین ممکن بود اصلاحات درست رد شوند.
بسیاری از صورت‌مسئله‌ها به‌طور کامل مشخص نشده بودند، که می‌توانست به چندین تفسیر معتبر منجر شود — در حالی‌ که تست‌ها تنها یکی از آن‌ها را پوشش می‌دادند.
بسته به پیکربندی محیط (برای مثال لینوکس در مقابل ویندوز، یا نسخه پایتون)، ممکن است برخی تست‌ها به‌طور کاذب شکست بخورند

ما SWE-bench Verified را در سال 2024 ایجاد کردیم تا به این مسائل رسیدگی کنیم. ما با مهندسان نرم‌افزار خبره همکاری کردیم تا 1699 مسئله SWE-bench را بررسی کنیم و مسئله‌هایی که این مشکلات را داشتند فیلتر کنیم. هر مسئله به‌طور مستقل توسط سه کارشناس بررسی شد. این فرایند بازبینی به ایجاد SWE-bench Verified، مجموعه‌ای گزینش‌شده شامل 500 مسئله، منجر شد.

آزمون‌های بسیار محدود و بسیار گسترده

اگرچه SWE-bench Verified نسبت به نسخه اولیه پیشرفت چشمگیری محسوب می‌شود، اما همچنان برخی مشکلات باقی مانده‌اند. ما 138 مسئله از مجموعهٔ SWE-bench Verified را که مدل OpenAI o3 در 64 اجرای مستقل نتوانسته بود به‌طور پایدار حل کند، مورد ممیزی (بازبینی) قرار دادیم. هر مورد به‌طور مستقل توسط دست‌کم شش مهندس نرم‌افزار باتجربه بررسی شد. اگر یک کارشناس مشکلی را علامت‌گذاری کرده بود، توسط یک تیم اضافی مجدداً تأیید شد.

دریافتیم که 59.4٪ از 138 مسئله دارای اشکالات اساسی در طراحی آزمون و/یا شرح مسئله بودند، اشکالاتی که حل آن‌ها را حتی برای توانمندترین مدل‌ها یا انسان‌ها بسیار دشوار یا ناممکن می‌ساخت.

35.5% از وظایف ممیزی‌شده دارای موارد آزمون سخت‌گیرانه‌ای هستند که جزئیات پیاده‌سازی مشخصی را تحمیل می‌کنند و بسیاری از ارسال‌های از نظر عملکردی درست را نامعتبر می‌سازند، که ما آن‌ها را موارد آزمون محدودمی‌نامیم.
18.8٪ از وظایف ممیزی‌شده تست‌هایی دارند که وجود قابلیت‌های اضافی‌ای را بررسی می‌کنند که در شرح مسئله مشخص نشده بود، که ما آن‌ها را موارد آزمون گستردهمی‌نامیم.
5.1٪ باقی‌مانده از وظایف، مشکلات متفرقه‌ای داشتند که در این گروه بندی به‌خوبی جای نمیگرفتند.

یک نمونه توضیحی از نخستین حالت خرابی pylint-dev__pylint-4551⁠(در یک پنجره جدید باز می‌شود) است، که در آن PR به‌عنوان بخشی از راه‌حل کلی، یک تابع جدید به نام «get_annotation» معرفی می‌کند. این نام تابع در توضیحات مسئله ذکر نشده است، اما مستقیماً توسط تست‌ها وارد می‌شود. اگرچه برخی مدل‌ها ممکن است به‌صورت شهودی چنین تابعی را ایجاد کنند، اما برای حل صحیح مسئله، پیاده‌سازی تابعی با این نام مشخص الزاماً ضروری نیست. بسیاری از راه‌حل‌های معتبر به‌دلیل خطاهای import در آزمون‌ها رد می‌شوند.

توضیح مسئله

متن ساده

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

قطعه آزمایشی PR

Python

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

شکست‌های تست PR (برای خوانایی مختصر شده است)

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)

یک نمونه از موارد آزمونِ بیش از حد گسترده sympy__sympy-18199⁠(در یک پنجره جدید باز می‌شود) است. این وظیفه از یک PR منشأ گرفته است که به سه مسئلهٔ متمایز در تابع «nthroot_mod» پرداخته بود، به‌طور مشخص شماره 17373⁠(در یک پنجره جدید باز می‌شود)، شماره 17377⁠(در یک پنجره جدید باز می‌شود)، و شماره 18212⁠(در یک پنجره جدید باز می‌شود). با این حال، شرح وظیفه SWE-bench Verified فقط مسئله نهایی شماره 18212⁠(در یک پنجره جدید باز می‌شود) را پوشش می‌دهد. این باعث ایجاد یک عدم‌تطابق می‌شود: تست‌های PR هر سه مسئله را پوشش می‌دهند، در حالی که توضیحات فقط یکی را با جزئیات بیان می‌کند. در اجراهای ما، مدل‌ها اغلب اصلاح توصیف‌شده را به‌درستی پیاده‌سازی می‌کنند و سپس در تست‌هایی که پیاده‌سازیِ دو مسئله دیگر را پوشش می‌دهند شکست می‌خورند.

توضیحات اصلی PR (از PR گیت‌هاب)

متن ساده

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

توضیح مشکل برای شماره 18212

متن ساده

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.

شرح مسئله برای وظیفه SWE-bench Verified (فقط برگرفته از #18212):

متن ساده

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.

آلودگی

SWE-bench Verified و محل نگهداری‌ها (پایگاه‌های کد و یادداشت‌های انتشار) هر دو متن‌باز هستند و به‌طور گسترده استفاده و درباره‌شان بحث می‌شود، که این موضوع اجتناب از آلودگی را برای توسعه‌دهندگان مدل دشوار می‌کند.

ما نخستین بار نشانه‌های آلودگی را در مدل‌های خودمان مشاهده کردیم. برای مثال، زمانی که GPT‑5.2 موفق به حل 31 وظیفه‌ای شد که ما آن‌ها را تقریباً غیرقابل‌حل تشخیص داده بودیم. در django__django-14725⁠(در یک پنجره جدید باز می‌شود) تست‌ها به یک پارامتر جدید مشخص به نام «edit_only» نیاز دارند که به‌طور صریح توسط بیانیه مسئله الزامی نشده است. در حین حل مسئله، GPT‑5.2 در زنجیره تفکر خود نشان می‌دهد که درباره یادداشت‌های انتشار که تغییرات در پایگاه کد را شرح می‌دهند اطلاعات دارد و به‌درستی تشخیص می‌دهد که پارامتر «edit_only» در Django 4.1 معرفی شده است.

GPT‑5.2 CoT

متن ساده

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.

برای ارزیابی گسترده‌تر میزان اهمیت آلودگی داده‌ای، یک چارچوب خودکار ردتیمینگ طراحی کردیم. برای هر پرسش SWE-bench Verified، از GPT‑5 خواستیم تا یک GPT‑5.2‑Chat را مورد بررسی قرار دهد، Claude Opus 4.5 و Gemini 3 Flash Preview برای بررسی آلودگی. این مدل‌ها برای کنار گذاشتن مدل‌های استدلال انتخاب شدند، اما اذعان می‌کنیم که احتمالاً شکاف توانمندی قابل‌توجهی بین آن‌ها وجود دارد.

برای بررسی احتمال آلودگی داده‌ای، موارد زیر در اختیار GPT‑5 قرار گرفت: شناسهٔ وظیفه در SWE-bench Verified، شرح مسئله، به‌روزرسانی نهایی بخش طلایی و تست‌های PR. در طول ۱۵ نوبت تعامل، به GPT‑5 اجازه دادیم اعلانِ سیستم/توسعه‌دهنده، اعلانِ کاربر، متن پیش‌فرض دستیار و همچنین راهبردهای مختلف استخراج را تغییر دهد. پس از هر نوبت، یک مدل داور برچسب‌گذاری کرد که چه مقدار اطلاعات جدیدِ خاصِ وظیفه ظاهر شده است و هر پاسخ از نظر شدت آلودگی از «none» تا «strong» برچسب‌گذاری شد. به GPT‑5 اجازه داده شد تا بر اساس نوبت‌های قبلی راهبرد خود را تطبیق دهد تا به‌صورت تکرارشونده جزئیات خاصِ وظیفه را بازیابی کند. برای هر نمونه از آلودگی شدید، با یک داور دیگر بررسی کردیم که GPT‑5 اطلاعات زیادی را به مدل هدف نشت نداده باشد. در نهایت، سپس نمونه‌های «قوی» را که رونوشت‌های این پست را تشکیل می‌دهند، به‌صورت دستی بازبینی کردیم.

در زیر نمونه‌هایی از آلودگی شدید در میان ارائه‌دهندگان مختلف مدل آمده است.

GPT‑5.2

با توجه به یک قطعه کوتاه از توضیحات وظیفه، GPT‑5.2 دقیقاً بخش طلایی را ارائه می‌دهد. به‌طور مشخص، این مدل نام دقیق کلاس و متد، و همچنین شرط بازگشت زودهنگام جدید یعنی «if username is None or password is None» را که اضافه شده است، می‌شناسد.

شناسهٔ کار: django__django-11451⁠(در یک پنجره جدید باز می‌شود)

استخراج آلودگی

بیان مسئله

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

پیام کاربر

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"

پاسخ مدل

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.

بخش طلایی

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 نه‌تنها قادر است تغییر عملکردی دقیقِ 4 خطی‌ای را که در PR اعمال شده، به‌همراه نام دقیق فایل و متدی که تحت تأثیر قرار گرفته‌اند به یاد آورد، بلکه حتی توضیح درون‌خطی موجود در diff را نیز عیناً نقل می‌کند.

شناسه کار: astropy__astropy-13236⁠(در یک پنجره جدید باز می‌شود)

استخراج آلودگی

اعلان کاربر

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.

پیش‌پردازش ورودی

1Let me be precise about the location and wording.

پاسخ دستیار

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

بخش طلایی

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، حتی زمانی که به‌جز شناسهٔ مسئله هیچ اطلاعات دیگری دربارهٔ آن دریافت نمی‌کند، قادر است جزئیاتِ موجود در شرحِ مسئله و بخش طلایی را عیناً بازتولید کند. این شامل فرمول regex جدید برای اعتبارسنجی نام کاربری و شماره خطوط دقیق برای این تغییر است.

شناسهٔ کار: django__django-11099⁠(در یک پنجره جدید باز می‌شود)

استخراج آلودگی

بیان مسئله

1UsernameValidator allows trailing newline in usernames

پیام کاربر

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.

پیش‌پردازش ورودی

1Let me be precise about the wording.

پاسخ مدل

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

بخش طلایی

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

بحث

از این ممیزیِ SWE-bench Verified، دو درس کلی‌تر برای طراحی ارزیابی می‌بینیم. ابتدا، معیار‌هایی که از مطالب عمومیِ در دسترس تهیه شده‌اند، با خطر آلودگی همراه‌اند، زیرا مواجهه با داده‌های آموزشی می‌تواند بی‌سروصدا امتیازها را به‌طور مصنوعی افزایش دهد. اگر در ساخت معیار از داده‌های عمومیِ گردآوری‌شده از وب استفاده شود، توسعه‌دهندگان مدل باید آزمون‌های بیشتری برای بررسی آلودگی داده انجام دهند. معیار‌ها، و حتی راه‌حل‌های آن‌ها، که به‌صورت عمومی منتشر می‌شوند ممکن است سر از داده‌های آموزشی دربیاورند. باید هم در نحوهٔ انتشار مجموعه‌داده‌ها (مثلاً با محافظت رمزعبور) و هم در پالایش داده‌های آموزشی (مانند پایبندیِ سخت‌گیرانه به رشته‌های کَنَری) دقت ویژه‌ای به‌کار گرفته شود.

دوم اینکه، طراحی امتیازدهی خودکار به‌درستی کار ساده‌ای نیست؛ موارد آزمون ایده‌آل باید به‌طور کامل درستی عملکرد را تأیید کنند، در عین حال نسبت به جزئیات غیرمهمِ پیاده‌سازی بی‌طرف باشند و در برابر راه‌حل‌های میان‌بُر نیز مقاوم عمل کنند. این مسائل ذاتاً پیچیده‌اند و حل آن‌ها دشوار است. شناسایی این مشکلات مستلزم چندین کارزار گسترده برچسب‌گذاری انسانی بود.

ما این یافته‌ها را در تلاش‌های اخیر ارزیابی خود گنجانده‌ایم. در ماه‌های اخیر تصمیم گرفته‌ایم نتایج مربوط به بخش عمومی SWE-Bench Pro را گزارش کنیم. توصیه می‌کنیم سایر توسعه‌دهندگان مدل نیز همین کار را انجام دهند. SWE-bench Pro بی‌نقص نیست، اما بر اساس شواهد تجربی به نظر می‌رسد کمتر با مشکلات آلودگی داده‌ای مواجه باشد. خط لولهٔ شناسایی آلودگی ما برخی موارد آلودگی را شناسایی کرد، اما این موارد در مقایسه با SWE-bench Verified به‌مراتب نادرتر و خفیف‌تر بودند، و هیچ مدلی نتوانست یک بخش طلایی کامل را به‌صورت عیناً بازتولید کند.

ما به سرمایه‌گذاری در معیار‌های اصیل و تألیف‌شده به‌صورت خصوصی ادامه خواهیم داد و از صنعت و جامعه دانشگاهی نیز خواهیم خواست که در این مسیر همراه شوند. در GDPVal⁠، وظایف به‌صورت خصوصی توسط متخصصان حوزه تدوین می‌شوند که این امر ریسک افشا یا در معرض قرار گرفتن را کاهش می‌دهد، و راه‌حل‌ها نیز به‌صورت جامع توسط ارزیابان آموزش‌دیده نمره‌دهی می‌شوند. این رویکرد منابع زیادی می‌طلبد، اما برای سنجش بهبودهای واقعیِ قابلیت‌ها به‌طور فزاینده‌ای ضروری است.

۲۰۲۶

نویسنده

OpenAI

به خواندن ادامه بده

مشاهده همه

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

تحقیق۱۴ خرداد ۱۴۰۵

معرفی قابلیت‌های جدید برای GPT-Rosalind

محصول۱۳ خرداد ۱۴۰۵

تقویت تاب‌آوری اجتماعی با Rosalind Biodefense

محصول۸ خرداد ۱۴۰۵