👨🏻 👭 🛌🏼 यह कैसे किया जाता है: उपसर्ग खोज 👧🏿 🚵🏿 👸🏻

हम ऐसे समय में रहते हैं जब सब कुछ सरल लगता है और सब कुछ होता है। हमें एक स्केलेबल प्रोजेक्ट बनाने की आवश्यकता है - हम MongoDB का उपयोग करते हैं, हमें एक कतार की आवश्यकता है - यहां RabbitMQ है, हमें खोज कार्यक्षमता को बढ़ाने की आवश्यकता है - बस थूक: स्फ़िंक्स, सोलर, इलास्टिसर्च (यह रेखांकित करें कि क्या आवश्यक है)।

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

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

हम देखेंगे कि कैसे, हमारे प्रोजेक्ट http://indexisto.com का उपयोग करते हुए , साइट http://maximonline.ru पर एक खोज की गई थी और इसकी तुलना अन्य साइटों पर की गई थी।

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

हम उन उप-पुनीत परियोजनाओं का चयन करेंगे जिनकी उपसर्ग खोज है, और वहां हमारी क्वेरी खोजने की कोशिश करें:

परियोजना	सही अनुरोध	अमान्य अनुरोध
afisha.ru	सब कुछ ठीक है	नहीं मिला
ivi.ru	सब कुछ ठीक है	नहीं मिला
vk.com	सब कुछ ठीक है	नहीं मिला
maximonline.ru	सब कुछ ठीक है	सब कुछ ठीक है

जैसा कि हमारे छोटे अध्ययन से देखा जा सकता है, स्थिति आदर्श से बहुत दूर है। यहां आम समस्याएं हैं

वर्ड स्वैपिंग काम नहीं करता है
"छलांग" हैं। यही है, जैसा कि आप लिखते हैं, वांछित फिल्म या तो परिणामों में दिखाई देती है, फिर गायब हो जाती है।
कोई फजी खोज नहीं
हर किसी की आकृति विज्ञान नहीं है

चलो अनुकूलित करते हैं

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

अनुक्रमण

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

जैसा कि आप देख सकते हैं, आकृति विज्ञान फिल्टर शब्द को बदलता है (सामान्य रूप की ओर जाता है)। एक सामान्य खोज में, यह अच्छी तरह से काम करता है, क्योंकि उपयोगकर्ता द्वारा दर्ज की गई क्वेरी को भी सामान्य रूप में लाया जाएगा। लेकिन क्या करें जबकि उपयोगकर्ता ने केवल आधे शब्द (उपसर्ग खोज) में प्रवेश किया है? हम सूचकांक में मूल टोकन को बचाते हैं!

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

क्वेरी विश्लेषक

विश्लेषणकर्ताओं का उपयोग न करें, जो आपके अनुरोध को "साफ़" कर सकते हैं, उदाहरण के लिए, एक स्टॉप-शब्द फ़िल्टर जो अवरोधों और कणों को हटा देता है। यहाँ एक उदाहरण है:

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

जांच

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

{ "query":{ "bool" : { "should" : [ { "custom_boost_factor": { "query":{ "match":{ .... } }, "boost_factor": 100 } }, { "custom_boost_factor": { "query":{ "match":{ .... } } }, "boost_factor": 10 } }, ..... ] } } }

लेख के शीर्षक में सटीक वाक्यांश मिलान

इसलिए, हमारी खोज क्वेरी में विभिन्न बूस्ट कारकों के साथ छोटे प्रश्नों का एक समूह है। बूस्ट फैक्टर एक प्रासंगिक कारक है जिसे तब लागू किया जाता है जब अंतर्निहित पाठ प्रासंगिकता की गणना पहले से की जाती है।

सबसे पहले, हम लेख के शीर्षक (या पृष्ठ शीर्षक) में वाक्यांश के सटीक मिलान की खोज करते हैं। सटीक मिलान का मतलब है कि हम उपसर्ग का उपयोग नहीं कर रहे हैं। उदाहरण के लिए, क्वेरी "HOW" पहले लेख " हाउ टू ... " को प्रदर्शित करेगी, न कि लेख "पार्टी की तरह बढ़ती" । इस तरह के अनुरोध पर प्राप्त दस्तावेजों को बढ़ावा मिलता है, उदाहरण के लिए, 10,000।

लेख शीर्षक में उपसर्ग वाक्यांश मिलान

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

यहाँ वर्तमान उत्पादन है:

सटीक मिलान पहले, उपसर्ग दूसरे हैं।

लेख के शरीर में मेल खाता है - पूर्ण और उपसर्ग

हमने शीर्षक में मैच पाया और उन्हें एक अच्छा बढ़ावा दिया। लेख के शरीर में जाने का समय। सबसे पहले, हम फिर से एक सटीक मैच की तलाश कर रहे हैं, और एक छोटे से बढ़ावा कारक के साथ, उपसर्ग मैच।

इस प्रकार, शीर्षक में मैच SERP में पहला होगा, और लेख के शरीर में मैच कम होंगे। प्रश्न उठता है: क्या इस तरह की छंटनी को पाठ की प्रासंगिकता को प्रासंगिकता दी जानी चाहिए? दरअसल, मानक एल्गोरिदम उस पाठ की लंबाई को ध्यान में रखते हैं जिसमें एक मैच पाया जाता है: पाठ जितना छोटा होगा, प्रासंगिकता उतनी ही अधिक होगी। हालांकि, अभ्यास से पता चला है कि लेख के शरीर में एक उपसर्ग खोज के साथ बहुत सारे संयोग होंगे। कल्पना कीजिए कि आपने 1-2 अक्षरों को टाइप किया है, और लेख के शरीर में पहले से ही 200-300 मैच होंगे, और पाठ की लंबाई के बावजूद, वे शीर्षक में मैचों की प्रासंगिकता को मार देंगे।

फजी शीर्षक या लेख के शरीर में मेल खाता है

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

 "custom_boost_factor": { "query":{ "multi_match":{ "query":"${q}", "fuzziness":0.005, "prefix_length" : 2, "operator":"and", "max_expansions":999, "fields":[ "article_name", "article_body" ] } }, "boost_factor": 1 } }

फ़ज़ी सर्च द्वारा पाए गए मैच न्यूनतम बूस्ट फैक्टर के कारण बहुत नीचे तक जाते हैं।

परिणाम क्या है?

चित्र दिखाता है कि संयोग के अनुसार हमारे परिणाम कैसे पंक्तिबद्ध हैं:

सटीक शीर्षक
उपसर्ग शीर्षक में
लेख के शरीर में सटीक हैं
उपसर्ग द्वारा लेख के शरीर में
लेख के शीर्षक और मुख्य भाग फ़िज़ी हैं (टाइपोस के साथ)

आर्टिकल में महारत हासिल करने वालों के लिए बोनस ट्रैक

हम खोज प्रश्नों के सभी आंकड़े एकत्र करते हैं, खोज के परिणामों पर क्लिक करते हैं, बिना क्लिक के खोज करते हैं, खाली परिणाम वाली खोजें करते हैं।
यह दिलचस्प है कि maximonline.ru पर खोज काफी लोकप्रिय कार्यक्षमता है, और 90% खोज क्वेरी लड़कियों के नाम हैं। यहाँ आप बहुत दिलचस्प डेटा प्राप्त कर सकते हैं :)

इसलिए, मैक्सिम पाठकों द्वारा सबसे ज्यादा मांग की जाने वाली लड़कियां रिवर्स ऑर्डर में हैं! नवंबर 2013 का डेटा।

5. अन्ना सेमेनोविच (टीवी प्रस्तोता)