एमएल प्रोजेक्ट की प्लानिंग, सामान्य सॉफ़्टवेयर इंजीनियरिंग प्रोजेक्ट की प्लानिंग से अलग होती है. एमएल प्रोजेक्ट आम तौर पर नॉन-लिनियर होते हैं और इनमें अनिश्चितता की डिग्री अलग-अलग होती है. इसके लिए, बार-बार कोशिश करने और प्रयोग करने की ज़रूरत होती है.
प्रोजेक्ट में अनिश्चितता
शुरुआती प्लानिंग करना मुश्किल हो सकता है, क्योंकि प्रोजेक्ट शुरू करते समय आम तौर पर सबसे सही तरीका पता नहीं चलता. इस वजह से, टाइमलाइन का अनुमान लगाना मुश्किल हो जाता है.
हाल ही में Kaggle के एक कॉम्पिटीशन में, एमएल प्रोजेक्ट की अनिश्चितता के बारे में बताया गया था. प्रतियोगिता के शुरुआती कुछ हफ़्तों में, 350 टीमों ने हिस्सा लिया. टॉप टीमों ने बेंचमार्क के आधार पर किए गए अनुमान की क्वालिटी को 35% से बढ़ाकर 65% कर दिया. अगले दो हफ़्तों में, इस समस्या पर काम करने वाली टीमों की संख्या 350 से बढ़कर 1,400 हो गई. हालांकि, सबसे अच्छे मॉडल ने सिर्फ़ 68% की अनुमान की क्वालिटी हासिल की.
तीसरे चित्र में, एमएल डेवलपमेंट में आने वाली अनिश्चितता को दिखाया गया है. इसमें, एमएल मॉडल बनाने में लगने वाले समय में काफ़ी बढ़ोतरी हुई है, लेकिन मॉडल की क्वालिटी में बहुत कम फ़र्क़ पड़ा है.
तीसरी इमेज. दो हफ़्ते के अंदर, इस समस्या पर काम करने वाली टीमों की संख्या चार गुना बढ़ गई, लेकिन मॉडल की क्वालिटी में कोई बदलाव नहीं हुआ. इससे पता चलता है कि किसी समस्या को हल करने के लिए, एमएल के इस्तेमाल में लगने वाले समय का अनुमान लगाना मुश्किल है.
दूसरे शब्दों में, एक हज़ार से ज़्यादा टीमों ने अलग-अलग तरह के डेटा ट्रांसफ़ॉर्मेशन, आर्किटेक्चर, और हाइपरपैरामीटर के साथ प्रयोग किया. हालांकि, इनमें से किसी टीम को भी सिर्फ़ 68% अनुमान की क्वालिटी वाला मॉडल बनाने में सफलता मिली.
इंडस्ट्री से जुड़े एक उदाहरण से, एमएल प्रोजेक्ट की गैर-लीनियरिटी के बारे में पता चलता है. इसमें, इनपुट के हिसाब से आउटपुट नहीं मिलता. किसी मॉडल को 90% सटीक अनुमान देने के लिए, दो टीमों को कई महीने लगे. हालांकि, कई टीमों को मॉडल को प्रोडक्शन के लिए तैयार करने में पांच साल से ज़्यादा समय लगा. इस दौरान, अनुमान की क्वालिटी 99.9% तक पहुंच गई.
इन उदाहरणों से पता चलता है कि प्रोडक्शन के लिए तैयार एमएल एक एक्सप्लोरेटिव प्रोसेस है. इसके लिए, साइंटिफ़िक और इंजीनियरिंग के नज़रिए की ज़रूरत होती है.
एक्सपेरिमेंटल तरीका
ज़्यादातर मामलों में, एमएल डेवलपमेंट, पारंपरिक सॉफ़्टवेयर इंजीनियरिंग के मुकाबले, एक्सपेरिमेंट करने जैसा होता है. एमएल के लिए, अलग-अलग सुविधाओं को टेस्ट करना, कई तरह के आर्किटेक्चर आज़माना, और हाइपरपैरामीटर को सही तरीके से ट्यून करना ज़रूरी है. एक्सपेरिमेंट के काम करने की कोई गारंटी नहीं होती. इसलिए, एक्सपेरिमेंटल फ़्रेमवर्क का इस्तेमाल करके प्लान बनाना सबसे अच्छा होता है.
आइए, एक सामान्य सॉफ़्टवेयर इंजीनियरिंग प्लान देखें और जानें कि यह एमएल प्रोजेक्ट प्लान से कैसे अलग है.
सॉफ़्टवेयर इंजीनियरिंग प्रोजेक्ट की प्लानिंग करना
किसी सामान्य सॉफ़्टवेयर इंजीनियरिंग प्लान में, ज़रूरी शर्तें तय की जाती हैं, कॉम्पोनेंट की जानकारी दी जाती है, काम में लगने वाले समय का अनुमान लगाया जाता है, और काम को शेड्यूल किया जाता है. समस्या को हल करने का तरीका साफ़ तौर पर बताया गया हो. उदाहरण के लिए, इंजीनियर अक्सर यह जानते हैं कि डिज़ाइन के स्पेसिफ़िकेशन के मुताबिक ऐप्लिकेशन बनाने के लिए, उन्हें कौनसे टास्क पूरे करने होंगे.
किसी टास्क को पूरा करने में लगने वाले समय का अनुमान लगाते समय, यह एआई मिलते-जुलते प्रोजेक्ट के आधार पर काम का अनुमान लगा सकता है. हालांकि, कभी-कभी चुनौतियां आती हैं. जैसे, अनजान डिपेंडेंसी या बदलती ज़रूरतें. इनकी वजह से, अनुमान लगाना मुश्किल हो सकता है. हालांकि, आम तौर पर समस्या को हल करने का एक तरीका मौजूद होता है.
इसके उलट, एमएल प्रोजेक्ट के लिए आम तौर पर कोई एक साफ़ रास्ता नहीं होता.
एमएल प्रोजेक्ट की प्लानिंग करना
एमएल के ज़्यादातर प्रोजेक्ट के लिए, आपको सबसे अच्छा समाधान तब मिलेगा, जब आप अलग-अलग तरीकों को आज़माकर देखेंगे. आम तौर पर, समस्या को हल करने से पहले आपको यह पता नहीं होता कि उसका सबसे सही समाधान क्या है. उदाहरण के लिए, सबसे सही समाधान का आर्किटेक्चर, कोई आसान लीनियर मॉडल, न्यूरल नेट या फ़ैसला लेने वाला ट्री हो सकता है. हर तरीके को आज़माकर ही, सबसे अच्छा समाधान पाया जा सकता है.
इस वजह से, प्लान बनाना मुश्किल हो जाता है. जैसा कि हमने पहले बताया था, किसी एमएल प्रोजेक्ट को पूरा करने में लगने वाले समय का अनुमान लगाना मुश्किल होता है. समस्या को हल करने की कोशिश करने पर ही, आपको यह पता चल सकता है कि समाधान के लिए कितना समय और संसाधनों की ज़रूरत पड़ सकती है.
एमएल से जुड़े काम की रणनीतियां बनाने के लिए, यहां कुछ सुझाव दिए गए हैं:
काम के लिए समय तय करें. टास्क पूरे करने या किसी खास समस्या का हल करने के लिए, समयसीमा सेट करें. उदाहरण के लिए, यह तय करने के लिए दो हफ़्ते का समय दिया जा सकता है कि आपको सही तरह का डेटा मिल सकता है या नहीं. अगर आपको डेटा मिल जाता है, तो दो हफ़्ते और इंतज़ार करें. इससे आपको यह पता चलेगा कि क्या किसी आसान मॉडल से यह पता चलता है कि एमएल का समाधान काम का है या नहीं. अगर कोई आसान मॉडल काम नहीं करता है, तो नेटल नेट आज़माने के लिए दो हफ़्ते और दिए जा सकते हैं. हर समयसीमा के आखिर में, आपके पास ज़्यादा जानकारी होगी, ताकि यह तय किया जा सके कि समस्या को हल करने के लिए संसाधनों का इस्तेमाल करना जारी रखना सही है या नहीं.
प्रोजेक्ट की ज़रूरी शर्तों को कम करें. अगर कोई एमएल समाधान बेहतरीन लगता है, लेकिन वह आपके प्रॉडक्ट या सेवा के लिए ज़रूरी सुविधा नहीं है, तो उसकी ज़रूरी शर्तों को कम करें. उदाहरण के लिए, अगली तिमाही के काम की योजना बनाते समय, आपके पास किसी बहुत आसान तरीके को आज़माने का विकल्प हो सकता है. इसके बाद, अगली तिमाहियों में, आपके पास इस समाधान को बार-बार बेहतर बनाने का विकल्प होता है. कई टीमों ने लंबे समय तक लगातार सुधार करके, एमएल के असरदार समाधानों को लागू किया है.
इंटर्न या नए कर्मचारी के लिए प्रोजेक्ट. किसी इंटर्न या नए कर्मचारी को एमएल से जुड़ा समाधान ढूंढने के लिए निर्देश देना और उसे गाइड करना, किसी नए क्षेत्र को एक्सप्लोर करने का एक अच्छा तरीका हो सकता है. प्रोजेक्ट पूरा होने के बाद, आपको यह बेहतर तरीके से पता चल जाएगा कि एमएल से जुड़े समाधान के लिए कितनी मेहनत की ज़रूरत होगी और कौनसे तरीके अपनाए जा सकते हैं. इसके अलावा, यह भी पता चलेगा कि संसाधनों को कहीं और इस्तेमाल करना चाहिए या नहीं.
किसी भी रणनीति के लिए, जल्दी फ़ेल होना बेहतर होता है. सबसे कम लागत वाले तरीकों को आज़माएं, लेकिन पहले उन तरीकों को आज़माएं जिनसे आपको सबसे ज़्यादा फ़ायदा हो सकता है. अगर यह तरीका काम करता है, तो इसका मतलब है कि आपको समस्या का एक अच्छा समाधान मिल गया है. अगर ऐसा नहीं होता है, तो आपने अपना बहुत समय और संसाधन बर्बाद नहीं किए हैं.
जैसे-जैसे टीमों को एक्सपेरिमेंट चलाने का अनुभव और जानकारी मिलेगी, वैसे-वैसे वे किसी एक्सपेरिमेंट के लिए ज़रूरी मेहनत का बेहतर अनुमान लगा पाएंगे. इससे, प्लानिंग को ज़्यादा बेहतर बनाया जा सकेगा. हालांकि, किसी एक्सपेरिमेंट का नतीजा हमेशा पता नहीं होता. इसलिए, सबसे अच्छा समाधान ढूंढने के लिए ज़रूरी एक्सपेरिमेंट की संख्या का पहले से अनुमान नहीं लगाया जा सकता.
एक्सपेरिमेंट के तौर पर नए तरीके आज़माने से, आपकी टीम को सफलता पाने में मदद मिलती है. जब कोई तरीका काम नहीं करता, तो टीम के सदस्य निराश होने के बजाय, यह समझते हैं कि यह एआई से जुड़ा समाधान ढूंढने की प्रोसेस का हिस्सा है. सबसे अहम बात यह है कि एमएल डेवलपमेंट में मौजूद अनिश्चितता के बारे में, हिस्सेदारों के साथ बातचीत करके, ज़्यादा सही उम्मीदें सेट की जा सकती हैं.
देखें कि आपको विषय की कितनी समझ है
ध्यान रखें
संभावित तौर पर एमएल के कई तरीकों को प्लान करने में समय और अनुभव लगता है. आपके प्रोजेक्ट प्लान को बार-बार अपडेट करने की ज़रूरत पड़ सकती है. इसे एक डाइनैमिक दस्तावेज़ के तौर पर देखें, जो लगातार अपडेट होता रहता है. ऐसा इसलिए होता है, क्योंकि आपकी टीम अलग-अलग तरीकों के साथ एक्सपेरिमेंट करती रहती है. यहां दिए गए मुख्य आइडिया पर फ़ोकस करके, अपनी सफलता की संभावनाएं बढ़ाई जा सकती हैं:
- हर तरीके की लागत और सफल होने की संभावना का अनुमान लगाएं.
- अलग-अलग तरीकों को आज़माएं.
- इस बारे में जानें कि उसने क्या सीखा. साथ ही, सिस्टम को एक बार में एक चीज़ को बेहतर बनाने की कोशिश करें.
- गड़बड़ियों के लिए प्लान बनाएं.
कभी-कभी, जल्दी से संपर्क करने पर बेहतर नतीजे मिलते हैं. किसी को डेटा जनरेशन पाइपलाइन या ट्रेनिंग-पुष्टि के बंटवारे में कोई गड़बड़ी मिल सकती है. अच्छी योजना बनाने और पूरी जानकारी देने वाले दस्तावेज़ों की मदद से, आपको ऐसा मॉडल मिल सकता है जो आपके कारोबार की समस्या को उम्मीद से पहले हल कर दे.