मशीन लर्निंग के बिना एक बुनियादी अनुशंसा इंजन कैसे बनाएं

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

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

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

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

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

इंजीनियरिंग परिप्रेक्ष्य से समस्या कथन

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

उच्च स्तर पर, इंजीनियरिंग के दृष्टिकोण से हमारी निम्नलिखित आवश्यकताएँ थीं -

1. सिस्टम को उपयोगकर्ता की रुचियों को कीवर्ड के रूप में पकड़ने में सक्षम होना चाहिए। सिस्टम को विशिष्ट कीवर्ड में उपयोगकर्ता की रुचि के स्तर को वर्गीकृत करने में भी सक्षम होना चाहिए।

   
   

2. सिस्टम को एक उपयोगकर्ता की अन्य उपयोगकर्ताओं में रुचि को पकड़ने में सक्षम होना चाहिए। यह किसी अन्य उपयोगकर्ता द्वारा बनाई गई सामग्री में उपयोगकर्ता की रुचि के स्तर को वर्गीकृत करने में सक्षम होना चाहिए।

   
   

3. सिस्टम को उपयोगकर्ता की रुचियों के आधार पर उच्च-गुणवत्ता वाली अनुशंसाएँ उत्पन्न करने में सक्षम होना चाहिए।

   
   

4. सिस्टम को यह सुनिश्चित करने में सक्षम होना चाहिए कि उपयोगकर्ता द्वारा पहले ही देखी/अस्वीकृत की गई अनुशंसाएँ X संख्या के दिनों तक दोबारा दिखाई न दें।

   
   

5. सिस्टम में यह सुनिश्चित करने के लिए तर्क होना चाहिए कि समान रचनाकारों के पोस्ट एक ही पृष्ठ पर समूहीकृत न हों। सिस्टम को यह सुनिश्चित करने की पूरी कोशिश करनी चाहिए कि यदि कोई उपयोगकर्ता दस पोस्ट (हमारे पृष्ठ आकार) का उपभोग करता है, तो वे सभी अलग-अलग रचनाकारों से होनी चाहिए।

   
   

6. सिस्टम तेज होना चाहिए. P99 विलंबता के 150 मिलीसेकंड से कम।

   
   

7. अन्य सभी गैर-कार्यात्मक आवश्यकताएँ, जैसे उच्च उपलब्धता, स्केलेबिलिटी, सुरक्षा, विश्वसनीयता, रखरखाव, आदि को पूरा किया जाना चाहिए।

   
   

फिर, यह समस्या कथनों की अत्यधिक सरलीकृत सूची है। वास्तव में, दस्तावेज़ 3000+ शब्दों के थे क्योंकि उनमें बहुत सारे किनारे के मामले और कोने के मामले भी शामिल थे जो इस अनुशंसा इंजन को हमारे मौजूदा सिस्टम में एकीकृत करते समय उत्पन्न हो सकते हैं। चलिए समाधान की ओर बढ़ते हैं।

समाधान - सिफ़ारिश इंजन की उच्च स्तरीय कार्यप्रणाली

मैं एक-एक करके समस्या के समाधानों पर चर्चा करूंगा और फिर पूरे सिस्टम की समग्र कार्यप्रणाली का वर्णन करूंगा।

हमारी पहली समस्या उपयोगकर्ता की रुचियों को पकड़ना और एक विशिष्ट रुचि के साथ उनकी रुचि के स्तर को परिभाषित करना है

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

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

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

हमारी दूसरी समस्या उपयोगकर्ता की रुचि के आधार पर उच्च-गुणवत्ता वाली अनुशंसाएँ तैयार करना है

निम्नलिखित आरेख सिस्टम कैसे काम करता है इसका एक सरलीकृत उच्च-स्तरीय प्रतिनिधित्व है।

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

आइए मैं चरण दर चरण समझाता हूँ:

चरण 1 - पोस्ट सामग्री को वेक्टर एम्बेडिंग में परिवर्तित करना

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

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

चरण 2 - उपयोगकर्ता की रुचि के बारे में प्रश्न करें

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

इसलिए, वह तर्क चुनें जो आपके व्यावसायिक उपयोग के मामले और उस व्यवहार के अनुकूल हो जिसे आप चलाना चाहते हैं और उपयोगकर्ता की सभी रुचियों की एक बड़ी सूची प्राप्त करने के लिए कई क्वेरी चलाएँ।

चरण 3 - मिली रुचियों के आधार पर एक एएनएन खोज करें

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

चरण 4 - ऑर्डर के साथ परिणामों को कैश डेटाबेस में संग्रहीत करें।

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

उपयोगकर्ता की विशिष्ट अनुशंसा का क्रम तय करने के लिए, हमने निम्नलिखित बातों पर विचार किया -

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

   
   

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

   
   

कुछ फ़ीड में, हम लोकप्रियता को प्राथमिकता देते हैं; दूसरों में, हम सामाजिक ग्राफ को प्राथमिकता देते हैं। लेकिन अधिकतर, ये सभी दोनों का एक स्वस्थ मिश्रण हैं।

सिस्टम कैसे काम करता है

जैसा कि आप ऊपर दिए गए चित्र से देख सकते हैं, सिस्टम को जानबूझकर बहुत सरल रखा गया है। सिस्टम इस प्रकार काम करता है -

1. जब उपयोगकर्ता ए एक पोस्ट बनाता है, तो पोस्ट सेवा, उस पोस्ट को सहेजने के बाद, एक पब/उप इवेंट को एक कतार में ट्रिगर करती है, जो उम्मीदवार पीढ़ी के लिए पृष्ठभूमि सेवा द्वारा प्राप्त की जाती है। हम उपयोग करते हैं गूगल पब/उप पब/उप कार्यक्षमता के लिए।

   
   

2. यह पृष्ठभूमि सेवा इसे अतुल्यकालिक रूप से प्राप्त करती है और पहले चर्चा की गई कार्यक्षमताओं को निष्पादित करती है - गोपनीयता जांच, मॉडरेशन जांच और कीवर्ड पीढ़ी और फिर वेक्टर एम्बेडिंग उत्पन्न करती है और उन्हें वेक्टर डेटाबेस में संग्रहीत करती है। हम प्रयोग कर रहे हैं AstraDB हमारे वेक्टर डेटाबेस के रूप में (बाद में चर्चा की गई)।

   
   

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

   
   

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

   
   

5. चूंकि उपरोक्त सभी चरण पर्दे के पीछे अतुल्यकालिक रूप से निष्पादित किए जाते हैं, इसलिए इन गणनाओं का अंतिम-उपयोगकर्ता अनुभव पर कोई प्रभाव नहीं पड़ता है।

   
   

6. फ़ीड अंततः अंतिम उपयोगकर्ता को फ़ीड सेवा के माध्यम से प्रदान की जाती है। चूँकि यह सेवा केवल रेडिस और हमारे मुख्य NoSQL डेटाबेस पर एक लुकअप करती है ( डायनमोडीबी ), इसकी P99 विलंबता 110 मिलीसेकंड से कम है। ये दोनों डेटाबेस पैमाने की परवाह किए बिना एकल-अंकीय मिलीसेकंड विलंबता में क्वेरी परिणाम लौटाते हैं।

प्रयुक्त उपकरण एवं प्रौद्योगिकियाँ

1. कुछ सेवाओं के बारे में लिखा गया है प्रोग्रामिंग भाषा जाओ , जबकि अन्य में लिखा गया है नोडजेएस (टाइपस्क्रिप्ट के साथ)।

   
   

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

   
   

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

   
   

4. रेडिस - गति, सरलता और शक्तिशाली डेटा संरचना। मुझे नहीं लगता कि मुझे इस बात पर चर्चा करने की ज़रूरत है कि 2024 में रेडिस क्यों।

   
   

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

भविष्य में समस्याओं का समाधान किया जाना है

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

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

   
   

2. विभिन्न कीवर्ड और उपयोगकर्ताओं के बीच संबंधों को सुव्यवस्थित और अधिक विस्तृत बनाया जाना चाहिए। वे अभी बहुत ऊंचे स्तर पर हैं. लेकिन उन्हें और अधिक गहरा करने की आवश्यकता होगी। हमें पहले अनुशंसाओं को परिष्कृत करने के लिए अपने ग्राफ़ में दूसरे और तीसरे-डिग्री संबंधों का पता लगाने की आवश्यकता होगी।

   
   

3. हम अभी अपने एम्बेडिंग मॉडल में कोई फ़ाइन-ट्यूनिंग नहीं कर रहे हैं। हमें निकट भविष्य में ऐसा करने की आवश्यकता होगी।

अंत नोट

मुझे आशा है कि आपको यह ब्लॉग उपयोगी लगा होगा। यदि आपके कोई प्रश्न, संदेह या सुझाव हैं, तो कृपया बेझिझक मुझसे संपर्क करें ट्विटर , Linkedin या Instagram . इस आर्टिकल को अपने दोस्तों और सहकर्मियों के साथ जरूर शेयर करें।