Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents
यह शोध पत्र एजेंट-जनित परीक्षणों के LLM-आधारित सॉफ्टवेयर इंजीनियरिंग में अनुमानित मूल्य को चुनौती देता है, यह प्रदर्शित करते हुए कि हालांकि ऐसे परीक्षण अक्सर लिखे जाते हैं, वे मुख्य रूप से कठोर सत्यापन के बजाय केवल अवलोकन संबंधी फीडबैक के रूप में कार्य करते हैं, और प्रॉम्प्ट हस्तक्षेपों के माध्यम से उनके वॉल्यूम में हेरफेर करने से अंतिम समस्या-समाधान परिणामों पर महत्वपूर्ण प्रभाव नहीं पड़ता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक जटिल, टूटे हुए कार इंजन (जो एक सॉफ्टवेयर कोडबेस में बग का प्रतिनिधित्व करता है) को ठीक करने के लिए सुपर-स्मार्ट, AI-संचालित मैकेनिकों की एक टीम को काम पर रख रहे हैं।
लंबे समय से, उद्योग का यह विश्वास रहा है: "कार को अच्छी तरह से ठीक करने के लिए, मैकेनिक को पहले एक विस्तृत चेकलिस्ट लिखनी चाहिए और कई डायग्नोस्टिक टेस्ट चलाने चाहिए।" तर्क यह है कि यदि मैकेनिक एक टेस्ट लिखता है, तो वह पूरी तरह से जांच कर रहा है, और कार निश्चित रूप से ठीक हो जाएगी।
यह शोध पत्र एक सरल, उत्तेजक प्रश्न पूछता है: "क्या वे सभी टेस्ट लिखना वास्तव में मैकेनिक को कार ठीक करने में मदद कर रहा है, या वे केवल समय और ईंधन बर्बाद कर रहे हैं?"
यहाँ शोधकर्ताओं ने जो पाया है, उसका विवरण कुछ रोजमर्रा के उदाहरणों का उपयोग करके दिया गया है।
1. "ओवर-प्रिपेयर" (अति-तैयारी करने वाला) बनाम "गट-फीलर" (अंतर्ज्ञान पर चलने वाला)
शोधकर्ताओं ने छह अलग-अलग AI "मैकेनिकों" (लार्ज लैंग्वेज मॉडल्स) को 500 अलग-अलग सॉफ्टवेयर समस्याओं को ठीक करने की कोशिश करते हुए देखा।
- द ओवर-प्रिपेयर (जैसे, क्लॉड ओपस 4.5): इस AI ने 83% कार्यों में नई टेस्ट फाइलें लिखीं। यह लगातार चेकलिस्ट लिखने, डायग्नोस्टिक्स चलाने और अपने काम को दोबारा जांचने में लगा रहता था।
- द गट-फीलर (जैसे, GPT-5.2): इस AI ने लगभग कभी भी नए टेस्ट नहीं लिखे (केवल 0.6% समय में)। इसने बस समस्या को देखा, गहराई से सोचा और उसे ठीक करना शुरू कर दिया।
चौंकाने वाला परिणाम: दोनों मैकेनिकों ने लगभग समान संख्या में कारें ठीक कीं (लगभग 72–74%)। जिसने सभी टेस्ट लिखे, उसने बिना टेस्ट लिखे वाले मैकेनिक से बेहतर काम नहीं किया। वास्तव में, "गट-फीलर" ने कागजी कार्रवाई को छोड़कर बहुत सारा समय और पैसा बचाया।
2. वे "टेस्ट" वास्तव में क्या कर रहे थे?
शोधकर्ताओं ने AI द्वारा लिखे गए टेस्टों का बारीकी से निरीक्षण किया। उन्हें उम्मीद थी कि वे सख्त "पास/फेल" चेकलिस्ट देखेंगे (जैसे: "यदि इंजन शोर करता है, तो टेस्ट फेल हो जाता है" )।
इसके बजाय, उन्होंने पाया कि AI मुख्य रूप से टेस्ट का उपयोग टॉर्च (flashlight) के रूप में कर रहा था, न कि एक जज के रूप में।
- उपमा: कल्पना कीजिए कि एक मैकेनिक इंजन के एक हिस्से पर टॉर्च चमका रहा है और कह रहा है, "हे, यह बोल्ट ढीला है," या "तेल का दबाव 40 psi है।"
- वास्तविकता: AI मुख्य रूप से "प्रिंट स्टेटमेंट" (टॉर्च चमकाना) लिख रहा था ताकि यह देख सके कि कोड के अंदर क्या हो रहा है। इसने शायद ही कभी सख्त "असर्टions" (वास्तविक पास/फेल नियम) लिखे। यह कोड को देखने (observe) के लिए टेस्ट का उपयोग कर रहा था, न कि यह निर्णय (judge) करने के लिए कि क्या सुधार एकदम सही है।
3. "प्रॉम्ट एक्सपेरिमेंट" (निर्देश प्रयोग)
यह सुनिश्चित करने के लिए, शोधकर्ताओं ने AI के साथ एक चाल चली। उन्होंने AI को दिए गए निर्देशों (प्रॉम्ट) को बदल दिया:
- ग्रुप A: "कृपया जितने हो सके उतने टेस्ट लिखें!"
- ग्रुप B: "कोई भी नया टेस्ट न लिखें; बस बग को ठीक करें।"
परिणाम:
- क्या सफलता दर बदली? नहीं। AI को टेस्ट लिखने के लिए मजबूर करने से इसने अधिक बग ठीक नहीं किए। इसे टेस्ट लिखने से रोकने से इसने कम बग ठीक नहीं किए। अंतिम परिणाम लगभग समान था।
- क्या लागत बदली? बहुत ज्यादा।
- जब उन्होंने AI को टेस्ट लिखने के लिए मजबूर किया, तो इसने 20% अधिक कंप्यूटर पावर (टोकन) खर्च की और सर्वर को अधिक फोन कॉल (API कॉल्स) किए।
- जब उन्होंने AI को टेस्ट न लिखने के लिए कहा, तो इसने गुणवत्ता में लगभग बिना किसी गिरावट के, बहुत सारा पैसा और समय बचाया।
मुख्य निष्कर्ष: "आदत बनाम रणनीति"
शोध पत्र निष्कर्ष निकालता है कि इन AI एजेंटों के लिए, टेस्ट लिखना एक आदत बन गया है, न कि एक रणनीति।
इसे एक छात्र के गणित की परीक्षा देने जैसा समझें।
- पुराना तरीका: छात्र सोचता है, "मुझे यह साबित करने के लिए एक अलग शीट पर अपना काम दिखाना चाहिए कि मैं स्मार्ट हूँ।"
- वास्तविकता: छात्र वास्तव में खुद को सोचने में मदद करने के लिए नोट्स लिख रहा है, लेकिन वह अलग शीट वास्तव में उसे सही उत्तर तक तेजी से पहुँचने में मदद नहीं कर रही है। वास्तव में, वह अतिरिक्त शीट लिखना उसे धीमा कर रहा है और उसके परीक्षा के समय का उपयोग कर रहा है।
भविष्य के लिए इसका क्या अर्थ है:
- AI को टेस्ट लिखने के लिए मजबूर न करें। यदि आप AI को "टेस्ट लिखें" कहते हैं, तो यह केवल आपका पैसा बर्बाद कर सकता है बिना समस्या को बेहतर ढंग से ठीक किए।
- "टॉर्च" (Flashlight) पर ध्यान दें। AI कोड को देखने (अवलोकन) के लिए टेस्ट का उपयोग करने में अच्छा है। हमें इसे कोड को जज करने (सख्त सत्यापन) के लिए टेस्ट का उपयोग करना सिखाने की आवश्यकता है।
- बजट बचाएं। यदि आप AI के साथ सॉफ्टवेयर बना रहे हैं, तो आप "पहले टेस्ट लिखें" वाले चरण को हटा सकते हैं और बहुत सारा पैसा बचा सकते हैं, जब तक कि आपके पास यह जांचने के अन्य तरीके हों कि सुधार काम कर रहा है या नहीं।
संक्षेप में: सिर्फ इसलिए कि एक AI टेस्ट लिख रहा है, इसका मतलब यह नहीं है कि वह बेहतर काम कर रहा है। कभी-कभी, वह केवल कागजी कार्रवाई भर रहा होता है जबकि असली काम कहीं और हो रहा होता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।