23 თებერვალი, 2026

რატომ აღარ ზომავს 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-ის ამოცანები აღებულია ღია კოდის რეპოზიტორიუმებიდან, რომლებსაც ბევრი მოდელის მომწოდებელი სასწავლო მიზნებისთვის იყენებს. ჩვენმა ანალიზმა აჩვენა, რომ ყველა მოწინავე მოდელს, რომელიც გამოვცადეთ, შეეძლო ადამიანის მიერ დაწერილი თავდაპირველი ხარვეზის გამოსწორების — ე.წ. gold patch-ის — ან გარკვეული ამოცანებისთვის პრობლემის აღწერის სიტყვასიტყვითი დეტალების გამეორება, რაც მიუთითებს, რომ ყველა მათგანს ტრენინგის დროს ნანახი ჰქონდა სულ მცირე ზოგიერთი პრობლემა და ამოხსნა.

ასევე აღმოვაჩინეთ მტკიცებულება, რომ მოდელები, რომლებმაც ტრენინგისას პრობლემები ნახეს, წარმატებას უფრო ხშირად აღწევენ, რადგან მათ აქვთ დამატებითი ინფორმაცია, რომელიც არასაკმარისად განსაზღვრული ტესტების გასავლელადაა საჭირო.

ეს ნიშნავს, რომ SWE-bench Verified-ზე გაუმჯობესებები აღარ ასახავს მოდელების რეალურ პროგრამული უზრუნველყოფის განვითარების უნარებში არსებით გაუმჯობესებას. ამის ნაცვლად, ისინი სულ უფრო მეტად ასახავს, რამდენად ჰქონდა მოდელს ბენჩმარკთან შეხება ტრენინგის დროს. სწორედ ამიტომ შევწყვიტეთ SWE-bench Verified-ის ქულების გამოქვეყნება და ვურჩევთ სხვა მოდელების დეველოპერებსაც, იგივე გააკეთონ.

ჩვენ ვქმნით ახალ, არაკონტამინირებულ შეფასებებს, რათა უკეთ ვადევნოთ თვალი კოდირების შესაძლებლობებს, და ვფიქრობთ, რომ ეს ფართო კვლევითი საზოგადოებისთვის მნიშვნელოვანი ფოკუსის სფეროა. მანამდე კი OpenAI რეკომენდაციას უწევს SWE-bench Pro-ის შედეგების გამოქვეყნებას.

ფონი

საწყისი SWE-bench⁠(იხსნება ახალ ფანჯარაში) შეფასება 2023 წელს გამოვიდა. თითოეული პრობლემა აღებულია 12 ღია კოდის Python რეპოზიტორიუმიდან ერთ-ერთში გადაჭრილი GitHub issue-იდან და შეწყვილებულია შესაბამის შერწყმის მოთხოვნასთან (PR). იმის დასადგენად, სწორია თუ არა მოდელის მიერ გენერირებული კოდის ცვლილება, თითოეულ პრობლემას ახლავს ტესტების ორი ნაკრები:

ტესტები, რომლებიც უცვლელ კოდურ ბაზაზე ვერ გადის, მაგრამ გადის, თუ issue სწორად გამოსწორდა
რეგრესიის ტესტები, რომლებიც ცვლილებამდე და ცვლილების შემდეგაც გადის, რათა დარწმუნდნენ, რომ დაუკავშირებელი ფუნქციონალი ხელუხლებელია.

მოდელი ტესტებს ვერ ხედავს. მან უნდა შექმნას კოდის ცვლილება მხოლოდ საწყისი issue-ის ტექსტისა და გამოსწორებამდე არსებული რეპოზიტორიუმის მდგომარეობის საფუძველზე. პრობლემა ჩათვლილია გავლილად მხოლოდ მაშინ, თუ კოდის ცვლილების გამოყენების შემდეგ ყველა ტესტი წარმატებით გადის.

ამ შეფასებაში მრავალი პრობლემა ვიპოვეთ, რამაც შეიძლება მოდელების შესაძლებლობების არასათანადო, შემცირებულად წარმოჩენა გამოიწვიოს.

ზოგი ერთეულის ტესტი ზედმეტად სპეციფიკური იყო ან ამოცანას არ ემთხვეოდა, რის გამოც სწორი გამოსწორებებიც შეიძლებოდა უარყოფილიყო.
ბევრი ამოცანის აღწერა არასაკმარისად იყო განსაზღვრული, რაც რამდენიმე სწორ ინტერპრეტაციას ტოვებდა — მაშინ, როცა ტესტები მხოლოდ ერთ კონკრეტულს ფარავდა.
გარემოს კონფიგურაციის მიხედვით (მაგალითად Linux თუ Windows, ან Python-ის ვერსია), ზოგი ტესტი შეიძლებოდა მცდარად ჩავარდნილიყო

ამ პრობლემების გადასაჭრელად 2024 წელს შევქმენით SWE-bench Verified. ვიმუშავეთ გამოცდილ პროგრამულ ინჟინრებთან ერთად, რათა 1,699 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`. ფუნქციის ეს სახელი პრობლემის აღწერაში ნახსენები არ არის, მაგრამ ტესტები მას პირდაპირ ახდენს 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⁠(იხსნება ახალ ფანჯარაში). ეს ამოცანა აღებულია 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.

იმის შესაფასებლად, რამდენად მნიშვნელოვანია კონტამინაცია უფრო ფართო ჭრილში, შევქმენით ავტომატიზებული 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 მოთხოვნა, მომხმარებლის მოთხოვნა, ასისტენტის წინასწარ შევსებული ტექსტი და გამოეყენებინა ინფორმაციის გამოწვევის განსხვავებული სტრატეგიები. ყოველი სვლის შემდეგ მსაჯმა მოდელმა მონიშნა, რამდენი ახალი, ამოცანისთვის სპეციფიკური ინფორმაცია გამოჩნდა, ხოლო თითოეული პასუხი შეფასდა კონტამინაციის სიმძიმით „არავითრიდან“ „ძლიერამდე“. GPT‑5‑ს შეეძლო წინა სვლებზე დაყრდნობით სტრატეგიის ადაპტირება, რათა ეტაპობრივად აღედგინა ამოცანისთვის სპეციფიკური დეტალები. ძლიერი კონტამინაციის თითოეული მაგალითისთვის სხვა მსაჯთან ერთად გადავამოწმეთ, რომ GPT‑5‑ს სამიზნე მოდელისთვის ზედმეტი ინფორმაცია არ გაეჟონა. ბოლოს კი ამ პოსტში მოცემული ტრანსკრიპტების შემადგენელი „ძლიერი“ მაგალითები ხელით გადავხედეთ.

ქვემოთ მოცემულია ძლიერი კონტამინაციის მაგალითები სხვადასხვა მოდელის მომწოდებლებს შორის.

GPT‑5.2

ამოცანის აღწერიდან მოკლე მონაკვეთის მიცემისას GPT‑5.2 ზუსტ gold patch-ს აბრუნებს. კერძოდ, მან იცის ზუსტი კლასისა და მეთოდის სახელი, ასევე ახალი ადრეული დაბრუნების პირობა `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-სტრიქონიანი ფუნქციური ცვლილება, ასევე კონკრეტული ფაილის სახელი და მეთოდი, რომელსაც ის შეეხო, არამედ სიტყვასიტყვით მოჰყავს კიდეც inline კომენტარი, რომელიც diff-ის ნაწილი იყო.

ამოცანის 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

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

სწორი პატჩი

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-ის საჯარო გაყოფიდან წარმოგვედგინა. სხვა მოდელების დეველოპერებსაც იმავეს ვურჩევთ. SWE-bench Pro იდეალური არ არის, მაგრამ ემპირიულად ჩანს, რომ კონტამინაციის პრობლემები მას ნაკლებად აწუხებს. ჩვენმა კონტამინაციის პაიპლაინმა რამდენიმე კონტამინაციის შემთხვევა იპოვა, მაგრამ ეს შემთხვევები მნიშვნელოვნად უფრო იშვიათი და ნაკლებად მძიმე იყო, ვიდრე SWE-bench Verified-ში, და ვერანაირმა მოდელმა ვერ შეძლო სრული სიტყვასიტყვითი gold patch-ის წარმოება.

ჩვენ გავაგრძელებთ ინვესტირებას ორიგინალურ, კერძოდ ავტორებულ ბენჩმარკებში და ვთხოვთ ინდუსტრიასა და აკადემიას, იგივე გააკეთონ. GDPVal⁠-ში ამოცანები კერძოდ არის შექმნილი დომენის ექსპერტების მიერ, რაც ამცირებს ექსპოზიციის რისკს, ხოლო ამოხსნები მთლიანობაში ფასდება გაწვრთნილი შემფასებლების მიერ. ეს მიდგომა რესურსმოხმარებით მძიმეა, მაგრამ სულ უფრო აუცილებელი ხდება რეალური შესაძლებლობების გაუმჯობესების გასაზომად.

2026

ავტორი

OpenAI

განაგრძეთ კითხვა

ყველას ნახვა

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

კვლევა4 ივნ. 2026

GPT-Rosalind-ის ახალი შესაძლებლობების წარდგენა

პროდუქტი3 ივნ. 2026

საზოგადოებრივი მედეგობის გაძლიერება Rosalind Biodefense-ის მეშვეობით

პროდუქტი29 მაი. 2026