वो एक लेख जिसने मेरे मल्टी-एजेंट आर्किटेक्चर की सारी उलझनें सुलझा दीं
ऑर्केस्ट्रेशन पैटर्न, कम्युनिकेशन मेथड्स, मेमोरी मैनेजमेंट और प्रोडक्शन की चुनौतियाँ - मल्टी-एजेंट सिस्टम डिज़ाइन करते वक़्त जहाँ-जहाँ अटका, उन सबका जवाब इस एक गाइड में मिला।
हमारी टीम इन दिनों एक एजेंटिक सिस्टम डिज़ाइन कर रही है। एक एजेंट बनाना तो ठीक-ठाक लगा, लेकिन जैसे ही कई एजेंट्स को आपस में जोड़ने की बात आई, सवालों का अंबार लग गया।
कौन सा ऑर्केस्ट्रेशन स्ट्रक्चर इस्तेमाल करें? एजेंट्स आपस में कैसे बात करेंगे? पूरे सिस्टम की मेमोरी कैसे मैनेज होगी?
तभी मुझे Rohit Ghumare का एक लेख मिला जिसने मेरी लगभग हर उलझन को सुलझा दिया। यहाँ उसकी मुख्य बातें हैं, साथ में मेरा अपना अनुभव भी।
मल्टी-एजेंट क्यों
जैसा कि मैंने पहले के पोस्ट्स में बताया है, मल्टी-एजेंट हमेशा सही जवाब नहीं होता। लेकिन पिछले पूरे साल मैं सिंगल एजेंट के कॉन्टेक्स्ट मैनेजमेंट में बार-बार फेल होता रहा।
समस्या: सिंगल एजेंट की कॉन्टेक्स्ट विंडो बहुत जल्दी भर जाती है, और भरने के बाद एजेंट भूलने लगता है। इसके अलावा, जब एक ही एजेंट कई डोमेन एक साथ हैंडल करता है, तो उसकी निर्णय क्षमता कमज़ोर पड़ जाती है।
मल्टी-एजेंट ज़िम्मेदारियाँ बाँटकर इसे हल करता है - लेकिन इसके बदले में कोऑर्डिनेशन ओवरहेड आता है। इस ओवरहेड को मैनेज करना ही असली चुनौती है, और लेख इसे सीधे तौर पर address करता है।
तीन ऑर्केस्ट्रेशन पैटर्न
यह सबसे प्रैक्टिकल सेक्शन था। “क्या ज़्यादा इम्प्रेसिव है” की बजाय “कब क्या इस्तेमाल करें” के हिसाब से organize किया गया है।
सुपरवाइज़र पैटर्न (Supervisor)
एक मैनेजर एजेंट टास्क को तोड़ता है, वर्कर्स को बाँटता है और नतीजे जोड़ता है।
- सबसे अच्छा जब: काम साफ़ तौर पर सब-टास्क में बँटता हो, या ट्रैकिंग ज़रूरी हो
- सही साइज़: 3-8 वर्कर्स
- ध्यान रखें: हर फ़ैसला सुपरवाइज़र से होकर गुज़रता है, जिससे bottleneck बन सकता है
स्वॉर्म पैटर्न (Swarm)
कोई केंद्रीय मैनेजर नहीं। एजेंट्स P2P में आपस में बात करते हैं और ख़ुद organize होते हैं।
- सबसे अच्छा जब: अलग-अलग नज़रियों की ज़रूरत हो, या रियल-टाइम रिस्पॉन्स ज़रूरी हो
- ध्यान रखें: डुप्लिकेट काम, इनफ़िनिट लूप, suboptimal convergence। डिबगिंग मुश्किल होती है
हाइरार्किकल पैटर्न (Hierarchical)
सुपरवाइज़र पैटर्न का recursive extension। टॉप-लेवल → मिड-लेवल मैनेजर → वर्कर्स की मल्टी-लेयर स्ट्रक्चर।
- सबसे अच्छा जब: 10 से ज़्यादा एजेंट्स हों, या स्ट्रैटेजी और टैक्टिक्स को अलग करना हो
- ध्यान रखें: हर कोऑर्डिनेशन लेयर के साथ टोकन कॉस्ट तेज़ी से बढ़ता है
मेरे अनुभव में सुपरवाइज़र पैटर्न सबसे स्टेबल रहा है। लेकिन वर्कर डिस्ट्रीब्यूशन और एरर हैंडलिंग सही होना बहुत ज़रूरी है - वरना सुपरवाइज़र ख़ुद failure point बन जाता है।
एजेंट्स कैसे कम्युनिकेट करते हैं
अगर ऑर्केस्ट्रेशन स्ट्रक्चर तय करता है, तो कम्युनिकेशन यह तय करता है कि एजेंट्स के बीच जानकारी असल में कैसे बहती है।
- शेयर्ड स्टेट (Shared State): सभी एजेंट्स एक ही स्टेट ऑब्जेक्ट को पढ़ते-लिखते हैं। इम्प्लीमेंट करना आसान, डिबग करना आसान। ज़्यादातर टीमों को यहीं से शुरू करना चाहिए
- मैसेज पासिंग (Message Passing): इवेंट बस के ज़रिए async कम्युनिकेशन। जब एजेंट्स के बीच loose coupling चाहिए
- हैंडऑफ़ (Handoff): एजेंट्स के बीच explicit बैटन पासिंग और पूरा कॉन्टेक्स्ट ट्रांसफ़र। फ़िक्स्ड-ऑर्डर पाइपलाइन के लिए बेस्ट
मल्टी-एजेंट सिस्टम के लिए मेमोरी आर्किटेक्चर
मेमोरी की मूल समस्या सीधी है: स्टेट शेयर कैसे करें बिना collision के? लेख इसे तीन पैटर्न में तोड़ता है।
सेशन-बेस्ड मेमोरी (Session-Based)
हर एजेंट isolated लोकल स्टेट में काम करता है। बदलाव सेशन ख़त्म होने पर ही शेयर्ड मेमोरी में merge होते हैं।
- सबसे अच्छा जब: पैरेलल वर्कर्स को बिना interference के independently काम करना हो
- कैसे काम करता है: सेशन शुरू होने पर शेयर्ड स्टेट का स्नैपशॉट लेता है, लोकली काम करता है, सेशन ख़त्म होने पर सिर्फ़ deltas merge करता है
- फ़ायदा: बिना collision के पैरेलल प्रोसेसिंग
विंडो मेमोरी (Window Memory)
स्लाइडिंग विंडो सिर्फ़ हाल के N exchanges रखती है। पुराने entries समरी में compress हो जाते हैं।
- सबसे अच्छा जब: लंबी बातचीत में कॉन्टेक्स्ट बचाना हो बिना tokens जलाए
- कैसे काम करता है: विंडो भरने पर सबसे पुराना 1/3 summarize और compress हो जाता है
- फ़ायदा: स्टेट के बेहिसाब बढ़ने की समस्या ख़त्म
एपिसोडिक मेमोरी (Episodic Memory)
ख़ास एजेंट combinations के पिछले collaboration history और results स्टोर करता है।
- सबसे अच्छा जब: बार-बार साथ काम करने वाले एजेंट्स को पिछले अनुभव से सुधार करना हो
- कैसे काम करता है: रिकॉर्ड करता है कि कौन सा एजेंट combination किस टास्क में सफल या असफल रहा
- फ़ायदा: “पिछली बार यह combination अच्छा रहा था - फिर से इस्तेमाल करें” जैसे फ़ैसले लेना संभव
प्रोडक्शन में ध्यान रखने वाली बातें
टोकन कॉस्ट
- सुपरवाइज़र + 4 वर्कर्स: decomposition ~1K + वर्कर्स ~12K + synthesis ~2K = कुल ~15K tokens प्रति टास्क
- वही टास्क सिंगल एजेंट से: लगभग 4K tokens। कोऑर्डिनेशन कॉस्ट लगभग 4 गुना
- ऑप्टिमाइज़ेशन: सुपरवाइज़र instructions कैश करें, वर्कर आउटपुट structured data में रखें, ज़रूरत पड़ने पर ही invoke करें
लेटेंसी
- हर LLM कॉल 2-5 सेकंड, 4 एजेंट सीरीज़ में 12+ सेकंड, पैरेलल में 3-4 सेकंड
- independent टास्क हमेशा पैरेलल में चलाएँ
एरर प्रोपेगेशन रोकना
- टाइमआउट: हर लेयर पर अनिवार्य
- सर्किट ब्रेकर: लगातार N बार फ़ेल होने पर उस एजेंट को कॉल करना बंद करें
- ग्रेसफ़ुल डिग्रेडेशन: कुछ एजेंट्स डाउन होने पर भी core functionality चलती रहे
- स्टेट आइसोलेशन: वर्कर की failure शेयर्ड स्टेट को corrupt न करे
अगर observe नहीं कर सकते, तो fix भी नहीं कर सकते। मॉनिटरिंग day one से ज़रूरी है।
बचने वाले एंटी-पैटर्न
- ज़रूरत से ज़्यादा ऑर्केस्ट्रेशन: independently चल सकने वाले एजेंट्स को ज़बरदस्ती जोड़ना
- गॉड एजेंट: एक एजेंट सब कुछ करे तो मल्टी-एजेंट का मतलब ही नहीं
- कॉस्ट इग्नोर करना: टोकन मॉनिटरिंग बिना deploy करना surprise बिल लाता है
- फ़ॉलबैक न होना: मानकर चलना कि सब एजेंट्स हमेशा available रहेंगे
निष्कर्ष
लेख का निष्कर्ष सबसे ज़्यादा याद रहा:
एक एजेंट बनाओ। पता लगाओ कहाँ टूटता है। उस जगह पर दूसरा एजेंट लगाओ। ज़रूरत हो तो सुपरवाइज़र रखो। दोहराओ।
मैंने शुरू में बड़ा hierarchical design बनाया था, लेकिन अंत में सुपरवाइज़र + 3 वर्कर्स में simplify कर दिया। सबक: पहले दो एजेंट्स की stable collaboration बनाओ, फिर वहाँ से scale करो।
अगर आप मल्टी-एजेंट सिस्टम डिज़ाइन कर रहे हैं, तो मूल लेख ज़रूर पढ़ें।
न्यूज़लेटर से जुड़ें
मेरे नवीनतम प्रोजेक्ट्स, लेखों और AI तथा वेब डेवलपमेंट प्रयोगों के बारे में अपडेट प्राप्त करें।