← नवीनतम पेपर
🤖 AI

Towards Comprehensive Benchmarking Infrastructure for LLMs In Software Engineering

यह शोध पत्र सॉफ्टवेयर इंजीनियरिंग के लिए वर्तमान लार्ज लैंग्वेज मॉडल मूल्यांकन में महत्वपूर्ण कमियों की पहचान करता है और BEHELM को पेश करता है, जो एक समग्र बेंचमार्किंग इंफ्रास्ट्रक्चर है जिसे निष्पक्ष, यथार्थवादी और पुनरुत्पादनीय मूल्यांकन सक्षम करने के लिए सॉफ्टवेयर-परिदृश्य विशिष्टताओं को मल्टी-मैट्रिक आकलन के साथ एकीकृत करने के लिए डिज़ाइन किया गया है।

मूल लेखक: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

प्रकाशित 2026-01-30
📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

मूल लेखक: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप यह आंकने की कोशिश कर रहे हैं कि "रोबोट शेफ" (कोड के लिए लार्ज लैंग्वेज मॉडल्स) की एक नई पीढ़ी खाना बनाने में कितनी अच्छी है। अभी, उन्हें टेस्ट करने का तरीका कुछ ऐसा है जैसे उनसे बस एक प्याज काटने के लिए कहना और देखना कि क्या वे इसे जल्दी करते हैं। यदि वे प्याज काट लेते हैं, तो हम उन्हें एक गोल्ड स्टार देते हैं।

लेकिन वास्तविक दुनिया में, एक शेफ सिर्फ प्याज नहीं काटता; वे पूरे किचन को संभालते हैं, जटिल रेसिपी का पालन करते हैं, घर को जलाने से बचने के लिए मसालेदार सामग्री को संभालते हैं, और एक टीम के साथ काम करते हैं। यह पेपर तर्क देता है कि हमारे वर्तमान "प्याज काटने वाले" टेस्ट बहुत सरल हैं। वे बड़ी तस्वीर को मिस कर देते हैं, और इस कारण से, हमें वास्तव में यह पता नहीं चलता कि क्या ये रोबोट शेफ वास्तविक डिनर सर्विस संभालने के लिए तैयार हैं।

यहाँ सरल उपमाओं (analogies) का उपयोग करके पेपर के मुख्य बिंदुओं का विवरण दिया गया है:

1. समस्या: "ड्राइविंग टेस्ट" बहुत आसान है

वर्तमान में, हम इन AI मॉडल्स को छोटे, अलग-थलग कार्यों (जैसे कोड का एक छोटा सा हिस्सा लिखना) के साथ टेस्ट करते हैं।

  • उपमा: यह एक ड्राइवर को ऐसा टेस्ट देने जैसा है जहाँ उसे केवल एक खाली पार्किंग लॉट में 5 मील प्रति घंटे की गति से गाड़ी चलानी है। वे शानदार तरीके से पास हो जाते हैं। लेकिन इससे यह पता नहीं चलता कि क्या वे भारी ट्रैफिक, खराब मौसम, या हाईवे पर अचानक ब्रेक फेल होने जैसी स्थितियों को संभाल सकते हैं।
  • वास्तविकता: पेपर कहता है कि वर्तमान टेस्ट "सैचुरेटेड" (तृप्त) हो चुके हैं। रोबोटों ने इन आसान पार्किंग लॉट टेस्ट के उत्तर रट लिए हैं। जब आप उन्हें वास्तविक दुनिया की समस्या (जैसे एक विशाल, अव्यवस्थित सॉफ्टवेयर प्रोजेक्ट में बग ठीक करना) देते हैं, तो वे अक्सर विफल हो जाते हैं क्योंकि वे केवल पैटर्न को रट रहे थे, न कि वास्तव में एक सॉफ्टवेयर इंजीनियर की तरह "सोचना" सीख रहे थे।

2. हमारे टेस्टिंग इंफ्रास्ट्रक्चर में तीन बड़े छेद

लेखकों ने पाया कि हमारे वर्तमान टेस्टिंग इंफ्रास्ट्रक्चर के टूटने के तीन मुख्य कारण हैं:

  • छेद #1: "संदर्भ" (रेसिपी बुक) की कमी
    • समस्या: वर्तमान टेस्ट केवल कोड को देखते हैं। वे सॉफ्टवेयर प्रोजेक्ट के बाकी हिस्सों को अनदेखा करते हैं।
    • उपमा: कल्पना कीजिए कि आप एक शेफ से सूप बनाने के लिए कह रहे हैं, लेकिन आप उसे केवल सामग्री की सूची देते हैं। आप उसे बर्तन, चूल्हा, रेसिपी बुक, या यह निर्देश नहीं देते कि वह सूप बाकी भोजन में कैसे फिट होता है। वास्तविक सॉफ्टवेयर इंजीनियरिंग अव्यवस्थित होती है; इसमें इतिहास, टीम कमेंट्स और विशिष्ट नियम शामिल होते हैं। हमारे टेस्ट उस "किचन के शोर-शराबे" को अनदेखा करते हैं, इसलिए रोबोटों को यह नहीं परखा जाता कि वे वास्तविक अराजकता को कैसे संभालते हैं।
  • छेद #2: गलत स्कोरकार्ड (द "पास/फेल" ट्रैप)
    • समस्या: हम मुख्य रूप से "सटीकता" (क्या यह काम किया? हाँ/नहीं) या "टेक्स्ट समानता" (क्या यह उत्तर जैसा दिखता है?) का उपयोग करते हैं।
    • उपमा: कल्पना कीजिए कि आप एक छात्र के निबंध को ग्रेड दे रहे हैं। यदि छात्र एक ऐसा पैराग्राफ लिखता है जो व्याकरणिक रूप से एकदम सही है लेकिन कहता कुछ भी गलत है, या यदि वे एक शानदार समाधान लिखते हैं जो शिक्षक के उत्तर कुंजी से अलग दिखता है, तो हमारे वर्तमान टेस्ट उन्हें गलत घोषित कर सकते हैं। हमें उन्हें इस आधार पर ग्रेड देना चाहिए कि उन्होंने इसे क्यों लिखा (व्याख्यात्मकता/interpretability), उन्होंने इसे कितनी तेजी से किया (दक्षता/efficiency), और क्या वे सभी के प्रति निष्पक्ष थे (पूर्वाग्रह/bias), न कि केवल इस आधार पर कि अंतिम शब्द गणना मेल खाती है या नहीं।
  • छेद #3: हर कोई अपना खुद का टेस्ट ट्रैक बना रहा है (द "कोई मानक नहीं" समस्या)
    • समस्या: प्रत्येक रिसर्च टीम अपना टेस्ट शून्य से बनाती है। एक टीम कीचड़ भरा ट्रैक उपयोग करती है, दूसरी पक्की सड़क, और तीसरी ट्रेडमिल।
    • उपमा: यह उन रेस कार ड्राइवरों की तुलना करने जैसा है जहाँ एक धूल भरे ट्रैक पर गाड़ी चलाता है, दूसरा बर्फ पर, और तीसरा हाईवे पर। आप यह नहीं कह सकते कि कौन सबसे अच्छा ड्राइवर है क्योंकि स्थितियाँ पूरी तरह से अलग हैं। पेपर कहता है कि हम इन ट्रैकों को बार-बार बनाने में बहुत अधिक समय और पैसा बर्बाद करते हैं, बजाय इसके कि एक मानकीकृत, उच्च-गुणवत्ता वाला ट्रैक हो जिसे हर कोई उपयोग करे।

3. समाधान: BEHELM (एक "ऑल-इन-वन" टेस्टिंग सेंटर)

इसे ठीक करने के लिए, लेखक BEHELM नामक एक नया इंफ्रास्ट्रक्चर प्रस्तावित करते हैं। इसे एक अत्याधुनिक ड्राइविंग एकेडमी के रूप में सोचें जो एक साथ ड्राइवर के कौशल के हर पहलू का परीक्षण करती है।

केवल एक टेस्ट के बजाय, BEHELM एक ग्रिड बनाता है जो जाँचता है:

  • परिदृश्य (Scenario): क्या हम कोड जनरेशन, बग फिक्सिंग, या ट्रांसलेशन का परीक्षण कर रहे हैं?
  • भाषा (Language): क्या यह Python, Java, या C++ है?
  • विवरण का स्तर (Detail Level): क्या हम एक शब्द, एक पूरी फ़ाइल, या एक पूरा प्रोजेक्ट देख रहे हैं?
  • मेट्रिक्स (Metrics): केवल "पास/फेल" के बजाय, यह मॉडल को निम्नलिखित पर ग्रेड देता है:
    • सटीकता (Accuracy): क्या यह काम किया?
    • दक्षता (Efficiency): क्या इसने बहुत अधिक कंप्यूटर पावर का उपयोग किया?
    • व्याख्यात्मकता (Interpretability): क्या हम समझ सकते हैं कि इसने यह विकल्प क्यों चुना?
    • निष्पक्षता और पूर्वाग्रह (Fairness & Bias): क्या इसने सभी उपयोगकर्ताओं के साथ समान व्यवहार किया?
    • मजबूती (Robustness): क्या अजीब इनपुट मिलने पर यह क्रैश हो गया?

निचोड़ (The Bottom Line)

पेपर निष्कर्ष निकालता है कि हमें AI कोड मॉडल्स को केवल "ऑटो-कंप्लीट" टूल्स की तरह मानना बंद करना होगा जिन्हें सरल क्विज़ की आवश्यकता है। हमें उन्हें पेशेवर सॉफ्टवेयर इंजीनियरों की तरह मानना होगा।

BEHELM एक मानकीकृत, व्यापक परीक्षण सुविधा बनाने का प्रस्ताव है जो यह जाँचता है कि क्या ये मॉडल वास्तव में वास्तविक दुनिया के जटिल सॉफ्टवेयर किचन में जीवित रह सकते हैं, न कि केवल एक पार्किंग लॉट टेस्ट पास कर सकते हैं। लक्ष्य यह सुनिश्चित करना है कि जब हम इन रोबोटों को वास्तविक नौकरियों के लिए भरोसा करें, तो वे वास्तव में काम के लिए तैयार हों।

अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?

आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।

Digest आज़माएँ →