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

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

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

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

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

शब्दावली

ये शब्द हमारी मशीन लर्निंग के असर के बारे में हमारी चर्चा में बार-बार सामने आएंगे:

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

खास जानकारी

शानदार प्रॉडक्ट बनाने के लिए:

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

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

1. पक्का करें कि आपकी पाइपलाइन एक जैसी हो.
2. सही मकसद से शुरू करें.
3. सामान्य तरीके से समझ में आने वाली सुविधाओं को आसान तरीके से जोड़ें.
4. पक्का करें कि आपकी पाइपलाइन में कोई गड़बड़ी न हो.

यह तरीका लंबे समय तक कारगर रहेगा. इस तरीके का इस्तेमाल सिर्फ़ तब करें, जब आपको और आगे ले जाने के लिए कोई आसान से तरकीब न हो. जटिलता को जोड़ने से भावी रिलीज़ धीमी हो जाती हैं.

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

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

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

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

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

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

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

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

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

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

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

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

नियम #3: एक जटिल अनुमान पर मशीन लर्निंग चुनें.

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

ML चरण I: आपकी पहली पाइपलाइन

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

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

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

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

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

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

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

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

पक्का करें कि इन्फ़्रास्ट्रक्चर की जांच की जा सकती हो. साथ ही, सिस्टम के लर्निंग पार्ट इस तरह से जोड़े गए हों, ताकि आप अपने आस-पास की सभी चीज़ों की जांच कर सकें. खास तौर पर:

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

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

नियम #6: पाइपलाइन को कॉपी करते समय, मिटाए गए डेटा के बारे में सावधानी बरतें.

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

नियम #7: अनुमान को सुविधाओं में बदलें या उन्हें बाहर से मैनेज करें.

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

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

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

निगरानी

आम तौर पर, चेतावनी देने में सावधानी बरतें. जैसे, चेतावनियों पर कार्रवाई करना और डैशबोर्ड पेज बनाना.

नियम #8: अपने सिस्टम की सबसे नई शर्तों के बारे में जानें.

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

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

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

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

नियम #10: लगातार हो रही गड़बड़ियों की जांच करें.

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

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

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

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

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

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

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

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

नियम #13: अपने पहले लक्ष्य के लिए एक आसान, निगरानी करने लायक और एट्रिब्यूशन मेट्रिक चुनें.

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

उपयोगकर्ता के व्यवहार को मॉडल करना सबसे आसान होता है जो सीधे देखा जाता है और सिस्टम की कार्रवाई के लिए एट्रिब्यूट किया जा सकता है:

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

शुरू में, सीधे तौर पर न दिखने वाले असर को मॉडल करने से बचें:

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

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

आखिर में, यह पता लगाने की कोशिश न करें कि मशीन लर्निंग क्या है:

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

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

नियम #14: व्याख्या करने वाले मॉडल से शुरुआत करने से, डीबग करना आसान हो जाता है.

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

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

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

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

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

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

ML फ़ेज़ II: फ़ीचर इंजीनियरिंग

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

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

नियम #16: लॉन्च करने और दोहराने के बारे में योजना बनाएं.

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

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

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

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

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

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

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

नियम #18: हर तरह के कॉन्टेंट को एक ही जगह पर दिखाने वाले फ़ीचर के बारे में जानें.

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

नियम #19: जब भी संभव हो तो बहुत विशिष्ट सुविधाओं का उपयोग करें.

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

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

सुविधाओं को जोड़ने और उनमें बदलाव करने के कई तरीके हैं. TensorFlow जैसे मशीन लर्निंग सिस्टम की मदद से, अपने डेटा को कन्वर्ज़न के ज़रिए पहले से प्रोसेस किया जा सकता है. दो तरीकों में से एक है “गड़बड़ी” और “क्रॉस.”

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

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

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

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

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

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

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

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

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

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

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

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

सिस्टम का मानवीय विश्लेषण

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #27: उपयोगकर्ताओं के व्यवहार में आए अनचाहे बदलावों को मापने की कोशिश करें.

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

नियम #28: ध्यान रखें कि एक ही तरह के छोटे व्यवहार से यह नहीं पता चलता कि उनका व्यवहार लंबे समय तक एक जैसा रहेगा.

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

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

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

ट्रेनिंग और सर्विंग की परफ़ॉर्मेंस में फ़र्क़ है. यह विषमता इसके कारण हो सकती है:

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

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

नियम #29: सेवा देने के समय इस्तेमाल की जाने वाली सुविधाओं के सेट को सेव करना और फिर उन सुविधाओं को एक लॉग में जोड़ना, ताकि ट्रेनिंग के समय उनका इस्तेमाल किया जा सके.

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

नियम #30: अहमियत के नमूने का डेटा, इसे आर्बिट्रेरी में न छोड़ें!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #37: मेज़रिंग ट्रेनिंग/सर्विंग स्क्यू.

कुछ ऐसी चीज़ें होती हैं जिनकी वजह से सामान्य रूप से फ़र्क़ हो सकता है. इसके अलावा, इसे कई हिस्सों में बांटा जा सकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #40: नतीजों को आसान रखें.

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

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

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

आपने उपयोगकर्ता के बारे में कुछ जनसांख्यिकी जानकारी जोड़ी है. आपने दस्तावेज़ में शामिल शब्दों के बारे में कुछ जानकारी जोड़ी है. आपने टेंप्लेट को एक्सप्लोर कर लिया है और नियमित करने के तरीके को अपने हिसाब से सेट कर लिया है. कुछ ही क्वॉर्टर में, आपने मुख्य मेट्रिक में 1% से ज़्यादा की बढ़ोतरी वाला लॉन्च नहीं देखा होगा. अब क्या करें?

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

नियम #42: क्या आपको लगता है कि विविधता, मनमुताबिक बनाने की सुविधा, और कितने काम का है, सब मिलता-जुलता है.

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

समस्या यह है कि अक्सर लोग पीछे हटना मुश्किल होता है.

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

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

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

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

इसी विषय से जुड़ा कॉन्टेंट

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

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

आभार

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

अपेन्डिक्स

इस दस्तावेज़ में, Google प्रॉडक्ट के बारे में कई तरह की जानकारी दी गई है. ज़्यादा जानकारी देने के लिए, मैं नीचे दिए गए सबसे सामान्य उदाहरणों का ब्यौरा दे रहा हूं.

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

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

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

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

Google प्लस की खास जानकारी

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