6.8 एआई मूल्यांकन और परीक्षण

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

ईवल-चालित विकास अपनाएँ

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

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

ऑफ़लाइन और ऑनलाइन मूल्यांकन को अलग रखें, और दोनों इस्तेमाल करें

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

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

प्रतिनिधि ईवल-सेट बनाएँ और संदूषण से बचें

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

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

काम के आकार से मेल खाते मेट्रिक्स चुनें

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

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

एलएलएम-को-न्यायाधीश इस्तेमाल करें, पर इसे मनुष्यों के मुक़ाबले कैलिब्रेट करें

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

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

ग्राउंड-ट्रुथ के लिए मनुष्यों को लूप में रखें

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

सुरक्षा और शत्रुतापूर्ण मज़बूती के लिए रेड-टीम करें

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

एजेंटों का मूल्यांकन छोर-से-छोर कार्य-सफलता से करें

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

मूल्यांकनों को सीआई में जोड़ें और उत्पादन की निगरानी करें

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

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

मूल्यांकन-दृष्टिकोण	फ़ायदे	नुक़सान	कब सबसे अच्छा
मानव-मूल्यांकन	सबसे ऊँची निष्ठा, बारीक़ियाँ पकड़ता है	धीमा, महँगा, स्केल करना कठिन	ग्राउंड-ट्रुथ, ऊँचे-दाँव, न्यायाधीशों को कैलिब्रेट करना
एलएलएम-को-न्यायाधीश	तेज़, सस्ता, बड़े सेटों तक स्केल करता है	पूर्वाग्रहग्रस्त, कैलिब्रेशन चाहिए	जेनेरेटिव आउटपुट पर बार-बार ऑफ़लाइन रन
संदर्भ-आधारित मेट्रिक्स (BLEU, ROUGE)	सस्ते, निर्धारणवादी, दोहराने-योग्य	असली गुणवत्ता का कमज़ोर प्रॉक्सी	मोटे रिग्रेशन-संकेत, अंतिम फ़ैसले नहीं
क्लासिक मेट्रिक्स (सटीकता, स्मरण, एफ़-स्कोर)	वस्तुनिष्ठ, अच्छी तरह समझे गए	सिर्फ़ सही लेबल वाले कामों में फ़िट	वर्गीकरण, निष्कर्षण, पुनर्प्राप्ति
सार्वजनिक बेंचमार्क	मॉडलों में तुलना-योग्य, कोई सेटअप नहीं	संदूषण, आपके काम से ख़राब फ़िट	प्रारंभिक मॉडल-शॉर्टलिस्टिंग, रिलीज़-गेट नहीं
ऑनलाइन मूल्यांकन (ए/बी, फ़ीडबैक)	असली उपयोगकर्ताओं और नतीजों को दर्शाता है	धीमा, उजागर होने के बाद आता है	पुष्टि करना कि किसी बदलाव ने वाक़ई मदद की

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

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

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

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

4. आज कौन-से एआई-बदलाव मूल्यांकन पर गेटेड हैं, और कौन-से अब भी किसी की सहज-आत्मविश्वास मात्र पर उपयोगकर्ताओं तक पहुँचते हैं? कोई गेट जो कुछ बदलावों पर चलता है पर दूसरों पर नहीं, आपको सुरक्षा का भ्रम देता है जबकि असली रिग्रेशन बिना गेट वाले रास्ते से फिसल जाते हैं: कोई चुपचाप प्रॉम्प्ट-बदलाव, कोई पुनर्प्राप्ति-ट्यूनिंग, कोई मॉडल-वर्शन बदलाव जिसे किसी ने बदलाव गिना ही नहीं। बड़ी टीम के लिए, ख़तरा उन लोगों की संख्या के साथ बढ़ता है जो किसी प्रॉम्प्ट को छू सकते हैं, क्योंकि हर बिना-गेट वाला रास्ता किसी ऐसे रिग्रेशन को शिप करने का तरीक़ा है जिसे किसी डेटासेट ने कभी नहीं देखा। सतत एकीकरण में वर्तमान में ऑफ़लाइन सूट को ट्रिगर करने वाले बदलाव-प्रकारों की सूची, जो नहीं करते, और किसी बिना-गेट बदलाव से जुड़ी पिछली कुछ घटनाएँ लाएँ। तय करें कि गेट कौन-सी सीमा और रुझान लागू करता है, क्योंकि कोई शोर-युक्त स्कोर परफ़ेक्ट रन की माँग के बजाय एक फ़र्श और एक रिग्रेशन-मार्जिन माँगता है। उद्यम और सरकारी परिवेश में, गेट को रिलीज़-रिकॉर्ड से ही जोड़ें, ताकि किसी बदलाव के मापे जाने का प्रमाण ऑडिट-ट्रेल का हिस्सा हो, किसी का एक बार लिया गया स्क्रीनशॉट नहीं।

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

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

क्षेत्र-लेंस

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

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

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

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

उदाहरण

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

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

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

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

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

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

एंटी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• चिप ह्युएन, एआई इंजीनियरिंग: बिल्डिंग एप्लिकेशन्स विद फ़ाउंडेशन मॉडल्स।
• लियानमिन झेंग एट अल., जजिंग एलएलएम-एज़-अ-जज विद एमटी-बेंच एंड चैटबॉट एरीना।
• किशोर पापिनेनी एट अल., BLEU: अ मेथड फ़ॉर ऑटोमैटिक इवैल्यूएशन ऑफ़ मशीन ट्रांसलेशन।
• चिन-यू लिन, ROUGE: अ पैकेज फ़ॉर ऑटोमैटिक इवैल्यूएशन ऑफ़ समरीज़।
• पर्सी लियांग एट अल., होलिस्टिक इवैल्यूएशन ऑफ़ लैंग्वेज मॉडल्स (HELM)।
• डीप गांगुली एट अल., रेड टीमिंग लैंग्वेज मॉडल्स टू रिड्यूस हार्म्स: मेथड्स, स्केलिंग बिहेवियर्स, एंड लेसन्स लर्न्ड।
• OWASP फ़ाउंडेशन, OWASP टॉप 10 फ़ॉर लार्ज लैंग्वेज मॉडल एप्लिकेशन्स।
• नेशनल इंस्टीट्यूट ऑफ़ स्टैंडर्ड्स एंड टेक्नोलॉजी, एआई रिस्क मैनेजमेंट फ़्रेमवर्क।