कार्य

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

1. संक्षिप्त नाम के साथ एक विशिष्ट नाम, जिसे केवल स्थानीय सुपरमार्केट या कैशियर खरीदारों द्वारा समझा जा सकता है।
2. खोज स्ट्रिंग में उपयोगकर्ता द्वारा दर्ज की गई एक प्राकृतिक भाषा क्वेरी।

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

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

डेटासेट - समस्याओं को हल करने के लिए

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

तकनीक के बारे में

खोज को लागू करने के लिए एलियटेसर्च एक काफी लोकप्रिय और सस्ती तकनीक है। यह एक JSON REST API खोज इंजन है, जो Lucene का उपयोग करता है और जावा में लिखा जाता है। इलास्टिक के मुख्य लाभ गति, मापनीयता और दोष सहिष्णुता हैं। दस्तावेजों के डेटाबेस में जटिल खोजों के लिए इसी तरह के इंजन का उपयोग किया जाता है। उदाहरण के लिए, भाषा की आकृति विज्ञान या भू-निर्देशांकों द्वारा की गई खोज को ध्यान में रखते हुए।

प्रयोग और सुधार के लिए दिशा-निर्देश

यह समझने के लिए कि आप अपनी खोज को कैसे बेहतर बना सकते हैं, आपको खोज प्रणाली को इसके घटक कस्टम घटकों में पार्स करने की आवश्यकता है। हमारे मामले के लिए, सिस्टम की संरचना इस तरह दिखती है।

1. खोज के लिए इनपुट स्ट्रिंग विश्लेषक के माध्यम से गुजरती है, जो एक निश्चित तरीके से स्ट्रिंग को टोकन में तोड़ देती है - खोज इकाइयां जो उस डेटा के बीच खोज करती हैं जिन्हें टोकन के रूप में भी संग्रहीत किया जाता है।
2. फिर मौजूदा डेटाबेस में प्रत्येक दस्तावेज़ के लिए इन टोकन के लिए एक प्रत्यक्ष खोज है। एक निश्चित दस्तावेज़ में टोकन खोजने के बाद (जो टोकन के सेट के रूप में डेटाबेस में भी प्रस्तुत किया गया है), इसकी प्रासंगिकता की गणना चयनित समानता मॉडल के अनुसार की जाती है (हम इसे प्रासंगिक मॉडल कहेंगे)। यह एक साधारण TF / IDF (टर्म फ़्रीक्वेंसी - इनवर्स डॉक्युमेंट फ़्रीक्वेंसी) हो सकता है, या यह अन्य अधिक जटिल या विशिष्ट मॉडल हो सकता है।
3. अगले चरण में, प्रत्येक व्यक्तिगत टोकन द्वारा बनाए गए अंकों की संख्या को एक निश्चित तरीके से एकत्र किया जाता है। एकत्रीकरण पैरामीटर क्वेरी शब्दार्थ द्वारा निर्धारित किए जाते हैं। इस तरह के एकत्रीकरण का एक उदाहरण कुछ टोकन (अतिरिक्त मूल्य) के लिए अतिरिक्त भार हो सकता है, एक टोकन की अनिवार्य उपस्थिति के लिए शर्तें आदि। इस चरण का परिणाम स्कोर है - प्रारंभिक अनुरोध के सापेक्ष डेटाबेस से किसी विशेष दस्तावेज़ की प्रासंगिकता का अंतिम मूल्यांकन।

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

1. विश्लेषक
2. समानता मॉडल
3. समय-समय पर सुधार

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

क्वेरी-समय में सुधार

यह समझने के लिए कि हम अनुरोध में क्या सुधार कर सकते हैं, हम प्रारंभिक अनुरोध का एक उदाहरण देते हैं।

{ "query": { "multi_match": { "query": "  105", "type": "most_fields", "fields": ["name"], "minimum_should_match": "70%" } }, “size”: 100, “min_score”: 15 } 

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

क्या कॉन्फ़िगर किया जा सकता है:

• विभिन्न विश्लेषणकर्ताओं का भारित संयोजन।
  प्रारंभ में, सभी खोज तत्वों का वजन समान है - और इसलिए, समान महत्व। इसे पैरामीटर 'बूस्ट' को जोड़कर बदला जा सकता है, जो संख्यात्मक मान लेता है। यदि पैरामीटर 1 से अधिक है, तो खोज तत्व क्रमशः 1 - कम से कम, परिणामों पर अधिक प्रभाव डालेंगे।
• विश्लेषण करने वालों को 'चाहिए' और 'चाहिए' में अलग करना।
  अर्थात्, कुछ विश्लेषण करने वालों को मेल खाना चाहिए, और कुछ वैकल्पिक हैं, जो अपर्याप्त है। हमारे मामले में, संख्या विश्लेषक इस तरह के अलगाव के लाभों का एक उदाहरण हो सकता है। यदि अनुरोध में उत्पाद नाम में केवल संख्या मेल खाती है और डेटाबेस में उत्पाद का नाम है, तो यह उनके समतुल्य के लिए पर्याप्त स्थिति नहीं है। हम ऐसे उत्पादों को परिणाम के रूप में नहीं देखना चाहते हैं। उसी समय, यदि अनुरोध "क्रीम 10%" है, तो हम चाहते हैं कि 10% वसा के साथ सभी क्रीम 20% वसा के साथ क्रीम पर एक बड़ा लाभ हो।
• न्यूनतम_शोल्डर_मैच पैरामीटर। डेटाबेस से अनुरोध और दस्तावेज़ में कितने टोकन आवश्यक रूप से मेल खाने चाहिए? यह पैरामीटर हमारे अनुरोध के प्रकार (most_fields) के साथ मिलकर काम करता है और प्रत्येक फ़ील्ड के लिए (हमारे मामले में, प्रत्येक विश्लेषक के लिए) मिलान की न्यूनतम संख्या की जांच करता है।
• Min_score पैरामीटर। अपर्याप्त बिंदुओं के साथ थ्रेसहोल्ड स्क्रीनिंग दस्तावेज़। पकड़ यह है कि कोई ज्ञात अधिकतम गति नहीं है। परिणामी स्कोर एक विशिष्ट अनुरोध और दस्तावेजों के एक विशिष्ट डेटाबेस पर निर्भर करता है। कभी-कभी यह 150, और कभी-कभी 2 हो सकता है, लेकिन इन दोनों मूल्यों का मतलब होगा कि डेटाबेस से ऑब्जेक्ट अनुरोध के लिए प्रासंगिक है। हम विभिन्न प्रश्नों के परिणामों के स्कोर की तुलना नहीं कर सकते हैं।
  
  • लगातार।
    विभिन्न प्रश्नों के लिए गति के अंतिम मूल्यों की पर्याप्त निगरानी के बाद, आप एक अनुमानित सीमा की पहचान कर सकते हैं, जिसके बाद अधिकांश प्रश्नों के लिए परिणाम अनुपयुक्त हो जाते हैं। यह सबसे आसान है, लेकिन सबसे बेवकूफ निर्णय भी है, जो खराब-गुणवत्ता वाली खोज की ओर जाता है।
  • न्यूनतम या शून्य min_score के साथ खोज करने के बाद एक विशिष्ट अनुरोध के लिए प्राप्त अंकों का विश्लेषण करने का प्रयास करें।
    विचार यह है कि एक निश्चित क्षण के बाद, आप कम गति की दिशा में एक तेज कूद का निरीक्षण कर सकते हैं। यह केवल समय में रोकने के लिए इस कूद को निर्धारित करने के लिए बनी हुई है। इस तरह का दृष्टिकोण समान प्रश्नों पर अच्छा काम करेगा:
    
    कूद सांख्यिकीय विधियों द्वारा पाया जा सकता है। लेकिन, दुर्भाग्य से, सभी अनुरोधों में यह कूद मौजूद नहीं है और आसानी से पहचाने जाने योग्य है।
  • आदर्श गति की गणना करें और min_score को आदर्श के एक निश्चित अंश के रूप में सेट करें, जिसे दो तरीकों से किया जा सकता है:
    
    • व्याख्या स्थापित करते समय स्वयं इलास्टिक द्वारा प्रदान की गई गणनाओं के विस्तृत विवरण से: वास्तविक पैरामीटर। यह एक कठिन काम है, जिसमें एलिस्टिक्स द्वारा उपयोग किए जाने वाले क्वेरी आर्किटेक्चर और कम्प्यूटेशनल एल्गोरिदम की गहन समझ की आवश्यकता है।
    • थोड़ी चाल से। हम एक अनुरोध प्राप्त करते हैं, एक ही नाम के साथ हमारे डेटाबेस में एक नया उत्पाद जोड़ते हैं, एक खोज करते हैं और अधिकतम गति प्राप्त करते हैं। चूंकि नाम में 100% मैच होगा, परिणामी मूल्य आदर्श होगा। यह इस दृष्टिकोण है कि हम अपने सिस्टम में उपयोग करते हैं, समय के संबंध में इस ऑपरेशन की उच्च लागत के बारे में चिंताओं की पुष्टि नहीं की गई है।
• स्कोरिंग एल्गोरिथ्म को बदलें, जो अंतिम प्रासंगिकता मूल्य के लिए जिम्मेदार है। यह स्टोर की दूरी को ध्यान में रखते हुए हो सकता है (उत्पादों के अधिक अंक दें जो करीब हैं), उत्पाद की कीमतें (सबसे संभावित मूल्य के साथ उत्पादों को अधिक अंक दें), आदि।

विश्लेषक

विश्लेषक तीन चरणों में इनपुट स्ट्रिंग का विश्लेषण करता है और आउटपुट - आउटपुट इकाइयों में टोकन को खोजता है:

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

गौर कीजिए कि हमारे मामले में कदमों की विविधताएँ कितनी उपयोगी हो गई हैं।

चार फिल्टर

• रूसी भाषा की बारीकियों के अनुसार, ऐसे पात्रों को वें और ई के रूप में संसाधित करना और उन्हें क्रमशः और ई के साथ प्रतिस्थापित करना उपयोगी होगा।
• लिप्यंतरण करें - एक लेखन के पात्रों का हस्तांतरण दूसरे लेखन के पात्रों द्वारा। हमारे मामले में, यह लैटिन में लिखे गए नामों का प्रसंस्करण है या दोनों वर्णमालाओं के साथ मिश्रित है। ट्रांसलिटरेशन को प्लग-इन ( ICU एनालिसिस प्लगिन ) को टोकन फिल्टर के रूप में लागू किया जा सकता है (अर्थात, यह मूल स्ट्रिंग नहीं, बल्कि अंतिम टोकन को प्रोसेस करता है)। हमने अपने लिप्यंतरण को लिखने का फैसला किया, क्योंकि हम प्लगइन में एल्गोरिथ्म से काफी खुश नहीं थे। विचार पहले चार-वर्ण सेट आवृत्तियों (जैसे, "SHCH => u") को प्रतिस्थापित करने के लिए है, फिर तीन-वर्ण की घटनाएँ, आदि जिसमें प्रतीक फ़िल्टर का उपयोग किया जाता है वह क्रम महत्वपूर्ण है क्योंकि परिणाम आदेश पर निर्भर करेगा।
• रूसी सी के साथ, सिरिलिक से घिरे लैटिन सी को बदलें। डेटाबेस में नामों का विश्लेषण करने के बाद इसकी आवश्यकता की पहचान की गई - सिरिलिक में बहुत सारे नामों में लैटिन सी शामिल हैं, जिसका अर्थ है सिरिलिक सी। जब मानो नाम पूरी तरह से लैटिन में है, तो लैटिन सी का मतलब सिरिलिक के या सी है। इसलिए, लिप्यंतरण से पहले, वर्ण c को प्रतिस्थापित करना आवश्यक है।
• नामों से बहुत बड़ी संख्या को हटाना। कभी-कभी उत्पाद नामों में एक आंतरिक पहचान संख्या होती है (उदाहरण के लिए 3387522 K.T. Maslo sunflower.raf। 0.9l), जो सामान्य मामले में कोई अर्थ नहीं रखती है।
• पीरियड्स के साथ कॉमा की जगह। इसकी आवश्यकता क्यों है? ताकि अंक, उदाहरण के लिए, दूध 3.2 और 3.2 की वसा सामग्री, बराबर हो

Tokenizer

• मानक टोकन - अंतरिक्ष और विराम चिह्न के अनुसार रेखाओं को अलग करता है (उदाहरण के लिए, "ट्विक्स अतिरिक्त 2" -> "ट्विक्स", "अतिरिक्त", "2")
• EdgeNGram टोकन - प्रत्येक शब्द को दी गई लंबाई (आमतौर पर संख्याओं की एक सीमा) के टोकन में विभाजित करता है, जो पहले वर्ण से शुरू होता है (उदाहरण के लिए, N = [3, 6]: "twix अतिरिक्त 2" -> "tee", "tweak"। "ट्विक्स", "पूर्व", "एक्सट", "एक्सट", "अतिरिक्त")
• संख्याओं के लिए टोकन - एक नियमित अभिव्यक्ति की खोज करके स्ट्रिंग से केवल संख्या का चयन करता है (उदाहरण के लिए, "ट्विक्स अतिरिक्त 2 4.5" -> "2", "4.5")

टोकन फ़िल्टर

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

समानता मॉडल

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

श्रेणियों का उपयोग करना

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

अंतिम मॉडल

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

डिफ़ॉल्ट मॉडल (Okapi - BM25) के साथ पैरामीटर b = 0.5 को प्रासंगिकता मॉडल के रूप में चुना गया था। डिफ़ॉल्ट मान 0.75 है। यह पैरामीटर दिखाता है कि उत्पाद नाम की लंबाई tf (टर्म फ़्रीक्वेंसी) वैरिएबल को किस हद तक सामान्य करती है। हमारे मामले में एक छोटी संख्या बेहतर काम करती है, क्योंकि लंबे नाम बहुत बार किसी एक शब्द के महत्व को प्रभावित नहीं करते हैं। यही है, नाम में "चॉकलेट" शब्द "25 टुकड़ों के पैकेज में कुचल हेज़लनट्स के साथ चॉकलेट" इस तथ्य से अपना मूल्य नहीं खोता है कि नाम काफी लंबा है।

अंतिम क्वेरी इस तरह दिखती है:

प्रयोगात्मक रूप से, विश्लेषक और भार का सबसे अच्छा संयोजन सामने आया था।

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

सादगी के लिए, गति के लिए सीमा इस अनुरोध में 15 पर सेट है, हालांकि हमारे सिस्टम में हम गणना किए गए पैरामीटर का उपयोग करते हैं जो पहले वर्णित था।

भविष्य में

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