Benchmark · agentic
Multi-SWE-bench
Multi-SWE-bench यह मापता है कि क्या कोई AI कोडिंग एजेंट केवल Python ही नहीं, बल्कि कई रिपॉज़िटरी और प्रोग्रामिंग भाषाओं में असली GitHub issues हल कर सकता है। मुख्य मीट्रिक है resolution rate: उन टास्क इंस्टेंसेस का प्रतिशत जिनका फ़िक्स छिपे हुए टेस्ट सूट को पास करा देता है।
और पढ़ें
- उदाहरण
- एक प्रतिनिधि टास्क: Java, Go, Rust, TypeScript, JavaScript, C या C++ जैसी भाषा में लिखे किसी ओपन-सोर्स प्रोजेक्ट की असली बग रिपोर्ट या फ़ीचर अनुरोध, साथ में फ़िक्स-से-पहले वाले कमिट पर चेक-आउट की गई रिपॉज़िटरी दी जाती है, और एजेंट को एक ऐसा कोड पैच बनाना होता है जो वर्णित समस्या को हल करे।
- स्कोरिंग
- प्रत्येक इंस्टेंस को निष्पादन (execution) के ज़रिए पास/फ़ेल आधार पर आँका जाता है। एजेंट का पैच रिपॉज़िटरी पर लागू किया जाता है और प्रोजेक्ट के टेस्ट चलाए जाते हैं; इंस्टेंस तभी हल माना जाता है जब निर्दिष्ट FAIL_TO_PASS टेस्ट अब पास हों और सभी PASS_TO_PASS टेस्ट पहले की तरह पास बने रहें। रिपोर्ट किया गया स्कोर resolution rate है (हल किए गए इंस्टेंस ÷ कुल), आमतौर पर pass@1 पर, और इसे भाषा तथा विशेषज्ञों द्वारा दी गई कठिनाई (easy/medium/hard) के अनुसार विभाजित किया जा सकता है।
- सत्यापन
- स्वीकृति पूरी तरह निष्पादन-आधारित है, प्रति-इंस्टेंस एक Docker इमेज के अंदर जो भाषा की टूलचेन और डिपेंडेंसीज़ को हूबहू पुनः तैयार करती है। बनाया गया पैच बिना टकराव के लागू होना चाहिए, फिर fail-to-pass और pass-to-pass टेस्ट चलाए जाते हैं; न कोई LLM-आधारित मूल्यांकन होता है और न ही डेवलपर के गोल्ड पैच से कोई टेक्स्ट तुलना।
- यह क्यों मायने रखता है
- SWE-bench प्रभावशाली रहा पर केवल Python तक सीमित है, जबकि असली सॉफ़्टवेयर इंजीनियरिंग कई भाषाओं में फैली है। Multi-SWE-bench जाँचता है कि कोडिंग एजेंट प्रामाणिक issues पर भाषाओं के आर-पार सामान्यीकरण करते हैं या नहीं, विशेषज्ञ कठिनाई लेबल के साथ, जिससे व्यावहारिक सॉफ़्टवेयर-इंजीनियरिंग क्षमता का अधिक कठिन, यथार्थवादी और कम संतृप्त संकेत मिलता है।
हल किया गया उदाहरण
कार्य
Multi-SWE-bench फ़ॉर्मैट में एक उदाहरणात्मक इंस्टेंस — भाषा: Go, एक छोटी जेनेरिक-कलेक्शन लाइब्रेरी। problem_statement: «खाली स्टैक पर Stack.Pop() शून्य मान और nil एरर लौटाता है, जिससे कॉल करने वाले कोड की बग चुपचाप छिप जाती है; इसके बजाय इसे सेंटिनल ErrEmpty लौटाना चाहिए।» आपको बग वाले बेस कमिट पर रिपॉज़िटरी और फ़ेल होता टेस्ट दिया जाता है। FAIL_TO_PASS: TestPopEmptyReturnsError। PASS_TO_PASS: TestPushThenPop, TestLen। एक ऐसा पैच जमा करें जो फ़ेल होते टेस्ट को पास करा दे और पास होते टेस्ट न टूटें।
समाधान
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}व्याख्या
यह फ़िक्स Pop में एक खाली-जाँच जोड़ता है जो ठीक वैसे ही सेंटिनल ErrEmpty (टाइप के शून्य मान के साथ) लौटाता है जैसा TestPopEmptyReturnsError अपेक्षा करता है, जबकि सामान्य पॉप-पथ को अपरिवर्तित रखता है ताकि TestPushThenPop और TestLen पास बने रहें। ग्रेडिंग विशुद्ध रूप से निष्पादन-आधारित है: हार्नेस इंस्टेंस की Docker इमेज में पैच लागू करता है और इंस्टेंस को तभी हल के रूप में चिह्नित करता है जब FAIL_TO_PASS टेस्ट पास होने लगे और कोई भी PASS_TO_PASS टेस्ट पीछे न हटे।
इस benchmark के लिए अभी तक कोई सत्यापित स्कोर रिपोर्ट नहीं किया गया है।