मशीन लर्निंग के नियम:

एमएल इंजीनियरिंग के लिए सबसे सही तरीके

मार्टिन ज़िनकेविच

यह दस्तावेज़ उन लोगों के लिए है जिन्हें मशीन की बुनियादी जानकारी है सीखने-सिखाने के अनुभव को मशीन लर्निंग के लिए, Google के सबसे सही तरीकों का फ़ायदा मिलता है. यह Google C++ स्टाइल गाइड की तरह ही, मशीन लर्निंग के लिए स्टाइल दिखाता है और व्यावहारिक प्रोग्रामिंग की अन्य लोकप्रिय गाइड देखें. अगर आपने कोई क्लास ली है या मशीन लर्निंग मॉडल पर काम किया है, तो आपको इस दस्तावेज़ को पढ़ने के लिए ज़रूरी बैकग्राउंड हो.

मार्टिन ज़िनकेविच अपने 10 पसंदीदा नियम बताते हैं मशीन लर्निंग का इस्तेमाल किया जाता है. सभी 43 नियमों के बारे में जानने के लिए आगे पढ़ें!

शब्दावली

विज्ञापन के असर को कम करने के लिए, मशीन लर्निंग:

• इंस्टेंस: वह चीज़ जिसके बारे में आपको सुझाव. उदाहरण के लिए, हो सकता है कि इंस्टेंस कोई ऐसा वेब पेज हो जिसे आपको अपने को "बिल्लियों के बारे में" कहा जाता है. या "बिल्लियों के बारे में नहीं" कहा जा सकता है.
• लेबल: किसी अनुमान के लिए दिया गया जवाब या तो या ट्रेनिंग डेटा में दिया गया सही जवाब हो. इसके लिए उदाहरण के लिए, किसी वेब पेज का लेबल "बिल्लियों के बारे में" हो सकता है.
• सुविधा: ऐसे इंस्टेंस की प्रॉपर्टी जिसका इस्तेमाल अनुमान लगाने वाले टास्क में किया जाता है. इसके लिए उदाहरण के लिए, किसी वेब पेज में "'बिल्ली' शब्द शामिल है" सुविधा हो सकती है.
• फ़ीचर कॉलम: संबंधित सुविधाओं का सेट, जैसे कि सभी संभावित कॉलम का सेट देशों में रहते हैं. उदाहरण में, एक या उससे ज़्यादा सुविधाएँ हो सकती हैं जो सुविधा कॉलम में मौजूद है. "सुविधा कॉलम" Google की खास शब्दावली है. सुविधा कॉलम को "नेमस्पेस" कहा जाता है (Yahoo/Microsoft के प्लैटफ़ॉर्म पर) या field सबमिट करें.
• उदाहरण: एक इंस्टेंस (उसकी सुविधाओं के साथ) और कोई लेबल.
• मॉडल: अनुमान वाले टास्क को आंकड़ों के तौर पर दिखाया जाता है. आपने मॉडल को ट्रेनिंग देने के लिए चुना है फिर मॉडल का इस्तेमाल अनुमान लगाने के लिए करें.
• मेट्रिक: वह संख्या, जो आपके लिए अहम है. इसे सीधे तौर पर ऑप्टिमाइज़ भी किया जा सकता है और नहीं भी.
• मकसद: वह मेट्रिक जिसे आपका एल्गोरिदम ऑप्टिमाइज़ करने की कोशिश कर रहा है.
• पाइपलाइन: मशीन लर्निंग एल्गोरिदम से जुड़ा इंफ़्रास्ट्रक्चर. इसमें फ़्रंट एंड से डेटा इकट्ठा करना और उसे ट्रेनिंग वाले डेटा में शामिल करना शामिल है फ़ाइलें, एक या ज़्यादा मॉडल को ट्रेनिंग देना, और मॉडल को प्रोडक्शन में एक्सपोर्ट करना शामिल है.
• क्लिक मिलने की दर (सीटीआर) किसी वेब पेज पर आने वाले ऐसे लोगों का प्रतिशत जो लिंक पर क्लिक करें.

खास जानकारी

बेहतरीन प्रॉडक्ट बनाने के लिए:

मशीन लर्निंग को आप जैसे महान इंजीनियर की तरह करते हैं, महान जैसे नहीं नहीं हैं.

ज़्यादातर समस्याएं, इंजीनियरिंग से जुड़ी होती हैं. बराबर एक बेहतरीन मशीन लर्निंग विशेषज्ञ के सभी संसाधनों से, बेहतर सुविधाओं से आते हैं, न कि बेहतरीन मशीन लर्निंग एल्गोरिदम से. इसलिए, यह तरीका है:

1. पक्का करें कि आपकी पाइपलाइन पूरी तरह से सुरक्षित हो.
2. उचित लक्ष्य से शुरुआत करें.
3. आसान तरीके से सामान्य ज्ञान की सुविधाएँ जोड़ें.
4. पक्का करें कि आपकी पाइपलाइन स्थिर रहे.

यह तरीका अपनाने पर, लंबे समय तक रोका है. इस तरीके का इस्तेमाल सिर्फ़ तब करें, जब आसान तरकीबें इस्तेमाल करके, आगे बढ़ें. जटिलता जोड़ने से, आने वाली रिलीज़ में देरी होती है.

आसान तरकीबें इस्तेमाल करने के बाद, बेहतरीन मशीन लर्निंग भविष्य में आपका स्वागत है. सेक्शन देखें तीसरा फ़ेज़ मशीन लर्निंग प्रोजेक्ट में.

दस्तावेज़ को इस तरह से व्यवस्थित किया गया है:

1. पहले हिस्से से आपको यह समझने में मदद मिलेगी कि यह मशीन लर्निंग सिस्टम बनाने के लिए सही समय है.
2. दूसरा हिस्सा, पहला पाइपलाइन.
3. तीसरा हिस्सा, प्रॉडक्ट लॉन्च करने और अपनी पाइपलाइन में नई सुविधाएं जोड़ते समय बार-बार, मॉडल का आकलन करने का तरीका और ट्रेनिंग और सेवा के बीच का अंतर.
4. कॉन्टेंट बनाने फ़ाइनल पार्ट यह इस बारे में है कि जब आप समतल जगह पर पहुंचते हैं, तो क्या करें.
5. इसके बाद, संबंधित काम की एक सूची और अपेंडिक्स में कुछ इस दस्तावेज़ में उदाहरणों के तौर पर आम तौर पर इस्तेमाल किए गए सिस्टम के बैकग्राउंड के बारे में बताया गया है.

मशीन लर्निंग से पहले

नियम #1: मशीन लर्निंग के बिना, किसी भी प्रॉडक्ट को लॉन्च करने से न घबराएं.

मशीन लर्निंग काम करती है, लेकिन इसके लिए डेटा की ज़रूरत होती है. सैद्धांतिक तौर पर, यह हासिल किया जा सकने वाला डेटा और फिर मॉडल में बदलाव करके उसे नए प्रॉडक्ट के लिए तैयार करते हैं, लेकिन सामान्य से कम परफ़ॉर्म करेगा ह्यूरिस्टिक्स. अगर आपको लगता है कि मशीन लर्निंग से आपको 100% बूस्ट मिलेगा, तो एक अनुमान से आपको 50% वहां तक पहुंच गए हैं.

उदाहरण के लिए, अगर आप किसी ऐप्लिकेशन मार्केटप्लेस में ऐप्लिकेशन को रैंक कर रहे हैं, तो आप इंस्टॉल की दर या इंस्टॉल की संख्या को अनुभव के तौर पर देखा जा सकता है. अगर आपको स्पैम का पता चलता है, जिन पब्लिशर ने पहले स्पैम भेजा है उन्हें फ़िल्टर करने के लिए. इंसानों का इस्तेमाल करने से न घबराएं बदलाव करना है. अगर आपको अपने संपर्कों को रैंक करना है, तो हाल ही में इस्तेमाल किए गए संपर्कों को रैंक करें सबसे ऊंचे (या अंग्रेज़ी वर्णमाला के क्रम में). अगर मशीन लर्निंग ठीक से काम नहीं करती आपके प्रॉडक्ट के लिए ज़रूरी है, तो जब तक आपके पास डेटा न हो, तब तक इसका इस्तेमाल न करें.

नियम #2: सबसे पहले, मेट्रिक डिज़ाइन करें और उन्हें लागू करें.

आपका मशीन लर्निंग सिस्टम क्या करेगा, इसे औपचारिक तय करने से पहले ज़्यादा से ज़्यादा काम ट्रैक करें जो आपके मौजूदा सिस्टम में सबसे ज़्यादा काम आ सकते हैं. ऐसा इन वजहों से करें:

1. सिस्टम का इस्तेमाल करने वाले लोगों से, शुरुआत में ही अनुमति लेना आसान होता है.
2. अगर आपको लगता है कि आने वाले समय में कोई समस्या हो सकती है, तो पुराना डेटा देखने में मदद मिलती है.
3. अगर मेट्रिक इंस्ट्रुमेंटेशन को ध्यान में रखकर अपना सिस्टम डिज़ाइन किया जाता है, तो के लिए बेहतर होगा आपको भविष्य में ज़रूरत हो. खास तौर पर, जब आप ऐसा नहीं करना चाहेंगे कि आपकी का इस्तेमाल करें!
4. आपको दिखेगा कि कौनसी चीज़ें बदलती हैं और कौनसी चीज़ें पहले जैसी ही रहती हैं. उदाहरण के लिए, मान लेते हैं कि आपको सीधे तौर पर एक दिन के सक्रिय उपयोगकर्ताओं को ऑप्टिमाइज़ करना है. हालांकि, सिस्टम के शुरुआती बदलावों के दौरान, आपको लगता है कि उपयोगकर्ता अनुभव में नाटकीय बदलाव होने पर भी, मेट्रिक के हिसाब से फ़िल्टर करें.

Google Plus की टीम मापती है कि हर बार पढ़े जाने के बाद, प्रति रीड पुनः साझाकरण, प्लस वन प्रति पढ़ें, टिप्पणियां/पढ़ें, हर उपयोगकर्ता के हिसाब से टिप्पणियां, हर उपयोगकर्ता के हिसाब से फिर से शेयर करना वगैरह जिनका वे इस्तेमाल करते हैं को यह पता लगाना होता है कि कोई पोस्ट कितनी अच्छी है. साथ ही, ध्यान रखें कि प्रयोग का फ़्रेमवर्क, जिसमें उपयोगकर्ताओं को बकेट और एग्रीगेट में ग्रुप किया जा सकता है एक्सपेरिमेंट के हिसाब से आंकड़े दिखाना ज़रूरी है. यहां जाएं: नियम #12.

मेट्रिक इकट्ठा करने में ज़्यादा उदार होने से, आपको पूरी जानकारी मिल सकती है तीन सबसे सही तरीक़े यहाँ दिए गए हैं. क्या आपको कोई समस्या दिखी? इसे ट्रैक करने के लिए मेट्रिक जोड़ें! कुछ चीज़ों को लेकर उत्साहित पिछली रिलीज़ पर डेटा में हुए बदलाव? इसे ट्रैक करने के लिए मेट्रिक जोड़ें!

नियम #3: जटिल अनुमान के बजाय मशीन लर्निंग का इस्तेमाल करें.

एक आसान अनुभव आपके प्रॉडक्ट को लोगों तक पहुंचा सकता है. एक जटिल अनुमान है बनाए रखने लायक नहीं हैं. एक बार आपके पास डेटा होने और उस काम की बुनियादी जानकारी हो जाने के बाद पूरा करने के लिए, मशीन लर्निंग पर जाएं. ज़्यादातर सॉफ़्टवेयर इंजीनियरिंग में करने के लिए प्रोत्साहित करते हैं, तो आप अपने काम करने के तरीके को लगातार अपडेट करना चाहेंगे, चाहे यह एक अनुभव हो सकता है और आप पा सकते हैं कि मशीन लर्निंग मॉडल को अपडेट करना और उसका रखरखाव करना ज़्यादा आसान है (देखें नियम #16).

मशीन लर्निंग का पहला फ़ेज़: आपकी पहली पाइपलाइन

अपनी पहली पाइपलाइन के लिए अपने सिस्टम के इन्फ़्रास्ट्रक्चर पर ध्यान दें. हालांकि, यह मज़ेदार है आप उन सभी काल्पनिक मशीन लर्निंग के बारे में सोचें जिन्हें अब आप बनाने जा रहे हैं, आपके लिए यह पता लगाना मुश्किल होगा कि क्या हो रहा है. पाइपलाइन.

नियम #4: पहले मॉडल को आसान रखें और बुनियादी ढांचे का इस्तेमाल करें.

पहला मॉडल आपके प्रॉडक्ट को सबसे ज़्यादा बेहतर बनाता है. इसलिए, इसकी ज़रूरत नहीं है कल्पना करती हैं. हालांकि, आपको इंफ़्रास्ट्रक्चर से जुड़ी ज़्यादा समस्याएं मिलेंगी उम्मीद है. इससे पहले कि कोई आपके नए मशीन लर्निंग सिस्टम का इस्तेमाल कर सके, आपके पास तय करने के लिए:

• लर्निंग एल्गोरिदम के उदाहरण पाने का तरीका.
• "अच्छा" शब्द की पहली झलक और "खराब" आपके सिस्टम के लिए कितना अहम है.
• अपने मॉडल को अपने ऐप्लिकेशन में इंटिग्रेट करने का तरीका. इनमें से कोई एक तरीका अपनाएं मॉडल को लाइव या ऑफ़लाइन उदाहरणों पर मॉडल की प्रीकंप्यूट करें और नतीजों को टेबल में स्टोर करें. उदाहरण के लिए, हो सकता है कि आप वेब पेजों को पहले से अलग करना और नतीजों को सेव करना चाहें लेकिन हो सकता है कि आप चैट मैसेज की लाइव कैटगरी तय करना चाहें.

आसान सुविधाएं चुनने से, यह पक्का करना आसान हो जाता है कि:

• सुविधाएं, आपके लर्निंग एल्गोरिदम तक सही तरीके से पहुंचती हैं.
• मॉडल उचित वज़न हासिल करता है.
• सुविधाएं, सर्वर में आपके मॉडल तक ठीक तरह से पहुंचती हैं.

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

नियम #5: मशीन लर्निंग से अलग इंफ़्रास्ट्रक्चर की जांच करें.

पक्का करें कि इन्फ़्रास्ट्रक्चर की जांच की जा सके. साथ ही, यह भी पक्का करें कि सिस्टम इस तरह बना होता है कि आप इसके आस-पास की हर चीज़ की जाँच कर सकें. खास तौर पर:

1. एल्गोरिदम में डेटा पाने की जांच करें. उन सुविधा कॉलम की जांच करें जो अपने-आप भरी जानी चाहिए. जहां निजता की अनुमति हो, मैन्युअल रूप से अपने ट्रेनिंग एल्गोरिदम के इनपुट की जांच करें. अगर हो सके, तो एक ही डेटा के आंकड़ों की तुलना में आपकी पाइपलाइन में मौजूद आंकड़े कहीं और प्रोसेस नहीं किया जा सकता.
2. ट्रेनिंग एल्गोरिदम से मॉडल पाने का टेस्ट करना. पक्का करें कि आपके ट्रेनिंग एनवायरमेंट में मॉडल, मॉडल के बराबर स्कोर देता है अपने मौजूदा माहौल में (देखें. नियम #37).

मशीन लर्निंग में एक ऐसी चीज़ होती है जिसकी उम्मीद नहीं की जा सकती, इसलिए पक्का करें कि ट्रेनिंग और सर्विंग में उदाहरण बनाने के लिए, कोड से जुड़े टेस्ट करता हो और जिसे लोड करने के दौरान, एक तय मॉडल का इस्तेमाल किया जा सकता है. साथ ही, यह ज़रूरी है कि अपने डेटा को समझने के लिए: इस लिंक पर जाएं बड़े और जटिल डेटा सेट का विश्लेषण करने के लिए व्यावहारिक सलाह.

नियम #6: पाइपलाइन कॉपी करते समय छूटे हुए डेटा से सावधान रहें.

अक्सर हम किसी मौजूदा पाइपलाइन को कॉपी करके एक पाइपलाइन बनाते हैं (यानी, कार्गो कल्ट प्रोग्रामिंग ) और पुरानी पाइपलाइन से वह डेटा मिलता है, जिसकी हमें नई पाइपलाइन के लिए ज़रूरत होती है. उदाहरण के लिए, Google Plus की पाइपलाइन पुरानी पोस्ट को कम करता है (क्योंकि यह नई पोस्ट की रैंक तय करने की कोशिश करता है). यह पाइपलाइन पहले Google Plus स्ट्रीम के लिए इस्तेमाल करने के लिए कॉपी किया गया, जहां पुरानी पोस्ट लेकिन पाइपलाइन अब भी पुरानी पोस्ट को ड्रॉप कर रही थी. अन्य सामान्य पैटर्न, सिर्फ़ उस डेटा को लॉग करना है जो उपयोगकर्ता ने देखा था. इस तरह, इस डेटा को इसका कोई फ़ायदा नहीं है. अगर हम यह मॉडल करना चाहें कि कोई पोस्ट उपयोगकर्ता ने क्यों नहीं देखी, क्योंकि सभी नेगेटिव उदाहरण हटा दिए गए हैं. यहां ऐसी ही एक समस्या आई है ऐप्लिकेशन चलाएं. Play के ऐप्लिकेशन के होम पेज पर काम करने के दौरान, एक नई पाइपलाइन बनाई गई इसमें Play Games के लैंडिंग पेज के ऐसे उदाहरण शामिल हैं जिनमें साफ़ तौर पर बताएं कि हर उदाहरण कहां से आया है.

नियम #7: अनुभव को सुविधाओं में बदलें या उन्हें बाहरी तौर पर इस्तेमाल करें.

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

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

किसी मशीन लर्निंग (एमएल) में अनुभव की जानकारी का इस्तेमाल करते समय, जोड़ी गई जटिलता का ध्यान रखें सिस्टम. अपने नए मशीन लर्निंग एल्गोरिदम में पुराने अनुभव का इस्तेमाल करने से आसान ट्रांज़िशन बनाने में मदद मिलेगी, लेकिन यह सोचें कि क्या कोई उसी प्रभाव को प्राप्त करने का सबसे आसान तरीका है.

निगरानी

आम तौर पर, साफ़-सफ़ाई के बारे में चेतावनी दें. जैसे, चेतावनियों को कार्रवाई के लायक बनाना आपके पास डैशबोर्ड पेज होना चाहिए.

नियम #8: अपने सिस्टम की नवीनता से संबंधित आवश्यकताएं जानें.

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

नियम #9: मॉडल एक्सपोर्ट करने से पहले समस्याओं का पता लगाएं.

कई मशीन लर्निंग सिस्टम में एक स्टेज होता है, जहां मॉडल को पेश किया जा रहा है. अगर एक्सपोर्ट किए गए मॉडल में कोई समस्या है, तो समस्या.

मॉडल को एक्सपोर्ट करने से ठीक पहले, सही जानकारी की जांच करें. खास तौर पर, पक्का करें कि कि मॉडल की परफ़ॉर्मेंस, होल्ड किए गए डेटा के हिसाब से सही हो. या अगर आपके पास है डेटा को लेकर दुविधा बनी रहे, मॉडल एक्सपोर्ट न करें. कई टीमें लगातार डिप्लॉय होने वाले मॉडल, आरओसी कर्व (या AUC) एक्सपोर्ट करने से पहले. ऐसे मॉडल से जुड़ी समस्याओं को एक्सपोर्ट करना ज़रूरी है जिन्हें एक्सपोर्ट नहीं किया गया है ईमेल सूचना मिलेगी. हालांकि, हो सकता है कि उपयोगकर्ताओं को मिलने वाले मॉडल में समस्याएं मौजूद हों. इसके लिए, एक पेज की ज़रूरत पड़ सकती है. बहुत बढ़िया ताकि उपयोगकर्ताओं पर असर डालने से पहले आप इंतज़ार कर सकें.

नियम #10: साइलेंट मोड पर हो रही गड़बड़ियों पर नज़र रखें.

यह समस्या दूसरी चीज़ों की तुलना में मशीन लर्निंग सिस्टम में ज़्यादा होती है कई तरह के सिस्टम होते हैं. मान लें कि जिस टेबल को जोड़ा जा रहा है वह अपडेट नहीं किया जा सकेगा. मशीन लर्निंग सिस्टम, सिस्टम और उसके व्यवहार में बदलाव करेगा हमेशा अच्छी होती रहेगी और यह धीरे-धीरे मिटती जाएगी. कभी-कभी आपको वे टेबल जो महीने पुरानी हैं. उन्हें रीफ़्रेश करने से परफ़ॉर्मेंस बेहतर होती है उस तिमाही में हुए किसी भी अन्य लॉन्च की तुलना में ज़्यादा! इसका कवरेज सुविधा लागू करने में होने वाले बदलावों की वजह से बदल सकती है: उदाहरण के लिए, फ़ीचर कॉलम यह 90% उदाहरणों से अपने-आप भर जाती है. उदाहरण. एक बार खेलें, जो 6 महीनों से पुरानी हो चुकी टेबल पर नज़र आ रही थी सिर्फ़ टेबल से इंस्टॉल रेट में 2% की बढ़ोतरी हुई. यदि आप के आंकड़े ट्रैक करते हैं, तो डेटा को कभी-कभी मैन्युअल तरीके से जांचा जाता है, तो आपके पास मदद मिलती है.

नियम #11: सुविधा कॉलम के मालिक और दस्तावेज़ दें.

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

आपका पहला मकसद

आपके पास उस सिस्टम से जुड़ी कई मेट्रिक या मेज़रमेंट हैं जो आपके लिए अहम हैं, लेकिन आपके मशीन लर्निंग एल्गोरिदम को अक्सर एक मकसद, वह संख्या दिख रही है, जिस पर आपका एल्गोरिदम "आज़मा रहा है" है ऑप्टिमाइज़ करने के लिए भी किया जा सकता है. मुझे यहां जाना है लक्ष्यों और मेट्रिक के बीच सेट करें: मेट्रिक, आपके सिस्टम को मिलने वाली कोई भी संख्या होती है रिपोर्ट देखी जा सकती हैं, जो अहम हो भी सकती हैं और नहीं भी. इन्हें भी देखें नियम #2.

नियम #12: जिस मकसद को सीधे तौर पर ऑप्टिमाइज़ करना है उसके बारे में बहुत ज़्यादा न सोचें.

आपका मकसद है पैसे कमाना, अपने उपयोगकर्ताओं को खुश रखना, और दुनिया को बेहतर बनाना जगह. ऐसी कई मेट्रिक मौजूद हैं जो आपके लिए अहम हैं. इसलिए, आपको अपने सभी कैंपेन (नियम #2 देखें). हालांकि, मशीन लर्निंग की शुरुआत में ही, मशीन लर्निंग का इस्तेमाल करते हुए आपने देखा होगा कि यह सभी का इस्तेमाल करके जिन्हें सीधे ऑप्टिमाइज़ नहीं किया जाता. उदाहरण के लिए, मान लीजिए कि आपको अपने क्लिक की संख्या और साइट पर बिताया गया समय. यदि आप इतने समय के लिए अनुकूलित करते हैं तो आपको उपयोग किए गए समय में बढ़ोतरी दिखाई दे सकती है.

इसलिए, इसे आसान रखें और अलग-अलग मेट्रिक के बीच संतुलन बनाने के बारे में ज़्यादा सोचें जब सभी मेट्रिक को आसानी से बढ़ाया जा सके. यह नियम भी न अपनाएं हालांकि: अपने उद्देश्य और सिस्टम (देखें नियम #39). और, अगर आप पाते हैं कि कारोबार में टिके रहने के लिए अनुकूलित की गई मेट्रिक, लेकिन लॉन्च न करने का निर्णय लेने पर, कुछ उद्देश्य संशोधन हो सकता है ज़रूरी है.

नियम #13: अपने पहले मकसद के लिए, आसान, मॉनिटर किया जा सकने वाला, और एट्रिब्यूट होने वाली मेट्रिक चुनें.

आम तौर पर, आपको पता नहीं होता कि वीडियो का असल मकसद क्या है. आपको लगता है कि आप ऐसा करते हैं, लेकिन फिर आपको अपने पुराने सिस्टम और नए एमएल के डेटा और साथ-साथ उसका विश्लेषण देखने को मिलेगा आपको लगता है कि आपको अपने मकसद में बदलाव करना है. इसके अलावा, अलग-अलग टीम सदस्य अक्सर सही उद्देश्य पर सहमत नहीं हो पाते हैं. एमएल का मकसद यह होना चाहिए कुछ ऐसा जो मापने में आसान हो और "सही" के लिए प्रॉक्सी हो मकसद. असल में, अक्सर कोई "सही" नहीं होता उद्देश्य (देखें नियम#39). तो आसान एमएल मकसद के बारे में ट्रेनिंग दें. साथ ही, "नीति की लेयर" बनाने के बारे में सोचें सबसे ऊपर की मदद से अतिरिक्त लॉजिक (उम्मीद है कि बहुत आसान लॉजिक) जोड़ा जा सकता है आखिरी रैंकिंग तय करें.

मॉडल बनाने का सबसे आसान तरीका, उपयोगकर्ता का ऐसा व्यवहार है जो सीधे तौर पर निगरानी में रखा जाता है. साथ ही, सिस्टम की कार्रवाई:

• क्या इस रैंक वाले लिंक पर क्लिक किया गया?
• क्या रैंक किया गया यह ऑब्जेक्ट डाउनलोड किया गया?
• क्या रैंक किए गए इस ऑब्जेक्ट को फ़ॉरवर्ड किया गया/इसका जवाब दिया गया/ईमेल भेजा गया?
• क्या रैंक किए गए इस ऑब्जेक्ट को रेटिंग दी गई थी?
• क्या दिखाए गए इस ऑब्जेक्ट को स्पैम/पोर्नोग्राफ़ी/आपत्तिजनक के तौर पर मार्क किया गया था?

शुरुआत में, इनडायरेक्ट इफ़ेक्ट को मॉडल करने से बचें:

• क्या उपयोगकर्ता अगले दिन विज़िट किया?
• उपयोगकर्ता ने साइट पर कितनी देर तक विज़िट किया?
• हर दिन के सक्रिय उपयोगकर्ता कितने थे?

इनडायरेक्ट इफ़ेक्ट से बेहतरीन मेट्रिक बनती हैं. इनका इस्तेमाल A/B टेस्टिंग और लॉन्च के दौरान किया जा सकता है तय करते हैं.

आखिर में, मशीन लर्निंग से ये समझने की कोशिश न करें:

• क्या उपयोगकर्ता, प्रॉडक्ट इस्तेमाल करके खुश है?
• क्या उपयोगकर्ता अनुभव से संतुष्ट है?
• क्या प्रॉडक्ट से लोगों की सेहत बेहतर हो रही है?
• इससे कंपनी की सेहत पर क्या असर पड़ेगा?

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

नियम #14: इंटरप्रेटेड मॉडल से शुरुआत करना, डीबग करना आसान बनाता है.

लीनियर रिग्रेशन, लॉजिस्टिक रिग्रेशन, और पॉइसन रिग्रेशन जो एक प्रॉबेब्लिस्टिक मॉडल से प्रेरित होते हैं. हर अनुमान को इस तरह समझा जा सकता है कि प्रायिकता या अपेक्षित मान. इससे, मॉडल के मुकाबले इन्हें डीबग करना ज़्यादा आसान हो जाता है जो ऐसे लक्ष्यों का इस्तेमाल करते हों (शून्य से एक नुकसान, कई तरह के कब्ज़ों का नुकसान वगैरह) डेटा की कैटगरी तय करने की प्रोसेस को सटीक बनाने या रैंकिंग की परफ़ॉर्मेंस को सीधे तौर पर ऑप्टिमाइज़ करने के लिए किया जा सकता है. इसके लिए उदाहरण के लिए, अगर ट्रेनिंग की प्रायिकताओं में अंतर होता है, तो या प्रोडक्शन सिस्टम की जांच करने से पता चलता है कि यह फ़र्क़ कोई समस्या सामने आए.

उदाहरण के लिए, लीनियर, लॉजिस्टिक या पॉइसन रिग्रेशन में, इसके सबसेट हैं वह डेटा जिसमें औसत अनुमानित उम्मीद, औसत लेबल (1- कैलिब्रेट किया जाता है या सिर्फ़ कैलिब्रेट किया जाता है). यह मान लेते हैं कि आपके पास कोई रेगुलराइज़ेशन लागू कर दिया है और आपके एल्गोरिदम की जानकारी इकट्ठा हो गई है. सही है. अगर आपके पास कोई ऐसी सुविधा है जो हर उदाहरण के लिए 1 या 0 है, तो फिर तीन उदाहरणों का सेट, जहां उस सुविधा की वैल्यू 1 है, कैलिब्रेट किया जाता है. साथ ही, अगर आपको हर उदाहरण के लिए ऐसी सुविधा है जो 1 है, तो सभी उदाहरणों का सेट कैलिब्रेट किया गया है.

आसान मॉडल की मदद से, फ़ीडबैक लूप से निपटना आसान होता है (देखें नियम #36). अक्सर, हम इन संभावित अनुमानों का इस्तेमाल फ़ैसला लेने के लिए करते हैं: जैसे, रैंक अनुमानित मान को कम करने में पोस्ट. उदाहरण के लिए, क्लिक/डाउनलोड/वगैरह की संभावना. हालांकि, याद रखें कि कौनसा मॉडल चुनना है, तो मॉडल को दिए गए फ़ैसले के बारे में, दिए गए डेटा की संभावना से ज़्यादा मायने रखता है (देखें कि नियम #27).

नियम #15: नीति की लेयर में, स्पैम फ़िल्टर करने और क्वालिटी की रैंकिंग को अलग-अलग करें.

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

कुछ स्तर पर, इन दोनों सिस्टम के आउटपुट को इंटिग्रेट करना होगा. नहीं ध्यान रखें कि खोज के नतीजों में स्पैम को फ़िल्टर करना ज़्यादा सख्त होगा ईमेल मैसेज में स्पैम फ़िल्टर करने से ज़्यादा है. इसके अलावा, यह एक आम तरीका है स्पैम के तौर पर मार्क किया गया है.

एमएल फ़ेज़ II: फ़ीचर इंजीनियरिंग

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

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

नियम #16: लॉन्च करने और इसे फिर से करने की योजना बनाएं.

यह उम्मीद न करें कि आपको जिस मॉडल पर अभी काम करना है वह आखिरी मॉडल होगा मॉडल लॉन्च करना हो या यहां तक कि लॉन्च करना बंद भी किया जा सकता हो. इस प्रकार देखें कि क्या इस लॉन्च में जोड़ी जा रही जटिलता धीमी हो जाएगी आने वाले समय में लॉन्च करने के बारे में है. कई टीमों ने हर तिमाही या उससे ज़्यादा साल. नए मॉडल लॉन्च करने की तीन बुनियादी वजहें हैं:

• आपके पास नई सुविधाएं हैं.
• रेगुलराइज़ेशन को ट्यून किया जा रहा है और पुरानी सुविधाओं को नए तरीकों से इंटिग्रेट किया जा रहा है.
• आप मकसद को ट्यून कर रहे हैं.

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

नियम #17: सीखी गई सुविधाओं के बजाय सीधे तौर पर मॉनिटर की गई और रिपोर्ट की गई सुविधाओं से शुरू करें.

यह एक विवादित मुद्दा हो सकता है, लेकिन इसमें बहुत-से नुकसानों से बचा जा सकता है. पहला आइए, जानते हैं कि सीखी गई सुविधा क्या है. सीखी गई सुविधा, एक सुविधा है या तो किसी बाहरी सिस्टम से जनरेट होता है (जैसे कि बिना निगरानी वाला क्लस्टरिंग या छात्र-छात्रा होने की वजह से (उदाहरण के लिए, फ़ैक्टर्ड मॉडल या डीप लर्निंग के ज़रिए). ये दोनों तरीके मददगार हो सकते हैं, लेकिन इनमें कई समस्याएं हो सकती हैं. इसलिए, आपको अपने पहले मॉडल में नहीं होना चाहिए.

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

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

नियम #18: कॉन्टेंट के ऐसे फ़ीचर एक्सप्लोर करें जो अलग-अलग कॉन्टेक्स्ट के हिसाब से होते हैं.

आम तौर पर, मशीन लर्निंग सिस्टम बड़े पैमाने पर काम करता है. इसके लिए उदाहरण के लिए, अगर आप किसी ऐसी पोस्ट की कल्पना करते हैं जिसका उपयोग सर्वाधिक चर्चित क्या है, में किया जा सकता है, तो किसी पोस्ट को गर्म है. अगर आपने छात्र-छात्राओं को ये आंकड़े उपलब्ध कराए हैं, तो इससे उनकी नई पोस्ट जिसमें उस संदर्भ के लिए कोई डेटा न हो जिसे वह ऑप्टिमाइज़ कर रहा है. YouTube 'अगला वीडियो' सेक्शन में, आपके वीडियो को देखे जाने की संख्या का इस्तेमाल किया जा सकता है. इसके अलावा, देखे जाने की संख्या (इसमें यह पता चलता है कि एक वीडियो को दूसरे वीडियो के बाद कितनी बार देखा गया देखे गए) YouTube खोज से. अश्लील कॉन्टेंट का इस्तेमाल भी किया जा सकता है उपयोगकर्ता रेटिंग. आखिर में, अगर आपके पास कोई उपयोगकर्ता कार्रवाई है जिसे लेबल के तौर पर इस्तेमाल किया जा रहा है, तो दस्तावेज़ पर की गई कार्रवाई को किसी अलग कॉन्टेक्स्ट में देखना सुविधा. इन सभी सुविधाओं की मदद से, संदर्भ के हिसाब से नया कॉन्टेंट बनाया जा सकता है. ध्यान दें कि यह मनमुताबिक बनाने के बारे में नहीं है: यह देखें कि क्या किसी को पहले उस संदर्भ में कॉन्टेंट पोस्ट करें.

नियम #19: अगर हो सके, तो बहुत ही खास सुविधाओं का इस्तेमाल करें.

बहुत सारे डेटा के साथ, लाखों आसान सुविधाओं को सीखना आसान है. कुछ जटिल सुविधाएं भी शामिल हैं. वापस लाए जा रहे दस्तावेज़ों के आइडेंटिफ़ायर और कैननिकल क्वेरी के लिए ज़्यादा सामान्य जानकारी नहीं दी जाती. हालांकि, कैननिकल के तौर पर की गई क्वेरी हेड क्वेरी पर आपके लेबल के साथ रैंकिंग. इसलिए, ऐसे ग्रुप बनाने से न घबराएं ऐसी सुविधाएं जहां हर सुविधा आपके डेटा के बहुत छोटे से हिस्से पर लागू होती है, लेकिन कुल कवरेज 90% से ज़्यादा है. रेगुलराइज़ेशन का इस्तेमाल करके, ऐसी सुविधाएं जो बहुत कम उदाहरणों पर लागू होती हैं.

नियम #20: नई सुविधाएं बनाने के लिए, मौजूदा सुविधाओं को एक साथ जोड़ें और उनमें बदलाव करें. ये सुविधाएं ऐसे तरीकों से बनाई जा सकती हैं जिन्हें लोग आसानी से समझ सकें.

सुविधाओं को जोड़ने और उनमें बदलाव करने के कई तरीके हैं. मशीन लर्निंग TensorFlow जैसे सिस्टम आपको ट्रांसफ़ॉर्मेशन. दो सबसे मानक दृष्टिकोण हैं "विच्छेदन" और "क्रॉस" भी होने चाहिए.

डिस्क्रीटाइज़ेशन में लगातार एक सुविधा का इस्तेमाल करना और कई मॉडल बनाना शामिल है अलग-अलग सुविधाएं उपलब्ध कराता है. उम्र जैसी सुविधा का इस्तेमाल करते रहें. आप की उम्र 18 साल से कम होने पर, यह सुविधा 1 है. 1, जब उम्र 18 से 35 साल के बीच हो वगैरह. अलग-अलग पहलुओं के बारे में न सोचें ये हिस्टोग्राम: बुनियादी मात्राओं से आपको ज़्यादातर असर पड़ेगा.

क्रॉस, दो या उससे ज़्यादा सुविधा कॉलम को जोड़ते हैं. TensorFlow के फ़ील्ड में, एक फ़ीचर कॉलम शब्दावली, एक जैसी सुविधाओं का एक सेट है, (जैसे, {male, Women}, {US, कनाडा, मेक्सिको}, वगैरह). क्रॉस, सुविधा का नया कॉलम है. इसमें पहले से मौजूद उदाहरण के लिए, {male, Women} × {US,Canada, Canada}. इस नई सुविधा का कॉलम यह सुविधा (पुरुष, कनाडा) शामिल होगी. अगर TensorFlow का इस्तेमाल किया जा रहा है और TensorFlow को आपके लिए यह क्रॉस बनाने के लिए कहें, तो यह (पुरुष, कनाडा) सुविधा कनाडा के पुरुष नागरिकों के उदाहरण देखें. ध्यान रखें कि इसे बनाने में बहुत तीन, चार या ज़्यादा आधार के क्रॉस वाले मॉडल को सीखने के लिए, डेटा की मात्रा सुविधा कॉलम.

सुविधा के बहुत बड़े कॉलम बनाने वाले क्रॉस पर ज़्यादा टेक्स्ट दिख सकता है. उदाहरण के लिए, मान लें कि आप किसी तरह की खोज कर रहे हैं और आपके पास एक सुविधा कॉलम है शब्दों के साथ खोज करते हैं, और आपके पास एक सुविधा कॉलम है जिसमें शब्द दस्तावेज़. आप इन्हें क्रॉस के साथ जोड़ सकते हैं, लेकिन आखिर में आपको बहुत सारे सुविधाएं (नियम #21 देखें).

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

नियम #21: किसी लीनियर मॉडल में मौजूद सुविधा के वज़न की संख्या, करीब-करीब आपके डेटा की मात्रा के अनुपात में होगी.

इससे, आंकड़ों से जुड़े दिलचस्प नतीजे देखने को मिले हैं. किसी मॉडल के लिए जटिलता का उचित स्तर, लेकिन यह नियम मूल रूप से जिन्हें जानना आपके लिए ज़रूरी है. मैंने ऐसी बातचीत की थी जिसमें लोगों को लग रहा था कि एक हज़ार उदाहरणों से कुछ भी सीखा जा सकता है या आपको को 10 लाख से ज़्यादा उदाहरणों की ज़रूरत है, क्योंकि वे किसी खास तरीके से अटक जाते हैं बहुत ज़रूरी है. सबसे ज़रूरी है कि आप अपने लर्निंग सिस्टम को अपने डेटा के साइज़ के हिसाब से स्केल करें:

1. अगर आप किसी खोज रैंकिंग सिस्टम पर काम कर रहे हैं और आपको दस्तावेज़ और क्वेरी में अलग-अलग शब्द होने चाहिए और आपके पास 1,000 लेबल किए गए उदाहरण के लिए, आपको दस्तावेज़ के बीच में डॉट प्रॉडक्ट और क्वेरी फ़ीचर, TF-IDF, और ट्रेनिंग के दौरान इस्तेमाल किए गए 50% से ज़्यादा सुविधाएँ. 1,000 उदाहरण, एक दर्जन सुविधाएं.
2. अगर आपके पास लाखों उदाहरण हैं, तो दस्तावेज़ और क्वेरी को काट दें फ़ीचर कॉलम पर क्लिक करें. इसके लिए, रेगुलराइज़ेशन और संभावित तौर पर सुविधा चुनने के विकल्प का इस्तेमाल किया जा सकता है. इससे आपको लाखों सुविधाएं मिलेंगी, लेकिन रेगुलराइज़ेशन के साथ आपको एक आवाज़ कम हो जाएगी. दस लाख उदाहरण, शायद एक लाख सुविधाएं.
3. अगर आपके पास करोड़ों या अरबों उदाहरण हैं, तो सुविधा चुनने के विकल्प का इस्तेमाल करके, दस्तावेज़ और क्वेरी टोकन वाले फ़ीचर कॉलम और रेगुलराइज़ेशन के लिए उपलब्ध है. आपके पास एक अरब उदाहरण और एक करोड़ सुविधाएँ. स्टैटिस्टिकल लर्निंग थ्योरी में ऐसा बहुत कम बार होता है जो ज़्यादा सटीक तरीके से नहीं देता, लेकिन के लिए बहुत उपयोगी सलाह दी है.

आखिर में, इसका इस्तेमाल करें नियम #28 इसके बाद, तय करें कि किन सुविधाओं का इस्तेमाल करना है.

नियम #22: उन सुविधाओं को हटाएं जिनका अब इस्तेमाल नहीं किया जा रहा है.

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

कौनसी सुविधाएं जोड़ने या रखने हैं, यह तय करते समय कवरेज को ध्यान में रखें. कितने उदाहरण के लिए, इस सुविधा के तहत क्या होता है? उदाहरण के लिए, अगर आपके पास मनमुताबिक बनाने की सुविधाएं मिलती हैं, लेकिन आपके सिर्फ़ 8% उपयोगकर्ताओं को मनमुताबिक अनुभव मिलता है नहीं है, तो यह बहुत प्रभावी नहीं होगा.

साथ ही, कुछ सुविधाएँ उनके वज़न से ज़्यादा हों. उदाहरण के लिए, अगर आपके पास ऐसी सुविधा है जो सिर्फ़ 1% डेटा को कवर करती है, लेकिन 90% उदाहरण अगर यह सुविधा पॉज़िटिव है, तो इसे जोड़ना बहुत अच्छा होगा.

सिस्टम का ह्यूमन ऐनलिसिस

मशीन लर्निंग के तीसरे चरण में जाने से पहले, यह ज़रूरी है कि किसी ऐसी चीज़ पर फ़ोकस करना जिसे किसी भी मशीन लर्निंग क्लास में नहीं पढ़ाया गया है: कैसे मौजूदा मॉडल को देख और उसमें सुधार कर सकते हैं. यह आर्टिफ़िशियल इंटेलिजेंस से चलने वाली और फिर भी ऐसे कई प्रतिरूप हैं जिनसे बचने में मदद मिलती है.

नियम #23: आप एक आम असली उपयोगकर्ता नहीं हैं.

यह किसी टीम को किसी टीम में शामिल करने का सबसे आसान तरीका है. हालांकि, कुछ फ़िशफ़ूडिंग के बहुत सारे फ़ायदे (अपनी टीम के एक प्रोटोटाइप का इस्तेमाल करके) और dogfooding (अपनी कंपनी के अंदर एक प्रोटोटाइप का इस्तेमाल करके), कर्मचारियों को इन बातों पर ध्यान देना चाहिए कि परफ़ॉर्मेंस सही है या नहीं. ऐसा बदलाव जो साफ़ तौर पर बुरा है का इस्तेमाल नहीं किया जाना चाहिए, प्रोडक्शन के पास मौजूद चीज़ों को को आगे बढ़ाने के लिए, या तो सामान्य लोगों को पैसे चुकाकर, क्राउडसोर्सिंग प्लैटफ़ॉर्म या असली उपयोगकर्ताओं पर लाइव एक्सपेरिमेंट के ज़रिए.

ऐसा होने की दो वजहें हैं. पहली चीज़ यह है कि आप कोड. हो सकता है कि आप पोस्ट के किसी विशेष पहलू को ढूंढ रहे हों या आप बहुत ज़्यादा भावनात्मक तौर पर शामिल नहीं होते (जैसे कि एक पक्ष की पुष्टि करना). दूसरा है, आपका समय बहुत कीमती है. एक कमरे में नौ इंजीनियर की लागत पर विचार करें और सोचें कि कितने कॉन्ट्रैक्टेड लेबल हैं, जो क्राउडसोर्सिंग प्लैटफ़ॉर्म.

अगर आपको वाकई में उपयोगकर्ता के सुझाव या राय चाहिए, तो उपयोगकर्ता अनुभव का इस्तेमाल करें इस्तेमाल करने का तरीका जानें. यूज़र पर्सोना बनाएं (एक विवरण बिल बक्सटन में है उपयोगकर्ता अनुभव बनाना) पहले ही इस्तेमाल कर सकते हैं और उपयोगिता की जाँच कर सकते हैं (एक ऐसा ब्यौरा है स्टीव क्रुग के साथ Don’t Make Me Think) बाद में. उपयोगकर्ता पर्सोना में एक काल्पनिक उपयोगकर्ता बनाना शामिल है. उदाहरण के लिए, अगर आपकी टीम में पुरुष हैं, तो 35 साल की महिला उपयोगकर्ता का पर्सोना (उपयोगकर्ता के साथ पूरी तरह से मेल खाने वाला) डिज़ाइन करना सुविधाएँ देखें), और इसके लिए 10 परिणामों के बजाय इससे जनरेट होने वाले परिणाम देखें 25 से 40 साल के पुरुष. शॉर्ट वीडियो की मदद से दर्शकों को प्रतिक्रिया देने के लिए प्रेरित करना इस्तेमाल करने से जुड़ी जांच की जा रही हो, तो साइट (स्थानीय या किसी दूसरी जगह से) भी इस्तेमाल की जा सकती है. देखें.

नियम #24: मॉडल के बीच के डेल्टा को मापें.

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

नियम #25: मॉडल चुनते समय, काम की परफ़ॉर्मेंस, अनुमानित पावर को पीछे छोड़ देती है.

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

नियम #26: मापी गई गड़बड़ियों में पैटर्न देखें और नई सुविधाएं बनाएं.

मान लें कि आपको ट्रेनिंग का एक उदाहरण दिखता है कि मॉडल का जवाब "गलत" है. में क्लासिफ़िकेशन टास्क है, तो यह गड़बड़ी फ़ॉल्स पॉज़िटिव या फ़ॉल्स नेगेटिव हो सकती है. रैंकिंग टास्क में, गड़बड़ी कोई ऐसा जोड़ा हो सकता है जिसमें किसी पॉज़िटिव को कम रैंक दी गई हो पर क्लिक करें. सबसे महत्वपूर्ण बात यह है कि यह एक ऐसा उदाहरण है मशीन लर्निंग सिस्टम को पता है कि यह गलती से हुआ है और हम इसे अवसर. अगर मॉडल को कोई ऐसी सुविधा दी जाती है जिससे यह गड़बड़ी को ठीक कर पाता है, तो मॉडल इसका इस्तेमाल करने की कोशिश करेगा.

दूसरी ओर, अगर आप उदाहरणों के आधार पर कोई सुविधा बनाने की कोशिश करते हैं, तो सिस्टम गलतियों को नहीं देखता, तो सुविधा को अनदेखा कर दिया जाएगा. उदाहरण के लिए, मान लीजिए कि Play ऐप्लिकेशन खोज में, कोई व्यक्ति "मुफ़्त गेम" खोजता है. मान लें सबसे अच्छे नतीजों में से एक है, गैग ऐप्लिकेशन कम काम का है. इसलिए, आपने "ऐप्लिकेशन बंद करना". हालांकि, अगर इंस्टॉल किए जाने की संख्या बढ़ाई जा रही है, और लोग जब लोग मुफ़्त गेम, "गग ऐप्लिकेशन" खोजेंगे, तो कोई गैग ऐप्लिकेशन इंस्टॉल करना सुविधा इस पर आपकी पसंद का कोई असर नहीं होगा.

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

नियम #27: अनचाहे व्यवहार का आकलन करने की कोशिश करें.

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

नियम #28: ध्यान रखें कि एक जैसा अल्पकालिक व्यवहार, एक जैसे दीर्घावधिक व्यवहार को नहीं दिखाता.

मान लें कि आपके पास एक नया सिस्टम है, जो हर doc_id और सटीक_क्वेरी को देखता है, और फिर हर क्वेरी के लिए हर दस्तावेज़ के लिए क्लिक की संभावना का हिसाब लगाता है. आपको लगता है कि इसका व्यवहार, दोनों में आपके मौजूदा सिस्टम की तरह ही है A/B टेस्टिंग कर सकते हैं, इसलिए यह आसान है, इसलिए इसे लॉन्च किया जा सकता है. हालांकि, आपने देखा कि कोई भी नया ऐप्लिकेशन नहीं दिख रहा है. क्यों? दरअसल, सिस्टम उस क्वेरी के अपने इतिहास के आधार पर ही दस्तावेज़ दिखाता है, कोई नया दस्तावेज़ दिखाया जाना चाहिए.

यह समझने के लिए कि ऐसा सिस्टम लंबे समय तक कैसे काम करेगा, यह मॉडल लाइव होने के दौरान हासिल किए गए डेटा के आधार पर ही ट्रेनिंग देता है. यह बहुत मुश्किल.

ट्रेनिंग-सर्विंग स्क्यू

ट्रेनिंग और विज्ञापन दिखाने के बीच का अंतर, ट्रेनिंग के दौरान परफ़ॉर्मेंस और प्रदर्शन के दौरान. ऐसा इन वजहों से हो सकता है:

• ट्रेनिंग और डिलीवरी वाले पाइपलाइन में, आपके डेटा को हैंडल करने के तरीके में अंतर.
• ट्रेनिंग लेने और सेवा देने के समय के बीच डेटा में होने वाला बदलाव.
• आपके मॉडल और आपके एल्गोरिदम के बीच एक फ़ीडबैक लूप.

हमने Google में प्रोडक्शन मशीन लर्निंग सिस्टम को ट्रेनिंग दी है. विज्ञापन में अंतर हो सकता है, जिससे परफ़ॉर्मेंस पर बुरा असर पड़ता है. सबसे अच्छा समाधान यह है कि इसे पूरी तरह मॉनिटर करें, ताकि सिस्टम और डेटा में किए गए बदलावों की वजह से कोई बदलाव न हो किसी का ध्यान नहीं गया.

नियम #29: अपनी तरह ट्रेनिंग लेने का सबसे अच्छा तरीका यह है कि साइट को इस्तेमाल करते समय इस्तेमाल की जाने वाली सुविधाओं के सेट को सेव कर लें और फिर ट्रेनिंग के समय इस्तेमाल करने के लिए इन सुविधाओं को एक लॉग से जोड़ें.

भले ही आप हर उदाहरण के लिए ऐसा न कर पाएं, लेकिन इसे बहुत छोटे-से अंश के लिए ही करें, जैसे कि आप यह पुष्टि कर सकते हैं कि पेजिंग और ट्रेनिंग के बीच एक जैसा संबंध है या नहीं (देखें नियम #37). जिन टीमों ने इसे बनाया है कभी-कभी नतीजों से Google को हैरानी हुई. YouTube होम पेज साइट पर लॉग इन करने की सुविधाओं पर स्विच किया गया, लेकिन यह अच्छी क्वालिटी की थी और कोड की जटिलता में कमी आई है और कई टीमें स्विच कर रही हैं तकनीकी तौर पर कम कर सकते हैं.

नियम #30: इंपोर्टेंस के महत्व वाले सैंपल डेटा का इस्तेमाल, बिना सोचे-समझे उसे न छोड़ें!

जब आपके पास बहुत ज़्यादा डेटा होता है, तो आप 1 से 12 तक की फ़ाइलें लेने का लालच देते हैं, और 13 से 99 तक की फ़ाइलों को अनदेखा करें. यह एक गलती है. हालांकि, वह डेटा जो उपयोगकर्ता को कभी नहीं दिखाया जा सकता, इसलिए अहमियत को अहमियत देना सबसे अच्छा है, क्योंकि आराम. महत्व के महत्व का मतलब है कि अगर आपने यह तय किया है कि उदाहरण के तौर पर X का सैंपल, 30% संभावना के साथ और फिर इसे 10/3 का वज़न दें. इसके साथ वे सभी कैलिब्रेशन प्रॉपर्टी जिन पर चर्चा की गई है नियम #14 फिर भी होल्ड करें.

नियम #31: ध्यान रखें कि अगर ट्रेनिंग और सर्व करने के दौरान, टेबल से डेटा जॉइन किया जाता है, तो टेबल में मौजूद डेटा बदल सकता है.

मान लें कि आप उस टेबल के साथ doc आईडी को जोड़ते हैं जिसमें उन दस्तावेज़ों की सुविधाएं मौजूद हैं (जैसे टिप्पणियों या क्लिक की संख्या बढ़ाई जा सकती है). ट्रेनिंग और सर्व करने के समय के बीच, टेबल बदल सकती है. समान दस्तावेज़ के लिए आपके मॉडल के सुझाव से फिर वे ट्रेनिंग और सेवा के बीच अंतर कर सकते हैं. इस क्रम से बचने का सबसे आसान तरीका की समस्या है, तो वेब पर सुविधाओं को लॉग करते समय नियम #32 ). अगर टेबल धीरे-धीरे बदलाव किया जा रहा है, लेकिन टेबल को हर घंटे या हर दिन उचित रूप से बंद डेटा. ध्यान दें कि इससे अब भी, समस्या.

नियम #32: जब भी मुमकिन हो, अपनी ट्रेनिंग पाइपलाइन और डिलीवरी पाइपलाइन के बीच कोड का फिर से इस्तेमाल करें.

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

नियम #33: अगर डेटा के आधार पर 5 जनवरी तक कोई मॉडल बनाया जाता है, तो उस मॉडल को 6 जनवरी और उसके बाद के डेटा पर टेस्ट करें.

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

नियम #34: फ़िल्टर करने के लिए बाइनरी क्लासिफ़िकेशन (जैसे कि स्पैम का पता लगाना या दिलचस्प ईमेल तय करना) में, बहुत ही साफ़ डेटा की परफ़ॉर्मेंस को कम समय के लिए छोड़ दें.

फ़िल्टर करने के किसी टास्क में, नेगेटिव के तौर पर मार्क किए गए उदाहरण उपयोगकर्ता है. मान लें कि आपके पास एक ऐसा फ़िल्टर है जो 75% नेगेटिव उदाहरणों को ब्लॉक करता है इस्तेमाल नहीं किया जा सकता. शायद आप उपयोगकर्ताओं को दिखाए जाने वाले इंस्टेंस. उदाहरण के लिए, अगर कोई उपयोगकर्ता किसी ईमेल को स्पैम के तौर पर मार्क करता है आपका फ़िल्टर काम करता है, तो शायद आप उससे सीखना चाहें.

हालांकि, इस तरीके में सैंपलिंग से जुड़े पूर्वाग्रह होते हैं. बेहतर डेटा इकट्ठा किया जा सकता है, अगर इसके बजाय, विज्ञापन दिखाने के दौरान आप सारे ट्रैफ़िक के 1% हिस्से पर "होल्ड आउट" का लेबल लगा देते हैं और सभी उपयोगकर्ताओं को कुछ उदाहरण दिए गए हों. अब आपका फ़िल्टर, नकारात्मक उदाहरण. ये रोक दिए गए उदाहरण आपका ट्रेनिंग डेटा बन सकते हैं.

ध्यान दें कि अगर आपका फ़िल्टर 95% या इससे ज़्यादा नेगेटिव उदाहरणों को ब्लॉक कर रहा है, तो अप्रोच कम व्यावहारिक हो जाता है. फिर भी, अगर आपको सर्विंग की मदद से परफ़ॉर्मेंस के आधार पर, एक छोटा सा नमूना बनाया जा सकता है (जैसे कि 0.1% या 0.001%). दस परफ़ॉर्मेंस का सटीक अनुमान लगाने के लिए, हज़ार उदाहरण काफ़ी हैं.

नियम #35: रैंकिंग से जुड़ी समस्याओं में पहले से मौजूद अंतर से सावधान रहें.

जब अपने रैंकिंग एल्गोरिदम को इस तरह बदला जाता है कि अलग-अलग नतीजे दिखते हैं को दिखाया है, तो आपने उस डेटा को प्रभावशाली ढंग से बदल दिया है जिससे आपका एल्गोरिदम भविष्य में बेहतर तरीके से समझें. इस तरह का तिरछा दिखाई देगा और आपको अपने तैयार किया है. इसके कई अलग-अलग तरीके हैं. ये तरीके अपनाए गए हैं: आपके मॉडल ने पहले ही देख लिया है.

1. ऐसी सुविधाओं को ज़्यादा नियमित करें जो ज़्यादा क्वेरी को कवर करती हों जो सिर्फ़ एक क्वेरी के लिए चालू हैं. इस तरह से, मॉडल ऐसी सुविधाओं के लिए जो किसी एक या कुछ क्वेरी के लिए ही होती हैं. सभी क्वेरी के लिए सामान्य जानकारी का इस्तेमाल कर सकते हैं. इस तरीके से, Google News के जो काम की क्वेरी नहीं हैं. ध्यान दें कि यह सुविधा के कॉलम को नियमित तौर पर इस्तेमाल करने के बारे में ज़्यादा बेहतर सलाह का इस्तेमाल करें.
2. सुविधाओं को सिर्फ़ पॉज़िटिव महत्व देने की अनुमति दें. इस तरह, कोई भी अच्छी सुविधा "अज्ञात" सुविधा से बेहतर है.
3. इसमें सिर्फ़ दस्तावेज़ वाली सुविधाएं नहीं होती हैं. यह #1 का एक्सट्रीम वर्शन है. इसके लिए उदाहरण के लिए, भले ही कोई ऐप्लिकेशन लोकप्रिय डाउनलोड हो, चाहे वह ऐप्लिकेशन क्वेरी है, तो आप इसे हर जगह नहीं दिखाना चाहते. सिर्फ़ दस्तावेज़ के लिए नहीं है सुविधाएं इसे आसान बनाए रखती हैं. कोई खास वजह न दिखाने की वजह हर जगह लोकप्रिय ऐप्लिकेशन, इसकी मदद से, अपनी पसंद के ऐप्लिकेशन को ऐक्सेस किया जा सकता है. उदाहरण के लिए, अगर कोई व्यक्ति "बर्ड वॉचिंग ऐप" के रूप में ब्राउज़ कर सकते हैं, तो वे "एंग्री बर्ड्स" डाउनलोड कर सकते हैं, लेकिन उनका इरादा नहीं था. ऐसा ऐप्लिकेशन दिखाने से डाउनलोड दर में सुधार हो सकता है, लेकिन उपयोगकर्ता की ज़रूरतों को पूरा नहीं करता.

नियम #36: पोज़िशनल सुविधाओं वाले सुझाव लूप से बचें.

कॉन्टेंट की पोज़िशन से इस बात पर काफ़ी असर पड़ता है कि उपयोगकर्ता आपसे कितनी आसानी से इंटरैक्ट कर सकते हैं उसके साथ. अगर किसी ऐप्लिकेशन को पहली पोज़िशन पर रखा जाता है, तो उस पर ज़्यादा बार क्लिक किया जाएगा, और आपको यकीन होगा कि इस पर क्लिक किए जाने की संभावना ज़्यादा है. समस्याओं से निपटने का एक तरीका है इसका मतलब है कि पोज़िशन के लिए सुविधाएँ जोड़ी गई हैं. जैसे, बहुत कम दिखता है. पोज़िशनल सुविधाओं की मदद से, अपने मॉडल को ट्रेनिंग दें और वज़न मापना सीखता है, उदाहरण के लिए, सुविधा "1stposition" बहुत ज़्यादा. आपका मॉडल इसलिए, यह "1stposition=true" वाले उदाहरणों के लिए, अन्य फ़ैक्टर को कम अहमियत देता है. फिर, सेवा के समय आप किसी भी स्थिति में पोज़िशनल फ़ीचर नहीं देते या डिफ़ॉल्ट सुविधा एक जैसी है, क्योंकि आप अपने मैच से पहले उम्मीदवार के स्कोर कर रहे हैं ने उन्हें दिखाने का क्रम तय कर लिया है.

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

नियम #37: ट्रेनिंग/सेवा के स्क्यू को मापें.

ऐसी कई चीज़ें हैं जिनकी वजह से आम तौर पर चीज़ों पर असर पड़ सकता है. इसके अलावा, इसे कई हिस्सों में बांटा जा सकता है:

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

ML फ़ेज़ III: धीमी गति से विकास, ऑप्टिमाइज़ेशन को बेहतर बनाना, और जटिल मॉडल

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

नियम #38: अगर समस्या अब भी अलाइन नहीं हुई है, तो नई सुविधाओं पर समय बर्बाद न करें.

जैसे-जैसे मेज़रमेंट कम होगा, आपकी टीम उन समस्याओं की जांच शुरू कर देगी जो आपके मौजूदा मशीन लर्निंग सिस्टम के मकसद के दायरे से बाहर हो. जैसे यह नीति पहले से तय है, अगर प्रॉडक्ट के लक्ष्य मौजूदा एल्गोरिदम से पूरे नहीं होते हैं मकसद के लिए, आपको अपने मकसद या प्रॉडक्ट के लक्ष्यों में बदलाव करना होगा. इसके लिए उदाहरण के लिए, आप क्लिक, प्लस-वन या डाउनलोड को ऑप्टिमाइज़ कर सकते हैं, लेकिन फ़ैसला लेने में लोगों की मदद करते हैं.

नियम #39: लॉन्च के फ़ैसले लंबे समय के प्रॉडक्ट लक्ष्यों के लिए प्रॉक्सी होते हैं.

ऐलिस के पास इंस्टॉल का अनुमान लगाने से जुड़े लॉजिस्टिक लॉस को कम करने का आइडिया है. वह कोई सुविधा जोड़ता है. लॉजिस्टिक लॉस कम हो जाता है. लाइव एक्सपेरिमेंट करते समय, वे इंस्टॉल दर में बढ़ोतरी दिखती है. हालांकि, जब वे किसी प्रॉडक्ट के लॉन्च की समीक्षा मीटिंग के दौरान, कोई व्यक्ति बताता है कि हर दिन के सक्रिय उपयोगकर्ताओं की संख्या में 5% की गिरावट आई है. टीम ने मॉडल लॉन्च न करने का फ़ैसला किया. ऐलिस निराश है, लेकिन अब हमारा मानना है कि लॉन्च करने का फ़ैसला कई मानदंडों पर निर्भर करता है, जिनमें से सिर्फ़ कुछ एमएल का इस्तेमाल करके, उसे सीधे तौर पर ऑप्टिमाइज़ किया जा सकता है.

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

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

प्रयोग	दैनिक सक्रिय उपयोगकर्ता	आय/दिन
A	10 लाख	40 लाख डॉलर
B	20 लाख	20 लाख डॉलर

अगर मौजूदा सिस्टम A है, तो टीम के B पर स्विच करने की संभावना कम है. अगर आपने मौजूदा सिस्टम B है, तो टीम के A पर स्विच करने की संभावना बहुत कम है. यह तर्क से भरे व्यवहार से मेल न खाता हो; हालांकि, बदलाव को लेकर पूर्वानुमान मेट्रिक का लेवल कम भी हो सकता है और नहीं भी. इसलिए, इसमें बड़ी जोखिम बदलें. हर मेट्रिक में कुछ ऐसे जोखिम की जानकारी होती है जिनसे हमारी टीम जुड़ी हो सकती है.

इतना ही नहीं, कोई भी मेट्रिक टीम की इस चिंता को कवर नहीं करती, "मेरा प्रॉडक्ट कहां है तो अब से पाँच साल बाद क्या होगा"?

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

नियम #40: एन्सेम्बल को आसान रखें.

सामान्य सुविधाएं इस्तेमाल करने और कॉन्टेंट को सीधे तौर पर रैंक करने वाले यूनिफ़ाइड मॉडल डीबग करने और समझने के लिए सबसे आसान मॉडल. हालाँकि, कई मॉडल (एक "मॉडल" जो अन्य मॉडल के स्कोर का कॉम्बिनेशन करती हैं) बेहतर काम कर सकती है. रखने के लिए बात आसान है, तो हर मॉडल या तो एक ऐसा सामूहिक हिस्सा होना चाहिए जिसमें या कोई ऐसा बेस मॉडल जिसमें कई सुविधाएं हों, लेकिन दोनों ही नहीं हों. अगर आपके पास दूसरे मॉडल की तुलना में, जिन्हें अलग से ट्रेनिंग दी जाती है. इसके बाद, उन्हें एक साथ मिलाया जाता है की वजह से ऐप्लिकेशन की परफ़ॉर्मेंस खराब हो सकती है.

असेंबल करने के लिए एक ऐसे आसान मॉडल का इस्तेमाल करें जो सिर्फ़ आपके "आधार" का आउटपुट लेता है मॉडल का इस्तेमाल किया जा सकता है. साथ ही, आपको इन एन्सेंबल मॉडल पर भी प्रॉपर्टी लागू करनी हैं. उदाहरण के लिए, किसी बेस मॉडल से बने स्कोर में बढ़ोतरी को एन्सेबल के स्कोर को कम कर सकता है. साथ ही, यह बेहतर होगा कि अगर आने वाले मॉडल वाक्यात्मक रूप से (उदाहरण के लिए, कैलिब्रेट किए गए) होते हैं, ताकि आप मौजूदा मॉडल, एन्सेंबल मॉडल को भ्रमित नहीं करते हैं. साथ ही, यह पक्का करें कि मौजूदा क्लासिफ़ायर की अनुमानित संभावना में बढ़ोतरी से एन्सेंबल की अनुमानित संभावना को कम कर सकता है.

नियम #41: परफ़ॉर्मेंस में बदलाव होने पर, मौजूदा सिग्नल को बेहतर बनाने के बजाय, जानकारी के नए सोर्स ढूंढने के बजाय, डेटा के नए सोर्स ढूंढें.

आपने उपयोगकर्ता के बारे में डेमोग्राफ़िक (उम्र, लिंग, आय, शिक्षा वगैरह) से जुड़ी कुछ जानकारी जोड़ी है. आपने कुछ कीवर्ड जोड़े हैं दस्तावेज़ में मौजूद शब्दों के बारे में जानकारी. आपने टेंप्लेट का इस्तेमाल कर लिया है और नियमितीकरण को ट्यून किया है. आपने अब तक ऐसा कोई लॉन्च नहीं देखा है कुछ तिमाही में आपकी मुख्य मेट्रिक में 1% की बढ़ोतरी हुई है. अब क्या करें?

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

नियम #42: विविधता, पसंद के हिसाब से कॉन्टेंट या दर्शकों की पसंद से उन चीज़ों के बीच संबंध न जोड़ें जो आपको असल में पसंद हैं.

किसी कॉन्टेंट में विविधता होने के कई मतलब हो सकते हैं. ऐसे में, यहां अलग-अलग तरह के लोगों को सबसे आम सोर्स में से एक है. ऐप्लिकेशन या उसके कॉन्टेंट को उपयोगकर्ता के मनमुताबिक बनाने की प्रोसेस के लिए, उपयोगकर्ता को अपने ही नतीजे मिल सकते हैं. प्रासंगिकता का अर्थ है कि किसी विशेष उस क्वेरी के लिए किसी दूसरी क्वेरी की तुलना में ज़्यादा सही होते हैं. इसलिए, तीनों इन प्रॉपर्टी को सामान्य प्रॉपर्टी से अलग माना जाता है.

समस्या यह है कि साधारण को हराना मुश्किल होता है.

ध्यान दें कि अगर आपका सिस्टम क्लिक, बिताए गए समय, देखे गए विज्ञापनों, और +1 कॉन्टेंट फिर से शेयर करना वगैरह के लिए, कॉन्टेंट की लोकप्रियता मेज़र की जा रही है. टीमें कभी-कभी विविधता के साथ एक व्यक्तिगत मॉडल सीखने की कोशिश करें. लोगों को उनकी दिलचस्पी के हिसाब से विज्ञापन दिखाने के लिए, की सुविधा देता है, जिसकी मदद से सिस्टम आपके हिसाब से कॉन्टेंट ( उपयोगकर्ता की रुचि से मेल खाते हैं या अलग-अलग तरह के हो सकते हैं. इन सुविधाओं से पता चलता है कि क्या इस दस्तावेज़ में वापस लौटाए गए अन्य दस्तावेज़ों, जैसे कि लेखक या कॉन्टेंट के साथ समान सुविधाएं), और देखें कि उन सुविधाओं का वज़न कम होता है (या कभी-कभी अलग चिह्न होता है) उम्मीद से ज़्यादा है.

इसका मतलब यह नहीं है कि विविधता, पसंद के हिसाब से विज्ञापन या कॉन्टेंट कितने काम का है, इसकी अहमियत नहीं है. जैसा कि पिछले नियम में बताया गया है, पोस्ट प्रोसेसिंग को बढ़ाने के लिए विविधता या ज़रूरत के मुताबिक है. अगर आपको कारोबार के लिए लंबे समय के लिए तय किए गए लक्ष्यों में बढ़ोतरी दिखती है, तो यह एलान करना होगा कि लोकप्रियता के अलावा, विविधता/काम की जानकारी भी अहम है. आप या तो अपनी पोस्टप्रोसेसिंग का इस्तेमाल जारी रखें या इसका लक्ष्य विविधता या प्रासंगिकता पर आधारित है.

नियम #43: आपके दोस्त अलग-अलग प्रॉडक्ट में एक जैसे दिखते हैं. ऐसा हो सकता है कि आपकी दिलचस्पी में कुछ भी न हो.

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

इसी विषय से जुड़ा काम

मशीन लर्निंग पर Google और बाहरी हिस्से में कई दस्तावेज़ मौजूद हैं.

• मशीन लर्निंग क्रैश कोर्स: अप्लाइड मशीन लर्निंग के बारे में जानकारी.
• मशीन लर्निंग: एक संभावित तरीका मशीन लर्निंग के क्षेत्र को समझने के लिए, केविन मर्फ़ी ने किया.
• डेटा का बेहतर विश्लेषण: डेटा सेट के बारे में सोचने के लिए डेटा साइंस का इस्तेमाल करना.
• इयान की डीप लर्निंग नॉनलीनियर मॉडल सीखने के लिए, गुडफ़ेलो और अन्य क्रिएटर्स.
• Google के पेपर तकनीकी क़र्ज़, जिसमें बहुत सामान्य सलाह है.
• Tensorflow दस्तावेज़.

स्वीकार की गई

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

अन्य जानकारी

इस दस्तावेज़ में Google प्रॉडक्ट के अलग-अलग रेफ़रंस दिए गए हैं. यहां की यात्रा पर हूं साथ ही, मैं सबसे ज़्यादा इस्तेमाल किए जाने वाले उदाहरणों के बारे में कम शब्दों में जानकारी देती हूँ देखें.

YouTube की खास जानकारी

YouTube, वीडियो स्ट्रीम करने की सेवा है. YouTube का 'अगला वीडियो' सेक्शन और YouTube होम पेज, दोनों पेज टीमें, वीडियो के सुझावों को रैंक करने के लिए एमएल मॉडल इस्तेमाल करती हैं. 'अगला वीडियो देखें' सेक्शन के सुझाव फ़िलहाल चल रहे किसी वीडियो के बाद, अगर आपको कोई वीडियो देखना है, तो होम पेज पर आपको वीडियो के सुझाव दिए जाएंगे वीडियो को प्राथमिकता देता है.

Google Play की खास जानकारी

Google Play में कई तरह के मॉडल हैं, जो अलग-अलग समस्याओं को हल करते हैं. Play Search, Play होम पेज पर, अपने हिसाब से सुझाव पाने की सुविधा और 'उपयोगकर्ताओं ने यह भी इंस्टॉल किया है' ऐप्लिकेशन, इन सभी का इस्तेमाल करते हैं मशीन लर्निंग.

Google Plus की खास जानकारी

Google Plus ने कई तरह की स्थितियों में मशीन लर्निंग का इस्तेमाल किया है: "स्ट्रीम" ऐसी पोस्ट जिन्हें उपयोगकर्ता ने देखा है, "सबसे लोकप्रिय क्या है" की रैंकिंग पोस्ट (पोस्ट जो अब बहुत लोकप्रिय हैं), तो जिन लोगों को आप जानते हैं उनकी रैंकिंग वगैरह. Google प्लस साल 2019 में सभी निजी खाते बंद कर दिए गए. इसकी जगह Google Currents ने ले ली के कारोबारी खातों के लिए उपलब्ध है.