सॉफ्टवेयर डेवलपर्स ने इन-इंजन ML के साथ लेटेंसी कम की, सर्च प्रासंगिकता बढ़ाई

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

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

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

सॉफ्टवेयर डेवलपर के दैनिक कार्य पर इसका प्रभाव स्पष्ट था: प्रबंधित करने के लिए अधिक इंफ्रास्ट्रक्चर, विफलता के अधिक संभावित बिंदु, और प्रासंगिकता की मुख्य समस्या पर ध्यान केंद्रित करने के लिए कम समय।

Swiggy की सफलता इस दुविधा को पूरी तरह से टाल देती है। एक लर्नड रैंकिंग मॉडल को सीधे OpenSearch के अंदर एकीकृत करके, उन्होंने पारंपरिक दो-चरणीय ‘रिट्रीव फिर रैंक’ प्रक्रिया को एक अत्यधिक अनुकूलित, इन-इंजन ऑपरेशन में ढहा दिया है। इसका मतलब है कि उन्नत रैंकिंग के लिए उपयोग किए जाने वाले वही शक्तिशाली मॉडल अब OpenSearch के भीतर प्रारंभिक उम्मीदवार पीढ़ी के साथ चल सकते हैं।

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

एक सॉफ्टवेयर डेवलपर के लिए ऑटो-कंप्लीट प्रासंगिकता में सुधार के कार्य को पूरा करने वाले विशिष्ट वर्कफ़्लो पर विचार करें: OpenSearch में ML को सीधे एकीकृत करने से पहले: एक डेवलपर प्रारंभिक शाब्दिक पुनर्प्राप्ति के लिए OpenSearch को कॉन्फ़िगर करेगा, तेज उम्मीदवार पीढ़ी सुनिश्चित करेगा। यदि वे मशीन लर्निंग लागू करना चाहते थे, तो वे एक अलग सेवा बनाएंगे, शायद एक XGBoost मॉडल होस्ट करने वाला एक पायथन एप्लिकेशन। यह सेवा प्रारंभिक उम्मीदवारों को प्राप्त करेगी, रीयल-टाइम संकेतों के लिए एक फीचर स्टोर को क्वेरी करेगी, ML मॉडल लागू करेगी, और उन्हें वापस भेजने से पहले परिणामों को फिर से रैंक करेगी। इस राउंड ट्रिप में, नेटवर्क लेटेंसी और अनुमान समय सहित, प्रति कीस्ट्रोक आसानी से 20-50 मिलीसेकंड जुड़ सकते हैं—उपयोगकर्ता को सुस्त महसूस कराने के लिए पर्याप्त। खर्च किया गया समय दो अलग-अलग प्रणालियों और उनके बीच नेटवर्क अनुबंध को प्रबंधित करने पर होगा। LTR के साथ OpenSearch में ML को सीधे एकीकृत करने के बाद: डेवलपर अभी भी सह-…