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