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