गुणवत्ता के खिलाफ लड़ाई के बारे में

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

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

बल्ले से सही

SphinxQL में डिफ़ॉल्ट रैंकिंग मोड (विस्तारित क्वेरी मोड के लिए, जो सिंटैक्स के साथ है) का अनुकरण उदाहरण के लिए, निम्न प्रकार है:
SELECT *, WEIGHT() FROM myindex WHERE MATCH('hello world')
OPTION ranker=expr('sum(lcs*user_weight)*1000+bm25')

स्फ़िंक्सएपीआई के माध्यम से, क्रमशः:
$client->SetRankingMode(SPH_RANK_EXPR, "sum(lcs*user_weight)*1000+bm25");


यह कैसे काम करता है

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

क्या कारक हैं

दस्तावेज़ स्तर कारक निम्नानुसार हैं:

• पूरे दस्तावेज़ के लिए सांख्यिकीय फ़ंक्शन BM25 का bm25 , मोटा (!) त्वरित अनुमान। मुझ में बोर चुप नहीं रह सकता है और यह सूचित नहीं करता है कि अनुकूलन के लिए सभी मोटे होने के बाद, यह वास्तव में, बीएम 15 की तुलना में अधिक संभावना है। बाकी सभी के लिए एक अधिक समझने योग्य स्पष्टीकरण: यह 0 से 999 तक की सीमा में कुछ प्रकार का जादू पूर्णांक है, जो बढ़ता है अगर दस्तावेज़ में बहुत सारे दुर्लभ शब्द हैं और यदि लगातार बहुत सारे हैं तो गिर जाता है।
• max_lcs , अधिकतम संभव मान योग (lcs * user_weight) है। MATCH_ANY का अनुकरण करने के लिए उपयोग किया जाता है, ठीक है, सामान्य रूप से, यह किसी भी सामान्यीकरण के काम में आ सकता है।
• फ़ील्ड_मास्क , मिलान वाले फ़ील्ड का 32-बिट मास्क।
• query_word_count , क्वेरी में अनन्य "शामिल" कीवर्ड की संख्या। दूसरे शब्दों में, "बहिष्कृत" शब्दों के लिए समायोजित किए गए अद्वितीय कीवर्ड की कुल संख्या। उदाहरण के लिए, क्वेरी (एक! दो) में यह 1 होगा, हो सकता है। शब्द (दो) को बाहर रखा गया है और कभी मेल नहीं खाएगा। अनुरोध के लिए (एक एक! दो) भी 1 है, हो सकता है। अद्वितीय (!) शामिल शब्द अभी भी केवल एक है। और अनुरोध के लिए (एक दो तीन) पहले से, तदनुसार, कारक का मूल्य 3 होगा।
• doc_word_count , वर्तमान दस्तावेज़ में मेल खाने वाले अनूठे शब्दों की संख्या। यह स्पष्ट है कि किसी भी तरह से query_word_count से अधिक नहीं होना चाहिए।

फ़ील्ड स्तर कारक निम्नानुसार हैं:

• एलसीएस , वही जादुई कारक जो क्वेरी और फ़ील्ड के बीच "वाक्यांश मिलान" की डिग्री पर विचार करता है। औपचारिक रूप से, क्वेरी और दस्तावेज़ में शब्दों के सबसे बड़े सामान्य बाद की लंबाई। यह 0 के बराबर है यदि क्षेत्र में कुछ भी संयोग नहीं है; कम से कम कुछ मिलान होने पर 1 के बराबर; और सीमा में (शामिल) क्वेरी शब्दों की संख्या के बराबर है, यदि क्वेरी फ़ील्ड से पूरी तरह मेल खाती है।
• क्रमश: SetFieldWeights () या OPTION field_weights के माध्यम से असाइन किए गए फ़ील्ड का उपयोगकर्ता वजन, उपयोगकर्ता का वजन।
• हिट_काउंट , कीवर्ड की मिलान वाली घटनाओं की संख्या। एक कीवर्ड कई घटनाएँ उत्पन्न कर सकता है। उदाहरण के लिए, यदि अनुरोध (हैलो दुनिया) एक फ़ील्ड से मेल खाता है जिसमें हैलो 3 बार और दुनिया 5 है, तो हिट_काउंट होगा 8. यदि, हालांकि, फ़ील्ड में वाक्यांश हैलो दुनिया ठीक 1 बार होती है (इस तथ्य के बावजूद कि शब्दों का उल्लेख 3 और है 5 बार) + इसके अलावा, अनुरोध उद्धरण चिह्नों में "हैलो वर्ल्ड" था, फिर हिट_काउंट 2 के बराबर होगा। शब्दों की घटनाओं की कुल संख्या अभी भी 8 है, लेकिन दूसरे मामले में उनके केवल 2 के वाक्यांश मिलान के साथ।
• word_count , फ़ील्ड में मेल खाने वाले अनूठे शब्दों की संख्या (घटनाएँ नहीं)। पिछले दोनों उदाहरणों में 2 के बराबर है, उदाहरण के लिए।
• tf_idf , सभी मिलान कीवर्ड के लिए TF * IDF का योग। टीएफ सिर्फ घटनाओं की संख्या (टर्म फ्रीक्वेंसी) है, लेकिन आईडीएफ एक और जादू मीट्रिक है जो शब्द की "दुर्लभता" को ध्यान में रखता है: सुपर-लगातार शब्दों के लिए (जो प्रत्येक दस्तावेज़ में हैं) यह 0 है, और एक अद्वितीय शब्द (1 दस्तावेज़ में 1 घटना) के लिए संपूर्ण संग्रह) 1 के बराबर है।
• min_hit_pos , क्षेत्र में बहुत पहले मिलान खोजशब्द स्थिति। क्रमांक 1 से शुरू होता है। यह उपयोगी है, उदाहरण के लिए, ऊपर के क्षेत्र की शुरुआत में मैचों को रैंक करने के लिए।
• min_best_span_pos , कीवर्ड की "सबसे बड़ी" (सबसे बड़ी) के सबसे पहले स्थान के सबसेट। नंबरिंग अभी भी 1 से है।
• सटीक_हिट , एक बूलीयन फ़्लैग जिसे यदि फ़ील्ड पूरी तरह से मेल खाती है, तो लहराया जाता है। मान, क्रमशः, 0 और 1 हैं।

फिलहाल एकत्रीकरण समारोह ठीक एक है, एसयूएम। फ़ंक्शन के अंदर की अभिव्यक्ति सभी क्षेत्रों के लिए गणना की जाती है, फिर परिणाम अभिव्यक्त किए जाते हैं। ये एक ही SUM कई किए जा सकते हैं, अलग-अलग भावों के साथ।
स्पष्ट कारणों के लिए, फ़ील्ड स्तर का कारक एकत्रीकरण फ़ंक्शन के भीतर सख्ती से होना चाहिए। अंत में, हमें एक विशिष्ट क्षेत्र में "लिंकिंग" के बिना, क्रमशः एक संख्या की गणना करनी चाहिए, ऐसे कारकों का कोई भौतिक अर्थ नहीं है। दस्तावेज़ स्तर के कारक और विशेषताएँ, निश्चित रूप से, अभिव्यक्ति में कहीं भी उपयोग किए जा सकते हैं।

मौजूदा रैंकर्स का अनुकरण कैसे करें

पहले के सभी मौजूदा रैंकर्स, वास्तव में, नए शांत फॉर्मूलों के रूप में बेहद सरल हैं। प्रति रैंकर कारकों की एक जोड़ी की एक अधिकतम। सूची है:

• SPH_RANK_PROXIMITY_BM25 = योग (lcs * user_weight) * 1000 + bm25
• SPH_RANK_BM25 = bm25
• SPH_RANK_NONE = 1
• SPH_RANK_WORDCOUNT = योग (हिट_काउंट * user_weight)
• SPH_RANK_PROXIMITY = राशि (lcs * user_weight)
• SPH_RANK_MATCHANY = sum ((word_count + (lcs-1) * max_lcs) * user_weight)
• SPH_RANK_FIELDMASK = field_mask
• SPH_RANK_SPH04 = योग ((4 * lcs + 2 * (min_hit_pos == 1) + exact_hit) * user_weight) * 1000 + bm25

बेशक, बिल्ट-इन रैंकर का उपयोग करने की तुलना में धीमी गति से काम करेगा। फिर भी, संकलित कोड हमारी अभिव्यक्ति कैलकुलेटर की तुलना में अभी भी तेज है! हालाँकि, मंदी, जिसे मैं सोचकर नहीं रोक सकता, अक्सर महत्वहीन है। यहां तक ​​कि उस मामले में जहां खोज मेल खाती है और सैकड़ों हजारों और लाखों दस्तावेजों को रैंक करना चाहिए, मुझे "माइक्रो" बेंचमार्क पर लगभग 30-50% का अंतर मिला (शाब्दिक रूप से निर्मित रैंक के साथ 0.4 सेकंड के बजाय, उत्सर्जन के बारे में 0.5-0.6 सेकंड)। मुझे संदेह है कि अगर 1-10k से कम दस्तावेज मेल खाते हैं, तो मतभेद बिल्कुल भी नहीं बताए जा सकते हैं।

आगे क्या है?

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

सभी को नमस्कार, खोज की गुणवत्ता के खिलाफ लड़ाई में शुभकामनाएँ :)