முக்கிய உள்ளடக்கத்திற்கு செல்க
OpenAI

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 தொகுப்பில் இரண்டு முக்கிய பிரச்சனைகளை நாங்கள் கண்டறிந்தோம்; இவை, இன்றைய செயல்திறன் நிலைகளில் ஃபிரான்டியர் வெளியீடுகளுக்கான தன்னாட்சி மென்பொருள் பொறியியல் திறன்களில் முன்னேற்றத்தை அளவிட இந்த அளவுகோல் இனி பொருத்தமானதல்ல என்பதை சுட்டிக்காட்டுகின்றன:

  1. சோதனைகள் சரியான தீர்வுகளை நிராகரிக்கின்றன: மாடல்கள் அடிக்கடி தீர்க்கத் தவறிய தரவுத்தொகுப்பின் 27.6% துணைத்தொகுப்பை நாங்கள் தணிக்கை செய்து, தணிக்கை செய்யப்பட்ட பிரச்சனைகளில் குறைந்தது 59.4% இல் செயல்பாட்டளவில் சரியான சமர்ப்பிப்புகளை நிராகரிக்கும் குறைபாடுள்ள சோதனை வழக்குகள் உள்ளன என்பதை கண்டறிந்தோம்; SWE-bench Verified-ஐ ஆரம்பத்தில் உருவாக்கும்போது இதை மேம்படுத்த எங்களால் முடிந்தவரை முயன்றிருந்தபோதும்.
  2. தீர்வுகள் குறித்த பயிற்சி: பெரிய ஃபிரான்டியர் மாடல்கள் தங்களின் பயிற்சியிலிருந்து தகவல்களை கற்றுக்கொள்ளக்கூடியதால், அவை மதிப்பீடு செய்யப்படும் பிரச்சனைகள் மற்றும் தீர்வுகள் மீது ஒருபோதும் பயிற்சி அளிக்கப்படாதது முக்கியம். இது, வரவிருக்கும் தேர்வுக்கு முன்பே மாணவர்களுடன் அந்தத் தேர்வுக்கான பிரச்சனைகள் மற்றும் தீர்வுகளைப் பகிர்வதைப் போன்றது - அவர்கள் பதிலை மனப்பாடம் செய்யாமல் இருக்கலாம், ஆனால் முன்பே பதில்களை பார்த்துள்ள மாணவர்கள், பார்க்காதவர்களை விட நிச்சயமாகச் சிறப்பாகச் செய்வார்கள். SWE-bench பிரச்சனைகள், பல மாடல் வழங்குநர்கள் பயிற்சி நோக்கங்களுக்காக பயன்படுத்தும் திறந்த-மூல ரிபாசிட்டரிகளிலிருந்து பெறப்படுகின்றன. எங்கள் பகுப்பாய்வில், நாங்கள் சோதித்த அனைத்து ஃபிரான்டியர் மாடல்கள், ground-truth reference ஆக பயன்படுத்தப்பட்ட அசல், மனிதர் எழுதிய பக் ஃபிக்ஸை (கோல்ட் பேட்ச் என அறியப்படும்) அல்லது சில பணிகளுக்கான verbatim problem statement விவரக்குறிப்புகளை மீண்டும் உருவாக்க முடிந்தது என்பதை கண்டறிந்தோம்; இதன் மூலம், பயிற்சியின் போது அவை அனைத்தும் குறைந்தது சில பிரச்சனைகளையும் தீர்வுகளையும் பார்த்திருக்கின்றன என்பதைக் காட்டுகிறது.

பயிற்சி நேரத்தில் அந்தப் பிரச்சனைகளை முன்பே பார்த்த மாடல்கள் வெற்றி பெற வாய்ப்பு அதிகமாக உள்ளது, ஏனெனில் அவை குறைந்த விவரங்களை கொண்ட சோதனைகளை கடக்க தேவையான கூடுதல் தகவலை ஏற்கனவே பெற்றிருக்கும்.

இதன் பொருள், SWE-bench Verified இல் உள்ள மேம்பாடுகள் இனி மாடல்களின் நிஜ உலக மென்பொருள் மேம்பாட்டு திறன்களில் அர்த்தமுள்ள மேம்பாடுகளை பிரதிபலிக்காது. அதற்கு பதிலாக, பயிற்சி நேரத்தில் மாடல் அந்த பெஞ்ச்மார்க்கிற்கு எவ்வளவு அளவு வெளிப்பட்டது என்பதை அவை அதிகமாக பிரதிபலிக்கின்றன. இதனால்தான் நாங்கள் SWE-bench Verified ஸ்கோர்களை அறிவிப்பதை நிறுத்தியுள்ளோம், மேலும் மற்ற மாடல் டெவலப்பர்களும் அதையே செய்யுமாறு பரிந்துரைக்கிறோம்.

கோடிங் திறன்களை மேலும் சிறப்பாக கண்காணிக்க, நாங்கள் புதிய, மாசுபடாத மதிப்பீடுகளை உருவாக்கி வருகிறோம். பரந்த ஆராய்ச்சி சமூகத்திற்காக இது முக்கியமான பகுதி என்று நாங்கள் நினைக்கிறோம். அவை கிடைக்கும் வரை, SWE-bench Pro-க்கான முடிவுகளை அறிக்கையிட OpenAI பரிந்துரைக்கிறது.

பின்னணி

அசல் SWE-bench(புதிய சாளரத்தில் திறக்கும்) மதிப்பீடு 2023 இல் வெளியிடப்பட்டது. ஒவ்வொரு பிரச்சனையும் 12 திறந்த மூல Python ரிபாசிட்டரிகளில் ஒன்றில் தீர்க்கப்பட்ட GitHub issue இலிருந்து பெறப்பட்டு, அதற்குரிய pull request (PR) உடன் இணைக்கப்பட்டுள்ளது. மாடல் உருவாக்கிய குறியீடு மாற்றம் சரியானதா என்பதை தீர்மானிக்க, ஒவ்வொரு பிரச்சனைக்கும் இரண்டு தொகுதி சோதனைகள் உள்ளன:

  • மாற்றமில்லாத குறியீட்டுத் தளத்தில் தோல்வியடையும் சோதனைகள், ஆனால் சிக்கல் சரியாக சரிசெய்யப்பட்டால் வெற்றி பெறும்
  • திருத்தத்திற்கு முன்பும் பின்பும் இரண்டிலும் தேர்ச்சி பெறும் மீள் சோதனைகள், தொடர்பற்ற செயல்பாடு பாதிக்கப்படாமல் இருப்பதை உறுதி செய்ய.

மாடல் சோதனைகளைப் பார்க்காது. அசல் issue உரையும், fix க்கு முன் ரிபாசிட்டரியின் நிலையும் மட்டும் கொடுக்கப்பட்ட நிலையில், இது ஒரு code change ஐ உருவாக்க வேண்டும். குறியீட்டு மாற்றம் பயன்படுத்தப்பட்ட பிறகு அனைத்து சோதனைகளும் தேர்ச்சி பெற்றால் மட்டுமே அது ஒரு பிரச்சனையை கடந்து செல்லும்.

அந்த மதிப்பீட்டில் மாடல்களின் திறன் குறைவாக அறிக்கையிடப்படுவதற்கு வழிவகுக்கக்கூடிய பல பிரச்சனைகளை நாங்கள் கண்டறிந்தோம்.

  • சில அலகு சோதனைகள் மிக குறிப்பாக இருந்தன அல்லது பணியுடன் பொருந்தவில்லை; அதனால் சரியான சரிசெய்தல்களும் நிராகரிக்கப்படலாம்.
  • பல பணிக் கூற்றுகள் போதுமான அளவில் விவரிக்கப்படவில்லை, இதனால் பல செல்லுபடியாகும் விளக்கங்கள் உருவாகக்கூடும் - ஆனால் சோதனைகள் ஒரு குறிப்பிட்ட ஒன்றை மட்டுமே உள்ளடக்கியிருந்தன.
  • சூழலின் அமைப்பைப் பொறுத்து (உதாரணமாக Linux மற்றும் Windows, அல்லது Python பதிப்பு), சில சோதனைகள் தவறாக தோல்வியடையக்கூடும்

இந்தச் சிக்கல்களைத் தீர்க்க 2024-இல் நாங்கள் SWE-bench சரிபார்ப்பு முடிந்தது என்பதை உருவாக்கினோம். 1,699 SWE-bench சிக்கல்களை மதிப்பாய்வு செய்து, இந்த பிரச்சனைகள் இருந்த சிக்கல்களை வடிகட்டுவதற்காக நாங்கள் நிபுணர் மென்பொருள் பொறியாளர்களுடன் பணியாற்றினோம். ஒவ்வொரு பிரச்சனையும் மூன்று நிபுணர்களால் சுயாதீனமாக மதிப்பாய்வு செய்யப்பட்டது. இந்த மதிப்பாய்வு செயல்முறை SWE-bench Verified-ஐ உருவாக்கியது; இது 500 பிரச்சனைகளைக் கொண்ட தேர்ந்தெடுக்கப்பட்ட தொகுப்பு.

மிகக் குறுகிய மற்றும் மிக அகலமான சோதனைகள்

SWE-bench Verified ஆரம்ப பதிப்பை விட பெரிய முன்னேற்றமாக இருந்தாலும், மீதமுள்ள சிக்கல்கள் அப்படியே உள்ளன. நாங்கள் 64 சுயாதீன இயக்கங்களில் OpenAI o3 தொடர்ந்து தீர்க்காத 138 SWE-bench சரிபார்க்கப்பட்ட சிக்கல்களின் தணிக்கையை மேற்கொண்டோம். ஒவ்வொரு வழக்கும் குறைந்தது ஆறு அனுபவமுள்ள மென்பொருள் பொறியாளர்களால் சுயாதீனமாக மதிப்பாய்வு செய்யப்பட்டது. ஒரு நிபுணர் ஒரு பிரச்சனையை குறித்திருந்தால், அது கூடுதல் குழுவால் மீண்டும் சரிபார்க்கப்பட்டது.

138 பிரச்சனைகளில் 59.4% இல் சோதனை வடிவமைப்பு மற்றும்/அல்லது பிரச்சனை விளக்கத்தில் முக்கியமான குறைகள் உள்ளன என்பதை நாங்கள் கண்டறிந்தோம்; இதனால், மிக திறமையான மாடல் அல்லது மனிதருக்குக் கூட அவற்றைத் தீர்ப்பது மிகக் கடினமாகவோ அல்லது சாத்தியமற்றதாகவோ ஆகிறது. 

  • ஆடிட் செய்யப்பட்ட பணிகளில் 35.5% இல், குறிப்பிட்ட செயலாக்க விவரங்களை கட்டாயப்படுத்தும் கடுமையான சோதனை நிகழ்வுகள் உள்ளன, இதனால் செயல்பாட்டளவில் சரியான பல சமர்ப்பிப்புகள் செல்லாதவையாகின்றன, இதை நாங்கள் நெருக்கமான சோதனை நிகழ்வுகள்என்று அழைக்கிறோம்.
  • தணிக்கை செய்யப்பட்ட பணிகளில் 18.8%, சிக்கல் விளக்கத்தில் குறிப்பிடப்படாத கூடுதல் செயல்பாட்டைச் சரிபார்க்கும் சோதனைகளைக் கொண்டுள்ளன, இதை நாங்கள் பரந்த சோதனை வழக்குகள் என்று அழைக்கிறோம்.
  • மீதமுள்ள 5.1% பணிகளில், இந்த வகைப்பாட்டுடன் நன்றாக ஒழுங்குபடுத்தப்படாத பல்வகை சிக்கல்கள் இருந்தன.

முதல் தோல்வி முறையின் ஒரு விளக்கமான உதாரணம் pylint-dev__pylint-4551(புதிய சாளரத்தில் திறக்கும்) ஆகும்; இதில், மொத்தத் தீர்வின் ஒரு பகுதியாக PR புதிய `get_annotation` செயல்பாட்டை அறிமுகப்படுத்துகிறது. இந்த செயல்பாட்டு பெயர் பிரச்சனை விளக்கத்தில் குறிப்பிடப்படவில்லை, ஆனால் சோதனைகள் மூலம் நேரடியாக இறக்குமதி செய்யப்படுகிறது. சில மாடல்கள் இப்படிப்பட்ட ஒரு செயல்பாட்டை உருவாக்க உள்ளுணர்வாகத் தோன்றினாலும், பிரச்சனையை சரியாகத் தீர்க்க இந்த குறிப்பிட்ட பெயருடன் ஒரு செயல்பாட்டை செயல்படுத்துவது கண்டிப்பாக அவசியமில்லை. பல செல்லுபடியாகும் தீர்வுகள் இறக்குமதி பிழைகளால் சோதனைகளில் தோல்வியடைகின்றன.

பிரச்சனை பற்றிய விபரம்

எளிய உரை

1
Use Python type hints for UML generation
2
It 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
`
5
class C(object):
6
def __init__(self, a: str = None):
7
self.a = a
8
`
9
### Current behavior
10
Output of pyreverse :
11
![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12
### Expected behavior
13
I would like to see something like : `a : String` in the output.
14
### pylint --version output
15
pylint-script.py 1.6.5,
16
astroid 1.4.9
17
Python 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 ______________
3
ImportError while importing test module '/testbed/tests/unittest_pyreverse_writer.py'.
4
Hint: make sure your test modules/packages have valid Python names.
5
Traceback:
6
/opt/miniconda3/envs/testbed/lib/python3.9/importlib/__init__.py:127: in import_module
7
return _bootstrap._gcd_import(name[level:], package, level)
8
tests/unittest_pyreverse_writer.py:32: in <module>
9
from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node
10
E 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 சரிபார்ப்பு முடிந்தது பணிக்கான விளக்கம், இருப்பினும், இறுதி சிக்கல் #18212(புதிய சாளரத்தில் திறக்கும்) ஐ மட்டுமே உள்ளடக்குகிறது. இது ஒரு பொருந்தாமையை உருவாக்குகிறது: PR சோதனைகள் மூன்று பிரச்சனைகளையும் உள்ளடக்குகின்றன, ஆனால் விளக்கம் ஒன்றை மட்டுமே விவரிக்கிறது. எங்கள் சோதனைகளில், மாடல்கள் பெரும்பாலும் விவரிக்கப்பட்ட பிழைத்திருத்தத்தை சரியாக செயல்படுத்துகின்றன, பின்னர் மற்ற இரண்டு சிக்கல்களுக்கான செயல்படுத்தலை உள்ளடக்கிய சோதனைகளில் தோல்வியடைகின்றன.

அசல் PR விளக்கம் (GitHub PR இலிருந்து)

எளிய உரை

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

#18212 க்கான பிரச்சனை விளக்கம்

எளிய உரை

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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 இலிருந்து மட்டும் எடுத்தது):

எளிய உரை

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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

எளிய உரை

1
There 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.2‑Chat ஐ ஆய்வு செய்ய GPT‑5 ஐ நாங்கள் பணியமர்த்தினோம், Claude Opus 4.5 and Gemini 3 Flash Preview for மாசுபாட்டிற்காக. இந்த மாடல்கள் ரீஸனிங் மாடல்களை விலக்குவதற்காக தேர்ந்தெடுக்கப்பட்டன, ஆனால் அவற்றுக்கிடையில் குறிப்பிடத்தக்க திறன் இடைவெளி இருக்க வாய்ப்புள்ளது என்பதை நாங்கள் ஒப்புக்கொள்கிறோம்.

மாசுபாட்டை கண்டறிய, GPT‑5 பெற்றது: SWE-bench Verified பணியின் ID, விளக்கம், கோல்ட் பேட்ச், மற்றும் PR சோதனைகள். 15 திருப்பங்களுக்கு மேல், GPT‑5 ஐ சிஸ்டம்/டெவலப்பர் ப்ராம்ட், பயனர் ப்ராம்ட் மற்றும் அசிஸ்டண்ட் ப்ரீஃபில் மற்றும் பல்வேறு எலிசிட்டேஷன் உத்திகளை மாற்ற அனுமதித்தோம். ஒவ்வொரு திருப்பத்திற்குப் பிறகும், ஒரு நீதிபதி மாடல், எவ்வளவு புதுமையான பணி சார்ந்த தகவல்கள் தோன்றின என்பதைக் குறித்தது, மேலும் ஒவ்வொரு பதிலும் "எதுவுமில்லை" என்பதிலிருந்து "வலுவானது" வரை மாசுபாட்டின் தீவிரத்திற்காகக் குறித்தது. GPT‑5, முந்தைய திருப்பங்களின் அடிப்படையில் தனது தந்திரத்தை மாற்றியமைத்து, பணிக்கே உரிய விவரங்களை மீண்டும் மீண்டும் கண்டறிய அனுமதிக்கப்பட்டது. ஒவ்வொரு வலுவான மாசுபாட்டின் (strong contamination) எடுத்துக்காட்டுக்கும், GPT‑5 இலக்கு மாடலுக்கு (target model) மிக அதிகமான தகவலை வெளிப்படுத்தவில்லை என இன்னொரு நீதிபதி/சான்றாளி (judge) மூலம் உறுதி செய்தோம். இறுதியாக, இந்த பதிவில் உள்ள டிரான்ஸ்கிரிப்ட்களை உருவாக்கும் “வலுவான” எடுத்துக்காட்டுகளை நாங்கள் கைமுறையாக பரிசீலித்தோம்.

கீழே வெவ்வேறு மாடல் வழங்குநர்களில் வலுவான மாசுபாட்டின் உதாரணங்கள் உள்ளன.

GPT‑5.2 

பணி விளக்கத்திலிருந்து ஒரு குறுகிய துணுக்கை வழங்கினால், GPT‑5.2 துல்லியமான gold patch ஐ வெளியிடுகிறது. குறிப்பாக, அது துல்லியமான class மற்றும் method பெயரை, மேலும் அறிமுகப்படுத்தப்படும் புதிய early return நிபந்தனை `if username is None or password is None` என்பதையும் அறிந்திருக்கிறது.

மாசுபாடு வெளிக்கொணர்வு

பிரச்சனை விளக்கம்

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

பயனர் தூண்டி

1
We're playing a SWE-bench Verified memory game.
2
Please 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.
3
The task ID is django__django-11451.
4
Hint: Part of the description was "... shouldn't make a database query when username is None"

மாடல் பதில்

1
Task (best-guess full sentence)
2
- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3

4
What 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

9
Best-guess diff (approximate, from memory)
10

11
```diff
12
diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13
index 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

33
If 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

1
diff --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-வரி செயல்பாட்டு மாற்றத்தை, அது தொட்ட குறிப்பிட்ட filename மற்றும் method உடன் சேர்த்து நினைவுகூருவதோடு மட்டுமல்லாமல், diff இன் ஒரு பகுதியாக இருந்த inline comment ஐயும் சொற்சொல்லாக மேற்கோள் காட்டுகிறது. 

மாசுபாடு வெளிக்கொணர்வு

பயனர் ப்ராம்ப்ட்

1
Quick 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.

முன் நிரப்பு

1
Let 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

13
The original code was:
14
```python
15
if (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

21
This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

கோல்ட் பேட்ச்

Python

1
diff --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 தவிர வேறு எந்தத் தகவலும் வழங்கப்படாதபோது, பணி விளக்கம் மற்றும் கோல்ட் பேட்ச் இலிருந்து சொற்சொல்லாக உள்ள விவரங்களை வெளியிட முடிகிறது. இதில் பயனர்பெயர் சரிபார்ப்புக்கான புதிய regex சூத்திரமும், மாற்றத்திற்கான துல்லியமான வரி எண்களும் அடங்கும்.

மாசுபாடு வெளிக்கொணர்வு

பிரச்சனை விளக்கம்

1
UsernameValidator allows trailing newline in usernames

பயனர் தூண்டி

1
Please 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.

முன் நிரப்பு

1
Let me be precise about the wording.

மாடல் பதில்

1
### Task Text
2
UsernameValidator allows trailing newlines.
3

4
ASCIIUsernameValidator 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

1
diff --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 பற்றிய இந்த தணிக்கையிலிருந்து, மதிப்பீட்டு வடிவமைப்பிற்கான இரண்டு பரந்த பாடங்களை நாம் காண்கிறோம். முதலில், பொதுவில் கிடைக்கும் பொருட்களிலிருந்து பெறப்பட்ட பெஞ்ச்மார்க்குகள் மாசுபாட்டு அபாயத்தை உடையவை; பயிற்சி தரவு வெளிப்பாடு மதிப்பெண்களை அமைதியாக உயர்த்தக்கூடும். பொதுவில் வலைவலம் செய்யப்பட்ட தரவு பெஞ்ச்மார்க் கட்டுமானத்தில் பயன்படுத்தப்பட்டால், மாதிரி உருவாக்குநர்கள் மாசுபாட்டிற்கான கூடுதல் சோதனைகளைச் செய்ய வேண்டும். பெஞ்ச்மார்க்குகள், மேலும் அவற்றின் தீர்வுகள்கூட, பொதுவெளியில் பதிவிடப்பட்டால் பயிற்சி தரவுகளில் சேர்ந்து விடலாம். தரவுத்தொகுப்புகள் எவ்வாறு பதிவிடப்படுகின்றன என்பதிலும் (i.e. கடவுச்சொல்லால் பாதுகாக்கப்பட்டது) மற்றும் பயிற்சித் தரவு வடிகட்டுதல் (i.e. canary string ஐ தவறாமல் கட்டாயமாக பின்பற்றுதல்). 

இரண்டாவதாக, தானியங்கி மதிப்பீடு சரியாக அமைப்பது சிக்கலானது; சிறந்த சோதனை நிகழ்வுகள் சரியான செயல்பாட்டை முழுமையாகச் சரிபார்க்க வேண்டும், குறிப்பிட்ட முக்கியமற்ற அமலாக்க விவரங்களுக்கு சார்பில்லாமல் இருப்பதோடு, குறுக்கு வழித் தீர்வுகளுக்கும் உறுதியானதாகவும் இருக்க வேண்டும். இந்த பிரச்சனைகள் இயல்பாகவே சிக்கலானவை மற்றும் தீர்க்க கடினமானவை. இந்தப் பிரச்சனைகளை கண்டறிய பல விரிவான மனித லேபிளிங் பிரச்சாரங்கள் தேவைப்பட்டன. 

இந்த கண்டறிதல்களை எங்களின் சமீபத்திய மதிப்பீட்டு முயற்சிகளில் இணைத்துள்ளோம். கடந்த மாதங்களில் SWE-Bench Pro இன் பொது பிரிப்பிலிருந்து கிடைத்த முடிவுகளை அறிக்கையிடத் தேர்ந்தெடுத்துள்ளோம். மற்ற மாடல் டெவலப்பர்களும் இதையே செய்ய பரிந்துரைக்கிறோம். SWE-bench Pro முழுமையானது அல்ல, ஆனால் அனுபவ ஆதாரங்களின்படி மாசுபாடு பிரச்சனைகளால் குறைவாகவே பாதிக்கப்படுவது போலத் தெரிகிறது. எங்கள் மாசுபாட்டு (contamination) சோதனை முறை (pipeline) சில மாசுபாட்டு நிகழ்வுகளை கண்டறிந்தது. ஆனால், இந்த நிகழ்வுகள் SWE-bench Verified ஐ விட மிக குறைவாகவும், அதிக கவலைக்குரியதும் அல்லாதவையாக இருந்தன. மேலும், எந்த மாடலும் முழுமையான மூலக் குறியீட்டு பதிப்பை (verbatim gold patch) உருவாக்க முடியவில்லை.

நாங்கள் அசல் மற்றும் தனிப்பட்ட முறையில் உருவாக்கப்பட்ட பெஞ்ச்மார்க்குகளில் தொடர்ந்து முதலீடு செய்வோம், மேலும் தொழில்துறை மற்றும் கல்வித்துறையிடமிருந்து அதேபோல் செய்ய உதவி கேட்போம். GDPVal இல், பணிகள் துறை நிபுணர்களால் தனிப்பட்ட முறையில் உருவாக்கப்படுவதால் வெளிப்பாடு அபாயம் குறைகிறது, மேலும் தீர்வுகள் பயிற்சி பெற்ற மதிப்பாய்வாளர்களால் முழுமையாக மதிப்பீடு செய்யப்படுகின்றன. இந்த அணுகுமுறை வளங்களை அதிகம் தேவைப்படுத்துகிறது, ஆனால் உண்மையான திறன் மேம்பாடுகளை அளவிட இது அதிகரித்து வரும் அளவில் மிகவும் அவசியமாகிறது.

ஆசிரியர்

OpenAI