कोडिंग मूल्यमापनांमधून सिग्नल आणि गोंगाट वेगळे करणे

योग्य उपयोजन आणि सुरक्षा निर्णयांसाठी, OpenAI च्या प्रिपेयर्डनेस फ्रेमवर्क⁠(नवीन विंडोमध्ये उघडेल) अंतर्गत घेतल्या जाणाऱ्या निर्णयांसह, आमच्या मॉडेल्सच्या क्षमतांचे अचूक मापन महत्त्वाचे आहे. प्रत्येक मॉडेल प्रकाशनासोबत, मॉडेलची प्रगती मोजण्यासाठी आम्ही विविध बाह्य आणि अंतर्गत बेंचमार्कचे निकाल नोंदवतो. निकालांवर परिणाम करणाऱ्या त्रुटी मूल्यमापनांत असतील, तर त्या क्षमतांविषयी चुकीचा समज निर्माण करू शकतात, सुरक्षा प्रकरणांचे चुकीचे चित्र देऊ शकतात आणि संशोधन प्राधान्यांवर परिणाम करू शकतात.

आम्ही अलीकडे तपासले की सर्वाधिक वापरल्या जाणाऱ्या कोडिंग बेंचमार्कपैकी एक असलेल्या SWE-bench Verified मध्ये मूलभूत रचना आणि दूषिततेच्या समस्या होत्या आणि eval आता सॉफ्टवेअर विकास क्षमतांबद्दल अर्थपूर्ण सिग्नल देत नाही असे आढळले. त्या वेळी, आम्ही व्यापक समुदायाला 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-आधारित तपासकर्ता एजंट्सद्वारे केले जाते; त्यांना कार्याच्या रिपॉझिटरीचा आणि वातावरणाचा प्रवेश दिलेला असतो. यामुळे त्यांना जवळचा कोड आणि रिपॉझिटरी परंपरा अभ्यासून अनेकदा सोडवता येणारी वाजवी कार्य-अस्पष्टता आणि खरी अपुरी निर्दिष्टता यांत फरक करता येतो. एजंट चाचण्या चालवू शकतो, repo मधील फाइल्स तपासू शकतो आणि कार्यावरील मॉडेलचे प्रयत्न व त्यांचे सामान्य अपयश प्रकार तपासू शकतो. या सखोल ऑडिट्सच्या अनेक स्वतंत्र पुनरावृत्त्यांनंतर, एका संशोधकाने सारांशांचे पुनरावलोकन केले, अंतिम निर्णय घेतला आणि संभाव्य समस्यांना लेबल लावले.

समांतरपणे, आम्ही फ्लॅग केलेल्या उपसंचावर मानवी अ‍ॅनोटेशन मोहीम चालवली. कार्यांचे पुनरावलोकन करण्यापूर्वी बेंचमार्कची उद्दिष्टे, समस्या वर्गीकरण आणि सीमावर्ती प्रकरणे यांचे प्रशिक्षण दिलेल्या अनुभवी सॉफ्टवेअर अभियंत्यांसोबत आम्ही काम केले. प्रत्येक कार्याचे पाच अभियंत्यांनी पुनरावलोकन केले.

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

तपासकर्ता एजंट्सपेक्षा मानवी पुनरावलोकन करणाऱ्यांनी कार्ये बिघडलेली म्हणून चिन्हांकित करण्याची शक्यता अधिक होती. दोन पुनरावलोकन मार्गांमध्ये श्रेणींबाबत काही मतभेदही होते, पण कोणत्याही फ्लॅग केलेल्या कार्यात “बिघडलेले नाही” हे सर्वाधिक सामान्य मानवी लेबल नव्हते. एजंट पाइपलाइनने फ्लॅग केलेल्या श्रेणींपैकी 74% प्रकरणांत पुनरावलोकन करणाऱ्यांचे निर्णय जुळले.

एजंट पाइपलाइनच्या तुलनेत, मानवी पुनरावलोकन करणाऱ्यांनी एखाद्या कार्यासाठी अनेक लेबले निवडण्याची शक्यताही अधिक होती; यावरून त्यांना कार्ये अनेक प्रकारे बिघडलेली वाटली किंवा ती एका श्रेणीत स्पष्टपणे बसत नव्हती असे दिसते. यावरून एजंट-आणि-पुनरावलोकन करणाऱ्यांच्या पाइपलाइनने संयमी लेबलिंग केले असे दिसते: तिने मानवांनी ओळखलेलेच व्यापक अपयश प्रकार पकडले, पण पुनरावलोकन करणाऱ्यांना अतिरिक्त किंवा एकमेकीत गुंतलेल्या समस्या दिसलेल्या प्रकरणांची मोजणी कमी झाली. सर्वात मोठा फरक कमी कव्हरेजच्या चाचण्यांत होता: एजंट पाइपलाइनकडून 4.1% च्या तुलनेत मानवांनी 9.4% बेंचमार्कमध्ये हा सर्वात सामान्य मुद्दा म्हणून निवडला.

आम्ही ओळखलेल्या समस्या, SWE-bench Verified मधील समान प्रकरणांसह, बेंचमार्कची काटेकोर तपासणी करण्याचे महत्त्व अधोरेखित करतात. ओपन-सोर्स रिपॉझिटरीजमधील समस्या आणि pull requests मूलतः मानवी सहकार्यासाठी तयार झाल्या होत्या, अनेकदा मेंटेनर्स आणि योगदानकर्त्यांमधील दीर्घ संवादांतून. परिणामी, समस्या-वर्णने, मर्ज केलेला कोड आणि युनिट चाचण्या मॉडेल्सचे विश्वसनीय मूल्यमापन करण्यासाठी स्पष्ट, स्वतंत्र कार्ये तयार करण्याइतक्या नेहमीच सुसंगत नसतात. विशेषतः, pull requests मध्ये समाविष्ट चाचण्या अतिशय कठोर असू शकतात, कारण त्या कार्य सोडवण्यासाठी अंमलबजावणी-निरपेक्ष मानक ठरवण्याऐवजी विशिष्ट बदलाची पडताळणी करण्यासाठी लिहिलेल्या असतात.

त्याच वेळी, अगदी अलीकडच्या काळाच्या तुलनेतही मूल्यमापनातील त्रुटी आता शोधणे सोपे झाले आहे. मॉडेल क्षमतांमध्ये सुधारणा होत असताना, आपण ती मॉडेल्स प्रॉम्प्ट्स, चाचण्या, पॅचेस, ट्रेसेस आणि सीमावर्ती प्रकरणे अधिक खोलीने व सातत्याने तपासण्यासाठी वापरू शकतो, ज्यामुळे पूर्वी मोठ्या प्रमाणावर शोधणे खर्चिक किंवा अव्यवहार्य असलेल्या बेंचमार्क समस्या समोर येण्यास मदत होते.

विस्तृत मूल्यमापन समुदाय अनुभवी सॉफ्टवेअर डेव्हलपर्सनी खास मॉडेल क्षमतांची चाचणी करण्यासाठी तयार केलेले नवे बेंचमार्क्स विकसित करेल अशी आम्हाला आशा आहे. हा दृष्टिकोन मॉडेल क्षमतांचे मापन करताना आपल्याला हवे असलेले उच्च निकष आणि वास्तववाद टिकवू शकतो आणि संपूर्ण प्रक्रियेत अधिक चांगली मानवी देखरेख शक्य करतो. या विश्लेषणात उघड झालेल्या समस्यांमुळे, SWE-Bench Pro स्वीकारण्याची आमची आधीची शिफारस आम्ही मागे घेतो.

शेवटी, eval ने असे बेंचमार्क वापरून अर्थपूर्ण संकेत द्यायला हवेत जे फसवणे कठीण, विश्वास ठेवणे सोपे, आणि मॉडेल क्षमता किंवा अलाईनमेंटचे खरे प्रतिबिंब असतील. हे निकाल OpenAI च्या उपयोजन आणि सुरक्षा निर्णयांना माहिती देतात, त्यामुळे आम्ही मागोवा घेत असलेले evals वैध आणि माहितीपूर्ण असणे आवश्यक आहे.