अगस्त 2024 में जब से हमने पहली बार SWE-बेंच वेरिफ़ाइड प्रकाशित किया, उद्योग ने स्वायत्त सॉफ़्टवेयर इंजीनियरिंग कार्यों पर मॉडलों की प्रगति को मापने के लिए इसका व्यापक रूप से उपयोग किया है. इसके रिलीज़ के बाद, SWE-बेंच वेरिफ़ाइड ने क्षमता प्रगति का एक मजबूत संकेत प्रदान किया और अत्याधुनिक मॉडल रिलीज़ में रिपोर्ट किया जाने वाला एक मानक मेट्रिक बन गया. इन क्षमताओं की प्रगति को ट्रैक करना और उसका पूर्वानुमान लगाना OpenAI के प्रिपेयर्डनेस फ़्रेमवर्क का भी एक महत्वपूर्ण हिस्सा है. जब हमने शुरुआत में Verified बेंचमार्क बनाया, तो हमने मूल मूल्यांकन में मौजूद उन समस्याओं को हल करने की कोशिश की जिनकी वजह से SWE-bench dataset(एक नई विंडो में खुलेगा) में कुछ कार्यों को पूरा करना असंभव हो जाता था.
शुरुआती छलांगों के बाद, SWE-बेंच वेरिफ़ाइड पर अत्याधुनिक प्रगति धीमी हो गई है, पिछले 6 महीनों में 74.9% से 80.9% तक सुधरते हुए(एक नई विंडो में खुलेगा) . यह सवाल उठता है: क्या बाकी बची विफलताएँ मॉडल की सीमाओं को दर्शाती हैं या स्वयं डेटासेट के गुणों को?
एक नए विश्लेषण में, हमें सत्यापित सेट के साथ दो प्रमुख समस्याएँ मिलीं, जो संकेत देती हैं कि आज के परफ़ॉर्मेंस स्तरों पर अत्याधुनिक लॉन्च के लिए स्वायत्त सॉफ़्टवेयर इंजीनियरिंग क्षमताओं में प्रगति को मापने के लिए यह बेंचमार्क अब उपयुक्त नहीं रहा:
- टेस्ट सही समाधानों को अस्वीकार करते हैं: हमने डेटासेट के 27.6% सबसेट का ऑडिट किया, जिसे मॉडल अक्सर सॉल्व नहीं कर पाते थे। हमने पाया कि कम से कम 59.4% ऑडिट की गई समस्याओं में गलत टेस्ट केस थे, जो फंक्शनली सही सबमिशन को रिजेक्ट कर देते हैं, भले ही SWE-बेंच वेरिफाइड को शुरू में बनाने में हमने इसे बेहतर बनाने की पूरी कोशिश की थी.
- समाधानों पर प्रशिक्षण: क्योंकि बड़े अत्याधुनिक मॉडल अपने प्रशिक्षण से जानकारी सीख सकते हैं, इसलिए यह महत्वपूर्ण है कि उन्हें कभी भी उन समस्याओं और समाधानों पर प्रशिक्षित न किया जाए जिन पर उनका मूल्यांकन किया जाता है. यह ठीक वैसा है जैसे किसी आने वाले टेस्ट से पहले स्टूडेंट्स के साथ टेस्ट के सवाल और उनके समाधान साझा करना - वे शायद उत्तर रटें नहीं, लेकिन जिन स्टूडेंट्स ने पहले से जवाब देखे हैं वे निश्चित रूप से उन लोगों से बेहतर करेंगे जिन्होंने नहीं देखे हैं. SWE-bench समस्याएं उन ओपन-सोर्स रिपॉज़िटरी से ली गई हैं जिनका कई मॉडल प्रदाता ट्रेनिंग उद्देश्यों के लिए उपयोग करते हैं. हमारे विश्लेषण में हमने पाया कि जिन सभी अत्याधुनिक मॉडल का हमने परीक्षण किया, वे मूल, मानव-लिखित बग फिक्स को—जिसे ग्राउंड-ट्रुथ रेफ़रेंस के रूप में इस्तेमाल किया गया था, जिसे गोल्ड पैच कहा जाता है—या कुछ टास्क्स के लिए प्रॉब्लम स्टेटमेंट की विशिष्ट बातों को शब्दशः पुन: प्रस्तुत करने में सक्षम थे, जो यह संकेत देता है कि ट्रेनिंग के दौरान उन सभी ने कम-से-कम कुछ समस्याएं और समाधान देखे हैं.
हमें इस बात के भी सबूत मिले कि जिन मॉडल्स ने ट्रेनिंग के दौरान प्रॉब्लम्स को देखा है, उनके सफल होने की संभावना ज़्यादा होती है, क्योंकि उनके पास अंडरस्पेसिफाइड टेस्ट्स को पास करने के लिए ज़रूरी एक्स्ट्रा जानकारी होती है.
इसका मतलब है कि SWE-बेंच वेरिफ़ाइड पर सुधार अब मॉडल की वास्तविक दुनिया की सॉफ़्टवेयर विकास क्षमताओं में सार्थक सुधार को नहीं दर्शाते हैं. इसके बजाय, वे बढ़ते हुए इस बात को दर्शाते हैं कि ट्रेनिंग के समय मॉडल को बेंचमार्क के संपर्क में कितना लाया गया था. इसी वजह से हमने SWE-बेंच वेरिफ़ाइड स्कोर की रिपोर्टिंग बंद कर दी है, और हम सुझाव देते हैं कि अन्य मॉडल डेवलपर्स भी ऐसा ही करें.
हम कोडिंग क्षमताओं को बेहतर ढंग से ट्रैक करने के लिए नए, बिना मिलावट वाले मूल्यांकन बना रहे हैं, और हमें लगता है कि बड़े रिसर्च समुदाय के लिए इस पर ध्यान देना एक महत्वपूर्ण क्षेत्र है. जब तक हमारे पास वे नहीं होते, OpenAI SWE-बेंच प्रो के लिए परिणाम रिपोर्ट करने की सलाह देता है.
मूल SWE-bench(एक नई विंडो में खुलेगा) मूल्यांकन 2023 में जारी किया गया था. हर समस्या 12 ओपन-सोर्स Python रिपॉज़िटरी में से किसी एक में एक resolved GitHub issue से ली गई है और संबंधित pull request (PR) के साथ जोड़ी गई है. यह निर्धारित करने के लिए कि मॉडल-जनरेटेड कोड परिवर्तन सही है या नहीं, प्रत्येक समस्या के साथ परीक्षणों के दो सेट आते हैं:
- ऐसे परीक्षण जो बिना बदले हुए कोडबेस पर विफल हो जाते हैं, लेकिन अगर समस्या को सही तरीके से ठीक किया जाए तो पास हो जाते हैं
- असंबंधित कार्यक्षमता को बरकरार रखने के लिए, फिक्स से पहले और बाद में पास होने वाले रिग्रेशन टेस्ट.
मॉडल परीक्षण नहीं देखता. इसे केवल मूल समस्या पाठ और फिक्स से पहले रिपॉज़िटरी की स्थिति के आधार पर एक कोड बदलाव तैयार करना होता है. यह किसी समस्या को तभी पास करता है जब कोड बदलाव लागू करने के बाद सभी परीक्षण पास हो जाएँ.
हमें उस मूल्यांकन में कई समस्याएँ मिलीं, जो मॉडलों की क्षमता को कम रिपोर्ट किए जाने का कारण बन सकती हैं.
- कुछ यूनिट टेस्ट बहुत अधिक विशिष्ट थे या कार्य के साथ असंगत थे, जिससे सही सुधार भी अस्वीकार किए जा सकते थे.
- कई टास्क स्टेटमेंट ठीक से नहीं बताए गए थे, जिससे कई सही मतलब निकाले जा सकते थे - जबकि टेस्ट में सिर्फ़ एक खास मतलब ही कवर किया गया था.
- पर्यावरण के सेटअप (उदाहरण के लिए Linux बनाम Windows, या python संस्करण) के आधार पर, कुछ परीक्षण कभी-कभी गलत तरीके से विफल हो सकते हैं
हमने 2024 में इन समस्याओं का समाधान करने के लिए SWE-बेंच वेरिफ़ाइड बनाया. हमने विशेषज्ञ सॉफ़्टवेयर इंजीनियरों के साथ मिलकर 1,699 SWE-bench समस्याओं की समीक्षा की और उन समस्याओं को फ़िल्टर कर दिया जिनमें ये समस्याएं थीं. हर समस्या का तीन एक्सपर्ट्स द्वारा इंडिपेंडेंटली रिव्यु किया गया. इस समीक्षा प्रक्रिया के परिणामस्वरूप SWE-बेंच वेरिफ़ाइड बना, जो 500 समस्याओं का एक क्यूरेटेड सेट है.
हालाँकि SWE-बेंच वेरिफ़ाइड शुरुआती संस्करण की तुलना में एक बड़ा सुधार है, फिर भी कुछ शेष समस्याएँ बनी हुई हैं. हमने 138 SWE-बेंच वेरिफ़ाइड समस्याओं का ऑडिट किया जिन्हें OpenAI o3 ने 64 स्वतंत्र रन के दौरान लगातार हल नहीं किया. प्रत्येक केस को कम से कम छह अनुभवी सॉफ़्टवेयर इंजीनियर्स द्वारा स्वतंत्र रूप से रिव्यू किया गया था. अगर किसी एक्सपर्ट ने कोई समस्या फ़्लैग की, तो उसे एक अतिरिक्त टीम द्वारा फिर से वेरिफ़ाई किया गया.
हमने पाया कि 138 समस्याओं में से 59.4% में टेस्ट डिज़ाइन और/या समस्या विवरण में महत्वपूर्ण समस्याएँ थीं, जिससे उन्हें सबसे सक्षम मॉडल या मानव के लिए भी हल करना अत्यंत कठिन या असंभव हो गया.
- ऑडिट किए गए टास्क्स में से 35.5% में सख्त टेस्ट केस हैं जो विशिष्ट इम्प्लीमेंटेशन डिटेल्स को लागू करते हैं, जिससे कई फंक्शनली सही सबमिशन अमान्य हो जाते हैं, जिन्हें हम संकीर्ण टेस्ट केसकहते हैं.
- ऑडिट किए गए टास्क में से 18.8% में ऐसे टेस्ट हैं जो समस्या विवरण में निर्दिष्ट नहीं की गई अतिरिक्त कार्यक्षमता की जाँच करते हैं, जिन्हें हम विस्तृत टेस्ट केसकहते हैं.
- बाकी 5.1% टास्क में अलग-अलग तरह के मुद्दे थे जिन्हें इस टैक्सोनॉमी के साथ ठीक से ग्रुप नहीं किया गया था.
पहले फ़ेलियर मोड का एक व्याख्यात्मक उदाहरण है pylint-dev__pylint-4551(एक नई विंडो में खुलेगा), जहाँ PR समग्र समाधान के हिस्से के रूप में एक नया फ़ंक्शन `get_annotation` पेश करता है. इस फ़ंक्शन का नाम समस्या के विवरण में उल्लेखित नहीं है, लेकिन इसे टेस्ट्स द्वारा सीधे इम्पोर्ट किया जाता है. हालांकि कुछ मॉडल सहज रूप से ऐसा फ़ंक्शन बनाने की ओर झुक सकते हैं, लेकिन समस्या को सही ढंग से संबोधित करने के लिए इस विशिष्ट नाम वाले फ़ंक्शन को इम्प्लीमेंट करना सख्ती से आवश्यक नहीं है. कई वैलिड सॉल्यूशन इम्पोर्ट एरर्स के कारण टेस्ट में फेल हो जाते हैं.
समस्या का विवरण
PR टेस्ट स्निपेट
PR परीक्षण विफलताएँ (पठनीयता के लिए संक्षिप्त)
बहुत विस्तृत टेस्ट केस का एक उदाहरण है sympy__sympy-18199(एक नई विंडो में खुलेगा). यह टास्क एक PR से लिया गया था, जिसमें `nthroot_mod` फ़ंक्शन से जुड़ी तीन अलग-अलग समस्याओं को संबोधित किया गया था, विशेष रूप से #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 and Gemini 3 Flash Preview के लिए कंटैमिनेशन. इन मॉडलों को रीज़निंग मॉडलों को बाहर रखने के लिए चुना गया था, लेकिन हम स्वीकार करते हैं कि उनके बीच संभवतः एक गैर-तुच्छ क्षमता अंतर है.
कंटैमिनेशन की जांच करने के लिए, GPT‑5 को मिला: SWE-बेंच वेरिफ़ाइड टास्क का ID, विवरण, गोल्ड पैच, और PR टेस्ट्स. 15 से ज़्यादा टर्न्स में, हमने GPT‑5 को सिस्टम/डेवलपर प्रॉम्प्ट, यूज़र प्रॉम्प्ट, और असिस्टेंट प्रीफिल तथा अलग-अलग एलिसिटेशन रणनीतियों में बदलाव करने दिया. हर टर्न के बाद, एक जज मॉडल ने लेबल किया कि कितना नया टास्क-विशिष्ट जानकारी दिखाई दी और हर प्रतिक्रिया को “none” से “strong.” तक कंटैमिनेशन की गंभीरता के लिए लेबल किया गया. GPT‑5 को पहले के टर्न्स के आधार पर अपनी स्ट्रैटेजी को एडैप्ट करने की अनुमति थी, ताकि वह इटरेटिव तौर पर टास्क-विशिष्ट डिटेल्स को रिकवर कर सके. मज़बूत संदूषण के हर उदाहरण के लिए, हमने एक अन्य जज के साथ वेरिफ़ाई किया कि GPT‑5 ने लक्ष्य मॉडल को बहुत ज़्यादा जानकारी लीक नहीं की. अंत में, फिर हमने इस पोस्ट में मौजूद ट्रांस्क्रिप्ट बनाने वाले “strong” उदाहरणों का मैन्युअल रिव्यु किया.
नीचे अलग-अलग मॉडल प्रदाताओं में मजबूत संदूषण के उदाहरण दिए गए हैं.
टास्क विवरण से दिए गए एक छोटे स्निपेट के आधार पर, GPT‑5.2 exact gold patch आउटपुट करता है. खास तौर पर, यह सटीक class और method name, और नई early return condition `if username is None or password is None` को जानता है, जिसे पेश किया गया है.
प्रदूषण प्रेरण
गोल्ड पैच
Opus न केवल PR द्वारा पेश किए गए सटीक 4-पंक्ति कार्यात्मक परिवर्तन को, साथ ही उसने जिस विशिष्ट फ़ाइलनाम और विधि को छुआ था उसे भी, याद कर पाता है, बल्कि अंतर का हिस्सा रहे इनलाइन टिप्पणी को भी शब्दशः उद्धृत करता है.
प्रदूषण प्रेरण
गोल्ड पैच
Gemini 3 Flash, जब उसे ID के अलावा कार्य के बारे में कोई अतिरिक्त जानकारी नहीं दी जाती, तो वह कार्य विवरण और गोल्ड पैच से शब्दशः विवरण आउटपुट करने में सक्षम होता है. इसमें यूज़रनेम वैलिडेशन के लिए नया regex फ़ॉर्मूला और बदलाव के लिए सटीक लाइन नंबर शामिल हैं.
प्रदूषण प्रेरण
गोल्ड पैच
SWE-बेंच वेरिफ़ाइड के इस ऑडिट से, हम मूल्यांकन डिज़ाइन के लिए दो व्यापक सबक देखते हैं. पहला, सार्वजनिक रूप से उपलब्ध सामग्री से लिए गए बेंचमार्क में कंटैमिनेशन का जोखिम होता है, जहाँ ट्रेनिंग-डेटा एक्सपोज़र चुपचाप स्कोर बढ़ा सकता है. यदि सार्वजनिक रूप से क्रॉल किए गए डेटा का उपयोग बेंचमार्क निर्माण में किया जाता है, तो मॉडल डेवलपर्स को कंटैमिनेशन के लिए अतिरिक्त परीक्षण करने चाहिए. बेंचमार्क, और यहाँ तक कि उनके सॉल्यूशंस भी, सार्वजनिक रूप से पोस्ट किए जाने पर ट्रेनिंग डेटा में शामिल हो सकते हैं. डेटासेट कैसे पोस्ट किए जाते हैं, इसमें भी अतिरिक्त सावधानी बरती जानी चाहिए (अर्थात पासवर्ड सुरक्षा) और ट्रेनिंग डेटा फ़िल्टरिंग (अर्थात कैनेरी स्ट्रिंग्स का सख्ती से पालन).
दूसरा, ऑटोमेटेड स्कोरिंग को सही करना मुश्किल है; परफेक्ट टेस्ट केस को सही फंक्शनैलिटी को पूरी तरह से वेरिफाई करना चाहिए, जो खास गैर-ज़रूरी इम्प्लीमेंटेशन डिटेल्स से अनजान हो और शॉर्टकट सॉल्यूशन के लिए भी मज़बूत हो. ये समस्याएँ स्वभाव से ही जटिल हैं और इन्हें हल करना मुश्किल है. इन समस्याओं को पकड़ने में कई व्यापक इंसानी लेबलिंग कैंपेन लगे.
हमने इन निष्कर्षों को अपने हालिया मूल्यांकन प्रयासों में शामिल किया है. पिछले महीनों में हमने SWE-बेंच प्रो के पब्लिक स्प्लिट से परिणाम रिपोर्ट करने का विकल्प चुना है. हम सुझाव देते हैं कि अन्य मॉडल डेवलपर्स भी ऐसा ही करें. SWE-बेंच प्रो परफेक्ट नहीं है, लेकिन अनुभवजन्य रूप से लगता है कि यह कंटैमिनेशन संबंधी समस्याओं से कम प्रभावित होता है. हमारी कंटैमिनेशन पाइपलाइन ने कंटैमिनेशन के कुछ मामले पाए, लेकिन ये मामले SWE-बेंच वेरिफ़ाइड की तुलना में काफी दुर्लभ और कम गंभीर थे, और कोई भी मॉडल पूरी तरह से वर्बैटिम गोल्ड पैच तैयार नहीं कर सका.
हम ओरिजिनल, प्राइवेट तौर पर लिखे गए बेंचमार्क में इन्वेस्ट करना जारी रखेंगे और ऐसा करने के लिए इंडस्ट्री और एकेडेमिया से मदद मांगेंगे. GDPVal में, टास्क डोमेन एक्सपर्ट्स प्राइवेट तौर पर लिखते हैं, जिससे एक्सपोज़र का रिस्क कम होता है, और सॉल्यूशन को ट्रेंड रिव्यूअर्स पूरी तरह से ग्रेड करते हैं. यह दृष्टिकोण संसाधन-गहन है, लेकिन वास्तविक क्षमता सुधारों को मापने के लिए लगातार अधिक आवश्यक होता जा रहा है.


