ऑगस्ट 2024 मध्ये आम्ही प्रथम SWE-बेंच व्हेरिफाइड प्रकाशित केल्यापासून, उद्योगाने स्वायत्त सॉफ्टवेअर अभियांत्रिकी कामांवरील मॉडेल्सची प्रगती मोजण्यासाठी याचा मोठ्या प्रमाणावर वापर केला आहे. त्याच्या रिलीज नंतर, SWE-बेंच व्हेरिफाइड ने क्षमतेतील प्रगतीचा एक मजबूत संकेत दिला आणि अत्याधुनिक मॉडेल रिलीजमध्ये नोंदवला जाणारा एक मानक मेट्रिक बनला. या क्षमतांच्या प्रगतीचा मागोवा घेणे आणि अंदाज बांधणे हे OpenAI च्या प्रिपेयर्डनेस फ्रेमवर्क चा देखील एक महत्त्वाचा भाग आहे. जेव्हा आम्ही सुरुवातीला व्हेरिफाइड बेंचमार्क तयार केला, तेव्हा आम्ही मूळ मूल्यांकनातील अशा समस्या सोडवण्याचा प्रयत्न केला ज्यामुळे SWE-बेंच dataset(नवीन विंडोमध्ये उघडेल) मधील काही कार्ये पूर्ण करणे अशक्य झाले होते.
प्रारंभिक उड्या घेतल्यानंतर, SWE-बेंच व्हेरिफाइडवर स्टेट-ऑफ-द-आर्ट प्रगती मंदावली आहे, सुधारणा(नवीन विंडोमध्ये उघडेल) गेल्या 6 महिन्यांत 74.9% वरून 80.9% पर्यंत झाली आहे. यामुळे प्रश्न निर्माण होतो: उरलेली अपयशे मॉडेलच्या मर्यादा दर्शवतात की डेटासेटच्या स्वतःच्या गुणधर्मांमुळे?
एका नवीन विश्लेषणात, आम्हाला व्हेरिफाइड सेटमध्ये दोन प्रमुख समस्या आढळल्या, ज्या दर्शवतात की आजच्या कार्यक्षमतेच्या पातळ्यांवर अत्याधुनिक लॉन्चेससाठी स्वायत्त सॉफ्टवेअर अभियांत्रिकी क्षमतांवरील प्रगती मोजण्यासाठी हा बेंचमार्क आता योग्य राहिलेला नाही:
- चाचण्या योग्य उपाय नाकारतात: आम्ही डेटासेटच्या 27.6% उपसंचाचे ऑडिट केले, ज्याचे निराकरण मॉडेल्सना अनेकदा करता आले नाही, आणि असे आढळले की ऑडिट केलेल्या समस्यांपैकी किमान 59.4% मध्ये त्रुटीपूर्ण टेस्ट केसेस आहेत ज्या कार्यात्मकदृष्ट्या योग्य सबमिशन्स नाकारतात, जरी आम्ही SWE-बेंच व्हेरिफाइड च्या प्रारंभिक निर्मितीत हे सुधारण्यासाठी सर्वोत्तम प्रयत्न केले होते.
- उपायांवरील प्रशिक्षण: मोठी अत्याधुनिक मॉडेल्स त्यांच्या प्रशिक्षणातून माहिती शिकू शकतात, त्यामुळे ज्या समस्या आणि उपायांवर त्यांचे मूल्यमापन केले जाते त्यावर त्यांना कधीही प्रशिक्षण दिले जाऊ नये, हे महत्त्वाचे आहे. हे चाचणीपूर्वी विद्यार्थ्यांसोबत येणाऱ्या चाचणीसाठीचे प्रश्न आणि त्यांची उत्तरे शेअर करण्यासारखे आहे - ते कदाचित उत्तर पाठ करून ठेवणार नाहीत, पण ज्यांनी आधी उत्तरे पाहिली आहेत असे विद्यार्थी, ज्यांनी पाहिली नाहीत त्यांच्यापेक्षा नक्कीच चांगली कामगिरी करतील. SWE-बेंच समस्या अनेक मॉडेल प्रदाते प्रशिक्षणासाठी वापरतात अशा मुक्त-स्रोत रिपॉझिटरींमधून घेतल्या जातात. आमच्या विश्लेषणात आम्हाला आढळले की आम्ही तपासलेल्या सर्व अत्याधुनिक मॉडेल्सना ग्राउंड-ट्रुथ संदर्भ म्हणून वापरलेला मूळ, मानवाने लिहिलेला बग फिक्स—ज्याला गोल्ड पॅच म्हणतात—किंवा काही कामांसाठी समस्या विधानातील तपशील शब्दशः पुनरुत्पादित करता आले, यावरून असे सूचित होते की प्रशिक्षणादरम्यान त्यांनी किमान काही समस्या आणि उपाय पाहिलेले आहेत.
आम्हाला असेही पुरावे आढळले की प्रशिक्षणादरम्यान समस्या पाहिलेल्या मॉडेल्सना यश मिळण्याची शक्यता अधिक असते, कारण अपुरे निर्दिष्ट केलेल्या चाचण्या पास करण्यासाठी आवश्यक अतिरिक्त माहिती त्यांच्याकडे असते.
याचा अर्थ असा की SWE-बेंच व्हेरिफाइड वरील सुधारणा आता मॉडेल्सच्या वास्तविक जगातील सॉफ्टवेअर विकास क्षमतांमधील अर्थपूर्ण सुधारणा दर्शवत नाहीत. त्याऐवजी, प्रशिक्षणाच्या वेळी मॉडेलला बेंचमार्कचा किती संपर्क आला होता हे ते अधिकाधिक प्रतिबिंबित करतात. म्हणूनच आम्ही SWE-बेंच व्हेरिफाइड स्कोअर्सचा अहवाल देणे थांबवले आहे, आणि आम्ही इतर मॉडेल डेव्हलपर्सनाही तसेच करण्याची शिफारस करतो.
आम्ही कोडिंग क्षमतांचा अधिक चांगल्या प्रकारे मागोवा घेण्यासाठी नवीन, दूषित नसलेली मूल्यमापने तयार करत आहोत, आणि व्यापक संशोधन समुदायासाठी हे लक्ष केंद्रित करण्याचे एक महत्त्वाचे क्षेत्र आहे असे आम्हाला वाटते. तोपर्यंत, OpenAI SWE-बेंच Pro साठी निकाल अहवालित करण्याची शिफारस करते.
मूळ SWE-बेंच(नवीन विंडोमध्ये उघडेल) मूल्यांकन 2023 मध्ये प्रकाशित झाले. प्रत्येक समस्या 12 ओपन-सोर्स Python रिपॉझिटरींपैकी एका मधील निराकरण झालेल्या GitHub issue मधून घेतली जाते आणि संबंधित pull request (PR) सोबत जोडली जाते. मॉडेल-निर्मित कोड बदल योग्य आहे की नाही हे ठरवण्यासाठी, प्रत्येक समस्येसोबत चाचण्यांचे दोन संच असतात:
- अपरिवर्तित कोडबेसवर अयशस्वी होणाऱ्या परंतु समस्या योग्य प्रकारे दुरुस्त केल्यास यशस्वी होणाऱ्या चाचण्या
- असंबंधित कार्यक्षमता अबाधित राहते याची खात्री करण्यासाठी निराकरणापूर्वी आणि नंतर दोन्ही वेळा पास होणाऱ्या रिग्रेशन चाचण्या.
मॉडेल चाचण्या पाहत नाही. मूळ इश्यू मजकूर आणि फिक्सपूर्वीची रिपॉझिटरीची स्थिती एवढेच दिले असताना त्याने कोड बदल तयार करणे आवश्यक आहे. कोड बदल लागू केल्यानंतर सर्व चाचण्या पास झाल्या तरच ते समस्या पास करते.
आम्हाला त्या मूल्यांकनात अनेक समस्या आढळल्या, ज्यामुळे मॉडेल्सच्या क्षमतेचे कमी अहवाल देणे होऊ शकते.
- काही युनिट चाचण्या खूपच विशिष्ट होत्या किंवा कार्याशी विसंगत होत्या, त्यामुळे योग्य दुरुस्त्या नाकारल्या जाऊ शकत होत्या.
- अनेक काम विधाने अपुरी निर्दिष्ट केली होती, ज्यामुळे अनेक वैध अर्थ लावणे शक्य होते, परंतु चाचण्यांनी फक्त एका विशिष्ट अर्थलावण्यालाच कव्हर केले होते.
- पर्यावरणाच्या (उदाहरणार्थ Linux विरुद्ध Windows, किंवा python version) सेटअपनुसार, काही चाचण्या अनपेक्षितपणे अपयशी ठरू शकतात
या समस्यांना सामोरे जाण्यासाठी आम्ही 2024 मध्ये SWE-बेंच सत्यापित तयार केले. आम्ही तज्ज्ञ सॉफ्टवेअर अभियंत्यांसोबत काम करून 1,699 SWE-बेंच समस्यांचे पुनरावलोकन केले आणि ज्यामध्ये या समस्या होत्या अशा समस्या वगळल्या. प्रत्येक समस्येचे तीन तज्ज्ञांनी स्वतंत्रपणे पुनरावलोकन केले. या पुनरावलोकन प्रक्रियेचा परिणाम SWE-बेंच सत्यापित, 500 समस्यांचा एक क्युरेट केलेला संच, असा झाला.
SWE-बेंच व्हेरिफाइड ही सुरुवातीच्या आवृत्तीपेक्षा मोठी सुधारणा असली तरी, काही उरलेल्या समस्या अजूनही आहेत. OpenAI o3 ने 64 स्वतंत्र रनमध्ये सातत्याने सोडवले नाहीत अशा 138 SWE-बेंच व्हेरिफाइड समस्यांचे आम्ही ऑडिट केले. प्रत्येक प्रकरणाचे किमान सहा अनुभवी सॉफ्टवेअर अभियंत्यांनी स्वतंत्रपणे पुनरावलोकन केले. जर एखाद्या तज्ज्ञाने एखादा मुद्दा फ्लॅग केला असेल, तर तो अतिरिक्त टीमद्वारे पुनःसत्यापित करण्यात आला.
आम्हाला आढळले की 138 समस्यांपैकी 59.4% समस्यांमध्ये चाचणी डिझाइन आणि/किंवा समस्या वर्णनात महत्त्वाच्या त्रुटी होत्या, ज्यामुळे त्या सर्वात सक्षम मॉडेल किंवा मानवासाठीही सोडवणे अत्यंत कठीण किंवा अशक्य ठरते.
- 35.5% ऑडिट केलेल्या कार्यांमध्ये कठोर चाचणी प्रकरणे आहेत जी विशिष्ट अंमलबजावणी तपशीलांची अंमलबजावणी करतात, ज्यामुळे अनेक कार्यात्मकदृष्ट्या योग्य सबमिशन अवैध ठरतात, ज्यांना आम्ही अरुंद चाचणी प्रकरणे.म्हणतो.
- ऑडिट केलेल्या कार्यांपैकी 18.8% कार्यांमध्ये समस्या वर्णनात निर्दिष्ट न केलेली अतिरिक्त कार्यक्षमता तपासणाऱ्या चाचण्या आहेत, ज्यांना आम्ही व्यापक चाचणी प्रकरणेम्हणतो.
- उर्वरित 5.1% कामांमध्ये विविध प्रकारचे मुद्दे होते, जे या टॅक्सोनॉमीमध्ये नीट गटबद्ध झाले नव्हते.
पहिल्या अपयश प्रकाराचे एक स्पष्टीकरणात्मक उदाहरण म्हणजे pylint-dev__pylint-4551(नवीन विंडोमध्ये उघडेल), जिथे PR एकूण समाधानाचा भाग म्हणून `get_annotation` हे नवीन फंक्शन सादर करते. या फंक्शनचे नाव समस्या वर्णनात नमूद केलेले नाही, पण ते टेस्ट्सद्वारे थेट आयात केले जाते. काही मॉडेलना अशी फंक्शन तयार करावी असे सहज सुचू शकते, पण समस्या योग्यरीत्या हाताळण्यासाठी या विशिष्ट नावाची फंक्शन अंमलात आणणे काटेकोरपणे आवश्यक नाही. अनेक वैध समाधाने इम्पोर्ट त्रुटींमुळे चाचण्यांमध्ये अपयशी ठरतात.
समस्येचे वर्णन
PR चाचणी स्निपेट
PR चाचणी अपयश (वाचनीयतेसाठी छाटलेले)
खूपच विस्तृत टेस्ट केसेसचे एक उदाहरण म्हणजे sympy__sympy-18199(नवीन विंडोमध्ये उघडेल). हे काम `nthroot_mod` फंक्शनमधील तीन वेगळ्या समस्यांना संबोधित करणाऱ्या PR मधून घेतले गेले होते, विशेषतः #17373(नवीन विंडोमध्ये उघडेल), #17377(नवीन विंडोमध्ये उघडेल), आणि #18212(नवीन विंडोमध्ये उघडेल). तथापि, SWE-बेंच व्हेरिफाइड टास्कचे वर्णन फक्त अंतिम इश्यू #18212(नवीन विंडोमध्ये उघडेल) कव्हर करते. यामुळे विसंगती निर्माण होते: PR चाचण्या तिन्ही समस्यांना कव्हर करतात, तर वर्णनात केवळ एका समस्येचा तपशील आहे. आमच्या रनमध्ये, मॉडेल्स अनेकदा वर्णन केलेली दुरुस्ती योग्यरीत्या लागू करतात आणि नंतर इतर दोन समस्यांसाठीच्या अंमलबजावणीला कव्हर करणाऱ्या चाचण्यांमध्ये अपयशी ठरतात.
मूळ PR चे वर्णन (GitHub PR वरून)
#18212 साठी समस्येचे वर्णन
SWE-बेंच व्हेरिफाइड कार्यासाठी समस्या वर्णन (फक्त #18212 मधून घेतलेले):
SWE-बेंच व्हेरिफाइड आणि रिपॉझिटरीज (कोड बेस आणि रिलीज नोट्स) दोन्ही ओपन-सोर्स आहेत आणि व्यापकपणे वापरल्या व चर्चिल्या जातात, ज्यामुळे मॉडेल डेव्हलपर्ससाठी दूषितता टाळणे कठीण होते.
आम्हाला प्रथम आमच्या स्वतःच्या मॉडेल्समध्ये दूषिततेची चिन्हे आढळली. उदाहरणार्थ, जेव्हा GPT‑5.2 ने आम्ही जवळजवळ अशक्य मानलेली 31 कामे सोडवली. django__django-14725(नवीन विंडोमध्ये उघडेल) मध्ये चाचण्यांसाठी `edit_only` हा एक विशिष्ट नवीन पॅरामीटर आवश्यक आहे, जो समस्या विधानात स्पष्टपणे नमूद केलेला नाही. समस्या सोडवताना, GPT‑5.2 त्याच्या चेन-ऑफ-थॉटमध्ये दाखवते की त्याच्याकडे रिलीज नोट्सबद्दल माहिती आहे ज्या कोडबेसमधील बदलांचे तपशील देतात, आणि `edit_only` पॅरामीटर Django 4.1 मध्ये सादर करण्यात आला होता हे योग्यरीत्या ओळखते.
GPT‑5.2 CoT
दूषण किती महत्त्वाचे आहे याचे अधिक व्यापक मूल्यांकन करण्यासाठी, आम्ही एक स्वयंचलित रेड टीमिंग सेटअप तयार केला. प्रत्येक SWE-बेंच व्हेरिफाइड प्रश्नासाठी, आम्ही GPT‑5 ला GPT‑5.2‑Chat, Claude Opus 4.5 आणि Gemini 3 Flash Preview मधील दूषितता तपासण्याचे काम सोपवले. हे मॉडेल्स रीझनिंग मॉडेल्स वगळण्यासाठी निवडले गेले, परंतु आम्ही मान्य करतो की त्यांच्यात कदाचित महत्त्वाचे क्षमता अंतर आहे.
दूषितता तपासण्यासाठी, GPT‑5 ला मिळाले: SWE-बेंच व्हेरिफाइड कार्याचे ID, वर्णन, गोल्ड पॅच, आणि PR चाचण्या. 15 पेक्षा जास्त टर्न्समध्ये, आम्ही GPT‑5 ला सिस्टम/डेव्हलपर प्रॉम्प्ट, वापरकर्ता प्रॉम्प्ट, आणि सहाय्यक प्रीफिल तसेच वेगवेगळ्या एलिसिटेशन रणनीती बदलू दिल्या. प्रत्येक टर्ननंतर, “मॉडेल” नावाच्या जज मॉडेलने किती नवीन टास्क-विशिष्ट माहिती दिसली याचे लेबल लावले आणि प्रत्येक प्रतिसादाला “none” ते “strong” पर्यंतच्या कंटॅमिनेशन तीव्रतेसाठी लेबल लावले. GPT‑5 ला मागील टर्न्सच्या आधारे त्याची रणनीती अनुकूलित करण्याची परवानगी देण्यात आली, जेणेकरून टास्क-विशिष्ट तपशील पुनरावृत्तीने पुनर्प्राप्त करता येतील. मजबूत दूषणाच्या प्रत्येक उदाहरणासाठी, आम्ही दुसऱ्या न्यायाधीशासोबत सत्यापित केले की GPT‑5 ने लक्ष्य मॉडेलला खूप जास्त माहिती लीक केली नाही. शेवटी, आम्ही या पोस्टमधील ट्रान्सक्रिप्ट्स बनवणाऱ्या “strong” उदाहरणांचे व्यक्तिचलितपणे पुनरावलोकन केले.
खाली विविध मॉडेल प्रदात्यांमध्ये मजबूत दूषिततेची उदाहरणे दिली आहेत.
कार्याच्या वर्णनातील एक छोटा तुकडा दिल्यास, GPT‑5.2 अचूक गोल्ड पॅच आउटपुट करते. विशेषतः, त्याला अचूक class आणि method नाव माहीत आहे, आणि नव्याने सादर केलेली early return अट `if username is None or password is None` देखील माहीत आहे.
टास्क आयडी: django__django-11451(नवीन विंडोमध्ये उघडेल)
दूषितता काढणे
गोल्ड पॅच
Opus केवळ PR ने सादर केलेला अचूक चार-ओळींचा कार्यात्मक बदल, त्याने स्पर्श केलेले विशिष्ट फाइलनाव आणि पद्धत यांसह आठवतो असे नाही, तर डिफचा भाग असलेली इनलाइन टिप्पणीही शब्दशः उद्धृत करतो.
टास्क आयडी: astropy__astropy-13236(नवीन विंडोमध्ये उघडेल)
दूषितता काढणे
गोल्ड पॅच
Gemini 3 Flash, जेव्हा ID व्यतिरिक्त कार्याबद्दल कोणतीही अतिरिक्त माहिती दिली जात नाही, तेव्हा कार्य वर्णन आणि गोल्ड पॅचमधील तपशील शब्दशः आउटपुट करू शकतो. यामध्ये वापरकर्तानाव पडताळणीसाठीचे नवीन regex सूत्र आणि बदलासाठीचे अचूक ओळ क्रमांक समाविष्ट आहेत.
टास्क आयडी: django__django-11099(नवीन विंडोमध्ये उघडेल)
दूषितता काढणे
सुवर्ण पॅच
SWE-बेंच सत्यापित केलेल्या या ऑडिटमधून, मूल्यांकन डिझाइनसाठी आपल्याला दोन व्यापक धडे दिसतात. प्रथम, सार्वजनिकरीत्या उपलब्ध सामग्रीतून घेतलेल्या बेंचमार्क्समध्ये दूषितीकरणाचा धोका असतो, ज्यामध्ये प्रशिक्षण-डेटाचा संपर्क गुणांकनांना नकळत फुगवू शकतो. जर सार्वजनिकरीत्या क्रॉल केलेला डेटा बेंचमार्क तयार करण्यासाठी वापरला जात असेल, तर मॉडेल डेव्हलपर्सनी दूषितीकरणासाठी अतिरिक्त चाचण्या कराव्यात. बेंचमार्क, आणि त्यांची सोल्यूशन्ससुद्धा, सार्वजनिकरित्या पोस्ट केल्यास ते प्रशिक्षण डेटामध्ये जाऊ शकतात. डेटासेट कसे पोस्ट केले जातात याबाबत (उदा. पासवर्डने संरक्षित) आणि प्रशिक्षण डेटा फिल्टरिंग (उदा. कॅनरी स्ट्रिंग्जचे कठोर पालन).
दुसरे म्हणजे, स्वयंचलित स्कोअरिंग अचूक करणे कठीण असते; परिपूर्ण चाचणी प्रकरणांनी योग्य कार्यक्षमता पूर्णपणे पडताळली पाहिजे, विशिष्ट गौण अंमलबजावणी तपशीलांबाबत तटस्थ राहून आणि शॉर्टकट उपायांबाबतही मजबूत राहून. या समस्या स्वभावतः जटिल आणि सोडविण्यास कठीण आहेत. या समस्या पकडण्यासाठी अनेक व्यापक मानवी लेबलिंग मोहिमा राबवाव्या लागल्या.
आम्ही हे निष्कर्ष आमच्या अलीकडील मूल्यांकन प्रयत्नांमध्ये समाविष्ट केले आहेत. मागील काही महिन्यांत आम्ही SWE-बेंच Pro च्या सार्वजनिक विभाजनातून मिळालेल्या निकालांचा अहवाल देणे निवडले आहे. आम्ही इतर मॉडेल डेव्हलपर्सनाही तेच करण्याची शिफारस करतो. SWE-बेंच Pro परिपूर्ण नाही, पण अनुभवजन्यदृष्ट्या प्रदूषण समस्यांमुळे कमी त्रास होतो असे दिसते. आमच्या दूषितता पाइपलाइनला दूषिततेची काही प्रकरणे आढळली, पण ही प्रकरणे SWE-बेंच व्हेरिफाइड पेक्षा लक्षणीयरीत्या अधिक दुर्मिळ आणि कमी गंभीर होती, आणि कोणतेही मॉडेल पूर्णपणे शब्दशः gold patch तयार करू शकले नाही.
आम्ही मूळ, खाजगीरित्या तयार केलेल्या बेंचमार्क्समध्ये गुंतवणूक करत राहू आणि उद्योग व शैक्षणिक क्षेत्राकडूनही त्याच प्रकारे मदत मागू. GDPVal मध्ये, कामे डोमेन तज्ज्ञांकडून खाजगीरित्या तयार केली जातात, ज्यामुळे उघडकीचा धोका कमी होतो, आणि उपाय प्रशिक्षित पुनरावलोककांकडून सर्वांगीण दृष्टिकोनातून ग्रेड केले जातात. हा दृष्टिकोन साधनसंपत्तीच्या दृष्टीने खर्चिक आहे, परंतु क्षमतांमधील खऱ्या सुधारणा मोजण्यासाठी तो अधिकाधिक आवश्यक ठरत आहे.


