कार की स्थिति का आकलन करने के लिए कंप्यूटर विजन का उपयोग कैसे करें। अनुभव यैंडेक्स। टेक्सी

हम यह सुनिश्चित करने का प्रयास करते हैं कि उपयोगकर्ता को टैक्सी का आदेश देने के बाद, मेक, कलर और नंबर की एक साफ-सुथरी कार, जो एप्लिकेशन में दिखाई देती है, उपयोगकर्ता के पास आएगी। और इसके लिए हम रिमोट क्वालिटी कंट्रोल (DCC) का इस्तेमाल करते हैं।

आज मैं हबर के पाठकों को सैकड़ों हजारों मशीनों के साथ तेजी से बढ़ती सेवा में गुणवत्ता नियंत्रण की लागत को कम करने के लिए मशीन का उपयोग करने के तरीके के बारे में बताऊंगा और मशीन को उस लाइन पर नहीं डालूंगा जो सेवा के नियमों का पालन नहीं करता है।

मशीन सीखने से पहले डीसीसी की व्यवस्था कैसे की गई

डीसीसी प्रक्रिया आरेख

डीसीसी की प्रक्रिया में, हम कार की तस्वीरों की जांच करते हैं और इस पर निर्णय लेते हैं कि क्या ऐसी कार पर ऑर्डर पूरा करना संभव है या, उदाहरण के लिए, इसे पहले धोया जाना चाहिए। यह सब इस तथ्य से शुरू होता है कि ड्राइवर एप्लिकेशन टैक्समीटर के माध्यम से हम ड्राइवर को डीसीसी पर कॉल करते हैं। यह आमतौर पर हर 10 दिनों में एक बार होता है, लेकिन कभी-कभी कम या अधिक बार - कितनी सफलतापूर्वक ड्राइवर ने पिछले चेक पास किए। डीसीसी को कॉल करने के तुरंत बाद, ड्राइवर को एक संदेश प्राप्त होता है जो उन्हें एक फोटोकंट्रोल से गुजरने के लिए आमंत्रित करता है। जैसे ही ड्राइवर ने निमंत्रण स्वीकार किया, उसी एप्लिकेशन में, वह कार के बाहरी और आंतरिक हिस्से को अलग-अलग कोणों से खींचता है और Yandex.Taxi को तस्वीरें भेजता है। डीसीसी चालू होने पर ड्राइवर ऑर्डर ले सकता है।

टैक्समीटर एप्लीकेशन में DCC स्टार्ट स्क्रीन

टेक्सीमीटर एप्लीकेशन में कार की तस्वीर लगाने के लिए स्क्रीन

परिणामी तस्वीरें Yandex.Toloka में आती हैं - एक सेवा जिसमें, क्राउडसोर्सिंग का उपयोग करके, आप जल्दी से सरल, लेकिन वॉल्यूम कार्यों में बड़े प्रदर्शन कर सकते हैं। यह कैसे काम करता है और क्यों Yandex.Tolok की आवश्यकता है, इसके बारे में हमने अपने ब्लॉग पर लिखा है।

Yandex.Tolok में, एक चेक के दौरान, कम से कम तीन कलाकार कार की स्थिति के बारे में सवालों के जवाब देते हैं, और यदि कलाकार अपने जवाबों के आधार पर सहमत होते हैं, तो एक निर्णय किया जाता है कि क्या चालक आदेश स्वीकार कर सकता है। Yandex.Tolok में चेक के दो परिणाम हैं:

• यदि कार के साथ सब कुछ ठीक है, तो ड्राइवर ऑर्डर लेना जारी रखता है।
• यदि कार गंदी, क्षतिग्रस्त है, या उसका मेक, कलर या नंबर ड्राइवर के कार्ड पर इंगित किए गए से मेल नहीं खाते हैं, तो Yandex.Taxi अस्थायी रूप से आदेश को स्वीकार करने के लिए ड्राइवर की क्षमता को सीमित करता है।

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

तो DCC निष्पादक Yandex.Tolki को देखता है

कार्य

Yandex.Taxi की वृद्धि के साथ, DCC निरीक्षणों की संख्या भी बढ़ रही है, जिसका अर्थ है कि tolkers और आकलनकर्ताओं के लिए लागत बढ़ रही है। इसके अलावा, कार की जांच की गति कम हो जाती है। जबकि DCC प्रगति पर है, आप या तो ड्राइवरों को आदेश स्वीकार करने की अनुमति दे सकते हैं, या नहीं। दोनों विकल्पों में अपनी कमियां हैं: पहले मामले में, एक बेईमान चालक के पास एक कार पर कई आदेशों को स्वीकार करने का समय होगा जो मानकों को पूरा नहीं करता है, दूसरे में - फोटो नियंत्रण के लिए कॉल किए गए सभी ड्राइवर तब तक काम करने में सक्षम नहीं होंगे जब तक कि जांच पूरी नहीं हो जाती। इसलिए, कारों को जल्दी से जांचना महत्वपूर्ण है ताकि उपयोगकर्ता और ड्राइवर दोनों किसी भी असुविधा का सामना न करें।

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

हमने DCC पर मशीन लर्निंग को कैसे लागू किया

डीसीसी प्रक्रिया आरेख के साथ एमएल अंदर

शुरू करने के लिए, हमने समस्या बयान पर फैसला किया: समग्र प्रवाह में त्रुटि दर में वृद्धि नहीं करते हुए, यथासंभव अधिक से अधिक जांच को स्वचालित करने के लिए।

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

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

• थ्रेड का वह भाग जो मशीन लर्निंग मॉडल स्वचालित रूप से उत्तर दे सकता है।
• एफएनआर सिस्टम।
• FPR सिस्टम।

दूसरे और तीसरे पर प्रतिबंधों का पालन करते हुए हम पहले मूल्य को अधिकतम करते हैं।

यह सवाल उठा सकता है: पैसे की बचत को अधिकतम क्यों न करें या सीधे स्कैन के औसत समय को कम से कम न करें, और न ही स्वचालित चेक के माध्यम से? पैसे का अनुकूलन एक बहुत ही आकर्षक विचार है, लेकिन आमतौर पर इसे लागू करना मुश्किल है। हमारे मामले में, बचत में दो कारक होते हैं: पहला प्रत्येक स्वचालित चेक से होने वाली बचत है, क्योंकि प्रत्येक चेक मूल्यांकनकर्ताओं या यैंडेक्स में होता है। दूसरा - त्रुटियों की संख्या को कम करने से बचाना, क्योंकि प्रत्येक त्रुटि का खर्च Yandex.Taxi पैसा है। निष्पक्ष रूप से गणना करना कि हमसे कितनी ग़लतियाँ होती हैं यह एक बहुत मुश्किल काम है, इसलिए हम केवल पहले कारक द्वारा बचत की गणना करने तक ही सीमित हैं। यह मान स्वचालित रूप से स्वचालित जांच के अनुपात में बढ़ता है, ताकि बचत के बजाय इस अंश को अधिकतम किया जा सके। एक ही तर्क औसत डीसीसी समय पर लागू होता है, यह स्वचालित जांचों के शेयर के अनुसार नीरस रूप से घटता है।

मॉडल चयन

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

पहला समाधान या "सभी एक बार" दृष्टिकोण

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

ऑल-इन-वन दृष्टिकोण

"सभी एक बार" दृष्टिकोण की समस्याएं:

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

साथ में, इन चार कारणों ने हमें पहले समाधान को व्यवहार में लाने की अनुमति नहीं दी, लेकिन हमने हिम्मत नहीं हारी और दूसरे के साथ आए।

दूसरा समाधान, या "सभी लेकिन धीरे-धीरे" दृष्टिकोण

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

दृष्टिकोण "सब कुछ, लेकिन धीरे-धीरे"

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

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

इसके बाद, हमने कार क्लासिफायर को रंगों और साथ ही रंगों और मॉडल को पहचानने के लिए प्रशिक्षित किया। इस क्षण से हम इस प्रश्न का उत्तर दे सकते हैं: "क्या ड्राइवर के कार्ड पर कार का मेक, मॉडल और रंग दर्शाया गया है?"

निष्कर्ष में, हमने क्षतिग्रस्त और गंदी कारों को खोजने के लिए क्लासिफायरर्स को प्रशिक्षित किया, इससे हमें सवालों को बंद करने की अनुमति मिली: "क्या कार के शरीर पर कोई नुकसान या दोष हैं?" और "कार शरीर कितना गंदा है?"

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

उत्पादन में कार्यान्वयन

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

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

1. नमूना लीजिए।
2. मॉडल को प्रशिक्षित करें।
3. गुणवत्ता को मापें और थ्रेसहोल्ड ऑफ़लाइन चुनें।
4. पृष्ठभूमि में सेवा के लिए एक मॉडल जोड़ें और गुणवत्ता को ऑनलाइन मापें।
5. उत्पादन में मॉडल को शामिल करें और अपनी भविष्यवाणियों के आधार पर निर्णय लेना शुरू करें।

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

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

परिणाम

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

• 30% वाहन बाहरी जांचों को अब स्वचालित प्रतिक्रिया मिली।
• एफएनआर उसी स्तर पर रहा, जबकि एफपीआर गिर गया, और हमने उन लोगों तक सेवा की पहुंच को कम करना शुरू कर दिया, जिनके पास इसके लायक नहीं थे।
• मूल्यांकनकर्ताओं पर भार 14% कम हो गया, और वे अधिक समय जटिल परीक्षणों में समर्पित करने में सक्षम थे जो मशीन सीखने की सेवा नहीं ले सकती थी।
• निरीक्षण के दौरान गंभीर खामियों वाली कारों का पता लगाने का समय कुछ घंटों से घटाकर कुछ सेकंड कर दिया गया था।

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

इतिहास का नैतिक

Yandex.Taxi में DCC स्वचालन पर काम करते समय, हमने कई समस्याओं का सामना किया, कई सफल समाधान पाए और छह महत्वपूर्ण निष्कर्ष दिए:

1. समस्या को हल करना हमेशा संभव नहीं होता है (भले ही आपके पास डीप लर्निंग हो)।
2. मॉडल उतना ही अच्छा है जितना उस डेटा पर जिसे यह प्रशिक्षित किया गया था (कॉर्न लगता है, लेकिन यह है)।
3. किसी भी समस्या को हल करने में, व्यवसाय की वास्तविक आवश्यकताओं पर निर्माण करना महत्वपूर्ण है, न कि क्रॉस-एंट्रोपी को कम करने पर।
4. कुछ समस्याओं को हल करने में, मशीन सीखने की शुरुआत (हेलो, यैंडेक्स.टोलोका!) के बावजूद लोग महत्वपूर्ण हैं।
5. मशीन लर्निंग मॉडल की भविष्यवाणियों के आधार पर निर्णय सभी मामलों में नहीं किए जा सकते हैं, लेकिन केवल उस हिस्से में जहां मॉडल अपने उत्तरों में बहुत आश्वस्त हैं। अन्य मामलों में, यह शायद पुराने तरीके से निर्णय लेने के लायक है - लोगों की मदद से।
6. वास्तुकला और मॉडल प्रशिक्षण की पसंद के अलावा, परियोजना के कई और चरण हैं जो बहुत प्रभावित कर सकते हैं कि व्यावसायिक समस्या कितनी अच्छी तरह हल हो गई है। ये चरण हैं: डेटा संग्रह, गुणवत्ता मीट्रिक का चयन, मॉडल कार्यान्वयन विकल्प, मॉडल भविष्यवाणियों के आधार पर उत्पाद निर्णय लेने का तर्क, और बहुत कुछ।

1. , . .

   
   

2. . .