क्या होता है जब आप बिना किसी प्रभारी के एक बड़ी परियोजना की योजना बनाते हैं? अधिकांश सॉफ़्टवेयर स्टैक एक एकल ऑर्केस्ट्रेटर (orchestrator) मानकर चलते हैं। एक प्रक्रिया स्टेट को संभालती है, जॉब्स को कतारबद्ध (queue) करती है, और कार्यों को सौंपती है। यदि वह समन्वयक (coordinator) रीस्टार्ट हो जाता है, तो पूरा वर्कफ़्लो लड़खड़ा जाता है। एक नया प्रोजेक्ट इस धारणा को पूरी तरह से उलट देता है। यह दिखाता है कि कैसे AI एजेंटों का एक झुंड (swarm) "जापान की दो सप्ताह की यात्रा की योजना बनाएं" जैसे लक्ष्य को एक पूर्ण टास्क ट्री (task tree) में विभाजित कर सकता है, बिना किसी एक नोड के किसी भी क्षण में पूरी योजना को अपने पास रखने के।
एक लीडरलेस (Leaderless) सिस्टम क्यों बनाएं?
केंद्रीकृत योजनाकार (Centralized planners) समझने में आसान होते हैं। आप सर्वर को एक अनुरोध भेजते हैं, वह काम को विभाजित करता है, और वर्कर वापस रिपोर्ट करते हैं। समस्या यह है कि सर्वर एक संज्ञानात्मक (cognitive) और भौतिक बाधा (bottleneck) बन जाता है। सत्य का स्वामित्व उसी के पास होता है।
एक वितरित सेटअप (distributed setup) में, सत्य एक साझा तस्वीर में बदल जाता है जिस पर नेटवर्क 'गॉसिप' (gossip) के माध्यम से सहमत होता है। यह विशिष्ट Python कार्यान्वयन दो अलग-अलग अवधारणाओं को आपस में जोड़ता है। पहला है एक पुनरावृत्ति परिशोधन लूप (iterative refinement loop): एक एजेंट प्रस्ताव लिखता है, दूसरा उसे स्कोर करता है, और तीसरा उसे निखारता है। दूसरा है libp2p पर बना एक पीयर-टू-पीयर (peer-to-peer) नेटवर्किंग लेयर, जो एजेंटों को बिना किसी रजिस्ट्री या लोड बैलेंसर के स्वचालित रूप से एक-दूसरे को खोजने की अनुमति देता है। इसका परिणाम एक ऐसा क्लस्टर है जहाँ पीयर्स (peers) बिना किसी ऑर्केस्ट्रा कंडक्टर के प्रकट होते हैं, प्रस्ताव देते हैं, वोट करते हैं और निष्पादित करते हैं।
चार भूमिकाएँ
सिस्टम प्रत्येक प्रतिभागी को चार व्यक्तित्वों में से एक प्रदान करता है। आपको चार भौतिक मशीनों की आवश्यकता नहीं है। वे एक लैपटॉप पर सह-अस्तित्व में हो सकते हैं या होम नेटवर्क में फैले हो सकते हैं। भूमिकाएँ इस प्रकार हैं:
Decomposer (विभाजक)। यह एजेंट शीर्ष-स्तरीय लक्ष्य प्राप्त करता है और उप-लक्ष्यों (subgoals) में विभाजन का प्रस्ताव देता है। चूंकि सिस्टम कई decomposers को समानांतर (parallel) में चलाता है, इसलिए आपको जापान की उसी यात्रा के लिए तीन अलग-अलग तरीके मिल सकते हैं। एक यात्रा को भूगोल के आधार पर विभाजित कर सकता है: टोक्यो, क्योटो, ओसाका। दूसरा गतिविधि के आधार पर विभाजित कर सकता है: पारगमन (transit), आवास, भोजन, दर्शनीय स्थल। तीसरा दिनों के क्रम में विभाजित कर सकता है। नेटवर्क उन सभी पर विचार करता है।
Scorer (स्कोरर)। ये एजेंट संपादकीय बोर्ड के रूप में कार्य करते हैं। वे प्रस्तावित विभाजन का निरीक्षण करते हैं और उसे रेटिंग देते हैं। एक स्कोर यह दर्शाता है कि क्या उप-लक्ष्य पर्याप्त रूप से ठोस, गैर-अतिव्यापी (non-overlapping) और सामूहिक रूप से व्यापक हैं। इससे भी महत्वपूर्ण बात यह है कि एक scorer यह तय करता है कि क्या कोई प्रस्ताव स्वीकार करने के लिए पर्याप्त अच्छा है। इसकी अनुमति के बिना, विभाजन अनिश्चितता (limbo) में रहता है।
Executor (निष्पादक)। एक बार जब ट्री उन लीफ नोड्स (leaf nodes) तक पहुँच जाता है जो कार्य करने के लिए पर्याप्त छोटे हैं, तो executors उन्हें हासिल करने की होड़ में लग जाते हैं। वे किसी केंद्रीय कतार (central queue) से अनुमति का इंतज़ार नहीं करते हैं। इसके बजाय, वे यह तय करने के लिए कि किसी कार्य पर किसका अधिकार है, एक टाइमस्टैम्प प्रोटोकॉल (timestamp protocol) का उपयोग करते हैं। विजेता एक स्थानीय LLM कॉल के माध्यम से कार्य को चलाता है और परिणाम प्रसारित करता है।
Observer (अवलोकनकर्ता)। यह वह शांत सदस्य है जिसकी हर नेटवर्क को आवश्यकता होती है। यह चुपचाप गॉसिप सुनता है, बातचीत से प्लान ट्री का पुनर्निर्माण करता है, और एक पठनीय स्नैपशॉट प्रिंट करता है। क्योंकि यह कभी बोलता नहीं है, यह एक महत्वपूर्ण बात साबित करता है: देर से जुड़ने वाला कोई भी व्यक्ति केवल सुनकर पूरी योजना का पता लगा सकता है।
सत्य के स्रोत के रूप में गॉसिप
libp2p लेयर डिस्कवरी और मैसेजिंग को संभालती है। एजेंट प्रोटोकॉल की अंतर्निहित पीयर डिस्कवरी के माध्यम से एक-दूसरे को पाते हैं, फिर एक साझा विषय (topic) पर संदेश प्रसारित करते हैं। यहाँ कोई रिकॉर्ड डेटाबेस नहीं है, कोई Redis कैश नहीं है जो आधिकारिक (canonical) योजना को रखता हो।
प्रत्येक पीयर प्लान ट्री की अपनी प्रति रखता है और सुनी गई गॉसिप के आधार पर इसे अपडेट करता है। जब एक decomposer प्रस्ताव प्रसारित करता है, तो प्रत्येक अन्य नोड इसे प्राप्त करता है, प्रारूप को मान्य करता है, और अपनी स्थानीय ट्री में शाखा जोड़ता है। जब scorers वोट डालते हैं, तो गणना (tally) उसी तरह प्रसारित होती है। यदि दो executors एक ही कार्य के लिए परस्पर विरोधी दावे प्रकाशित करते हैं, तो टाइमस्टैम्प प्रोटोकॉल टकराव (collision) को हल करता है। नेटवर्क पहले दावे पर सहमत होता है और देर से आए दावे को खारिज कर देता है।
समय के साथ, ट्री मूल लक्ष्य से स्वीकृत उप-लक्ष्यों की परतों के माध्यम से नीचे की ओर बढ़ता है जब तक कि वह छोटे-छोटे कार्यों (bite-sized tasks) तक नहीं पहुँच जाता। यह प्रक्रिया ब्लॉकचेन द्वारा सर्वसम्मति (consensus) तक पहुँचने के समान है, सिवाय इसके कि यहाँ पेलोड सिक्कों का बहीखाता (ledger) होने के बजाय यात्रा कार्यक्रम या सॉफ़्टवेयर विनिर्देश (spec) है।
मतदान और निष्पादन की दौड़
लोकतंत्र महंगा है, और यह सिस्टम इसकी कीमत लेटेंसी (latency) के रूप में चुकाता है। एक विभाजन तभी जीतता है जब पर्याप्त scorers सहमत हों। वह सीमा (threshold) एक साधारण बहुमत या एक सख्त कोरम (quorum) हो सकती है, जो इस बात पर निर्भर करती है कि आप क्लस्टर को कैसे कॉन्फ़िगर करते हैं। Decomposers प्रस्ताव देना बंद नहीं करते हैं, इसलिए नेटवर्क अक्सर एक साथ कई प्रतिस्पर्धी ट्री का मूल्यांकन करता है। अंततः, एक ट्री आवश्यक वोटों तक पहुँच जाता है और उसके उप-लक्ष्य ड्राफ्ट से स्वीकृत (accepted) श्रेणी में आ जाते हैं।
एग्जीक्यूटर्स समन्वय की एक और परत जोड़ते हैं। चूंकि गॉसिप चैनल पर टास्क सार्वजनिक होते हैं, इसलिए कई एग्जीक्यूटर्स एक ही आकर्षक लीफ नोड को पकड़ने की कोशिश कर सकते हैं। टाइमस्टैम्प प्रोटोकॉल एक टाईब्रेकर के रूप में कार्य करता है। प्रत्येक दावे के साथ एक मोनोटोनिक टाइमस्टैम्प होता है, और नेटवर्क सबसे पुराने दावे को स्वीकार करता है। हारने वाला बस अगले उपलब्ध टास्क पर चला जाता है। यह एक सरल तरीका है, लेकिन यह डेटाबेस में रो (rows) को लॉक करने वाले एक केंद्रीकृत शेड्यूलर की आवश्यकता को टाल देता है।
डिज़ाइन द्वारा लचीलापन
जब चीजें खराब होती हैं, तब यह आर्किटेक्चर अपनी उपयोगिता साबित करता है। यदि कोई डीकंपोज़र आधे सबगोल्स प्रस्तावित करने के बाद क्रैश हो जाता है, तो जीवित बचे डीकंपोज़र्स स्प्लिट्स पेश करना जारी रखते हैं। प्लान रीस्पॉन का इंतज़ार करते हुए रुकता नहीं है। यदि कोई स्कोरर नेटवर्क से हट जाता है, तो शेष वोटर्स अभी भी कोरम तक पहुँच सकते हैं, बशर्ते आपने क्लस्टर का आकार उचित रूप से रखा हो।
असली लाभ 'लेट जॉइन्स' में है। एक नया एजेंट जो बीच में बूट अप होता है, उसे स्नैपशॉट या एक
