जैसे-जैसे AI एजेंट परीक्षण प्रोटोटाइप से वास्तविक दुनिया के अनुप्रयोगों की ओर बढ़ते हैं, उनकी व्यवहार को समझने, उनके प्रदर्शन की निगरानी करने और उनके आउटपुट का व्यवस्थित रूप से मूल्यांकन करने की क्षमता महत्वपूर्ण हो जाती है।
इस पाठ को पूरा करने के बाद, आप जानेंगे/समझेंगे:
उद्देश्य आपको आपके “ब्लैक बॉक्स” एजेंटों को पारदर्शी, प्रबंधनीय और भरोसेमंद प्रणालियों में बदलने के ज्ञान से लैस करना है।
ध्यान दें: यह महत्वपूर्ण है कि AI एजेंट सुरक्षित और भरोसेमंद हों। Building Trustworthy AI Agents पाठ भी देखें।
अवलोकन उपकरण जैसे Langfuse या Microsoft Foundry आमतौर पर एजेंट रन को ट्रेसेस और स्पैन्स के रूप में प्रस्तुत करते हैं।
बिना अवलोकन के, एक AI एजेंट “ब्लैक बॉक्स” जैसा महसूस हो सकता है - इसकी आंतरिक स्थिति और तर्क अस्पष्ट होती है, जिससे मुद्दों का निदान करना या प्रदर्शन को बेहतर बनाना मुश्किल हो जाता है। अवलोकन के साथ, एजेंट “ग्लास बॉक्स” बन जाते हैं, जो पारदर्शिता प्रदान करते हैं जो विश्वास बनाने और सुनिश्चित करने के लिए आवश्यक है कि वे योजना के अनुसार काम करें।
AI एजेंटों को उत्पादन वातावरण में स्थानांतरित करने पर नई चुनौतियां और आवश्यकताएं सामने आती हैं। अवलोकन अब “अच्छा हो” से कहीं अधिक एक महत्वपूर्ण क्षमता है:
एजेंट के व्यवहार की निगरानी और समझ के लिए विभिन्न मीट्रिक्स और संकेतों को ट्रैक किया जाना चाहिए। जबकि एजेंट के उद्देश्य के आधार पर विशिष्ट मीट्रिक्स बदल सकते हैं, कुछ सार्वभौमिक रूप से महत्वपूर्ण होते हैं।
अवलोकन उपकरणों द्वारा ट्रैक किए जाने वाले कुछ सामान्य मीट्रिक्स यहां हैं:
लेटेंसी: एजेंट कितनी तेजी से प्रतिक्रिया करता है? लंबा इंतजार उपयोगकर्ता अनुभव को नकारात्मक रूप से प्रभावित करता है। आपको एजेंट रन के ट्रेसिंग द्वारा कार्यों और व्यक्तिगत चरणों के लिए लेटेंसी मापनी चाहिए। उदाहरण के लिए, यदि एक एजेंट सभी मॉडल कॉल के लिए 20 सेकंड लेता है, तो आप तेज मॉडल का उपयोग करके या मॉडल कॉल को समानांतर में चलाकर इसे तेज कर सकते हैं।
लागत: प्रति एजेंट रन लागत कितनी है? AI एजेंट टोकन या बाहरी API के आधार पर बिल की गई LLM कॉल पर निर्भर करते हैं। बार-बार टूल उपयोग या एकाधिक प्रॉम्प्ट लागत तेजी से बढ़ा सकते हैं। उदाहरण के लिए, यदि एक एजेंट गुणवत्ता में मामूली सुधार के लिए LLM को पांच बार कॉल करता है, तो आपको यह आंकना होगा कि क्या लागत सही ठहराई जाती है या आप कॉल की संख्या कम कर सकते हैं या सस्ता मॉडल उपयोग कर सकते हैं। रीयल-टाइम मॉनिटरिंग अप्रत्याशित बढ़ोतरी (जैसे API लूप्स को अत्यधिक उत्पन्न करने वाले बग) की पहचान करने में भी मदद कर सकती है।
रिक्वेस्ट त्रुटियां: एजेंट ने कितनी रिक्वेस्ट विफल की? इसमें API त्रुटियां या असफल टूल कॉल शामिल हो सकते हैं। उत्पादन में अपने एजेंट को अधिक मजबूत बनाने के लिए आप फॉलबैक या पुनः प्रयास सेट कर सकते हैं। उदाहरण के लिए, यदि LLM प्रदाता A डाउन है, तो आप बैकअप के रूप में LLM प्रदाता B पर स्विच कर सकते हैं।
उपयोगकर्ता प्रतिक्रिया: सीधे उपयोगकर्ता मूल्यांकन लागू करना मूल्यवान अंतर्दृष्टि प्रदान करता है। इसमें स्पष्ट रेटिंग (👍अच्छा/👎खराब, ⭐1-5 सितारे) या टेक्स्ट टिप्पणियां शामिल हो सकती हैं। लगातार नकारात्मक प्रतिक्रिया आपको सचेत करनी चाहिए क्योंकि यह बताता है कि एजेंट अपेक्षित रूप से काम नहीं कर रहा है।
निहित उपयोगकर्ता प्रतिक्रिया: उपयोगकर्ता व्यवहार बिना स्पष्ट रेटिंग के अप्रत्यक्ष प्रतिक्रिया प्रदान करते हैं। इसमें तत्काल प्रश्न पुनःफॉर्मिंग, बार-बार क्वेरी करना या पुनः प्रयास बटन पर क्लिक करना शामिल हो सकता है। उदाहरण के लिए यदि आप देखते हैं कि उपयोगकर्ता बार-बार एक ही प्रश्न पूछते हैं, तो यह एक संकेत है कि एजेंट अपेक्षित रूप से काम नहीं कर रहा है।
सटीकता: एजेंट कितनी बार सही या वांछित आउटपुट प्रदान करता है? सटीकता की परिभाषाएँ भिन्न हो सकती हैं (जैसे समस्या-समाधान की सहीता, सूचना पुनः प्राप्ति की सटीकता, उपयोगकर्ता संतोष)। पहला कदम यह परिभाषित करना है कि आपके एजेंट के लिए सफलता क्या दिखती है। आप स्वचालित जाँच, मूल्यांकन स्कोर, या कार्य पूर्णता लेबल के माध्यम से सटीकता ट्रैक कर सकते हैं। उदाहरण के लिए, ट्रेसेस को “सफल” या “असफल” के रूप में चिह्नित करना।
स्वचालित मूल्यांकन मीट्रिक्स: आप स्वचालित मूल्यांकन भी सेट कर सकते हैं। उदाहरण के लिए, आप एजेंट आउटपुट का मूल्यांकन करने के लिए LLM का उपयोग कर सकते हैं कि क्या वह सहायक, सटीक है या नहीं। कई ओपन सोर्स पुस्तकालय भी हैं जो एजेंट के विभिन्न पहलुओं को स्कोर करने में मदद करते हैं। जैसे RAGAS RAG एजेंटों के लिए या LLM Guard हानिकारक भाषा या प्रॉम्प्ट इंजेक्शन का पता लगाने के लिए।
व्यवहार में, इन मीट्रिक्स का संयोजन AI एजेंट के स्वास्थ्य का सर्वोत्तम कवरेज देता है। इस अध्याय के उदाहरण नोटबुक में हम आपको दिखाएंगे कि ये मीट्रिक्स वास्तविक उदाहरणों में कैसे दिखते हैं, लेकिन पहले हम सीखेंगे कि एक सामान्य मूल्यांकन वर्कफ़्लो कैसा दिखता है।
ट्रेसिंग डेटा इकट्ठा करने के लिए, आपको अपने कोड को उपकरण बनाना होगा। उद्देश्य एजेंट कोड को इस तरह उपकरण बनाना है कि वह ट्रेसेस और मीट्रिक्स उत्पन्न करे जिन्हें अवलोकन प्लेटफ़ॉर्म द्वारा कैप्चर, प्रोसेस और विज़ुअलाइज़ किया जा सके।
OpenTelemetry (OTel): OpenTelemetry LLM अवलोकन के लिए उद्योग मानक के रूप में उभरा है। यह टेलीमेट्री डेटा उत्पन्न करने, संग्रहित करने और निर्यात करने के लिए API, SDK और उपकरणों का सेट प्रदान करता है।
कई उपकरण पुस्तकालय हैं जो मौजूदा एजेंट फ्रेमवर्क को लपेटते हैं और OpenTelemetry स्पैन्स को अवलोकन उपकरण तक निर्यात करना आसान बनाते हैं। Microsoft एजेंट फ्रेमवर्क 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 मॉडल्स का उपयोग करके। यह रणनीति बार-बार पूछे जाने वाले प्रश्नों या सामान्य वर्कफ़्लोज़ के लिए लागत को काफी कम कर सकती है।
इस सेक्शन के उदाहरण नोटबुक में, हम देखेंगे कि हम कैसे ऑब्जर्वेबिलिटी टूल्स का उपयोग करके अपने एजेंट की निगरानी और मूल्यांकन कर सकते हैं।
Microsoft Foundry Discord में जुड़ें, अन्य सीखने वालों से मिलें, ऑफिस ऑवर्स में भाग लें और अपने AI एजेंट्स के सवालों के जवाब पाएं।
अस्वीकरण: इस दस्तावेज़ का अनुवाद AI अनुवाद सेवा Co-op Translator का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं।