बधाई हो! आपने यूनीकॉर्न मॉडल डिप्लॉय किया हो. आपका मॉडल बिना किसी समस्या के 24x7 चलना चाहिए. यह पक्का करने के लिए कि ऐसा हो रहा है, आपको अपनी मशीन लर्निंग (एमएल) पाइपलाइन पर नज़र रखनी होगी.
रॉ डेटा की पुष्टि करने के लिए डेटा स्कीमा लिखना
अपने डेटा को मॉनिटर करने के लिए, आपको उसे उम्मीद के मुताबिक आंकड़ों की वैल्यू के साथ लगातार जांचना चाहिए. इसके लिए, आपको ऐसे नियम लिखने होंगे जिनका डेटा पालन करता हो. नियमों के इस कलेक्शन को डेटा स्कीमा कहा जाता है. डेटा स्कीमा तय करने के लिए, यह तरीका अपनाएं:
अपनी सुविधाओं की रेंज और डिस्ट्रिब्यूशन को समझें. कैटगरी वाली वैल्यू के लिए, संभावित वैल्यू के सेट को समझें.
अपनी समझ को डेटा स्कीमा में कोड में बदलें. यहां नियमों के कुछ उदाहरण दिए गए हैं:
- पक्का करें कि उपयोगकर्ताओं की सबमिट की गई रेटिंग हमेशा 1 से 5 के बीच हो.
- देखें कि अंग्रेज़ी टेक्स्ट की सुविधा के लिए, the शब्द सबसे ज़्यादा बार इस्तेमाल हुआ है या नहीं.
- देखें कि हर कैटगरी वाली सुविधा, संभावित वैल्यू के तय किए गए सेट में से किसी वैल्यू पर सेट की गई है या नहीं.
अपने डेटा की जांच, डेटा स्कीमा के हिसाब से करें. आपके स्कीमा में डेटा से जुड़ी ये गड़बड़ियां दिखनी चाहिए:
- अनियमितताएं
- कैटगरी वाले वैरिएबल की अनचाही वैल्यू
- डेटा के अनचाहे डिस्ट्रिब्यूशन
सुविधा इंजीनियरिंग की पुष्टि करने के लिए यूनिट टेस्ट लिखना
आपका रॉ डेटा, डेटा स्कीमा की शर्तें पूरी कर सकता है. हालांकि, आपका मॉडल रॉ डेटा पर ट्रेन नहीं होता. इसके बजाय, आपका मॉडल उस डेटा पर ट्रेनिंग लेता है जिसे फ़ीचर इंजीनियर किया गया है. उदाहरण के लिए, आपका मॉडल, रॉ संख्यात्मक डेटा के बजाय, सामान्य संख्यात्मक सुविधाओं पर ट्रेनिंग लेता है. फ़ीचर इंजीनियर किया गया डेटा, रॉ इनपुट डेटा से काफ़ी अलग हो सकता है. इसलिए, आपको रॉ इनपुट डेटा की जांच करने के अलावा, फ़ीचर इंजीनियर किए गए डेटा की अलग से जांच करनी होगी.
फ़ीचर इंजीनियर किए गए डेटा की समझ के आधार पर यूनिट टेस्ट लिखें. उदाहरण के लिए, यूनिट टेस्ट लिखकर इन स्थितियों की जांच की जा सकती है:
- सभी संख्या वाली सुविधाओं को स्केल किया जाता है. उदाहरण के लिए, 0 से 1 के बीच.
- वन-हॉट कोड में बदले गए वेक्टर में सिर्फ़ एक 1 और N-1 शून्य होते हैं.
- ट्रांसफ़ॉर्मेशन के बाद डेटा डिस्ट्रिब्यूशन, उम्मीद के मुताबिक हो. उदाहरण के लिए, अगर आपने Z-स्कोर का इस्तेमाल करके नॉर्मलाइज़ किया है, तो Z-स्कोर का औसत 0 होना चाहिए.
- आउटलायर को मैनेज किया जाता है. जैसे, स्केलिंग या क्लिपिंग.
अहम डेटा स्लाइस के लिए मेट्रिक देखना
कभी-कभी, पूरे डेटा सेट के काम करने की वजह से, काम न करने वाले सबसेट को छिपा दिया जाता है. दूसरे शब्दों में, ऐसा हो सकता है कि बेहतर मेट्रिक वाला मॉडल भी कुछ स्थितियों के लिए गलत अनुमान लगाए. उदाहरण के लिए:
आपका यूनिकॉर्न मॉडल, कुल मिलाकर अच्छा परफ़ॉर्म करता है. हालांकि, सहारा रेगिस्तान के लिए अनुमान लगाते समय, इसकी परफ़ॉर्मेंस खराब होती है.
अगर आप ऐसे इंजीनियर हैं जो कुल मिलाकर बेहतरीन AUC से संतुष्ट हैं, तो हो सकता है कि आपको सहारा रेगिस्तान में मॉडल की समस्याएं न दिखें. अगर हर इलाके के लिए अच्छे अनुमान लगाना ज़रूरी है, तो आपको हर इलाके के लिए परफ़ॉर्मेंस ट्रैक करनी होगी. डेटा के सबसेट, जैसे कि सहारा रेगिस्तान से जुड़े डेटा को डेटा स्लाइस कहा जाता है.
अपनी पसंद के डेटा स्लाइस की पहचान करना. इसके बाद, इन डेटा स्लाइस के लिए मॉडल मेट्रिक की तुलना, अपने पूरे डेटासेट की मेट्रिक से करें. यह जांचने से कि आपका मॉडल सभी डेटा स्लाइस में अच्छा परफ़ॉर्म करता है, पक्षपात को हटाने में मदद मिलती है. ज़्यादा जानकारी के लिए, निष्पक्षता: पक्षपात का आकलन करना देखें.
असल दुनिया की मेट्रिक का इस्तेमाल करना
ज़रूरी नहीं है कि मॉडल मेट्रिक, आपके मॉडल के असल असर को मेज़र करें. उदाहरण के लिए, किसी हाइपरपैरामीटर में बदलाव करने से मॉडल का AUC बढ़ सकता है, लेकिन इस बदलाव का उपयोगकर्ता अनुभव पर क्या असर पड़ा? असल दुनिया में होने वाले असर को मेज़र करने के लिए, आपको अलग-अलग मेट्रिक तय करनी होंगी. उदाहरण के लिए, अपने मॉडल के उपयोगकर्ताओं के बारे में सर्वे किया जा सकता है, ताकि यह पुष्टि की जा सके कि मॉडल के अनुमान के मुताबिक, उन्हें सचमुच यूनिकॉर्न दिखे या नहीं.
ट्रेनिंग और ब्राउज़र में वेब पेज खोलने के दौरान परफ़ॉर्मेंस में अंतर की जांच करना
ट्रेनिंग और सर्विंग में डेटा का अंतर का मतलब है कि ट्रेनिंग के दौरान इस्तेमाल किया गया इनपुट डेटा, सर्विंग के दौरान इस्तेमाल किए गए इनपुट डेटा से अलग है. नीचे दी गई टेबल में, स्क्वीयर के दो अहम टाइप के बारे में बताया गया है:
| टाइप | परिभाषा | उदाहरण | समाधान |
|---|---|---|---|
| स्कीमा स्क्यू | ट्रेनिंग और इनपुट डेटा, एक ही स्कीमा के मुताबिक नहीं है. | आपका मॉडल पुराने डेटा पर ट्रेनिंग जारी रखता है, जबकि दिखाए जा रहे डेटा का फ़ॉर्मैट या डिस्ट्रिब्यूशन बदल जाता है. | ट्रेनिंग और डेटा दिखाने की पुष्टि करने के लिए, एक ही स्कीमा का इस्तेमाल करें. पक्का करें कि आपने उन आंकड़ों की अलग से जांच की हो जिनकी जांच आपके स्कीमा ने नहीं की है. जैसे, छूटी हुई वैल्यू का हिस्सा |
| सुविधा का स्क्यू | इंजीनियर किया गया डेटा, ट्रेनिंग और सर्विंग के बीच अलग-अलग होता है. | ट्रेनिंग और सर्विंग के बीच फ़ीचर इंजीनियरिंग कोड अलग-अलग होता है. इससे, इंजीनियर किया गया अलग-अलग डेटा जनरेट होता है. | स्कीमा स्क्वीयर की तरह ही, एआई को ट्रेनिंग देने और एआई से मिलने वाले डेटा को दिखाने के लिए, एक जैसे आंकड़ों के नियम लागू करें. गलत तरीके से इस्तेमाल की गई सुविधाओं की संख्या और हर सुविधा के लिए गलत तरीके से इस्तेमाल किए गए उदाहरणों का अनुपात ट्रैक करें. |
ट्रेनिंग और ब्राउज़र में वेब पेज खोलने के दौरान परफ़ॉर्मेंस में अंतर की वजहें साफ़ तौर पर नहीं दिखती हैं. हमेशा इस बात का ध्यान रखें कि अनुमान लगाने के समय आपके मॉडल के पास कौनसा डेटा उपलब्ध है. ट्रेनिंग के दौरान, सिर्फ़ उन सुविधाओं का इस्तेमाल करें जो आपके पास विज्ञापन दिखाते समय उपलब्ध होंगी.
एक्सरसाइज़: देखें कि आपको क्या समझ आया
मान लें कि आपका एक ऑनलाइन स्टोर है और आपको यह अनुमान लगाना है कि किसी खास दिन आपको कितनी कमाई होगी. आपका एमएल लक्ष्य, ग्राहकों की संख्या को सुविधा के तौर पर इस्तेमाल करके, रोज़ की आय का अनुमान लगाना है.
जवाब: समस्या यह है कि दिन की बिक्री पूरी होने से पहले, अनुमान लगाने के समय आपको खरीदारों की संख्या का पता नहीं होता. इसलिए, यह सुविधा काम की नहीं है. भले ही, यह सुविधा आपके रोज़ के रेवेन्यू का सटीक अनुमान लगाती हो. इसी तरह, जब किसी मॉडल को ट्रेनिंग दी जा रही हो और आपको बेहतरीन आकलन मेट्रिक (जैसे, 0.99 AUC) मिलें, तो ऐसी सुविधाओं को ढूंढें जो आपके लेबल में शामिल की जा सकती हैं.
लेबल लीक होने की जांच करना
लेबल लीक का मतलब है कि आपके ग्राउंड ट्रूथ लेबल, जिन्हें आपको अनुमान लगाना है वे अनजाने में आपकी ट्रेनिंग सुविधाओं में शामिल हो गए हैं. लेबल के लीक होने का पता लगाना कभी-कभी बहुत मुश्किल होता है.
एक्सरसाइज़: देखें कि आपको क्या समझ आया
मान लें कि आपने अस्पताल के किसी नए मरीज़ को कैंसर है या नहीं, यह पता लगाने के लिए बाइनरी क्लासिफ़िकेशन मॉडल बनाया है. आपका मॉडल इन सुविधाओं का इस्तेमाल करता है:
- मरीज़ की उम्र
- पेशेंट का लिंग
- पहले से मौजूद बीमारियां
- अस्पताल का नाम
- बीपी, धड़कन की दर वगैरह से जुड़ा डेटा
- परीक्षण परिणाम
- आनुवांशिकता
लेबल इस तरह से है:
- बूलियन: क्या मरीज़ को कैंसर है?
डेटा को ध्यान से बांटें, ताकि आपका ट्रेनिंग सेट, पुष्टि करने वाले सेट और टेस्ट सेट से अलग हो. पुष्टि करने वाले सेट और टेस्ट सेट पर, मॉडल की परफ़ॉर्मेंस काफ़ी अच्छी है. साथ ही, मेट्रिक बेहतरीन हैं. माफ़ करें, असल दुनिया में नए मरीजों के लिए यह मॉडल बहुत खराब परफ़ॉर्म करता है.
जवाब: मॉडल की एक सुविधा, अस्पताल का नाम है. कुछ अस्पताल, कैंसर के इलाज में माहिर होते हैं. ट्रेनिंग के दौरान, मॉडल को पता चला कि कुछ अस्पतालों में भेजे गए मरीज़ों को कैंसर हो सकता है. इसलिए, अस्पताल के नाम को ज़्यादा अहमियत दी गई.
अनुमान लगाने के समय, ज़्यादातर मरीज़ों को किसी अस्पताल में भेजा नहीं गया था. आखिरकार, मॉडल का मकसद कैंसर की मौजूदगी या न होने का पता लगाना था. इसके बाद, उस नतीजे का इस्तेमाल करके मरीज़ को सही अस्पताल में भेजना था. इस वजह से, अनुमान लगाने के दौरान, अस्पताल के नाम की सुविधा उपलब्ध नहीं थी और मॉडल को अन्य सुविधाओं पर भरोसा करना पड़ा.
पूरी पाइपलाइन में मॉडल की उम्र पर नज़र रखना
अगर विज्ञापन दिखाने के लिए इस्तेमाल होने वाला डेटा समय के साथ बदलता है, लेकिन आपके मॉडल को नियमित तौर पर फिर से ट्रेन नहीं किया जाता, तो आपको मॉडल की क्वालिटी में गिरावट दिखेगी. मॉडल को नए डेटा पर फिर से ट्रेन किए जाने के बाद से बीता समय ट्रैक करें. साथ ही, सूचनाओं के लिए थ्रेशोल्ड उम्र सेट करें. मॉडल को दिखाने के दौरान उसकी उम्र पर नज़र रखने के अलावा, आपको पूरी पाइपलाइन के दौरान मॉडल की उम्र पर नज़र रखनी चाहिए, ताकि पाइपलाइन में रुकावटों का पता चल सके.
जांचें कि मॉडल के वेट और आउटपुट संख्या के हिसाब से स्थिर हैं या नहीं
मॉडल को ट्रेनिंग देने के दौरान, आपके वेट और लेयर आउटपुट NaN (कोई संख्या नहीं) या Inf (इनफ़ाइनाइट) नहीं होने चाहिए. अपने वेट और लेयर आउटपुट की NaN और Inf वैल्यू की जांच करने के लिए टेस्ट लिखें. इसके अलावा, यह भी जांचें कि किसी लेयर के आधे से ज़्यादा आउटपुट शून्य न हों.
मॉडल की परफ़ॉर्मेंस पर नज़र रखना
यूनिकॉर्न के दिखने का अनुमान लगाने वाला आपका टूल, उम्मीद से ज़्यादा लोकप्रिय हुआ है! आपको अनुमान के लिए बहुत सारे अनुरोध और ज़्यादा ट्रेनिंग डेटा मिल रहा है. आपको लगता है कि यह बहुत बढ़िया है, लेकिन जब आपको पता चलता है कि आपके मॉडल को ट्रेनिंग देने में ज़्यादा से ज़्यादा मेमोरी और समय लग रहा है, तो आपको यह अच्छा नहीं लगता. आपने अपने मॉडल की परफ़ॉर्मेंस पर नज़र रखने का फ़ैसला लिया है. इसके लिए, यह तरीका अपनाएं:
- कोड, मॉडल, और डेटा के वर्शन के हिसाब से मॉडल की परफ़ॉर्मेंस को ट्रैक करें. इस तरह की ट्रैकिंग की मदद से, परफ़ॉर्मेंस में होने वाली गिरावट की सटीक वजह का पता लगाया जा सकता है.
- नए मॉडल वर्शन के लिए, हर सेकंड में ट्रेनिंग के चरणों की जांच करें. साथ ही, इसकी तुलना पिछले वर्शन और तय थ्रेशोल्ड से करें.
- मेमोरी के इस्तेमाल के लिए थ्रेशोल्ड सेट करके, मेमोरी लीक का पता लगाएं.
- एपीआई के रिस्पॉन्स में लगने वाले समय को मॉनिटर करें और उनके प्रतिशत को ट्रैक करें. एपीआई के रिस्पॉन्स में लगने वाला समय, शायद आपके कंट्रोल में न हो. हालांकि, रिस्पॉन्स में लगने वाले लंबे समय की वजह से, असल दुनिया की मेट्रिक खराब हो सकती हैं.
- हर सेकंड में जवाब दी गई क्वेरी की संख्या पर नज़र रखें.
दिखाए गए डेटा पर लाइव मॉडल की क्वालिटी की जांच करना
आपने अपने मॉडल की पुष्टि कर ली है. हालांकि, अगर पुष्टि करने के लिए इस्तेमाल किया गया डेटा रिकॉर्ड करने के बाद, असल दुनिया के उदाहरण, जैसे कि यूनीकॉर्न के व्यवहार में बदलाव हो जाता है, तो क्या होगा? ऐसा करने पर, दिखाए गए मॉडल की क्वालिटी खराब हो जाएगी. हालांकि, एआई से मिलने वाले डेटा की क्वालिटी की जांच करना मुश्किल है, क्योंकि असल दुनिया का डेटा हमेशा लेबल नहीं किया जाता. अगर आपका दिखाया जा रहा डेटा लेबल नहीं किया गया है, तो इन टेस्ट को आज़माएं:
उन मॉडल की जांच करें जो अनुमानों में आंकड़ों के हिसाब से काफ़ी पक्षपात दिखाते हैं. क्लासिफ़िकेशन: अनुमान में बायस देखें.
अपने मॉडल के लिए, असल दुनिया की मेट्रिक ट्रैक करें. उदाहरण के लिए, अगर स्पैम का ब्यौरा दिया जा रहा है, तो अपने अनुमान की तुलना, उपयोगकर्ता की शिकायत वाले स्पैम से करें.
अपनी कुछ क्वेरी पर नए मॉडल का वर्शन दिखाकर, ट्रेनिंग और डेटा दिखाने के बीच संभावित अंतर को कम करें. विज्ञापन दिखाने के नए मॉडल की पुष्टि करते समय, सभी क्वेरी को धीरे-धीरे नए वर्शन पर स्विच करें.
इन टेस्ट का इस्तेमाल करके, अचानक और धीरे-धीरे होने वाली, अनुमान की क्वालिटी में गिरावट पर नज़र रखना न भूलें.
रैंडमाइज़ेशन
डेटा जनरेशन पाइपलाइन को दोबारा इस्तेमाल किया जा सके. मान लें कि आपको कोई सुविधा जोड़नी है, ताकि यह देखा जा सके कि इसका मॉडल की क्वालिटी पर क्या असर पड़ता है. सही तरीके से एक्सपेरिमेंट करने के लिए, आपके डेटासेट एक जैसे होने चाहिए. हालांकि, इस नई सुविधा को छोड़कर. इस बात का ध्यान रखें कि डेटा जनरेशन में, रैंडमाइज़ेशन को डिटरमिनिस्टिक बनाया जा सकता है:
- रैंडम नंबर जनरेटर (आरएनजी) को सीड करें. सीडिंग से यह पक्का होता है कि आरएनजी को हर बार चलाने पर, वह एक ही क्रम में एक ही वैल्यू दिखाए. इससे आपका डेटासेट फिर से बन जाता है.
- इनवैरिएंट हैश कुंजियों का इस्तेमाल करें. हैशिंग, डेटा को बांटने या सैंपल लेने का एक आम तरीका है. हर उदाहरण को हैश किया जा सकता है. साथ ही, इससे मिले पूर्णांक का इस्तेमाल करके यह तय किया जा सकता है कि उदाहरण को किस स्प्लिट में रखना है. डेटा जनरेशन प्रोग्राम को हर बार चलाने पर, आपके हैश फ़ंक्शन के इनपुट में बदलाव नहीं होना चाहिए. अपने हैश में, मौजूदा समय या किसी रैंडम नंबर का इस्तेमाल न करें. उदाहरण के लिए, अगर आपको मांग पर अपने हैश फिर से बनाने हैं.
ऊपर बताए गए तरीके, डेटा को सैंपल करने और उसे बांटने, दोनों पर लागू होते हैं.
हैशिंग के लिए ध्यान रखने वाली बातें
मान लें कि आपने Search Network में की गई क्वेरी इकट्ठा की हैं और क्वेरी को शामिल करने या बाहर रखने के लिए हैशिंग का इस्तेमाल किया है. अगर हैश बटन में सिर्फ़ क्वेरी का इस्तेमाल किया गया है, तो कई दिनों के डेटा में, आपको उस क्वेरी को हमेशा शामिल करना होगा या हमेशा बाहर रखना होगा. किसी क्वेरी को हमेशा शामिल करना या हमेशा बाहर रखना गलत है, क्योंकि:
- आपके ट्रेनिंग सेट में, अलग-अलग तरह की क्वेरी कम दिखेंगी.
- आपके आकलन सेट, कृत्रिम रूप से मुश्किल होंगे, क्योंकि वे आपके ट्रेनिंग डेटा के साथ ओवरलैप नहीं करेंगे. असल में, विज्ञापन दिखाने के समय, आपको अपने ट्रेनिंग डेटा में कुछ लाइव ट्रैफ़िक दिखेगा. इसलिए, आपके आकलन में इस बात को दिखाया जाना चाहिए.
इसके बजाय, क्वेरी + तारीख के हिसाब से हैश किया जा सकता है. इससे हर दिन अलग-अलग हैशिंग होगी.
