📄 👂🏽 🏆 वास्तव में स्मार्ट खोज करना: चरण-दर-चरण मार्गदर्शिका 👂 🏇🏿 👨🏿

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

मौजूदा डेटाबेस के लिए एलिस्टिक्स खोज पर आधारित पूर्ण-पाठ खोज को कैसे तेज़ किया जाए, इस पर बहुत सारे लेख हैं। लेकिन वास्तव में स्मार्ट खोज करने के तरीके पर स्पष्ट रूप से पर्याप्त लेख नहीं हैं।

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

ठीक है, हमने अभी एक अल्टीमेटम निर्णय नहीं लिया है, लेकिन एक नियमित पूर्ण-पाठ खोज को स्मार्ट के करीब लाने के लिए क्या किया जा सकता है?

बुद्धि के तत्व

स्मार्ट खोज - यह केवल मामला है जब मात्रा गुणवत्ता में जा सकती है और बहुत छोटी और काफी सरल विशेषताएं जादू की भावना का निर्माण कर सकती हैं।

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

पृष्ठभूमि

इसमें कई दस्तावेजों के साथ एक ECM DIRECTUM है। दस्तावेज़ में मेटा-सूचना और एक निकाय के साथ एक कार्ड होता है, जिसमें कई संस्करण हो सकते हैं।

लक्ष्य को जल्दी और आसानी से खोज इंजन के एक उपयोगकर्ता के लिए इन दस्तावेजों में सामान्य तरीके से जानकारी के लिए खोज करना है।

अनुक्रमण

कुछ अच्छी तरह से देखने के लिए, आपको पहले इसे अच्छी तरह से अनुक्रमित करने की आवश्यकता है।

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

ईसीएम दस्तावेज़ों को एलेस्टिक्स खोज दस्तावेजों में मैप करना

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

कार्ड और बॉडी के अलावा, विभिन्न सेवाओं की जानकारी को एलेस्टिक्स खोज दस्तावेज़ में जोड़ा जाता है, जो अलग से ध्यान देने योग्य है:

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

सूचकांक रचना

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

लेकिन - सिस्टम में दस्तावेज़ अलग-अलग भाषाओं में हो सकते हैं, और इलास्टिक्स में बहुभाषी डेटा संग्रहीत करने से 2 समस्याएं आती हैं:

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

स्टैमिंग - शब्द के आधार का पता लगाना। तने को शब्द का मूल या उसका सामान्य रूप होना जरूरी नहीं है। आमतौर पर संबंधित शब्दों के लिए एक रूपरेखा में पेश किया जाना पर्याप्त है।
लेमेटेटाइजेशन एक प्रकार का स्टेमिंग है जिसमें किसी शब्द के सामान्य (शब्दावली) रूप को आधार माना जाता है।

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

पहली समस्या उस मामले के लिए हल की जा सकती है जब विभिन्न भाषाएं विभिन्न वर्ण सेटों का उपयोग करती हैं, (रूसी-अंग्रेजी दस्तावेज़ सिरिलिक और लैटिन अक्षरों का उपयोग करते हैं) - भाषा स्टेमर्स केवल "उनके" वर्णों को संसाधित करेंगे।

बस दूसरी समस्या को हल करने के लिए, हमने प्रत्येक भाषा के लिए एक अलग सूचकांक के साथ दृष्टिकोण का उपयोग किया।

दोनों दृष्टिकोणों को मिलाकर, हम भाषा सूचकांक प्राप्त करते हैं, जिसमें कई भाषाओं के लिए विश्लेषक होते हैं जो वर्णों के सेट में अंतर नहीं करते हैं: रूसी-अंग्रेजी (और अलग-अलग अंग्रेजी-रूसी), पोलिश-रूसी, जर्मन-रूसी, यूक्रेनी-अंग्रेजी, आदि। ।

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

सूचकांक संरचना

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

"ru_en_analyzer": { "filter": [ "lowercase", "russian_morphology", "english_morphology", "word_delimiter", "ru_en_stopwords" ], "char_filter": [ "yo_filter" ], "type": "custom", "tokenizer": "standard"}

लोअरकेस फ़िल्टर के साथ, सब कुछ स्पष्ट है, मैं आपको बाकी के बारे में बताऊंगा।

क्रमशः रूसी और अंग्रेजी पाठ के रूपात्मक विश्लेषण के लिए फ़िल्टर रशियन_मॉर्फोलॉजी और इंग्लिश_मॉर्फोलॉजी का इरादा है। वे इलास्टिसर्च का हिस्सा नहीं हैं और एक अलग विश्लेषण-आकृति विज्ञान प्लगइन के भाग के रूप में शामिल हैं। ये लेम्मेटाइज़र हैं जो कुछ अनुमानों के साथ संयोजन में शब्दावली दृष्टिकोण का उपयोग करते हैं और महत्वपूर्ण रूप से काम करते हैं, इसी भाषा के लिए अंतर्निहित फिल्टर की तुलना में बेहतर है।

 POST _analyze { "analyzer": "russian", "text": "   " } >>

और:

 POST _analyze { "analyzer": "ru_en_analyzer", "text": "   " } >>

बहुत ही जिज्ञासु शब्द_दालिमिटर फ़िल्टर। उदाहरण के लिए, यह टाइपो को खत्म करने में मदद करता है जब डॉट के बाद कोई जगह नहीं होती है। हम निम्नलिखित विन्यास का उपयोग करते हैं:

 "word_delimiter": { "catenate_all": "true", "type": "word_delimiter", "preserve_original": "true" }

yo_filter आपको E और E के बीच के अंतर को अनदेखा करने की अनुमति देता है:

 "yo_filter": { "type": "mapping", "mappings": [ " => ", " => " ] }

ru_en_stopwords फ़िल्टर प्रकार स्टॉप - स्टॉप शब्दों का हमारा शब्दकोश।

अनुक्रमण प्रक्रिया

ईसीएम में दस्तावेजों के निकाय, एक नियम के रूप में, कार्यालय स्वरूपों की फाइलें हैं: .docx, .pdf, आदि। पाठ को निकालने के लिए, निगलना-लगाव प्लगइन का उपयोग निम्नलिखित पाइपलाइन के साथ किया जाता है:

 { "document_version": { "processors": [ { "attachment": { "field": "content", "target_field": "attachment", "properties": [ "content", "content_length", "content_type", "language" ], "indexed_chars": -1, "ignore_failure": true } }, { "remove": { "field": "content", "ignore_failure": true } }, { "script": { "lang": "painless", "params": { "languages": ["ru", "en" ], "language_delimeter": "_" }, "source": "..." } }, { "remove": { "field": "attachment", "ignore_failure": true } } ] } }

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

 if (ctx.attachment != null) { if (params.languages.contains(ctx.attachment.language)) ctx._index = ctx._index + params.language_delimeter + ctx.attachment.language; if (ctx.attachment.content != null) ctx.content = ctx.attachment.content; if (ctx.attachment.content_length != null) ctx.content_length = ctx.attachment.content_length; if (ctx.attachment.content_type != null) ctx.content_type = ctx.attachment.content_type; if (ctx.attachment.language != null) ctx.language = ctx.attachment.language; }

इस प्रकार, हम हमेशा दस्तावेज़ को index_name में भेजते हैं । यदि भाषा परिभाषित नहीं है या समर्थित नहीं है, तो दस्तावेज़ इस सूचकांक में बसता है, अन्यथा यह index_name_language में आता है ।

हम फ़ाइल के मूल शरीर को संग्रहीत नहीं करते हैं, लेकिन _source फ़ील्ड सक्षम है, क्योंकि दस्तावेज़ को आंशिक रूप से अपडेट करना और पाया को हाइलाइट करना आवश्यक है।

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

जैसे, Elasticsearch में दस्तावेज़ का कोई अद्यतन नहीं है, तकनीकी रूप से, जब सूचकांक से अद्यतन किया जाता है, तो पुराने दस्तावेज़ को फिर से निकाल दिया जाता है, बदल दिया जाता है और पूरी तरह से फिर से अनुक्रमित किया जाता है।

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

खोज

विवरण की सुविधा के लिए, मैं अंतिम परिणाम का स्क्रीनशॉट दूंगा

पूरा पाठ

हमारे पास मुख्य प्रकार की क्वेरी सरल क्वेरी स्ट्रिंग क्वेरी है :

 "simple_query_string": { "fields": [ "card.d*.*_text", "card.d*.*_text.exact", "card.name^2", "card.name.exact^2", "content", "content.exact" ], "query": " ", "default_operator": "or", "analyze_wildcard": true, "minimum_should_match": "-35%", "quote_field_suffix": ".exact" }

जहाँ .exact डिफ़ॉल्ट पार्सर द्वारा अनुक्रमित फ़ील्ड हैं। दस्तावेज़ के नाम का महत्व अन्य क्षेत्रों की तुलना में दो गुना अधिक माना जाता है। "minimum_should_match": "-35%" "default_operator": "or" और "minimum_should_match": "-35%" का संयोजन आपको उन दस्तावेज़ों को खोजने की अनुमति देता है जिनमें 35% तक खोज शब्द शामिल नहीं हैं।

समानार्थी

सामान्य तौर पर, अलग-अलग एनालाइज़र का उपयोग अनुक्रमण और खोज के लिए किया जाता है, लेकिन उनमें एकमात्र अंतर खोज क्वेरी के पर्यायवाची को जोड़ने के लिए एक फिल्टर के अतिरिक्त है:

 "search_analyzer": { "filter": [ "lowercase", "russian_morphology", "english_morphology", "synonym_filter", "word_delimiter", "ru_en_stopwords" ], "char_filter": [ "yo_filter" ], "tokenizer": "standard" }

 "synonym_filter": { "type": "synonym_graph", "synonyms_path": "synonyms.txt" }

लेखा अधिकार

अधिकार-आधारित खोजों के लिए, मुख्य क्वेरी बूल क्वेरी में फ़िल्टर के अतिरिक्त के साथ सन्निहित है:

 "bool": { "must": [ { "simple_query_string": {...} } ], "filter": [ { "terms": { "rights": [           ] } } ] }

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

प्रासंगिकता ट्यूनिंग

डिफ़ॉल्ट रूप से, Elasticsearch बीएम 25 एल्गोरिथ्म का उपयोग करके परिणाम की प्रासंगिकता का मूल्यांकन क्वेरी और दस्तावेज़ के पाठ का उपयोग करके करता है। हमने तय किया कि तीन और कारकों को वांछित और वास्तविक परिणाम के अनुपालन के मूल्यांकन को प्रभावित करना चाहिए:

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

आप इस प्रभाव को फंक्शन स्कोर क्वेरी की सहायता से प्राप्त कर सकते हैं:
```
 "function_score": { "functions": [ { "gauss": { "modified_date": { "origin": "now", "scale": "1095d", "offset": "31d", "decay": 0.5 } } }, { "field_value_factor": { "field": "access_count", "missing": 1, "modifier": "log2p" } }, { "filter": { "term": { "life_stage_value_id": { "value": "" } } }, "weight": 1.1 } ], "query": { "bool": {...} } } 
```
नतीजतन, ceteris paribus, हम परिणाम की रेटिंग निर्भरता के अंतिम निर्भरता के अंतिम परिवर्तन एक्स और हिट Y की संख्या के बाद लगभग प्राप्त करते हैं:

बाहरी बुद्धि

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

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

ये दो ऑपरेशन ECM इंटेलिजेंट मॉड्यूल - DIRECTUM एरियो द्वारा किए जाते हैं।

स्मार्ट खोज प्रक्रिया

यह अधिक विस्तार से विचार करने का समय है कि क्या तंत्र बुद्धि के तत्वों को लागू किया जाता है।

उपयोगकर्ता त्रुटि सुधार

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

और दूसरी बात, खोज के अन्य चरण सही लेआउट के साथ किए गए हैं:

और अगर सही लेआउट के साथ कुछ भी नहीं पाया जा सकता है, तो खोज मूल रेखा से शुरू होती है।

टाइपस सुधार को वाक्यांश सुझाव का उपयोग करके कार्यान्वित किया जाता है। इसके साथ एक समस्या है - यदि आप एक ही समय में कई अनुक्रमित पर क्वेरी निष्पादित करते हैं, तो सुझाव कुछ भी वापस नहीं कर सकता है, जबकि यदि आप केवल एक सूचकांक पर निष्पादित करते हैं, तो परिणाम हैं। यह आत्मविश्वास = 0 सेट करके व्यवहार किया जाता है , लेकिन फिर सुझाव देते हैं कि शब्दों को उनके सामान्य रूप से प्रतिस्थापित करें। सहमत हूँ, यह अजीब होगा जब आप "पत्र" के लिए भावना में उत्तर पाने के लिए खोज करेंगे : शायद आप एक पत्र के बारे में खोज रहे थे?

अनुरोध में दो संकेतों का उपयोग करके इसे दरकिनार किया जा सकता है:

 "suggest": { "content_suggest": { "text": " ", "phrase": { "collate": { "query": {         {{suggestion}} } }, } }, "check_suggest": { "text": "", "phrase": { "collate": { "query": {         {{suggestion}} - ({{source_query}}) }, "params": { "source_query": " " } }, } } }

उपयोग किए गए आम मापदंडों में से

 "confidence": 0.0, "max_errors": 3.0, "size": 1

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

यदि स्रोत स्ट्रिंग पर खोज 0 परिणाम लौटाती है, तो इसे मर्ज द्वारा प्राप्त स्ट्रिंग से बदल दिया जाता है और खोज फिर से की जाती है:

अन्यथा, परिणामी संकेत स्ट्रिंग को केवल खोज के लिए संकेत के रूप में लौटाया जाता है:

क्वेरी वर्गीकरण और तथ्य निष्कर्षण

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

खोज पक्ष से - उन्होंने एक कॉन्फिगरेशन बनाया, जिसमें उन्होंने श्रेणियों को पंजीकृत किया, कौन से फैक्ट्स किस फेक फिल्टर्स पर लागू होते हैं।

इनपुट पूरा हुआ

पहले से ही वर्णित लेआउट सुधारों के अलावा, उपयोगकर्ता और सार्वजनिक दस्तावेजों की पिछली खोजें ऑटो-पूर्णता में आती हैं।

उन्हें एक अन्य प्रकार के सुझाव - पूर्णता प्राप्त करने वाले का उपयोग करके कार्यान्वित किया जाता है, लेकिन प्रत्येक की अपनी बारीकियां हैं।

स्वत: पूर्णता: खोज इतिहास

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

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

 "mappings": { "document": { "properties": { "input": { "type": "keyword" }, "suggest": { "type": "completion", "analyzer": "simple", "preserve_separators": true, "preserve_position_increments": true, "max_input_length": 50, "contexts": [ { "name": "user", "type": "CATEGORY" } ] }, "user": { "type": "keyword" } } } }

प्रत्येक नए संकेत के लिए वजन एक पर सेट होता है और हर बार जब आप अपडेट बाय क्वेरी एपीआई का उपयोग करके एक बहुत ही सरल ctx._source.suggest.weight++ स्क्रिप्ट के साथ इसे फिर से दर्ज करते हैं तो यह बढ़ जाता है।

स्वतः पूर्णता: दस्तावेज़

लेकिन बहुत सारे दस्तावेज और अधिकारों के संभावित संयोजन हो सकते हैं। इसलिए, यहां, इसके विपरीत, हमने ऑटो-पूर्ण होने पर अधिकारों द्वारा फ़िल्टरिंग नहीं करने का निर्णय लिया, लेकिन केवल सार्वजनिक दस्तावेजों को अनुक्रमित किया। हां, और आपको इस इंडेक्स से अलग-अलग टिप्स निकालने की जरूरत नहीं है। ऐसा लगता है कि सब कुछ में कार्यान्वयन पिछले एक की तुलना में आसान है, अगर दो बिंदुओं के लिए नहीं:

पहले एक - .01.01 केवल उपसर्ग खोज का समर्थन करता है, और ग्राहक हर चीज को आइटम नंबर असाइन करना पसंद करते हैं, और कुछ .01.01 को .01.01 क्योंकि आप एक क्वेरी टाइप करते हैं .01.01 हैं। यहाँ, पूरे नाम के साथ, आप इसे प्राप्त किए गए n-ग्राम को भी अनुक्रमित कर सकते हैं:

 { "extension": "pdf", "name": ".01.01   ", "suggest": [ { "input": "", "weight": 70 }, { "input": " ", "weight": 80 }, { "input": "  ", "weight": 90 }, { "input": ".01.01   ", "weight": 100 } ] }

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

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

यह पता चला है कि यहाँ एक पाइपलाइन है:

 { "dir_public_documents_pipeline": { "processors": [ ... { "set": { "field": "terms_array", "value": "{{name}}" } }, { "split": { "field": "terms_array", "separator": "\\s+|$" } }, { "script": { "source": "..." } } ] } }

निम्नलिखित स्क्रिप्ट के साथ:

 Date modified = new Date(0); if (ctx.modified_date != null) modified = new SimpleDateFormat('dd.MM.yyyy').parse(ctx.modified_date); long dayCount = (System.currentTimeMillis() - modified.getTime())/(1000*60*60*24); double score = Math.exp((-0.7*Math.max(0, dayCount - 31))/1095) * Math.log10(ctx.access_count + 2); int count = ctx.terms_array.length; ctx.suggest = new ArrayList(); ctx.suggest.add([ 'input': ctx.terms_array[count - 1], 'weight': Math.round(score * (255 - count + 1)) ]); for (int i = count - 2; i >= 0 ; --i) { if (ctx.terms_array[i].trim() != "") { ctx.suggest.add([ "input": ctx.terms_array[i] + " " + ctx.suggest[ctx.suggest.length - 1].input, "weight": Math.round(score * (255 - i))]); } } ctx.remove('terms_array'); ctx.remove('access_count'); ctx.remove('modified_date');

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

वास्तव में आवश्यक सार्वजनिक दस्तावेजों की संरचना अक्सर अपडेट नहीं की जाती है, इसलिए इस कमांड को मैन्युअल शुरुआत पर छोड़ा जा सकता है।

परिणाम प्रदर्शित करें

श्रेणी

श्रेणी निर्धारित करती है कि कौन से पहलू उपलब्ध होंगे और स्निपेट कैसा दिखेगा। यह बाहरी बुद्धि द्वारा स्वचालित रूप से पता लगाया जा सकता है या मैन्युअल रूप से खोज बार के ऊपर चुना जा सकता है।

पहलुओं

पहलू सभी के लिए एक ऐसी सहज बात है, जिसका व्यवहार, हालांकि, बहुत ही गैर-तुच्छ नियमों द्वारा वर्णित है। यहाँ उनमें से कुछ हैं:

पहलू मान खोज परिणामों पर निर्भर करते हैं, लेकिन परिणाम और खोज परिणाम चयनित पहलुओं पर निर्भर करते हैं। पुनरावृत्ति से कैसे बचें?
एक पहलू के भीतर मूल्यों का चयन इस पहलू के अन्य मूल्यों को प्रभावित नहीं करता है, लेकिन यह अन्य पहलुओं में मूल्यों को प्रभावित करता है:

उपयोगकर्ता-चयनित पहलू मान गायब नहीं होने चाहिए, भले ही किसी अन्य पहलू में कोई विकल्प उन्हें 0 में मिटा दे या वे अब शीर्ष में नहीं हैं:

लोच में, पहलुओं को एकत्रीकरण तंत्र के माध्यम से महसूस किया जाता है, लेकिन वर्णित नियमों का पालन करने के लिए, इन एकत्रीकरणों को एक दूसरे में निवेश किया जाना चाहिए और एक-दूसरे द्वारा फ़िल्टर किया जाना चाहिए।

इसके लिए ज़िम्मेदार अंशों पर विचार करें:

कोड बहुत बड़ा है

 { ... "post_filter": { "bool": { "must": [ { "terms": { "card.author_value_id": [ "1951063" ] } }, { "terms": { "editor_value_id": [ "2337706", "300643" ] } } ] } }, "query": {...} "aggs": { "card.author_value_id": { "filter": { "terms": { "editor_value_id": [ "2337706", "300643" ] } }, "aggs": { "card.author_value_id": { "terms": { "field": "card.author_value_id", "size": 11, "exclude": [ "1951063" ], "missing": "" } }, "card.author_value_id_selected": { "terms": { "field": "card.author_value_id", "size": 1, "include": [ "1951063" ], "missing": "" } } } }, ... "editor_value_id": { "filter": { "terms": { "card.author_value_id": [ "1951063" ] } }, "aggs": { "editor_value_id": { "terms": { "field": "editor_value_id", "size": 11, "exclude": [ "2337706", "300643" ], "missing": "" } }, "editor_value_id_selected": { "terms": { "field": "editor_value_id", "size": 2, "include": [ "2337706", "300643" ], "missing": "" } } } }, ... } }

यहाँ क्या है कि:

पोस्ट_फिल्टर आपको पहले से पूरी की गई क्वेरी के परिणामों पर एक अतिरिक्त शर्त लगाने की अनुमति देता है और एकत्रीकरण के परिणामों को प्रभावित नहीं करता है। वही पुनरावृत्ति अंतराल। सभी पहलुओं के सभी चयनित मूल्य शामिल हैं।
शीर्ष स्तर के एकत्रीकरण, उदाहरण के लिए card.author_value_id और editor_value_id । प्रत्येक में है:
- अन्य सभी पहलुओं के मान से फ़िल्टर करें, केवल अपने को छोड़कर;
- चयनित पहलू मूल्यों के लिए नेस्टेड एकत्रीकरण - विनाश के खिलाफ सुरक्षा ;
- अन्य पहलू मूल्यों के लिए नेस्टेड एकत्रीकरण। हम शीर्ष 10 दिखाते हैं, और शीर्ष 11 का अनुरोध करते हैं - यह निर्धारित करने के लिए कि क्या सभी बटन दिखाएं ।

के टुकड़े

चयनित श्रेणी के आधार पर, स्निपेट अलग दिख सकता है, उदाहरण के लिए, श्रेणी में खोजते समय समान दस्तावेज़

सभी :

और कर्मचारी :

या याद रखें, हम एक वाणिज्यिक प्रस्ताव के विषय को देखना चाहते थे और यह किससे आया था?

लोचदार से पूरे कार्ड को खींचने के लिए नहीं (यह खोज को धीमा करता है), स्रोत फ़िल्टरिंग का उपयोग किया जाता है :

 { ... "_source": { "includes": [ "id", "card.name", "card.card_type_value_id", "card.life_stage_value_id", "extension", ... ] }, "query": {...} ... }

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

 "highlight": { "pre_tags": [ "<strong>" ], "post_tags": [ "</strong>" ], "encoder": "html", "fields": { "card.name": { "number_of_fragments": 0 }, "content": { "fragment_size": 300, "number_of_fragments": 3, "type": "fvh" } } },

इस मामले में, नाम को संपूर्णता में हाइलाइट किया गया है, और पाठ से हम 300 वर्णों तक 3 टुकड़े प्राप्त करते हैं। फास्ट वेक्टर हाइलाइटर द्वारा लौटाए गए पाठ को एक न्यूनतम स्निपेट स्थिति प्राप्त करने के लिए एक मेकशिफ्ट एल्गोरिथ्म द्वारा आगे संपीड़ित किया जाता है।

गिरावट

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

 { ... "query": {...} ... "collapse": { "field": "id" } }

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

अंत।

वास्तव में स्मार्ट खोज करना: चरण-दर-चरण मार्गदर्शिका