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