Beyond Resolution Rates: Behavioral Drivers of Coding Agent Success and Failure
9,374 कोडिंग एजेंट प्रक्षेप पथों (trajectories) का यह बड़े पैमाने पर अनुभवजन्य अध्ययन यह प्रकट करता है कि जबकि पैच जटिलता कार्य की कठिनाई को समझाने में विफल रहती है, सफलता मुख्य रूप से अंतर्निहित LLM की क्षमताओं और प्री-एडिटिंग संदर्भ संग्रह एवं सत्यापन जैसी विशिष्ट व्यवहार संबंधी रणनीतियों द्वारा संचालित होती है, न कि फ्रेमवर्क डिज़ाइन या सरल प्रक्षेप पथ लंबाई द्वारा।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपने सॉफ़्टवेयर कोड की एक विशाल, जटिल लाइब्रेरी में बग्स को ठीक करने के लिए रोबोट इंटर्न की एक टीम को काम पर रखा है। ये केवल साधारण स्क्रिप्ट नहीं हैं; ये उन्नत AI दिमागों (लार्ज लैंग्वेज मॉडल्स) द्वारा संचालित "कोडिंग एजेंट" हैं जो फाइलों को पढ़ सकते हैं, टेस्ट चला सकते हैं और इंसानी डेवलपर्स की तरह ही कोड एडिट कर सकते हैं।
मुख्य सवाल जो शोधकर्ताओं ने पूछा था वह था: "क्यों इनमें से कुछ रोबोट सफल होते हैं जबकि अन्य विफल हो जाते हैं, भले ही वे एक ही समस्याओं पर काम कर रहे हों?"
उन्होंने केवल अंतिम स्कोर को नहीं देखा (क्या उन्होंने ठीक किया? हाँ/नहीं)। इसके बजाय, उन्होंने रोबोटों के काम करने के पूरे चलचित्र (मूवी) को देखा, और लगभग 10,000 प्रयासों का विश्लेषण किया। यहाँ उन्होंने क्या खोजा, जिसे सरल उपमाओं (analogies) के माध्यम से समझाया गया है।
1. "सिंपल फिक्स" का जाल (क्यों आसान कार्य कठिन होते हैं)
आप सोच सकते हैं कि कोई कार्य आसान है यदि उसे ठीक करने के लिए केवल कोड की एक लाइन बदलने की आवश्यकता हो। यह एक मैकेनिक के कहने जैसा है, "बस इस एक बोल्ट को कस दें।"
- निष्कर्ष: शोधकर्ताओं ने पाया कि 12 ऐसे कार्य थे जिन्हें इंसानों द्वारा "आसान" लेबल किया गया था क्योंकि उनमें केवल बहुत छोटे कोड परिवर्तन की आवश्यकता थी। फिर भी, हर एक रोबोट इन कार्यों में विफल रहा।
- उपमा: एक कार की कल्पना करें जो स्टार्ट नहीं हो रही है क्योंकि बैटरी खत्म हो गई है। एक "सिंपल फिक्स" केवल बैटरी बदलना है। लेकिन यदि रोबोट मैकेनिक यह सोचता है कि समस्या इंजन में है और वह इंजन को फिर से बनाने की कोशिश करता है, तो वह विफल हो जाएगा, भले ही फिक्स बहुत सरल था।
- असली कारण: रोबोट इसलिए विफल हुए क्योंकि उनमें आर्किटेक्चरल रीजनिंग (संरचनात्मक तर्क) की कमी थी। वे यह नहीं समझ सके कि बड़ी तस्वीर में समस्या वास्तव में कहाँ स्थित है। उन्होंने मूल कारण (बैटरी) के बजाय लक्षण (इंजन) को ठीक करने की कोशिश की। वे जानते थे कि कोड कैसे टाइप करना है, लेकिन यह नहीं जानते थे कि कोड वास्तव में क्यों टूटा हुआ था।
2. "लंबा होना बुरा है" का मिथक (लंबाई का जाल)
एक लोकप्रिय धारणा थी कि यदि कोई रोबोट किसी समस्या को हल करने में लंबा समय (कई स्टेप्स) लेता है, तो वह संघर्ष कर रहा है और उसके विफल होने की संभावना अधिक है। यह सोचने जैसा है, "यदि एक छात्र 10 मिनट के गणित परीक्षण के लिए 3 घंटे लेता है, तो शायद उसने उसे गलत किया है।"
- निष्कर्ष: यह वास्तव में एक चाल है!
- परिदृश्य A (एक रोबट को देखते हुए): यदि आप एक रोबोट को देखते हैं, तो हाँ, उसके असफल प्रयास आमतौर पर सफल प्रयासों की तुलना में लंबे होते हैं।
- परिदृश्य B (उसी समस्या को देखते हुए): लेकिन यदि आप उसी कठिन समस्या को देखते हैं और विभिन्न रोबोटों की तुलना करते हैं, तो सफल रोबोटों ने विफल होने वालों की तुलना में अधिक स्टेप्स लिए थे।
- उपमा: एक भूलभुलैया (maze) के बारे में सोचें।
- यदि आप एक खराब नेविगेटर हैं, तो आप बहुत देर तक भटक सकते हैं और खो सकते हैं (लंबा रास्ता = विफलता)।
- लेकिन यदि भूलभुलैया अत्यधिक कठिन है, तो सबसे स्मार्ट नेविगेटर को भी बाहर निकलने का रास्ता खोजने के लिए एक लंबा, सावधानीपूर्वक रास्ता तय करना होगा। "छोटा" रास्ता उस रोबोट द्वारा लिया गया था जिसने बहुत जल्दी हार मान ली या गलत अनुमान लगाया।
- सबक: रोबोट को इस आधार पर न आंकें कि उसे कितना समय लगता है। उसे इस आधार पर आंकें कि वह अपना समय कैसे बिताता है।
3. गुप्त नुस्खा: वे अपना समय कैसे बिताते हैं
शोधकर्ताओं ने पाया कि रोबोट के काम की संरचना उसकी लंबाई से अधिक मायने रखती है। उन्होंने तीन "आदतों" की पहचान की जो विजेताओं को हारने वालों से अलग करती हैं:
- लिखने से पहले पढ़ें: विजेताओं ने कोड को पढ़ने और संदर्भ (context) को समझने में अपने पहले कुछ स्टेप्स बिताए। हारने वाले तुरंत कोड एडिट करने में कूद पड़े।
- उपमा: एक अच्छा शेफ नमक डालने से पहले सूप को चखता है। एक बुरा शेफ तुरंत उसमें नमक डाल देता है।
- एडिट्स की स्पैमिंग न करें: हारने वाले एक ही गलती को बार-बार करने की प्रवृत्ति रखते थे—कोड एडिट करना, एरर मिलना और बिना सोचे-समझे फिर से एडिट करना।
- उपमा: यह एक अटके हुए जार को खोलने के लिए उसे 28 बार हथौड़े से मारने जैसा है। विजेता रुक जाता, किसी औज़ार की तलाश करता, या मदद मांगता।
- गहन परीक्षण (Test) करें: विजेताओं ने यह सुनिश्चित करने के लिए बहुत समय लगाया कि उनका फिक्स वास्तव में काम कर रहा है। हारने वाले अक्सर इसे छोड़ देते थे या बहुत देर से करते थे।
महत्वपूर्ण रूप से: ये आदतें स्थिर (fixed) थीं। एक रोबोट यह नहीं कहता था, "यह एक कठिन समस्या है, इसलिए मैं अधिक पढ़ूँगा।" उसका बस एक व्यक्तित्व (personality) था। कुछ रोबोट "रीडर" (पाठक) थे, और कुछ "हैमर" (हथौड़ा चलाने वाले) थे। "रीडर" अधिक बार जीतते थे।
4. दिमाग बनाम शरीर (LLM बनाम फ्रेमवर्क)
अंत में, उन्होंने पूछा: "क्या अधिक महत्वपूर्ण है? दिमाग (AI मॉडल) या शरीर (वह सॉफ़्टवेयर फ्रेमवर्क जो टूल्स को थामे रखता है)?"
- निष्कर्ष: दिमाग ही सब कुछ है।
- उपमा: एक नौसिखिया ड्राइवर द्वारा चलाई जा रही फॉर्मूला 1 कार (फ्रेमवर्क) बनाम एक विश्व चैंपियन द्वारा चलाई जा रही फॉर्मूला 1 कार की कल्पना करें।
- यदि आप एक विश्व चैंपियन को एक पुरानी बेकार कार (sedan) में भी रख दें, तो वह अभी भी एक नौसिखिए द्वारा चलाई जा रही फेरारी से बेहतर ड्राइव करेगा।
- शोधकर्ताओं ने पाया कि यदि आप AI "दिमाग" को एक स्मार्ट दिमाग से बदल देते हैं, तो रोबोट बहुत बेहतर हो जाता है, चाहे वह किसी भी सॉफ़्टवेयर "शरीर" में हो।
- जैसे-जैसे AI दिमाग स्मार्ट होते जाते हैं, अलग-अलग सॉफ़्टवेयर बॉडीज के बीच का अंतर समाप्त होता जाता है। एक स्मार्ट दिमाग एक साधारण शरीर को भी चैंपियन की तरह प्रदर्शन करने के योग्य बना सकता है।
सारांश: हमें क्या करना चाहिए?
यह पेपर हमें बताता है कि बेहतर कोडिंग रोबोट बनाने के लिए, हमें केवल अपने सॉफ़्टवेयर टूल्स को अधिक शानदार बनाने या उन्हें लंबे निर्देश देने पर ध्यान केंद्रित नहीं करना चाहिए।
- दिमाग को अपग्रेड करें: हमें अधिक स्मार्ट AI मॉडल की आवश्यकता है जो यह समझ सकें कि सॉफ़्टवेयर कैसे काम करता है, न कि केवल कोड कैसे टाइप करना है।
- अच्छी आदतें सिखाएं: हमें रोबोट को पहले पढ़ना, फिर एडिट करना और अक्सर टेस्ट करना सिखाने की आवश्यकता है।
- समय से निर्णय न लें: एक लंबी प्रक्रिया आवश्यक रूप से बुरी नहीं होती; एक जल्दबाजी वाली प्रक्रिया अक्सर घातक होती है।
संक्षेप में: यह इस बारे में नहीं है कि रोबोट कितनी तेज़ी से दौड़ता है; यह इस बारे में है कि क्या उसे पता है कि वह कहाँ जा रहा है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।