मशीन लर्निंग प्रोजेक्ट प्रबंधन में नुकसान

डेढ़ साल से मैं अपनी कंपनी में मुख्य एमएल डेवलपर का पद संभाल रहा हूं। छह महीने मैं एक छोटी टीम का प्रबंधन करता हूं। मुझे ऐसा अनुभव प्राप्त हुआ है जिसे मैं साझा करना चाहता हूं। मैं त्रुटियों और संभावित कठिनाइयों के शीर्ष के प्रारूप में ऐसा करूंगा।

हम एक तंत्रिका नेटवर्क चाहते हैं!

कई लोगों ने कम से कम कृत्रिम बुद्धि और तंत्रिका नेटवर्क की उपलब्धियों के बारे में कुछ सुना है। कुछ लोग व्यवसाय में तंत्रिका नेटवर्क का उपयोग सिर्फ इसलिए करना चाहते हैं क्योंकि यह लोकप्रिय है। इसलिए आपने पाठ विश्लेषण के कुछ छोटे काम हल कर लिए हैं और आप सभी को सुरक्षित रूप से घोषणा कर सकते हैं कि आपका व्यवसाय सबसे आधुनिक कृत्रिम बुद्धिमत्ता प्रौद्योगिकियों का उपयोग करता है।

इसके अलावा, लगभग कोई भी तंत्रिका नेटवर्क की ताकत और कमजोरियों को नहीं समझता है। दरअसल, उच्च संसाधन खपत के कारण, वे हमेशा इष्टतम मॉडल से दूर हैं।

अक्सर, एल्गोरिदम जैसे बूस्टिंग, के-निकटतम पड़ोसी या svm व्यावसायिक समस्याओं को हल करने में उच्च गुणवत्ता वाले संकेतक दिखा सकते हैं (यदि हम तंत्रिका नेटवर्क की तुलना में क्लासिक स्क्रिप्ट सुविधाओं -> मूल्य के बारे में बात कर रहे हैं)। यह इस तथ्य के बावजूद है कि वे बहुत अधिक हल्के हैं।

यदि क्लाइंट आपको बताता है: "हमें इस तरह की समस्या को हल करने के लिए एक तंत्रिका नेटवर्क की आवश्यकता है," तो सबसे अधिक संभावना है कि वह आसानी से नहीं जानता कि इस समस्या को हल करने के लिए कौन से उपकरण सबसे अच्छा है। लेकिन ऐसा लगता है कि यहां कुछ जटिल एल्गोरिदम की आवश्यकता है और उनके दिमाग में आने वाली एकमात्र चीज एक तंत्रिका नेटवर्क है।

तो आप कुछ और प्रकाश मॉडल के माध्यम से समस्या को हल कर सकते हैं।

यह स्पष्ट लगता है, लेकिन वास्तव में, क्लाइंट से इस तरह के अनुरोध के बाद, आप तंत्रिका नेटवर्क के विभिन्न आर्किटेक्चर के माध्यम से छंटाई में समय बिता सकते हैं इससे पहले कि आपको पता चले कि कार्य को बहुत आसान हल किया जा सकता है।

सुबह का डेटा, शाम का एस्टीमेट

अक्सर, आपको प्रयोगों के प्रदर्शन के लिए समय सीमा देने के लिए कहा जाएगा। इसके अलावा, इस तरह के अनुमानों का आधार समस्या का केवल एक सार वर्णन प्रदान कर सकता है। उदाहरण के लिए: “हम एक तंत्रिका नेटवर्क चाहते हैं जो चिकित्सा छवियों के अनुसार, एक बीमारी वाले व्यक्ति का निदान करेगा। इसमें कितना समय लगेगा? ” जो लोग एमएल के साथ काम नहीं करते थे (और कभी-कभी काम करते थे) को प्रयोगों की अवधारणा के बारे में बहुत कम समझ है। कई एमएल समाधान के विकास के मानक सॉफ्टवेयर विकास के रूप में दृष्टिकोण करते हैं। लेकिन ये सब गलतियाँ हैं। एमएल विकास विज्ञान की तुलना में विकास के करीब है (विशेषकर प्रारंभिक चरणों में)। अधिकांश समय डेटा विश्लेषण और प्रयोगों के लिए आवश्यक है। और लोग इसे शायद ही कभी समझते हैं।

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

प्रारंभिक प्रयोग में मॉडल की सटीकता 99.99999%

यहां तक ​​कि अगर आप प्रारंभिक प्रयोगों में उच्च प्रोटोटाइप प्राप्त करते हैं या प्रोटोटाइप का परीक्षण करते हैं, तो यह उन्हें क्लाइंट को तुरंत संवाद करने का कारण नहीं है। लेकिन आपके द्वारा कही गई हर बात का इस्तेमाल आपके खिलाफ किया जा सकता है।

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

वैकल्पिक रूप से, आप अपने मॉडल की विभिन्न अंतिम गुणवत्ता के लिए अनुबंध में विभिन्न भुगतानों को ठीक कर सकते हैं।

आमतौर पर, लोग अमूर्त संख्याओं से अधिक ठोस उदाहरणों पर भरोसा करते हैं। आपके मॉडल का एक छोटा प्रदर्शन 99% सटीकता के बारे में बयानों की तुलना में ग्राहक को अधिक आत्मविश्वास देगा।

यदि आप समस्या का समाधान कर रहे हैं, उदाहरण के लिए, संवेदी तंत्रिका विधियों का उपयोग करके पता लगाना / वर्गीकरण करना और सशर्त अवधि के लिए टीम की सफलता पर एक रिपोर्ट लिखना, अतिरिक्त 30 मिनट खर्च करना और कुछ सुंदर चित्र बनाना: अमूर्तन के उच्च स्तर पर दृढ़ फिल्टर के विज़ुअलाइज़ेशन से खेलना या पूरी तरह से जुड़ी हुई परतें बनाना। कक्षाओं इत्यादि के ऊष्मा मानचित्र

सर्वर की कोई समस्या नहीं होगी

कुछ बिंदु पर मैंने नोटिस करना शुरू किया कि मॉडल का काम अक्सर अपने आकार पर टिकी हुई है। उदाहरण के लिए, जब आपको 5 मिलियन वर्गों के लिए एक क्लासिफायर बनाने की आवश्यकता होती है, तो सबसे सरल मॉडल भी संसाधन-गहन हो सकते हैं। फिर सवाल स्वाभाविक रूप से सर्वर विनिर्देशन का उठता है, जिसे ग्राहक कुछ इस तरह से खारिज कर सकता है: "सर्वर के साथ कोई समस्या नहीं होगी - हम क्लाउड सेवाओं पर कुछ चुनेंगे।"

समस्या यह है कि यह मॉडल के पैमाने का बिल्कुल प्रतिनिधित्व नहीं कर सकता है। उदाहरण के लिए, एक डेटासेट में 2 टेराबाइट होंगे, और प्रशिक्षित मॉडल का वजन मैट्रिक्स 500 गीगाबाइट है। ऐसे मॉडल का उपयोग करने के लिए, आपको 68-128 जीबी रैम की आवश्यकता है। ऐसी कार किराए पर लेने के लिए ग्राहक को कई हजार से लेकर कई दसियों डॉलर प्रति माह (यदि अधिक जीपीयू की आवश्यकता हो) हो सकती है। और यहाँ, कई ऐसे सर्वरों के लिए भुगतान करने के लिए सहमत नहीं हैं।