ai-agents-for-beginners

उत्पादनातील AI प्रतिनिधी: निरीक्षण आणि मूल्यांकन

जसे AI प्रतिनिधी प्रयोगात्मक प्रोटोटाइप्समधून वास्तविक विश्वाच्या अनुप्रयोगांमध्ये जात आहेत, त्यांचा वर्तन समजून घेणे, त्यांच्या कामगिरीचे निरीक्षण करणे आणि त्यांच्या आउटपुटचे प्रणालीबद्ध मूल्यमापन करणे महत्त्वाचे होते.

शिकण्याचे उद्दिष्टे

या धड्याला पूर्ण केल्यानंतर तुम्हाला पुढील गोष्टी कळतील / समजतील:

• प्रतिनिधी निरीक्षण आणि मूल्यांकनाची मूलभूत संकल्पना
• प्रतिनिधींच्या कामगिरी, खर्च आणि परिणामकारकता सुधारण्यासाठी तंत्रे
• तुमच्या AI प्रतिनिधींचे संपूर्णपणे कसे आणि काय मूल्यांकन करायचे
• उत्पादनात AI प्रतिनिधी तैनात करताना खर्च कसा नियंत्रित करायचा
• Microsoft Agent Framework वापरून तयार केलेल्या प्रतिनिधींना कसे साधनबद्ध करायचे

उद्दिष्ट म्हणजे तुम्हाला तुमचे “ब्लॅक बॉक्स” प्रतिनिधी पारदर्शक, व्यवस्थापनीय आणि विश्वासार्ह प्रणालींमध्ये रूपांतरित करण्यासाठी ज्ञान देणे.

टीप: सुरक्षित आणि विश्वासार्ह AI प्रतिनिधी तैनात करणे महत्त्वाचे आहे. Building Trustworthy AI Agents धडा देखील पाहा.

ट्रेसेस आणि स्पॅन्स

निरीक्षण साधने जसे की Langfuse किंवा Microsoft Foundry सामान्यपणे प्रतिनिधीचे चालणे ट्रेसेस आणि स्पॅन्स म्हणून दर्शवितात.

• ट्रेस म्हणजे पूर्ण प्रतिनिधीचे कार्य सुरुवातीपासून शेवटपर्यंत (उदाहरणार्थ, वापरकर्त्याचा प्रश्न हाताळणे).
• स्पॅन्स म्हणजे त्या ट्रेसमधील स्वतंत्र टप्पे (उदाहरणार्थ, भाषा मॉडेल कॉल करणे किंवा डेटा मिळवणे).

निरीक्षणाशिवाय, AI प्रतिनिधी “ब्लॅक बॉक्स” सारखा वाटू शकतो - त्याची अंतर्गत स्थिती आणि विचारसरणी अस्पष्ट आहे, ज्यामुळे समस्या निदान करणे किंवा कामगिरी सुधारणे कठीण होते. निरीक्षणासह, प्रतिनिधी “काच बॉक्स” बनतात, जे पारदर्शकता देतात जी विश्वासार्हता निर्माण करण्यासाठी आणि ते अपेक्षितप्रमाणे काम करत असल्याचे सुनिश्चित करण्यासाठी महत्त्वाची आहे.

उत्पादन वातावरणात निरीक्षणाचे महत्त्व

AI प्रतिनिधींना उत्पादन वातावरणात स्थानांतरीत करताना नवीन आव्हाने आणि गरजा निर्माण होतात. निरीक्षण हे आता एक “आवडते” पर्याय नाही तर एक आवश्यक क्षमता आहे:

• डिबगिंग आणि मूळ कारण विश्लेषण: जेव्हा प्रतिनिधी अपयशी ठरतो किंवा अनपेक्षित आउटपुट निर्माण करतो, तेव्हा निरीक्षण साधने त्रुटीचा स्रोत शोधण्यासाठी आवश्यक ट्रेसेस पुरवितात. हे विशेषतः जटिल प्रतिनिधींसाठी महत्त्वाचे आहे ज्यात अनेक LLM कॉल्स, टूल्सशी संवाद आणि सशर्त लॉजिक असू शकते.
• देर आणि खर्च व्यवस्थापन: AI प्रतिनिधी अनेकदा LLMs आणि इतर बाह्य API वर आधारित असतात जे टोकन अथवा कॉलनुसार बिलिंग करतात. निरीक्षण अचूकपणे या कॉल्सचे ट्रॅकिंग करण्याची परवानगी देते, ज्यामुळे जास्त उशीर किंवा महागडे ऑपरेशन्स ओळखता येतात. यामुळे संघांना प्रॉम्प्ट्स ऑप्टिमाइझ करणे, अधिक परिणामकारक मॉडेल निवडणे किंवा कार्यप्रवाहांचे पुनर्निर्माण करणे सोपे होते ज्यामुळे ऑपरेशनल खर्च नियंत्रित होतो आणि चांगला वापरकर्ता अनुभव मिळतो.
• विश्वास, सुरक्षा आणि अनुरूपता: अनेक अनुप्रयोगांमध्ये प्रतिनिधी सुरक्षित आणि नैतिक वागणूक देतात याची खात्री करणे गरजेचे आहे. निरीक्षण प्रतिनिधीच्या क्रिया आणि निर्णयांचा ऑडिट ट्रेल पुरवते. हे प्रॉम्प्ट इंजेक्शन, हानिकारक सामग्री निर्मिती किंवा व्यक्तिचलित माहिती (PII) चुकून हाताळल्यासारख्या समस्या शोधण्यासाठी आणि कमी करण्यासाठी वापरले जाऊ शकते. उदाहरणार्थ, तुम्ही ट्रेसेस पुनरावलोकन करून समजू शकता की एखाद्या प्रतिनिधीने विशिष्ट प्रतिसाद का दिला किंवा विशिष्ट टूल का वापरले.
• सतत सुधारणा लूप्स: निरीक्षण डेटा पुनरावृत्ती विकास प्रक्रियेचा पाया आहे. वास्तविक जगात प्रतिनिधी कसे काम करतात ते निरीक्षण करून, संघ सुधारणा क्षेत्र ओळखू शकतात, मॉडेल फाइन-ट्यूनिंगसाठी डेटा गोळा करू शकतात आणि बदलांच्या परिणामांची पुष्टी करू शकतात. यामुळे अभिप्राय लूप तयार होतो जिथे ऑनलाइन मूल्यांकनातून मिळालेल्या उत्पादनातील अंतर्दृष्टी ऑफलाइन प्रयोग आणि सुधारणा मार्गदर्शन करते, ज्यामुळे नियमितपणे प्रतिनिधीची कामगिरी सुधारते.

ट्रॅक करण्यासाठी मुख्य मेट्रिक्स

प्रतिनिधीचे वर्तन निरीक्षण आणि समजून घेण्यासाठी, विविध मेट्रिक्स आणि संकेत ट्रॅक करणे आवश्यक आहे. प्रतिनिधीच्या उद्दिष्टानुसार विशिष्ट मेट्रिक्स वेगळ्या असू शकतात, परंतु काही सार्वत्रिक महत्त्वाचे आहेत.

येथे काही सामान्य मेट्रिक्स आहेत जे निरीक्षण साधने ट्रॅक करतात:

प्रतिक्रिया वेळ: प्रतिनिधी किती लवकर प्रतिसाद देतो? जास्त प्रतीक्षा वेळा वापरकर्ता अनुभवाला नकारात्मक प्रभाव टाकतात. तुम्हाला टास्क आणि स्वतंत्र टप्प्यांसाठी प्रतिक्रिया वेळ मोजावी लागेल - प्रतिनिधीच्या रनचे ट्रॅकिंग करून. उदाहरणार्थ, जर काही मॉडेल कॉल्ससाठी प्रतिनिधीला २० सेकंद लागतात तर तुम्ही जलद मॉडेल वापरून किंवा मॉडेल कॉल्स समानकालीन चालवून जलदगती मिळवू शकता.

खर्च: प्रत्येक प्रतिनिधी रनचा खर्च किती आहे? AI प्रतिनिधी LLM कॉल्सवर किंवा बाह्य API वर आधारित असतात ज्यांचे बिलिंग टोकन किंवा कॉलनुसार होते. वारंवार टूल वापर किंवा अनेक प्रॉम्प्टमुळे खर्च लवकर वाढतो. उदाहरणार्थ, जर प्रतिनिधीने चांगल्या दर्ज्यासाठी LLM पांच वेळा कॉल केला तर तुम्हाला पाहावे लागेल की खर्च योग्य आहे का किंवा कॉल्स कमी करता येतात का किंवा स्वस्त मॉडेल वापरता येतो का. रिअल-टाइम निरीक्षण अनपेक्षित वाढी (उदा. बग्स ज्यामुळे API loops वाढतात) ओळखण्यास मदत करू शकते.

विनंती दोष: प्रतिनिधी किती विनंत्या अपयशी ठरवतो? यामध्ये API दोष किंवा अपयशी टूल कॉल्स असू शकतात. उत्पादनात तुमच्या प्रतिनिधीला अधिक बळकट करण्यासाठी, तुम्ही फॉलबॅक किंवा पुनर्प्रयत्न सेट करू शकता. उदा. जर LLM पुरवठादार A उपलब्ध नसेल तर b पुरवठादार B वापरा.

वापरकर्ता अभिप्राय: थेट वापरकर्ता मूल्यमापन अमलात आणल्याने मौल्यवान अंतर्दृष्टी मिळते. यात स्पष्ट रेटिंग्स (👍पॉझिटीव्ह/👎नेगेटिव्ह, ⭐1-5 स्टार) किंवा मजकूरात्मक टिप्पण्या असू शकतात. सतत नकारात्मक अभिप्राय आपल्याला सूचित करतो की प्रतिनिधी अपेक्षेप्रमाणे काम करत नाही.

अप्रत्यक्ष वापरकर्ता अभिप्राय: वापरकर्त्याच्या वर्तनातून अप्रत्यक्ष अभिप्राय मिळतो जरी स्पष्ट रेटिंग नसेल. यात त्वरीत प्रश्न पुन्हा विचारणे, पुनरावृत्ती प्रश्न किंवा पुनर्प्रयत्न बटणावर क्लिक करणे समाविष्ट असू शकते. उदा. जर वापरकर्ते वारंवार एकाच प्रश्न विचारत असतील, तर ते सूचित करते की प्रतिनिधी अपेक्षेप्रमाणे कार्य करत नाही.

अचूकता: प्रतिनिधी किती वेळा बरोबर किंवा इच्छित आउटपुट तयार करतो? अचूकतेची व्याख्या वेगवेगळी असू शकते (उदा. समस्या सोडवण्याची खात्री, माहिती मिळवण्याचे अचूकता, वापरकर्ता समाधान). पहिला टप्पा म्हणजे तुमच्या प्रतिनिधीसाठी यश काय आहे ते ठरवणे. तुम्ही अचूकता स्वयंचलित तपासणी, मूल्यमापन गुण किंवा कार्य पूर्णता लेबल वापरून ट्रॅक करू शकता. उदाहरणार्थ, ट्रेसेसना “यशस्वी” किंवा “अपयशी” म्हणून चिन्हांकित करणे.

स्वयंचलित मूल्यांकन मेट्रिक्स: तुम्ही ऑटोमेटेड मूल्यमापन देखील सेट करू शकता. उदाहरणार्थ, तुम्ही LLM वापरून प्रतिनिधीच्या आउटपुटचा स्कोअर करू शकता उदा. उपयुक्त, अचूक आहे की नाही. काही मुक्त स्रोत लायब्ररीज देखील आहेत ज्या प्रतिनिधीच्या विविध बाबींचे स्कोअरिंग करण्यात मदत करतात. उदा. RAGAS RAG एजंटसाठी किंवा LLM Guard हानिकारक भाषा किंवा प्रॉम्प्ट इंजेक्शन शोधण्यासाठी.

व्यवहारात, या मेट्रिक्सचे संयोजन AI प्रतिनिधीच्या आरोग्याचे सर्वोत्तम कव्हरेज देते. या अध्यायाच्या उदाहरण नोटबुक मध्ये, आम्ही तुम्हाला दाखवू की या मेट्रिक्स प्रत्यक्ष उदाहरणांमध्ये कसे दिसतात, पण प्रथम, आपण एक सामान्य मूल्यांकन कार्यप्रवाह कसा असतो हे शिकू.

तुमच्या प्रतिनिधीचे साधनबद्ध करा

ट्रेसींग डेटा गोळा करण्यासाठी, तुम्हाला तुमचा कोड साधनबद्ध करावा लागेल. उद्दिष्ट म्हणजे प्रतिनिधीचा कोड उपकरणे आणि मेट्रिक्स पाठविण्यासाठी तयार करणे, जे निरीक्षण प्लॅटफॉर्मद्वारे पकडले, प्रक्रियेत आणले आणि दृश्यरूप दिले जाऊ शकते.

OpenTelemetry (OTel): OpenTelemetry LLM निरीक्षणासाठी एक उद्योग मानक म्हणून उदयास आले आहे. हे टेलीमेट्री डेटा तयार करणे, गोळा करणे आणि निर्यात करण्यासाठी API, SDK आणि उपकरणांचा संच पुरवते.

अनेक साधनबद्धी लायब्ररी आहेत जी विद्यमान प्रतिनिधी फ्रेमवर्क्सला कव्हर करतात आणि OpenTelemetry स्पॅन्स सहज निर्यात करणे शक्य करतात. Microsoft Agent Framework OpenTelemetry सह नैसर्गिकरित्या एकत्रित आहे. खाली MAF प्रतिनिधी साधनबद्धीचे उदाहरण आहे:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # एजंट कार्यवाही आपोआप ट्रेस केली जाते
    pass

या अध्यायातील उदाहरण नोटबुक मध्ये तुम्हाला तुमच्या MAF प्रतिनिधीचे साधनबद्धी कशी करायची ते दाखवले जाईल.

मॅन्युअल स्पॅन निर्मिती: साधनबद्धी लायब्ररी एक चांगली सुरुवात पुरवतात, पण अनेकदा अधिक सविस्तर किंवा सानुकूल माहितीची गरज असते. तुम्ही मॅन्युअली स्पॅन्स तयार करू शकता ज्यात सानुकूल अॅप्लिकेशन लॉजिक समाविष्ट करता येते. महत्त्वाचे म्हणजे, ते स्वयंचलित किंवा मॅन्युअल तयार केलेल्या स्पॅन्सना सानुकूल वैशिष्ट्यांनी (टॅग्ज किंवा मेटाडेटा म्हणून ओळखले जातात) समृद्ध करू शकतात. या वैशिष्ट्यांमध्ये व्यवसाय-विशिष्ट डेटा, मध्यम परिणाम किंवा कोणताही संदर्भ असू शकतो जो डिबगिंग किंवा विश्लेषणासाठी उपयुक्त असू शकतो, जसे की user_id, session_id, किंवा model_version.

Langfuse Python SDK वापरून ट्रेसेस आणि स्पॅन्स मॅन्युअली तयार करण्याचे उदाहरण:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

प्रतिनिधी मूल्यांकन

निरीक्षण मेट्रिक्स देते, पण मूल्यांकन ही प्रक्रिया आहे जी त्या डेटाचा विश्लेषण करते (आणि चाचण्या करते) की AI प्रतिनिधी किती चांगले काम करत आहे आणि त्यात कसे सुधारणा करता येतील. दुसऱ्या शब्दांत, जेव्हा तुमच्याकडे ते ट्रेसेस आणि मेट्रिक्स असतात, तेव्हा तुम्ही त्यांचा वापर करून प्रतिनिधीचे मूल्यांकन कसे कराल आणि निर्णय कसे घ्याल?

नियमित मूल्यांकन महत्त्वाचे आहे कारण AI प्रतिनिधी अनेकदा अनिश्चित असतात आणि विकसित होऊ शकतात (अपडेट्स किंवा मॉडेल वर्तनातील बदलांमुळे) – मूल्यांकनाशिवाय, तुम्हाला कळणार नाही की तुमचा “स्मार्ट प्रतिनिधी” खरोखरच चांगले काम करत आहे की नाही किंवा त्याने मागे पडले आहे.

AI प्रतिनिधींसाठी दोन प्रकारचे मूल्यांकन आहेत: ऑनलाइन मूल्यांकन आणि ऑफलाइन मूल्यांकन. दोन्ही महत्त्वाचे आहेत आणि एकमेकांना पूरक आहेत. आपण सामान्यतः ऑफलाइन मूल्यांकनाने सुरुवात करतो, कारण हे कोणताही प्रतिनिधी तैनात करण्यापूर्वी आवश्यक टप्पा आहे.

ऑफलाइन मूल्यांकन

यात प्रतिनिधीला नियंत्रित सेटिंगमध्ये, सहसा टेस्ट डेटासेट्स वापरून मूल्यांकन केले जाते, जिवंत वापरकर्ता क्वेरीज न वापरता. तुम्ही अश्याप्रकारे तयार केलेले डेटासेट्स वापरता ज्यामध्ये अपेक्षित आउटपुट किंवा बरोबर वर्तन माहित असते, आणि नंतर त्या डेटासेटवर तुमचा प्रतिनिधी चालवता.

उदाहरणार्थ, जर तुम्ही एक गणिती शब्दसमस्या प्रतिनिधी तयार केली असेल, तर तुम्ही 100 प्रश्नांचा टेस्ट डेटासेट असेल ज्यात उत्तर माहित आहे. ऑफलाइन मूल्यांकन विकास काळात (आणि CI/CD पाइपलाइनचा भाग असू शकते) सुधारणा तपासण्यासाठी किंवा रिग्रेशन विरुद्ध संरक्षणासाठी केले जाते. याचा फायदा असा की हे परताव्याजोगे आहे आणि तुम्हाला अचूकता मोजता येते कारण तुम्हाला खरे उत्तर माहित आहे. तुम्ही वापरकर्ता क्वेरीजचे अनुकरण करू शकता आणि प्रतिनिधीच्या प्रतिसादांचे मूल्यांकन करू शकता, किंवा स्वयंचलित मेट्रिक्स वापरू शकता ज्याचा उल्लेख वर केला आहे.

ऑफलाइन मूल्यांकनात मोठा आव्हान म्हणजे तुमचा टेस्ट डेटासेट सर्वसमावेशक आणि वापरासाठी उपयुक्त ठेवणे – प्रतिनिधी निश्चित टेस्ट सेटवर चांगली कामगिरी करू शकतो, पण उत्पादनात खूप वेगळ्या क्वेरीजना सामोरे जाऊ शकतो. म्हणून, तुम्ही टेस्ट सेट्स नवीन एज केस आणि वास्तविक विश्वातील उदाहरणांची भर घालून अद्ययावत ठेवले पाहिजेत. लहान “स्मोक टेस्ट” प्रकरणे आणि मोठे मूल्यांकन संचांचा संगम उपयुक्त आहे: वेगवान तपासणीसाठी लहान संच आणि व्यापक कामगिरी मेट्रिक्ससाठी मोठे संच.

ऑनलाइन मूल्यांकन

याचा अर्थ म्हणजे प्रतिनिधीला थेट वास्तविक जगाच्या परिस्थितीत, म्हणजेच उत्पादनातील प्रत्यक्ष वापरादरम्यान मूल्यांकन करणे. ऑनलाइन मूल्यांकन म्हणजे वास्तविक वापरकर्त्यांबरोबरच्या संवादांवर प्रतिनिधीच्या कामगिरीचे सतत निरीक्षण आणि निकालांचे विश्लेषण करणे.

उदाहरणार्थ, तुम्ही यशाचे दर, वापरकर्ता समाधान गुण किंवा इतर मेट्रिक्स जिवंत ट्रॅफिकवर ट्रॅक करू शकता. ऑनलाइन मूल्यांकनाचे फायदे म्हणजे ते तुम्हाला प्रयोगशाळेत अपेक्षित नसलेले घटक टिपते – मॉडेल ड्रिफ्ट कालांतराने आपण पाहू शकता (जर प्रतिनिधीची परिणामकारकता इनपुट पॅटर्न बदलल्यावर कमी झाली) आणि अनपेक्षित क्वेरीज किंवा परिस्थिती पकडू शकता जिने तुमच्या टेस्ट डेटामध्ये नव्हती. हे प्रत्यक्षात प्रतिनिधी कसा वागत आहे याचा खरा चित्र प्रदान करते.

ऑनलाइन मूल्यांकनमध्ये अनेकदा अप्रत्यक्ष आणि स्पष्ट वापरकर्ता अभिप्राय गोळा करणे, तसेच शॅडो टेस्ट किंवा A/B टेस्ट चालवणे (जिथे नवीन आवृत्ती जुन्या आवृत्तीच्या तुलनेत समांतर चालते) यांचा समावेश असतो. आव्हान म्हणजे जिवंत संवादासाठी विश्वसनीय लेबल्स किंवा स्कोअर्स मिळवणे कधी कधी कठीण असते – तुम्ही वापरकर्ता अभिप्राय किंवा डाउनस्ट्रीम मेट्रिक्सवर अवलंबून असू शकता (उदा. वापरकर्ते निकालावर क्लिक केले का).

दोन्हींचे संयोजन

ऑनलाइन आणि ऑफलाइन मूल्यांकन परस्परविरुद्ध नाहीत; ते खूप पूरक आहेत. ऑनलाइन निरीक्षणातून मिळालेल्या अंतर्दृष्टी (उदा. नवीन प्रकारच्या क्वेरीज जिथे प्रतिनिधी खराब काम करतो) ऑफलाइन टेस्ट डेटासेटअस सुधारणा करण्यासाठी वापरता येऊ शकते. उलट, जे प्रतिनिधी ऑफलाइन चाचण्यांमध्ये चांगले कार्य करतात, त्यांची तैनाती अधिक आत्मविश्वासाने करून नंतर ऑनलाइन मॉनिटर केली जाऊ शकते.

प्रत्यक्षात, अनेक संघ खालील प्रतीकात्मक लूप स्वीकारतात:

ऑफलाइन मूल्यांकन -> तैनात करणे -> ऑनलाइन मॉनिटरिंग -> नवीन अपयश प्रकरणे गोळा करणे -> ऑफलाइन डेटासेटमध्ये जोडणे -> प्रतिनिधी सुधारणा करणे -> पुनरावृत्ती.

सामान्य समस्या

जेव्हा तुम्ही AI प्रतिनिधी उत्पादनात तैनात करता, तेव्हा तुम्हाला विविध आव्हाने येऊ शकतात. येथे काही सामान्य समस्या आणि त्यांचे संभाव्य उपाय आहेत:

समस्या	संभाव्य उपाय
AI प्रतिनिधी कार्य सातत्याने करत नाही	- AI प्रतिनिधीला दिलेला प्रॉम्प्ट सुधारित करा; उद्दिष्टांबाबत स्पष्ट रहा. - कोणत्या ठिकाणी कामे उपकार्यांमध्ये विभागून अनेक प्रतिनिधींना देऊ शकता हे शोधा.
AI प्रतिनिधी सतत लूपमध्ये अडकतो	- स्पष्ट समाप्ती नियम आणि अटी ठरवा जेणेकरून प्रतिनिधी प्रक्रिया थांबवायला शिकलो. - कारणीभूत व नियोजनात्मक कामांसाठी विशेष मॉडेल वापरा जे यासाठी खास तयार केलेले आहे.
AI प्रतिनिधी टूल कॉलस नीट कार्य करत नाही	- टूलचा आउटपुट एजंट सिस्टमच्या बाहेर तपासून आणि सत्यापित करा. - परिभाषित पॅरामीटर्स, प्रॉम्प्ट आणि टूलचे नाव अधिक चांगले करा.
मल्टी-एजंट प्रणाली सातत्याने कार्य करत नाही	- प्रत्येक एजंटसाठी दिलेल्या प्रॉम्प्टमध्ये विशिष्टता आणि भेद ठेवा. - “राउटिंग” किंवा कंट्रोलर एजंट वापरून कोणता एजंट योग्य आहे हे ठरवणारी पद्दत तयार करा.

या अनेक समस्या निरीक्षण उपलब्ध असल्यास अधिक प्रभावीपणे ओळखता येतात. आधी सांगितलेल्या ट्रेसेस आणि मेट्रिक्स प्रतिनिधीच्या वर्कफ्लोत कोणत्या ठिकाणी समस्या आहेत हे नेमके सांगतात, ज्यामुळे डिबगिंग आणि ऑप्टिमायझेशन अधिक कार्यक्षम होते.

खर्च व्यवस्थापन

AI एजंट्सना उत्पादनात तैनात करण्याच्या खर्चाचे व्यवस्थापन करण्यासाठी काही धोरणे येथे आहेत:

लहान मॉडेल्सचा वापर: लहान भाषा मॉडेल्स (SLMs) काही एजंटिक वापरप्रकरणांवर चांगले काम करू शकतात आणि खर्चात लक्षणीय कपात करतील. पूर्वी नमूद केल्याप्रमाणे, मोठ्या मॉडेल्सच्या तुलनेत कामगिरी ठरवण्यासाठी आणि तुलना करण्यासाठी एक मूल्यमापन प्रणाली तयार करणे हे तुमच्या वापरासाठी SLM किती चांगले काम करेल हे समजून घेण्याचा सर्वोत्तम मार्ग आहे. सोप्या कामांसाठी जसे की हेतू वर्गीकरण किंवा पॅरामीटर एक्सट्रॅक्शनसाठी SLM वापरण्याचा विचार करा, तर गुंतागुंतीच्या विचारांसाठी मोठ्या मॉडेल्स राखून ठेवा.

राउटर मॉडेलचा वापर: यासमान धोरण म्हणजे विविध मॉडेल्स आणि आकारांचा वापर करणे. तुम्ही LLM/SLM किंवा सर्वरलेस फंक्शन वापरू शकता ज्याद्वारे जटिलतेनुसार विनंत्या योग्य मॉडेल्सकडे वाटचाल करता येतील. यामुळे खर्च कमी करणे सोपे होईल आणि योग्य कामांसाठी कामगिरी सुनिश्चित होईल. उदाहरणार्थ, सोप्या चौकशा लहान, जलद मॉडेल्सकडे मार्गदर्शन करा आणि केवळ जटिल विचारांसाठी महागडे मोठे मॉडेल्स वापरा.

प्रतिसाद कॅशिंग: सामान्य विनंत्या आणि कामे ओळखून, त्यांचे प्रतिसाद एजंटिक सिस्टमद्वारे जाण्याआधी देणे हे समान विनंत्यांच्या प्रमाणात कपात करणे एक चांगला मार्ग आहे. तुम्ही अगदी एका फ्लोची अंमलबजावणी करू शकता ज्याद्वारे कॅश केलेल्या विनंत्यांशी विनंती किती सारखी आहे हे अधिक मूलभूत AI मॉडेल्सच्या साहाय्याने ओळखू शकता. ही धोरणे वारंवार विचारल्या जाणाऱ्या प्रश्नांसाठी किंवा सामान्य कार्यप्रवाहांसाठी खर्चात लक्षणीय कपात करू शकतात.

चला पाहूया हे व्यवहारात कसे कार्य करते

या विभागाच्या उदाहरण नोटबुकमध्ये, आपण पाहू की आपण कसे निरीक्षण साधने वापरून आपला एजंट मॉनिटर आणि मूल्यमापन करू शकतो.

उत्पादनातील AI एजंट्सबाबत अधिक प्रश्न आहेत का?

Microsoft Foundry Discord मध्ये सामील व्हा, इतर शिकणाऱ्यांशी भेटा, ऑफिस तासांना उपस्थित रहा आणि तुमचे AI एजंट्सचे प्रश्न सोडवा.

मागील धडा

Metacognition Design Pattern

पुढील धडा

Agentic Protocols

---

अस्वीकरण: हा दस्तऐवज AI भाषांतर सेवा Co-op Translator चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.

This site is open source. Improve this page.