इस समस्या को समझने के लिए, नीचे दिए गए टास्क करें:
- प्रॉडक्ट के उस लक्ष्य के बारे में बताएं जिसे आप डेवलप कर रहे हैं या फिर से आज़मा रहे हैं.
- तय करें कि लक्ष्य को सबसे बेहतर तरीके से हल करना है या नहीं. इसके अलावा, अनुमानित एमएल या एआई (AI) समाधान का इस्तेमाल करके भी यह तय किया जा सकता है.
- अगर आपने अनुमानित एमएल तरीके का इस्तेमाल किया है, तो पुष्टि करें कि आपके पास मॉडल को ट्रेनिंग देने के लिए ज़रूरी डेटा है.
लक्ष्य तय करें
अपना लक्ष्य गैर-एमएल शब्दों की जानकारी देकर शुरू करें. लक्ष्य यह है कि इस सवाल का जवाब "मैं क्या हासिल करने की कोशिश कर रहा हूं?"
यहां दी गई टेबल में, काल्पनिक ऐप्लिकेशन से जुड़े लक्ष्यों के बारे में साफ़ तौर पर बताया गया है:
| ऐप्लिकेशन | लक्ष्य |
|---|---|
| मौसम की जानकारी देने वाला ऐप्लिकेशन | किसी भौगोलिक इलाके के लिए, छह घंटे की बढ़ोतरी का अनुमान लगाएं. |
| फ़ैशन ऐप्लिकेशन | शर्ट के कई तरह के डिज़ाइन जनरेट करें. |
| वीडियो ऐप्लिकेशन | उपयोगी वीडियो के सुझाव दें. |
| मेल ऐप्लिकेशन | स्पैम का पता लगाएं. |
| वित्तीय ऐप्लिकेशन | एक से ज़्यादा समाचार स्रोतों से मिलने वाली वित्तीय जानकारी के बारे में बताएं. |
| मैप ऐप्लिकेशन | यात्रा में लगने वाले समय का हिसाब लगाएं. |
| बैंकिंग ऐप्लिकेशन | धोखाधड़ी वाले लेन-देन की पहचान करना. |
| डाइनिंग ऐप्लिकेशन | रेस्टोरेंट के मेन्यू में पकवान ढूंढें. |
| ई-कॉमर्स ऐप्लिकेशन | मददगार जवाबों के साथ समीक्षाओं का जवाब दें. |
मशीन लर्निंग (एमएल) के इस्तेमाल के उदाहरण साफ़ करें
कुछ टूल, एमएल को यूनिवर्सल टूल के तौर पर देखते हैं. इसे सभी समस्याओं पर लागू किया जा सकता है. असल में, एमएल एक खास टूल है, जो सिर्फ़ खास समस्याओं के लिए काम करता है. जब आसान गैर-एमएल समाधान काम करेगा, तो आप मुश्किल एमएल समाधान लागू नहीं करना चाहते.
ML सिस्टम को दो बड़ी कैटगरी में बांटा जा सकता है: अनुमानित ML और सामान्य AI. इस टेबल में इनके बारे में जानकारी दी गई है:
| इनपुट | आउटपुट | ट्रेनिंग की तकनीक | |
|---|---|---|---|
| अनुमानित एमएल |
टेक्स्ट इमेज ऑडियो वीडियो नंबर |
यह अनुमान लगाता है कि किसी ईमेल को स्पैम के तौर पर मार्क किया गया है या स्पैम वाले ईमेल को नहीं, बल्कि कल के बारिश का अनुमान लगाया जा रहा है या स्टॉक की कीमत का अनुमान लगाया जा रहा है. आउटपुट की पुष्टि आम तौर पर रिएलिटी से की जा सकती है. | आम तौर पर, किसी खास टास्क को करने के लिए, बहुत सारे डेटा का इस्तेमाल किया जाता है. इसमें, निगरानी में रखे गए, बिना निगरानी वाले या प्रशिक्षित करने वाले मॉडल को ट्रेनिंग दी जाती है. |
| एआई (AI) |
टेक्स्ट इमेज ऑडियो वीडियो नंबर |
ऐसा करने से उपयोगकर्ता के मकसद के मुताबिक आउटपुट मिलता है. उदाहरण के लिए, किसी लेख में खास जानकारी देना या ऑडियो क्लिप या छोटा वीडियो बनाना. | आम तौर पर, बिना लेबल वाले कई डेटा का इस्तेमाल करके, एक बड़े लैंग्वेज मॉडल या इमेज जनरेटर को ट्रेनिंग दी जाती है, ताकि उसमें मौजूद डेटा को भरा जा सके. इसके बाद, इस मॉडल का इस्तेमाल उन टास्क के लिए किया जा सकता है जिन्हें खाली हुए फ़ील्ड में भरा जा सकता है. इसके अलावा, इसे किसी खास टास्क जैसे कि डेटा की कैटगरी तय करने के लिए, लेबल किए गए डेटा की मदद से ट्रेनिंग दी जा सकती है. |
यह पुष्टि करने के लिए कि ML सही तरीका है, पहले पुष्टि करें कि आपका मौजूदा गैर-ML समाधान ऑप्टिमाइज़ किया गया है. अगर आपने बिना एमएल वाला समाधान लागू नहीं किया है, तो हेरिस्टिक का इस्तेमाल करके, समस्या को मैन्युअल तरीके से हल करने की कोशिश करें.
गैर-एमएल समाधान वह मानदंड है जिसका इस्तेमाल करके आप यह तय कर सकते हैं कि एमएल, आपकी समस्या के लिए इस्तेमाल का अच्छा उदाहरण है या नहीं. एमएल के साथ गैर-एमएल तरीके की तुलना करते समय इन सवालों पर ध्यान दें:
क्वालिटी. आपके हिसाब से, एमएल समाधान कितना बेहतर हो सकता है? {0}अगर आपको लगता है कि एमएल समाधान एक छोटा सा सुधार हो सकता है, तो हो सकता है कि मौजूदा समाधान सबसे अच्छा समाधान हो.
लागत और रखरखाव. छोटी और लंबी अवधि, दोनों में एमएल समाधान कितना महंगा है? कुछ मामलों में, संसाधनों की गणना करने और मशीन लर्निंग (एमएल) लागू करने में लगने वाले समय के मुकाबले इसकी लागत बहुत ज़्यादा होती है. नीचे दिए गए सवालों पर विचार करें:
- क्या एमएल समाधान, बढ़ी हुई लागत को सही ठहराता है? ध्यान दें कि बड़े सिस्टम में होने वाले छोटे सुधार, एमएल समाधान को लागू करने की लागत और रखरखाव को सही साबित कर सकते हैं.
- समाधान के लिए कितने रखरखाव की ज़रूरत होगी? कई मामलों में, एमएल लागू करने के लिए लंबे समय तक रखरखाव की ज़रूरत होती है.
- क्या आपके प्रॉडक्ट में ट्रेनिंग या इससे जुड़े लोगों को काम पर रखने के लिए एमएल विशेषज्ञता वाले संसाधन उपलब्ध हैं?
अपनी समझ की जांच करें
प्रेडिक्टिव एमएल और डेटा
डेटा, अनुमानित एमएल की प्रेरणा देता है. बेहतर अनुमान बनाने के लिए, आपको सुविधाओं वाले डेटा की ज़रूरत होती है. आपके डेटा में ये विशेषताएं होनी चाहिए:
बहुत ज़्यादा. आपके dataset में जितने ज़्यादा काम के और काम के उदाहरण होंगे, आपका मॉडल उतना ही बेहतर होगा.
लगातार और भरोसेमंद. लगातार और भरोसेमंद तरीके से इकट्ठा किया गया डेटा होने से, बेहतर मॉडल बन सकता है. उदाहरण के लिए, ML के हिसाब से चलने वाले मौसम मॉडल को, एक ही भरोसेमंद डिवाइस से कई साल तक इकट्ठा किए गए डेटा से फ़ायदा मिलेगा.
भरोसेमंद. जानें कि आपका डेटा कहां से आएगा. क्या यह डेटा उन भरोसेमंद सोर्स से लिया जाएगा जिन्हें आपने कंट्रोल किया है, जैसे कि आपके प्रॉडक्ट के लॉग या यह उन सोर्स से लिया जाएगा जिनके बारे में आपको ज़्यादा जानकारी नहीं है, जैसे कि किसी दूसरे एमएल सिस्टम से मिलने वाला आउटपुट?
उपलब्ध है. पक्का करें कि सभी इनपुट सही फ़ॉर्मैट में अनुमानित समय पर उपलब्ध हों. अगर अनुमानित समय पर कुछ खास सुविधाओं की वैल्यू को हासिल करना मुश्किल होगा, तो अपने डेटासेट से वे सुविधाएं हटा दें.
सही. बड़े डेटासेट में, यह ज़रूरी है कि कुछ लेबल की वैल्यू गलत हों, हालांकि, लेबल के एक छोटे से ज़्यादा से ज़्यादा हिस्से गलत होने पर, मॉडल खराब अनुमान दे सकता है.
प्रतिनिधि. डेटासेट को वास्तविक क्षेत्र के बारे में जानकारी देने वाला होना चाहिए. दूसरे शब्दों में, डेटासेट से इवेंट, उपयोगकर्ता के व्यवहार, और/या असल दुनिया के घटनाक्रमों के बारे में सटीक जानकारी मिलनी चाहिए. अगर मॉडल को असल में दिखाने के लिए कहा जाए, तो सटीक जानकारी न देने वाले डेटासेट की ट्रेनिंग से, परफ़ॉर्मेंस खराब हो सकती है.
अगर ज़रूरत के मुताबिक डेटा नहीं मिल पाता है, तो आपका मॉडल खराब अनुमान लगाएगा.
प्रेडिक्टिव पावर
मॉडल के लिए अच्छे अनुमान लगाने के लिए, आपके डेटासेट की सुविधाओं में अनुमानित पावर होनी चाहिए. लेबल के साथ जितनी ज़्यादा संबंधित विशेषता होगी, इस बात का अनुमान लगाने की संभावना उतनी ही ज़्यादा होगी.
कुछ सुविधाओं में, दूसरे डिवाइस के मुकाबले ज़्यादा अनुमानित पावर होती है. उदाहरण के लिए, मौसम के डेटासेट में, cloud_coverage, temperature, और dew_point जैसी सुविधाएं, moon_phase या day_of_week की तुलना में बारिश का बेहतर अनुमान लगा सकती हैं. वीडियो ऐप्लिकेशन के उदाहरण के लिए, यह अनुमान लगाया जा सकता है कि उपयोगकर्ता video_description, length, और views जैसी सुविधाओं के लिए कौनसा वीडियो देखना पसंद करेगा.
ध्यान रखें कि संदर्भ या डोमेन में बदलाव होने की वजह से, सुविधा की अनुमानित क्षमता बदल सकती है. उदाहरण के लिए, वीडियो ऐप्लिकेशन में upload_date आम तौर पर, लेबल की मदद से कमज़ोर तरीके से काम करता है. हालांकि, गेमिंग वीडियो के उप-डोमेन में upload_date को लेबल के साथ पूरी तरह से जोड़ा जा सकता है.
यह पता लगाना कि आपके पास किन सुविधाओं के लिए अनुमानित क्षमता है, समय लग सकता है. मॉडल को ट्रेनिंग देते समय, सुविधाओं को अनुमान के आधार पर हटाकर और जोड़ा जा सकता है. इससे, यह अनुमान लगाया जा सकता है कि सुविधा किस तरह की है. पीरसन कोरिलेशन, अडजस्ट्ड म्युचुअल इन्फ़ॉर्मेशन (एएमआई), और शेपली वैल्यू जैसे एल्गोरिदम का इस्तेमाल करके, किसी सुविधा के अनुमान लगाने की प्रोसेस को ऑटोमेट किया जा सकता है.यह सुविधा, सुविधा पर आधारित अनुमानित क्षमता का विश्लेषण करने के लिए, अंकों का आकलन करती है.
अपनी समझ की जांच करें
अपने डेटासेट का विश्लेषण करने और उन्हें तैयार करने के बारे में ज़्यादा जानकारी के लिए, मशीन लर्निंग के लिए डेटा तैयारी और फ़ीचर इंजीनियरिंग देखें.
अनुमान बनाम कार्रवाइयां
अगर आप सुझाव को ऐसी कार्रवाई में नहीं बदल सकते जिससे उपयोगकर्ताओं को मदद मिलती है, तो कुछ भी अनुमान लगाने की ज़रूरत नहीं है. इसका मतलब है कि आपके प्रॉडक्ट को मॉडल के आउटपुट से कार्रवाई करनी चाहिए.
उदाहरण के लिए, ऐसा मॉडल जो यह अनुमान लगाता है कि उपयोगकर्ता को कोई वीडियो काम का लगेगा या नहीं, उसे ऐसे ऐप्लिकेशन में फ़ीड करना चाहिए जो काम के वीडियो का सुझाव देता हो. एक मॉडल, जो यह अनुमान लगाता है कि बारिश होगी या नहीं, उसे मौसम की जानकारी देने वाले ऐप्लिकेशन में डालना चाहिए.
अपनी समझ की जांच करें
नीचे दिए गए उदाहरण के आधार पर, तय करें कि एमएल इस्तेमाल करना समस्या के लिए सबसे अच्छा तरीका है या नहीं.
किसी बड़े संगठन की इंजीनियरिंग टीम, आने वाले फ़ोन कॉल मैनेज करने के लिए ज़िम्मेदार है.
लक्ष्य: कॉल करने वाले लोगों को यह बताने के लिए कि मौजूदा कॉल के दौरान वे कितनी देर तक कॉल को होल्ड करेंगे.
उनके पास कोई हल नहीं है, लेकिन उन्हें लगता है कि अपने ग्राहकों की मौजूदा संख्या को फ़ोन पर जवाब देने वाले कर्मचारियों की संख्या से भाग देने के बाद, 10 मिनट से गुणा किया जाएगा. हालांकि, वे जानते हैं कि कुछ ग्राहकों की समस्याएं दो मिनट में हल हो जाती हैं, जबकि दूसरों को 45 मिनट या उससे ज़्यादा समय लग सकता है.
उनके अनुमान के हिसाब से, उन्हें इतनी संख्या में सेवाएं नहीं मिल सकतीं. वे इन कॉलम की मदद से डेटासेट बना सकते हैं: number_of_callcenter_phones, user_issue, time_to_resolve, call_time, और time_on_hold.
time_on_hold लेबल के लिए अनुमानित सुविधाएं होती हैं.