इस सेक्शन में बताया गया है कि एमएल प्रोजेक्ट की शुरुआत में, इन्हें कैसे चुना जाता है:
- मॉडल आर्किटेक्चर
- ऑप्टिमाइज़र
- बैच का साइज़
- शुरुआती कॉन्फ़िगरेशन
अनुमान
इस सेक्शन में दी गई सलाह में ये बातें शामिल हैं:
- आपने पहले ही समस्या तैयार कर ली है और काफ़ी हद तक अपना ट्रेनिंग डेटा तैयार किया है.
- आपने ट्रेनिंग और टेस्टिंग पाइपलाइन पहले ही सेट अप कर ली है.
- आपने पहले ही ऐसी मेट्रिक चुनी और लागू कर ली हैं जो डिप्लॉय किए गए एनवायरमेंट में मेज़र की जाने वाली मेट्रिक को दिखाती हैं.
यह मानते हुए कि आपने पिछली सभी आवश्यकताएं पूरी कर ली हैं, अब आप मॉडल आर्किटेक्चर और ट्रेनिंग कॉन्फ़िगरेशन के लिए समय देने के लिए तैयार हैं.
मॉडल आर्किटेक्चर चुनें
आइए, इन परिभाषाओं से शुरू करते हैं:
- मॉडल आर्किटेक्चर, अनुमान लगाने का सिस्टम है. मॉडल आर्किटेक्चर में इनपुट डेटा को अनुमानों में बदलने वाला फ़्रेमवर्क होता है. हालांकि, इसमें पैरामीटर वैल्यू नहीं होती हैं. उदाहरण के लिए, 10 नोड, 5 नोड, और 3 नोड की छिपी हुई तीन लेयर वाला न्यूरल नेटवर्क एक मॉडल आर्किटेक्चर है.
- model एक मॉडल आर्किटेक्चर होता है और सभी पैरामीटर के लिए खास वैल्यू होती है. उदाहरण के लिए, मॉडल में मॉडल आर्किटेक्चर की परिभाषा में बताए गए न्यूरल नेटवर्क और हर नोड के वज़न और पूर्वाग्रह के लिए खास वैल्यू शामिल होती हैं.
- मॉडल फ़ैमिली एक टेंप्लेट है, जो हाइपर पैरामीटर के सेट के आधार पर मॉडल आर्किटेक्चर बनाने के लिए इस्तेमाल किया जाता है.
मॉडल आर्किटेक्चर चुनने का मतलब है कि अलग-अलग मॉडल का सेट (मॉडल हाइपर पैरामीटर की हर सेटिंग के लिए एक) चुनना.
जब भी हो सके, तो ऐसे दस्तावेज़ वाले कोड बेस ढूंढने की कोशिश करें जो मौजूदा समस्या की सटीक जानकारी दे सके. इसके बाद, उस मॉडल से शुरुआत करने के लिए फिर से कोशिश करें.
ऑप्टिमाइज़र चुनें
कोई भी ऑप्टिमाइज़र, मशीन लर्निंग से जुड़ी हर तरह की समस्याओं और मॉडल आर्किटेक्चर के लिए "सबसे अच्छा" नहीं होता है. यहां तक कि सिर्फ़ ऑप्टिमाइज़र की परफ़ॉर्मेंस की तुलना करना भी मुश्किल होता है. ❗हम जाने-माने और लोकप्रिय ऑप्टिमाइज़र का इस्तेमाल करने का सुझाव देते हैं. खास तौर पर, कोई नया प्रोजेक्ट शुरू करते समय ऐसा करना ज़रूरी है.
आप जिस तरह की समस्या पर काम कर रहे हैं, हम उसके लिए सबसे लोकप्रिय ऑप्टिमाइज़र चुनने का सुझाव देते हैं. हम नीचे दिए गए जाने-माने ऑप्टिमाइज़र का सुझाव देते हैं:
- SGD में ज़्यादा दिलचस्पी. हम Nesterov वैरिएंट का इस्तेमाल करने का सुझाव देते हैं.
- एडम और नडेम, इनकी तुलना में एसजीडी की तुलना में ज़्यादा सामान्य हैं. ध्यान दें कि एडम के पास चार ट्यून किए जा सकने वाले आर्ग्युमेंट हैं और वे सभी मायने रखते हैं! देखें कि एडम के हाइपर पैरामीटर को कैसे ट्यून किया जाना चाहिए?.
चुने गए ऑप्टिमाइज़र के सभी तर्कों पर ध्यान दें. ज़्यादा हाइपर पैरामीटर वाले ऑप्टिमाइज़र को आम तौर पर ज़्यादा ट्यूनिंग की ज़रूरत होती है. यह किसी प्रोजेक्ट की शुरुआत में खास तौर पर तब तकलीफ़ देने वाला होता है, जब आपको कई दूसरे हाइपर पैरामीटर (उदाहरण के लिए, लर्निंग रेट) की सबसे अच्छी वैल्यू ढूंढने की कोशिश करनी होती है. साथ ही, ऑप्टिमाइज़र वाले तर्कों को परेशानी के तौर पर देखते हैं. इसलिए, हम आपको यहां दिया गया तरीका अपनाने का सुझाव देते हैं:
- प्रोजेक्ट की शुरुआत में, कोई ऐसा ऑप्टिमाइज़र चुनें जिसमें बदलाव करने लायक
हाइपर पैरामीटर शामिल न हों. यहां दो उदाहरण दिए गए हैं:
- फ़िक्स्ड मोमेंट के साथ SGD.
- [व्यक्ति का नाम], [व्यक्ति का नाम], और बीटा2 में सुधार कर चुके हैं.
- प्रोजेक्ट के आखिरी चरणों में, ऐसे सामान्य ऑप्टिमाइज़र पर स्विच करें जो डिफ़ॉल्ट वैल्यू पर सेट करने के बजाय, ज़्यादा हाइपर पैरामीटर को ट्यून करता हो.
बैच का साइज़ चुनें
खास जानकारी: बैच का साइज़, ट्रेनिंग में लगने वाले समय को कंट्रोल करता है. पुष्टि करने के सेट की परफ़ॉर्मेंस को सीधे तौर पर ट्यून करने के लिए बैच साइज़ का इस्तेमाल न करें.
बैच साइज़ से ट्रेनिंग में लगने वाले समय और संसाधनों के इस्तेमाल की गणना करने का तरीका काफ़ी हद तक तय होता है. बैच का साइज़ बढ़ाने से, अक्सर ट्रेनिंग में लगने वाला समय कम हो जाता है, जो:
- इससे हाइपर पैरामीटर को तय समय के अंतराल में अच्छी तरह से ऑप्टिमाइज़ किया जा सकता है. इससे, एक बेहतर फ़ाइनल मॉडल बन सकता है.
- डेवलपमेंट साइकल की लेटेंसी कम होती है. इससे नए आइडिया को ज़्यादा बार टेस्ट किया जा सकता है.
बैच का साइज़ बढ़ाने से, संसाधन का इस्तेमाल कम या ज़्यादा हो सकता है या संसाधन के इस्तेमाल में कोई बदलाव नहीं हो सकता.
पुष्टि करने के सेट की परफ़ॉर्मेंस के लिए, बैच साइज़ को ट्यूनेबल हाइपर पैरामीटर के तौर पर न मानें. अगर ये सभी शर्तें पूरी होती हैं, तो मॉडल की परफ़ॉर्मेंस, बैच के साइज़ पर निर्भर नहीं होनी चाहिए:
- सभी ऑप्टिमाइज़र हाइपर पैरामीटर अच्छी तरह से ट्यून किए गए हैं.
- नियमित तौर पर कॉन्टेंट दिखाने के लिए काफ़ी है और इसे ट्यून किया गया है.
- ट्रेनिंग के चरणों की संख्या काफ़ी है.
किसी भी बैच साइज़ का इस्तेमाल करके, एक जैसी आखिरी परफ़ॉर्मेंस हासिल की जा सकती है (Shallue et al. 2018 देखें और पुष्टि करने के सेट की परफ़ॉर्मेंस को सीधे तौर पर बेहतर बनाने के लिए, बैच के साइज़ को ट्यून क्यों नहीं किया जाना चाहिए?.
बैच के सही साइज़ तय करना और ट्रेनिंग की क्षमता का अनुमान लगाना
किसी मॉडल और ऑप्टिमाइज़र के लिए, उपलब्ध हार्डवेयर आम तौर पर कई तरह के बैच साइज़ के साथ काम करता है. सीमित करने का कारक आम तौर पर ऐक्सेलरेटर मेमोरी होती है. अफ़सोस की बात यह है कि यह हिसाब लगाना मुश्किल हो सकता है कि पूरे ट्रेनिंग प्रोग्राम को चलाए बिना या कम से कम कंपाइल किए बिना, मेमोरी में कौनसे बैच साइज़ फ़िट होंगे. इसका सबसे आसान समाधान आम तौर पर अलग-अलग बैच के साइज़ (उदाहरण के लिए, 2 की पावर बढ़ाना) में ट्रेनिंग जॉब को चलाना है. ऐसा तब तक किया जाता है, जब तक कि कोई जॉब उपलब्ध मेमोरी को पार न कर जाए. हर बैच के साइज़ के लिए, इतनी देर तक ट्रेनिंग करें कि ट्रेनिंग की क्षमता का सही अनुमान लगाया जा सके:
ट्रेनिंग थ्रूपुट = हर सेकंड में प्रोसेस किए गए उदाहरणों की संख्या
या इसके बराबर, हर चरण में लगने वाला समय:
हर चरण के हिसाब से समय = बैच का साइज़ / ट्रेनिंग की क्षमता
अगर बैच का साइज़ दोगुना नहीं है, तो ट्रेनिंग की क्षमता भी दोगुनी या कम से कम दोगुनी होनी चाहिए. इसी तरह, बैच का साइज़ बढ़ने के साथ हर चरण का समय स्थिर या कम से कम करीब स्थिर होना चाहिए. अगर ऐसा नहीं है, तो ट्रेनिंग पाइपलाइन में एक बॉटलनेक होता है, जैसे कि I/O या कंप्यूट नोड के बीच सिंक करना. आगे बढ़ने से पहले, समस्या का पता लगाकर उसे ठीक करें.
अगर ट्रेनिंग थ्रूपुट सिर्फ़ कुछ ज़्यादा से ज़्यादा बैच साइज़ तक बढ़ता है, तो तो सिर्फ़ बैच साइज़ को ज़्यादा से ज़्यादा जितना बड़ा किया जा सकता है, पर ही विचार करें, भले ही हार्डवेयर एक बड़े बैच साइज़ के साथ काम करता हो. बड़े बैच साइज़ का इस्तेमाल करने से मिलने वाले सभी फ़ायदों में यह माना जाता है कि ट्रेनिंग की क्षमता बढ़ जाती है. अगर समस्या ठीक नहीं होती है, तो बॉटलनेक को ठीक करें या छोटे बैच साइज़ का इस्तेमाल करें.
ग्रेडिएंट कलेक्शन, हार्डवेयर के मुकाबले बैच के बड़े साइज़ को सिम्युलेट करता है. इसलिए, इससे थ्रूपुट का कोई फ़ायदा नहीं मिलता. आम तौर पर, आपको लागू किए गए काम में ग्रेडिएंट इकट्ठा होने से बचना चाहिए.
मॉडल या ऑप्टिमाइज़र को बदलने के दौरान, आपको हर बार ये चरण दोहराने पड़ सकते हैं. उदाहरण के लिए, किसी दूसरे मॉडल आर्किटेक्चर का इस्तेमाल करके, मेमोरी में ज़्यादा बड़े बैच का साइज़ फ़िट किया जा सकता है.
ट्रेनिंग में लगने वाले समय को कम करने के लिए, बैच का साइज़ चुनें
ट्रेनिंग में लगने वाले समय की परिभाषा यहां दी गई है:
- ट्रेनिंग में लगने वाला समय = (हर चरण में लगने वाला समय) x (कदमों की कुल संख्या)
सभी संभावित बैच साइज़ के लिए, हर चरण में लगने वाले समय को करीब-करीब एक जैसा माना जा सकता है. ऐसा तब होता है, जब:
- पैरलल कंप्यूटेशन से कोई ओवरहेड नहीं होता.
- ट्रेनिंग में आने वाली सभी समस्याओं की पहचान करके उन्हें ठीक किया गया है. (ट्रेनिंग में आने वाली रुकावटों की पहचान करने का तरीका जानने के लिए, पिछला सेक्शन देखें. व्यावहारिक रूप से, बैच का साइज़ बढ़ाने में आम तौर पर कम से कम कुछ ओवरहेड होते हैं.
बैच का साइज़ बढ़ने पर, परफ़ॉर्मेंस के एक तय लक्ष्य तक पहुंचने के लिए कदमों की कुल संख्या कम होती जाती है. हालांकि, बैच का साइज़ बदलते समय, सभी ज़रूरी हाइपर पैरामीटर फिर से चालू किए जाते हैं. (Shallue et al. 2018 देखें.) उदाहरण के लिए, बैच का साइज़ दोगुना करने से, ज़रूरी चरणों की कुल संख्या आधी हो सकती है. इस संबंध को सही स्केलिंग कहा जाता है. इसे ज़रूरी बैच साइज़ तक सभी बैच साइज़ के लिए रखा जाना चाहिए.
ज़रूरी बैच साइज़ के अलावा, बैच का साइज़ बढ़ाने से रिटर्न में कमी आती है. इसका मतलब है कि बैच का साइज़ बढ़ाने से ट्रेनिंग के चरणों की संख्या कम नहीं होती, लेकिन उसमें कोई बढ़ोतरी नहीं होती. इसलिए, ट्रेनिंग में लगने वाले समय को कम करने वाला बैच साइज़ आम तौर पर सबसे बड़ा बैच साइज़ होता है. इससे ट्रेनिंग के लिए ज़रूरी चरण की संख्या कम हो जाती है. बैच का साइज़ डेटासेट, मॉडल, और ऑप्टिमाइज़र पर निर्भर करता है. साथ ही, यह एक खुली समस्या है कि हर नई समस्या के लिए प्रयोग के तौर पर खोजने के अलावा, इसकी गिनती कैसे की जाए. 🤖
बैच के साइज़ की तुलना करते समय, यहां दी गई चीज़ों के बीच अंतर का ध्यान रखें:
- उदाहरण के लिए बजट या epoch budget में से दिया गया कोई भी कैंपेन, ट्रेनिंग के उदाहरण प्रज़ेंटेशन की संख्या को ठीक करते हुए, सभी प्रयोगों को चलाता है.
- कदम का बजट—ट्रेनिंग के चरणों की तय संख्या के साथ सभी प्रयोग चलाना.
Epoch बजट के साथ बैच साइज़ की तुलना करने पर, सिर्फ़ सबसे सही स्केलिंग रिजीम की जांच होती है. भले ही, बड़े बैच साइज़ अब भी ट्रेनिंग के ज़रूरी चरणों को कम करके, तेज़ी से काम करने वाले हों. अक्सर, उपलब्ध हार्डवेयर के साथ काम करने वाला सबसे बड़ा बैच साइज़, ज़रूरी बैच साइज़ से छोटा होता है. इसलिए, सबसे अच्छे बैच (प्रयोग को चलाए बिना) का इस्तेमाल करना चाहिए.अगर ट्रेनिंग का समय बढ़ जाता है, तो बड़े बैच साइज़ का इस्तेमाल करने का कोई फ़ायदा नहीं है.
संसाधनों का इस्तेमाल कम करने के लिए बैच का साइज़ चुनें
बैच का साइज़ बढ़ाने के लिए, दो तरह की संसाधन लागत का इस्तेमाल किया जाता है:
- शुरुआती कीमत. उदाहरण के लिए, मल्टी-जीपीयू / मल्टी-टीपीयू ट्रेनिंग लागू करने के लिए, नया हार्डवेयर खरीदना या ट्रेनिंग पाइपलाइन को नए सिरे से लिखना.
- इस्तेमाल की लागत. उदाहरण के लिए, टीम के रिसॉर्स बजट के लिए बिलिंग, क्लाउड सेवा देने वाली कंपनी से बिलिंग, बिजली / रखरखाव का खर्च.
अगर बैच का साइज़ बढ़ाने के लिए शुरुआती कीमत काफ़ी ज़्यादा है, तो बैच का साइज़ तब तक बढ़ाना बेहतर हो सकता है, जब तक कि प्रोजेक्ट मैच नहीं हो जाता. साथ ही, लागत और फ़ायदे के हिसाब से ट्रेड-ऑफ़ का आकलन आसानी से किया जा सकता है. एक से ज़्यादा होस्ट वाले समानांतर ट्रेनिंग प्रोग्राम लागू करने से, bugs और छोटी समस्याएं आ सकती हैं. इसलिए, आसान पाइपलाइन से शुरुआत करना बेहतर होगा. दूसरी ओर, ट्रेनिंग के समय में तेज़ी से बढ़ना, उस प्रोसेस की शुरुआत में काफ़ी मददगार हो सकता है, जहाँ बहुत सारे ट्यूनिंग एक्सपेरिमेंट की ज़रूरत हो.
हम संसाधन के इस्तेमाल की कुल लागत (जिसमें अलग-अलग तरह की कई तरह की लागतें शामिल हो सकती हैं) को नीचे बताए गए तरीके से कैलकुलेट किया जाता है:
संसाधन की खपत = हर चरण में संसाधन का इस्तेमाल x कदमों की कुल संख्या
बैच का साइज़ बढ़ाने से आम तौर पर, चरणों की कुल संख्या कम हो जाती है. संसाधन का इस्तेमाल बढ़ता या घटता है, यह इस बात पर निर्भर करता है कि हर चरण में चीज़ों की खपत किस तरह बदलती है. बैच के साइज़ पर इस तरह से असर पड़ता है:
- बैच का साइज़ बढ़ाने से, संसाधन का इस्तेमाल कम हो सकता है. उदाहरण के लिए, अगर बड़े बैच साइज़ वाला हर चरण उसी हार्डवेयर पर चलाया जा सकता है जिस पर छोटे बैच साइज़ (हर चरण में समय में सिर्फ़ थोड़ी सी बढ़ोतरी के साथ) किया जा सकता है, तो हर चरण में संसाधन के इस्तेमाल में होने वाली बढ़ोतरी, चरणों की संख्या कम करने से खत्म हो सकती है.
- हो सकता है कि बैच का साइज़ बढ़ाने से, संसाधन के इस्तेमाल में बदलाव न हो. उदाहरण के लिए, अगर बैच का साइज़ दोगुना करने से ज़रूरी चरणों की संख्या आधी हो जाती है और इस्तेमाल किए गए जीपीयू की संख्या दोगुनी हो जाती है, तो कुल खपत (जीपीयू-घंटे के हिसाब से) में कोई बदलाव नहीं होता.
- बैच का साइज़ बढ़ाने से रिसॉर्स का इस्तेमाल बढ़ सकता है. उदाहरण के लिए, अगर बैच का साइज़ बढ़ाने के लिए, अपग्रेड किए गए हार्डवेयर की ज़रूरत है, तो हर चरण में इस्तेमाल की जाने वाली बढ़ोतरी से, चरणों की संख्या में कमी भी हो सकती है.
बैच का साइज़ बदलने के लिए, ज़्यादातर हाइपर पैरामीटर को फिर से ठीक करना ज़रूरी होता है
ज़्यादातर हाइपर पैरामीटर की सबसे अच्छी वैल्यू, बैच के साइज़ के हिसाब से संवेदनशील होती हैं. इसलिए, आम तौर पर बैच का साइज़ बदलने के लिए, ट्यूनिंग प्रोसेस फिर से शुरू करनी पड़ती है. ऐसे हाइपर पैरामीटर जो बैच साइज़ के साथ सबसे ज़्यादा इंटरैक्ट करते हैं, इसलिए ज़रूरी है कि हर बैच साइज़ के लिए अलग-अलग ट्यून करें. ये पैरामीटर इस तरह हैं:
- ऑप्टिमाइज़र हाइपर पैरामीटर (उदाहरण के लिए, सीखने की दर और मोमेंट)
- रेगुलराइज़ेशन हाइपर पैरामीटर
प्रोजेक्ट की शुरुआत में बैच का साइज़ चुनते समय इस बात का ध्यान रखें. अगर बाद में आपको बैच के किसी अलग साइज़ पर स्विच करना हो, तो नए बैच साइज़ के लिए अन्य हाइपर पैरामीटर को फिर से ट्यून करना मुश्किल और समय लेने वाला हो सकता है.
बैच मानदंड, बैच साइज़ के साथ कैसे इंटरैक्ट करता है
बैच नॉर्मल मुश्किल होता है. आम तौर पर, आंकड़ों का कंप्यूट करने के लिए ग्रेडिएंट कंप्यूटेशन से अलग बैच साइज़ का इस्तेमाल करना चाहिए. ज़्यादा जानकारी के लिए बैच नॉर्मलाइज़ेशन लागू करने की जानकारी देखें.
शुरुआती कॉन्फ़िगरेशन चुनें
हाइपर पैरामीटर ट्यूनिंग का पहला चरण इनके लिए शुरुआती पॉइंट तय करता है:
- मॉडल कॉन्फ़िगरेशन (जैसे, लेयर की संख्या)
- ऑप्टिमाइज़र हाइपर पैरामीटर (उदाहरण, लर्निंग रेट)
- ट्रेनिंग के चरणों की संख्या
यह शुरुआती कॉन्फ़िगरेशन तय करने के लिए, मैन्युअल रूप से कॉन्फ़िगर की गई कुछ ट्रेनिंग रन और ट्रायल-एंड-एरर की ज़रूरत होती है.
हमारे दिशा-निर्देश का सिद्धांत इस तरह है:
ऐसा आसान, तेज़, और कम संसाधन इस्तेमाल करने वाला कॉन्फ़िगरेशन ढूंढें जिससे सही परफ़ॉर्मेंस मिलती है.
कहां:
- सरल का मतलब है, पाइपलाइन की ग़ैर-ज़रूरी सुविधाओं से बचना, जैसे कि खास तरह के रेगुलराइज़ेशन या वास्तुशिल्प की तरकीबें. उदाहरण के लिए, ऐसी पाइपलाइन जो ड्रॉपआउट रेगुलराइज़ेशन के बिना हो या ड्रॉपआउट को नियमित करने की सुविधा बंद हो
- सही परफ़ॉर्मेंस, समस्या पर निर्भर करती है. हालांकि, कम से कम एक उचित प्रशिक्षित मॉडल, पुष्टि करने के लिए सेट किए गए रैंडम तरीके की तुलना में बेहतर परफ़ॉर्म करता है.
एक ऐसा शुरुआती कॉन्फ़िगरेशन चुनना जो तेज़ हो और कम संसाधन इस्तेमाल करता हो, जिससे हाइपर पैरामीटर ट्यूनिंग ज़्यादा बेहतर तरीके से होती है. उदाहरण के लिए, छोटे मॉडल से शुरू करें.
ट्रेनिंग के चरणों की संख्या चुनने पर, इस तनाव को संतुलित किया जाता है:
- ज़्यादा चरणों के लिए ट्रेनिंग लेने से परफ़ॉर्मेंस बेहतर हो सकती है. साथ ही, हाइपर पैरामीटर ट्यूनिंग को आसान बनाया जा सकता है. (ज़्यादा जानकारी के लिए, Shallue et al. 2018 देखें).
- इसके उलट, कम कदमों वाली ट्रेनिंग का मतलब है कि हर ट्रेनिंग तेज़ होती है और कम संसाधनों का इस्तेमाल करती है. इससे साइकल के बीच का समय कम होता है, जिससे ट्यूनिंग क्षमता बढ़ती है. साथ ही, ज़्यादा प्रयोग चलाए जा सकते हैं. इसके अलावा, अगर प्रोजेक्ट की शुरुआत में चरणों के लिए ग़ैर-ज़रूरी बजट चुना जाता है, तो बाद में प्रोजेक्ट में इसे बदलना मुश्किल हो सकता है. उदाहरण के लिए, इतने चरणों के लिए लर्निंग रेट को शेड्यूल करने के बाद.