मल्टी-एजेंट सिस्टम: क्षमता जो स्केलिंग के साथ खत्म होती जाती है
बड़े भाषा मॉडल पर आधारित मल्टी-एजेंट सिस्टम का वादा आकर्षक लगता है: कई LLM एजेंट एक बड़े कार्य को आपस में बाँट सकते हैं, एक-दूसरे से सलाह ले सकते हैं और मिलकर समाधान ढूंढ सकते हैं। हालाँकि, व्यवहार में इसका उल्टा प्रभाव देखने को मिलता है: जितने अधिक एजेंट सहयोग से जुड़ते हैं, सिस्टम उतना ही कम स्थिर होता जाता है। सहज रूप से ऐसा लगता है कि समस्या समन्वय में है, लेकिन arXiv पर एक पोजीशन पेपर में शोधकर्ताओं के एक समूह ने स्थिति को और गहराई से देखने का सुझाव दिया है।
कई विफलताओं की जड़ इस बात में है कि एजेंट साझा अवस्था (shared state) का उपयोग कैसे करते हैं। उनमें से प्रत्येक साझा भंडार में डेटा पढ़ता और लिखता है — नोट्स, परिणाम, तथ्यों के संस्करण। जब एक्सेस की संख्या बढ़ जाती है, तो क्लासिकल डेटा रेस (data races) उत्पन्न होती हैं। अगर यह एक सामान्य मल्टी-थ्रेडेड प्रोग्राम होता, तो इंजीनियर तुरंत सिंक्रोनाइज़ेशन समस्याओं पर संदेह करते। लेकिन चूँकि सिस्टम के सदस्य 'बुद्धिमान' दिखते हैं, उनकी गलतियों को अक्सर गलतफहमी मान लिया जाता है, जबकि वास्तव में यह साझा संसाधनों तक समानांतर पहुँच का विशिष्ट व्यवहार है।
लंबे 'विचार' — दोगुने खतरनाक
LLM एजेंटों की विशेषता अतिरिक्त जटिलता जोड़ती है। मॉडल में तार्किक अनुमान (inference) की प्रक्रिया में काफी समय लगता है, और इस पूरे समय एजेंट उस अवस्था के स्नैपशॉट के साथ काम करता है जो उसने अनुरोध के समय देखा था। जब मॉडल 'सोचता' है, अन्य एजेंट स्थिर नहीं रहते: वे साझा डेटा को अपडेट करते हैं। तैयार समाधान के साथ लौटने पर, एजेंट दुनिया की पुरानी तस्वीर पर भरोसा कर सकता है।
एजेंटों की संख्या बढ़ने के साथ, ऐसी लंबी विचार-विंडो (thinking windows) अधिक हो जाती हैं, और उनके साथ विभिन्न विसंगतियों की संभावना भी बढ़ जाती है। एक एजेंट को पता नहीं चलता कि उप-कार्य पहले ही किसी सहकर्मी द्वारा पूरा हो चुका है, और वह काम को दोहराना शुरू कर देता है। दो एजेंट अंतिम परिणाम लिखने की कोशिश करते हैं, और आखिरी लेखन बिना किसी चेतावनी के पिछले को मिटा देता है। कोई डेटा उस समय पढ़ता है जब दूसरा उसे अपडेट करना समाप्त नहीं कर पाया होता, और उसे एक असंगत मध्यवर्ती संस्करण मिलता है। यह सब अराजकता जैसा दिखता है, लेकिन वास्तव में यह डेटाबेस सिद्धांत से ज्ञात पैटर्न का पालन करता है — पुरानी रीडिंग (stale reads), खोए हुए अपडेट (lost updates) और अवस्था की अखंडता का उल्लंघन।
संचार विफलताएँ भी केवल परिणाम हैं
निदान में गलती करना इतना आसान क्यों है? आइए समन्वय के उल्लंघन को लें। एजेंटों ने स्पष्ट रूप से भूमिकाएँ वितरित कीं और, जाहिरा तौर पर, कार्यों पर सहमति बना ली। लेकिन अगर तथ्यों का साझा आधार लगातार बदल रहा है, तो एक एजेंट उस अवस्था के आधार पर कार्य कर सकता है जिसे सहकर्मी पहले ही फिर से लिख चुका है। बाहर से यह योजनाओं की असंगति या निर्देशों की खराब समझ जैसा दिखता है। हालाँकि, मूल कारण — कमजोर समन्वय नहीं, बल्कि डेटा तक एक साथ पहुँच पर नियंत्रण की कमी है।
यही बात संचार पर भी लागू होती है। संदेश स्वयं पूरी तरह से सही बनाया जा सकता है और समय पर पहुँचाया जा सकता है। लेकिन अगर जिस समय प्राप्तकर्ता उसे संसाधित करना शुरू करता है, साझा डेटा पहले ही बदल चुका होता है, तो संदेश का अर्थ विकृत हो जाता है। ऐसी विफलताओं को दोबारा पैदा करना बेहद मुश्किल है: वे सटीक समय (timing) पर निर्भर करती हैं। जब तक एजेंट कम होते हैं, समस्या लगभग प्रकट नहीं होती, लेकिन स्केलिंग के साथ ओवरलैपिंग ऑपरेशनों की संख्या बढ़ती है, और त्रुटियाँ भयावह नियमितता के साथ उत्पन्न होने लगती हैं।
कंकरेंसी नियंत्रण — पैच के रूप में नहीं, बल्कि नींव के रूप में
शोधकर्ताओं द्वारा प्रस्तावित समाधान डेटाबेस की दुनिया से सिद्ध दृष्टिकोणों को मल्टी-एजेंट सिस्टम की वास्तुकला में स्थानांतरित करने में निहित है। यह मानने के बजाय कि LLM किसी तरह 'आपस में बातचीत' कर लेंगे, प्लेटफ़ॉर्म को स्पष्ट रूप से कंकरेंट एक्सेस का प्रबंधन करना चाहिए। व्यावहारिक रूप से इसका अर्थ है कार्य की तीन दिशाएँ:
- संघर्ष का पता लगाना। सिस्टम एजेंटों द्वारा एक ही डेटा को संशोधित करने के एक साथ प्रयासों पर नज़र रखता है और टकराव को परिणाम को नुकसान पहुँचाने से पहले ही रोक देता है।
- आइसोलेशन की गारंटी। प्रत्येक एजेंट को अवस्था के पूर्ण स्नैपशॉट के साथ काम करना चाहिए या उसके पास ऐसे तंत्र होने चाहिए जो अधूरे लेखन को पढ़ने से रोकें।
- संसाधनों तक संरचित पहुँच। साझा संदर्भ तक सीधे अनुरोधों के बजाय, स्पष्ट इंटरफेस का उपयोग किया जाता है: लॉक, ऑपरेशन संस्करण, लेखन के लिए कतारें या परमाणु अपडेट।
लेखक इस बात पर जोर देते हैं कि कंकरेंसी नियंत्रण को बाद में नहीं जोड़ा जा सकता, जब सिस्टम पहले ही विफल होने लगा हो। यह 'दूसरी मंजिल' स्तर का वास्तुशिल्प निर्णय होना चाहिए, जिससे बाकी सारा डिज़ाइन शुरू होता है। यदि पहले साझा अवस्था के साथ काम करने के नियमों पर विचार किया जाए, और उसके बाद ही उनके ऊपर एजेंटों का समन्वय बनाया जाए, तो कई विश्वसनीयता समस्याएँ उत्पन्न ही नहीं होंगी।
निष्कर्ष
LLM पर आधारित मल्टी-एजेंट सिस्टम में अपार क्षमता है, लेकिन उनकी भेद्यता अलग-अलग मॉडलों की कमजोरी से नहीं, बल्कि इससे जुड़ी है कि हम कई समानांतर निष्पादकों को बिना बुनियादी सुरक्षा तंत्र के एक बदलती अवस्था के साथ काम करने के लिए मजबूर कर रहे हैं। डेटा रेस को विफलताओं के मुख्य स्रोत के रूप में स्वीकार करके, डेवलपर्स को लंबे समय से ज्ञात समाधानों को लागू करने का अवसर मिलता है — आइसोलेशन, संघर्ष का पता लगाना और एक्सेस को क्रमबद्ध करना। शायद यह प्रॉम्प्ट सुधारने जितना प्रभावशाली नहीं है, लेकिन यही दृष्टिकोण मल्टी-एजेंट सिस्टम को प्रतिभागियों की संख्या बढ़ने पर भी विश्वसनीय बने रहने की अनुमति देता है।
