हमने उपयोगकर्ता के अनुरोध की भविष्यवाणी करने और खोज परिणामों के भार में तेजी लाने का तरीका सीखा

खोज संकेत (sjest) न केवल एक उपयोगकर्ता सेवा है, बल्कि एक बहुत शक्तिशाली भाषा मॉडल भी है जो अरबों खोज क्वेरीज़ को संग्रहीत करता है, फ़र्ज़ी खोज, निजीकरण और बहुत कुछ का समर्थन करता है। हमने सीखा कि उपयोगकर्ता के अंतिम प्रश्न की भविष्यवाणी करने के लिए और "खोज" बटन पर क्लिक करने से पहले खोज परिणामों को लोड करने के लिए सुजस्ट का उपयोग कैसे करें।

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

1. क्या आइडिया काम करेगा?

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

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

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

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

प्री-रेंडरर के लिए मेट्रिक्स पूरी तरह से सामान्य बाइनरी वर्गीकरण की तरह व्यवस्थित नहीं हैं। केवल दो पैरामीटर महत्वपूर्ण हैं, लेकिन यह सटीकता या पूर्णता नहीं है।

चलो $$$आर$- अनुरोधों की कुल संख्या, $$$पी$- सभी पूर्वज की कुल संख्या, $$$ep$- सफल पूर्ववक्ताओं की कुल संख्या, अर्थात्। जो अंततः उपयोगकर्ता इनपुट से मेल खाते हैं। फिर दो दिलचस्प विशेषताओं की गणना निम्नानुसार की जाती है:

$$

$$ओवरहेड = \ frac {p + r - ep} {r} - 1$$

$$

$$दक्षता = \ frac {अवधि} {r}$$

उदाहरण के लिए, यदि वास्तव में प्रति अनुरोध एक प्रीरेन्डर किया जाता है, और आधे से प्रेडेंडर सफल होते हैं, तो प्रीरेन्डर 50% प्रभावी होगा, और इसका मतलब यह है कि अनुरोधों के आधे हिस्से को लोड करना तेज करना संभव था। उसी समय, उन अनुरोधों के लिए जिनमें प्रीरेन्डर ने सफलतापूर्वक काम किया था, अतिरिक्त ट्रैफ़िक नहीं बनाया गया था; उन अनुरोधों के लिए जिनमें प्रीरेन्डर विफल रहा, एक अतिरिक्त अनुरोध सेट करना पड़ा; इसलिए अनुरोधों की कुल संख्या मूल से डेढ़ गुना बड़ी है, इसलिए "अतिरिक्त" मूल संख्या का 50% अनुरोध करता है $$$ओवरहेड = 0.5$।

इन निर्देशांक में, मैंने पहली बिखराव की साजिश रची। वह इस तरह दिखे:

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

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

margin prefix candidate -180.424   -96.096    -67.425    -198.641    -138.851    -123.803    -109.841    -96.805    -146.568     -135.725     -125.448     -58.615      31.414     -66.754      1.716         

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

2. पहला कार्यान्वयन

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

उस समय, क्लासिफायर ने नए कारकों का अधिग्रहण किया, और मॉडल अब लॉजिस्टिक प्रतिगमन नहीं था, लेकिन काफी कैटबॉस्ट था । प्रारंभ में, हमने क्लासिफ़ायर के लिए काफी रूढ़िवादी थ्रेसहोल्ड रोल किए, लेकिन यहां तक ​​कि उन्होंने हमें लगभग 10% खोज परिणामों को तुरंत लोड करने की अनुमति दी। यह एक बहुत ही सफल रिलीज थी, क्योंकि हम SERP की डाउनलोड गति की छोटी मात्रा को काफी हद तक स्थानांतरित करने में कामयाब रहे, और उपयोगकर्ताओं ने इस पर ध्यान दिया और सांख्यिकीय रूप से खोज पर वापस लौटना शुरू किया: खोज के एक महत्वपूर्ण स्पीडअप ने खोज सत्रों को करने वाले उपयोगकर्ताओं की आवृत्ति को प्रभावित किया!

3. और सुधार

हालांकि कार्यान्वयन सफल था, फिर भी समाधान अत्यंत अपूर्ण था। ऑपरेशन लॉग के एक सावधानीपूर्वक अध्ययन से पता चला है कि कई समस्याएं हैं।

1. क्लासिफायरियर अस्थिर है। उदाहरण के लिए, यह पता लगा सकता है कि Yandex उपसर्ग के द्वारा यह Yandex अनुरोध की भविष्यवाणी करता है, Yandex उपसर्ग द्वारा यह कुछ भी भविष्यवाणी नहीं करता है, और Yandex उपसर्ग द्वारा यह फिर से Yandex अनुरोध की भविष्यवाणी करता है। फिर हमारा पहला सीधा कार्यान्वयन दो अनुरोध करता है, हालांकि यह एक के साथ अच्छी तरह से प्रबंधित कर सकता है।

   
   

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

   
   

3. कुछ मामलों में, उम्मीदवारों के पास सफल होने का कोई मौका नहीं है। उदाहरण के लिए गलत संयोग के लिए एक खोज काम करती है, इसलिए उम्मीदवार, उदाहरण के लिए, उपयोगकर्ता द्वारा दर्ज किए गए केवल एक शब्द को शामिल कर सकते हैं; या उपयोगकर्ता एक टाइपो बना सकता है, और फिर पहला संकेत इसके इनपुट के साथ बिल्कुल मेल नहीं खाएगा।

   
   

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

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

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

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

अंत में, हमने एमएल की मदद से तीसरी समस्या को हल किया: संकेत के स्रोतों के बारे में कारकों को जोड़ा, उपयोगकर्ता इनपुट के साथ संयोग; इसके अलावा, पहले लॉन्च के लिए धन्यवाद, हम अधिक आंकड़े एकत्र करने और मासिक डेटा से सीखने में सक्षम थे।

4. नतीजा क्या है

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

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

सौभाग्य से, लागू किए गए कार्यान्वयन पहले से ही हमें पूर्व-रेंडरर के बारे में काफी स्थिर सुविधा के बारे में बात करने की अनुमति देते हैं; हमने अतिरिक्त रूप से खंड 2 में वर्णित कार्यान्वयनों का परीक्षण किया: उनमें से सभी एक साथ इस तथ्य को भी जन्म देते हैं कि उपयोगकर्ता स्वयं खोज सत्रों को अधिक बार करना शुरू करते हैं। यह एक और उपयोगी सबक है: सेवा की गति में महत्वपूर्ण सुधार सांख्यिकीय रूप से इसकी अवधारण को काफी प्रभावित कर सकता है।

नीचे दिए गए वीडियो में आप देख सकते हैं कि कैसे प्रीरेन्डर अब मेरे फोन पर काम कर रहा है।