एजेंटिक सिस्टम का मूल्यांकन: चार-अक्षीय विधि

2026 की शुरुआत में, मैं एक प्रमुख उत्तरी अमेरिकी बैंक में वेल्थ-मैनेजमेंट प्रूफ ऑफ वैल्यू चला रहा था। समीक्षाधीन एजेंट एक चैटबॉट नहीं था। यह एक शासित वर्कफ़्लो के भीतर रहता था: इसे एक केस प्राप्त होता था, टूल (दस्तावेज़ पुनर्प्राप्ति, स्क्रीनिंग जाँच, खाता लुकअप) को कॉल करता था, और एक संरचित आउटपुट उत्पन्न करता था जिसे डाउनस्ट्रीम प्रक्रिया चरण बिना किसी मानव द्वारा पहले पढ़े उपभोग करते थे। एक कार्य सत्र के अंत के करीब, क्लाइंट पक्ष के किसी व्यक्ति ने वह प्रश्न पूछा जो हर एंटरप्राइज़ अंततः पूछता है: “यह मॉडल क्यों? और प्रति केस इसकी लागत हमें कितनी होगी?”

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

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

बेंचमार्क मूल्यांकन गलत प्रश्न का उत्तर क्यों देते हैं

एक प्रक्रिया-एम्बेडेड एजेंट एक चैटबॉट से चार तरीकों से भिन्न होता है जो चैटबॉट-युग की हर मूल्यांकन तकनीक को तोड़ देता है।

यह निर्माण द्वारा बहु-मोड़ है। एक प्रक्रिया इंस्टेंस एक लूप है: मॉडल योजना बनाता है, एक टूल को कॉल करता है, परिणाम प्राप्त करता है, फिर से योजना बनाता है। एक सिंगल केस में दो मॉडल कॉल या चौदह शामिल हो सकते हैं। “एक प्रॉम्प्ट, एक पूर्णता” पर गणना किया गया कोई भी मीट्रिक एक ऐसी चीज़ को मापता है जो उत्पादन में कभी नहीं होती।

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

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

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

आयाम	बेंचमार्क मूल्यांकन (चैटबॉट युग)	प्रक्रिया मूल्यांकन (एजेंट युग)
माप की इकाई	एक प्रॉम्प्ट, एक पूर्णता	एक प्रक्रिया इंस्टेंस, एंड-टू-एंड
इंटरैक्शन का आकार	एकल-मोड़ प्रश्नोत्तर	टूल कॉल के साथ बहु-मोड़ लूप
निर्णयित आउटपुट	मुक्त पाठ, मानवीय वरीयता	संरचित फ़ील्ड, प्रति फ़ील्ड श्रेणीबद्ध
लागत मॉडल	प्रति मिलियन टोकन मूल्य	प्रति केस मापी गई लागत, जिसमें पुनः प्रयास और टूल राउंड ट्रिप शामिल हैं
दृश्यमान विफलता मोड	गलत या अनुपयोगी उत्तर	गलत फ़ील्ड, छोड़ा गया टूल, गलत टूल, गलत या भ्रमित तर्क, समय से पहले उत्तर
‘अच्छा’ का क्या अर्थ है	लीडरबोर्ड स्थिति	प्रक्रिया स्वीकार्य, अनुमानित लागत पर सही ढंग से पूरी हुई

इस मार्गदर्शिका का शेष भाग चार अक्षों को एक-एक करके लेता है। प्रत्येक लॉग करने के लिए ठोस चीजों और गणना करने के लिए मेट्रिक्स का एक सेट है। साथ में वे उस कमरे से दो सवालों का जवाब देते हैं: कौन सा मॉडल, और प्रति केस कितनी लागत पर।

अक्ष 1: प्रति प्रक्रिया इंस्टेंस लागत

महत्वपूर्ण इकाई टोकन नहीं है। यह केस है: एक ऋण आवेदन, एक KYC समीक्षा, एक दावा। यह वह इकाई है जिसके आधार पर व्यवसाय मूल्य निर्धारित करता है, कर्मचारी नियुक्त करता है और बजट बनाता है, इसलिए यह वह इकाई है जिसमें आपके मूल्यांकन को रिपोर्ट करना चाहिए।

प्रति इंस्टेंस मापी गई लागत उस इंस्टेंस द्वारा ट्रिगर किए गए हर मॉडल कॉल का योग है:

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

इसकी गणना करने के लिए, प्रति मॉडल कॉल लॉग करें: मॉडल पहचानकर्ता, इनपुट टोकन, आउटपुट टोकन, विलंबता और समाप्ति कारण। प्रति इंस्टेंस लॉग करें: पुनरावृत्ति गणना और पुनः प्रयास गणना। टोकन को प्रदाता की वर्तमान कीमतों से गुणा करें और योग करें। मीडियन और p95 की रिपोर्ट करें, क्योंकि एजेंटिक लागत वितरण में लंबी पूंछ होती है; वह केस जो तीन पुनः प्रयास और बारह टूल कॉल को ट्रिगर करता है, वही है जो चालान में दिखाई देता है।

एक व्युत्पन्न मीट्रिक ने तब से हर जुड़ाव में अपना स्थान अर्जित किया है: प्रति सही केस लागत, जो प्रति इंस्टेंस लागत को उन इंस्टेंस के अंश से विभाजित करती है जिन्हें मॉडल ने पूरी तरह से सही किया। एक सस्ता मॉडल जो एक तिहाई समय गलत होता है, वह सस्ता नहीं होता, क्योंकि कोई पुनः कार्य के लिए भुगतान करता है।

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

इस अक्ष पर खतरा मापने के बजाय मूल्य सूचियों की तुलना करना है। एक मॉडल जिसकी प्रति टोकन लागत आधी है लेकिन प्रति केस औसतन दो अतिरिक्त लूप पुनरावृत्तियाँ और एक पुनः प्रयास होता है, वह अधिक महंगा हो सकता है। मैंने ठीक यही उलटाव होते देखा है। लूप को मापें, सूची को नहीं।

अक्ष 2: गुणवत्ता, प्रति फ़ील्ड श्रेणीबद्ध

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

गोल्ड सेट बनाना। क्षेत्र से मेरा नियम: वास्तविक मामलों से तैयार किए गए 10 से 30 परिदृश्य 1,000 सिंथेटिक परिदृश्यों से बेहतर हैं। सिंथेटिक केस जनरेटर (आमतौर पर एक और LLM) परीक्षण के तहत मॉडल के समान ब्लाइंड स्पॉट दोहराते हैं; वे स्वच्छ, सुव्यवस्थित, सांख्यिकीय रूप से औसत मामले उत्पन्न करते हैं। वास्तविक मामले उन अजीबोगरीब स्थितियों को ले जाते हैं जो वास्तव में एजेंटों को तोड़ देती हैं: हाइफ़नेटेड नाम जो एक मिलान अनुमान को हरा देता है, दोहरी नागरिकता वाला ग्राहक, एक पृष्ठ गायब वाला दस्तावेज़, वह इकाई जिसका पंजीकृत पता उसके परिचालन पते से भिन्न है। मैं जिस प्रक्रिया का उपयोग करता हूँ:

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

प्रति फ़ील्ड ग्रेडिंग, अनुभव के अनुसार नहीं। क्योंकि आउटपुट संरचित है, अधिकांश ग्रेडिंग नियतात्मक हो सकती है: एनम और पहचानकर्ताओं के लिए सटीक मिलान, नामों और तिथियों के लिए सामान्यीकृत मिलान, राशियों के लिए संख्यात्मक सहिष्णुता। मुक्त-पाठ औचित्य फ़ील्ड के लिए LLM-as-judge आरक्षित करें, और उन स्कोरों को दिशात्मक मानें, आधिकारिक नहीं (सीमाओं के तहत न्यायाधीश पूर्वाग्रह पर अधिक)। गणना करें:

• परिदृश्यों में प्रति-फ़ील्ड सटीकता, ताकि आप देख सकें कि entity_type ठीक है लेकिन source_of_wealth कमजोर है।
• प्रति परिदृश्य सभी-फ़ील्ड-सही दर, वह संख्या जो “पुनः कार्य की आवश्यकता वाले मामलों” से मेल खाती है।
• महत्वपूर्ण-फ़ील्ड सटीकता अपनी खुद की हेडलाइन के रूप में। एक अनुपालन प्रक्रिया में, pep_flag को गलत करना एक फॉर्मेटिंग की बारीकी को गलत करने जैसा नहीं है। तदनुसार भार दें और रिपोर्ट में ऐसा कहें।

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

अक्ष 3: टूल विश्वसनीयता, वह अक्ष जिसे कोई नहीं मापता

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

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

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

यदि आपका हार्नेस केवल वही रिकॉर्ड करता है जो एजेंट ने कहा, तो आप कुछ टूल के पास खड़े एक टेक्स्ट जनरेटर का मूल्यांकन कर रहे हैं। रिकॉर्ड करें कि उसने क्या किया, और वह क्या करने में विफल रहा।

ट्रांसक्रिप्ट से (जिन्हें आप पहले से ही लागत अक्ष के लिए लॉग कर रहे हैं), प्रति मॉडल गणना करें:

• टूल रिकॉल: एक सही निष्पादन के लिए आवश्यक टूल कॉल में से, एजेंट ने कितना अंश बनाया?
• प्रति टूल स्किप दर: कौन से विशिष्ट टूल स्किप किए जाते हैं, और किन परिदृश्य वर्गों पर? स्किप क्लस्टर होते हैं; एक टूल जिसे स्किप किया जाता है वह आमतौर पर ऐसा होता है जिसका विवरण उसकी आवश्यकता को स्पष्ट नहीं करता है।
• गलत-टूल दर: एजेंट ने कुछ कॉल किया, लेकिन सही कुछ नहीं।
• गलत-तर्क दर: कॉल जो स्कीमा सत्यापन में विफल रहे।
• तर्क सटीकता: कॉल जो सत्यापन पास कर गए लेकिन गलत मान ले गए।

टूल विफलताओं का पूर्ण वर्गीकरण, जिस क्रम में मैं उनके बारे में चिंता करता हूँ:

टूल स्किप

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

समय से पहले उत्तर

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

भ्रमित तर्क

कॉल स्कीमा-वैध है और रनटाइम इसे स्वीकार करता है, लेकिन एक तर्क मान मामले से लेने के बजाय आविष्कार किया गया था: एक मनगढ़ंत खाता पहचानकर्ता, एक ऐसी तारीख जो दस्तावेजों में नहीं है। यह हर स्वचालित गेट को पास करता है और डाउनस्ट्रीम डेटा को दूषित करता है। पता लगाने के लिए तर्क-स्तरीय गोल्ड मान या एक विशेषज्ञ स्पॉट-चेक की आवश्यकता होती है; इसके लिए बजट रखें।

गलत टूल चयन

एजेंट अकाउंट-हिस्ट्री टूल को कॉल करता है जब केस को स्क्रीनिंग टूल की आवश्यकता होती है। आमतौर पर मॉडल की कमजोरी के बजाय ओवरलैपिंग टूल विवरण का एक लक्षण। एनोटेशन के खिलाफ स्वचालित रूप से पता लगाने योग्य।

गलत तर्क

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

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

अक्ष 4: तापमान संवेदनशीलता

मैंने इस अक्ष को उबाऊ होने की उम्मीद में जोड़ा था। कुछ तापमानों पर ग्रिड चलाएं, पुष्टि करें कि तापमान शून्य आउटपुट भिन्नता को कम करता है, एक स्लाइड लिखें, आगे बढ़ें। डेटा ने ऐसा नहीं कहा।

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

यह अक्ष बिल्कुल क्यों मौजूद है: नियामक ग्राहक विशेष रूप से तापमान शून्य मांगते हैं, और विक्रेता इसे नियमित रूप से एक सुरक्षा नियंत्रण के रूप में प्रस्तुत करते हैं। इससे पहले कि आप बैंक में उस दावे को दोहराएं, आपको पता होना चाहिए कि तापमान शून्य वास्तव में आपके विशिष्ट एजेंट के लिए क्या करता है, क्योंकि “यह बदलता है कि कौन से टूल कॉल किए गए” “यह यादृच्छिकता को कम करता है” से भौतिक रूप से भिन्न कथन है।

किसी नियामक ग्राहक को यह न बताएं कि तापमान शून्य एक सुरक्षा नियंत्रण है जब तक कि आपने यह न मापा हो कि यह क्या बदलता है। मेरे परीक्षणों में इसने बदल दिया कि कौन से टूल कॉल किए गए।

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

संख्याएँ आपकी वास्तुकला के लिए क्या करती हैं: मॉडल रूटिंग

चार अक्ष फाइल करने के लिए एक रिपोर्ट कार्ड नहीं हैं। वे रूटिंग इनपुट हैं।

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

• फ्लैट वक्र। मध्य-स्तरीय मॉडल प्रीमियम मॉडल के समान गुणवत्ता पर लागत के एक अंश पर बैठता है। यह KYC-शैली की खोज थी: समान सटीकता, लगभग 1/13वें हिस्से की लागत। निर्णय: मध्य-स्तरीय मॉडल चलाएं, प्रीमियम मॉडल को वृद्धि लक्ष्य के रूप में रखें, और अंतर को बचाएं। फ्लैट वक्र अच्छे टूल कॉन्ट्रैक्ट्स के साथ निष्कर्षण और नियम-पालन कार्यों पर आम हैं।
• क्लिफ वक्र। गुणवत्ता एक निश्चित मॉडल टियर के नीचे तेजी से गिरती है। कई दस्तावेजों में वास्तविक बहु-चरणीय निर्णय या संश्लेषण की आवश्यकता वाले कार्यों पर आम है। निर्णय: क्लिफ के ऊपर के टियर के लिए भुगतान करें; खरीद को आपको इसके नीचे बात न करने दें।
• कुछ नहीं के लिए भुगतान वक्र। प्रीमियम मॉडल अधिक महंगा है और बेहतर नहीं है, कभी-कभी टूल रिकॉल पर भी बदतर होता है (बड़े मॉडल समान रूप से बेहतर एजेंट नहीं होते हैं; मापें, अनुमान न लगाएं)। निर्णय: स्पष्ट।

गहरा परिणाम प्रति-चरण रूटिंग है। एक प्रक्रिया-एम्बेडेड एजेंट एक मॉडल निर्णय नहीं है; यह प्रति चरण एक निर्णय है, क्योंकि ऑर्केस्ट्रेशन लेयर (मेरे बिल्ड में Camunda, लेकिन Temporal, LangGraph, या एक हाथ से बनाया गया Node.js लूप आपको वही सीम देता है) प्रत्येक कार्य को स्वतंत्र रूप से एक मॉडल से बांधता है। यह बहु-मॉडल दर्शन को सक्षम बनाता है जिसे मैं अब हर जुड़ाव में लाता हूँ:

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

प्रक्रिया स्तर पर प्रति केस लागत तब चरणों पर एक भारित योग बन जाती है, और आप कमरे के दूसरे प्रश्न (“प्रति केस इसकी लागत कितनी होगी?”) का उत्तर एक ऐसी संख्या के साथ दे सकते हैं जिसमें कंधे उचकाने के बजाय त्रुटि बार होते हैं।

मूल्यांकन लगातार चलाना

हार्नेस का पहला रन “कौन सा मॉडल” का उत्तर देता है। हर बाद का रन एक अधिक महत्वपूर्ण प्रश्न का उत्तर देता है: “क्या हमने इसे अभी तोड़ा?”

एक प्रक्रिया-एम्बेडेड एजेंट में कम से कम पांच परिवर्तन सतहें होती हैं, और उनमें से हर एक चुपचाप चार अक्षों को स्थानांतरित कर सकती है:

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

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

यह किफायती है क्योंकि गोल्ड सेट छोटा है। बीस परिदृश्य, तीन पुनरावृत्तियाँ, एक मॉडल: यह एक कॉफी-ब्रेक रन है, इतना सस्ता है कि इसे तिमाही तुलनाओं के लिए बचाने के बजाय हर सार्थक परिवर्तन से जोड़ा जा सके। अक्ष 2 से 10-से-30-परिदृश्य अनुशासन केवल लेबल गुणवत्ता के बारे में नहीं है; यह वही है जो निरंतर मूल्यांकन को आर्थिक रूप से उबाऊ बनाता है, जो इसे वास्तव में होने देता है।

यह विधि क्या हल नहीं करती है

ईमानदारी अनुभाग, क्योंकि एक विधि जिस पर आप उसकी सीमाओं से परे भरोसा करते हैं, वह किसी भी विधि से बदतर है।

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

छोटा n आपको रैंकिंग देता है, प्रमाणन नहीं। दस से तीस परिदृश्य विश्वसनीय रूप से मॉडल को रैंक करते हैं और बड़े रिग्रेशन को पकड़ते हैं। यह एक ऑडिट दस्तावेज़ में “94.2 प्रतिशत सटीक” का समर्थन नहीं करेगा; 20 मामलों पर आत्मविश्वास अंतराल व्यापक है, और अन्यथा ढोंग करना कदाचार है। इंजीनियरिंग निर्णयों के लिए हार्नेस का उपयोग करें। यदि एक अनुपालन फ़ंक्शन को एक प्रमाणित सटीकता संख्या की आवश्यकता है, तो वह एक बड़ा, अलग से शासित सैंपलिंग अभ्यास है।

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

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

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

एक-पैराग्राफ संस्करण

चैटबॉट-युग के मूल्यांकन आपको यह नहीं बता सकते कि एक शासित प्रक्रिया में एम्बेडेड एजेंट को कौन सा मॉडल चलाना चाहिए, इसलिए एजेंट को उस तरह से मापें जैसे व्यवसाय इसका अनुभव करेगा: प्रति-फ़ील्ड अपेक्षित आउटपुट और अपेक्षित टूल कॉल के साथ 10 से 30 वास्तविक गुमनाम मामलों का एक गोल्ड सेट बनाएं, फिर प्रत्येक उम्मीदवार मॉडल को चार अक्षों पर स्कोर करें: प्रति प्रक्रिया इंस्टेंस लागत (प्रत्येक लूप पुनरावृत्ति, पुनः प्रयास, और टूल राउंड ट्रिप, प्रति केस रिपोर्ट की गई, जहाँ एक मध्य-स्तरीय मॉडल ने एक बार प्रीमियम मॉडल की लागत के लगभग 1/13वें हिस्से पर मेल खाया), गोल्ड लेबल के खिलाफ प्रति-फ़ील्ड सटीकता (नियतात्मक मिलान, अनुभव नहीं), टूल विश्वसनीयता (स्किप दरें, गलत-टूल चयन, और गलत या भ्रमित तर्क, अनुमानित के बजाय मापा गया, क्योंकि एक चुपचाप छोड़ा गया अनुपालन जाँच डेमो में अदृश्य और उत्पादन में घातक होता है), और तापमान संवेदनशीलता (तापमान शून्य ने मेरे परीक्षणों में टूल की गहनता को बदल दिया, न कि केवल भिन्नता को, इसलिए इसे सुरक्षा नियंत्रण कहने से पहले मापें)। परिणामी गुणवत्ता-की-लागत वक्रों को प्रति-चरण मॉडल रूटिंग में फीड करें, प्रत्येक प्रॉम्प्ट, टूल और मॉडल परिवर्तन पर हार्नेस को एक रिग्रेशन सूट के रूप में फिर से चलाएं, और परिणामों को ढीले ढंग से रखें जहाँ विधि कमजोर है: छोटे गोल्ड सेट मॉडल को रैंक करते हैं लेकिन उन्हें प्रमाणित नहीं करते हैं, और गोल्ड सेट बासी हो जाते हैं।

संदर्भ

• एंथ्रोपिक, “मजबूत अनुभवजन्य मूल्यांकन बनाएं”: docs.anthropic.com/en/docs/build-with-claude/develop-tests
• एंथ्रोपिक, “प्रभावी एजेंट बनाना”: anthropic.com/engineering/building-effective-agents
• ओपनएआई, “इवल्स” गाइड: platform.openai.com/docs/guides/evals
• झेंग एट अल., “एमटी-बेंच और चैटबॉट एरिना के साथ LLM-as-a-Judge का न्याय करना” (न्यायाधीश पूर्वाग्रहों का प्रामाणिक उपचार): arxiv.org/abs/2306.05685
• याओ एट अल., “τ-बेंच: वास्तविक दुनिया के डोमेन में टूल-एजेंट-उपयोगकर्ता इंटरैक्शन के लिए एक बेंचमार्क”: arxiv.org/abs/2406.12045
• बर्कले फंक्शन-कॉलिंग लीडरबोर्ड, सार्वजनिक टूल-कॉलिंग तुलनाओं के लिए (उपयोगी संदर्भ, आपके अपने गोल्ड सेट का विकल्प नहीं): gorilla.cs.berkeley.edu/leaderboard.html
• हैमेल हुसैन, “आपके AI उत्पाद को मूल्यांकन की आवश्यकता है”: hamel.dev/blog/posts/evals
• टूल विश्वसनीयता के स्पेक पक्ष पर सहयोगी मार्गदर्शिका: टूल कॉन्ट्रैक्ट्स
• यह विधि बड़े वित्तीय संस्थानों के साथ उत्पादन प्रूफ-ऑफ-वैल्यू कार्य से निकाली गई थी; जुड़ावों को सामान्यीकृत किया गया है और कोई ग्राहक मूल्यांकन कोड सार्वजनिक नहीं है।