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

1. क्वोरम ऑपरेटर:

"computing and technology news"/2इसका अर्थ है कि वाक्यांश के कम से कम दो शब्द मेल खाने चाहिए, यानी यह क्वेरी “computing news” और “technology news” दोनों शब्दों वाले पाठ को ढूंढेगी।

2. निकटता खोज ऑपरेटर:

"computing news"~3 इसका मतलब है कि क्वेरी के शब्दों के बीच N गैर-मिलान शब्द हो सकते हैं। यहां कुछ उदाहरण दिए गए हैं जब पाठ a b c d e f g h है:

• "a h"~7 ढूंढ पाएगा क्योंकि b c d e f h 6 गैर-मिलान शब्द हैं और यह 7 से कम है
  हालांकि "a h"~6 पाठ को नहीं ढूंढेगा
• "a d h"~6 ढूंढ पाएगा
• "a d h"~5 नहीं ढूंढेगा

3. NEAR ऑपरेटर

computing NEAR/6 "technology news"

ऊपर दिया गया निकटता ऑपरेटर केवल कीवर्ड सेट पर काम करता है। NEAR अधिक सामान्य है और अपने दो तर्कों के रूप में मनमानी उप-अभिव्यक्तियों को स्वीकार कर सकता है, दस्तावेज को तब मैच करता है जब दोनों उप-अभिव्यक्तियां एक-दूसरे से N शब्दों के भीतर पाई जाती हैं, चाहे किसी भी क्रम में हों।

ऊपर दी गई क्वेरी:

• computing is a popular topic in technology news वाले दस्तावेज से मेल खाएगी, क्योंकि पहला शब्द और वाक्यांश 6 शब्दों के भीतर पाए जाते हैं
• लेकिन computing nowadays is a popular topic in* technology news से मेल नहीं खाएगी क्योंकि अंतर पहले से ही 6 है और NEAR ऑपरेटर में निर्धारित सीमा से अधिक है।

दूसरे पास की तर्क

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

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

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

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