हर ट्रेनिंग रन के लिए चरणों की संख्या तय करना

ट्रेनिंग के वर्कलोड दो तरह के होते हैं:

• कंप्यूट-बाउंड
• कंप्यूटिंग की ज़रूरत नहीं होती

कंप्यूट-बाउंड ट्रेनिंग में, ट्रेनिंग में बिताए जा सकने वाले समय की सीमा होती है. यह सीमा, ट्रेनिंग के लिए उपलब्ध डेटा या किसी अन्य फ़ैक्टर पर निर्भर नहीं करती. दूसरे शब्दों में, ट्रेनिंग के लिए "सबसे सही" समय हमेशा "उतना होता है जितना आपके पास है." अगर आप किसी तरह ज़्यादा देर तक या ज़्यादा असरदार तरीके से ट्रेनिंग कर सकते हैं, तो ट्रेनिंग लॉस कम होना चाहिए. (सही ट्यूनिंग के साथ, पुष्टि करने के दौरान होने वाले नुकसान में भी कमी आनी चाहिए.)

कंप्यूटिंग की क्षमता पर निर्भर ट्रेनिंग को तेज़ करने का मतलब है कि ट्रेनिंग को बेहतर बनाया जा रहा है. हालांकि, सिर्फ़ इसलिए कि कोई वर्कलोड कंप्यूटिंग की क्षमता पर निर्भर करता है, इसका मतलब यह नहीं है कि ट्रेनिंग को ज़्यादा समय तक या तेज़ी से करने से ही नतीजे बेहतर होंगे.

जब ट्रेनिंग में कंप्यूटिंग की ज़रूरत नहीं होती है, तब ट्रेनिंग को अपनी ज़रूरत के हिसाब से चलाया जा सकता है. हालांकि, मॉडल को ज़्यादा समय तक ट्रेन करने से ज़्यादा फ़ायदा नहीं मिल सकता या इससे ओवरफ़िटिंग भी हो सकती है. जब ट्रेनिंग में कंप्यूटिंग की ज़रूरत नहीं होती:

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

कोई वर्कलोड कंप्यूटिंग से जुड़ा है या नहीं, इससे कोई फ़र्क़ नहीं पड़ता. आम तौर पर, ग्रेडिएंट के वैरिएंस (बैच के हिसाब से) को बढ़ाने वाले तरीकों से ट्रेनिंग की प्रोसेस धीमी हो जाती है. इसलिए, किसी खास पुष्टि करने वाले नुकसान तक पहुंचने के लिए, ट्रेनिंग के चरणों की संख्या बढ़ सकती है. इनमें से किसी भी वजह से, ग्रेडिएंट वेरियंस ज़्यादा हो सकता है:

• बैच का साइज़ छोटा करके.
• डेटा ऑगमेंटेशन जोड़ा गया.
• कुछ तरह के रेगुलराइज़ेशन जोड़ना. जैसे, ड्रॉपआउट रेगुलराइज़ेशन.

यह तय करें कि ट्रेनिंग कब तक करनी है, जब ट्रेनिंग में कंप्यूटिंग की ज़रूरत नहीं होती

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

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

किसी स्टडी में max_train_steps नंबर को कभी भी ट्यून न करें. इसके बजाय, कोई वैल्यू चुनें और सभी ट्रायल के लिए उसी वैल्यू का इस्तेमाल करें. इन ट्रायल से, ट्रेनिंग के उस चरण का पता लगाएं जिसे रेट्रोस्पेक्टिव चेकपॉइंट सिलेक्शन, max_train_steps के विकल्प को बेहतर बनाने के लिए ढूंढता है.

उदाहरण के लिए, अगर सबसे अच्छा चरण हमेशा ट्रेनिंग के पहले 10% के दौरान होता है, तो चरणों की ज़्यादा से ज़्यादा संख्या बहुत ज़्यादा होती है. इसके अलावा, अगर सबसे अच्छा चरण लगातार ट्रेनिंग के आखिरी 25% में होता है, तो आपको ज़्यादा समय तक ट्रेनिंग करने और डीके शेड्यूल को फिर से ट्यून करने से फ़ायदा मिल सकता है. आर्किटेक्चर या डेटा में बदलाव होने पर, ट्रेनिंग के चरणों की सही संख्या बदल सकती है. उदाहरण के लिए, डेटा ऑगमेंटेशन जोड़ने पर. अगले सेक्शन में, max_train_steps के लिए शुरुआती कैंडिडेट वैल्यू चुनने का तरीका बताया गया है. यह वैल्यू, ट्रेनिंग सेट को "पूरी तरह से फ़िट" करने के लिए ज़रूरी चरणों की संख्या के आधार पर तय की जाती है. इसके लिए, लर्निंग रेट को स्थिर रखा जाता है.

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

अगर ट्रेनिंग प्रोसेस में किसी तरह का सुधार होता है, तो max_train_steps को कम किया जा सकता है. उदाहरण के लिए, बेहतर तरीके से ट्यून किए गए ऑप्टिमाइज़र या बेहतर तरीके से ट्यून किए गए लर्निंग रेट शेड्यूल की मदद से.

लर्निंग रेट स्वीप का इस्तेमाल करके, max_train_steps के लिए शुरुआती उम्मीदवार चुनने का एल्गोरिदम

लर्निंग रेट स्वीप एल्गोरिदम की मदद से, max_train_steps के लिए शुरुआती उम्मीदवार चुना जा सकता है. नीचे दिए गए एल्गोरिदम में यह माना गया है कि ट्रेनिंग सेट को न सिर्फ़ "पूरी तरह से" फ़िट किया जा सकता है, बल्कि ऐसा लर्निंग रेट के तय शेड्यूल का इस्तेमाल करके भी किया जा सकता है.

1. अगर पूरे ट्रेनिंग सेट को पूरी तरह से फ़िट किया जा सकता है, तो एक ऐसा कॉन्फ़िगरेशन (max_train_steps की किसी वैल्यू के साथ) मौजूद होना चाहिए जो ट्रेनिंग सेट को पूरी तरह से फ़िट करता हो. इस तरह का कोई कॉन्फ़िगरेशन ढूंढें और max_train_steps की वैल्यू को शुरुआती पॉइंट N के तौर पर इस्तेमाल करें.
2. डेटा ऑगमेंटेशन और रेगुलराइज़ेशन के बिना, लगातार लर्निंग रेट स्वीप (यानी कि लर्निंग रेट के लिए ग्रिड सर्च) चलाएं. इसमें हर ट्रायल को � steps के लिए ट्रेन किया जाता है.N लर्निंग रेट स्वीप में सबसे तेज़ ट्रायल के लिए, ट्रेनिंग की परफ़ॉर्मेंस को बेहतर बनाने के लिए ज़रूरी चरणों की संख्या, max_train_steps के लिए आपका शुरुआती अनुमान होना चाहिए.

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

तय करें कि मॉडल को कितनी देर तक ट्रेनिंग देनी है, जब ट्रेनिंग में कंप्यूटिंग संसाधनों का इस्तेमाल ज़्यादा हो रहा हो

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

• कम समय के ज़्यादा एक्सपेरिमेंट करके, मॉडल को ज़्यादा असरदार तरीके से ट्यून किया जा सकता है. साथ ही, "प्रोडक्शन लेंथ" वाले सबसे लंबे एक्सपेरिमेंट को उन मॉडल के लिए रिज़र्व किया जा सकता है जिन्हें आपको लॉन्च करना है.
• जब ट्रेनिंग में लगने वाला समय आपकी तय सीमा के करीब पहुंच जाता है, तब ट्यूनिंग एक्सपेरिमेंट, लॉन्च किए जाने वाले संभावित उम्मीदवारों के लिए ज़्यादा काम के हो जाते हैं. हालांकि, ऐसे एक्सपेरिमेंट कम किए जा सकते हैं.
• ऐसा हो सकता है कि आपको प्रोडक्शन लेंथ के सिर्फ़ ~10% हिस्से को ट्रेन करने पर ही कई सवालों के जवाब मिल जाएं. हालांकि, इस समयसीमा में मिले नतीजे, प्रॉडक्शन लेंथ के 20% हिस्से पर किए गए एक्सपेरिमेंट पर लागू नहीं हो सकते. 100% हिस्से पर किए गए एक्सपेरिमेंट पर तो बिलकुल भी नहीं.

कई राउंड में ट्यूनिंग करना एक अच्छा तरीका है. इसमें हर बार ट्रेनिंग के चरणों की सीमा बढ़ाई जाती है. जितने चाहें उतने राउंड चलाए जा सकते हैं. हालांकि, आम तौर पर एक से तीन राउंड सबसे सही होते हैं. असल में, कम समय में समस्या को ज़्यादा से ज़्यादा समझने की कोशिश करें. इसके लिए, इन बातों का ध्यान रखें:

• ट्यूनिंग की बारीकी.
• सबसे लंबी दौड़ के लिए, सही फ़ॉर्म में होना.

जब किसी तय समयसीमा में किए गए ट्रायल से काम की अहम जानकारी मिल जाए, तो ट्रेनिंग का समय बढ़ाएं और ट्यूनिंग जारी रखें. साथ ही, ज़रूरत के हिसाब से कम समय में किए गए ट्रायल से मिले नतीजों की दोबारा जांच करें. हमारा सुझाव है कि शुरुआत में, दो बार ट्यूनिंग करें:

• पहला राउंड: कम समय तक चलने वाले एक्सपेरिमेंट, ताकि अच्छे मॉडल और ऑप्टिमाइज़र के हाइपरपैरामीटर का पता लगाया जा सके.
• दूसरा राउंड: फ़ाइनल मॉडल पाने के लिए, अच्छे हाइपरपैरामीटर पॉइंट पर बहुत कम समय के लिए रन किए जाते हैं.

पहले राउंड से दूसरे राउंड में जाने के लिए, सबसे बड़ा सवाल यह है कि:

लर्निंग रेट कम होने के शेड्यूल को कैसे अडजस्ट किया जाता है.

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

पहला राउंड: ट्रेनिंग के लिए कई छोटी-छोटी दौड़ें

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

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

दूसरा राउंड: कम बार दौड़ना, लेकिन ज़्यादा देर तक दौड़ना

पहले राउंड के सबसे अच्छे हाइपरपैरामीटर कॉन्फ़िगरेशन को चलाएं.

अनुमान लगाना: 🤖 ज़्यादा लर्निंग रेट पर ट्रेनिंग की अवधि बढ़ाने के लिए, अतिरिक्त चरणों का इस्तेमाल करें. उदाहरण के लिए, अगर लीनियर शेड्यूल का इस्तेमाल किया जा रहा है, तो पहले राउंड से ही, परफ़ॉर्मेंस में गिरावट की अवधि को तय रखें. साथ ही, शुरुआत में lr की अवधि को बढ़ाएं. कोसाइन डिके के लिए, पहले राउंड से बेस lr को बनाए रखें और max_train_steps को Training Compute-Optimal Large Language Models में बताए गए तरीके से बढ़ाएं.

इन सभी स्थितियों में, टीमों के लिए ट्रेनिंग के अतिरिक्त राउंड फ़ायदेमंद हो सकते हैं:

• बहुत मैच्योर मॉडलिंग
• ट्यूनिंग पाइपलाइन
• प्रोडक्शन ट्रेनिंग रन बहुत लंबे और महंगे होते हैं

हालांकि, अतिरिक्त ट्रेनिंग रन अक्सर काम के नहीं होते.

हम पहले ही बता चुके हैं कि राउंड 1 से राउंड 2 में कैसे ट्रांसफ़र किया जाता है. अगर आपको विश्लेषण के समय से कोई फ़र्क़ नहीं पड़ता और कंप्यूटिंग संसाधनों का बेहतर तरीके से इस्तेमाल करना आपकी मुख्य चिंता है, तो हमारा सुझाव है कि आप ट्यूनिंग के कई अलग-अलग राउंड में, ट्रेनिंग रन की अवधि को तेज़ी से बढ़ाएं. इससे, स्टडी को पूरा करने में लगने वाला कुल समय भी बढ़ जाएगा:

• हर राउंड में, यह पक्का करें कि आपके चुने गए विकल्प से अच्छे नतीजे मिलते रहें.
• नए आइडिया को एक ऐसी पाइपलाइन में डालें जो उन्हें चरण i से चरण i+1 तक ले जाए. इस दौरान, लंबे समय तक चलने वाले एक्सपेरिमेंट का इस्तेमाल करके, उनके जोखिम को धीरे-धीरे कम किया जाए.