ठेस में सीवी के लिए कागल दृष्टिकोण: आप कटौती करने के लिए लागू नहीं कर सकते

वैज्ञानिकों की तारीख के बीच, कई होलिवार्स हैं, और उनमें से एक प्रतिस्पर्धी मशीन सीखने की चिंता करता है। क्या कागल की सफलता वास्तव में विशिष्ट कार्य कार्यों को हल करने की विशेषज्ञ की क्षमता को दर्शाती है? आर्सेनी arseny_info (R & D टीम लीड @ WANNABY , कागले मास्टर , बाद में A. में ) और आर्थर n01z3 (कंप्यूटर विज़न @ X5 रिटेल ग्रुप के प्रमुख , कागल ग्रैंडमास्टर , बाद में N. में होलिवर को एक नए स्तर पर पहुंचा दिया: एक और चर्चा के बजाय: उन्होंने चैट रूम में माइक्रोफोन ले लिया और बैठक में एक सार्वजनिक चर्चा की , जिसके आधार पर इस लेख का जन्म हुआ।

मेट्रिक्स, कर्नेल, लीडरबोर्ड

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

हैरानी की बात यह है कि इससे भी समस्याएं पैदा होती हैं। जब "अपरिचित / असंगत मीट्रिक को देखते हैं तो" कागलर्स "भ्रमित होने पर कई उदाहरणों को खोजना मुश्किल नहीं है।

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

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

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



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

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



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



एक:
समस्या यह है कि वास्तविक कार्यों में लीडरबोर्ड नहीं है । आमतौर पर कोई एकल संख्या नहीं होती है जो बताती है कि सब कुछ गलत हो गया या इसके विपरीत, सब कुछ ठीक है। अक्सर कई संख्याएं होती हैं, वे एक-दूसरे के विपरीत होते हैं, उन्हें एक प्रणाली में जोड़ना एक और चुनौती है।

न:
लेकिन मेट्रिक्स किसी तरह महत्वपूर्ण हैं। वे एल्गोरिथ्म का एक उद्देश्य प्रदर्शन दिखाते हैं। कुछ उपयोग योग्य सीमा से ऊपर मैट्रिक्स वाले एल्गोरिदम के बिना, एमएल-आधारित सेवाएं बनाना असंभव है।

एक:
लेकिन केवल अगर वे ईमानदारी से उत्पाद की स्थिति को दर्शाते हैं, जो हमेशा मामला नहीं होता है। ऐसा होता है कि आपको मीट्रिक को कुछ हाइजीनिक न्यूनतम तक खींचने की आवश्यकता है, और "तकनीकी" मीट्रिक के आगे सुधार अब उत्पाद सुधार के अनुरूप नहीं हैं (उपयोगकर्ता इन +0.01 IoU को नोटिस नहीं करता है), मीट्रिक और उपयोगकर्ता की संवेदनाओं के बीच संबंध खो जाता है।

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

विश्वसनीय सत्यापन और बोल्ड मॉडल के नमूने

न:
कागल आपको सही ढंग से मान्य करना सिखाता है, जिसमें चेहरे की उपस्थिति भी शामिल है। लीडरबोर्ड पर गति में सुधार कैसे हुआ है, इसके बारे में आपको बहुत स्पष्ट होना चाहिए। यदि हम वास्तविक कार्य के बारे में बात कर रहे हैं, तो प्रतिनिधि मंडल का निर्माण करना आवश्यक है , जो लीडरबोर्ड के निजी हिस्से या उत्पादन में डेटा के वितरण को दर्शाता है।

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



एक:
काग्ले में "सरल एकल मॉडल" की अवधारणा एक साथ मिलती है और उत्पादन के वातावरण के लिए बहुत भिन्न हो सकती है। प्रतियोगिता के ढांचे के भीतर, यह 5/10 सिलवटों में प्रशिक्षित एक आर्किटेक्चर होगा, जो प्रसार एनकोडर के साथ होता है, समय में आप परीक्षण के समय में वृद्धि की उम्मीद कर सकते हैं। प्रतियोगिता मानकों के हिसाब से, यह वास्तव में सरल उपाय है।

लेकिन उत्पादन में अक्सर परिमाण के आदेशों के एक जोड़े के समाधान की आवश्यकता होती है , खासकर जब यह मोबाइल अनुप्रयोगों या IoT की बात आती है। उदाहरण के लिए, मेरे मामले में कागले-मॉडल आमतौर पर 100+ मेगाबाइट पर कब्जा कर लेते हैं, और मॉडल के काम में कुछ मेगाबाइट से अधिक अक्सर भी नहीं माना जाता है; अनुमान की दर के लिए आवश्यकताओं में समान अंतर है।

न:
हालांकि, अगर तारीख वैज्ञानिक जानता है कि एक भारी ग्रिड को कैसे प्रशिक्षित किया जाए, तो सभी समान तकनीकें हल्के मॉडल के प्रशिक्षण के लिए भी उपयुक्त हैं। पहले सन्निकटन में, आप एक समान मेष आसान या समान वास्तुकला का मोबाइल संस्करण ले सकते हैं। कागज़र्स की क्षमता से परे तराजू और छंटाई की मात्रा - इसमें कोई संदेह नहीं है। लेकिन ये पहले से ही बहुत विशिष्ट कौशल हैं, जो ठेस में हमेशा जरूरी हैं।

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

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



छद्म डबिंग क्या है? हम मौजूदा मॉडल लेते हैं, जहां वे विश्वसनीय भविष्यवाणियां देते हैं, हम इन नमूनों को हमारे डेटासेट में भविष्यवाणियों के साथ फेंक देते हैं। इस मामले में, मॉडल के लिए मुश्किल नमूने अनब्लॉक रहते हैं, क्योंकि ये भविष्यवाणियां अभी अच्छी नहीं हैं। दुष्चक्र!

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

कोड और टीम वर्क की सुंदरता के बारे में

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



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

न:
कोड की गुणवत्ता cuggle पर एक म्यूट बिंदु है, मैं सहमत हूं। हालाँकि, मैं ऐसे लोगों से भी मिला, जिन्होंने बहुत योग्य पाइपलाइनें लिखीं, जिन्हें अन्य कार्यों के लिए पुन: उपयोग किया जा सकता है। लेकिन यह बल्कि अपवाद है: लड़ाई की गर्मी में, कोड की गुणवत्ता नए विचारों की त्वरित जांच के पक्ष में बलिदान की जाती है, खासकर प्रतियोगिता के अंत की ओर।

लेकिन कागले टीम वर्क सिखाते हैं। और कुछ भी लोगों को एक सामान्य कारण, एक सामान्य समझने योग्य लक्ष्य की तरह एकजुट नहीं करता है। आप विभिन्न लोगों के एक समूह के साथ प्रतिस्पर्धा करने, शामिल होने और नरम कौशल विकसित करने का प्रयास कर सकते हैं।



एक:
कागल-शैली की टीमें भी बहुत अलग हैं। यह अच्छा है अगर भूमिकाओं, रचनात्मक अंतःक्रिया से कुछ अलग तरह के काम होते हैं, और हर कोई अपना योगदान देता है। फिर भी, जिन टीमों में हर कोई अपनी खुद की मिट्टी की बड़ी गेंद बनाता है, और प्रतियोगिता के अंतिम दिनों में यह सब कुछ मिश्रित है, पर्याप्त भी हैं, और यह कुछ भी अच्छा नहीं सिखाता है - वास्तविक सॉफ्टवेयर विकास (डेटा विज्ञान सहित) बहुत लंबे समय से नहीं किया।

सारांश

आइए संक्षेप में बताते हैं।

निस्संदेह, प्रतियोगिताओं में भागीदारी अपने बोनस देती है जो दैनिक कार्यों में उपयोगी होती हैं: सबसे पहले, यह त्वरित रूप से पुनरावृति करने की क्षमता है, मीट्रिक के ढांचे के भीतर डेटा से बाहर सब कुछ निचोड़ना और कला दृष्टिकोण की स्थिति का उपयोग करने में संकोच न करें।

दूसरी ओर, कागले दृष्टिकोण का दुरुपयोग अक्सर उप-विषयक अपठनीय कोड, संदिग्ध कार्य प्राथमिकताओं और थोड़े से दोष के कारण होता है।

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