搜索引擎是信息檢索（IR）系統(tǒng)的通俗叫法。雖然研究和開發(fā)人員看待IR系統(tǒng)的眼光更寬一些惩淳，但用戶想到它們更多的是根據(jù)他們期望系統(tǒng)能做的功能 — 即搜索網(wǎng)絡(luò)小泉，或者企業(yè)內(nèi)部網(wǎng)检访，或者一個數(shù)據(jù)庫司光。事實上用戶會更喜歡一個發(fā)現(xiàn)引擎惹悄，而不僅僅是一個搜索引擎误褪。
搜索引擎匹配查詢到它們創(chuàng)建的索引上责鳍。這個索引包含每個文檔的單詞，和能指向文兒當?shù)刂返闹羔樖藜洹＿@被叫做倒排索引文件【 inverted file】历葛。一個搜索引擎或者IR系統(tǒng)包括四個基本的模塊：
- 一個文檔處理器
- 一個查詢處理器
- 一個搜索和匹配功能
- 一個排名能力
雖然用戶關(guān)注的點是“搜索”，但是搜索和匹配功能僅僅是這四個模塊里的其中之一嘀略。這四個模塊中的每一個都可能導致用戶在使用搜索引擎時獲得預(yù)期或意外的結(jié)果恤溶。
文檔處理器
文檔處理器準備，處理和輸入用戶搜索的文檔帜羊，頁面或站點咒程。文檔處理器執(zhí)行以下部分或全部步驟：
- 將文檔流規(guī)范化為預(yù)定義格式。
- 將文檔流分解為所需的可檢索單元逮壁。
- 隔離和元標記每個子文檔塊撞羽。
- 標識文檔中潛在的可索引元素。
- 刪除停用詞狗热。
- 詞根化檢索詞滤灯。
- 提取索引條目。
- 計算權(quán)重忧饭。
- 創(chuàng)建并更新搜索引擎搜索的主要倒排索引文件扛伍，以便將查詢與文檔進行匹配。
第1-3步：預(yù)處理词裤。雖然是必不可少的步驟并且可能對影響搜索結(jié)果很重要刺洒，但前三個步驟只是簡單地標準化了各種來源或者處理各種網(wǎng)站時遇到的多種文件格式。這些步驟用于將所有數(shù)據(jù)合并為一個一致的數(shù)據(jù)結(jié)構(gòu)吼砂，所有下游進程都可以處理逆航。對于格式良好，格式一致的需求與文檔處理的后續(xù)步驟的復(fù)雜性是成重要正比的渔肩。第二步很重要因俐，因為存儲在倒排索引文件中的指針將使系統(tǒng)能夠檢索各種大小的單元 - 站點，頁面周偎，文檔抹剩，章節(jié)，段落或句子蓉坎。
第4步：確定要索引的元素澳眷。識別文檔中潛在的可索引元素會顯著的影響引擎將要搜索的文檔表示的性質(zhì)和質(zhì)量。在設(shè)計系統(tǒng)時蛉艾，我們必須定義“檢索詞【term】”一詞钳踊。它是空格或標點符號之間的字母數(shù)字字符嗎衷敌？如果是這樣，那么非成分短語怎么辦（單詞中沒有表達短語含義的短語箍土，如“skunk works”或“hot dog”）【譯者注：skunk works指特殊團隊逢享，hot dog指熱狗（面包夾熏紅腸）】，多字專有名稱吴藻，或連字符或撇號等詞間符號瞒爬，可以表示 "small business men"與small-business men之間的區(qū)別」当ぃ【譯者注：small business men的含義為身材矮小的生意人侧但，mall-business men的含義為小生意人 】。每個搜索引擎都依賴于其文檔處理器必須執(zhí)行的一組規(guī)則來確定“分詞器【tokenizer】”將采取的操作航罗。分詞器【tokenizer】即用于定義適合索引的檢索詞的軟件禀横。
第5步：刪除停用詞。此步驟通過消除進一步處理以及潛在的匹配（那些對于查找有用文檔以及響應(yīng)客戶查詢沒什么價值的檢索詞）粥血，來幫助節(jié)省系統(tǒng)資源柏锄。當內(nèi)存變得更加便宜且系統(tǒng)速度變得更快，這個比起現(xiàn)在可能沒多少價值了复亏，但由于停用詞可能占文檔中的文本詞高達40％趾娃，因此它仍具有一定的意義。停用詞列表通常由已知傳達一些實質(zhì)意義的詞類組成缔御，例如冠詞（a抬闷，the），連詞（and, but）耕突，感嘆詞（oh, but）笤成，介詞（in, over），代詞（he, it）和“將來”動詞的形式（is, are）眷茁。為了刪除停用詞炕泳，算法將文檔中的索引詞候選詞與停用詞列表進行比較，并從搜索索引中刪除這些詞語上祈。
第6步：檢索詞詞根化（詞干提群把隆）。詞干提取可以在一層又一層的處理中遞歸地刪除單詞后綴雇逞。這個過程有兩個目標。在效率方面茁裙，詞干提取減少了索引中唯一單詞的數(shù)量塘砸，從而減少了索引所需的存儲空間并加快了搜索過程。在有效性方面晤锥，詞干提取通過將所有形式的單詞縮減為基礎(chǔ)詞或詞干形式來改善檢索掉蔬。
例如廊宪，如果用戶要查詢analyze，他們可能還需要包含analysis女轿，analyzing箭启，analyzer，analyzes和analyzed的文檔蛉迹。因此傅寡，文檔處理器會根據(jù)文檔術(shù)語進行分析，以便包含各種形式的analy-的文檔會被同等概率的重新取回北救。如果引擎僅單獨索引變量形式并且要求用戶輸入全部檢索詞荐操，則不會發(fā)生這種情況。當然珍策，詞根化確實有缺點托启。它可能會對所有形式的詞干匹配的精度產(chǎn)生負面影響，當現(xiàn)實中攘宙，用戶希望查詢結(jié)果僅僅來自匹配查詢中實際使用的單詞時屯耸。
系統(tǒng)可以實現(xiàn)強干擾算法或弱干擾算法。強干擾算法將去除構(gòu)形后綴（-s蹭劈，-es疗绣，-ed）和派生后綴（-able，-aciousness链方，-ability）持痰，弱干擾算法只會去除構(gòu)形后綴（-s， -es祟蚀，-ed）工窍。
第7步：提取索引條目。完成步驟1到6后前酿，文檔處理器從原始文檔中提取剩余的條目患雏。例如，以下段落是要發(fā)送到搜索引擎進行處理的全文：
Milosevic's comments, carried by the official news agency Tanjug, cast doubt over the governments at the talks, which the international community has called to try to prevent an all-out war in the Serbian province. "President Milosevic said it was well known that Serbia and Yugoslavia were firmly committed to resolving problems in Kosovo, which is an integral part of Serbia, peacefully in Serbia with the participation of the representatives of all ethnic communities," Tanjug said. Milosevic was speaking during a meeting with British Foreign Secretary Robin Cook, who delivered an ultimatum to attend negotiations in a week's time on an autonomy proposal for Kosovo with ethnic Albanian leaders from the province. Cook earlier told a conference that Milosevic had agreed to study the proposal.
步驟1到6為了搜索將此文本減少到以下內(nèi)容：
Milosevic comm carri offic new agen Tanjug cast doubt govern talk interna commun call try prevent all-out war Serb province President Milosevic said well known Serbia Yugoslavia firm commit resolv problem Kosovo integr part Serbia peace Serbia particip representa ethnic commun Tanjug said Milosevic speak meeti British Foreign Secretary Robin Cook deliver ultimat attend negoti week time autonomy propos Kosovo ethnic Alban lead province Cook earl told conference Milosevic agree study propos.
然后插入步驟7罢维，并將輸出存儲在倒排索引文件中淹仑，該文件列出了索引條目以及它們的位置和出現(xiàn)頻率。但是肺孵，索引條目的具體性質(zhì)將根據(jù)步驟4中確定“要索引的元素”而有所不同匀借。更復(fù)雜的文檔處理器將具有短語識別器，以及命名實體識別器和分類器平窘，確保像Milosevic【米洛舍維奇（人名）】這樣的索引條目被標記為人吓肋，并將諸如Yugoslavia【南斯拉夫】和Serbia【塞爾維亞】等條目標記為國家。
第8步：檢索詞權(quán)重分配瑰艘。權(quán)重分配給索引文件中的檢索詞是鬼。最簡單的搜索引擎只分配二進制權(quán)重：1表示存在肤舞，0表示沒有。搜索引擎越復(fù)雜均蜜，加權(quán)方案就越復(fù)雜李剖。測量文檔中檢索詞出現(xiàn)的頻率會產(chǎn)生更復(fù)雜的加權(quán)，頻率的長度歸一化更復(fù)雜囤耳。多年來在信息檢索研究方面的豐富經(jīng)驗清楚地表明篙顺，最佳權(quán)重來自于使用“tf / idf”。該算法測量文檔中每個檢索詞的出現(xiàn)頻率紫皇。 然后慰安，它將該頻率與整個數(shù)據(jù)庫中出現(xiàn)的頻率進行比較。
并非所有檢索詞都是好的“鑒別器” — 也就是說聪铺，所有檢索詞都不會很好地從另一個文檔中挑出一個文檔化焕。一個簡單的例子就是“the”這個詞。這個詞出現(xiàn)在太多的文件中铃剔，以幫助區(qū)分彼此撒桨。一個不太明顯的例子是“antibiotic【抗生素】”這個詞。 在體育數(shù)據(jù)庫中键兜，我們將每個文檔與整個數(shù)據(jù)庫進行較凤类，“antibiotic【抗生素】”一詞可能是文件中的一個很好的鑒別者，因此會被賦予很高的權(quán)重普气。相反谜疤，在專門用于健康或醫(yī)學的數(shù)據(jù)庫中，“antibiotic【抗生素】”可能是一種差的鑒別因素现诀，因為它經(jīng)常出現(xiàn)夷磕。TF / IDF加權(quán)方案為那些真正區(qū)分一個文檔與其他文檔的檢索詞分配了更高的權(quán)重。
第9步：創(chuàng)建索引仔沿。索引或反向索引文件是存儲索引信息的內(nèi)部數(shù)據(jù)結(jié)構(gòu)坐桩，將被每個查詢搜索到。反向索引文件的范圍從一組索引的文檔/頁面中的每個字母數(shù)字序列的簡單列表封锉，以及序列發(fā)生的文檔的整體識別號绵跷，更復(fù)雜的條目列表，tf / idf權(quán)重成福，以及指向術(shù)語每個文檔內(nèi)部位置的指針碾局。索引中的信息越完整，搜索結(jié)果就越好奴艾。
查詢處理器
查詢處理有七個可能的步驟擦俐，盡管系統(tǒng)可以縮短這些步驟并在處理期間將查詢匹配到多個位置中的任何一處反向索引文件。文檔處理與查詢處理共享許多步驟握侧。更多的步驟和更多的文檔使得該過程在計算資源和響應(yīng)性方面的處理更加昂貴蚯瞧。但是，等待結(jié)果的時間越長品擎，結(jié)果的質(zhì)量就越高埋合。因此，搜索系統(tǒng)設(shè)計者必須選擇對用戶最重要的東西 - 時間或質(zhì)量萄传。公開可用的搜索引擎通常更多選擇的時間而不是質(zhì)量甚颂，因為有太多要搜索的文檔了。
查詢處理中的步驟如下（使用選項停止處理并開始匹配秀菱，表示為“Matcher【匹配程序】”）：
- 標記【Tokenize】查詢檢索詞振诬。
識別查詢檢索詞與特殊運算符。
————————> Matcher - 刪除停用詞衍菱。
- 詞根化單詞赶么。
- 創(chuàng)建查詢表示
————————> Matcher - 展開查詢檢索詞
- 計算權(quán)重。
————————> Matcher
第1步：標記【Tokenizing】脊串。用戶輸入查詢后立即搜索引擎 — 無論是基于關(guān)鍵字的系統(tǒng)還是完整的自然語言處理（NLP）系統(tǒng) — 必須將查詢流標記化辫呻，即，將其分解為可理解的部分琼锋。通常放闺，token被定義為在空格和/或標點符號之間出現(xiàn)的字母數(shù)字字符串。
第2步：解析缕坎。由于用戶可以在其查詢中使用特殊運算符怖侦，包括布爾運算符，鄰接運算符或鄰近運算符谜叹，因此系統(tǒng)需要首先將查詢解析為查詢項和運算符匾寝。這些運算符可以以保留標點符號（例如，引號）或?qū)Ｓ酶袷降谋Ａ粜g(shù)語（例如叉谜，AND旗吁，OR）的形式出現(xiàn)。在NLP系統(tǒng)的情況下停局，無論如何表達運算符（例如很钓，介詞，連詞董栽，排序）码倦，查詢處理器將隱式地識別所使用的語言中的運算符。
此時锭碳，搜索引擎可以獲取查詢術(shù)語列表并針對倒排索引文件搜索它們袁稽。 事實上，這是大多數(shù)公開搜索引擎執(zhí)行搜索的點擒抛。
第3和4步：停止列表和詞干提取【 Stop list and stemming】推汽。一些搜索引擎會更進一步补疑，停止列表并阻止查詢，類似于上面文檔處理器部分中描述的過程歹撒。停止列表還可能包含常見查詢短語中的單詞莲组，例如“我想了解有關(guān)的信息【I'd like information about】”。然而暖夭，由于大多數(shù)公開可用的搜索引擎鼓勵非常短的查詢锹杈，如所提供的查詢窗口的大小所示，引擎可能會放棄這兩個步驟迈着。
第5步：創(chuàng)建查詢竭望。每個特定搜索引擎如何創(chuàng)建查詢表示取決于系統(tǒng)如何進行匹配。 如果使用基于統(tǒng)計的匹配器裕菠，則查詢必須與系統(tǒng)中文檔的統(tǒng)計表示相匹配咬清。好的統(tǒng)計查詢應(yīng)該包含許多同義詞和其他查詢詞，以便創(chuàng)建完整的表示糕韧。如果使用布爾匹配器枫振，則系統(tǒng)必須創(chuàng)建由AND，OR或NOT連接的術(shù)語的邏輯集萤彩。
NLP系統(tǒng)將識別單個術(shù)語粪滤，短語和命名實體。 如果它使用任何布爾邏輯雀扶，它還將識別步驟2中的邏輯運算符杖小，并創(chuàng)建包含AND'd，OR'd或NOT'd的術(shù)語邏輯集的表示愚墓。
此時予权，搜索引擎可以采用查詢表示并針對反向索引文件執(zhí)行搜索。 更高級的搜索引擎可能需要兩個步驟浪册。
第6步：查詢擴展扫腺。 由于搜索引擎的用戶通常只在查詢中包含他們信息需求的單個陳述，因此很可能他們需要的信息可以使用同義詞來表達村象，而不是搜索引擎搜索的文檔中的確切查詢詞笆环。因此，更復(fù)雜的系統(tǒng)可能會將查詢擴展為所有可能的同義詞厚者，甚至可能的更廣和更窄的術(shù)語躁劣。
這個過程接近搜索中介在早期商業(yè)搜索系統(tǒng)中為最終用戶所做的事情。當時库菲，中介可能使用了將主題描述符分配給文檔的索引器所使用的相同受控詞匯表或詞庫账忘。今天，WordNet等資源通常是可用的，或?qū)ｉT的擴展設(shè)施可以采取初始查詢并通過添加相關(guān)詞匯來擴大它鳖擒。
第7步：查詢檢索詞【term】加權(quán)（假設(shè)多個查詢檢索詞）溉浙。查詢處理的最后一步涉及計算查詢中查詢詞的權(quán)重。有時蒋荚，用戶通過指示每個查詢詞的權(quán)重或者簡單地查詢中哪個查詢詞來控制該步驟放航，或查詢中的概念最重要，并且必須出現(xiàn)在每個檢索到的文檔中以確保相關(guān)性圆裕。
將權(quán)重留給用戶并不常見，因為研究表明用戶并不是特別擅長確定術(shù)語在查詢中的相對重要性荆几。由于幾個原因吓妆，他們不能做出這個決定。 首先吨铸，他們不知道數(shù)據(jù)庫中還有什么行拢，并且通過與整個數(shù)據(jù)庫進行比較來對文檔術(shù)語進行加權(quán)。其次诞吱，大多數(shù)用戶尋求有關(guān)不熟悉主題的信息舟奠，因此他們可能不知道正確的術(shù)語。
很少有搜索引擎實現(xiàn)基于系統(tǒng)的查詢加權(quán)房维，但有些搜索引擎通過將查詢中的第一項視為具有更高的重要性來進行隱式加權(quán)沼瘫。 引擎使用此信息向用戶提供文檔/頁面列表。
在最后一步之后咙俩，針對文檔的反向索引文件搜索擴展的加權(quán)查詢耿戚。
搜索和匹配功能
系統(tǒng)如何執(zhí)行其搜索和匹配功能有所不同，信息檢索的理論模型是系統(tǒng)設(shè)計理念的基礎(chǔ)阿趁。由于這些模型之間的區(qū)別遠遠超出了本文的目標膜蛔，因此我們將在以下搜索和匹配功能的描述中進行一些廣泛的概括。那些對進一步細節(jié)感興趣的人可以參考R. Baeza-Yates和B. Ribeiro-Neto關(guān)于IR的卓越的教科書（Modern Information Retrieval脖阵，Addison-Wesley皂股，1999）。
在倒排索引文件中搜索滿足查詢要求的文檔命黔，簡稱為“匹配【matching】”呜呐，通常是標準二進制搜索，無論搜索是在查詢處理的前兩個纷铣，五個還是所有七個步驟之后結(jié)束卵史。雖然簡單的，未加權(quán)的非布爾查詢匹配所需的計算處理比加權(quán)內(nèi)的基于NLP的查詢模型簡單得多搜立，布爾模型以躯，它也遵循文檔表示更簡單，查詢表示和匹配算法，結(jié)果相關(guān)性較小忧设，刁标，除了非常簡單的查詢，例如尋求最普遍已知信息的單字址晕，非模糊查詢膀懈。
在某種程度上確定了哪個文檔或頁面子集符合查詢要求，基于系統(tǒng)使用的評分算法谨垃，在查詢和每個文檔/頁面之間計算相似性得分启搂。評分算法排名基于查詢詞的存在/不存在，檢索詞頻率刘陶，tf / idf胳赌，布爾邏輯實現(xiàn)或查詢詞權(quán)重。
一些搜索引擎使用的評分算法不是基于文檔內(nèi)容的匙隔，而是基于文件之間的關(guān)系或過去的文件/頁面的檢索歷史疑苫。
在計算文檔子集中的每個文檔的相似性之后，系統(tǒng)向用戶呈現(xiàn)有序列表纷责。文件排序的復(fù)雜程度又取決于系統(tǒng)使用的模型捍掺，以及文檔和查詢加權(quán)機制的豐富性。例如再膳，搜索引擎挺勿，只需要查詢的字母數(shù)字在任何地方出現(xiàn)的地方，在任何順序中饵史，在文檔中將產(chǎn)生與搜索引擎非常不同的排名满钟，搜索引擎在語言上糾正文檔和查詢表示的措辭，并使用經(jīng)過驗證的tf / idf加權(quán)方案胳喷。
但是搜索引擎決定排名湃番，排名結(jié)果列表發(fā)送給用戶，然后用戶只需單擊并按照系統(tǒng)的內(nèi)部指針指向所選文檔/頁面吭露。
更復(fù)雜的系統(tǒng)將在此階段進一步發(fā)展吠撮，并允許用戶提供一些相關(guān)性反饋或根據(jù)他們看到的結(jié)果修改他們的查詢。如果其中任何一個可用讲竿，然后泥兰，系統(tǒng)將調(diào)整其查詢結(jié)果以反映此增值反饋，并使用改進的查詢重新運行搜索题禀，使用改進的查詢來生成一組新文檔或從初始搜索中對文檔進行簡單的重新排序鞋诗。
哪些文檔特征與查詢匹配良好
我們已經(jīng)討論了搜索引擎的工作原理，但是查詢的哪些功能可以實現(xiàn)良好的匹配迈嘹？讓我們看一下關(guān)鍵特性削彬，并考慮它們在幫助檢索文檔/頁面的良好表現(xiàn)方面的一些優(yōu)點和缺點全庸。
- 檢索詞頻率：查詢檢索詞在文檔中出現(xiàn)的頻率是確定文檔與查詢相關(guān)性的最明顯方法之一。雖然大多數(shù)情況下是這樣的融痛，有幾種情況可以破壞這個前提壶笼。首先，許多單詞具有多重含義 - 它們是多義的雁刷。例如這樣的詞"pool"或者”fire“覆劈。呈現(xiàn)給用戶的許多不相關(guān)文檔來自匹配正確的單詞，但具有錯誤的含義沛励。
此外责语，在特定域中的文檔集合中，例如教育【education】目派，諸如“教育【education】”或“教學【teaching】”之類的常見查詢術(shù)語是如此常見并且如此頻繁地發(fā)生鹦筹，引擎區(qū)分集合中相關(guān)與不相關(guān)的能力會急劇下降。不使用tf / idf加權(quán)算法的搜索引擎不會對過于頻繁的術(shù)語進行適當?shù)臏p重址貌，也沒有將更高的權(quán)重分配給適當?shù)膮^(qū)分（和不常發(fā)生的）檢索詞，例如“早期童年【early-childhood】”徘键。
- 檢索詞的位置：許多搜索引擎優(yōu)先考慮標題或引導段落或文檔元數(shù)據(jù)中的單詞练对。一些研究表明，一個術(shù)語出現(xiàn)在文檔或頁面上的位置 - 表明它對文件的重要性吹害。因此螟凭，在與查詢檢索詞匹配的文檔或頁面的標題中出現(xiàn)的檢索詞的權(quán)重通常比在文檔正文中出現(xiàn)的檢索詞更重要。類似地它呀，在章節(jié)標題或文檔的第一段中出現(xiàn)的檢索詞更有可能是相關(guān)的螺男。
鏈接分析：基于網(wǎng)絡(luò)的搜索引擎為頁面加權(quán)和排名引入了一個截然不同的功能。鏈接分析有點像書目引用實踐纵穿，例如Science Citation Index使用的那些下隧。鏈接分析基于每個頁面的良好連接，如Hubs和Authorities所定義的那樣谓媒，Hub文檔鏈接到大量其他頁面（out-links）淆院，Authority文檔是許多其他頁面引用的文檔，或者具有大量“in-links” (J. Kleinberg, "Authoritative Sources in a Hyperlinked Environment," Proceedings of the 9th ACM-SIAM Symposium on Discrete Algorithms. 1998,pp. 668-77).
流行度：谷歌和其他幾個搜索引擎增加了鏈接分析的流行度句惯，以幫助確定頁面的相關(guān)性或價值土辩。受歡迎程度利用所有用戶選擇頁面的頻率數(shù)據(jù)作為預(yù)測相關(guān)性的手段。雖然流行度有時是一個很好的指標抢野，但它假設(shè)基礎(chǔ)信息需求保持不變拷淘。
公布日期：一些搜索引擎假設(shè)信息越新，它就越有可能對用戶有用或相關(guān)指孤。因此启涯，搜索引擎呈現(xiàn)的是離現(xiàn)在最近的結(jié)果。
長度：雖然長度本身不一定預(yù)測相關(guān)性，它是用于計算類似頁面的相對價值的一個因素逝嚎。因此扁瓢，在兩個包含相同查詢檢索詞的文檔之間進行選擇，假定包含相對于文檔長度的檢索詞出現(xiàn)比例較高的文檔更可能是相關(guān)的补君。
查詢檢索詞的接近程度：當查詢中的檢索詞在文檔中彼此接近時引几，文檔與查詢相關(guān)的可能性大于檢索詞距離比較遠的情況。雖然有些搜索引擎在查詢中無法識別短語本身挽铁，如果查詢檢索詞彼此相鄰或者距離很近伟桅，與檢索詞在文檔中距離很遠相比，某些搜索引擎會在結(jié)果中對文檔進行更高的排名叽掘。
專有名詞:因為對人楣铁，地點或事物進行了如此多的搜索,有時會有更高的權(quán)重。雖然這可能很有用更扁，但如果搜索引擎假設(shè)您正在搜索名稱而不是與正常日常檢索詞相同的單詞盖腕，則搜索結(jié)果可能會偏差特別大。想象一下浓镜，當你在為藝術(shù)史課尋找madonnas的照片時溃列，會獲取搖滾明星“madonnas【麥當娜】”的信息。
總結(jié)
上面的解釋列出了搜索引擎中可能出現(xiàn)的處理范圍膛薛，以及哪些選項影響搜索引擎提供商做決定听隐。選項范圍可能有助于改善用戶對查詢返回結(jié)果的頻繁驚訝。到目前為止哄啄，搜索引擎提供商主要選擇較少的雅任，而不是更復(fù)雜的文檔和查詢處理。因此咨跌，典型的搜索結(jié)果需要搜索者做很多工作沪么，搜索者必須在搜索結(jié)果之前，點擊并瀏覽一些文檔锌半，然后才能確切地找到他們所尋求的內(nèi)容成玫。產(chǎn)品和服務(wù)的典型演變表明，這種現(xiàn)狀不會繼續(xù)下去拳喻。進一步提高處理復(fù)雜性和質(zhì)量的搜索引擎將得到搜索者的更大忠誠哭当，另外搜索引擎會得到更多的經(jīng)濟回報機會。
搜索者應(yīng)該持續(xù)關(guān)注最好的搜索結(jié)果并追求它冗澈。
