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