एक्सपेरिमेंट से किसी प्रोजेक्ट को कामयाब बनाने में मदद मिलती है. ये ऐसे अनुमान होते हैं जिन्हें जांचा जा सकता है और फिर से बनाए जा सकते हैं. एक्सपेरिमेंट चलाते समय, हमारा मकसद अलग-अलग तरह के मॉडल आर्किटेक्चर और सुविधाओं का आकलन करके, लगातार सुधार करना होता है. एक्सपेरिमेंट करते समय, आपको ये काम करने होंगे:
बेसलाइन परफ़ॉर्मेंस का पता लगाएं. सबसे पहले, बेसलाइन मेट्रिक सेट अप करें. एक्सपेरिमेंट की तुलना करने के लिए, बेसलाइन एक मेज़रिंग स्टिक के तौर पर काम करता है.
कुछ मामलों में, मौजूदा नॉन-एमएल समाधान, पहला बेसलाइन मेट्रिक दे सकता है. अगर फ़िलहाल कोई समाधान मौजूद नहीं है, तो आसान आर्किटेक्चर और कुछ सुविधाओं के साथ एक मशीन लर्निंग मॉडल बनाएं. साथ ही, इसकी मेट्रिक का इस्तेमाल बेसलाइन के तौर पर करें.
एक बार में एक या दो छोटे बदलाव करें. एक बार में सिर्फ़ एक छोटा बदलाव करें. उदाहरण के लिए, हाइपरपैरामीटर, आर्किटेक्चर या सुविधाओं में. अगर बदलाव से मॉडल बेहतर होता है, तो आने वाले समय में होने वाले प्रयोगों की तुलना करने के लिए, उस मॉडल की मेट्रिक नई बेसलाइन बन जाती हैं.
यहां ऐसे एक्सपेरिमेंट के उदाहरण दिए गए हैं जिनमें एक छोटा बदलाव किया गया है:
- सुविधा X शामिल करें.
- पहली छिपी हुई लेयर पर 0.5 ड्रॉपआउट का इस्तेमाल करें.
- Y फ़ीचर का लॉग ट्रांसफ़ॉर्म करें.
- लर्निंग रेट को 0.001 पर सेट करें.
एक्सपेरिमेंट की प्रोग्रेस रिकॉर्ड करें. आपको कई प्रयोग करने पड़ सकते हैं. बेसलाइन की तुलना में, खराब (या सामान्य) अनुमान की क्वालिटी वाले एक्सपेरिमेंट अब भी ट्रैक करने के लिए काम के हैं. इससे यह पता चलता है कि कौनसे तरीकों से काम नहीं किया जा सकता. आम तौर पर, प्रगति एक सीधी रेखा में नहीं होती. इसलिए, यह दिखाना ज़रूरी है कि आप समस्या पर काम कर रहे हैं. इसके लिए, उन सभी तरीकों को हाइलाइट करें जो काम नहीं करते. साथ ही, बेसलाइन क्वालिटी को बेहतर बनाने में हुई अपनी प्रोग्रेस के बारे में भी बताएं.
असल दुनिया के डेटासेट पर हर बार पूरी ट्रेनिंग में घंटे या दिन लग सकते हैं. इसलिए, स्पेस को तेज़ी से एक्सप्लोर करने के लिए, एक साथ कई अलग-अलग प्रयोग चलाएं. बार-बार कोशिश करने पर, आपको उम्मीद है कि आपको प्रॉडक्शन के लिए ज़रूरी क्वालिटी मिल जाएगी.
एक्सपेरिमेंट के नतीजों में गड़बड़ी
ध्यान दें कि आपको एक्सपेरिमेंट के नतीजों में गड़बड़ियां दिख सकती हैं. ये गड़बड़ियां, मॉडल या डेटा में किए गए बदलावों की वजह से नहीं होती हैं. इससे यह पता लगाना मुश्किल हो जाता है कि आपके किए गए बदलाव से मॉडल में असल में सुधार हुआ है या नहीं. यहां उन चीज़ों के उदाहरण दिए गए हैं जिनकी वजह से, एक्सपेरिमेंट के नतीजों में गड़बड़ी हो सकती है:
डेटा को क्रम से लगाना: मॉडल को डेटा जिस क्रम में दिखाया जाता है उससे मॉडल की परफ़ॉर्मेंस पर असर पड़ सकता है.
वैरिएबल को शुरू करने का तरीका: मॉडल के वैरिएबल को शुरू करने के तरीके से भी उसकी परफ़ॉर्मेंस पर असर पड़ सकता है.
असाइनमेंट के लिए अलग-अलग प्रोसेसर का इस्तेमाल करना: अगर मॉडल को असाइनमेंट के लिए अलग-अलग प्रोसेसर का इस्तेमाल करके ट्रेन किया जाता है, तो मॉडल के अलग-अलग हिस्सों को अपडेट करने के क्रम से भी उसकी परफ़ॉर्मेंस पर असर पड़ सकता है.
छोटे आकलन सेट: अगर आकलन सेट बहुत छोटा है, तो हो सकता है कि वह मॉडल की पूरी परफ़ॉर्मेंस को न दिखा पाए. इससे मॉडल की क्वालिटी में असमान बदलाव हो सकते हैं.
एक्सपेरिमेंट को कई बार चलाने से, एक्सपेरिमेंट के नतीजों की पुष्टि करने में मदद मिलती है.
एक्सपेरिमेंट के तरीकों के साथ अलाइन करना
आपकी टीम को यह साफ़ तौर पर पता होना चाहिए कि "एक्सपेरिमेंट" क्या होता है. साथ ही, उसे तरीकों और आर्टफ़ैक्ट के बारे में भी पता होना चाहिए. आपको ऐसे दस्तावेज़ चाहिए जिनमें ये जानकारी दी गई हो:
आर्टफ़ैक्ट. किसी एक्सपेरिमेंट के लिए आर्टफ़ैक्ट क्या होते हैं? ज़्यादातर मामलों में, एक्सपेरिमेंट एक ऐसा अनुमान होता है जिसकी जांच की जा चुकी होती है और जिसे फिर से चलाया जा सकता है. आम तौर पर, ऐसा मेटाडेटा (जैसे, सुविधाएं और हाइपरपैरामीटर) को लॉग करके किया जाता है. इससे, एक्सपेरिमेंट के बीच हुए बदलावों और मॉडल की क्वालिटी पर उनके असर के बारे में पता चलता है.
कोडिंग के तरीके. क्या सभी लोग एक्सपेरिमेंट के लिए अपने-अपने एनवायरमेंट का इस्तेमाल करेंगे? सभी लोगों के काम को शेयर की गई लाइब्रेरी में एक साथ कैसे रखा जा सकता है?
नतीजों को दोहराना और ट्रैक करना. नतीजों को दोहराने के लिए क्या मानक हैं? उदाहरण के लिए, क्या टीम को एक ही डेटा पाइपलाइन और वर्शन बनाने के तरीकों का इस्तेमाल करना चाहिए या सिर्फ़ प्लॉट दिखाना ठीक है? एक्सपेरिमेंटल डेटा को कैसे सेव किया जाएगा: एसक्यूएल क्वेरी के तौर पर या मॉडल के स्नैपशॉट के तौर पर? हर एक्सपेरिमेंट के लॉग को कहां दस्तावेज़ में शामिल किया जाएगा: एक्सपेरिमेंट मैनेज करने के लिए किसी दस्तावेज़, स्प्रेडशीट या सीएमएस में?
गलत अनुमान
असल दुनिया का कोई भी मॉडल परफ़ेक्ट नहीं होता. आपका सिस्टम, गलत अनुमान को कैसे मैनेज करेगा? इन समस्याओं से निपटने के बारे में पहले से सोचना शुरू करें.
सबसे सही तरीके से काम करने वाली रणनीति से, उपयोगकर्ताओं को गलत अनुमान को सही तरीके से लेबल करने के लिए बढ़ावा मिलता है. उदाहरण के लिए, मेल ऐप्लिकेशन, गलत कैटगरी में रखे गए ईमेल को कैप्चर करते हैं. इसके लिए, वे उन ईमेल को लॉग करते हैं जिन्हें उपयोगकर्ता अपने स्पैम फ़ोल्डर में ले जाते हैं. साथ ही, वे उन ईमेल को भी लॉग करते हैं जिन्हें स्पैम फ़ोल्डर से इनबॉक्स में ले जाया जाता है. उपयोगकर्ताओं से ग्राउंड ट्रूथ लेबल कैप्चर करके, डेटा इकट्ठा करने और मॉडल को फिर से ट्रेन करने के लिए, अपने-आप काम करने वाले फ़ीडबैक लूप डिज़ाइन किए जा सकते हैं.
ध्यान दें कि यूज़र इंटरफ़ेस (यूआई) में एम्बेड किए गए सर्वे, उपयोगकर्ता के सुझाव, शिकायत या राय को कैप्चर करते हैं. हालांकि, यह डेटा आम तौर पर क्वालिटी पर आधारित होता है और इसे फिर से ट्रेनिंग देने के लिए इकट्ठा किए गए डेटा में शामिल नहीं किया जा सकता.
एंड-टू-एंड समाधान लागू करना
जब आपकी टीम मॉडल पर एक्सपेरिमेंट कर रही हो, तो फ़ाइनल पाइपलाइन के कुछ हिस्सों को बनाना शुरू करना अच्छा होता है. हालांकि, इसके लिए ज़रूरी है कि आपके पास इसके लिए संसाधन हों.
डेटा इनटेक और मॉडल को फिर से ट्रेन करने जैसी पाइपलाइन के अलग-अलग हिस्सों को सेट अप करने से, फ़ाइनल मॉडल को प्रोडक्शन में ले जाना आसान हो जाता है. उदाहरण के लिए, डेटा डालने और अनुमान दिखाने के लिए एंड-टू-एंड पाइपलाइन मिलने से, टीम को प्रॉडक्ट में मॉडल को इंटिग्रेट करने और शुरुआती चरण में उपयोगकर्ता टेस्टिंग शुरू करने में मदद मिल सकती है.
रुके हुए प्रोजेक्ट से जुड़ी समस्या हल करना
ऐसा हो सकता है कि किसी प्रोजेक्ट की प्रोग्रेस रुक जाए. ऐसा हो सकता है कि आपकी टीम, किसी ऐसे प्रयोग पर काम कर रही हो जो काफ़ी बेहतर साबित हो सकता है. हालांकि, हफ़्तों से मॉडल को बेहतर बनाने में उसे सफलता नहीं मिल रही है. ऐसे में आपको क्या करना चाहिए? यहां कुछ संभावित तरीके दिए गए हैं:
रणनीतिक. आपको समस्या को फिर से फ़्रेम करना पड़ सकता है. एक्सपेरिमेंट के फ़ेज़ में समय बिताने के बाद, आपको समस्या, डेटा, और संभावित समाधानों को बेहतर तरीके से समझने में मदद मिलती है. डोमेन के बारे में ज़्यादा जानने से, आपको समस्या को ज़्यादा सटीक तरीके से समझने में मदद मिल सकती है.
उदाहरण के लिए, हो सकता है कि आपने शुरुआत में किसी संख्या वाली वैल्यू का अनुमान लगाने के लिए, लीनियर रिग्रेशन का इस्तेमाल किया हो. माफ़ करें, काम का लीनियर रिग्रेशन मॉडल बनाने के लिए, डेटा काफ़ी अच्छा नहीं था. हो सकता है कि ज़्यादा विश्लेषण से पता चलता हो कि किसी उदाहरण के किसी खास वैल्यू से ऊपर या नीचे होने का अनुमान लगाकर, समस्या को हल किया जा सकता है. इससे, समस्या को बाइनरी क्लासिफ़िकेशन के तौर पर फिर से तैयार किया जा सकता है.
अगर प्रोग्रेस उम्मीद से कम है, तो निराश न हों. समय के साथ धीरे-धीरे सुधार करना, समस्या को हल करने का एकमात्र तरीका हो सकता है. जैसा कि पहले बताया गया है, हर हफ़्ते उतनी ही प्रोग्रेस होने की उम्मीद न करें. आम तौर पर, किसी मॉडल का प्रॉडक्शन के लिए तैयार वर्शन पाने में काफ़ी समय लगता है. मॉडल में सुधार, समय-समय पर और अचानक हो सकता है. धीमी प्रोग्रेस के बाद, अचानक परफ़ॉर्मेंस में बढ़ोतरी हो सकती है. इसके अलावा, परफ़ॉर्मेंस में अचानक बढ़ोतरी के बाद, धीमी प्रोग्रेस भी हो सकती है.
तकनीकी. गलत अनुमान का पता लगाने और उनका विश्लेषण करने में समय बिताना. कुछ मामलों में, गलत अनुमानों को अलग करके और उन मामलों में मॉडल के व्यवहार का पता लगाकर, समस्या का पता लगाया जा सकता है. उदाहरण के लिए, आपको आर्किटेक्चर या डेटा से जुड़ी समस्याएं मिल सकती हैं. अन्य मामलों में, ज़्यादा डेटा इकट्ठा करने से मदद मिल सकती है. आपको एक साफ़ सिग्नल मिल सकता है, जिससे पता चलता है कि आप सही रास्ते पर हैं. इसके अलावा, इससे ज़्यादा शोर भी हो सकता है, जिससे पता चलता है कि आपके तरीके में कोई और समस्या है.
अगर आपको किसी ऐसी समस्या पर काम करना है जिसके लिए लोगों के लेबल किए गए डेटासेट की ज़रूरत है, तो हो सकता है कि मॉडल का आकलन करने के लिए, लेबल किया गया डेटासेट इकट्ठा करना मुश्किल हो. इवैलुएशन के लिए ज़रूरी डेटासेट पाने के लिए, संसाधन ढूंढें.
ऐसा हो सकता है कि कोई समाधान न हो. अपने तरीके के लिए समय तय करें. अगर तय समयसीमा में कोई प्रोग्रेस नहीं होती है, तो उसे रोक दें. हालांकि, अगर आपके पास समस्या के बारे में कोई ज़रूरी जानकारी है, तो हो सकता है कि हम उस पर कार्रवाई करें.