कोडिंग मूल्यांकनों में संकेत को शोर से अलग करना

हमारे मॉडलों की क्षमताओं को सटीक रूप से मापना ठोस डिप्लॉयमेंट और सुरक्षा निर्णयों के लिए महत्वपूर्ण है, जिनमें OpenAI के प्रिपेयर्डनेस फ़्रेमवर्क⁠(एक नई विंडो में खुलेगा) के तहत लिए जाने वाले निर्णय भी शामिल हैं. हर मॉडल रिलीज़ के साथ, हम मॉडल की प्रगति को ट्रैक करने के लिए विभिन्न बाहरी और आंतरिक बेंचमार्क के परिणाम रिपोर्ट करते हैं. जब मूल्यांकनों में ऐसी खामियाँ होती हैं जो परिणामों को प्रभावित करती हैं, तो वे क्षमताओं की गलत समझ दे सकती हैं, सुरक्षा मामलों को गलत ढंग से प्रस्तुत कर सकती हैं और शोध प्राथमिकताओं को प्रभावित कर सकती हैं.

हमने हाल ही में जाँच की कि सबसे व्यापक रूप से उपयोग किए जाने वाले कोडिंग बेंचमार्कों में से एक, SWE-bench Verified, में मूलभूत डिज़ाइन और संदूषण संबंधी समस्याएँ थीं, और पाया कि यह मूल्यांकन अब सॉफ़्टवेयर विकास क्षमताओं पर सार्थक संकेत नहीं देता था. उस समय, हमने व्यापक समुदाय को SWE-Bench Pro पर जाने के लिए प्रोत्साहित किया था.

SWE-Bench Pro⁠(एक नई विंडो में खुलेगा) को SWE-bench Verified में सुधार के लिए डिज़ाइन किया गया था, ताकि मॉडलों को लंबे क्षितिज और अधिक यथार्थवादी कोडिंग कार्यों पर परखकर एजेंटिक कोडिंग क्षमताओं को बेहतर ढंग से ट्रैक किया जा सके. SWE-bench Verified की तरह, कार्य सार्वजनिक और निजी रिपॉज़िटरी के एक समूह में फीचर बदलावों के इतिहास से प्रोग्रामेटिक रूप से लिए जाते हैं. मॉडलों से अपेक्षा की जाती है कि वे ऐसा समाधान लागू करें जो मौजूदा कार्यक्षमता को तोड़े बिना किसी फीचर के लिए नए परीक्षण पास करे. 731-कार्य वाले सार्वजनिक स्प्लिट पर, अत्याधुनिक मॉडलों की पास दर आठ महीनों में 23.3% से बढ़कर 80.3% हो गई.

इसके बाद हमने SWE-Bench Pro पर भी ऐसा ही ऑडिट किया, जिसमें डेटापॉइंट विश्लेषण पाइपलाइन का उपयोग करके डेटासेट की समीक्षा की. पाइपलाइन ने संभावित मूल्यांकन खामियों को चिह्नित करने के लिए कार्य पर मॉडल के प्रयासों, कार्य मेटाडेटा और विफलता ट्रेस की समीक्षा की. फिर प्रत्येक चिह्नित कार्य का आकलन कई अन्वेषक-एजेंट पासों के माध्यम से किया गया और पाँच अनुभवी सॉफ़्टवेयर इंजीनियरों ने स्वतंत्र रूप से उसकी समीक्षा की; असहमतियों को आगे की जाँच के लिए बढ़ाया गया.

समस्याएँ मुख्य रूप से चार श्रेणियों में आईं:

• अत्यधिक सख्त परीक्षण¹ प्रॉम्प्ट में निर्दिष्ट नहीं किए गए खास कार्यान्वयन विवरण लागू करते हैं, जिससे कई कार्यात्मक रूप से सही सबमिशन अमान्य हो जाते हैं.
• अपर्याप्त रूप से निर्दिष्ट प्रॉम्प्ट² वे आवश्यकताएँ छोड़ देते हैं जिन्हें छिपे हुए परीक्षण लागू करते हैं और जिनका युक्तिसंगत अनुमान नहीं लगाया जा सकता.
• कम-कवरेज परीक्षण अनुरोधित फीचर की पर्याप्त जाँच नहीं करते, इसलिए अधूरे सुधार पास हो सकते हैं.
• भ्रामक प्रॉम्प्ट मॉडलों को गलत व्यवहार की ओर ले जाता है या परीक्षणों की अपेक्षा के विरुद्ध जाता है.

हमारे निष्कर्ष कठिन लेकिन निष्पक्ष बेंचमार्क तैयार करने की चुनौती और बड़े पैमाने पर डेटा गुणवत्ता जाँचों के लिए एजेंटों की बढ़ती उपयोगिता की ओर इशारा करते हैं. इन परिणामों के आधार पर, हमारा अनुमान है कि SWE-bench Pro के लगभग 30% कार्य त्रुटिपूर्ण हैं, और हम सलाह देते हैं कि मॉडल डेवलपर परिणामों की सावधानी से जाँच करें.

हमारा लक्ष्य यह सुनिश्चित करना है कि कार्यों में विफलताएँ वास्तविक मॉडल सीमाओं को दर्शाएँ, और कार्यों में सफलताएँ प्रॉम्प्ट आवश्यकताओं के पूर्ण और वैध समाधानों को दर्शाएँ. मूल्यांकन में उपयोग किए गए डेटा की गुणवत्ता जाँचने के लिए, हमने यह आकलन करने वाली गुणवत्ता आश्वासन पाइपलाइन बनाई कि प्रत्येक डेटापॉइंट मॉडल क्षमताओं को सही ढंग से दर्शाता है या नहीं.

एक प्रारंभिक स्वचालित फ़िल्टर मॉडल को दिए गए निर्देशों, कार्य हल करने के मॉडल के प्रयासों और इन प्रयासों को ग्रेड करने के लिए उपयोग किए गए परीक्षणों की समीक्षा करता है, ताकि संभावित रूप से त्रुटिपूर्ण या समस्याग्रस्त उदाहरणों को चिह्नित किया जा सके. इस फ़िल्टर ने 286 संभावित रूप से त्रुटिपूर्ण कार्य चिह्नित किए. इसके बाद हमने उस उपसमूह की दो तरीकों से गहन समीक्षा की: मानव-पर्यवेक्षित एजेंट समीक्षा, जिसमें अन्वेषक एजेंटों से व्यापक जाँचें कराई जाती हैं और अंत में मानव निर्णय होता है; और अनुभवी सॉफ़्टवेयर डेवलपरों के साथ मानव एनोटेशन अभियान.

हर चिह्नित समस्या का ऑडिट Codex-आधारित अन्वेषक एजेंटों से कराया जाता है, जिन्हें कार्य की रिपॉज़िटरी और परिवेश तक पहुँच दी गई थी. इससे वे युक्तिसंगत कार्य अस्पष्टता, जिसे अक्सर पास के कोड और रिपॉज़िटरी परंपराओं का अध्ययन करके हल किया जा सकता है, और वास्तविक अपर्याप्त विनिर्देशन में अंतर कर पाते हैं. एजेंट परीक्षण चला सकता है, रेपो में फ़ाइलों की जाँच कर सकता है, और कार्य पर मॉडल के प्रयासों तथा उनके सामान्य विफलता प्रकारों की पड़ताल कर सकता है. इन गहन ऑडिटों की कई स्वतंत्र पुनरावृत्तियों के बाद, एक शोधकर्ता ने सारांशों की समीक्षा की, अंतिम निर्णय लिया और संभावित समस्याओं को लेबल किया.

समानांतर रूप से, हमने चिह्नित उपसमूह पर मानव एनोटेशन अभियान चलाया. हमने अनुभवी सॉफ़्टवेयर इंजीनियरों के साथ काम किया, जिन्हें कार्यों की समीक्षा से पहले बेंचमार्क लक्ष्यों, समस्या वर्गीकरण और सीमांत मामलों पर प्रशिक्षित किया गया था. प्रत्येक कार्य की समीक्षा पाँच इंजीनियरों ने की.

समीक्षकों ने पाइपलाइन विश्लेषण या ट्रांसक्रिप्ट को सहायक संदर्भ के रूप में उपयोग करने से पहले दृश्यमान समस्या विवरण, परीक्षण मामलों और ग्राउंड-ट्रुथ संदर्भ समाधान (जिसे गोल्ड पैच कहा जाता है) से स्वतंत्र निर्णय बनाया. इसके बाद समीक्षकों ने ठोस प्रमाणों के आधार पर लेबल और गंभीरता रेटिंग दी, और असहमतियों या कम-विश्वास वाले मामलों को आगे की समीक्षा के लिए बढ़ाया.

मानव समीक्षकों ने अन्वेषक एजेंटों की तुलना में कार्यों को त्रुटिपूर्ण चिह्नित करने की अधिक संभावना दिखाई. दोनों समीक्षा मार्गों के बीच श्रेणियों पर कुछ असहमति भी थी, लेकिन किसी भी चिह्नित कार्य में “त्रुटिपूर्ण नहीं” सबसे आम मानव लेबल नहीं था. एजेंट पाइपलाइन ने जिन श्रेणियों को चिह्नित किया, उनमें समीक्षकों के निर्णय 74% मामलों में मेल खाते थे.

एजेंट पाइपलाइन की तुलना में, मानव समीक्षक किसी कार्य के लिए कई लेबल चुनने की भी अधिक संभावना रखते थे, जिससे संकेत मिलता है कि उन्हें कार्य कई तरीकों से त्रुटिपूर्ण लगे या वे किसी एक श्रेणी में साफ़ तौर पर फिट नहीं हुए. इससे पता चलता है कि एजेंट-प्लस-समीक्षक पाइपलाइन ने सावधानीपूर्ण लेबलिंग दी: उसने मनुष्यों द्वारा पहचाने गए वही व्यापक विफलता प्रकार पकड़े, जबकि उन मामलों की गिनती कम की जहाँ समीक्षकों ने अतिरिक्त या ओवरलैपिंग समस्याएँ देखीं. सबसे बड़ा अंतर कम-कवरेज परीक्षणों में था, जिन्हें मनुष्यों ने बेंचमार्क के 9.4% के लिए सबसे आम समस्या के रूप में चुना, जबकि एजेंट पाइपलाइन में यह 4.1% था.

हमने जिन समस्याओं की पहचान की है, वे SWE-bench Verified में समान मामलों के साथ मिलकर बेंचमार्क की कठोर जाँच के महत्व को रेखांकित करती हैं. ओपन-सोर्स रिपॉज़िटरी से आए इश्यू और पुल रिक्वेस्ट मूल रूप से मानव सहयोग के लिए बनाए गए थे, अक्सर मेंटेनरों और योगदानकर्ताओं के बीच लंबे संवादों के माध्यम से. नतीजतन, समस्या विवरण, मर्ज किया गया कोड और यूनिट परीक्षण हमेशा ऐसे साफ़, अलग-थलग कार्य नहीं बनाते जिनसे मॉडलों का विश्वसनीय मूल्यांकन हो सके. विशेष रूप से, पुल रिक्वेस्ट में शामिल परीक्षण अत्यधिक सख्त हो सकते हैं, क्योंकि वे कार्य हल करने के लिए कार्यान्वयन-निरपेक्ष मानक परिभाषित करने के बजाय किसी खास बदलाव को सत्यापित करने के लिए लिखे जाते हैं.

साथ ही, मूल्यांकन खामियों का पता लगाना अब थोड़े समय पहले की तुलना में भी आसान है. जैसे-जैसे मॉडल क्षमताएँ बेहतर होती हैं, हम उन मॉडलों का उपयोग प्रॉम्प्ट, परीक्षण, पैच, ट्रेस और सीमांत मामलों को कहीं अधिक गहराई और निरंतरता से जाँचने के लिए कर सकते हैं, जिससे बेंचमार्क समस्याएँ सामने लाने में मदद मिलती है जिन्हें पहले बड़े पैमाने पर खोजना महँगा या अव्यावहारिक था.

हमें उम्मीद है कि व्यापक मूल्यांकन समुदाय अनुभवी सॉफ़्टवेयर डेवलपरों द्वारा विशेष रूप से मॉडल क्षमताओं का परीक्षण करने के लिए बनाए गए नए बेंचमार्क विकसित करेगा. यह तरीका मॉडल क्षमताओं को मापने के लिए वांछित ऊँचे मानक और यथार्थवाद को बनाए रख सकता है, और पूरी प्रक्रिया में बेहतर मानव निगरानी की अनुमति देता है. इस विश्लेषण में सामने आई समस्याओं को देखते हुए, हम SWE-Bench Pro अपनाने की अपनी पिछली सिफ़ारिश वापस लेते हैं.

अंततः, किसी मूल्यांकन को ऐसे बेंचमार्कों के माध्यम से सार्थक संकेत देना चाहिए जिन्हें चकमा देना कठिन हो, जिन पर भरोसा करना आसान हो, और जो सचमुच मॉडल क्षमता या संरेखण को प्रतिबिंबित करें. क्योंकि ये परिणाम OpenAI के डिप्लॉयमेंट और सुरक्षा निर्णयों को प्रभावित करते हैं, जिन मूल्यांकनों को हम ट्रैक करते हैं उन्हें वैध और सूचनाप्रद होना चाहिए.