मूल्यांकन ढांचे क्यों बन गए उद्यम AI का सबसे उपेक्षित रणनीतिक संपत्ति
एक पैटर्न बार-बार दोहराया जाता है उन संगठनों में जो पिछले अठारह महीनों से आर्टिफिशियल इंटेलिजेंस एजेंट तैनात कर रहे हैं: वे जानते हैं कि सिस्टम काम करते हैं, क्योंकि उन्होंने उन्हें डेमो में काम करते देखा था। जो वे नहीं जानते वह यह है कि क्या वे आज भी काम कर रहे हैं — प्रोडक्शन में, उनके ग्राहकों के डेटा पर, उन वर्कफ़्लो के भीतर जो वास्तव में मायने रखते हैं। पायलट की निश्चितता और वास्तविक परिवेश की अपारदर्शिता के बीच की यही दूरी है जहाँ बजट, विश्वास और वह समय बर्बाद होता है जो किसी के पास नहीं है।
AI मॉडल मूल्यांकन और बेंचमार्किंग प्लेटफ़ॉर्म का बाज़ार 2025 में 1.6 अरब डॉलर पर आंका गया था और अनुमान है कि यह 2034 तक 19.8 अरब डॉलर तक पहुँचेगा, जिसमें 35.2% की वार्षिक चक्रवृद्धि विकास दर होगी। ये संख्याएँ किसी तकनीकी आला बाजार का वर्णन नहीं करतीं। ये उस सवाल के संस्थागतकरण का वर्णन करती हैं जो कंपनियों को शुरू से ही पूछना चाहिए था: मुझे कैसे पता चलेगा कि यह वास्तव में काम करता है?
इस सवाल का जवाब, कुछ समय पहले तक, असहज करने वाला था। अधिकांश संगठनों ने सार्वजनिक बेंचमार्क पर भरोसा किया जो यह मापते हैं कि कोई मॉडल मानकीकृत परिस्थितियों में कितनी अच्छी तरह से उत्तर देता है। मॉडलों की आपस में तुलना करने के लिए उपयोगी। लेकिन यह जानने के लिए लगभग अप्रासंगिक कि क्या वह मॉडल आपकी कंपनी के चालान सही तरीके से प्रोसेस करता है, सपोर्ट टिकट को उचित रूप से एस्केलेट करता है, या CRM रिकॉर्ड को मूक त्रुटियाँ डाले बिना अपडेट करता है।
चैटबॉट से एजेंट तक: मापने की वस्तु क्यों बदल गई
संवादी AI के बड़े पैमाने पर अपनाए जाने के शुरुआती वर्षों में, केंद्रीय सवाल सरल था: क्या सिस्टम ने सही उत्तर दिया? मूल्यांकक, व्यवहार में, एक इंसान था जो जवाब पढ़ता था और तय करता था कि क्या वह उसे सुसंगत, संपूर्ण और उचित लगता है। यह एक आदिम तरीका था, लेकिन काम करता था क्योंकि सिस्टम भी आदिम थे। वे टेक्स्ट उत्पन्न करते थे। वे कुछ करते नहीं थे।
एजेंट एक अलग श्रेणी हैं। एक AI एजेंट जवाब नहीं देता: वह कार्य करता है। वह APIs को कॉल करता है, डेटाबेस को क्वेरी करता है, रिकॉर्ड अपडेट करता है, वास्तविक सिस्टम पर अनुक्रमिक कदम निष्पादित करता है। एक ही कार्य पूरा करने से पहले वह दर्जनों मध्यवर्ती निर्णय ले सकता है। और हर निष्पादन में बिल्कुल अलग-अलग रास्तों से सही परिणाम तक पहुँच सकता है।
यह चैटबॉट युग से विरासत में मिले मूल्यांकन मॉडल को तोड़ देता है। यदि एजेंट एक ही उद्देश्य को पूरा करने के लिए कई रास्ते अपना सकता है, तो प्रत्येक मध्यवर्ती चरण का मूल्यांकन करना अब परिचालन अर्थ नहीं रखता। जो मायने रखता है वह है एजेंट के कार्य करने के बाद दुनिया की अंतिम स्थिति: क्या बुकिंग सही मापदंडों के साथ दर्ज हुई?, क्या डेटाबेस संबंधित पंक्ति के साथ अपडेट हुआ?, क्या संदेश इंगित चैनल पर भेजा गया? मूल्यांकन चरणों के विश्लेषण से प्रभावों के विश्लेषण की ओर स्थानांतरित होता है।
इस स्थानांतरण का तकनीकी वास्तुकला पर सीधा प्रभाव पड़ता है। प्रभावों को मापने के लिए, आपको एक ऐसे परिवेश की आवश्यकता है जो उन्हें समाहित कर सके: अनुकरण किए गए डेटाबेस, परीक्षण डेटा के साथ कॉन्फ़िगर किए गए उपकरण, एक नियंत्रित "दुनिया" जहाँ एजेंट संचालित हो और जो प्रत्येक कार्य से पहले और बाद की स्थिति की तुलना करने की अनुमति दे। इसे ही मूल्यांकन हार्नेस कहा जाता है — एक नियंत्रित परीक्षण परिवेश जो उन्हें उजागर किए बिना प्रोडक्शन स्थितियों की प्रतिलिपि बनाता है। इसे बनाने के लिए निवेश, जानबूझकर डिज़ाइन और पूर्व परिभाषाओं की आवश्यकता होती है जो कई संगठनों के पास अभी भी नहीं हैं।
समस्या तकनीकी नहीं है। यह प्राथमिकता की है। कंपनियाँ एजेंट बनाने में निवेश करती हैं और व्यवस्थित रूप से इस बात को कम आँकती हैं कि यह जानने में क्या लागत आती है कि वे एजेंट काम करते हैं या नहीं।
बेंचमार्क और व्यवसाय के बीच की खाई
सार्वजनिक बेंचमार्क में एक संरचनात्मक दोष होता है जब उन्हें व्यावसायिक संदर्भों में लागू किया जाता है: वे मॉडलों की तुलना करने के लिए डिज़ाइन किए गए थे, न कि वर्कफ़्लो को मान्य करने के लिए। एक मॉडल गणितीय तर्क में रैंकिंग में शीर्ष पर हो सकता है और उस विशेष प्रारूप के साथ खरीद ऑर्डर के फ़ील्ड प्रोसेस करने में लगातार विफल हो सकता है जो आपका ERP उपयोग करता है।
यह बेंचमार्क के विरुद्ध तर्क नहीं है। यह उन्हें किसी ऐसी चीज़ के विकल्प के रूप में उपयोग करने के विरुद्ध तर्क है जो स्वयं संगठनों को बनानी होती है: अपने वर्कफ़्लो के लिए विशिष्ट मूल्यांकन सेट, ऐसे परीक्षण मामलों के साथ जो उनके उपयोगकर्ताओं के संदर्भ का प्रतिनिधित्व करते हों और अपेक्षित परिणाम सत्यापन योग्य संदर्भ के रूप में कोडीकृत हों।
उस मूल्यांकन सेट का निर्माण करना — जिसे व्यवहार में ग्राउंड ट्रुथ कहा जाता है, वे सही परिणाम जो सिस्टम को उत्पन्न करने चाहिए — शायद पूरी प्रक्रिया का सबसे कम आँका जाने वाला कदम है। इसके लिए आवश्यक है कि व्यवसाय के ज्ञान वाला कोई व्यक्ति बैठे और कार्य-दर-कार्य परिभाषित करे कि सही निष्पादन का क्या अर्थ है। अमूर्त रूप से नहीं। ठोस रूप से: यदि एजेंट फ्लाइट रद्दीकरण प्रोसेस करता है, तो डेटाबेस से कौन सी पंक्ति हटनी चाहिए?, कौन सा संदेश उत्पन्न होना चाहिए?, कौन सा टूल किस पैरामीटर के साथ आमंत्रित होना चाहिए था?
यह विशिष्टता असहज करती है क्योंकि इसमें मानव विशेषज्ञ कार्य की आवश्यकता होती है जिसे शुरुआत से स्वचालित नहीं किया जा सकता। लेकिन यही वह चीज़ है जो बाद के मूल्यांकन प्रणाली को विश्वसनीय बनाती है। उस लंगर के बिना, आप जो भी मेट्रिक उत्पन्न करते हैं वह कुछ न कुछ माप रही है, लेकिन कोई यह सुनिश्चित नहीं कर सकता कि वह व्यवसाय के लिए प्रासंगिक है।
एक डिज़ाइन सिद्धांत भी है जो तब सामने आता है जब मूल्यांकन प्रणाली परिपक्व होती हैं: ग्राउंड ट्रुथ बहुत कठोर नहीं हो सकता। जो एजेंट तर्क करते हैं उनमें समस्याओं को हल करने के नए रास्ते खोजने की क्षमता होती है। एक मूल्यांकन प्रणाली जो अपेक्षित पथ से हर विचलन को दंडित करती है, वह उस क्षमता को सेंसर करना समाप्त कर देती है जिसे आप मापने का दावा कर रहे हैं। चुनौती यह है कि सफलता के मानदंड इतने सटीक हों कि त्रुटियाँ पकड़ी जा सकें और इतने लचीले हों कि वैध विविधता को सहन किया जा सके।
यह संतुलन एक ही समीक्षा से नहीं प्राप्त होता। यह पुनरावृत्त रूप से बनाया जाता है, वास्तविक विफलता के मामलों, उपयोगकर्ता शिकायतों और उन एज-केस परिदृश्यों को शामिल करके जिनका मूल प्रणाली ने अनुमान नहीं लगाया था।
निरंतर मूल्यांकनकर्ता जोखिम की अर्थव्यवस्था को कैसे बदलते हैं
मजबूत मूल्यांकन हार्नेस बनाने के कम चर्चित परिणामों में से एक यह है कि वे परिचालन जोखिम की अर्थव्यवस्था पर क्या करते हैं। जब आपके पास निरंतर मूल्यांकन प्रणाली नहीं होती, तो मॉडल, प्रॉम्प्ट या वर्कफ़्लो में प्रत्येक बदलाव एक दाँव है। आप मैन्युअल रूप से कुछ मामलों का परीक्षण कर सकते हैं, लेकिन कवरेज आंशिक है और परीक्षण की लागत हर नई क्षमता के साथ बढ़ती जाती है जो आप जोड़ते हैं।
एक मूल्यांकन हार्नेस के साथ जो प्रत्येक बदलाव पर स्वचालित रूप से चलता है, जोखिम प्रोफ़ाइल भौतिक रूप से बदल जाती है। रिग्रेशन प्रोडक्शन तक पहुँचने से पहले ही पकड़ी जाती हैं। एक परिदृश्य में व्यवहार सुधारने के लिए प्रॉम्प्ट को समायोजित करते समय जो त्रुटियाँ पेश की गईं, वे उजागर हो जाती हैं यदि वे किसी अन्य परिदृश्य में व्यवहार को खराब करती हैं। टीम अधिक तेज़ी से पुनरावृत्ति कर सकती है, ठीक इसलिए क्योंकि उसे प्रत्येक बदलाव के प्रभाव की तत्काल दृश्यता होती है।
इस यांत्रिकी का एक सीधा वित्तीय परिणाम है। जो संगठन बिना निरंतर मूल्यांकन के प्रोडक्शन में AI तैनात करते हैं, वे उस प्रणाली को बनाने की लागत नहीं बचा रहे हैं: वे उस लागत को अपने ग्राहकों को त्रुटियों के रूप में, सपोर्ट टीम को टिकट के रूप में और प्रबंधन को ऐसी घटनाओं के रूप में हस्तांतरित कर रहे हैं जिन्हें समझाना पड़ता है। लागत वैसे भी मौजूद है। अंतर यह है कि हार्नेस के बिना, यह देर से और दृश्यता के बिना चुकाई जाती है।
अच्छी तरह से बनाई गई मूल्यांकन प्रणालियाँ कुछ ऐसा भी संभव बनाती हैं जो AI टीमें उनके बिना शायद ही कभी कर पाती हैं: निरंतर सुधार प्रदर्शित करना। जब बेंचमार्क परिभाषित हो और मेट्रिक्स का इतिहास मौजूद हो, तो यह दिखाना संभव है कि मॉडल के अंतिम समायोजन के बाद प्रोडक्शन में सटीकता तीन प्रतिशत अंक बढ़ी, या किसी कार्य को पूरा करने का औसत समय पंद्रह सेकंड कम हुआ। ये वे संख्याएँ हैं जो एक CFO पढ़ सकता है और जो AI खर्च को लागत की एक पंक्ति से एक दस्तावेज़ीकृत रिटर्न वाले निवेश में बदल देती हैं।
MLOps प्लेटफ़ॉर्म का बाज़ार, जिसमें निगरानी, तैनाती और मूल्यांकन की बुनियादी संरचना शामिल है, 2026 में 2.8 से 4.5 अरब डॉलर के बीच अनुमानित है और 2032–2035 तक 37,000 से 89,000 अरब डॉलर के बीच लक्षित है। यह पैमाना केवल तकनीकी अपनाने को नहीं दर्शाता। यह दर्शाता है कि संगठन यह समझना शुरू कर रहे हैं कि गुणवत्ता उपकरण के बिना AI संचालित करना महत्वपूर्ण बुनियादी ढाँचे को निगरानी के बिना संचालित करने के समान है। कोई भी प्रोडक्शन सर्वर पर इस पर बहस नहीं करेगा। लेकिन AI एजेंट के साथ, इसे अभी भी समझाना पड़ता है।
वह शासन जो मॉडल से पहले आता है
एजेंटिक AI क्षमताएँ बना रहे संगठनों में एक सामान्य भ्रम है: वे मूल्यांकन को एक अंतिम चरण मानते हैं, कुछ ऐसा जो एक बार सिस्टम तैयार हो जाने के बाद किया जाता है। तर्क उचित लगता है: पहले बनाओ, फिर मापो।
समस्या यह है कि इस बात की पूर्व परिभाषा के बिना निर्माण करना कि सही तरीके से काम करने का क्या अर्थ है, बिना विशिष्टता के निर्माण करना है। और जो सिस्टम बिना विशिष्टता के बनाए जाते हैं वे स्पष्ट और शोरगुल वाले तरीकों से विफल नहीं होते: वे क्रमिक और मूक तरीकों से विफल होते हैं जो तभी दृश्यमान होते हैं जब वे पहले से ही वास्तविक उपयोगकर्ताओं को प्रभावित कर चुके हों।
मूल्यांकन में निवेश को तैनाती से पहले आना होगा, न कि उसके बाद। इसका अर्थ है कि एजेंट की पहली कोड लाइन लिखने से पहले, किसी को सटीकता के साथ उत्तर देने में सक्षम होना होगा: वह कौन से कार्य स्वचालित करेगा, उनमें से प्रत्येक के लिए सफल निष्पादन क्या है, किन उपकरणों को किन परिस्थितियों में आमंत्रित करने की अनुमति है, और किसी ग्राहक तक पहुँचने से पहले त्रुटि का पता कैसे लगाया जाए।
ये सवाल तकनीकी नहीं हैं। ये व्यावसायिक सवाल हैं। और यह तथ्य कि कई इंजीनियरिंग टीमें उन्हें अकेले उत्तर दे रही हैं — उन लोगों को शामिल किए बिना जो स्वचालित होने वाले वर्कफ़्लो को जानते हैं — AI परियोजनाओं के उस बड़े हिस्से की व्याख्या करता है जो ठोस डेमो और निराशाजनक उत्पादन परिणाम देती हैं।
निरंतर मूल्यांकन वह परत नहीं है जो सत्यापित करती है कि सिस्टम काम करता है। यह वह परत है जो संगठन को यह परिभाषित करने के लिए मजबूर करती है कि काम करने का क्या अर्थ है, इतनी सटीकता के साथ कि एक मशीन इसे सत्यापित कर सके। वह सटीकता स्वयं में एक संपत्ति है। जो संगठन इसे बनाते हैं वे अपने स्वयं के वर्कफ़्लो की एक समझ विकसित करते हैं जो उनके पास पहले शायद ही कभी दस्तावेज़ीकृत थी। और वह समझ ही है जो आत्मविश्वास के साथ एजेंट को स्केल करने की अनुमति देती है — मॉडल में विश्वास नहीं।
मॉडल प्रतिस्थापन योग्य है। यह विशिष्टता कि उसे क्या करना है, और जो प्रणाली सत्यापित करती है कि वह ऐसा कर रहा है — वे नहीं हैं।
