AWS ने विभिन्न फ्रेमवर्कों में AI एजेंटों के मूल्यांकन के लिए UAEF का विवरण दिया

11 नवंबर, 2026 को AWS ने Universal Agent Evaluation Framework (UAEF) का तकनीकी परिचय प्रकाशित किया। यह Apache-2.0 लाइसेंस के तहत उपलब्ध ओपन-सोर्स प्रणाली है, जो सात आयामों में 36 अंतर्निहित मेट्रिक्स का उपयोग करके AI एजेंटों का मूल्यांकन करती है।

UAEF को LangGraph, LangChain, Strands Agents और Amazon Bedrock AgentCore पर किए गए मूल्यांकनों को तुलनीय बनाए रखने के लिए तैयार किया गया है। ये फ्रेमवर्क संदेशों, टूल कॉल और एजेंटों के बीच कार्य-हस्तांतरण को अलग-अलग तरीकों से दर्ज करते हैं। इसलिए, किसी एक प्रारूप से जुड़ा मूल्यांकन कोड बदलते फ्रेमवर्क के बाद नए मेट्रिक्स, स्कोरिंग लॉजिक और परिणामों के भंडारण की मांग कर सकता है। इससे यह तय करना कठिन हो जाता है कि प्रॉम्प्ट, मॉडल या टूल में किए गए बदलाव से एजेंट बेहतर हुआ या नहीं।

AWS के अनुसार, दूरसंचार, स्वास्थ्य सेवा और वित्तीय सेवा क्षेत्रों के 12 संगठनों के ग्राहकों ने रिलीज़ से पहले एजेंट के विभिन्न संस्करणों पर एकसमान मेट्रिक्स लागू करने और उनकी तुलना करने के लिए UAEF का इस्तेमाल किया। awslabs/uaef रिपॉज़िटरी में Python लाइब्रेरी, फ्रेमवर्क अडैप्टर, मेट्रिक्स, AWS परिनियोजन अवसंरचना, वेब इंटरफ़ेस और चलाए जा सकने वाले नोटबुक शामिल हैं।

मानकीकृत ट्रेस से साझा स्कोरिंग

अडैप्टर हर एजेंट के संदेशों, टूल कॉल और कार्य-हस्तांतरण को एक मानक AgentTraceनिरूपण में बदलते हैं—यह स्कोरिंग इंजन द्वारा इस्तेमाल किया जाने वाला एकमात्र निरूपण है। UAEF पिछली बार के रन, लॉग या ऑब्ज़र्वेबिलिटी स्टोर से मौजूदा ट्रेस को अनुकूलित कर सकता है, या रनटाइम Amazon Resource Name अथवा HTTP एंडपॉइंट के ज़रिए एजेंट को चला सकता है और उससे मिले निष्पादन को रूपांतरित कर सकता है। सामान्य JSON अडैप्टर इस प्रक्रिया को कस्टम फ्रेमवर्क तक विस्तारित करता है।

मेट्रिक्स कैटलॉग में अंतर्निहित मेट्रिक्स को टूल कॉलिंग, जवाब की गुणवत्ता, ज़िम्मेदार AI, प्रदर्शन, बहु-चरणीय बातचीत, बहु-एजेंट समन्वय और तर्क-वितर्क के वर्गों में बाँटा गया है। स्कोर 0 से 1 के सामान्यीकृत पैमाने पर दिए जाते हैं, जहाँ 1 सर्वश्रेष्ठ है। नियतात्मक मेट्रिक्स ट्रेस और ग्राउंड ट्रुथ से सीधे गणना करते हैं, जबकि LLM-as-a-judge मेट्रिक्स प्रासंगिकता और सुरक्षा जैसी विशेषताओं का आकलन करने के लिए Amazon Bedrock पर एक मॉडल का उपयोग करते हैं। कस्टम मेट्रिक्स के साथ RAGAS और DeepEval इंटीग्रेशन भी समर्थित हैं।

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

संग्रहीत प्रयोगों से समस्याएँ उजागर होती हैं

सहेजे गए मूल्यांकन प्रयोग बन जाते हैं। Amazon DynamoDB सूचीकरण और तुलना के लिए मेटाडेटा संग्रहीत करता है, जिसमें मूल्यांकनों की संख्या और औसत स्कोर शामिल हैं; वहीं Amazon S3 हर मेट्रिक के स्कोर और निर्णायक मॉडल के तर्क सहित पूरे JSON परिणाम रखता है। हर रन में इस्तेमाल किया गया फ्रेमवर्क, मॉडल, टूल, सिस्टम प्रॉम्प्ट, पैरामीटर, कॉन्फ़िगरेशन का स्नैपशॉट और Git कमिट दर्ज किया जा सकता है, जिससे हर स्कोर का संबंध परीक्षणाधीन एजेंट डिज़ाइन से जुड़ जाता है। UAEF भंडारण से पहले ट्रेस में निजी जानकारी की जाँच करता है और सहेजे गए परिणामों को छिपाने की सुविधा भी उपलब्ध है।

दो रन में साझा मेट्रिक्स के लिए तुलना इंजन आधार-रेखा के सापेक्ष निरपेक्ष और प्रतिशत बदलावों की गणना करता है। डिफ़ॉल्ट रूप से 5% पर निर्धारित की जा सकने वाली सीमा सुधार, गिरावट और बिना बदलाव वाले परिणामों को अलग करती है; गिरावट को मामूली, मध्यम या गंभीर श्रेणी दी जाती है और आयाम के अनुसार बाँटा जाता है। इस वर्गीकरण से पता चल सकता है कि प्रॉम्प्ट में बदलाव से टूल कॉलिंग प्रभावित हुई, जबकि जवाब की गुणवत्ता में कोई बदलाव नहीं आया।

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

Python लाइब्रेरी और लो-कोड वेब सेवा एक ही मूल्यांकन इंजन और स्टोरेज का उपयोग करते हैं। टीमें नोटबुक, स्क्रिप्ट और निरंतर एकीकरण व निरंतर परिनियोजन पाइपलाइन में, या ब्राउज़र के ज़रिए मूल्यांकन चला सकती हैं—और परिणामों को स्कोर करने तथा उनकी तुलना करने का तरीका नहीं बदलता।

AWS पर निर्भरता और पृथक्करण की सीमाएँ

इंस्टॉलेशन गाइड के अनुसार Python 3.10 या उसके बाद का संस्करण और uv पैकेज मैनेजर आवश्यक हैं। Bedrock-आधारित निर्णय और DynamoDB/S3 में डेटा सहेजने के लिए AWS क्रेडेंशियल चाहिए। इसलिए, इन निर्णय और भंडारण सुविधाओं का उपयोग करने वाली टीमें AWS सेवाओं से जुड़ी रहती हैं, भले ही उनके एजेंट अलग-अलग फ्रेमवर्क इस्तेमाल करते हों।

UAEF मूल्यांकित एजेंट के आउटपुट को निर्णायक मॉडल के प्रॉम्प्ट के लिए अविश्वसनीय इनपुट मानता है। यह मूल्यांकन मानदंड अलग से भेजता है, सामग्री को एस्केप करता है, निर्णायक मॉडल के जवाबों को सख्ती से पार्स करता है और स्कोर स्वीकार करने से पहले साक्ष्य का हूबहू उद्धृत अंश माँगता है। AWS का कहना है कि निर्णायक मॉडल के स्कोर को सुरक्षा नियंत्रणों पर रोक लगाने के लिए इस्तेमाल नहीं करना चाहिए; रनटाइम पर नियंत्रण लागू करने के लिए Amazon Bedrock Guardrails का अलग इनवोकेशन पथ होना चाहिए।

रिपॉज़िटरी में UAEF को एक संदर्भ आर्किटेक्चर बताया गया है, जिसे ऐसे प्लेटफ़ॉर्म के भीतर चलाने के लिए बनाया गया है जो उपयोगकर्ताओं और टेनेंटों का पृथक्करण सुनिश्चित करता हो। होस्ट स्तर पर ऐसे नियंत्रणों के बिना सीधे बहु-टेनेंट परिनियोजन समर्थित नहीं है। हर टेनेंट के लिए अलग परिनियोजन ज़रूरी है, जिसमें उसका अपना AWS खाता हो या कम-से-कम उसका अपना स्टैक, DynamoDB टेबल, S3 बकेट और Cognito उपयोगकर्ता पूल हो।

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