2026 оны хоёрдугаар сарын 23

Яагаад SWE-bench Verified нь хил хязгаар кодчиллын чадамжийг дахин хэмжихгүй болсон бэ

SWE-bench Verified улам бүр бохирдож байна. Бид SWE-bench Pro-г зөвлөж байна.

Ачаалж байна…

Бид SWE-bench Verified-ийг 2024 оны 8-р сард анх нийтэлснээс хойш салбарынхан үүнийг автоном програм хангамжийн инженерчлэлийн даалгаврууд дээрх загваруудын ахицыг хэмжихэд өргөн ашиглаж ирсэн. Гарсны дараа SWE-bench Verified нь чадамжийн ахицын хүчтэй дохио өгч, хил хязгаар загварын нээлтүүдэд тайлагнадаг стандарт хэмжүүр болсон. Эдгээр чадамжийн ахицыг хянах, таамаглах нь мөн OpenAI-ийн Preparedness Framework-ийн чухал хэсэг юм. Бид Verified жишиг үзүүлэлтийг анх бүтээхдээ эх үнэлгээнд байсан, SWE-bench dataset⁠(шинэ цонхонд нээгдэнэ) дэх зарим даалгаврыг биелүүлэх боломжгүй болгодог асуудлуудыг шийдэхийг оролдсон.

Эхний үсрэнгүй ахицын дараа SWE-bench Verified дээрх хамгийн шилдэг гүйцэтгэлийн ахиц саарч, сүүлийн 6 сард 74.9%-аас 80.9% хүртэл сайжирсан⁠(шинэ цонхонд нээгдэнэ). Энэ нь дараах асуултыг гаргаж байна: үлдсэн бүтэлгүйтлүүд нь загварын хязгаарлалтыг тусгаж байна уу, эсвэл өгөгдлийн багцын өөрийн шинж чанарыг уу?

Шинэ шинжилгээгээр бид Verified багцад хоёр том асуудал байгааг олсон бөгөөд эдгээр нь өнөөгийн гүйцэтгэлийн түвшинд хил хязгаар нээлтүүдийн автоном програм хангамжийн инженерчлэлийн чадамжийн ахицыг хэмжихэд энэ жишиг үзүүлэлт тохирохоо больсныг харуулж байна:

Тестүүд зөв шийдлийг буцаадаг: Бид загварууд ихэвчлэн шийдэж чадаагүй өгөгдлийн багцын 27.6%-ийн дэд хэсгийг аудит хийж, аудитлагдсан асуудлуудын дор хаяж 59.4%-д нь функциональ хувьд зөв илгээмжийг буцаадаг алдаатай тестийн тохиолдлууд байгааг олсон. Энэ нь SWE-bench Verified-ийг анх бүтээхдээ үүнийг сайжруулахын тулд хамгийн их хичээсэн ч гэсэн хэвээр байв.
Шийдлүүд дээр сургалт хийсэн: Том хил хязгаар загварууд сургалтаасаа мэдээлэл сурч чаддаг тул тэднийг үнэлж буй асуудал, шийдлүүд дээр нь хэзээ ч сургаагүй байх нь чухал. Энэ нь шалгалтын өмнө сурагчдад удахгүй болох шалгалтын бодлого, шийдлийг өгч байгаатай адил — тэд хариуг цээжлэхгүй байж болох ч өмнө нь хариуг харсан сурагчид хараагүйгээсээ илүү сайн хийх нь гарцаагүй. SWE-bench-ийн асуудлууд нь олон загвар нийлүүлэгч сургалтын зорилгоор ашигладаг нээлттэй эхийн репозитороос авсан. Бидний шинжилгээнд туршсан бүх хил хязгаар загварууд ground-truth лавлагаа болгон ашигласан, gold patch гэж нэрлэдэг хүний бичсэн анхны алдааны засварыг, эсвэл зарим даалгаврын хувьд асуудлын тайлбарын үгчлэн нарийн мэдээллийг сэргээж чадсан нь тэд бүгд сургалтын явцад дор хаяж зарим асуудал, шийдлийг харсан гэдгийг харуулж байна.

Мөн сургалтын явцад асуудлуудыг харсан загварууд дутуу тодорхойлогдсон тестүүдийг давахад хэрэгтэй нэмэлт мэдээлэлтэй байдаг тул амжилттай байх магадлал өндөр гэдгийг нотлох баримт бид олсон.

Энэ нь SWE-bench Verified дээрх сайжруулалтууд загваруудын бодит ертөнцийн програм хангамж хөгжүүлэх чадварын утга учиртай сайжруулалтыг дахин тусгахаа больсон гэсэн үг. Харин тэдгээр нь сургалтын үед загвар жишиг үзүүлэлтэд хэр их өртсөнийг улам бүр тусгаж байна. Тиймээс бид SWE-bench Verified оноог тайлагнахаа больсон бөгөөд бусад загвар хөгжүүлэгчдэд ч мөн адил хийхийг зөвлөж байна.

Бид кодчиллын чадамжийг илүү сайн хянахын тулд бохирдоогүй шинэ үнэлгээнүүдийг бүтээж байгаа бөгөөд үүнийг өргөн судалгааны нийгэмлэг анхаарах ёстой чухал чиглэл гэж үзэж байна. Тэдгээрийг бэлэн болтол OpenAI нь SWE-bench Pro-ийн үр дүнг тайлагнахыг зөвлөж байна.

Суурь мэдээлэл

Анхны SWE-bench⁠(шинэ цонхонд нээгдэнэ) үнэлгээ 2023 онд гарсан. Асуудал бүр нь 12 нээлттэй эхийн Python репозиторын аль нэг дэх шийдэгдсэн GitHub issue-оос авсан бөгөөд түүнд харгалзах pull request (PR)-тай хослуулсан. Загвараас үүсгэсэн кодын өөрчлөлт зөв эсэхийг тодорхойлохын тулд асуудал бүр хоёр багц тесттэй:

Өөрчлөгдөөгүй кодын суурь дээр бүтэлгүйтдэг боловч асуудлыг зөв засвал амжилттай болдог тестүүд
Хамааралгүй функц хэвээр үлдсэнийг баталгаажуулахын тулд засварын өмнө болон дараа хоёуланд нь амжилттай болдог регрессийн тестүүд.

Загвар тестүүдийг хардаггүй. Түүнд зөвхөн issue-ийн анхны текст болон засварын өмнөх репозиторын төлөв өгөгдөх ба үүн дээр үндэслэн кодын өөрчлөлт гаргах ёстой. Кодын өөрчлөлтийг хэрэгжүүлсний дараа бүх тест амжилттай болсон тохиолдолд л тухайн асуудлыг давсанд тооцно.

Бид энэ үнэлгээнд загваруудын чадамжийг дутуу тайлагнахад хүргэж болох олон асуудал байгааг олсон.

Зарим unit test хэт нарийн эсвэл даалгавартай нийцээгүй байсан тул зөв засварууд ч буцаагдаж болох байв.
Олон даалгаврын тайлбар дутуу тодорхойлогдсон байсан нь олон зөв тайлбарлалтад хүргэж болох ч тестүүд зөвхөн нэг тодорхой хувилбарыг хамарч байсан.
Орчны тохиргооноос (жишээлбэл Linux vs Windows, эсвэл python хувилбар) хамааран зарим тестүүд худал бүтэлгүйтэж болох байв

Бид эдгээр асуудлыг шийдэхийн тулд 2024 онд SWE-bench Verified-ийг бүтээсэн. Бид мэргэжлийн програм хангамжийн инженерүүдтэй хамтран SWE-bench-ийн 1,699 асуудлыг хянаж, дээрх асуудлуудтай бодлогуудыг шүүж хассан. Асуудал бүрийг гурван шинжээч бие даан хянасан. Энэ хяналтын үйл явцын үр дүнд 500 асуудлаас бүрдсэн сонгомол багц болох SWE-bench Verified бий болсон.

Хэт нарийн ба хэт өргөн тестүүд

SWE-bench Verified нь анхны хувилбараасаа ихээхэн сайжирсан ч үлдэгдэл асуудлууд хэвээр байна. OpenAI o3 64 бие даасан ажиллуулалтын турш тогтмол шийдэж чадаагүй 138 SWE-bench Verified асуудалд бид аудит хийсэн. Тохиолдол бүрийг дор хаяж зургаан туршлагатай програм хангамжийн инженер бие даан хянасан. Хэрэв шинжээч асуудал тэмдэглэвэл нэмэлт баг дахин баталгаажуулсан.

Бид 138 асуудлын 59.4%-д нь тестийн загварчлал болон/эсвэл асуудлын тайлбарт ноцтой асуудал байгааг олсон бөгөөд энэ нь хамгийн чадварлаг загвар эсвэл хүнд ч тэдгээрийг шийдэхийг туйлын хэцүү эсвэл боломжгүй болгож байв.

Аудитлагдсан даалгаврын 35.5%-д нь тодорхой хэрэгжүүлэлтийн нарийн ширийнийг шаардаж, функциональ хувьд зөв олон илгээмжийг хүчингүй болгодог хатуу тестийн тохиолдлууд байсан бөгөөд үүнийг бид нарийн тестийн тохиолдол гэж нэрлэдэг.
Аудитлагдсан даалгаврын 18.8%-д нь асуудлын тайлбарт заагаагүй нэмэлт функцийг шалгадаг тестүүд байсан бөгөөд үүнийг бид өргөн тестийн тохиолдол гэж нэрлэдэг.
Үлдсэн 5.1% даалгаварт энэ ангилалд сайн багтаагүй бусад төрлийн асуудлууд байсан.

Эхний алдааны горимын нэг тод жишээ нь pylint-dev__pylint-4551⁠(шинэ цонхонд нээгдэнэ) бөгөөд энд PR нь ерөнхий шийдлийн нэг хэсэг болгон `get_annotation` нэртэй шинэ функц нэвтрүүлдэг. Энэ функцийн нэр асуудлын тайлбарт дурдаагүй боловч тестүүд үүнийг шууд import хийдэг. Зарим загварууд ийм функц үүсгэхийг зөнгөөрөө тааж болох ч асуудлыг зөв шийдэхийн тулд заавал энэ нэртэй функц хэрэгжүүлэх шаардлагагүй. Олон хүчинтэй шийдэл 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⁠(шинэ цонхонд нээгдэнэ) юм. Энэ даалгавар нь `nthroot_mod` функцтэй холбоотой тус тусдаа гурван асуудлыг шийдсэн PR-ээс авсан бөгөөд тухайлбал #17373⁠(шинэ цонхонд нээгдэнэ), #17377⁠(шинэ цонхонд нээгдэнэ), болон #18212⁠(шинэ цонхонд нээгдэнэ). Харин SWE-bench Verified даалгаврын тайлбар нь зөвхөн сүүлийн асуудал болох #18212⁠(шинэ цонхонд нээгдэнэ)-ыг л хамардаг. Энэ нь зөрүү үүсгэдэг: PR тестүүд гурван асуудлыг бүгдийг хамардаг бол тайлбар нь зөвхөн нэгийг нь дэлгэрүүлдэг. Бидний ажиллуулалтаар загварууд тайлбарласан засварыг зөв хэрэгжүүлээд дараа нь бусад хоёр асуудлын хэрэгжүүлэлтийг хамарсан тестүүд дээр унадаг байсан.

PR-н анхны тайлбар (GitHub 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 өөрийн chain of thought дотор кодын санд орсон өөрчлөлтийг тайлбарласан release notes-ийн талаар мэдээлэлтэйгээ харуулж, `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.

Бохирдол илүү өргөн хүрээнд хэр ач холбогдолтойг үнэлэхийн тулд бид автомат red-teaming орчин бүтээсэн. SWE-bench Verified асуулт бүрийн хувьд GPT‑5‑ыг GPT‑5.2‑Chat, Claude Opus 4.5, болон Gemini 3 Flash Preview загваруудад бохирдлыг илрүүлэхээр туршилт хийлгэсэн. Эдгээр загваруудыг сэтгэн бодох загваруудыг хасахын тулд сонгосон боловч тэдний хооронд үл тоомсорлож болохгүй чадамжийн зөрүү байгаа гэдгийг бид хүлээн зөвшөөрч байна.

Бохирдлыг шалгахын тулд GPT‑5 дараахыг авсан: SWE-bench Verified даалгаврын ID, тайлбар, gold patch, болон PR тестүүд. 15 ээлжийн турш GPT‑5‑д system/developer өгөгдөл, user өгөгдөл, assistant prefill, мөн өөр өөр илрүүлэх стратегийг өөрчлөх боломж олгосон. Ээлж бүрийн дараа шүүгч загвар даалгаварт өвөрмөц шинэ мэдээлэл хэр их гарсныг тэмдэглэж, хариулт бүрийг “байхгүй”-гээс “хүчтэй” хүртэл бохирдлын түвшнээр шошголсон. GPT‑5‑д өмнөх ээлжүүдэд тулгуурлан стратегиа өөрчилж, даалгаварт өвөрмөц нарийн мэдээллийг давтан сэргээх боломж олгосон. Хүчтэй бохирдлын жишээ бүрийн хувьд GPT‑5 зорилтот загварт хэт их мэдээлэл алдаагүй эсэхийг өөр шүүгчээр баталгаажуулсан. Эцэст нь энэ нийтлэл дэх бичвэрүүдийг бүрдүүлж буй “хүчтэй” жишээнүүдийг бид гараар хянасан.

Доор өөр өөр загвар нийлүүлэгчдийн хүчтэй бохирдлын жишээнүүдийг үзүүлэв.

GPT‑5.2

Даалгаврын тайлбараас авсан богино хэсгийг өгөхөд GPT‑5.2 яг gold patch-ийг гаргаж байна. Тэр дундаа яг class болон method-ийн нэрийг, мөн шинээр нэмэгдсэн `if username is None or password is None` гэсэн эрт буцах нөхцөлийг мэдэж байна.

Даалгаврын ID: 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.

Gold patch

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 нь PR-ээр нэвтрүүлсэн яг 4 мөрийн функциональ өөрчлөлт, хүрсэн тодорхой файлын нэр болон method-ийг санахаас гадна diff-ийн нэг хэсэг байсан inline comment-ийг хүртэл үгчлэн иш татаж чаддаг.

Даалгаврын ID: 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

Gold patch

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 нь даалгаврын талаар ID-гаас өөр мэдээлэл өгөөгүй байхад даалгаврын тайлбар болон gold patch-ээс үгчлэн дэлгэрэнгүй мэдээлэл гаргаж чаддаг. Үүнд хэрэглэгчийн нэр баталгаажуулах шинэ regex томьёо болон өөрчлөлтийн яг мөрийн дугаарууд орно.

Даалгаврын ID: 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```

Gold patch

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-ийн энэ аудитээс үнэлгээний загварт хамаарах хоёр өргөн сургамж харагдаж байна. Нэгдүгээрт, нийтэд нээлттэй материалаас бүрдүүлсэн жишиг үзүүлэлтүүд бохирдох эрсдэлтэй байдаг бөгөөд сургалтын өгөгдөлд өртөлт нь оноог чимээгүйхэн хөөрөгдөж болзошгүй. Хэрэв нийтэд мөлхөж цуглуулсан өгөгдлийг жишиг үзүүлэлт бүтээхэд ашиглаж байгаа бол загвар хөгжүүлэгчид бохирдлын нэмэлт шалгалт хийх ёстой. Жишиг үзүүлэлтүүд, тэр байтугай тэдгээрийн шийдлүүд ч нийтэд тавигдсанаар сургалтын өгөгдөлд орж болзошгүй. Өгөгдлийн багцыг хэрхэн нийтлэх (ж.нь. нууц үгээр хамгаалах) болон сургалтын өгөгдлийг хэрхэн шүүхэд (ж.нь. canary string-ийг хатуу мөрдөх) аль алинд нь нэмэлт анхаарал хандуулах хэрэгтэй.

Хоёрдугаарт, автомат оноолт зөв хийхэд төвөгтэй; төгс тестийн тохиолдлууд зөв функцийг бүрэн баталгаажуулахын зэрэгцээ ач холбогдолгүй тодорхой хэрэгжүүлэлтийн нарийн ширийнээс ангид, мөн товчилсон шийдлүүдэд тэсвэртэй байх ёстой. Эдгээр асуудал угаасаа нарийн төвөгтэй бөгөөд шийдэхэд хэцүү. Эдгээрийг илрүүлэхэд хүний өргөн хүрээтэй олон шошгололтын кампанит ажил шаардсан.

Бид эдгээр олдворыг сүүлийн үеийн үнэлгээний ажилдаа тусгасан. Сүүлийн саруудад бид SWE-Bench Pro-ийн нийтийн split-ийн үр дүнг тайлагнахаар сонгосон. Бусад загвар хөгжүүлэгчдэд ч мөн адил хийхийг зөвлөж байна. SWE-bench Pro төгс биш ч туршлагаар бохирдлын асуудлаас бага өртдөг бололтой. Манай бохирдлын pipeline зарим бохирдлын тохиолдол олсон ч эдгээр нь SWE-bench Verified-тай харьцуулахад мэдэгдэхүйц ховор, бага ноцтой байсан бөгөөд ямар ч загвар бүрэн үгчлэн gold patch гаргаж чадаагүй.

Бид анхнаасаа зохиогдсон, хувийн жишиг үзүүлэлтүүдэд хөрөнгө оруулсаар байх бөгөөд үүнийг мөн хийхэд салбар болон академийн тусламжийг хүсэж байна. GDPVal⁠-д даалгавруудыг тухайн салбарын мэргэжилтнүүд хувиараа зохиодог тул өртөлтийн эрсдэл буурч, шийдлүүдийг бэлтгэгдсэн хянагчид цогцоор нь үнэлдэг. Энэ арга нь их нөөц шаарддаг ч жинхэнэ чадамжийн сайжруулалтыг хэмжихэд улам бүр зайлшгүй болж байна.

2026

Зохиогч

OpenAI

Үргэлжлүүлэн уншина уу

Бүгдийг үзэх

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Судалгаа2026 оны 6-р сарын 4

Introducing new capabilities to GPT-Rosalind

Бүтээгдэхүүн2026 оны 6-р сарын 3

Розалинд Биодифенстэй хамтран нийгмийн уян хатан байдлыг бэхжүүлэх

Бүтээгдэхүүн2026 оны 5-р сарын 29