नफा:
- एजंटला 'मॉडेल + टूल्स + लूप' म्हणून परिभाषित करणे आणि त्याची गरज कधी आहे हे ठरवणे
- नाव, वर्णन आणि इनपुट_स्कीमासह टूलची व्याख्या लिहित आहे
- टूल_उपयोग आणि टूल_रिझल्ट लूपचा प्रवाह आणि त्रुटी हाताळणीचे निरीक्षण करणे
आत्तापर्यंत, मॉडेलने नेहमीच एक काम केले आहे: मजकूर इनपुट प्राप्त करा, मजकूर प्रतिसाद तयार करा. परंतु वास्तविक कामासाठी अनेकदा मजकूरापेक्षा अधिक आवश्यक असते; गणना करणे, डेटाबेस क्वेरी करणे, API कॉल करणे, वर्तमान विनिमय दर शोधणे. मॉडेल या गोष्टी स्वत: करू शकत नाही — परंतु त्या कधी करायच्या आहेत हे ती ठरवू शकते आणि एखाद्याला त्या करायला सांगू शकते. हेच साधन वापर मॉडेल देते आणि हे एआय एजंट्सचा आधार आहे. या युनिटमध्ये, आपण एजंट म्हणजे काय, टूलची व्याख्या कशी केली जाते आणि टूल_यूज लूप कसे कार्य करते हे शिकू.
एजंट म्हणजे काय? मॉडेल + टूल्स + लूप
एआय एजंटमध्ये तीन भाग असतात: मॉडेल (निर्णय घेणारा मेंदू), टूल्स (मॉडेल ज्या फंक्शन्सवर कॉल करू शकतो: हवामान, डेटाबेस क्वेरी, ईमेल पाठवा), आणि लूप (लूप; मॉडेल टूलला कॉल करतो, परिणाम मिळवतो, काय करायचे ते पुन्हा ठरवतो आणि असेच).
गंभीर फरक: एकल पॅटर्न कॉल एजंट नाही. एजंट ही अशी प्रक्रिया आहे ज्यामध्ये मॉडेल टप्प्याटप्प्याने पुढे जाते, प्रत्येक टप्प्यावर टूलच्या परिणामावर आधारित पुढील चाल निवडते. "माणसासारखा विचार करा, आपले हात वापरा, परिणाम पहा, पुन्हा विचार करा."
एक महत्त्वाची वस्तुस्थिती: मॉडेल स्वतःच वाहन चालवत नाही. मॉडेल फक्त "मला या इनपुटसह या साधनाला कॉल करायचा आहे" असे म्हणतात. तुमचा ॲप्लिकेशन (ज्याला हार्नेस म्हणतात) टूल चालवते आणि परिणाम मॉडेलला परत करते. सुरक्षिततेसाठी हे महत्त्वाचे आहे: मॉडेल थेट तुमच्या सिस्टमला स्पर्श करत नाही; प्रत्येक क्रिया तुमच्या नियंत्रणात आहे.
टीप: एजंटसह प्रत्येक समस्या सोडवण्याचा प्रयत्न करू नका. एजंट; विलंब, खर्च आणि त्रुटींचा धोका वाढतो. प्रथम विचारा: "हे एका कॉलने किंवा निश्चित कार्यप्रवाहाने सोडवले जाईल?" जर उत्तर होय असेल तर एजंटची गरज नाही. एजंट हे ओपन-एंडेड कामांसाठी आहे जेथे पायऱ्या आधीच ओळखता येत नाहीत.
साधन व्याख्या: नाव, वर्णन, इनपुट_स्कीमा
मॉडेलमध्ये साधन सादर करण्यासाठी, तुम्ही तीन गोष्टी द्या:
- नाव: वाहनाची ओळख, उदा. get_weather.
- वर्णन: साधन काय करते आणि ते कधी कॉल करायचे. हे सर्वात महत्वाचे क्षेत्र आहे जे मॉडेलला योग्य वेळी योग्य साधन निवडण्याची परवानगी देते. फक्त "काय करते" नाही तर "कॉल केव्हा" देखील लिहा.
- input_schema (इनपुट स्कीमा): JSON स्कीमा जे उपकरणाला कोणत्या पॅरामीटर्सची अपेक्षा आहे, कोणत्या प्रकारात हे परिभाषित करते.
# वाहन व्याख्या (वैचारिक — JSON स्कीमा){ "name": "get_order_status", "description": "ऑर्डरची वर्तमान शिपिंग स्थिती पुनर्प्राप्त करते. जेव्हा वापरकर्ता ऑर्डर क्रमांक कुठे आहे किंवा तो कधी येईल हे विचारतो तेव्हा कॉल करा.", "input_schema": { "type": "object", "properties": "description": "description": {{order}": "description": "ऑर्डर क्रमांक, उदा. SP-1024"} }, "आवश्यक": ["order_no"] }}
चांगल्या साधनाच्या वर्णनासाठी नियम: स्पष्ट आणि संक्षिप्त नाव, "केव्हा वापरायचे" सह वर्णन, प्रत्येक पॅरामीटरचे वर्णन, आवश्यक असलेले खरोखर अनिवार्य टाकणे. वाहनांच्या संख्येवर लक्ष केंद्रित करा; डझनभर समान वाहन मॉडेल आश्चर्यकारक आहेत.
क्षेत्र
ते काय करते?
चांगले उदाहरण
वाईट उदाहरण
नाव
वाहन आयडी
order_status_getir
आणणे
वर्णन
ते काय करते + कधी कॉल करायचा
"कार्गो स्थिती परत करते; जेव्हा वापरकर्ता ऑर्डर कुठे आहे असे विचारतो तेव्हा कॉल करा"
"डेटा आणते"
इनपुट_स्कीमा
पॅरामीटर प्रकार आणि आवश्यकता
{order_no: string, annotated}
आकृती/वर्णन नाही
टूल_वापर → टूल_रिझल्ट लूप
सायकल अशा प्रकारे कार्य करते, चरण-दर-चरण:
- तुम्ही मॉडेलला वापरकर्ता प्रश्न + टूलचे वर्णन पाठवता.
- मॉडेल एकतर थेट प्रतिसाद देते किंवा टूल_यूज ब्लॉक व्युत्पन्न करते: "ऑर्डर_no=SP-1024 सह ऑर्डर_डुरुमु_गेटिरला कॉल करा."
- तुमचा ॲप्लिकेशन प्रत्यक्षात टूल चालवतो (डेटाबेसची चौकशी करतो).
- तुम्ही निकाल पुन्हा मॉडेलला टूल_रिझल्ट म्हणून पाठवा.
- या परिणामासह, मॉडेल एकतर अंतिम उत्तर तयार करते किंवा दुसरे साधन कॉल करते. मॉडेल "मी पूर्ण झाले" असे म्हणत नाही तोपर्यंत सायकल चालू राहते.
# एजंट लूप (वैचारिक) संदेश = [उपयोगकर्ता_प्रश्न] खरे असताना: प्रतिसाद = model.uret(संदेश, साधने=टूल_परिभाषे) जर प्रतिसाद.tur == "टूल_उपयोग": परिणाम = harness.run(response.tool_name, response.entries) # APPLICATION रन करतो मेसेज, # अंतिम रिटर्न रिटर्न; प्रतिसाद पळवाट संपते
आधुनिक SDKs टूल रनर ऑफर करतात जे तुमच्यासाठी हे लूप चालवतात; तुम्ही फक्त टूल फंक्शन्स लिहा. पण पडद्यामागे नेमके तेच घडते.
त्रुटी व्यवस्थापन
साधने अयशस्वी होऊ शकतात: ऑर्डर सापडली नाही, API वेळा संपली, इनपुट अवैध आहे. तुम्ही टूल चालवू शकत नसल्यास, वर्णनात्मक टूल_रिझल्ट ("त्रुटी: ऑर्डर क्रमांक SP-9999 सापडला नाही") आणि एरर फ्लॅग म्हणून मॉडेलमध्ये त्रुटी परत करा. मॉडेल हे पाहू शकते आणि वापरकर्त्याला हळूवारपणे समजावून सांगू शकते किंवा वेगळ्या पद्धतीने प्रयत्न करू शकते. त्रुटी गिळू नका आणि रिक्त परिणाम परत करू नका; काय चूक झाली हे मॉडेलला माहित असणे आवश्यक आहे.
कमकुवत/सशक्त वाहनाचे वर्णन
कमकुवत (अनिश्चित संज्ञा, "केव्हा" नाही):
नाव: "डेटा", वर्णन: "डेटा आणतो"# मॉडेलला कधी आणि कसे कॉल करावे हे माहित नाही; तो एकतर अजिबात कॉल करत नाही किंवा चुकीच्या पद्धतीने कॉल करतो.
मजबूत (निव्वळ नाव + जेव्हा + पॅरामीटर वर्णन):
name: "musteri_bakiyesi_getir" वर्णन: "ग्राहकाच्या चालू खात्यातील शिल्लक परत करते. जेव्हा वापरकर्ता डेबिट, क्रेडिट किंवा शिल्लक विचारतो तेव्हा कॉल करा. पेमेंट करत नाही."input_schema: {custeri_id: string ("Customer ID")}# मॉडेल योग्य वेळी कॉल करते, त्याच्या योग्य मर्यादांसह, जाणून घ्या.
तीन मिनी केसेस
केस 1 - अनावश्यक एजंट. एका टीमने मल्टी-टूल एजंटसह "मजकूर सारांशित करा" व्यवसाय तयार केला; प्रत्येक रिकॅपमध्ये 4 मॉडेल कॉल्स आणि 9 सेकंद लागतात. नोकरी ही खरं तर एक-कॉल जॉब होती. जेव्हा आम्ही एजंट काढला आणि तो एका कॉलमध्ये कमी केला, तेव्हा वेळ 1.5 सेकंदांपर्यंत कमी झाला आणि खर्च एक चतुर्थांश झाला. धडा: जेव्हा खरोखर आवश्यक असेल तेव्हा एजंट वापरा.
केस 2 - कमकुवत स्पष्टीकरण, चुकीचा कॉल. समर्थन एजंटमध्ये, फेच नावाचे एक अस्पष्ट साधन यादृच्छिकपणे मॉडेलद्वारे शिल्लक प्रश्न आणि शिपिंग प्रश्न दोन्हीमध्ये कॉल केले गेले. जेव्हा वाहने बॅलन्स_गेटीर आणि कार्गो_दुरुमु_गेटीरमध्ये विभागली गेली आणि "कॉल केव्हा" स्पष्टीकरण जोडले गेले, तेव्हा चुकीच्या वाहनांची निवड 50 उदाहरणांमध्ये 18 वरून 1 पर्यंत कमी झाली.
केस 3 - त्रुटी गिळली. ऑर्डर न मिळाल्याने एजंट रिकामे निकाल देत होता; मॉडेलने याचा अर्थ "ऑर्डर वितरित झाली" असा केला आणि ग्राहकांची दिशाभूल केली. जेव्हा त्रुटी संदेश टूल_रिझल्ट ("ऑर्डर सापडला नाही") वर स्पष्टपणे लिहिला जातो, तेव्हा मॉडेल योग्यरित्या म्हणतो "मला हा नंबर सापडला नाही, तुम्ही तो तपासू शकता का?" तो म्हणू लागला.
सामान्य चुका
- सर्व काही एजंटकडे वळवणे: एक कॉल पुरेसा असताना, एजंट खर्च आणि विलंब जोडतो.
- अस्पष्ट वाहन वर्णन: मॉडेलला कधी कॉल करायचा हे माहित नाही; चुकीची निवड करते.
- मॉडेल वाहन चालवते असा विचार करणे: हार्नेस वाहन चालवते; मॉडेलला फक्त हवे आहे.
- त्रुटी गिळणे: काय चूक झाली हे मॉडेलला माहित असणे आवश्यक आहे; ओपन टूल_रिझल्ट म्हणून त्रुटी द्या.
- बरीच समान वाहने: मॉडेल गोंधळले; टूलसेट फोकस आणि कमीतकमी ठेवा.
लक्ष द्या: मॉडेलने "त्या वाहनाला कॉल करा" असे म्हटले आहे याचा अर्थ कारवाई केली पाहिजे असा नाही. विध्वंसक साधनांवर (हटवा, चेकआउट, ईमेल) तुमचा अनुप्रयोग आंधळेपणाने कॉल कार्यान्वित करू नये — पुढील युनिटमधील सुरक्षा विषयाचा हा मुख्य भाग आहे.
सारांशात
- एजंट = मॉडेल (निर्णय) + साधने (कार्ये) + लूप (कॉल टूल, निकाल मिळवा, पुन्हा निर्णय घ्या).
- सिंगल पॅटर्न कॉल एजंट नाही; एजंट ही एक चरण-दर-चरण प्रक्रिया आहे.
- मॉडेल वाहन चालवत नाही; तुमचा अनुप्रयोग चालतो (हार्नेस) आणि परिणाम टूल_रिझल्ट म्हणून परत करतो.
- साधन नाव, वर्णन (विशेषत: "कॉल केव्हा") आणि इनपुट_स्कीमा द्वारे ओळखले जाते.
- टूल_उपयोग → हार्नेस रन → टूल_रिझल्ट → मॉडेल "पूर्ण झाले" असे म्हणेपर्यंत लूप चालू राहते; मॉडेलला त्रुटी स्पष्टपणे कळवल्या जातात.
अर्ज कार्य
तुमच्या स्वतःच्या व्यवसायातील 3 साधने डिझाइन करा जी एजंटला दिली जाऊ शकतात. (1) प्रत्येकासाठी नाव, "कॉल केव्हा" सह वर्णन आणि इनपुट_स्कीमा लिहा; किमान एक नॉन-डिस्ट्रक्टिव वाचन साधन आणि एक गणना असू द्या. (२) एक वास्तववादी वापरकर्ता प्रश्न निवडा आणि मॅन्युअली स्टेप बाय स्टेप लिहा (लूपमध्ये) यापैकी कोणते टूल मॉडेल कोणत्या इनपुटसह कॉल करेल आणि टूल_रिझल्ट आल्यानंतर ते काय करेल. (3) एक परिस्थिती सेट करा ज्यामध्ये एक साधन अयशस्वी झाले आणि त्रुटी संदेश मॉडेलवर कसा परत येईल ते दर्शवा.
चेकलिस्ट
- [ ] मी एजंटला "मॉडेल + टूल्स + लूप" म्हणून परिभाषित करू शकतो आणि ते कधी आवश्यक आहे ते ठरवू शकतो.
- [ ] मला माहित आहे की हार्नेस वाहन चालवते, मॉडेलला ते हवे आहे.
- मी [ ] नाव, वर्णन ("कॉल केव्हा") आणि इनपुट_स्कीमासह ठोस वाहन वर्णन लिहू शकतो.
- मी [ ] tool_use → tool_result सायकल स्टेप बाय स्टेप फॉलो करू शकतो.
- [ ] मी टूल एररचा अहवाल ओपन टूल_रिझल्ट म्हणून मॉडेलला देतो.