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

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

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

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

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

शब्दावली

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

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

खास जानकारी

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

क्या आप उस अच्छे इंजीनियर की तरह मशीन लर्निंग का इस्तेमाल करते हैं जिससे आप उस मशीन लर्निंग के विशेषज्ञ नहीं हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निगरानी

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

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

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

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

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

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

नियम #10: साइलेंट मोड पर सेट की गई सूचनाओं पर नज़र रखें.

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

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

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

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

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

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

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

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

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

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

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

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

सीधे तौर पर होने वाले असर को मॉडल करने से पहले, ऐसा करने से बचें:

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

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

आखिर में, मशीन लर्निंग की मदद से इनके बारे में न जानें:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जब आपको ऐसे उदाहरण मिल जाएं जिनमें यह मॉडल गलत हो गया है, तो ऐसे रुझान ढूंढें जो आपके मौजूदा फ़ीचर सेट से बाहर के हैं. उदाहरण के लिए, अगर ऐसा लगता है कि सिस्टम लंबी पोस्ट को कम कर रहा है, तो पोस्ट की लंबाई जोड़ें. अपनी जोड़ी गई सुविधाओं के बारे में बहुत ज़्यादा खास जानकारी न दें. अगर आपको पोस्ट की लंबाई बढ़ानी है, तो लंबी अवधि का अनुमान लगाने की कोशिश न करें. बस दर्जनों सुविधाएं जोड़ें और मॉडल को पता लगाने दें कि उन पर क्या कार्रवाई करनी है (नियम #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%. परफ़ॉर्मेंस का सटीक अनुमान लगाने के लिए, दस हज़ार उदाहरण काफ़ी हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नियम #40: पहनावे को आसान रखें.

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

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

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

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

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

नियम #42: यह उम्मीद न करें कि अलग-अलग तरह की लोकप्रियता, उनके कॉन्टेंट को पसंद के मुताबिक बनाने या उनकी पसंद के हिसाब से कॉन्टेंट उपलब्ध होने के मामले में, आपकी पसंद के मुताबिक लोकप्रियता होगी.

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

समस्या यह है कि सामान्य को पीछे छोड़ देना मुश्किल होता है.

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

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

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

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

मिलता-जुलता काम

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

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

स्वीकार हैं

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

अन्य जानकारी

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

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

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

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

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

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

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