डेटासेट: मूल डेटासेट को विभाजित करना

सॉफ़्टवेयर इंजीनियरिंग के सभी अच्छे प्रोजेक्ट, अपने ऐप्लिकेशन की जांच करने के लिए काफ़ी मेहनत करते हैं. इसी तरह, हमारा सुझाव है कि आप अपने एआई मॉडल की जांच करें, ताकि यह पता लगाया जा सके कि उसके अनुमान सही हैं या नहीं.

ट्रेनिंग, पुष्टि, और टेस्ट सेट

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

आठवां चित्र. एक हॉरिज़ॉन्टल बार, जिसे दो हिस्सों में बांटा गया है: इनमें से ~80% हिस्सा
            ट्रेनिंग सेट और ~20% हिस्सा टेस्ट सेट है.
आठवां डायग्राम. यह ऑप्टिमाइज़ नहीं किया गया स्प्लिट है.

 

एक्सरसाइज़: अपने अंतर्ज्ञान की जांच करना

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

डेटासेट को दो सेट में बांटना एक अच्छा तरीका है. हालांकि, डेटासेट को तीन सबसेट में बांटना बेहतर तरीका है. ट्रेनिंग सेट और टेस्ट सेट के अलावा, तीसरा सबसेट यह है:

नौवां चित्र. एक हॉरिज़ॉन्टल बार, जिसे तीन हिस्सों में बांटा गया है: इनमें से 70% हिस्सा
            ट्रेनिंग सेट, 15% हिस्सा पुष्टि करने वाला सेट, और 15% हिस्सा
            टेस्ट सेट है
नौवीं इमेज. आय का बंटवारा बेहतर तरीके से किया जा सकता है.

ट्रेनिंग सेट के नतीजों का आकलन करने के लिए, पुष्टि करने वाले सेट का इस्तेमाल करें. पुष्टि करने वाले सेट का बार-बार इस्तेमाल करने के बाद, यह पता चलता है कि आपका मॉडल अच्छी भविष्यवाणियां कर रहा है. अपने मॉडल की दोबारा जांच करने के लिए, टेस्ट सेट का इस्तेमाल करें.

नीचे दिए गए इलस्ट्रेशन में यह वर्कफ़्लो दिखाया गया है. इस इमेज में, "मॉडल में बदलाव करना" का मतलब है कि मॉडल में कुछ भी बदलना. जैसे, लर्निंग रेट बदलना, सुविधाएं जोड़ना या हटाना, और फिर से एक नया मॉडल डिज़ाइन करना.

दसवां चित्र. वर्कफ़्लो का डायग्राम, जिसमें ये चरण शामिल हैं:
            1. ट्रेनिंग सेट पर मॉडल को ट्रेनिंग दें.
            2. पुष्टि करने वाले सेट पर मॉडल का आकलन करें.
            3. पुष्टि करने वाले सेट के नतीजों के हिसाब से मॉडल में बदलाव करें.
            4. पहले, दूसरे, और तीसरे चरण को दोहराएं. आखिर में, वह मॉडल चुनें जो पुष्टि करने वाले सेट पर सबसे अच्छा परफ़ॉर्म करता है.
            5. टेस्ट सेट पर नतीजों की पुष्टि करें.
10वां डायग्राम. डेवलपमेंट और टेस्टिंग के लिए अच्छा वर्कफ़्लो.

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

एक्सरसाइज़: अपने अंतर्ज्ञान की जांच करना

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

टेस्ट सेट से जुड़ी अन्य समस्याएं

पिछले सवाल से पता चलता है कि डुप्लीकेट उदाहरणों से मॉडल के आकलन पर असर पड़ सकता है. डेटासेट को ट्रेनिंग, पुष्टि, और टेस्ट सेट में बांटने के बाद, पुष्टि करने वाले सेट या टेस्ट सेट में ऐसे सभी उदाहरण मिटाएं जो ट्रेनिंग सेट के उदाहरणों के डुप्लीकेट हों. किसी मॉडल की जांच सिर्फ़ नए उदाहरणों के आधार पर की जानी चाहिए, न कि डुप्लीकेट उदाहरणों के आधार पर.

उदाहरण के लिए, एक ऐसा मॉडल जिससे यह अनुमान लगाया जा सकता है कि कोई ईमेल स्पैम है या नहीं. इसके लिए, सब्जेक्ट लाइन, ईमेल का मुख्य हिस्सा, और ईमेल भेजने वाले का ईमेल पता, फ़ीचर के तौर पर इस्तेमाल किया जाता है. मान लें कि आपने डेटा को 80-20 के अनुपात में, ट्रेनिंग और टेस्ट सेट में बांटा है. ट्रेनिंग के बाद, मॉडल को ट्रेनिंग सेट और टेस्ट सेट, दोनों पर 99% सटीक नतीजे मिलते हैं. आपको टेस्ट सेट पर कम सटीक नतीजे मिल सकते हैं. इसलिए, डेटा को फिर से देखें और पता लगाएं कि टेस्ट सेट के कई उदाहरण, ट्रेनिंग सेट के उदाहरणों के डुप्लीकेट हैं. समस्या यह है कि आपने डेटा को अलग-अलग हिस्सों में बांटने से पहले, अपने इनपुट डेटाबेस से एक ही स्पैम ईमेल की डुप्लीकेट एंट्री को हटाना नहीं भूल लिया. आपने गलती से अपने कुछ टेस्ट डेटा पर ट्रेनिंग दी है.

खास जानकारी के तौर पर, एक अच्छा टेस्ट सेट या पुष्टि करने वाला सेट, इन सभी शर्तों को पूरा करता है:

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

एक्सरसाइज़: देखें कि आपको क्या समझ आया

अगर किसी डेटासेट में तय संख्या में उदाहरण हैं, तो इनमें से कौनसा स्टेटमेंट सही है?
टेस्ट सेट में मौजूद उदाहरणों की संख्या, पुष्टि करने वाले सेट या ट्रेनिंग सेट में मौजूद उदाहरणों की संख्या से ज़्यादा होनी चाहिए.
मॉडल की जांच करने के लिए इस्तेमाल किए गए हर उदाहरण का इस्तेमाल, मॉडल को ट्रेनिंग देने के लिए नहीं किया जाता.
टेस्ट सेट में उदाहरणों की संख्या, पुष्टि करने वाले सेट में उदाहरणों की संख्या से ज़्यादा होनी चाहिए.
मान लें कि आपके टेस्ट सेट में, आंकड़ों के हिसाब से अहम टेस्ट करने के लिए ज़रूरी उदाहरण मौजूद हैं. इसके अलावा, जांच सेट के आधार पर जांच करने से, कम नुकसान होता है. हालांकि, असल दुनिया में मॉडल की परफ़ॉर्मेंस खराब रही. ऐसे में आपको क्या करना चाहिए?
उसी टेस्ट सेट पर फिर से जांच करें. हो सकता है कि जांच के नतीजे में कोई गड़बड़ी हुई हो.
यह पता लगाएं कि ओरिजनल डेटासेट, असल डेटा से किस तरह अलग है.
टेस्ट सेट में कितने उदाहरण होने चाहिए?
ओरिजनल डेटासेट का कम से कम 15% हिस्सा.
आंकड़ों के हिसाब से अहम नतीजे पाने के लिए ज़रूरत के मुताबिक उदाहरण.