एआई मॉडल का परीक्षण कैसे करें

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

चाबी छीनना:

सफलता के मानदंड : मेट्रिक्स चुनने से पहले उपयोगकर्ताओं, निर्णयों, बाधाओं और सबसे खराब स्थिति में होने वाली विफलताओं को परिभाषित करें।

पुनरावर्तनीयता : एक ऐसा मूल्यांकन तंत्र बनाएं जो प्रत्येक परिवर्तन के साथ तुलनीय परीक्षणों को पुनः चलाए।

डेटा स्वच्छता : स्थिर विभाजन बनाए रखें, डुप्लिकेट को रोकें और फीचर लीकेज को शुरुआती चरण में ही रोकें।

विश्वास जांच : स्पष्ट मानदंडों के साथ मजबूती, निष्पक्षता के स्तर और एलएलएम सुरक्षा व्यवहारों का तनाव-परीक्षण।

जीवनचक्र अनुशासन : चरणों में लागू करें, विचलन और घटनाओं की निगरानी करें, और ज्ञात कमियों का दस्तावेजीकरण करें।

इस लेख के बाद आप ये लेख भी पढ़ सकते हैं:

🔗 एआई नैतिकता क्या है?
जिम्मेदार एआई डिजाइन, उपयोग और शासन को निर्देशित करने वाले सिद्धांतों का अन्वेषण करें।.

🔗 एआई पूर्वाग्रह क्या है?
जानिए कैसे पक्षपातपूर्ण डेटा एआई के निर्णयों और परिणामों को प्रभावित करता है।.

🔗 AI स्केलेबिलिटी क्या है?
प्रदर्शन, लागत और विश्वसनीयता के लिए एआई सिस्टम को स्केल करने की प्रक्रिया को समझें।.

🔗 एआई क्या है?
कृत्रिम बुद्धिमत्ता, इसके प्रकार और वास्तविक दुनिया में इसके उपयोगों का स्पष्ट अवलोकन।.

1) "अच्छा" की उस परिभाषा से शुरुआत करें जो ग्लैमरस नहीं है।

मैट्रिक्स से पहले, डैशबोर्ड से पहले, किसी भी तरह के बेंचमार्क का प्रदर्शन करने से पहले - तय करें कि सफलता कैसी दिखती है।.

स्पष्ट करना:

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

यही वह चरण है जहाँ टीमें सार्थक परिणाम के बजाय दिखावटी मापदंडों को प्राथमिकता देने में लग जाती हैं। ऐसा अक्सर होता है। मतलब... बहुत बार।.

इस जोखिम के प्रति जागरूक रहने का एक ठोस तरीका (और वाइब्स-आधारित नहीं) परीक्षण को भरोसेमंदता और जीवनचक्र जोखिम प्रबंधन के इर्द-गिर्द तैयार करना है, जिस तरह से एनआईएसटी एआई जोखिम प्रबंधन फ्रेमवर्क (एआई आरएमएफ 1.0) [1] में करता है।

2) एआई मॉडल का परीक्षण कैसे करें, इसका एक अच्छा संस्करण क्या बनाता है? ✅

एक ठोस परीक्षण पद्धति में कुछ ऐसी बातें होती हैं जिन पर समझौता नहीं किया जा सकता:

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

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

दो दस्तावेज़ीकरण पैटर्न जो टीमों को लगातार स्पष्टवादी बने रहने में मदद करते हैं:

मॉडल कार्ड (मॉडल किस लिए है, इसका मूल्यांकन कैसे किया गया, यह कहाँ विफल होता है) [2]
डेटासेट के लिए डेटाशीट (डेटा क्या है, इसे कैसे एकत्र किया गया था, इसका उपयोग किस लिए किया जाना चाहिए/नहीं किया जाना चाहिए) [3]

3) उपकरणों की वास्तविकता: लोग व्यवहार में किन उपकरणों का उपयोग करते हैं 🧰

उपकरण वैकल्पिक हैं। लेकिन अच्छे मूल्यांकन की आदतें अनिवार्य हैं।.

यदि आप एक व्यावहारिक व्यवस्था चाहते हैं, तो अधिकांश टीमों के पास अंततः तीन बाल्टियाँ होती हैं:

प्रयोगों की ट्रैकिंग (रन, कॉन्फ़िगरेशन, आर्टिफैक्ट)
मूल्यांकन उपकरण (पुनरावर्तनीय ऑफ़लाइन परीक्षण + प्रतिगमन सूट)
निगरानी (अस्थिरता संकेत, प्रदर्शन प्रॉक्सी, घटना संबंधी अलर्ट)

आपको अक्सर ये उदाहरण देखने को मिलेंगे (ये किसी का समर्थन नहीं है, और हाँ - सुविधाएँ/कीमतें बदलती रहती हैं): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith।.

यदि आप इस अनुभाग से विचार एक दोहराने योग्य मूल्यांकन प्रणाली बनाएं । आप चाहते हैं कि "बटन दबाएं → तुलनीय परिणाम प्राप्त करें", न कि "नोटबुक को दोबारा चलाएं और प्रार्थना करें।"

4) सही टेस्ट सेट बनाएं (और डेटा लीक होने से रोकें) 🚧

चौंकाने वाली बात यह है कि कई "बेहतरीन" मॉडल अनजाने में धोखाधड़ी कर रही हैं।.

मानक एमएल के लिए

कुछ ऐसे नियम जो देखने में भले ही आकर्षक न लगें, लेकिन करियर बचा सकते हैं:

ट्रेन/वैलिडेशन/टेस्ट रखें (और विभाजन तर्क को लिख लें)
विभाजन के दौरान डुप्लिकेट को रोकें (एक ही उपयोगकर्ता, एक ही दस्तावेज़, एक ही उत्पाद, लगभग डुप्लिकेट)।
फीचर लीक (भविष्य की जानकारी का वर्तमान फीचर्स में चुपके से शामिल हो जाना) पर नज़र रखें।
बेसलाइन (डमी अनुमानक) का उपयोग करें ताकि आप कुछ भी नहीं हराने का जश्न न मनाएं [4]

लीकेज की परिभाषा (संक्षिप्त रूप में): प्रशिक्षण/मूल्यांकन के दौरान कोई भी ऐसी चीज़ जो मॉडल को ऐसी जानकारी तक पहुँच प्रदान करती है जो निर्णय लेने के समय उसके पास नहीं होती। यह स्पष्ट ("भविष्य का लेबल") या सूक्ष्म ("घटना के बाद का टाइमस्टैम्प बकेट") हो सकता है।

एलएलएम और जनरेटिव मॉडल के लिए

आप एक त्वरित प्रतिक्रिया और नीति प्रणाली का , न कि केवल "एक मॉडल" का।

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

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

5) ऑफ़लाइन मूल्यांकन: ऐसे मापदंड जिनका कुछ महत्व हो 📏

मापदंड ठीक हैं। लेकिन मापदंड पर ही निर्भर रहना ठीक नहीं है।.

वर्गीकरण (स्पैम, धोखाधड़ी, इरादा, छँटाई)

सटीकता से अधिक का उपयोग करें।.

परिशुद्धता, रिकॉल, F1
थ्रेशोल्ड ट्यूनिंग (आपका डिफ़ॉल्ट थ्रेशोल्ड आपकी लागतों के लिए शायद ही कभी "सही" होता है) [4]
प्रत्येक खंड (क्षेत्र, डिवाइस प्रकार, उपयोगकर्ता समूह) के लिए भ्रम मैट्रिक्स

प्रतिगमन (पूर्वानुमान, मूल्य निर्धारण, स्कोरिंग)

MAE / RMSE (त्रुटियों को दंडित करने के तरीके के आधार पर चुनें)
आउटपुट को "स्कोर" के रूप में उपयोग करते समय अंशांकन संबंधी जांच (क्या स्कोर वास्तविकता से मेल खाते हैं?)

रैंकिंग / अनुशंसा प्रणाली

एनडीसीजी, एमएपी, एमआरआर
क्वेरी प्रकार के आधार पर विभाजित करें (हेड बनाम टेल)

कंप्यूटर दृष्टि

मैप, आईओयू
प्रत्येक कक्षा में प्रदर्शन (कुछ ही कक्षाएं ऐसी होती हैं जिनमें मॉडल आपको शर्मिंदा करते हैं)

जनरेटिव मॉडल (एलएलएम)

यहीं पर लोग दार्शनिक बातें करने लगते हैं 😵💫

वास्तविक टीमों में कारगर साबित होने वाले व्यावहारिक विकल्प:

मानव मूल्यांकन (सर्वोत्तम संकेत, सबसे धीमा लूप)
जोड़ीदार वरीयता / जीत दर (A बनाम B का मूल्यांकन करना पूर्ण स्कोरिंग से आसान है)
स्वचालित टेक्स्ट मेट्रिक्स (कुछ कार्यों के लिए उपयोगी, दूसरों के लिए भ्रामक)
कार्य-आधारित जाँच: “क्या इसने सही फ़ील्ड निकाले?” “क्या इसने नीति का पालन किया?” “क्या इसने आवश्यकता पड़ने पर स्रोतों का उल्लेख किया?”

यदि आप एक संरचित "बहु-मीट्रिक, कई-परिदृश्य" संदर्भ बिंदु चाहते हैं, तो HELM एक अच्छा एंकर है: यह स्पष्ट रूप से मूल्यांकन को सटीकता से परे अंशांकन, मजबूती, पूर्वाग्रह/विषाक्तता और दक्षता ट्रेड-ऑफ जैसी चीजों में धकेल देता है [5]।.

विषयांतर करते हुए, लेखन की गुणवत्ता मापने के स्वचालित तरीके कभी-कभी सैंडविच का वजन करके उसका मूल्यांकन करने जैसे लगते हैं। यह कोई छोटी बात नहीं है, लेकिन... हद है!

6) मजबूती परीक्षण: इसे थोड़ा पसीना बहाने दें 🥵🧪

यदि आपका मॉडल केवल साफ-सुथरे इनपुट पर ही काम करता है, तो यह मूल रूप से एक कांच के फूलदान जैसा है। सुंदर, नाजुक, महंगा।.

परीक्षा:

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

एलएलएम के लिए, निम्नलिखित शामिल करें:

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

मजबूती उन भरोसेमंद गुणों में से एक है जो घटनाओं के घटित होने तक अमूर्त प्रतीत होता है। फिर यह बहुत ही मूर्त हो जाता है [1]।.

7) पक्षपात, निष्पक्षता और यह किसके लिए काम करता है ⚖️

एक मॉडल समग्र रूप से "सटीक" हो सकता है, लेकिन विशिष्ट समूहों के लिए लगातार खराब प्रदर्शन कर सकता है। यह कोई मामूली त्रुटि नहीं है। यह उत्पाद और भरोसे से जुड़ी समस्या है।.

व्यावहारिक कदम:

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

यदि आप इसे कहीं दस्तावेज़ित नहीं कर रहे हैं, तो आप मूल रूप से भविष्य में स्वयं को बिना किसी मानचित्र के विश्वास संकट से निपटने के लिए कह रहे हैं। मॉडल कार्ड इसे रखने के लिए एक ठोस जगह है [2], और NIST का भरोसेमंदता ढांचा आपको एक मजबूत चेकलिस्ट देता है कि "अच्छा" में क्या शामिल होना चाहिए [1]।.

8) सुरक्षा और संरक्षा परीक्षण (विशेष रूप से एलएलएम के लिए) 🛡️

यदि आपका मॉडल कंटेंट जनरेट कर सकता है, तो आप सिर्फ सटीकता का परीक्षण नहीं कर रहे हैं। आप व्यवहार का परीक्षण कर रहे हैं।.

निम्नलिखित के लिए परीक्षण शामिल करें:

प्रतिबंधित सामग्री निर्माण (नीति का उल्लंघन)
निजता का रिसाव (क्या यह रहस्यों की प्रतिध्वनि है?)
उच्च जोखिम वाले क्षेत्रों में मतिभ्रम
अत्यधिक अस्वीकृति (मॉडल सामान्य अनुरोधों को अस्वीकार करता है)
विषाक्तता और उत्पीड़न के परिणाम
शीघ्र इंजेक्शन के माध्यम से डेटा निष्कासन का प्रयास

एक व्यावहारिक दृष्टिकोण यह है: नीति नियम परिभाषित करें → परीक्षण संकेत तैयार करें → मानव और स्वचालित जांच के माध्यम से परिणामों का मूल्यांकन करें → जब भी कुछ परिवर्तन हो, इसे चलाएं। यही "हर बार" वाला हिस्सा सबसे महत्वपूर्ण है।.

यह जीवनचक्र जोखिम मानसिकता में अच्छी तरह से फिट बैठता है: शासन करें, संदर्भ का मानचित्रण करें, मापें, प्रबंधित करें, दोहराएँ [1]।.

9) ऑनलाइन परीक्षण: चरणबद्ध तरीके से शुरू करना (जहाँ सच्चाई छिपी है) 🚀

ऑफलाइन परीक्षण आवश्यक हैं। ऑनलाइन माध्यम में ही वास्तविकता गंदे जूतों में दिखाई देती है।.

आपको दिखावा करने की जरूरत नहीं है। आपको बस अनुशासित रहने की जरूरत है:

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

भले ही आपको तुरंत लेबल न मिलें, आप प्रॉक्सी सिग्नल और परिचालन स्वास्थ्य (विलंबता, विफलता दर, लागत) की निगरानी कर सकते हैं। मुख्य बिंदु: आप से पहले [1]।

10) तैनाती के बाद निगरानी: विचलन, क्षय और मौन विफलता 📉👀

आपने जिस मॉडल का परीक्षण किया, ज़रूरी नहीं कि वही मॉडल आपको अंत में इस्तेमाल करना पड़े। डेटा बदलता है। उपयोगकर्ता बदलते हैं। दुनिया बदलती है। पाइपलाइन रात के 2 बजे भी ठप हो सकती है। आप जानते ही हैं कि ऐसा कैसे होता है..

निगरानी करना:

इनपुट डेटा में विचलन (स्कीमा में परिवर्तन, डेटा की कमी, वितरण में बदलाव)
परिणाम विचलन (कक्षा संतुलन में बदलाव, अंकों में बदलाव)
प्रदर्शन प्रॉक्सी (क्योंकि लेबल विलंब वास्तविक होते हैं)
प्रतिक्रिया संकेत (अस्वीकृति, पुनः संपादन, शिकायत निवारण)
खंड-स्तरीय प्रतिगमन (मूक हत्यारे)

और अलर्ट की सीमाएँ इस प्रकार निर्धारित करें कि वे बहुत ज़्यादा संवेदनशील न हों। लगातार बजने वाला मॉनिटर अनदेखा कर दिया जाता है - जैसे शहर में कार का अलार्म।.

यह “समय के साथ निगरानी करना और सुधार करना” चक्र वैकल्पिक नहीं है यदि आप विश्वसनीयता की परवाह करते हैं [1]।.

11) एक व्यावहारिक कार्यप्रणाली जिसे आप अपना सकते हैं 🧩

यहां एक सरल लूप है जो स्केल करने योग्य है:

सफलता + विफलता मोड को परिभाषित करें (लागत/विलंबता/सुरक्षा सहित) [1]
डेटासेट बनाएं:
- स्वर्ण सेट
- एज-केस पैक
- हाल के वास्तविक नमूने (गोपनीयता सुरक्षित)
मापदंड चुनें:
- कार्य मैट्रिक्स (F1, MAE, जीत दर) [4][5]
- सुरक्षा मेट्रिक्स (नीति उत्तीर्ण दर) [1][5]
- परिचालन संबंधी मापदंड (विलंबता, लागत)
एक मूल्यांकन हार्नेस बनाएं (हर मॉडल/प्रॉम्प्ट परिवर्तन पर चलता है) [4][5]
तनाव परीक्षण + प्रतिकूल परीक्षण जोड़ें [1][5]
नमूने के लिए मानवीय समीक्षा (विशेष रूप से एलएलएम आउटपुट के लिए) [5]
छाया + चरणबद्ध रोलआउट के माध्यम से जहाज [1]
अनुशासन के साथ निगरानी करें + सतर्क करें + पुनः प्रशिक्षण दें [1]
दस्तावेज़ के परिणामस्वरूप मॉडल-कार्ड शैली का विवरण [2][3] प्राप्त होता है

प्रशिक्षण आकर्षक होता है। परीक्षण करना सिर्फ आय का एक साधन है।.

12) समापन टिप्पणी + संक्षिप्त सारांश 🧠✨

एआई मॉडल का परीक्षण करने के तरीके के बारे में केवल कुछ ही बातें याद हैं :

प्रतिनिधि परीक्षण डेटा का उपयोग करें और रिसाव से बचें [4]
कई मेट्रिक्स चुनें [4][5]
एलएलएम के लिए, मानव समीक्षा + जीत-दर शैली तुलना [5]
परीक्षण मजबूती - असामान्य इनपुट सामान्य इनपुट का ही दूसरा रूप हैं [1]
सुरक्षित रूप से रोल आउट करें और निगरानी करें, क्योंकि मॉडल विचलित होते हैं और पाइपलाइन टूट जाती हैं [1]
आपने क्या परीक्षण किया और क्या परीक्षण नहीं किया, उसे दस्तावेज़ करें (असुविधाजनक लेकिन शक्तिशाली) [2][3]

टेस्टिंग का मतलब सिर्फ "यह साबित करना कि यह काम करता है" नहीं है। इसका मतलब है "उपयोगकर्ताओं के जानने से पहले ही यह पता लगाना कि इसमें क्या कमियां हैं।" और हां, यह सुनने में उतना आकर्षक नहीं लगता - लेकिन यही वह हिस्सा है जो सिस्टम को तब संभाले रखता है जब हालात डांवाडोल हो जाते हैं... 🧱🙂

अक्सर पूछे जाने वाले प्रश्न

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

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

मूल्यांकन मापदंडों का चयन करने से पहले सफलता के मानदंडों को परिभाषित करना

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

मॉडल मूल्यांकन में डेटा लीक और अनजाने में होने वाली धोखाधड़ी को रोकना

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

मूल्यांकन प्रणाली में क्या-क्या शामिल होना चाहिए ताकि परीक्षणों को परिवर्तनों के दौरान दोहराया जा सके

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

सटीकता से परे एआई मॉडल के परीक्षण के लिए मेट्रिक्स

कई मेट्रिक्स का उपयोग करें, क्योंकि एक ही संख्या महत्वपूर्ण ट्रेड-ऑफ को छिपा सकती है। वर्गीकरण के लिए, प्रेसिजन/रिकॉल/F1 को थ्रेशोल्ड ट्यूनिंग और सेगमेंट के अनुसार कन्फ्यूजन मैट्रिक्स के साथ मिलाएं। रिग्रेशन के लिए, त्रुटियों को दंडित करने के तरीके के आधार पर MAE या RMSE चुनें, और जब आउटपुट स्कोर की तरह काम करते हैं तो कैलिब्रेशन-शैली की जांच जोड़ें। रैंकिंग के लिए, NDCG/MAP/MRR का उपयोग करें और असमान प्रदर्शन को पकड़ने के लिए हेड बनाम टेल क्वेरी द्वारा स्लाइस करें।.

स्वचालित मेट्रिक्स के अपर्याप्त होने पर एलएलएम आउटपुट का मूल्यांकन करना

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

शोरगुल वाले इनपुट पर मॉडल के विफल न होने के लिए मजबूती परीक्षण चलाए जाने चाहिए।

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

सैद्धांतिक उलझनों में फंसे बिना पूर्वाग्रह और निष्पक्षता संबंधी मुद्दों की जांच करना

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

जनरेटिव एआई और एलएलएम सिस्टम के लिए सुरक्षा और संरक्षा परीक्षण शामिल किए जाने चाहिए।

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

लॉन्च के बाद एआई मॉडल को लागू करना और उसकी निगरानी करना ताकि कमियों और घटनाओं का पता लगाया जा सके।

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

संदर्भ

[1] एनआईएसटी - कृत्रिम बुद्धिमत्ता जोखिम प्रबंधन ढांचा (एआई आरएमएफ 1.0) (पीडीएफ)
[2] मिशेल एट अल. - "मॉडल रिपोर्टिंग के लिए मॉडल कार्ड" (arXiv:1810.03993)
[3] गेब्रू एट अल. - "डेटासेट के लिए डेटाशीट" (arXiv:1803.09010)
[4] scikit-learn - "मॉडल चयन और मूल्यांकन" प्रलेखन
[5] लियांग एट अल. - "भाषा मॉडल का समग्र मूल्यांकन" (arXiv:2211.09110)

आधिकारिक एआई असिस्टेंट स्टोर पर नवीनतम एआई खोजें

हमारे बारे में

ब्लॉग पर वापस जाएँ

देश/क्षेत्र