← नवीनतम पेपर
💻 computer science

Code Reasoning for Software Engineering Tasks: A Survey and A Call to Action

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

मूल लेखक: Saurabh Pujar, Ira Ceka, Irene Manotas, Gail Kaiser, Baishakhi Ray, Shyam Ramji

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

मूल लेखक: Saurabh Pujar, Ira Ceka, Irene Manotas, Gail Kaiser, Baishakhi Ray, Shyam Ramji

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

कल्पना कीजिए कि आपके पास एक बहुत ही बुद्धिमान, सुशिक्षित सहायक (एक लार्ज लैंग्वेज मॉडल, या LLM) है जो कहानियाँ लिखने में तो बहुत अच्छा है, लेकिन जब उसे कंप्यूटर कोड लिखने के लिए कहा जाता है, तो वह कभी-कभी संघर्ष करता है। कोड पेचीदा होता है क्योंकि एक कहानी के विपरीत, इसे पूरी तरह से सही होना चाहिए अन्यथा यह टूट जाता है।

यह शोध पत्र एक सर्वेक्षण (एक बड़ी समीक्षा) है कि कैसे शोधकर्ता इन AI सहायकों को कोड लिखने से पहले बेहतर तरीके से "सोचना" सिखा रहे हैं। IBM और कोलंबिया यूनिवर्सिटी के लेखकों ने दर्जनों नई विधियों का अध्ययन किया यह देखने के लिए कि कौन सी विधियाँ वास्तव में AI को सॉफ्टवेयर इंजीनियरिंग की समस्याओं, जैसे बग्स को ठीक करने या नई सुविधाएँ बनाने में मदद करती हैं।

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

1. समस्या: "प्रथम ड्राफ्ट" का जाल (The "First Draft" Trap)

सामान्यतः, जब आप किसी AI को कोड लिखने के लिए कहते हैं, तो वह एक छात्र की तरह व्यवहार करता है जो परीक्षा दे रहा हो: वह प्रश्न पढ़ता है और तुरंत अपना पहला उत्तर लिख देता है। यदि वह उत्तर गलत है, तो वह समाप्त है।

  • पेपर का अंतर्दृष्टि (Insight): सबसे अच्छे परिणाम तब आते हैं जब हम AI को अंतिम कोड लिखने से पहले रुकने और सोचने के लिए मजबूर करते हैं। इसे "टेस्ट-टाइम रीजनिंग" (test-time reasoning) कहा जाता है। यह एक छात्र से गणित के सवाल का उत्तर केवल अनुमान लगाने के बजाय, अपना काम (steps) दिखाने के लिए कहने जैसा है।

2. टूलकिट: AI को सोचने के चार तरीके

लेखकों ने सभी नई विधियों को चार मुख्य श्रेणियों में व्यवस्थित किया है, जिसे वे "रीजनिंग टूलकिट" कहते हैं:

  • चेन-ऑफ-थॉट (CoT): "चरण-दर-चरण योजनाकार" (The "Step-by-Step Planner")

    • उपमा: समाधान पर सीधे कूदने के बजाय, AI को पहले एक योजना लिखने के लिए कहा जाता है।
    • ट्विस्ट: पेपर में पाया गया कि संरचना-आधारित योजनाएं (structure-based plans) अस्पष्ट योजनाओं (vague plans) की तुलना में बेहतर काम करती हैं।
    • उदाहरण: एक अस्पष्ट योजना कहती है, "घर बनाओ।" एक संरचना-आधारित योजना कहती है, "पहले नींव (कंक्रीट) बिछाएं, फिर दीवारों का ढांचा (लकड़ी) तैयार करें, फिर छत डालें।" क्योंकि कोड के सख्त नियम होते हैं (जैसे एक घर), इसलिए कोड की संरचनाओं (लूप्स, फंक्शन्स) के संदर्भ में सोचना AI के लिए केवल कोड के बारे में कहानी लिखने की तुलना में अधिक मददगार होता है।
  • सेल्फ-रिफाइनमेंट (Self-Refinement): "संपादक और डिबगर" (The "Editor and Debugger")

    • उपमा: AI एक ड्राफ्ट लिखता है, यह देखने के लिए उसे चलाता है कि क्या वह क्रैश होता है, त्रुटि संदेश (error message) पढ़ता है, और फिर अपने काम को ठीक करता है।
    • परिणाम: यह एक बड़ा विजेता था। पेपर में पाया गया कि AI को अपना कोड "चलाने" देने और अपनी गलतियों को खुद ठीक करने (Self-Refinement) से अक्सर केवल एक बेहतर योजना बनाने की तुलना में बेहतर परिणाम मिलते हैं। यह एक लेखक की तरह है जो एक पैराग्राफ लिखता है, उसे ज़ोर से पढ़ता है, महसूस करता है कि यह अजीब लग रहा है, और तुरंत उसे फिर से लिखता है।
  • इन्फरेंस स्केलिंग (Inference Scaling): "कई रास्तों को आज़माने" की रणनीति

    • उपमा: एक उत्तर लिखने के बजाय, AI कोड के दस अलग-अलग संस्करण बनाता है, उन सभी को चलाता है, और उनमें से उस एक को चुनता है जो सबसे अच्छा काम करता है।
    • परिणाम: यह एक जासूस की तरह है जो अपराध सुलझाने के लिए दस अलग-अलग सिद्धांतों को आज़माता है। पेपर में पाया गया कि कई विकल्प उत्पन्न करना और सबसे अच्छे की तलाश करना अक्सर पहली बार में ही सही होने की कोशिश करने से बेहतर परिणाम देता है।
  • SWE एजेंट्स (SWE Agents): "प्रोजेक्ट मैनेजर" (The "Project Manager")

    • उपमा: यह सबसे उन्नत विधि है। AI केवल एक लेखक नहीं है; यह एक प्रोजेक्ट मैनेजर है। इसके पास एक योजना है, यह कोड लिखता है, परीक्षण (tests) चलाता है, बग्स को ठीक करता है, और अपने काम की जाँच करने के लिए उपकरणों (जैसे कंप्यूटर टर्मिनल) का उपयोग करता है।
    • परिणाम: ये "एजेंट्स" वर्तमान में विजेता (champions) हैं। योजना बनाना, आत्म-सुधार और टूल के उपयोग को मिलाकर, वे अकेले किसी भी विधि की तुलना में कठिन समस्याओं (जैसे वास्तविक दुनिया के सॉफ्टवेयर बग्स को ठीक करना) को बेहतर ढंग से हल करते हैं।

3. क्या सबसे अच्छा काम करता है? ("स्वर्ण नियम")

लेखकों ने इन विधियों की कई अलग-अलग परीक्षणों में तुलना की और स्पष्ट विजेता पाए:

  • कोड संरचना की जीत: कोड के बारे में एक इमारत (लूप्स और फंक्शन्स जैसे विशिष्ट भागों के साथ) की तरह सोचना, एक कहानी की तरह सोचने की तुलना में बेहतर काम करता है।
  • परीक्षण की जीत: वे विधियाँ जो त्रुटियों की जाँच करने के लिए वास्तव में कोड को चलाती हैं (Self-Refinement), केवल कोड के बारे में सोचने की तुलना में अधिक शक्तिशाली हैं।
  • संयोजन की जीत: सबसे अच्छे सिस्टम केवल एक ट्रिक का उपयोग नहीं करते; वे उन सभी को मिला देते हैं (योजना + चलाना + ठीक करना + खोजना)।

4. क्या गायब है? ("कार्रवाई का आह्वान")

पेपर बताता है कि जबकि हम AI को कोड लिखने में बेहतर बना रहे हैं, हम अभी भी कुछ महत्वपूर्ण हिस्सों को खो रहे हैं:

  • बहुत अधिक परीक्षण, पर्याप्त विविधता नहीं: अधिकांश शोधकर्ता इन AI टूल्स को केवल सरल "कोड जनरेशन" कार्यों (एक छोटा फंक्शन लिखना) पर टेस्ट करते हैं। हमें ऐसे परीक्षणों की आवश्यकता है जो यह जाँच सकें कि क्या AI जटिल, वास्तविक दुनिया के सॉफ्टवेयर इंजीनियरिंग कार्यों को संभाल सकता है, जैसे कि एक विशाल, अव्यवस्थित (messy) कोडबेस में बग को ठीक करना।
  • त्रुटि रिकवरी (Error Recovery): हमारे पास ऐसे तरीके नहीं हैं जो यह परीक्षण कर सकें कि क्या AI गलती करने पर उबर सकता है। हमें ऐसे बेंचमार्क की आवश्यकता है जो विशेष रूप से यह परीक्षण करें कि एक विफलता के बाद AI कितनी अच्छी तरह "अपने पैरों पर वापस खड़ा" हो सकता है।
  • यूनिट टेस्ट से परे: वर्तमान में, AI मुख्य रूप से यह जाँचने के लिए यूनिट टेस्ट (एक छोटे हिस्से की जाँच करना) का उपयोग करता है कि कोड काम करता है या नहीं। पेपर सुझाव देता है कि हमें AI को अन्य चीजों के लिए भी प्रशिक्षित करने की आवश्यकता है, जैसे सुरक्षा (security), गति (speed), और कोड के विभिन्न हिस्से एक साथ कितनी अच्छी तरह काम करते हैं।

सारांश

संक्षेप में, यह पेपर कहता है: AI को कोडिंग में अच्छा बनाने के लिए, केवल इसे लिखने के लिए न कहें; इसे योजना बनाने, चलाने, परीक्षण करने और ठीक करने के लिए कहें। आज के सबसे सफल AI "कोडर" वे हैं जो इंजीनियरों की एक टीम की तरह कार्य करते हैं—सावधानी से योजना बनाना, अपने काम की जाँच करना और कई समाधानों को आज़माना—बजकर केवल एक ऐसी मशीन के जो केवल वही थूकती है जो उसके मन में पहला विचार आता है। लेखक आशा करते हैं कि यह समीक्षा अन्य शोधकर्ताओं को भविष्य में और भी स्मार्ट, अधिक विश्वसनीय कोडिंग सहायक बनाने में मदद करेगी।

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

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

Digest आज़माएँ →