हम अनुशंसाओं के चयन की गुणवत्ता और गति पर कैसे काम करते हैं

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

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

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

मैं आपको बताऊंगा कि हमने इन समस्याओं को कैसे हल किया।

उम्मीदवारों का चयन

हम कुछ मिलीसेकंड में हजारों बार विचार किए जाने वाले दस्तावेजों की संख्या को कैसे कम कर सकते हैं, जबकि रैंकिंग गुणवत्ता पर इसका कोई प्रभाव नहीं पड़ेगा?

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

उम्मीदवारों के चयन का हमारा सिद्धांत विकसित हो चुका है, और फिलहाल हम एक बहु-चरणीय योजना पर पहुंच गए हैं:

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

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

रनटाइम में ALS चरण

क्लिक के तुरंत बाद उपयोगकर्ता की प्रतिक्रिया को कैसे ध्यान में रखा जाए?

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

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

उपयोगकर्ता-दस्तावेज़ मैट्रिक्स के गठन और विघटन का सामान्य सिद्धांतमान लीजिए कि हमारे पास m उपयोगकर्ता और n दस्तावेज़ हैं। कुछ उपयोगकर्ताओं के लिए, कुछ दस्तावेज़ों के प्रति उनका रवैया ज्ञात है। फिर इस जानकारी को मैट्रिक्स mxn के रूप में दर्शाया जा सकता है: पंक्तियाँ उपयोगकर्ताओं के अनुरूप हैं, और कॉलम दस्तावेज़ों के अनुरूप हैं। चूँकि व्यक्ति ने अधिकांश दस्तावेज़ नहीं देखे हैं, इसलिए अधिकांश मैट्रिक्स सेल खाली रहेंगे, और अन्य भरे जाएँगे। मैट्रिक्स में प्रत्येक घटना (पसंद, नापसंद, क्लिक) के लिए, कुछ मान प्रदान किया जाता है - लेकिन आइए एक सरलीकृत मॉडल पर विचार करें जिसमें पसंद 1 के अनुरूप है, और नापसंद -1।

आइए मैट्रिक्स को दो भागों में विभाजित करें: P (mxd) और Q (dxn), जहाँ d वेक्टर प्रतिनिधित्व की आयामीता है (आमतौर पर एक छोटी संख्या)। फिर प्रत्येक ऑब्जेक्ट एक d-आयामी वेक्टर के अनुरूप होगा (उपयोगकर्ता मैट्रिक्स P में एक पंक्ति है, दस्तावेज़ मैट्रिक्स Q में एक कॉलम है)। ये वेक्टर संबंधित ऑब्जेक्ट के एम्बेडिंग होंगे। यह अनुमान लगाने के लिए कि उपयोगकर्ता को दस्तावेज़ पसंद आएगा या नहीं, आप बस उनके एम्बेडिंग को गुणा कर सकते हैं।

मैट्रिक्स को विघटित करने के संभावित तरीकों में से एक ALS (अल्टरनेटिंग लीस्ट स्क्वेयर) है। हम निम्नलिखित हानि फ़ंक्शन को अनुकूलित करेंगे:

यहाँ rui उपयोगकर्ता u का दस्तावेज़ i के साथ इंटरैक्शन है, qi दस्तावेज़ i का वेक्टर है, pu उपयोगकर्ता u का वेक्टर है।

फिर माध्य वर्ग त्रुटि (निश्चित दस्तावेज़ वैक्टर के साथ) के संदर्भ में इष्टतम उपयोगकर्ता वेक्टर को संबंधित रैखिक प्रतिगमन को हल करके विश्लेषणात्मक रूप से पाया जाता है।

इसे "ALS चरण" कहा जाता है। और ALS एल्गोरिथ्म में हम बारी-बारी से एक मैट्रिक्स (उपयोगकर्ता और लेख) को ठीक करते हैं और दूसरे को अपडेट करते हैं, जिससे इष्टतम समाधान मिल जाता है।

सौभाग्य से, उपयोगकर्ता एम्बेडिंग को ढूँढना एक काफी तेज़ ऑपरेशन है जिसे वेक्टर निर्देशों का उपयोग करके रनटाइम पर किया जा सकता है। यह तरकीब हमें रैंकिंग में उपयोगकर्ता की प्रतिक्रिया को तुरंत ध्यान में रखने की अनुमति देती है। उम्मीदवार चयन को बेहतर बनाने के लिए उसी एम्बेडिंग का उपयोग kNN इंडेक्स में किया जा सकता है।

वितरित सहयोगी फ़िल्टरिंग

वृद्धिशील वितरित मैट्रिक्स फैक्टराइजेशन कैसे करें और नए लेखों का वेक्टर प्रतिनिधित्व शीघ्रता से कैसे खोजें?

अनुशंसाओं के लिए संकेतों का एकमात्र स्रोत सामग्री नहीं है। एक अन्य महत्वपूर्ण स्रोत सहयोगी जानकारी है। अच्छी रैंकिंग सुविधाएँ पारंपरिक रूप से उपयोगकर्ता-दस्तावेज़ मैट्रिक्स को विघटित करके प्राप्त की जा सकती हैं। लेकिन जब हमने ऐसा विघटन करने की कोशिश की, तो हमें समस्याएँ आईं:

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

उपरोक्त समस्याओं को हल करने के लिए, हमने लगातार वृद्धिशील अपडेट के साथ उपयोगकर्ता-दस्तावेज़ मैट्रिक्स का वितरित विघटन लागू किया। यह वास्तव में कैसे काम करता है?

मान लीजिए हमारे पास N मशीनों का एक समूह है (N सैकड़ों में है) और हम उन पर एक मैट्रिक्स का वितरित अपघटन करना चाहते हैं जो किसी एक मशीन पर फिट नहीं होता है। सवाल यह है: यह अपघटन कैसे किया जाए ताकि एक तरफ, प्रत्येक मशीन में पर्याप्त डेटा हो और दूसरी तरफ, गणना स्वतंत्र हो?

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

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

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

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

किसी अन्य डोमेन क्षेत्र में स्थानांतरण

वीडियो का वेक्टर प्रतिनिधित्व बनाने के लिए पाठ्य लेखों पर उपयोगकर्ता प्रतिक्रिया का उपयोग कैसे करें?

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

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

निष्कर्ष

वास्तविक समय अनुशंसा प्रणाली कोर विकसित करने में कई चुनौतियाँ शामिल हैं। डेटा को जल्दी से संसाधित करना और इस डेटा का प्रभावी ढंग से उपयोग करने के लिए एमएल विधियों को लागू करना आवश्यक है; कम से कम समय में उपयोगकर्ता संकेतों और नई सामग्री इकाइयों को संसाधित करने में सक्षम जटिल वितरित सिस्टम का निर्माण करना; और कई अन्य कार्य।

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

स्रोत: www.habr.com