𝗬𝗼𝘂 𝗗𝗼𝗻'𝘁 𝗡𝗲𝗲𝗱 𝗦𝘂𝗯-𝗔𝗴𝗲𝗻𝘁𝘀
ज़्यादातर लोग एजेंट आर्किटेक्चर को संगठनात्मक चार्ट (organizational charts) की तरह बनाते हैं।
वे सबसे ऊपर एक Orchestrator रखते हैं। वे एक Researcher, एक Coder और एक Tester के लिए लाइनें खींचते हैं। यह देखने में साफ़-सुथरा और प्रोफेशनल लगता है।
यह एक गलती है।
1975 में, फ्रेड ब्रूक्स (Fred Brooks) ने लिखा था कि किसी देरी से चल रहे सॉफ्टवेयर प्रोजेक्ट में और अधिक लोगों को जोड़ने से वह और भी देरी से पूरा होता है। ऐसा इसलिए होता है क्योंकि काम पूरा होने की गति की तुलना में संचार की लागत (communication costs) तेज़ी से बढ़ती है।
जब आप एजेंटों का एक झुंड (swarm) बनाते हैं, तो आप इसी गलती को दोहराते हैं।
Orchestrator अपना सारा समय सब-टास्क (subtasks) को मैनेज करने में बिता देता है। इससे भारी ओवरहेड (overhead) पैदा होता है। आप कोई आर्किटेक्चर नहीं बना रहे हैं, बल्कि आप केवल प्लंबिंग (plumbing) कर रहे हैं।
यहाँ बताया गया है कि सब-एजेंट्स क्यों विफल होते हैं:
- कॉन्टेक्स्ट का नुकसान (Context loss): एक सब-एजेंट अपने स्वयं के विंडो में चलता है। वह अपने पूरे तर्क (reasoning) को पैरेंट (parent) तक नहीं पहुँचा सकता। वह केवल एक सारांश (summary) भेजता है।
- महंगे वर्कअराउंड (Expensive workarounds): लोग एजेंटों को फ़ाइलों या git में लिखने के लिए मजबूर करते हैं ताकि पैरेंट यह पढ़ सके कि क्या हुआ। आप साझा मेमोरी (shared memory) का पुनरुद्धार कर रहे हैं, लेकिन उसे और धीमा बना रहे हैं।
- टोकन की बर्बादी (Token waste): हर सीमा (boundary) के पार कॉन्टेक्स्ट भेजने के लिए आपको भुगतान करना पड़ता है। N एजेंटों के झुंड की लागत टोकन के मामले में N+1 होती है।
- विरोधाभासी निर्णय (Conflicting decisions): समानांतर (parallel) एजेंट अलग-अलग धारणाएं बनाते हैं। यदि दो एजेंट एक ही चीज़ बनाते हैं, तो वे अक्सर अलग-अलग शैलियों या तर्क का उपयोग करते हैं।
शोध से पता चलता है कि मल्टी-एजेंट फ्रेमवर्क की विफलता दर 41% से 87% के बीच होती है। ये विफलताएं इसलिए होती हैं क्योंकि एजेंट एक-दूसरे की बात को ठीक से नहीं समझ पाते (talk past each other)। एक बेहतर मॉडल इसे ठीक नहीं करेगा। यह समन्वय (coordination) की समस्या है, मॉडल की समस्या नहीं।
इसके बजाय आपको कैसे निर्माण करना चाहिए?
इन दो नियमों का पालन करें:
- यदि कार्य स्वतंत्र हैं, तो उन्हें अलग-अलग लूप (loops) के रूप में चलाएं। दो अलग-अलग प्रोग्राम का उपयोग करें। यह पैरेलल प्रोसेसिंग (parallel processing) है, मल्टी-एजेंट सिस्टम नहीं।
- यदि कार्य के लिए विचारों की एक ही श्रृंखला (single train of thought) की आवश्यकता है, तो एक ही लूप का उपयोग करें।
एक अकेला लूप सभी कॉन्टेक्स्ट को एक ही स्थान पर रखता है। यह आसानी से स्वयं को सुधार (self-correct) लेता है। यह एक अव्यवस्थित ग्रुप चैट के बजाय एक साफ़ इतिहास छोड़ता है।
मेश (meshes) बनाना बंद करें। लूप (loops) बनाना शुरू करें।
स्रोत: https://dev.to/tony__vi/you-dont-need-sub-agents-1eh7
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi