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

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

Martin Zinkevich

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

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

शब्दावली

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

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

खास जानकारी

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

मशीन लर्निंग को एक बेहतर इंजीनियर की तरह अपनाएं, न कि मशीन लर्निंग विशेषज्ञ की तरह.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मशीन लर्निंग का पहला चरण: आपकी पहली पाइपलाइन

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

चौथा नियम: पहला मॉडल आसान बनाएं और इंफ़्रास्ट्रक्चर को सही बनाएं.

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

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

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

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

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

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

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

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

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

छठा नियम: पाइपलाइन कॉपी करते समय, डेटा को ड्रॉप होने से बचाने के लिए सावधानी बरतें.

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

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

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

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

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

निगरानी

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

आठवां नियम: अपने सिस्टम के अपडेट होने की ज़रूरी शर्तों के बारे में जानें.

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

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

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

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

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

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

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

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

आपका पहला लक्ष्य

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

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

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

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

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

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

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

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

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

  • क्या उपयोगकर्ता अगले दिन भी आया?
  • उपयोगकर्ता ने साइट पर कितनी देर बिताई?
  • हर दिन के सक्रिय उपयोगकर्ताओं की संख्या क्या थी?

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

आखिर में, मशीन लर्निंग से ये काम करने के लिए न कहें:

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

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

नियम #14: किसी ऐसे मॉडल से शुरुआत करें जिसे समझा जा सके. इससे डीबग करना आसान हो जाता है.

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

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

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

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

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

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

एमएल का दूसरा चरण: फ़ीचर इंजीनियरिंग

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

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

नियम #16: लॉन्च और बार-बार इस्तेमाल करने के लिए प्लान बनाएं.

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

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

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

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

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

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

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

नियम #18: ऐसे कॉन्टेंट की सुविधाओं को एक्सप्लोर करें जो सभी संदर्भों में काम करते हों.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #27: गलत व्यवहार की संख्या का पता लगाने की कोशिश करें.

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

नियम #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% जैसे छोटे सैंपल का इस्तेमाल किया जा सकता है. परफ़ॉर्मेंस का सटीक अनुमान लगाने के लिए, 10 हज़ार उदाहरण काफ़ी हैं.

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

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

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

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

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

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

नियम #37: ट्रेनिंग और ब्राउज़र में वेब पेज खोलने के दौरान परफ़ॉर्मेंस में अंतर को मेज़र करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #42: यह उम्मीद न करें कि अलग-अलग तरह के कॉन्टेंट, उपयोगकर्ताओं के हिसाब से कॉन्टेंट दिखाने या काम के कॉन्टेंट की वजह से, आपके वीडियो की लोकप्रियता बढ़ेगी.

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

समस्या यह है कि सामान्य चीज़ों को बेहतर बनाना मुश्किल होता है.

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

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

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

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

Google के साथ-साथ बाहर भी, मशीन लर्निंग के बारे में कई दस्तावेज़ उपलब्ध हैं.

आभार

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

अन्य जानकारी

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

YouTube के बारे में खास जानकारी

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

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

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

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

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