Execution Grounded Multiagent Systems for Reliable Backend Code Generation with Large Language Models'
यह शोध पत्र ExecuGraph प्रस्तुत करता है, जो एक कॉन्फ़िगर करने योग्य ढांचा है जो यह प्रदर्शित करता है कि निष्पादन फीडबैक (execution feedback) बड़े भाषा मॉडलों में कोड जनरेशन की सटीकता में सुधार का प्राथमिक चालक है, जबकि यह भी दिखाता है कि मल्टी-एजेंट भूमिका अपघटन (multi-agent role decomposition) जोड़ने से सिंगल-एजेंट रिट्राय लूप्स की तुलना में कोई मापने योग्य लाभ नहीं मिलता है, बावजूद इसके कि इसकी कम्प्यूटेशनल लागत काफी अधिक है।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक बहुत ही प्रतिभाशाली, लेकिन थोड़े ख्याली पुलाव पकाने वाले (dreamy) रोबोट को कंप्यूटर कोड लिखना सिखाने की कोशिश कर रहे हैं। यह रोबोट एक "लार्ज लैंग्वेज मॉडल" (LLM) है, जो एक सुपर-स्मार्ट छात्र की तरह है जिसने लाइब्रेरी की लगभग हर किताब और कोड स्निपेट को पढ़ लिया है। यह ऐसा कोड लिख सकता है जो कागज पर एकदम सही दिखता है, लेकिन कभी-कभी इसमें ऐसी सूक्ष्म गलतियाँ होती हैं जो केवल तभी सामने आती हैं जब आप वास्तव में प्रोग्राम को चलाने की कोशिश करते हैं। सॉफ्टवेयर की दुनिया में, यह एक बड़ी बात है क्योंकि एक छोटी सी त्रुटि पूरी वेबसाइट को क्रैश कर सकती है या डेटा खो सकती है।
कुछ समय के लिए, लोगों को लगा कि इसे ठीक करने का सबसे अच्छा तरीका रोबोट विशेषज्ञों की एक पूरी टीम को काम पर रखना है—एक "मल्टी-एजेंट सिस्टम"। कल्पना कीजिए कि एक प्रोजेक्ट मैनेजर, एक सख्त संपादक, एक लॉजिक चेकर और एक कोड लेखक मिलकर काम कर रहे हैं। विचार यह था कि यदि आप काम को विभाजित करते हैं और अलग-अलग रोबोटों से एक-दूसरे के काम की जाँच करवाते हैं, तो अंतिम कोड त्रुटिहीन होगा। लेकिन एक चुभता हुआ सवाल था: क्या सुधार एक "टीम" होने से आ रहा था, या केवल इसलिए क्योंकि रोबोटों को अपनी गलतियाँ देखने के बाद फिर से प्रयास करने की अनुमति दी गई थी? यह पूछने जैसा है कि क्या एक छात्र बेहतर ग्रेड प्राप्त करता है क्योंकि उसके पास एक स्टडी ग्रुप है, या केवल इसलिए क्योंकि उसे अपनी पहली परीक्षा देखने के बाद दूसरा टेस्ट देने की अनुमति दी गई थी। यह शोध पत्र उस रहस्य को सुलझाने के लिए बनाया गया है जो इन दो कारकों को अलग कर सके।
शोधकर्ताओं ने एक चतुर ढांचा बनाया जिसे ExecuGraph कहा जाता है, जो कोड लिखने वाले रोबोटों के परीक्षण के लिए एक स्विस आर्मी नाइफ की तरह काम करता है। उन्होंने इसे इस तरह डिज़ाइन किया कि वे तुरंत तीन मोड के बीच स्विच कर सकें: एक "लोन वुल्फ" (अकेला भेड़िया) रोबोट जो कोड एक बार लिखता है और रुक जाता है; एक "लोन वुल्फ" जिसे विफल होने पर फिर से प्रयास करने की अनुमति मिलती है; और पाँच अलग-अलग रोबोट एजेंटों की पूरी "ड्रीम टीम" जो मिलकर काम करती है। इन 164 कठिन कोडिंग पहेलियों को इन विभिन्न मोड के माध्यम से चलाने पर, उन्हें कुछ आश्चर्यजनक पता चला।
मुख्य निष्कर्ष यह है कि रोबोट को अपनी गलतियों को देखने के बाद फिर से प्रयास करने देना ही असली जादू है, न कि विशेषज्ञों की एक टीम होना। जब उन्होंने एक अकेले रोबोट को अपनी गलतियों को देखने और पुनः प्रयास करने का मौका दिया (एक प्रक्रिया जिसे "एक्ज़ीक्यूशन फीडबैक" कहा जाता है), तो इसकी सफलता दर में भारी 25.6 प्रतिशत अंक की वृद्धि हुई। यह लगभग 56% समस्याओं को सही करने से बढ़कर 81% से अधिक तक पहुँच गई। यह एक बहुत बड़ी जीत है!
हालाँकि, जब उन्होंने इस रिट्राय (पुनः प्रयास) सिस्टम के ऊपर पाँच अतिरिक्त एजेंटों (एक योजनाकार, एक समीक्षक, एक अनुकूलक, आदि) की पूरी टीम जोड़ी, तो परिणाम और बेहतर नहीं हुए। वास्तव में, टीम वाला संस्करण एकल रोबोट (जिसे केवल पुनः प्रयास करने का मौका मिला था) के समान ही था। टीम वाले संस्करण ने कंप्यूटर शक्ति और समय का लगभग 3.6 गुना अधिक खर्च किया लेकिन एक भी अतिरिक्त सही उत्तर नहीं दिया। शोधकर्ताओं ने इस विचार को भी खारिज कर दिया कि टीम केवल इसलिए जीत रही थी क्योंकि उन्हें "पासे फेंकने" के अधिक मौके मिले थे; उन्होंने साबित किया कि बिना किसी फीडबैक के पाँच रैंडम अनुमान उत्पन्न करना भी बहुत अधिक मददगार नहीं था।
लेकिन, इस कहानी में एक मोड़ भी आया। शोधकर्ताओं ने अपनी परीक्षण मशीन (एक "सैंडबॉक्स" जो कोड चलाती है) में एक बग पाया जो गलती से सही कोड को भी अस्वीकार कर रहा था। एक बार जब उन्होंने इस बग को ठीक कर दिया, तो संख्याएँ बदल गईं, लेकिन मुख्य निष्कर्ष वही रहा: रिट्राय लूप (पुनः प्रयास चक्र) ही नायक है, और अतिरिक्त एजेंट ज्यादातर केवल महंगे सजावटी सामान हैं।
शोध पत्र ने यह भी देखा कि यह विभिन्न प्रकार के रोबोटों के साथ कैसे काम करता है। एक विशिष्ट प्रकार के रोबोट (एक 16-बिलियन-पैरामीटर मॉडल) पर, टीम के दृष्टिकोण ने "ग्राफ समस्याओं" नामक एक विशेष प्रकार की पहेली के साथ मदद की, जिससे सफलता 70% से बढ़कर 90% हो गई। लेकिन अन्य प्रकार की पहेलियों पर, टीम वास्तव में खराब प्रदर्शन करती है, और समग्र स्कोर वही रहा। यह सुझाव देता है कि अधिक एजेंट जोड़ने से रोबोट स्वचालित रूप से स्मार्ट नहीं हो जाता; यह केवल यह बदल देता है कि वह किन समस्याओं को हल कर सकता है।
अंत में, शोध पत्र सुझाव देता है कि यदि आप एक विश्वसनीय कोड-लिखने वाला रोबोट चाहते हैं, तो आपको पाँच अलग-अलग एजेंटों का एक जटिल संगठन बनाने की आवश्यकता नहीं है। आपको बस अपने रोबोट को एक सरल, स्मार्ट लूप देना है: कोड लिखें, उसे चलाएं, देखें कि क्या टूटा, और उसे ठीक करने का प्रयास करें। यह एक पूरी समिति को काम पर रखने की तुलना में बहुत सस्ता, तेज़ और उतना ही प्रभावी है। "टीम" दृष्टिकोण अभी भी अतिरिक्त रिपोर्ट या स्पष्टीकरण उत्पन्न करने के लिए उपयोगी हो सकता है, लेकिन सही कोड लिखने के वास्तविक काम के लिए, सरल "प्रयास करो, विफल हो जाओ, फिर से प्रयास करो" की रणनीति स्पष्ट विजेता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।