AI एजेंट का मूल्यांकन कैसे करें: टेस्ट सेट, ग्रेडर और रिग्रेशन जाँच

AI एजेंट के मूल्यांकन के लिए छह चरणों वाली एक व्यावहारिक गाइड, जिसमें सफलता को परिभाषित करने और असली विफलताओं से टेस्ट सेट बनाने से लेकर ग्रेडर चुनने, रिग्रेशन जाँचें चलाने और प्रोडक्शन में निगरानी करने तक सब कुछ शामिल है।

An AI agent evaluation detects an unapproved spare-part recommendation and verifies the corrected result after a fix.

हर बेहतरीन AI प्रोडक्ट के पीछे एक मज़बूत AI एजेंट मूल्यांकन प्रक्रिया होती है, जिसे इवैल्स कहा जाता है। यह गलतियों को शुरुआत में ही पकड़ लेती है और सुनिश्चित करती है कि एजेंट ठीक से काम करे। इवैल्स उन AI एजेंट्स के लिए बेहद ज़रूरी हैं जो किसी की ओर से रिफ़ंड जैसे उच्च जोखिम वाले काम करते हैं।

इस प्रक्रिया को बनाने के लिए कुछ तकनीकी जानकारी और डेटा विश्लेषण कौशल की ज़रूरत होती है। लेकिन यह उतना डरावना या कठिन बिल्कुल नहीं है जितना सुनने में लग सकता है। शुरुआत करने में आपकी मदद के लिए, हमने AI एजेंट्स के मूल्यांकन के छह व्यावहारिक चरण और उन आम गलतफ़हमियों के बारे में बताया है जो इस प्रक्रिया को बिगाड़ देती हैं।

AI एजेंट का मूल्यांकन करने का क्या मतलब है?

AI एजेंट का मूल्यांकन करने का मतलब है यह आकलन करना कि वह कार्यों को कितनी सही तरह से पूरा करता है और क्या उसके निर्णय संगठन की ज़रूरतों को पूरा करते हैं। व्यावहारिक रूप से, AI एजेंट मूल्यांकन, या इवैल्स, ऐसे विशिष्ट मेट्रिक्स हैं जो संगठनों को यह तय करने में मदद करते हैं कि एजेंट अपनी इच्छित भूमिका के लिए पर्याप्त भरोसेमंद ढंग से काम करता है या नहीं।

किसी मैन्युफ़ैक्चरिंग प्लांट में एक AI खरीद एजेंट के बारे में सोचिए, जो स्पेयर पार्ट्स की इन्वेंटरी जाँचता है और स्टॉक दोबारा भरने के अनुरोध तैयार करता है। अगर कोई स्वीकृत पार्ट उपलब्ध नहीं है या सप्लायर की जानकारी पुरानी है, तो क्या एजेंट समस्या को फ़्लैग करेगा या किसी अस्वीकृत विकल्प की सिफ़ारिश करेगा?

और अगर आप उस समस्या को ठीक करने के लिए उसका सिस्टम प्रॉम्प्ट बदलते हैं, तो आपको कैसे पता चलेगा कि आपने कोई नई समस्या तो पैदा नहीं कर दी?

मूल्यांकन के बिना, प्रोडक्ट मैनेजर असल में बस अनुमान लगाते रह जाते हैं। इसलिए, इवैल्स एक फ़ीडबैक संकेत देते हैं, जिससे प्रदर्शन मापा जा सकता है, बार-बार आने वाली समस्याओं को पहचाना जा सकता है और बदलावों को ज़्यादा भरोसे के साथ परखा जा सकता है।

इसके साथ ही, एजेंट मूल्यांकन किसी रन के कई पहलुओं की जाँच कर सकता है:

  • अंतिम परिणाम की गुणवत्ता
  • एजेंट द्वारा इस्तेमाल की गई जानकारी
  • उसके द्वारा कॉल किए गए टूल
  • क्या उसने अपने व्यवहार को नियंत्रित करने वाले नियमों का पालन किया

AI एजेंट मूल्यांकन के आम मेट्रिक्स

इवैल्स गुणात्मक और मात्रात्मक, दोनों तरह के डेटा पर काम करते हैं। गुणात्मक मूल्यांकन से आपको यह समझने में मदद मिलती है कि क्या हो रहा है और क्यों, जिसमें एजेंट के निर्णयों की मैन्युअल समीक्षा भी शामिल है। मात्रात्मक मूल्यांकन इन अवलोकनों को मापने योग्य संकेतों में बदलता है, जैसे विशिष्ट विफलता मोड की आवृत्ति गिनना या कार्य सफलता दर की गणना करना।

यहाँ AI एजेंट मूल्यांकन के बुनियादी मेट्रिक्स की सूची दी गई है:

  • कार्य सफलता यह मापती है कि एजेंट ने इच्छित परिणाम हासिल किया या नहीं; इसे आमतौर पर उन रन के प्रतिशत के रूप में मापा जाता है जो मान्य परिणाम देते हैं।
  • कार्रवाई की शुद्धता यह मापती है कि क्या एजेंट ने टूल का सही ढंग से इस्तेमाल किया, मान्य आर्ग्युमेंट चुने और अनुमतियों का पालन किया।
  • उत्तर की गुणवत्ता यह आकलन करती है कि अंतिम आउटपुट सटीक, पूर्ण और उपयोगी है या नहीं। इसमें तथ्यात्मक शुद्धता, निर्देशों का पालन, और यह भी शामिल हो सकता है कि एजेंट उपलब्ध जानकारी के आधार पर अपने निर्णयों को सही ठहराता है या नहीं।
  • विश्वसनीयता बार-बार किए गए परीक्षणों, अलग-अलग इनपुट और एज केस में एकरूपता को मापती है।
  • लागत और लेटेंसी किसी सफल परिणाम को हासिल करने के लिए ज़रूरी संसाधनों को मापते हैं, जिनमें निष्पादन समय, टोकन की खपत और टूल कॉल शामिल हैं।

आप क्या माप रहे हैं, इसके आधार पर इवैल्स किसी एजेंट के एंड-टू-एंड प्रदर्शन, उसकी निष्पादन ट्रैजेक्टरी, या टूल कॉल और रिट्रीवल चरणों जैसे अलग-अलग घटकों का आकलन कर सकते हैं।

चरण 1: तय करें कि एजेंट का सफल रन कैसा दिखता है

सबसे पहले, स्पष्ट रूप से बताएँ कि एजेंट को क्या हासिल करना है — यानी प्रोडक्ट की ज़रूरतें। सुनने में यह आसान लगता है, फिर भी यह हैरानी की हद तक मुश्किल हो सकता है। इसका एक नाम भी है: स्पेसिफ़िकेशन गैप।

हमारे सीनियर डेटा साइंटिस्ट Andrey Khomutov के अनुसार, इसे इस तरह अपनाएँ:

“दो सवालों से शुरुआत करें: “किसे काम पूरा होना माना जाएगा?” और “कौन-सी बात देखने में सफल लगने वाले रन को अस्वीकार्य बना देगी?”

तकनीकी दृष्टि से, एजेंट्स के लिए इसका मतलब है परिणाम और एजेंट वहाँ तक कैसे पहुँचे, दोनों की जाँच करना।”

कोई एजेंट लीक हुई उत्तर कुंजी तक पहुँचकर सही उत्तर दे सकता है या अपना कार्य पूरा करते समय अनधिकृत कार्रवाइयाँ कर सकता है। Khomutov बताते हैं कि उत्तर का लीक होना और मूल्यांकन के दौरान असुरक्षित कार्रवाइयाँ ऐसे ठोस कारण हैं जिनकी वजह से केवल अंतिम उत्तर के आधार पर आकलन नहीं करना चाहिए।

वे आगे कहते हैं, “मुझे उम्मीद है कि ट्रैजेक्टरी निरीक्षण एजेंट इवैल सुइट्स का एक मानक हिस्सा बन जाएगा, न कि ऐसा कुछ जो हम सिर्फ़ तब करें जब कोई परिणाम संदिग्ध लगे।”

इसके बाद, अपने सफलता मानदंडों की पुष्टि करने के लिए किसी डोमेन विशेषज्ञ को शामिल करें। जिन लोगों को उस डोमेन का व्यावहारिक ज्ञान होता है, वे बता सकते हैं कि हमने AI एजेंट के लिए जो शर्तें तय की हैं, वे किसी सफल परिणाम को दर्शाती हैं या नहीं।

चरण 2. वास्तविक कार्यों और विफलताओं से एक टेस्ट सेट बनाएँ

अच्छा और खराब प्रदर्शन कैसा दिखता है, यह समझने के लिए एजेंट के वास्तविक व्यवहार की जाँच करें। सिर्फ़ अपने अनुमान के आधार पर कि क्या गलत हो सकता है, दर्जनों टेस्ट बनाकर शुरुआत करने के लालच से बचें।

Parlance Lab के ML इंजीनियर Hamel Husain और ML सिस्टम्स व अप्लाइड AI इवैल्स की शोधकर्ता Shreya Shankar सुझाव देते हैं कि शुरुआत त्रुटि विश्लेषण से की जाए, जो मशीन लर्निंग और डेटा साइंस से ली गई एक तकनीक है। यह प्रक्रिया एजेंट के निष्पादन ट्रेस के गुणात्मक विश्लेषण से शुरू होती है — ये ऐसे रिकॉर्ड होते हैं जो उपयोगकर्ता का इनपुट, टूल कॉल, प्राप्त की गई जानकारी और एजेंट का आउटपुट दिखाते हैं।

  1. अलग-अलग ट्रेस की समीक्षा करें और त्रुटियों को एनोटेट करें (ओपन कोडिंग)। किसी डोमेन विशेषज्ञ से एजेंट रन की जाँच करवाएँ और छोटे नोट्स में लिखवाएँ कि क्या गलत हुआ। पहली महत्वपूर्ण त्रुटि पर ध्यान दें।
  2. अवलोकनों को विफलता मोड में समूहित करें (एक्सियल कोडिंग)। पर्याप्त नोट्स हो जाने पर, मिलती-जुलती त्रुटियों के लिए श्रेणियाँ सुझाने के लिए किसी LLM का इस्तेमाल करें। इनमें असंगत पार्ट्स की सिफ़ारिशें, इन्वेंटरी की गलत जानकारी निकालना और इंसान को काम सौंपने (हैंडऑफ़) में विफलता शामिल हो सकती है।
  3. घटनाओं की गिनती करें। हर अवलोकन को एक श्रेणी में रखें, फिर स्प्रेडशीट या पिवट टेबल का इस्तेमाल करके गणना करें कि हर विफलता मोड कितनी बार सामने आता है।
  4. तय करें कि पहले किन समस्याओं को हल करना है, और इसके लिए आवृत्ति व गंभीरता, दोनों को ध्यान में रखें।
  5. महत्वपूर्ण विफलताओं को टेस्ट केस में बदलें। संबंधित इनपुट, शुरुआती स्थितियाँ, अपेक्षित परिणाम और ग्रेडिंग मानदंड सहेजें, ताकि एजेंट को उसी परिदृश्य पर फिर से परखा जा सके।

आपको कितने ट्रेस की जाँच करनी चाहिए? लगभग 100, लेकिन कोई तय जादुई संख्या नहीं है। सैद्धांतिक संतृप्ति तक पहुँचते ही रुक जाएँ: यानी वह बिंदु जहाँ अतिरिक्त ट्रेस की समीक्षा करने से विफलता के कोई नए महत्वपूर्ण पैटर्न सामने नहीं आते।

अभी तक ऐप्लिकेशन लॉन्च नहीं किया है? सिंथेटिक उदाहरण शुरुआती टेस्ट सेट बनाने में मदद कर सकते हैं, लेकिन जैसे ही वास्तविक उपयोगकर्ता डेटा उपलब्ध हो, उसे इस सेट का आधार बनाना चाहिए।

AI एजेंट मूल्यांकन में बेंचमार्क का उपयोग

अपने खुद के टेस्ट केस बनाने के अलावा, आप एजेंट की क्षमताओं का आकलन करने के लिए मानकीकृत मूल्यांकन कार्यों के मौजूदा संग्रहों का भी उपयोग कर सकते हैं, जिन्हें बेंचमार्क कहा जाता है।

लेकिन बेंचमार्क त्रुटिहीन नहीं होते। SWE-bench ऑडिट, Epoch AI की बेंचमार्क समीक्षाएँ और TheoPhysEval में शुरू में अस्वीकार किए गए सही उत्तर दिखाते हैं कि त्रुटिपूर्ण कार्य या अपेक्षित उत्तर मूल्यांकन के परिणामों को कैसे बिगाड़ सकते हैं।

Khomutov की सलाह है कि अपने डोमेन से जुड़े अप-टू-डेट बेंचमार्क चुनें और स्कोर को एजेंट के प्रदर्शन का भरोसेमंद सबूत मानने से पहले अप्रत्याशित सफलताओं या विफलताओं की जाँच करें।

चरण 3. एजेंट को दोहराने योग्य टेस्ट एनवायरनमेंट में चलाएँ

दोहराने योग्य टेस्ट एनवायरनमेंट एक नियंत्रित सेटअप होता है, जहाँ आप किसी AI एजेंट को समान शुरुआती स्थितियों में समान टेस्ट केस पर चला सकते हैं और परिणामों की तुलना कर सकते हैं। इसमें टेस्ट केस का एक फ़ोल्डर, एजेंट को चलाने वाली Python स्क्रिप्ट, या परिणामों का मूल्यांकन करने वाली जाँचों का एक सेट शामिल होता है।

आप प्रतिनिधि इनपुट को JSON फ़ाइलों के रूप में सहेजकर, और अपने एजेंट का वर्कफ़्लो चलाने तथा असर्शन के ज़रिए उसके आउटपुट की जाँच करने के लिए Python स्क्रिप्ट का इस्तेमाल करके शुरुआत कर सकते हैं। हमारे मैन्युफ़ैक्चरिंग प्लांट के इन्वेंटरी एजेंट के लिए, दोहराने योग्य टेस्ट एनवायरनमेंट कुछ ऐसा दिख सकता है:

दोहराने योग्य टेस्ट एनवायरनमेंट सेट अप करने के लिए, ये चरण अपनाएँ:

  1. प्रतिनिधि इनपुट सहेजें। वास्तविक इवेंट या टेस्ट केस को उसी संरचना में स्टोर करें जिसमें आपका ऐप्लिकेशन उन्हें प्रोडक्शन में प्राप्त करता है। हमारे परिदृश्य में, आप मशीन ID, ज़रूरी स्पेयर पार्ट और मेंटेनेंस की तारीख वाले मेंटेनेंस अनुरोध को JSON फ़ाइल के रूप में सहेजेंगे, साथ ही इन्वेंटरी और स्वीकृत पार्ट्स के डेटा का स्नैपशॉट भी।
  2. वर्कफ़्लो चलाएँ। हर इनपुट को एजेंट से गुज़ारें, जिसमें उसके रिट्रीवल चरण, टूल कॉल और रिस्पॉन्स जनरेशन शामिल हैं।
  3. परिणाम और ट्रेस रिकॉर्ड करें। अंतिम आउटपुट और बीच की संबंधित कार्रवाइयों (जैसे इन्वेंटरी लुकअप) को कैप्चर करें, ताकि आप न सिर्फ़ यह देख सकें कि एजेंट विफल हुआ या नहीं, बल्कि यह भी कि कहाँ विफल हुआ।
  4. विफलता की गंभीरता, आवृत्ति और समस्या को ठीक करने की कठिनाई के आधार पर केस दोहराएँ। LLM ऐप्लिकेशन नॉनडिटरमिनिस्टिक होते हैं (वे एक जैसे इनपुट से अलग-अलग परिणाम दे सकते हैं), इसलिए एक सफल रन इस बात की गारंटी नहीं देता कि अगला रन भी सफल होगा। सफल परीक्षणों का अनुपात रिपोर्ट करें और विफलताओं की जाँच करें।

इसके लिए Khomutov pass@1 (एजेंट एक ही प्रयास में कितनी बार सफल होता है) और pass@k (तय संख्या के प्रयासों में कम से कम एक बार सफल होने की संभावना) मापने की सलाह देते हैं। अगर आप pass@k रिपोर्ट कर रहे हैं, तो प्रयासों की संख्या बताएँ, क्योंकि कई उत्तरों में से एक सही उत्तर देने का मतलब यह नहीं है कि एजेंट जानता है कि किसे चुनना है।

जैसे-जैसे आपका ऐप्लिकेशन बढ़ता है, टेस्ट को व्यवस्थित करने और चलाने के लिए pytest जैसे टेस्टिंग फ़्रेमवर्क का इस्तेमाल करें, और बड़े टेस्ट डेटासेट व परिणामों को डेटाबेस में स्टोर करने पर विचार करें।

चरण 4. हर जाँच के लिए सही ग्रेडर चुनें

ग्रेडर (जिसे अक्सर इवैल्यूएटर भी कहा जाता है) एक ऐसा तंत्र है — कोड का कोई हिस्सा, ग्रेडिंग रूब्रिक से निर्देशित कोई LLM, या कोई मानव समीक्षक — जो किसी तय मानदंड के आधार पर एजेंट के आउटपुट या कार्रवाई की जाँच करता है। ग्रेडर एक पास/फ़ेल निर्णय और प्रासंगिक साक्ष्य बताने वाली व्याख्या देता है।

जानकारी: ग्रेडिंग रूब्रिक मानदंडों और निर्देशों का एक सेट होता है, जो तय करता है कि किसे सही या स्वीकार्य परिणाम माना जाएगा।

सही ग्रेडर का प्रकार इस बात पर निर्भर करता है कि आप क्या सत्यापित करना चाहते हैं। तीनों तरीकों की तुलना इस तरह है:

ग्रेडर

किसके लिए सबसे उपयुक्त

उदाहरण

मुख्य सीमा

कोड-आधारित

सटीक, सत्यापन योग्य शर्तें

क्या सुझाया गया स्पेयर पार्ट स्वीकृत संगतता सूची में था?

हर व्यक्तिपरक निर्णय का भरोसेमंद आकलन नहीं कर सकता

LLM-as-a-judge

संदर्भ पर निर्भर आकलन

क्या एजेंट ने बताया कि वह रिप्लेसमेंट की सिफ़ारिश क्यों नहीं कर सका?

इसके निर्णय गलत या असंगत हो सकते हैं

मानव

डोमेन-विशिष्ट विशेषज्ञता और अनिश्चित मामले

क्या मेंटेनेंस मैनेजर एजेंट की सिफ़ारिश को उचित मानते हैं?

बड़े पैमाने पर लागू करना महँगा

कभी-कभी एक ही रन के अलग-अलग पहलुओं के लिए अलग-अलग मूल्यांकन तरीकों की ज़रूरत हो सकती है, इसलिए आपको कई ग्रेडर को मिलाकर इस्तेमाल करना पड़ सकता है।

ग्रेडर को कैसे मिलाएँ?

खुद से पूछें: “क्या परिणाम को किसी ज्ञात नियम या अपेक्षित मान के आधार पर सत्यापित किया जा सकता है, या इसके लिए इंसान जैसे विवेक की ज़रूरत है?”

  • अगर आप परिणाम को सटीक रूप से सत्यापित कर सकते हैं, तो कोड-आधारित ग्रेडर से शुरुआत करें। कोड-आधारित ग्रेडर स्ट्रक्चर्ड आउटपुट, मान्य फ़ील्ड मान, टूल आर्ग्युमेंट या डेटाबेस की अंतिम स्थिति को भी सत्यापित कर सकते हैं।
  • अगर जाँच के लिए संदर्भ की व्याख्या करनी पड़े, तो LLM-as-a-judge का इस्तेमाल करें।
  • डोमेन-विशिष्ट या विवादित निर्णयों के लिए मानव समीक्षकों का इस्तेमाल करें।

महत्वपूर्ण! कोई LLM ग्रेडर साक्ष्य की गलत व्याख्या कर सकता है या रूब्रिक को गलत तरीके से लागू कर सकता है। इसलिए उसके लिए मूल्यांकन का एक अतिरिक्त चरण ज़रूरी होता है: मानव निर्णयों के आधार पर कैलिब्रेशन।

मानव निर्णयों के आधार पर LLM ग्रेडर को कैलिब्रेट करें।

मूल रूप से, कैलिब्रेशन के लिए ज़रूरी है कि कोई डोमेन विशेषज्ञ एजेंट के वास्तविक रन का आकलन करे। इसके बाद विशेषज्ञ अपने निर्णयों की तुलना LLM के निर्णयों से करता है और असहमतियों के आधार पर ग्रेडिंग रूब्रिक को बेहतर बनाता है।

यहाँ पाँच चरणों वाली ग्रेडर कैलिब्रेशन प्रक्रिया दी गई है:

  1. एजेंट के इनपुट, आउटपुट और प्रासंगिक ट्रेस के उदाहरण इकट्ठा करें।
  2. किसी डोमेन विशेषज्ञ से स्वतंत्र रूप से आकलन करवाएँ कि हर उदाहरण मूल्यांकन मानदंड को पूरा करता है या नहीं।
  3. उन उदाहरणों पर LLM ग्रेडर चलाएँ।
  4. मानव और मॉडल के निर्णयों की तुलना करें।
  5. असहमतियों की जाँच करें और नए उदाहरणों पर परखने से पहले ग्रेडर के रूब्रिक को बेहतर बनाएँ।

Khomutov LLM ग्रेडर की एकरूपता को अलग से परखने के महत्व पर भी ज़ोर देते हैं:

“एजेंट को दोबारा चलाए बिना, ग्रेडर को बिल्कुल वही सहेजा गया रन और फ़ाइलें कई बार दें। इससे आप एजेंट के काम में होने वाले अंतर को ग्रेडिंग में होने वाले अंतर से अलग कर सकते हैं।”

अगर एक ही आउटपुट को अलग-अलग फ़ैसले मिलते हैं, तो यह न मानें कि स्कोर में हर बदलाव एजेंट की वजह से है। इसके बजाय, एक कन्फ़्यूज़न मैट्रिक्स देखें, जो दिखाता है कि ग्रेडर ने कब त्रुटियों को सही पहचाना, कब उन्हें पकड़ने से चूक गया, या कब स्वीकार्य आउटपुट को गलत तरीके से फ़्लैग किया।

संदर्भ निर्णय तय करने, विवादित मामलों को सुलझाने और ऐसे नए विफलता मोड खोजने के लिए मानव समीक्षा अब भी ज़रूरी है, जिन्हें पकड़ने के लिए मौजूदा ग्रेडर बनाए ही नहीं गए थे।

चरण 5. वर्ज़न की तुलना करें और रिग्रेशन जाँच चलाएँ

मान लीजिए त्रुटि विश्लेषण से पता चलता है कि आपका इन्वेंटरी एजेंट अक्सर अस्वीकृत रिप्लेसमेंट पार्ट्स की सिफ़ारिश करता है। आप उसके सिस्टम प्रॉम्प्ट में बदलाव करके स्पष्ट संगतता जाँच को अनिवार्य कर देते हैं। अब पहले विफल होने वाला केस पास हो जाता है। लेकिन आपको कैसे पता चलेगा कि इस बदलाव ने दूसरे कार्यों पर असर नहीं डाला है?

यहीं पर रिग्रेशन टेस्टिंग काम आती है।

रिग्रेशन टेस्टिंग का मतलब है एजेंट के प्रॉम्प्ट, मॉडल या वर्कफ़्लो में बदलाव करने के बाद पहले सफल रहे टेस्ट केस को दोबारा चलाना, ताकि यह सुनिश्चित हो सके कि बदलाव से कोई नई विफलता नहीं आई है।

  1. टेस्ट सेट से सहेजे गए इनपुट का इस्तेमाल करके मूल विफलता को दोबारा उत्पन्न करें।
  2. प्रॉम्प्ट, मॉडल या वर्कफ़्लो में लक्षित बदलाव करें।
  3. समस्या हल हुई है या नहीं, यह जाँचने के लिए विफल टेस्ट को दोबारा चलाएँ।
  4. अन्य टेस्ट चलाएँ ताकि यह पुष्टि हो सके कि इस बदलाव से वह व्यवहार नहीं बिगड़ा है जो पहले सफलतापूर्वक काम कर रहा था।
  5. नतीजों की जाँच करें और किसी भी नई विफलता की पड़ताल करें।

सटीक नतीजों के लिए बेसलाइन और अपडेट किए गए एजेंट की तुलना एक ही टेस्ट केस और ग्रेडिंग मानदंडों का उपयोग करके करें।

चरण 6: प्रोडक्शन में AI एजेंट के प्रदर्शन की निगरानी करें

एप्लिकेशन डिप्लॉय करने के बाद भी एजेंट का मूल्यांकन बंद नहीं होता। जैसा कि Husain और Shankar बताते हैं, डेवलपमेंट के दौरान इस्तेमाल किए जाने वाले वही इवैल्युएटर असली प्रोडक्शन डेटा पर भी चलाए जा सकते हैं, ताकि यह मापा जा सके कि समय के साथ आपका एजेंट कैसा प्रदर्शन करता है।

इसे ऑनलाइन मूल्यांकन कहा जाता है, और यह प्रोडक्शन मॉनिटरिंग की एक व्यापक प्रक्रिया का हिस्सा है, जो बार-बार होने वाली और पहले से अज्ञात विफलताओं का पता लगाने में मदद करती है।

यह प्रक्रिया बार-बार दोहराई जाती है और इसमें एक-दूसरे की पूरक चार गतिविधियाँ शामिल हैं:

  • प्रोडक्शन ट्रेस पर कैलिब्रेट किए गए LLM जज चलाएँ। एजेंट के असली इंटरैक्शन के सैंपल लें और उन इवैल्युएटर को लागू करें जिन्हें आप पहले ही मानवीय आकलनों के आधार पर सत्यापित कर चुके हैं।
  • समय के साथ विफलता दरों पर नज़र रखें। बार-बार होने वाली समस्याओं को मापने के लिए त्रुटि विश्लेषण के दौरान तय की गई विफलता श्रेणियों का उपयोग करें।
  • ट्रेस की मैन्युअल समीक्षा जारी रखें। ऑटोमेटेड ग्रेडर सिर्फ़ उन्हीं समस्याओं का पता लगाते हैं जिन्हें पहचानने के लिए उन्हें बनाया गया है। नई त्रुटियों या असामान्य यूज़र अनुरोधों का पता लगाने के लिए एजेंट के असली इंटरैक्शन के सैंपल की मैन्युअल रूप से जाँच करें।
  • बिज़नेस नतीजों को मापने के लिए A/B टेस्टिंग का उपयोग करें (सिर्फ़ तभी जब उचित हो)। टास्क पूरा होने, यूज़र संतुष्टि और समाधान में लगने वाले समय जैसे मेट्रिक्स का उपयोग करके अलग-अलग प्रॉम्प्ट, मॉडल या वर्कफ़्लो की तुलना करें। यह प्रक्रिया यह तय करने में मदद करती है कि कोई बदलाव अलग-अलग टेस्ट पास करने से आगे बढ़कर असल प्रोडक्ट अनुभव को बेहतर बनाता है या नहीं।

एक ज़रूरी बात: इवैल्स को पूरी तरह परफ़ेक्ट बनाने की ज़रूरत नहीं है। उन्हें बस इतना अच्छा होना चाहिए कि वे आपके प्रोडक्ट को बेहतर बना सकें।

AI एजेंट मूल्यांकन से जुड़ी आम गलतफ़हमियाँ

  • इवैल्स बस यूनिट टेस्ट हैं। ऐसा नहीं है; यूनिट टेस्ट छोटी, ऑटोमेटेड जाँचें होती हैं जो मूल्यांकन का सिर्फ़ एक हिस्सा हैं। इवैल्स में एप्लिकेशन की गुणवत्ता मापने के लिए गुणात्मक त्रुटि विश्लेषण, मानवीय आकलन, प्रोडक्शन मॉनिटरिंग और प्रयोग भी शामिल होते हैं।
  • कोई मूल्यांकन प्लेटफ़ॉर्म आपके लिए सब कुछ कर सकता है। तैयार टूल कुछ जाँचों को ऑटोमेट कर सकते हैं, लेकिन वे यह तय नहीं कर सकते कि कौन-से फ़ेल्योर मोड (त्रुटियों के प्रकार या एजेंट के अवांछित व्यवहार) आपके प्रोडक्ट के लिए मायने रखते हैं।
  • आप हर चीज़ का मूल्यांकन LLM पर छोड़ सकते हैं। यह एक बड़ी भ्रांति है। इंसानों के नेतृत्व में होने वाला त्रुटि विश्लेषण और ग्रेडर कैलिब्रेशन अब भी ज़रूरी हैं, क्योंकि LLM के पास हर समस्या का पता लगाने के लिए ज़रूरी बिज़नेस संदर्भ नहीं होता।
  • A/B टेस्टिंग या सिर्फ़ एजेंट का इस्तेमाल करना इवैल्स की जगह ले लेता है। गलत। A/B टेस्ट यह दिखा सकते हैं कि चुने गए मेट्रिक्स पर कौन-सा वर्शन बेहतर प्रदर्शन करता है, लेकिन वे अपने आप में मूल समस्याओं की व्याख्या नहीं कर सकते।

AI एजेंट मूल्यांकन से जुड़े अक्सर पूछे जाने वाले सवाल

1. AI एजेंट मूल्यांकन और LLM मूल्यांकन में क्या अंतर है?

LLM मूल्यांकन यह मापता है कि कोई लैंग्वेज मॉडल किसी दिए गए टास्क को कितनी अच्छी तरह करता है, जैसे किसी सवाल का जवाब देना, किसी दस्तावेज़ का सारांश बनाना या जानकारी निकालना। AI एजेंट मूल्यांकन ऐसे सिस्टम का आकलन करता है जो कोई टास्क पूरा करने के लिए स्वतंत्र रूप से कई चरण पूरे करता है।

सामान्य LLM मूल्यांकन के विपरीत, एजेंट मूल्यांकन अंतिम नतीजे के साथ-साथ उसे हासिल करने के लिए की गई कार्रवाइयों के क्रम की भी जाँच करता है, जिसमें टूल कॉल, निर्णय और पहले से तय नियमों का पालन शामिल है।

2. AI एजेंट मूल्यांकन के लिए मुख्य मेट्रिक्स

AI एजेंट मूल्यांकन मेट्रिक्स दो व्यापक श्रेणियों में आते हैं:

  • तकनीकी प्रदर्शन मेट्रिक्स: टास्क सफलता दर, कार्रवाई की शुद्धता, जवाब की गुणवत्ता, विश्वसनीयता (pass@1 और pass@k), लेटेंसी, टोकन उपयोग और प्रति सफल टास्क लागत।
  • बिज़नेस और यूज़र अनुभव मेट्रिक्स: ग्राहक संतुष्टि (CSAT), समस्या समाधान दर, एस्केलेशन दर, कन्वर्ज़न दर, टास्क पूरा करने में लगने वाला समय और एजेंट की भूमिका से जुड़े अन्य नतीजे।

उदाहरण के लिए, किसी ग्राहक सहायता एजेंट का मूल्यांकन समस्याओं के सफल समाधान और ग्राहक संतुष्टि के आधार पर किया जा सकता है, जबकि किसी AI खरीद एजेंट को स्टॉक की भरपाई के अनुरोधों की सटीकता, अनुमोदन दरों और खरीद चक्र में लगने वाले समय से मापा जा सकता है।

सही मेट्रिक्स से यह पता चलना चाहिए कि एजेंट कितनी विश्वसनीयता से काम करता है और क्या उसका काम बिज़नेस नतीजों को बेहतर बनाता है।

3. AI एजेंट का मूल्यांकन करने के लिए सबसे अच्छे टूल कौन-से हैं?

आम विकल्पों में ये शामिल हैं:

  • टेस्टिंग फ़्रेमवर्क: Python असर्शन और pytest दोहराए जा सकने वाले टेस्ट केस चलाने और सटीक शर्तों की जाँच करने के लिए उपयोगी हैं, जैसे कि एजेंट ने सही टूल चुना या नहीं, या मान्य पार्ट ID लौटाया या नहीं।
  • AI एजेंट मूल्यांकन फ़्रेमवर्क: DeepEval और Google का agent-eval toolkit ज़्यादा जटिल मूल्यांकनों को सपोर्ट करते हैं, जिनमें एक्ज़ीक्यूशन ट्रेस, LLM-आधारित ग्रेडर और ऑटोमेटेड रिग्रेशन टेस्टिंग शामिल हैं।
  • मूल्यांकन और ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म: LangSmith, Arize Phoenix और MLflow टीमों को एजेंट के व्यवहार की जाँच करने, मूल्यांकन डेटासेट मैनेज करने, एजेंट के वर्शन की तुलना करने और प्रोडक्शन में प्रदर्शन की निगरानी करने में मदद करते हैं।

4. AI एजेंट मूल्यांकनों को ऑटोमेट कैसे करें?

आप दोहराए जा सकने वाले टेस्ट बनाकर, ऑटोमेटेड ग्रेडर लागू करके और उन जाँचों को डेवलपमेंट और प्रोडक्शन वर्कफ़्लो में इंटीग्रेट करके AI एजेंट मूल्यांकनों को ऑटोमेट कर सकते हैं:

  1. मूल्यांकन डेटासेट बनाएँ: यूज़र के प्रतिनिधि टास्क, अपेक्षित नतीजे, ज्ञात विफलताएँ और एजेंट के एक्ज़ीक्यूशन ट्रेस इकट्ठा करें। इसमें विफल टूल कॉल, अधूरी जानकारी और अनधिकृत कार्रवाइयों जैसे एज केस भी शामिल करें।
  2. टेस्ट एक्ज़ीक्यूशन और ग्रेडिंग को ऑटोमेट करें: टेस्ट केस चलाने और कोड-आधारित जाँचें या LLM ग्रेडर लागू करने के लिए pytest या DeepEval जैसे फ़्रेमवर्क का उपयोग करें। LLM ग्रेडर के स्कोर पर भरोसा करने से पहले उन्हें मानवीय आकलनों के आधार पर सत्यापित करें।
  3. मूल्यांकनों को CI/CD में इंटीग्रेट करें: जब डेवलपर किसी एजेंट के प्रॉम्प्ट, मॉडल, टूल या वर्कफ़्लो को अपडेट करें, तो रिग्रेशन टेस्ट अपने आप दोबारा चलाएँ। नतीजों की तुलना बेसलाइन से करें और गुणवत्ता की ऐसी सीमाएँ तय करें जो अहम जाँचें विफल होने पर रिलीज़ को रोक दें।
  4. सैंपल किए गए प्रोडक्शन ट्रेस पर कैलिब्रेट किए गए ग्रेडर लागू करें, विफलता दरों और प्रदर्शन के अन्य मेट्रिक्स पर नज़र रखें, और मैन्युअल समीक्षा के ज़रिए नई त्रुटियों की पड़ताल करें।