Multi-Agent LLM Collaborative Reasoning and Task Planning for Complex Task Solving
यह शोध पत्र एक मल्टी-एजेंट एलएलएम (LLM) फ्रेमवर्क प्रस्तावित करता है जिसमें कैलिब्रेटेड पैरामीटर्स और साझा-मेमोरी तंत्र के साथ एक डिपेंडेंसी-अवेयर टास्क ग्राफ पर संचालित होने वाली विशिष्ट प्लानर, एक्जीक्यूटर और वेरिफायर भूमिकाएं शामिल हैं, जो पूर्णता दर, सटीकता और तथ्यात्मक निरंतरता में सुधार करते हुए तथा टूल त्रुटियों को कम करते हुए जटिल कार्यों को हल करने में सिंगल-एजेंट बेसलाइन्स की तुलना में काफी बेहतर प्रदर्शन करता है।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक बहुत बड़ी, जटिल पहेली को हल करने की कोशिश कर रहे हैं, जैसे कि आंखों पर पट्टी बांधकर लेगो (LEGO) से एक गगनचुंबी इमारत बनाना, और आप केवल एक व्यक्ति की याददाश्त और निर्देशों पर निर्भर हैं। एक एकल लार्ज लैंग्वेज मॉडल (LLM) से जटिल समस्या हल करने के लिए कहने पर वास्तव में यही होता है। यह सब कुछ एक साथ करने की कोशिश करता है: संरचना की योजना बनाना, दीवारें बनाना, माप की जांच करना और गलतियों को सुधारना। अक्सर, यह भ्रमित हो जाता है, शुरुआत में एक गलती करता है, और फिर उस त्रुटि के ऊपर ही पूरी मीनार बना देता है, जिससे वह ढह जाती है।
यह शोध पत्र एक बेहतर तरीका प्रस्तावित करता है: एक व्यक्ति द्वारा सब कुछ करने के बजाय, हम तीन अलग-अलग एआई (AI) एजेंटों से बना एक विशेषज्ञ निर्माण दल (specialized construction crew) बनाते हैं जो एक सख्त, व्यवस्थित क्रम में मिलकर काम करते हैं।
यहाँ बताया गया है कि उनका यह "निर्माण दल" कैसे काम करता है, सरल उपमाओं का उपयोग करते हुए:
1. तीन भूमिकाएँ (दल)
शोध पत्र कार्य को तीन विशिष्ट नौकरियों में विभाजित करता है, ठीक वैसे ही जैसे एक वास्तविक दुनिया की परियोजना टीम में होता है:
- योजनाकार (द आर्किटेक्ट - द आर्किटेक्ट): यह एजेंट बड़ी तस्वीर देखता है। केवल "मीनार बनाओ" कहने के बजाय, यह काम को निर्भरताओं के एक मानचित्र में तोड़ देता है। यह कहता है, "पहले, हमें एक नींव की आवश्यकता है। फिर, हमें स्तंभों की आवश्यकता है। हम छत तब तक नहीं लगा सकते जब तक स्तंभ तैयार न हो जाएं।" यह प्रत्येक चरण को उसके महत्व और जोखिम के आधार पर एक "प्राथमिकता स्कोर" (priority score) आवंटित करता है।
- निष्पादक (द बिल्डर - द बिल्डर): यह एजेंट वास्तविक भारी काम करता है। यह आर्किटेक्ट के मानचित्र का पालन करता है, आवश्यक उपकरण (जैसे कैलकुलेटर, सर्च इंजन, या कोड इंटरप्रेटर) उठाता है, और विशिष्ट भागों का निर्माण करता है। इसे पूरी इमारत की चिंता नहीं करनी होती; यह बस अपने विशिष्ट कार्य को सही ढंग से पूरा करने पर ध्यान केंद्रित करता है।
- सत्यापनकर्ता (द इंस्पेक्टर - द इंस्पेक्टर): यह नया और महत्वपूर्ण जुड़ाव है। बिल्डर के काम को स्वीकार करने से पहले, इंस्पेक्टर उसकी जांच करता है। वे साक्ष्य देखते हैं: "क्या आपने सही उपकरण का उपयोग किया? क्या गणित सही है? क्या यह ब्लूप्रिंट से मेल खाता है?" यदि इंस्पेक्टर का आत्मविश्वास (एक विशिष्ट "ट्रस्ट स्कोर" 0.72 से नीचे) कम है, तो वे बिल्डर को उस विशिष्ट भाग को ठीक करने के लिए वापस भेज देते हैं। वे पूरी इमारत को नहीं गिराते; वे बस टूटी हुई ईंट को ठीक करते हैं।
2. साझा नोटबुक (साझा स्मृति/Shared Memory)
एक सामान्य बातचीत में, लोग शायद भूल जाते हैं कि पांच मिनट पहले क्या कहा गया था। इस प्रणाली में, तीनों एजेंट एक डिजिटल नोटबुक साझा करते हैं।
- जब आर्किटेक्ट एक योजना बनाता है, तो वह नोटबुक में चली जाती है।
- जब बिल्डर कोई साक्ष्य पाता है, तो उसे एक "स्रोत टैग" (source tag) के साथ लिखा जाता है।
- जब इंस्पेक्टर किसी विचार को खारिज करता है, तो उस अस्वीकृति को भी दर्ज किया जाता है ताकि कोई भी उस टूटे हुए विचार पर दोबारा निर्माण न करे।
यह सुनिश्चित करता है कि यदि टीम को एक अनुभाग को फिर से शुरू करना पड़ता है, तो उन्हें सब कुछ शुरू से सीखने की आवश्यकता नहीं होती। वे बस नोट्स देख सकते हैं।
3. "ट्रैफिक लाइट" प्रणाली (प्रोटोकॉल)
एजेंटों को एक-दूसरे के ऊपर बोलने या बहस के अंतहीन चक्र में फंसने से रोकने के लिए, वे सख्त नियमों का पालन करते हैं:
- ग्रीन लाइट (हरा संकेत): आर्किटेक्ट एक कार्य देता है।
- येलो लाइट (पीला संकेत): बिल्डर काम करता है और अपना साक्ष्य दिखाता है।
- रेड या ग्रीन लाइट (लाल या हरा संकेत): इंस्पेक्टर काम की जांच करता है।
- ग्रीन: "आगे बढ़ें।" काम को सहेज लिया जाता है।
- रेड: "रुकें।" इंस्पेक्टर विस्तार से बताता है कि वह क्यों विफल रहा (जैसे, "गलत उपकरण का उपयोग किया गया" या "डेटा गायब है")। आर्किटेक्ट फिर केवल उस एक समस्या को ठीक करने के लिए योजना को अपडेट करता है।
4. परिणाम: यह बेहतर क्यों है
शोधकर्ताओं ने कठिन कार्यों जैसे जटिल गणित, कई उपकरणों का उपयोग करने और पेचीदा तथ्यात्मक प्रश्नों के उत्तर देने पर इस "क्रू" (दल) का परीक्षण एक एकल "सोलो वर्कर" (एक मानक GPT-4 मॉडल) के मुकाबले किया।
इस "सोलो वर्कर" को एक प्रतिभाशाली लेकिन थके हुए छात्र के रूप में समझें जो एक ही बैठक में 10 पन्नों का निबंध लिखने की कोशिश करता है। वे पैराग्राफ 2 में एक छोटी सी गलती कर सकते हैं, और पैराग्राफ 10 तक, पूरा निबंध पटरी से उतर सकता है।
"क्रू" दृष्टिकोण एक संपादक और लेखक की टीम की तरह काम करता है जो काम के दौरान एक-दूसरे के काम की जांच करते हैं। शोध पत्र ने पाया कि इस प्रणाली का उपयोग करके:
- उन्होंने अधिक कार्य पूरे किए: सफलता दर में 27.3% की वृद्धि हुई।
- उनके उत्तर अधिक सही थे: सटीकता में 19.6% का सुधार हुआ।
- उन्होंने उपकरणों से कम गलतियाँ कीं: गलत कैलकुलेटर का उपयोग करने या गलत चीज़ खोजने जैसी त्रुटियां 31.5% तक गिर गईं।
- वे अधिक ईमानदार थे: वे तथ्य गढ़ने की कम संभावना रखते थे, जिससे तथ्यात्मक निरंतरता में 24.8% का सुधार हुआ।
मुख्य निष्कर्ष
शोध पत्र का तर्क है कि कठिन समस्याओं को हल करने का रहस्य केवल AI को "स्मार्ट" बनाना नहीं है। यह संगठन के बारे में है। योजना बनाने, करने और जांचने की भूमिकाओं को अलग करके, और उन्हें एक संरचित, साक्ष्य-आधारित प्रणाली के माध्यम से संवाद करने के लिए मजबूर करके, AI टीम "एक-व्यक्ति पूर्वाग्रह" (one-person bias) से बचती है जहाँ एक गलती पूरे प्रोजेक्ट को बर्बाद कर देती है। यह एक अराजक विचार-मंथन सत्र को एक अनुशासित, ऑडिट योग्य निर्माण परियोजना में बदल देता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।