सॉफ़्टवेयर इंजीनियरिंग के सभी अच्छे प्रोजेक्ट, अपने ऐप्लिकेशन की जांच करने के लिए काफ़ी मेहनत करते हैं. इसी तरह, हमारा सुझाव है कि आप अपने एआई मॉडल की जांच करें, ताकि यह पता लगाया जा सके कि उसके अनुमान सही हैं या नहीं.
ट्रेनिंग, पुष्टि, और टेस्ट सेट
आपको मॉडल को ट्रेनिंग देने के लिए इस्तेमाल किए गए उदाहरणों के बजाय, मॉडल की जांच अलग उदाहरणों के आधार पर करनी चाहिए. थोड़ी देर बाद आपको पता चलेगा कि अलग-अलग उदाहरणों पर जांच करने से, आपके मॉडल के सही होने का ज़्यादा भरोसा होता है. ऐसा, एक ही सेट के उदाहरणों पर जांच करने के मुकाबले होता है.
आपको ये अलग-अलग उदाहरण कहां से मिलते हैं? आम तौर पर, मशीन लर्निंग में, आपको मूल डेटासेट को बांटकर, अलग-अलग उदाहरण मिलते हैं. इसलिए, यह माना जा सकता है कि आपको ओरिजनल डेटासेट को दो सबसेट में बांटना चाहिए:
आठवां डायग्राम. यह ऑप्टिमाइज़ नहीं किया गया स्प्लिट है.
एक्सरसाइज़: अपने अंतर्ज्ञान की जांच करना
मान लें कि आपने ट्रेनिंग सेट पर ट्रेनिंग दी है और कई राउंड में, टेस्ट सेट का आकलन किया है. हर राउंड में, टेस्ट सेट के नतीजों का इस्तेमाल करके,
हाइपरपैरामीटर और फ़ीचर सेट को अपडेट करने का तरीका तय किया जाता है. क्या आपको इस तरीके में कोई गड़बड़ी दिखती है? सिर्फ़ एक जवाब चुनें.
इस प्रोसेस को कई बार करने से, मॉडल के लिए
टेस्ट सेट की खास बातों को अपने-आप फ़िट होने की संभावना बढ़ जाती है.
हां! एक ही टेस्ट सेट का जितनी ज़्यादा बार इस्तेमाल किया जाता है, उतनी ही ज़्यादा संभावना होती है कि मॉडल, टेस्ट सेट के हिसाब से काम करे.
ठीक उसी तरह जैसे कोई शिक्षक, परीक्षा के हिसाब से पढ़ाता है, मॉडल भी अनजाने में
टेस्ट सेट के हिसाब से काम करता है. इससे मॉडल के लिए, असल दुनिया के डेटा के हिसाब से काम करना मुश्किल हो सकता है.
यह तरीका ठीक है. आखिरकार, आपने ट्रेनिंग सेट पर ट्रेनिंग दी है और अलग टेस्ट सेट पर उसका आकलन किया है.
असल में, यहां एक छोटी सी समस्या है. इस बारे में सोचें कि धीरे-धीरे क्या गलत हो सकता है.
यह तरीका, कैलकुलेशन के लिए कारगर नहीं है. हर बार टेस्ट करने के बाद,
हाइपरपैरामीटर या सुविधाओं के सेट में बदलाव न करें.
अक्सर टेस्ट करना महंगा होता है, लेकिन ज़रूरी है. हालांकि, बार-बार जांच कराने की लागत, अतिरिक्त ट्रेनिंग की लागत से काफ़ी कम होती है. हाइपरपैरामीटर और सुविधाओं के सेट को ऑप्टिमाइज़ करने से, मॉडल की क्वालिटी में काफ़ी सुधार हो सकता है. इसलिए, इन पर काम करने के लिए हमेशा समय और कंप्यूटेशनल संसाधनों का बजट रखें.
डेटासेट को दो सेट में बांटना एक अच्छा तरीका है. हालांकि, डेटासेट को तीन सबसेट में बांटना बेहतर तरीका है.
ट्रेनिंग सेट और टेस्ट सेट के अलावा, तीसरा सबसेट यह है:
नौवीं इमेज. आय का बंटवारा बेहतर तरीके से किया जा सकता है.
ट्रेनिंग सेट के नतीजों का आकलन करने के लिए, पुष्टि करने वाले सेट का इस्तेमाल करें.
वैलिडेशन सेट का बार-बार इस्तेमाल करने के बाद, अगर आपको लगता है कि आपका मॉडल सही अनुमान लगा रहा है, तो अपने मॉडल की दोबारा जांच करने के लिए टेस्ट सेट का इस्तेमाल करें.
नीचे दिए गए इलस्ट्रेशन में यह वर्कफ़्लो दिखाया गया है.
इस इमेज में, "मॉडल में बदलाव करना" का मतलब है कि मॉडल में कुछ भी बदलना. जैसे, लर्निंग रेट बदलना, सुविधाएं जोड़ना या हटाना, और फिर से एक नया मॉडल डिज़ाइन करना.
इस वर्कफ़्लो के आखिर में, आपको टेस्ट सेट पर सबसे अच्छा परफ़ॉर्म करने वाला मॉडल चुनना होता है.
10वां डायग्राम. डेवलपमेंट और टेस्टिंग के लिए अच्छा वर्कफ़्लो.
फ़िगर 10 में दिखाया गया वर्कफ़्लो सबसे सही है. हालांकि, इस वर्कफ़्लो के बावजूद, बार-बार इस्तेमाल करने पर, जांच के सेट और पुष्टि करने वाले सेट "खराब हो जाते हैं".
इसका मतलब है कि हाइपरपैरामीटर सेटिंग या मॉडल में अन्य सुधारों के बारे में फ़ैसले लेने के लिए, एक ही डेटा का ज़्यादा इस्तेमाल करने पर, इस बात की संभावना कम हो जाती है कि मॉडल नए डेटा के लिए अच्छे अनुमान लगा पाएगा.
इसलिए, टेस्ट सेट और पुष्टि करने वाले सेट को "रीफ़्रेश" करने के लिए, ज़्यादा डेटा इकट्ठा करना एक अच्छा विचार है. फिर से शुरुआत करना, एक बेहतरीन रीसेट है.
एक्सरसाइज़: अपने अंतर्ज्ञान की जांच करना
आपने डेटासेट में मौजूद सभी उदाहरणों को शफ़ल किया है और शफ़ल किए गए उदाहरणों को ट्रेनिंग, पुष्टि, और टेस्ट सेट में बांटा है. हालांकि, आपके टेस्ट सेट में लॉस वैल्यू इतनी कम है कि आपको लगता है कि कोई गड़बड़ी हुई है. क्या गड़बड़ी हुई है?
टेस्ट सेट में मौजूद कई उदाहरण, ट्रेनिंग सेट में मौजूद उदाहरणों के डुप्लीकेट हैं.
हां. यह समस्या ऐसे डेटासेट में हो सकती है जिसमें बहुत से ग़ैर-ज़रूरी उदाहरण हों. हमारा सुझाव है कि जांच करने से पहले, डुप्लीकेट उदाहरणों को
टेस्ट सेट से मिटा दें.
ट्रेनिंग और टेस्टिंग, नॉन-डेटरमिनिस्टिक होती हैं. कभी-कभी, अचानक से आपके टेस्ट में होने वाली हानियां बहुत कम हो जाती हैं. नतीजे की पुष्टि करने के लिए, जांच फिर से चलाएं.
हालांकि, हर बार रन करने पर लॉस में थोड़ा अंतर होता है, लेकिन यह इतना नहीं होना चाहिए कि आपको लगे कि आपने मशीन लर्निंग की लॉटरी जीत ली है.
ऐसा हो सकता है कि टेस्ट सेट में ऐसे उदाहरण शामिल हों जिन पर
मॉडल की परफ़ॉर्मेंस अच्छी रही हो.
उदाहरणों को अच्छी तरह से शफ़ल किया गया था, इसलिए ऐसा होने की संभावना बहुत कम है.
टेस्ट सेट से जुड़ी अन्य समस्याएं
पिछले सवाल से पता चलता है कि डुप्लीकेट उदाहरणों से मॉडल के आकलन पर असर पड़ सकता है.
किसी डेटासेट को ट्रेनिंग, पुष्टि करने वाले, और टेस्ट सेट में बांटने के बाद, पुष्टि करने वाले सेट या टेस्ट सेट में ऐसे सभी उदाहरण मिटाएं जो ट्रेनिंग सेट के उदाहरणों के डुप्लीकेट हों. किसी मॉडल की जांच सिर्फ़ नए उदाहरणों के आधार पर की जानी चाहिए, न कि डुप्लीकेट उदाहरणों के आधार पर.
उदाहरण के लिए, एक ऐसा मॉडल जिससे यह अनुमान लगाया जा सकता है कि कोई ईमेल स्पैम है या नहीं. इसके लिए, सब्जेक्ट लाइन, ईमेल का मुख्य हिस्सा, और ईमेल भेजने वाले का ईमेल पता, फ़ीचर के तौर पर इस्तेमाल किया जाता है.
मान लें कि आपने डेटा को 80-20 के अनुपात में, ट्रेनिंग और टेस्ट सेट में बांटा है.
ट्रेनिंग के बाद, मॉडल को ट्रेनिंग सेट और
टेस्ट सेट, दोनों पर 99% सटीक नतीजे मिलते हैं. आपको टेस्ट सेट पर कम सटीक नतीजे मिल सकते हैं. इसलिए, डेटा को फिर से देखें और पता लगाएं कि टेस्ट सेट के कई उदाहरण, ट्रेनिंग सेट के उदाहरणों के डुप्लीकेट हैं. समस्या यह है कि आपने डेटा को अलग-अलग हिस्सों में बांटने से पहले, अपने इनपुट डेटाबेस से एक ही स्पैम ईमेल की डुप्लीकेट एंट्री को हटाना नहीं भूल लिया. आपने गलती से अपने कुछ जांच डेटा पर ट्रेनिंग दी है.
खास जानकारी के तौर पर, एक अच्छा टेस्ट सेट या पुष्टि करने वाला सेट, इन सभी शर्तों को पूरा करता है:
यह डेटा इतना बड़ा हो कि आंकड़ों के हिसाब से अहम नतीजे मिल सकें.
डेटासेट का पूरा प्रतिनिधित्व करता है. दूसरे शब्दों में, ऐसा टेस्ट सेट न चुनें जो ट्रेनिंग सेट से अलग हो.
असल दुनिया के उस डेटा का प्रतिनिधि जो मॉडल को अपने कारोबार के मकसद के तहत मिलेगा.
ट्रेनिंग सेट में डुप्लीकेट उदाहरण नहीं हैं.
एक्सरसाइज़: देखें कि आपको क्या समझ आया
अगर किसी डेटासेट में तय संख्या में उदाहरण हैं, तो
इनमें से कौनसा स्टेटमेंट सही है?
मॉडल की जांच करने के लिए इस्तेमाल किए गए हर उदाहरण का इस्तेमाल, मॉडल को ट्रेनिंग देने के लिए नहीं किया जाता.
उदाहरणों को ट्रेन/टेस्ट/पुष्टि करने वाले सेट में बांटना, शून्य-योग वाला गेम है.
यह मुख्य समस्या है.
टेस्ट सेट में उदाहरणों की संख्या, पुष्टि करने वाले सेट में उदाहरणों की संख्या से ज़्यादा होनी चाहिए.
सिद्धांत रूप से, पुष्टि करने वाले सेट और टेस्ट सेट में एक जैसे उदाहरण होने चाहिए या कम से कम उनकाफ़ायदेमंद होना चाहिए.
टेस्ट सेट में मौजूद उदाहरणों की संख्या, पुष्टि करने वाले सेट या ट्रेनिंग सेट में मौजूद उदाहरणों की संख्या से ज़्यादा होनी चाहिए.
आम तौर पर, ट्रेनिंग सेट में मौजूद उदाहरणों की संख्या, पुष्टि करने वाले सेट या टेस्ट सेट में मौजूद उदाहरणों की संख्या से ज़्यादा होती है. हालांकि, अलग-अलग सेट के लिए प्रतिशत की कोई ज़रूरी शर्त नहीं होती.
मान लें कि आपके टेस्ट सेट में, आंकड़ों के हिसाब से अहम टेस्ट करने के लिए ज़रूरी उदाहरण मौजूद हैं. इसके अलावा, जांच सेट के आधार पर जांच करने से, कम नुकसान होता है. हालांकि, असल दुनिया में मॉडल की परफ़ॉर्मेंस खराब रही. ऐसे में आपको क्या करना चाहिए?
यह पता लगाएं कि ओरिजनल डेटासेट, असल डेटा से किस तरह अलग है.
हां. सबसे अच्छे डेटासेट भी असल डेटा का सिर्फ़ एक स्नैपशॉट होते हैं. साथ ही, समय के साथ ग्राउंड ट्रूथ में बदलाव होता रहता है. आपका टेस्ट सेट, मॉडल की अच्छी क्वालिटी का सुझाव देने के लिए, आपके
ट्रेनिंग सेट से काफ़ी हद तक मैच करता है. हालांकि, ऐसा हो सकता है कि आपका
डेटासेट, असल दुनिया के डेटा से काफ़ी हद तक मैच न करता हो.
आपको नए डेटासेट के लिए, मशीन लर्निंग मॉडल को फिर से ट्रेन करना पड़ सकता है और फिर से टेस्ट करना पड़ सकता है.
उसी टेस्ट सेट पर फिर से जांच करें. हो सकता है कि जांच के नतीजे में कोई गड़बड़ी हुई हो.
हालांकि, फिर से जांच करने पर थोड़े अलग नतीजे मिल सकते हैं,
लेकिन यह तरीका शायद बहुत मददगार न हो.
टेस्ट सेट में कितने उदाहरण होने चाहिए?
आंकड़ों के हिसाब से अहम नतीजे पाने के लिए ज़रूरत के मुताबिक उदाहरण.
हां. कितने उदाहरण हैं? आपको एक्सपेरिमेंट करना होगा.
