अपने एजेंट-आधारित सिस्टम में निर्णय कैसे और कहां लिए जाते हैं, इस पर सावधानी से विचार करना महत्वपूर्ण है.
LLM को अधिक निर्णय सौंपने से सिस्टम अधिक प्रकार के कार्यों के अनुकूल हो सकता है, लेकिन इससे गति, विश्वसनीयता और सुदृढ़ता प्रभावित हो सकती है.
जहां संभव हो, निर्णय लेने की प्रक्रिया का अधिकतम हिस्सा LLM से निकालकर स्पष्ट सॉफ़्टवेयर कोड में रखें. यह खास तौर पर उच्च जोखिम वाले और उत्पादन कार्यप्रवाहों पर लागू होता है.
LLM-आधारित एजेंट सिस्टम बनाते समय सबसे महत्वपूर्ण निर्णयों में से एक यह है कि निर्णय-प्रक्रिया का कितना हिस्सा LLM मॉडल में रखा जाए और कितना स्पष्ट सॉफ़्टवेयर में.
इसे समझने के लिए हम इस विकल्प को निम्नलिखित तरीकों के बीच एक विस्तार-क्रम के रूप में देख सकते हैं:
राउटर-आधारित संरचनाएं कोड में क्रम और तर्क स्पष्ट रूप से परिभाषित करती हैं, जिससे सीमित दायरे वाले कार्यों में परीक्षण-योग्यता, पूर्वानुमेयता और सुदृढ़ता सुनिश्चित होती है. इन्हें ‘कार्यप्रवाह एजेंट’ भी कहा जाता है.
ऑर्केस्ट्रेटर एजेंट प्राकृतिक भाषा के निर्देशों से कार्यप्रवाह तय करने के लिए बड़े भाषा मॉडल (LLM) पर निर्भर होते हैं. ये ऐसे मुक्त संवादों के लिए आदर्श हैं, जहां पूर्वनिर्धारित तर्क अपर्याप्त या असंभव हो.
उच्च जोखिम वाले उत्पादन कार्यप्रवाहों में हम आम तौर पर अधिक राउटर-आधारित सुविधाएं अपनाने और ऑर्केस्ट्रेटर को लचीली, सामान्य प्रयोजन की बातचीत वाले अनुप्रयोगों तक सीमित रखने की सलाह देते हैं.
राउटर-आधारित संरचनाएं
राउटर एजेंट सिस्टम:
कोड या सॉफ़्टवेयर के माध्यम से निर्णय-प्रवाह स्पष्ट रूप से परिभाषित करते हैं और यह तय करने के लिए LLM का उपयोग करते हैं कि सॉफ़्टवेयर कौन-सा मार्ग अपनाए.
ये पारंपरिक सॉफ़्टवेयर सिस्टम के अधिक करीब होते हैं, क्योंकि इनके मार्ग स्पष्ट और पूर्वानुमेय होते हैं तथा परिणाम अधिक सुसंगत रहते हैं.
ये स्पष्ट रूप से परिभाषित किए जा सकने वाले कार्यों के लिए आदर्श हैं.
नीचे ‘राउटर तरीका’ अपनाने वाले विमान सेवा बुकिंग चैटबॉट एजेंट का एक सरल उदाहरण है. LLM तीन संभावित विकल्पों में से प्रश्न का आशय वर्गीकृत करता है, लेकिन अंततः हमारा सॉफ़्टवेयर ही उस आशय को पहले से तैयार उत्तर से जोड़ता है. LLM पर कड़े प्रतिबंध होने के कारण उपयोगकर्ता को अधिक सुसंगत व्यवहार मिलता है.
ऑर्केस्ट्रेटर संरचनाएं
राउटर सिस्टम के विपरीत, ऑर्केस्ट्रेटर एजेंट सिस्टम:
सॉफ़्टवेयर के बजाय प्राकृतिक भाषा के निर्देशों से तार्किक प्रवाह परिभाषित करते हैं. ध्यान दें: प्रोग्रामिंग भाषा की तुलना में प्राकृतिक भाषा स्वभावतः अस्पष्ट और लचीली होती है. ये दोनों गुण सकारात्मक भी हैं और नकारात्मक भी, जैसा कि हम आगे देखेंगे. हम इसे ‘निर्देश के बजाय आशय’ मानते हैं.
ये प्रसंस्करण के कई विकल्प दे सकते हैं, जबकि LLM निष्पादन का क्रम और तरीका तय करता है.
ये ऐसे नए तार्किक मार्ग गतिशील रूप से बना सकते हैं, जिन्हें सॉफ़्टवेयर में स्पष्ट रूप से परिभाषित करना कठिन होता है.
यह अस्पष्टता असंगत परिणाम दे सकती है, लेकिन सही ढंग से काम करने पर यह ‘जादुई’ लग सकती है.
निम्न उदाहरण विमान सेवा की उसी सरल समस्या पर ऑर्केस्ट्रेटर तरीका लागू करता है. उचित उत्तर का निर्णय सॉफ़्टवेयर से कराने के बजाय निर्णय-प्रक्रिया LLM परत को सौंप दी जाती है. यहां एक बहु-एजेंट सिस्टम है, जिसमें एक ‘मुख्य’ ऑर्केस्ट्रेटर एजेंट उपयोगकर्ता की क्वेरी छांटकर उसे उड़ान बदलने के लिए विशेष रूप से बनाए गए एजेंट को सौंपता है, जो अंततः उपयोगकर्ता को उत्तर देता है.
इस उदाहरण में LLM परत वर्गीकरणकर्ता, राउटर और उत्तर-लेखक की भूमिकाएं निभा रही है. राउटर वाले उदाहरण में यह केवल वर्गीकरणकर्ता की भूमिका निभा रही थी और बाकी काम सॉफ़्टवेयर कर रहा था.
जहां संभव हो, हम राउटर-आधारित तरीका अपनाने की सलाह देते हैं, क्योंकि इसके निम्न लाभ हैं:
गति और दक्षता: स्थानीय गणना, बाहरी एपीआई पर निर्भर ऑर्केस्ट्रेटर की तुलना में अधिक तेज होती है. आपके ‘अगर/अन्यथा’ तर्क को पाइथन में संसाधित करना, उसे 400 अरब मापदंडों वाले मॉडल से चलाने के लिए किसी LLM प्रदाता को भुगतान करने की तुलना में बहुत सस्ता भी है.
परीक्षण-योग्यता और पूर्वानुमेयता: स्थापित सॉफ़्टवेयर पद्धतियों से त्रुटियां ढूंढना, परीक्षण करना और रखरखाव करना काफी आसान होता है.
पारदर्शिता और विश्वसनीयता: व्यवहार में कम भिन्नता से समस्या का कारण ढूंढना आसान होता है. अनुप्रयोग के प्रवाह का बड़ा हिस्सा पारदर्शी और संस्करण-नियंत्रित सॉफ़्टवेयर में व्यक्त होता है, न कि LLM के अपारदर्शी और समझ से परे भारों में.
राउटर तरीकों की कमियां यह हैं कि वे कठोर और अलचीले हो सकते हैं तथा अधिक मुक्त समस्याओं से निपटने में कठिनाई महसूस कर सकते हैं. हमेशा बिल्कुल एक जैसे उत्तर देने वाला चैटबॉट उपयोगकर्ताओं को उबाऊ या ठहरा हुआ लग सकता है.
ऑर्केस्ट्रेटर रूपरेखाओं में प्रभावशाली क्षमताएं होती हैं:
योजना बनाना: ये गतिशील रूप से उत्तर की योजना बना सकती हैं.
उपकरण चयन और एजेंट को हस्तांतरण: उचित उपकरण चुनना या एजेंट को कार्य सौंपना.
परिणामों का पुनरावृत्त संयोजन: परिणामों को बार-बार सुधारना और रचनात्मक ढंग से फिर जोड़ना.
पूर्णता तय करना: यह तय करना कि अंतिम उत्तर तैयार करने के लिए पर्याप्त जानकारी एकत्र हो गई है.
Pydantic-AI या OpenAI के Agents SDK जैसे ढांचों से ऑर्केस्ट्रेशन को लागू करना आसान और तेज हो जाता है. इसलिए यह प्रदर्शन या अवधारणा के प्रमाण के लिए बहुत उपयोगी है.
इस तरीके की कमियां ये हैं:
इसकी कोई गारंटी नहीं है कि LLM की योजना के चरण और उनके बाद की कार्रवाइयां सही या उचित होंगी. राउटर सिस्टम में भी यही समस्या है, लेकिन अधिक सीमित होने के कारण उसका व्यवहार अधिक पूर्वानुमेय होता है.
सरल और स्पष्ट रूप से परिभाषित कार्यों के लिए बहु-एजेंट सिस्टम की पूरी क्षमता की आवश्यकता शायद नहीं होती. उदाहरण के लिए, हमारे विमान सेवा एजेंट के मामले में शायद कुछ सीमित प्रकार की क्वेरी ही होंगी, जिन्हें विमान सेवा सहायता सिस्टम का उपयोग करने वाला व्यक्ति पूरा करना चाहता है.
LLM में अधिक तर्क समाहित होने के कारण दुर्भावनापूर्ण लोगों के लिए इसे जेलब्रेक करना या इसका दुरुपयोग करना कहीं आसान हो जाता है.
यह निर्णय-प्रक्रिया को LLM के भीतर अमूर्त कर देता है, जिससे आपके सिस्टम को समझना कठिन हो जाता है. हालांकि Langfuse या Braintrust जैसे निगरानी उपकरण इसमें कुछ मदद कर सकते हैं.
पाठक के लिए टिप्पणी: मॉडल की क्षमता तेजी से बदल रही है, फिर भी निकट भविष्य में नीचे दी गई बातें बदलने की संभावना कम है.
अपनी समस्या का दायरा तय करें.
क्या आप अपनी इच्छित निर्णय-प्रक्रिया को किसी आरेख में आसानी से परिभाषित कर सकते हैं?
क्या आपके अनुप्रयोग में विफलता या अप्रत्याशित व्यवहार बिल्कुल स्वीकार्य नहीं है?
ऊपर दिए गए किसी भी प्रश्न का उत्तर ‘हां’ होने पर राउटर सुविधाएं बेहतर विकल्प होंगी.
जहां तक संभव हो, हम राउटर तरीके अपनाने की सलाह देते हैं. सामान्य सिद्धांत यह है कि यदि आपके सिस्टम का कोई हिस्सा कोड में व्यक्त किया जा सकता है, तो उसे कोड में ही लिखें. यानी आवश्यकता न होने पर LLM का अत्यधिक उपयोग न करें.
इन तरीकों की सीमा पूरी होने पर मुक्त ऑर्केस्ट्रेटर के कुछ लाभों को नियंत्रित रूप में दोहराया जा सकता है. उदाहरण के लिए:
उपकरण चयन और एजेंट को हस्तांतरण: इसे सशर्त शाखाओं या LLM वर्गीकरणकर्ताओं से आसानी से लागू किया जा सकता है.
पूर्णता तय करना: सरल LLM वर्गीकरणकर्ता उपयोगकर्ता को उत्तर भेजने से पहले जांच सकते हैं कि वह पूरा है या नहीं.
हालांकि कठोर राउटर सिस्टम में ‘योजना बनाना’ और ‘परिणामों का पुनरावृत्त संयोजन’ निस्संदेह कहीं अधिक कठिन हैं. इसलिए जब किसी कार्य में इनकी आवश्यकता हो, जैसा कि LLM वर्गीकरणकर्ता या कोई अन्य तर्क तय करे, तो हम सिस्टम में कम प्रतिबंध वाली ऑर्केस्ट्रेटर शाखा बनाने का सुझाव देते हैं.
राउटर और ऑर्केस्ट्रेटर संरचनाओं के बीच आपका चुनाव अनुप्रयोग की स्पष्टता, जटिलता और संवाद शैली के अनुरूप होना चाहिए. फिलहाल राउटर-आधारित तरीके स्पष्ट रूप से परिभाषित कार्यों के लिए विश्वसनीयता, दक्षता और आसान परीक्षण प्रदान करते हैं. ऑर्केस्ट्रेटर व्यापक, संवादपरक बातचीत के लिए अधिक लचीलापन देते हैं.
LLM के लगातार उन्नत होने के साथ इन तरीकों के बीच संतुलन बदल सकता है. उत्पादन कार्यभारों के लिए हम राउटर-आधारित या मिश्रित संरचनाओं को प्राथमिकता देते हैं और ऑर्केस्ट्रेटर को ऐसी मुक्त समस्याओं के लिए रखते हैं, जिनमें गतिशील और मानव-जैसे संवाद की आवश्यकता हो.