कृत्रिम बुद्धिमत्ता और मशीन लर्निंग समाधानों को लागू करने की यात्रा में कई सामान्य चुनौतियों को हल करने की आवश्यकता होती है जो नियमित रूप से डिजिटल सिस्टम में सामने आती हैं: विरासत प्रणालियों को अपडेट करना, बैच प्रक्रियाओं को समाप्त करना, और ग्राहक अनुभव को बेहतर बनाने के लिए एआई/एमएल पर आधारित नवीन प्रौद्योगिकियों का उपयोग करना। ऐसे तरीके जो कुछ साल पहले विज्ञान कथा जैसे लगते थे।
इस विकास को स्पष्ट करने के लिए, आइए एक काल्पनिक ठेकेदार का अनुसरण करें जिसे एक बड़े-बॉक्स रिटेलर पर एआई/एमएल समाधान लागू करने में मदद करने के लिए काम पर रखा गया था। यह लेखों की श्रृंखला में पहला है जो एआई/एमएल की यात्रा के महत्वपूर्ण पहलुओं का विवरण देगा।
यह बिगबॉक्सको में "इन्फ्रास्ट्रक्चर" टीम का पहला दिन है। अनिवार्य मानव संसाधन गतिविधियों के माध्यम से काम करने के बाद, मुझे अपना ठेकेदार बैज प्राप्त हुआ और मैं अपने नए कार्यक्षेत्र में चला गया।
टीम से मिलने के बाद, मुझे बताया गया कि आज सुबह हमारी "सिफारिशें" टीम के साथ बैठक है।
मेरा सिस्टम एक्सेस अभी तक पूरी तरह से काम नहीं कर रहा है, इसलिए उम्मीद है कि जब हम मीटिंग में होंगे तो आईटी इसे ठीक कर लेगा।
बैठक कक्ष में, हममें से कुछ ही लोग हैं: मेरे प्रबंधक और मेरी नई टीम के दो अन्य इंजीनियर, और सिफ़ारिश टीम से एक इंजीनियर। हम कुछ परिचयों के साथ शुरुआत करते हैं और फिर पिछले सप्ताह के किसी मुद्दे पर चर्चा करने के लिए आगे बढ़ते हैं।
जाहिर है, पिछले सप्ताह रात भर का बैच किसी प्रकार से विफल हो गया था, और वे अभी भी इसका प्रभाव महसूस कर रहे हैं।
ऐसा लगता है जैसे मौजूदा उत्पाद अनुशंसाएँ ग्राहक ऑर्डर से एकत्र किए गए डेटा द्वारा संचालित होती हैं। प्रत्येक ऑर्डर के साथ, ऑर्डर किए गए उत्पादों के बीच एक नया जुड़ाव होता है, जिसे रिकॉर्ड किया जाता है।
जब ग्राहक उत्पाद पृष्ठ देखते हैं, तो वे विभिन्न उत्पादों के साथ-साथ कितने अन्य ग्राहकों ने वर्तमान उत्पाद खरीदा है, इसके आधार पर सिफारिशें प्राप्त कर सकते हैं।
उत्पाद अनुशंसाएँ bigboxco.com पर क्लाउड में एक माइक्रोसर्विस लेयर के माध्यम से उपयोगकर्ताओं को प्रदान की जाती हैं। परिणामों को प्रस्तुत करने के लिए माइक्रोसर्विस परत अपाचे कैसेंड्रा के स्थानीय (क्लाउड) डेटा सेंटर परिनियोजन का उपयोग करती है।
हालाँकि, परिणाम कैसे एकत्र और प्रस्तुत किए जाते हैं, यह पूरी तरह से एक अलग कहानी है। अनिवार्य रूप से, उत्पादों (एक साथ खरीदे गए) के बीच संबंधों के परिणाम MapReduce कार्य के दौरान संकलित किए जाते हैं। यह वह बैच प्रक्रिया है जो पिछले सप्ताह विफल हो गई थी।
हालाँकि यह बैच प्रक्रिया कभी तेज़ नहीं रही, समय के साथ यह धीमी और अधिक भंगुर हो गई है। दरअसल, कभी-कभी इस प्रक्रिया को चलने में दो या तीन दिन भी लग जाते हैं।
बैठक के बाद, मैं अपने कंप्यूटर की जांच करता हूं, और ऐसा लगता है कि मैं अंततः लॉग इन कर सकता हूं। जैसे ही मैं चारों ओर देख रहा हूं, हमारे प्रमुख इंजीनियर (पीई) आते हैं और अपना परिचय देते हैं।
मैं उन्हें सिफ़ारिश टीम के साथ बैठक के बारे में बताता हूं, और वह मुझे सिफ़ारिश सेवा के पीछे के इतिहास के बारे में थोड़ा और बताते हैं।
ऐसा लगता है कि बैच प्रक्रिया लगभग 10 वर्षों से चल रही है। जिस इंजीनियर ने इसे डिज़ाइन किया था वह आगे बढ़ चुका है, संगठन में बहुत से लोग इसे वास्तव में नहीं समझते हैं, और कोई भी इसे छूना नहीं चाहता है।
दूसरी समस्या, मैं समझाना शुरू करता हूं, वह यह है कि प्रत्येक अनुशंसा को संचालित करने वाला डेटासेट लगभग हमेशा कुछ दिन पुराना होता है।
हालाँकि चीजों की भव्य योजना में यह कोई बड़ी बात नहीं हो सकती है, अगर अनुशंसा डेटा को अधिक अद्यतन बनाया जा सकता है, तो इससे विपणन द्वारा चलाए जाने वाले अल्पकालिक प्रचारों को लाभ होगा।
वह सहमति में सिर हिलाते हैं और कहते हैं कि सिस्टम को बेहतर बनाने के बारे में वह निश्चित रूप से सुझावों के लिए तैयार हैं।
शुरुआत में, यह मुझे एक ग्राफ़ समस्या की तरह लगता है। हमारे पास ऐसे ग्राहक हैं जो साइट पर लॉग इन करते हैं और उत्पाद खरीदते हैं। इससे पहले, जब वे किसी उत्पाद को देखते हैं या उसे कार्ट में जोड़ते हैं, तो हम "एक्स खरीदने वाले ग्राहकों ने वाई भी खरीदा" के रूप में सिफारिशें दिखा सकते हैं।
साइट में आज यह है, जिसमें अनुशंसा सेवा बिल्कुल यही करती है: यह शीर्ष चार अतिरिक्त उत्पाद लौटाती है जो अक्सर एक साथ खरीदे जाते हैं।
लेकिन हमें उत्पादों को "रैंक" करने का कोई तरीका रखना होगा क्योंकि हमारे 200 मिलियन ग्राहकों में से किसी एक द्वारा एक ही समय में खरीदे गए प्रत्येक उत्पाद की मैपिंग तेजी से होने वाली है।
इसलिए हम उन्हें एक क्रम में दिखाई देने वाली संख्या के आधार पर रैंक कर सकते हैं। इस प्रणाली का ग्राफ कुछ-कुछ वैसा दिख सकता है जैसा नीचे चित्र 1 में दिखाया गया है।
इसे मॉडलिंग करने और डेटा की वास्तविक मात्रा के साथ हमारे ग्राफ़ डेटाबेस पर चलाने के बाद, मुझे तुरंत एहसास हुआ कि यह काम नहीं करेगा।
एक उत्पाद से आस-पास के ग्राहकों तक उनके उत्पादों तक पहुंचने और सबसे अधिक दिखाई देने वाले उत्पादों की गणना करने में लगभग 10 सेकंड का समय लगता है।
अनिवार्य रूप से, हमने दो-दिवसीय बैच की समस्या पर "पंट" लगाया है, प्रत्येक लुकअप में ट्रैवर्सल विलंबता को ठीक वहीं रखा जाता है जहां हम इसे नहीं चाहते हैं: ग्राहक के सामने।
लेकिन शायद, वह ग्राफ़ मॉडल उससे बहुत दूर नहीं है जो हमें यहाँ करने की आवश्यकता है? वास्तव में, ऊपर वर्णित दृष्टिकोण एक मशीन लर्निंग (एमएल) तकनीक है जिसे "सहयोगी फ़िल्टरिंग" के रूप में जाना जाता है।
अनिवार्य रूप से, सहयोगात्मक फ़िल्टरिंग एक दृष्टिकोण है जो अन्य उपयोगकर्ताओं के साथ गतिविधि के आधार पर कुछ डेटा ऑब्जेक्ट की समानता की जांच करता है, और यह हमें उस डेटा के आधार पर भविष्यवाणियां करने में सक्षम बनाता है।
हमारे मामले में, हम अपने ग्राहक आधार से कार्ट/ऑर्डर डेटा को अप्रत्यक्ष रूप से एकत्र करेंगे, और हम इसका उपयोग ऑनलाइन बिक्री बढ़ाने के लिए बेहतर उत्पाद सिफारिशें करने के लिए करेंगे।
सबसे पहले, आइए डेटा संग्रह को देखें। शॉपिंग "प्लेस ऑर्डर" फ़ंक्शन में एक अतिरिक्त सेवा कॉल जोड़ना कोई बड़ी बात नहीं है। वास्तव में, यह पहले से ही मौजूद है; यह सिर्फ इतना है कि डेटा डेटाबेस में संग्रहीत हो जाता है और बाद में संसाधित होता है। कोई गलती न करें: हम अभी भी बैच प्रोसेसिंग को शामिल करना चाहते हैं।
लेकिन हम उस कार्ट डेटा को वास्तविक समय में संसाधित करना भी चाहेंगे, ताकि हम इसे तुरंत ऑनलाइन डेटा सेट में फ़ीड कर सकें और तुरंत बाद इसका उपयोग कर सकें।
हम जैसे इवेंट स्ट्रीमिंग समाधान डालकर शुरुआत करेंगे
जहां तक बाद की बात है, हमारा पल्सर उपभोक्ता कैसेंड्रा टेबल (चित्र 2 में दिखाया गया है) पर लिखेगा, जिसे केवल ऑर्डर में प्रत्येक उत्पाद के लिए प्रविष्टियां रखने के लिए डिज़ाइन किया गया है। फिर उत्पाद में उस और अन्य ऑर्डर के सभी अन्य उत्पादों के लिए एक पंक्ति होती है:
CREATE TABLE order_products_mapping ( id text, added_product_id text, cart_id uuid, qty int, PRIMARY KEY (id, added_product_id, cart_id) ) WITH CLUSTERING ORDER BY (added_product_id ASC, cart_id ASC);
फिर हम इस तालिका को किसी विशेष उत्पाद (इस उदाहरण में "DSH915") के लिए इस तरह क्वेरी कर सकते हैं:
SELECT added_product_id, SUM(qty) FROm order_products_mapping WHERE id='DSH915' GROUP BY added_product_id; added_product_id | system.sum(qty) ------------------+----------------- APC30 | 7 ECJ112 | 1 LN355 | 2 LS534 | 4 RCE857 | 3 RSH2112 | 5 TSD925 | 1 (7 rows)
फिर हम शीर्ष चार परिणाम ले सकते हैं और उन्हें उत्पाद अनुशंसा तालिका में डाल सकते हैं, जो ` product_id
द्वारा अनुशंसा सेवा के लिए क्वेरी के लिए तैयार है:
SELECT * FROM product_recommendations WHERE product_id='DSH915'; product_id | tier | recommended_id | score ------------+------+----------------+------- DSH915 | 1 | APC30 | 7 DSH915 | 2 | RSH2112 | 5 DSH915 | 3 | LS534 | 4 DSH915 | 4 | RCE857 | 3 (4 rows)
इस प्रकार, नई अनुशंसा डेटा को लगातार अद्यतन रखा जा रहा है। साथ ही, ऊपर वर्णित सभी बुनियादी ढांचागत संपत्तियां स्थानीय डेटा सेंटर में स्थित हैं।
इसलिए, किसी ऑर्डर से उत्पाद संबंधों को खींचने, उन्हें पल्सर विषय के माध्यम से भेजने और उन्हें कैसेंड्रा में संग्रहीत अनुशंसाओं में संसाधित करने की प्रक्रिया एक सेकंड से भी कम समय में होती है।
इस सरल डेटा मॉडल के साथ, कैसेंड्रा एकल-अंक मिलीसेकंड में अनुरोधित अनुशंसाओं को पूरा करने में सक्षम है।
हम यह सुनिश्चित करना चाहेंगे कि दीर्घावधि में हमारा डेटा हमारी कैसेंड्रा तालिकाओं में कैसे लिखा जा रहा है। इस तरह, हम अनबाउंड रो ग्रोथ और इन-प्लेस अपडेट जैसी चीजों से संबंधित संभावित समस्याओं से आगे निकल सकते हैं।
कुछ अतिरिक्त अनुमानी फ़िल्टर भी जोड़ना आवश्यक हो सकता है, जैसे "अनुशंसित न करें" सूची।
ऐसा इसलिए है क्योंकि कुछ ऐसे उत्पाद हैं जिन्हें हमारे ग्राहक या तो एक बार या कभी-कभार ही खरीदेंगे, और उनकी अनुशंसा करने से अन्य उत्पादों की तुलना में उनकी जगह कम हो जाएगी जिन्हें वे आवेग में खरीदने की अधिक संभावना रखते हैं।
उदाहरण के लिए, हमारे उपकरण प्रभाग से वॉशिंग मशीन जैसी किसी चीज़ की खरीदारी की अनुशंसा करने से "आवेग में खरीदारी" प्राप्त होने की संभावना नहीं है।
भविष्य में एक और सुधार उत्पाद संबंध स्ट्रीमिंग दोनों को संभालने और सीधे सेवा में अनुशंसा डेटा प्रदान करने के लिए कास्काडा जैसे वास्तविक समय एआई/एमएल प्लेटफॉर्म को लागू करना होगा।
सौभाग्य से, हम वास्तविक समय में संसाधित होने वाली कार्ट-ऐड घटनाओं को फीड करने के लिए पल्सर का उपयोग करके मौजूदा, सुस्त बैच प्रक्रिया को बढ़ाने का एक तरीका लेकर आए। एक बार जब हमें यह एहसास हो जाए कि यह प्रणाली लंबे समय में कैसा प्रदर्शन करती है, तो हमें विरासत बैच प्रक्रिया को बंद करने पर विचार करना चाहिए।
पीई ने स्वीकार किया कि हमने नए समाधान के साथ अच्छी प्रगति की है, और, इससे भी बेहतर, हमने कुछ तकनीकी ऋण को खत्म करने के लिए जमीनी कार्य करना भी शुरू कर दिया है। अंत में, हर किसी को इसके बारे में अच्छा लगता है।
आगामी लेख में, हम वेक्टर खोज के साथ उत्पाद प्रचार को बेहतर बनाने पर एक नज़र डालेंगे।
जानें कि डेटास्टैक्स वास्तविक समय एआई को कैसे सक्षम करता है
आरोन प्लोएट्ज़, डेटास्टैक्स द्वारा
यहाँ भी प्रकाशित किया गया