एक एकल उपकरण कॉल के साथ अपना पहला AI एजेंट बनाएँ
AI एजेंट बनाने के लिए एक शुरुआती गाइड जो बाहरी डेटा लाने, परिणामों पर तर्क करने और आगे स्केलिंग से पहले प्रतिक्रिया देने के लिए एकल टूल कॉल का उपयोग करता है।
मुख्य जानकारी
- मेमोरी, प्लानिंग और कई टूल्स को एक साथ जोड़ने के बजाय AI एजेंट लूप बनाने के लिए एक ही टूल कॉल से शुरू करें।
- एक टूल कॉल मॉडल को संरचित क्रियाओं का अनुरोध करने देता है, जबकि बाहरी उपकरण वास्तविक डेटा प्रदान करता है या अनुमत ऑपरेशन निष्पादित करता है।
- स्पष्ट इनपुट और आउटपुट के साथ एक छोटा, सुरक्षित, केवल पढ़ने योग्य पहला कार्य चुनें और अनुमानित तर्क प्रारूपों के साथ संकीर्ण उपकरण को परिभाषित करें।
- एक न्यूनतम एजेंट लूप बनाएँ जो प्रश्न और उपकरण विवरण को मॉडल में भेजता है, अनुरोधित टूल चलाता है परिणाम देता है और अंतिम उत्तर या सेट चरण सीमा के बाद रुक जाता है।
- संदेश भेजने, फ़ाइलों को संपादित करने या वास्तविक प्रणालियों को बदलने जैसे जोखिम भरे कार्रवाई-लेने वाले उपकरणों की अनुमति देने से पहले मानव जांच जोड़ें।
मेटा विवरण: Towards Data Science से इस शुरुआती ट्यूटोरियल में स्पष्ट चरणों, जोखिमों और अगले कार्यों के साथ एक उपकरण कॉल के साथ अपने पहले AI एजेंट का निर्माण करना सीखें।
टैगः AI एजेंट, उपकरण कॉल, शुरुआती ट्यूटोरियल, Towards Data Science, फ़ंक्शन कॉल
विशेष रुप से प्रदर्शित छवि: एक छोटे robot का अमूर्त, मैत्रीपूर्ण चित्रण सरल मेनू से एक उपकरण चुन रहा है; कोई वास्तविक लोग नहीं हैं, न ही लोगो और पाठ।
One Tool Call के साथ Build Your First AI एजेंट शीर्षक वाली पोस्ट पहली बार Towards Data Science पर AI Agents for Beginners के भाग 1 के रूप में दिखाई दी। यह गाइड उन शुरुआती लोगों के लिए है जो समझना चाहते हैं कि एक साधारण AI एजेंट कैसे काम करता है बिना किसी बड़े ढांचे की नकल किए। आपको एजेन्ट की सादे भाषा परिभाषा, एक सुरक्षित पहला बिल्ड पैटर्न और किसी भी टूल को मॉडल से जोड़ने से पहले आवश्यक जांच मिलेगी। आपूर्ति की गई सामग्री में प्रकाशन तिथि, मॉडल का नाम, प्रदाता या कोड नमूना शामिल नहीं है, इसलिए यह मार्गदर्शिका प्रदाता-तटस्थ रहती है और केवल सामान्य अवधारणाओं का उपयोग करती है जिसे पाठक अपने चुने हुए उपकरण के खिलाफ सत्यापित कर सकता है।
क्यों एक उपकरण कॉल एक उपयोगी प्रारंभिक बिंदु है
AI एजेंट को सबसे अच्छी तरह से एक छोटी सी प्रणाली के रूप में समझा जाता है जो टेक्स्ट जनरेटर से मॉडल को कुछ ऐसा बनाती है जो कार्रवाई कर सकता है। केवल एक प्रश्न का उत्तर देने के बजाय, एजेंट एक कदम चुन सकता है, एक टूल कॉल कर सकते हैं, परिणाम पढ़ सकते हैं और फिर निर्णय ले सकते हैं कि आगे क्या करना है। सबसे सरल उपयोगी संस्करण को केवल एक उपकरण कॉल की आवश्यकता होती है। यह सीमा महत्वपूर्ण है क्योंकि शुरुआती अक्सर विफल हो जाते हैं जब वे बहुत अधिक चल भागोंः स्मृति, बहु-चरण योजना, कई APIs , पुनः प्रयास और जटिल संकेत सभी एक साथ शुरू करते हैं।
एक टूल कॉल मॉडल से बाहरी फ़ंक्शन के लिए एक संरचित अनुरोध है। उदाहरण के लिए, यदि कार्य वर्तमान मौसम का उपयोग करके किसी प्रश्न का उत्तर देना है, तो मॉडल मौसम लुकअप का अनुरोध कर सकता है। फिर कार्यक्रम उस लुक अप को चलाता है और परिणाम वापस मॉडल को देता है। मॉडल जादुई रूप से मौसम नहीं जानता; उपकरण इसे आपूर्ति करता है। यह अलगाव विश्वास के लिए महत्वपूर्ण है।
एक उपकरण कॉल के साथ शुरू करने से डिबगिंग भी आसान हो जाती है। यदि उत्तर गलत है, तो पाठक तीन चीजों की जांच कर सकता हैः क्या टूल सही ढंग से चुना गया था, तर्क सही थे और टूल आउटपुट को सही तरीके से व्याख्या किया गया था। यह पूर्ण एजेंट फ्रेमवर्क को ठीक करने की तुलना में बहुत छोटी समस्या है। शुरुआत के लिए, लक्ष्य प्रभावशाली डेमो का निर्माण नहीं करना है। उद्देश्य एक विश्वसनीय लूप बनाना है जिसे बाद में विस्तारित किया जा सके।
निर्माण से पहले आपको क्या चाहिए
कोड लिखने या प्रॉम्प्ट कॉन्फ़िगर करने से पहले, एक ऐसा कार्य चुनें जो छोटा, उपयोगी और सुरक्षित हो। अच्छे प्रथम कार्यों में स्पष्ट इनपुट और आउटपुट होते हैं। मौसम की खोज, इकाई रूपांतरण, दिनांक गणना, सरल कैलकुलेटर या अपने स्वयं के नोट्स की खोज सभी काम कर सकते हैं। बुरा पहला कार्य कुछ है जो email भेजता है, भुगतान करता है, फ़ाइलों को संपादित करता है या उत्पादन प्रणालियों को बदलता है। ये क्रियाएं वास्तविक दुनिया का जोखिम पैदा करती हैं इससे पहले कि पाठक ने एजेंट को नियंत्रित करना सीखा हो।
आपको एक मॉडल या API की भी आवश्यकता है जो टूल उपयोग या फ़ंक्शन कॉलिंग का समर्थन करता है. चूंकि मूल सामग्री में प्रदाता का नाम नहीं दिया गया है, इसलिए किसी विशिष्ट सेवा को न मानें. अपने चुने हुए प्लेटफ़ॉर्म में इन बुनियादी क्षमताओं के लिए देखें: मॉडल को उपलब्ध उपकरणों का विवरण भेजने का एक तरीका, मॉडल के लिए अनुरोधित उपकरण और उसके तर्कों को वापस करने का एक रास्ता, और टूल परिणाम को मॉडल पर वापस भेजना। यदि प्लेटफार्म केवल सादे पाठ प्रतिक्रियाओं का समर्थन करते हैं, तो आप अभी भी एजेंट पैटर्न का अनुकरण कर सकते हैं, लेकिन यह कम विश्वसनीय और अधिक मैनुअल होगा।
अंत में, उपकरण को ध्यान से परिभाषित करें। एक टूल के पास एक काम होना चाहिए, एक अपेक्षित आउटपुट प्रारूप और एक स्पष्ट अनुमति सीमा होनी चाहिए। यदि उपकरण कैलकुलेटर है, तो इसे केवल गणना करनी चाहिए। अगर यह नोट्स की खोज करने वाला है तो उसे केवल नोट्स पढ़ना चाहिए; यदि यह मौसम का कार्य है तो वह केवल मौसम की जानकारी लौटाता है। संकीर्ण उपकरण एजेंट को परीक्षण करना आसान बनाते हैं और भरोसा करना आसान करते हैं।
चरण-दर-चरण: सबसे छोटा उपयोगी एजेंट बनाएं
- एक उपयोगकर्ता प्रश्न चुनें जिसे बाहरी जानकारी की आवश्यकता हो. उदाहरण के लिए, "मेरे शहर में वर्तमान तापमान क्या है?" या "दो तिथियों के बीच कितने दिन हैं? सवाल इतना सरल होना चाहिए कि एक उपकरण इसका उत्तर दे सके। ऐसे सवालों से बचें जिनसे एजेंट को internet ब्राउज़ करने, फ़ाइलों को संपादित करने या कई क्रियाएं करने की आवश्यकता होती है.
- उपकरण का एक सादे भाषा में वर्णन लिखें। यह विवरण मॉडल को बताता है कि उपकरण का उपयोग कब करना है और उसे किस इनपुट की आवश्यकता है। एक अच्छा विवरण कहता है कि टूल क्या करता है, वह क्या नहीं करता है और कौन से मान आवश्यक हैं। दिनांक कैलकुलेटर के लिए, कहेंः "इस टूल का उपयोग करें जब उपयोगकर्ता दो तिथियों के बीच दिनों की संख्या पूछता है। इसे प्रारूप YYYY-MM-DD में प्रारंभ तिथि और समाप्ति तिथि की आवश्यकता होती है।"
- उपकरण के लिए एक इनपुट प्रारूप चुनें. मॉडल को तर्क पूर्वानुमान योग्य रूप में लौटना चाहिए. कई सिस्टम JSON जैसे संरचित स्वरूपों का उपयोग करते हैं, लेकिन सटीक प्रारूप प्रदाता पर निर्भर करता है. फ़ील्ड सरल रखें। यदि टूल को स्थान की आवश्यकता होती है, तो स्थान नामक एक क्षेत्र का उपयोग करें. यदि इसे तिथियों की आवश्यकता हो, तो start_date और end_date का उपयोग करे. विवरण या जानकारी जैसे अस्पष्ट क्षेत्रों से बचें.
- टूल फ़ंक्शन का निर्माण करें. फंक्शन को तर्क लेना चाहिए, वास्तविक ऑपरेशन चलाना चाहिए और एक स्पष्ट परिणाम वापस करना चाहिए। यदि आपरेशन विफल हो जाता है, तो क्रैश होने के बजाय एक स्पष्ट त्रुटि संदेश लौटाएं। शुरुआत करने वाले व्यक्ति को पहले मॉडल के बिना कार्य की जांच करनी चाहिए। अगर समारोह अपने दम पर सही उत्तर नहीं दे सकता, तो मॉडल उस समस्या को ठीक नहीं करेगा।
- एजेंट लूप बनाएँ. न्यूनतम लूप में तीन चरण होते हैंः उपयोगकर्ता प्रश्न और टूल विवरण मॉडल को भेजें, मॉडल प्रतिक्रिया प्राप्त करें, और यदि उत्तर एक उपकरण के लिए पूछता है, तो टूल चलाएं और परिणाम वापस भेजें। अगर मॉडल अंतिम जवाब देता है, रोक दें। इस लूप की अधिकतम संख्या होनी चाहिए कदमों की सीमा के बिना, एक भ्रमित मॉडल उपकरण का अनुरोध कर सकता है और कभी समाप्त नहीं हो सकता है।
- जोखिम भरे कार्यों से पहले एक मानव जांच जोड़ें. यहां तक कि एक-टूल एजेंट के लिए, पाठक को यह तय करना चाहिए कि उपकरण केवल पढ़ने योग्य है या कार्रवाई करने वाला है। मौसम लुकअप आमतौर पर केवल-पढ़ने योग्य होता है। कोई फ़ंक्शन जो सामग्री पोस्ट करता है, फ़ाइलों को हटा देता है, या संदेश भेजता है वह नहीं है। यदि टूल किसी क्रिया को निष्पादित करता है तो नियोजित कार्य दिखाएं और इसे चलाने से पहले पुष्टि मांगें। यह सबसे सरल सुरक्षा आदत है जो खराब एजेंट व्यवहार को रोकती है।
- स्पष्ट मामलों और टूटे हुए मामलों के साथ परीक्षण करें। एजेंट को सामान्य प्रश्नों, लापता जानकारी और असंभव अनुरोधों के साथ चलाएं। एक सामान्य सवाल हो सकता हैः "पेरिस में तापमान क्या है?" एक लापत-सूचना प्रश्न यह हो सकता है किः "तापमान क्या है? "एजेंट को अनुमान लगाने के बजाय शहर के लिए पूछना चाहिए। एक असम्भव अनुरोध हो सकता हैंः "चंद्रमा पर तापमान कितना है?" एजेन्ट को यह पहचानना चाहिए कि उपकरण उस उत्तर का समर्थन नहीं करता है। ये परीक्षण एजेंट से सीखते हैं कि कैसे कहें नहीं, जो हां कहने जितना ही महत्वपूर्ण है।
आम गलतियाँ
सबसे आम गलती मॉडल को उपकरण के परिणामों का आविष्कार करने देना है। एक मॉडल तब भी आश्वस्त उत्तर दे सकता है जब टूल को नहीं बुलाया गया था। इससे बचने के लिए, अंतिम उत्तर की आवश्यकता होती है कि वह टूल आउटपुट पर आधारित हो जब प्रश्न बाहरी डेटा पर निर्भर करता है। यदि उपकरण विफल रहता है, तो एजेंट को यह कहना चाहिए कि वह अंतराल भरने के बजाय डेटा प्राप्त नहीं कर सका।
एक और गलती उपकरण को बहुत व्यापक बनाना है. ऐसा उपकरण जो "कुछ भी कर सकता है" का परीक्षण करना कठिन होता है और इसका उपयोग करने के लिए खतरनाक होता है। शुरुआती लोगों को पूरे एप्लिकेशन को एक फ़ंक्शन में लपेटने की इच्छा से बचना चाहिए। एक संकीर्ण कार्रवाई के साथ शुरू करें। पहली कार्रवाई विश्वसनीय होने के बाद ही विस्तार करें।
एक तीसरी गलती एजेंट को बहुत अधिक अनुमति देना है। यदि उपकरण निजी फ़ाइलों तक पहुंच सकता है, संदेश भेज सकता है या सिस्टम सेटिंग्स बदल सकता है तो इसे आवश्यक न्यूनतम विशेषाधिकार के साथ चलाना चाहिए। सादे संकेतों में संवेदनशील क्रेडेंशियल स्टोर न करें। मॉडल को वैधता के बिना मनमाने यूआरएल या फाइल नहीं चुनने दें। शीघ्र इंजेक्शन एक व्यावहारिक जोखिम हैः वेब पृष्ठों, ईमेल या दस्तावेजों में छिपे हुए निर्देश एजंट को पुनर्निर्देशित करने का प्रयास कर सकते हैं। शुरुआती परियोजना के लिए, सबसे सुरक्षित उत्तर उन उपकरणों से बचना है जो कोर लूप की अच्छी तरह से जांच होने तक अपरिवर्तनीय कार्रवाई कर सकती हैं।
चौथी गलती मूल्यांकन को छोड़ना है। एजेंट एक डेमो में प्रभावशाली लग सकता है लेकिन सामान्य उपयोग में विफल हो जाता है। तीन सरल मैट्रिक्स ट्रैक करेंः क्या सही उपकरण बुलाया गया था, तर्क सही थे और क्या अंतिम उत्तर टूल परिणाम से मेल खाता था? आपको बड़े बेंचमार्क dataset की आवश्यकता नहीं है। कमजोर टूल विवरण और अस्पष्ट संकेतों का खुलासा करने के लिए दस अच्छी तरह से चुने गए परीक्षण मामले पर्याप्त हैं।
इन बुनियादी बातों के बाद, अगला कदम एक बार में कई उपकरण नहीं जोड़ना है। पाठक को उन पैटर्नों पर ध्यान देना चाहिए जो वास्तविक एजेंट सिस्टम में मायने रखते हैंः जब कोई टूल विफल हो जाता है तो पुनः प्रयास करता है, मॉडल ने जो पूछा था उसे लॉग करते हुए, समय-अवधि जो रनवे लूप को रोकते हैं, और अनुमति नियम जो पढ़ने से लिखने से अलग होते हैं। ये वे विशेषताएं हैं जो एक-टूल डेमो को भरोसेमंद वर्कफ़्लो में बदल देती हैं। अभी के लिए, सबसे महत्वपूर्ण सबक सरल हैः एक AI एजेंट तब उपयोगी होता है जब यह सुरक्षित रूप से एक टूल कॉल कर सकता है और परिणाम का ईमानदारी से उपयोग कर सकता ਹੈ।

Comments (0)