23 փետրվարի, 2026 թ.

Ինչո՞ւ SWE-bench Verified-ը այլևս չի չափում կոդավորման առաջադեմ հնարավորությունները

SWE-bench Verified-ը գնալով ավելի է աղտոտվում։ Մենք խորհուրդ ենք տալիս SWE-bench Pro-ն։

Բեռնվում է…

2024 թվականի օգոստոսին SWE-bench Verified -ը առաջին անգամ հրապարակելուց ի վեր, ոլորտը լայնորեն օգտագործել է այն՝ ինքնավար ծրագրային ապահովման ճարտարագիտության առաջադրանքներում մոդելների առաջընթացը չափելու համար։ Թողարկումից հետո 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 թվականին։ Յուրաքանչյուր խնդիր վերցված է 12 բաց կոդով Python պահոցներից մեկում լուծված GitHub խնդրից և զուգակցված է համապատասխան pull request (PR)-ի հետ։ Որոշելու համար, թե արդյոք մոդելի կողմից ստեղծված կոդի փոփոխությունը ճիշտ է, յուրաքանչյուր խնդիր ունի թեստերի երկու հավաքածու՝

Թեստեր, որոնք ձախողվում են չփոփոխված կոդային բազայում, բայց անցնում են, եթե խնդիրը ճիշտ է շտկված
Ռեգրեսիոն թեստեր, որոնք անցնում են ինչպես շտկումից առաջ, այնպես էլ հետո՝ համոզվելու համար, որ չառնչվող ֆունկցիոնալությունը մնում է անխաթար։

Մոդելը չի տեսնում թեստերը։ Այն պետք է ստեղծի կոդի փոփոխություն՝ ունենալով միայն սկզբնական խնդրի տեքստը և պահոցի վիճակը՝ շտկումից առաջ։ Խնդիրը համարվում է լուծված միայն այն դեպքում, եթե կոդի փոփոխությունը կիրառելուց հետո բոլոր թեստերը անցնեն։

Մենք հայտնաբերեցինք բազմաթիվ խնդիրներ կապված այդ գնահատման հետ, որոնք կարող են հանգեցնել մոդելների կարողությունների թերագնահատման։

Որոշ միավորային թեստեր չափազանց կոնկրետ էին կամ չէին համապատասխանում առաջադրանքին, ուստի ճիշտ շտկումները կարող էին մերժվել։
Շատ առաջադրանքների նկարագրություններ թերի էին սահմանված, ինչը կարող էր հանգեցնել մի քանի վավեր մեկնաբանությունների, մինչդեռ թեստերը ընդգրկում էին միայն մեկ կոնկրետ տարբերակ։
Կախված միջավայրի կարգավորումից (օրինակ՝ Linux-ի և Windows-ի միջև, կամ Python-ի տարբերակից), որոշ թեստեր կարող են անօրինական եղանակով ձախողվել

Մենք ստեղծեցինք SWE-bench Verified -ը 2024 թվականին՝ այս խնդիրները լուծելու համար։ Մենք աշխատեցինք փորձառու ծրագրային ապահովման ինժեներների հետ՝ վերանայելու 1699 SWE-bench խնդիրներ և զտելու այն պրոբլեմները, որտեղ առկա էին այս խնդիրները։ Յուրաքանչյուր խնդիր վերանայվել է երեք փորձագետների կողմից՝ մեկը մյուսից անկախ։ Այս վերանայման գործընթացի արդյունքում ստացվեց SWE-bench Verified-ը՝ 500 խնդիրներից կազմված ընտրված հավաքածու։

Չափազանց նեղ և չափազանց լայն թեստեր

Թեև SWE-bench Verified-ը մեծ բարելավում է սկզբնական տարբերակի համեմատ, մնացորդային խնդիրներ դեռևս մնում են։ Մենք իրականացրել ենք աուդիտ՝ 138 SWE-bench Verified խնդիրների վերաբերյալ, որոնք OpenAI o3‑ը 64 անկախ գործարկումների ընթացքում հետևողականորեն չէր լուծում։ Յուրաքանչյուր դեպք անկախ կերպով վերանայվել է ծրագրային ապահովման առնվազն վեց փորձառու ինժեներների կողմից։ Եթե փորձագետը խնդիր է նշել, այն կրկին ստուգվել է լրացուցիչ թիմի կողմից։

Մենք պարզեցինք, որ 138 խնդիրներից 59.4%-ը պարունակում էր էական խնդիրներ թեստի նախագծման և/կամ խնդրի նկարագրության մեջ, ինչը դրանք դարձնում էր չափազանց դժվար կամ անհնար լուծելի նույնիսկ ամենաունակ մոդելի կամ մարդու համար։

Աուդիտ անցած առաջադրանքների 35.5%-ը ունի խիստ թեստային դեպքեր, որոնք պարտադրում են իրականացման կոնկրետ մանրամասներ՝ անվավեր դարձնելով բազմաթիվ ֆունկցիոնալ առումով ճիշտ ներկայացումներ, որոնք անվանում ենք նեղ թեստային դեպքեր։
Աուդիտ անցած առաջադրանքների 18.8%-ն ունի թեստեր, որոնք ստուգում են լրացուցիչ ֆունկցիոնալություն, որը նշված չէր խնդրի նկարագրության մեջ, ինչն անվանում ենք լայն թեստային դեպքեր։
Առաջադրանքների մնացած 5.1%-ը ուներ տարբեր խնդիրներ, որոնք այս դասակարգման շրջանակում լավ չէին խմբավորվում։

Առաջին ձախողման ռեժիմի պատկերավոր օրինակ է pylint-dev__pylint-4551⁠(բացվում է նոր պատուհանում)-ը, որտեղ PR-ը որպես ընդհանուր լուծման մաս ներմուծում է նոր «get_annotation» ֆունկցիա։ Այս ֆունկցիայի անունը նշված չէ խնդրի նկարագրության մեջ, բայց թեստերի կողմից ներմուծվում է անմիջապես։ Թեև որոշ մոդելներ կարող են ինտուիտիվ եղանակով ստեղծել նման ֆունկցիա, խնդիրը ճիշտ լուծելու համար խստորեն անհրաժեշտ չէ իրականացնել այս հատուկ անունով ֆունկցիա։ Շատ վավեր լուծումներ ձախողվում են թեստերում՝ ներմուծման սխալների պատճառով։

Խնդրի նկարագրություն

Պարզ տեքստ

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-ի բնօրինակ նկարագրությունը (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‑ը իր մտքերի շղթայում ցույց է տալիս, որ ունի տեղեկություն թողարկման նշումների մասին, որոնք մանրամասնում են կոդային բազայում կատարված փոփոխությունները, և ճիշտ է նույնականացնում, որ «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 առաջադրանքի ID-ն, նկարագրությունը, ոսկե պատչը և PR թեստերը։ 15-ից ավելի շրջափուլերի ընթացքում մենք թույլ տվեցինք GPT‑5‑ին փոփոխել համակարգի/մշակողի հարցումը, օգտատիրոջ հարցումը և օգնականի նախալցոնումը, ինչպես նաև տվյալների հավաքագրման տարբեր ռազմավարություններ։ Յուրաքանչյուր շրջափուլից հետո գնահատող մոդելը պիտակավորեց, թե որքան նոր, առաջադրանքին հատուկ տեղեկատվություն է հայտնվել, և յուրաքանչյուր պատասխան պիտակավորվեց աղտոտման լրջության աստիճանով՝ «ոչ մեկ»-ից մինչև «ուժեղ»։ GPT‑5‑ին թույլատրվեց հարմարեցնել իր ռազմավարությունը՝ հիմնվելով նախորդ շրջափուլերի վրա, որպեսզի կրկնաբար վերականգնի առաջադրանքին հատուկ մանրամասները։ Ուժեղ աղտոտման յուրաքանչյուր օրինակի համար մենք մեկ այլ գնահատողի հետ ստուգեցինք, որ GPT‑5‑ը չափազանց շատ տեղեկատվություն չի արտահոսել թիրախային մոդելին։ Վերջապես, այնուհետև մենք ձեռքով վերանայեցինք այս գրառման սղագրությունները կազմող «ուժեղ» օրինակները։

Ստորև բերված են տարբեր մոդելների մատակարարների միջև ուժեղ աղտոտման օրինակներ։

GPT‑5.2

Առաջադրանքի նկարագրությունից տրված կարճ հատվածի հիման վրա GPT‑5.2‑ը արտածում է ճշգրիտ ոսկե պատչը։ Մասնավորապես, այն գիտի դասի և մեթոդի ճշգրիտ անունը, ինչպես նաև նոր վաղ վերադարձի պայմանը «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.

Ոսկե պատչ

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 տողանոց ֆունկցիոնալ փոփոխությունը՝ դրա դիպչած կոնկրետ ֆայլի անունով և մեթոդով, այլ նաև բառացի մեջբերում է տարբերության մաս կազմող ներտողային մեկնաբանությունը։

Առաջադրանքի 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

Ոսկե պատչ

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

Առաջադրանքի վերաբերյալ ID-ից բացի այլ լրացուցիչ տեղեկություն չստանալու դեպքում, Gemini 3 Flash-ը կարողանում է բառացիորեն արտածել առաջադրանքի նկարագրության և ոսկե պատչի մանրամասները։ Սա ներառում է օգտանվան վավերացման համար 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```

Ոսկե պատչ

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⁠-ում առաջադրանքները մասնավոր կերպով ստեղծվում են տիրույթի փորձագետների կողմից՝ նվազեցնելով բացահայտման ռիսկը, և լուծումները համապարփակ կերպով գնահատվում են վերապատրաստված վերանայողների կողմից։ Այս մոտեցումը պահանջում է ռեսուրսներ, սակայն գնալով ավելի անհրաժեշտ է դառնում՝ իրական կարողությունների բարելավումները չափելու համար։

2026

Հեղինակ

OpenAI

Շարունակել կարդալ

Դիտել բոլորը

Better memory for a more helpful ChatGPT

Ավելի ամուր հիմք ChatGPT-ի հիշողության համար

Հետազոտություններ4 հնս, 2026 թ.

Ներկայացնում ենք GPT-Rosalind-ի նոր կարողությունները

Արտադրանք3 հնս, 2026 թ.

Հասարակության դիմակայունության ամրապնդում Rosalind Biodefense-ի միջոցով

Արտադրանք29 մյս, 2026 թ.