引言

首先，所謂“搜尋引擎”，說到底是一個網路應用軟體系統。從網路使用者的角度看，它根據使用者提交的類自然語言查詢詞或者短語，返回一系列很可能與該查詢相關的網頁資訊，供使用者進一步判斷和選取。為了有效地做到這一點，它大致上被分成三個功能模組，或者三個子系統；即網頁蒐集，預處理和查詢服務，這三個部分是相對獨立的，它們的工作形成了搜尋引擎工作的三個階段。

基本要求

如前述，搜尋引擎是一個網路應用軟體系統，對它有如下基本要求：

能夠接受使用者通過瀏覽器提交的查詢詞或者短語，記作q，例如“非典”，“伊拉克戰爭”，“床前明月光”等等。在一個 可以接受的時間內 返回一個和該使用者查詢 匹配 的網頁資訊 列表 ，記作L。這個列表的每一條目至少包含三個元素（標題，網址連結，摘要）。

這裡有三個問題需要注意，分別對應以上的黑體字：

“可以接受的時間”，也就是響應時間。對於在Web上面向廣大使用者提供服務的軟體來說，這個時間不能太長。這是衡量搜尋引擎可用性的一個基本指標，也是和傳統資訊檢索系統的一個差別。更進一步的，這樣的響應時間要求不僅要能滿足單個使用者查詢，而且要能在系統設計負載的情況下滿足所有的使用者。也就是說，系統應該在額定吞吐率的情況下保證秒級響應時間。

“匹配”，指的是網頁中以某種形式包含有q的內容，其中最簡單、最常見的形式就是q在其中直接出現。不過如果一個搜尋引擎就是以百分之百滿足這種簡單的包含關係為目標，即使實現了也並不就達到了最好的效果。

“列表”這蘊含著一種“序”（rank）。在絕大多數情況下，L是相當長的，例如超過一萬個條目（這是和圖書館全文檢索系統的又一個不同，那裡返回的列表通常較短，例如幾十個條目）。這不僅是由於Web上的資訊量大，也由於搜尋引擎的查詢方式簡單。簡單，意味著抽象；抽象，意味著有更多的具體事物可能是它的體現。對於一個長長的列表，很少有使用者有耐心都審視一遍（不僅是因為長，還因為大多數使用搜索引擎的使用者通常都是“找到為止”，而不是“不全部找到不罷休”，加上這個列表中和一個使用者關心的其實只佔很少的比例）。有分析統計表明，使用者平均察看返回結果不超過2頁。

現代大規模高質量搜尋引擎一般採用如下圖所示的稱之為三段式的工作流程，即：網頁蒐集、預處理和查詢服務。

網頁採集

搜尋引擎這樣一個軟體系統應該是以何種方式工作？如果說軟體系統是工作在某個資料集合上的程式的話，這個軟體系統操作的資料不僅包括內容不可預測的使用者查詢，還要包括在數量上動態變化的海量網頁，並且這些網頁不會主動送到系統來，而是需要由系統去抓取。

首先，我們考慮抓取的時機：事先還是即時。我們都有經驗，在網路比較暢通的情況下，從網上下載一篇網頁大約需要1秒鐘左右，因此如果在使用者查詢的時候即時去網上抓來成千上萬的網頁，一個個分析處理，和使用者的查詢匹配，不可能滿足搜尋引擎的響應時間要求。不僅如此，這樣做的系統效益也不高（會重複抓取太多的網頁）；面對大量的使用者查詢，不可能想象每來一個查詢，系統就到網上“搜尋”一次。 因此我們看到，大規模搜尋引擎服務端基礎應該是一批預先蒐集好的網頁（直接或間接）。這一批網頁如何維護？可以有兩種基本的考慮。

定期蒐集，每次蒐集替換上一次的內容，我們稱之為“批量蒐集”。由於每次都是重新來一次，對於大規模搜尋引擎來說，每次蒐集的時間通常會花幾周。而由於這樣做開銷較大，通常兩次蒐集的間隔時間也不會很短（例如早期天網的版本大約每3個月來一次，Google在一段時間曾是每隔28天來一次）。這樣做的好處是系統實現比較簡單，主要缺點是“時新性”（freshness）不高，還有重複蒐集所帶來的額外頻寬的消耗。

增量蒐集，開始時蒐集一批，往後只是（1）蒐集新出現的網頁，（2）蒐集那些在上次蒐集後有過改變的網頁，（3）發現自從上次蒐集後已經不再存在了的網頁，並從庫中刪除。由於除新聞網站外，許多網頁的內容變化並不是很經常的（有研究指出50%網頁的平均生命週期大約為50天），這樣做每次蒐集的網頁量不會很大，於是可以經常啟動蒐集過程（例如每天）。30萬網頁，一臺PC機，在一般的網路條件下，半天也就蒐集完了。這樣的系統表現出來的資訊時新性就會比較高，主要缺點是系統實現比較複雜；這種複雜還不僅在於蒐集過程，而是還在於下面要談到的建索引的過程。

上面講的是系統網頁資料庫維護的基本策略。在這兩種極端的情況之間也可能有一些折中的方案，J. Cho博士在這方面做過深入的研究，根據一種網頁變化模型和系統所含內容時新性的定義，提出了相應優化的網頁蒐集策略。其中一個有趣的結論是：在系統蒐集能力一定的情況下，若有兩類網頁（例如“商業”和“教育”），它們的更新週期差別很大（例如“商業”類網頁平均更新週期是“天”，而“教育”類網頁平均更新週期是“月”），則系統應該將注意力放在更新慢的網頁上，以使系統整體的時新性達到比較高的取值。

在具體蒐集過程中，如何抓取一篇篇的網頁，也可以有不同的考慮。最常見的一種是所謂“爬取”：將Web上的網頁集合看成是一個有向圖，蒐集過程從給定起始URL集合S（或者說“種子”）開始，沿著網頁中的連結，按照先深、先寬、或者某種別的策略遍歷，不停的從S中移除URL，下載相應的網頁，解析出網頁中的超連結URL，看是否已經被訪問過，將未訪問過的那些URL加入集合S。整個過程可以形象地想象為一個蜘蛛（spider）在蜘蛛網（Web）上爬行（crawl）。後面我們會看到，真正的系統其實是多個“蜘蛛”同時在爬。

這種方式的好處除了概念很漂亮，一般實現起來也不困難外，還有很重要的一條是容易通過一定的策略，使蒐集到的網頁相對比較“重要”。前面提過，任何搜尋引擎是不可能將Web上的網頁蒐集完全的，通常都是在其他條件的限制下決定蒐集過程的結束（例如磁碟滿，或者蒐集時間已經太長了）。因此就有一個儘量使搜到的網頁比較重要的問題，這對於那些並不追求很大的數量覆蓋率的搜尋引擎特別重要。研究表明，按照先寬搜尋方式得到的網頁集合要比先深搜尋得到的集合重要（這裡當然有一個重要性的指標問題）。這種方式的一個困難是要從每一篇網頁中提取出所含的URL。由於HTML的靈活性，其中出現URL 的方式各種各樣，將這個環節做得徹底不容易（例如我們現在還沒有很好的簡單辦法從JavaScript指令碼中提取URL）。同時，由於Web的“蝴蝶結” 形狀這種方式蒐集到的網頁不大會超過所有目標網頁數量2的2/3。

另外一種可能的方式是在第一次全面網頁蒐集後，系統維護相應的URL集合S，往後的蒐集直接基於這個集合。每搜到一個網頁，如果它發生變化並含有新的URL，則將它們對應的網頁也抓回來，並將這些新URL也放到集合S中；如果S中某個url對應的網頁不存在了，則將它從S中刪除。這種方式也可以看成是一種極端的先寬搜尋，即第一層是一個很大的集合，往下最多隻延伸一層。 還有一種方法是讓網站擁有者主動向搜尋引擎提交它們的網址（為了宣傳自己，通常會有這種積極性），系統在一定時間內（2天到數月不等）定向向那些網站派出 “蜘蛛”程式，掃描該網站的所有網頁並將有關資訊存入資料庫中。大型商業搜尋引擎一般都提供這種功能。

預處理

得到海量的原始網頁集合，距離面向網路使用者的檢索服務之間還有相當的距離。巨集觀地看，服務子系統是一個程式。採用Wirth關於“程式 = 演算法+資料結構”的觀點來考察這個程式，一個合適的資料結構是查詢子系統工作的核心和關鍵。這裡只是指出：現行最有效的資料結構是“倒排檔案” （inverted file）；倒排檔案是用文件中所含關鍵詞作為索引，文件作為索引目標的一種結構（類似於普通書籍中，索引是關鍵詞，書的頁面是索引目標）。下面以 常規全文搜尋引擎 為例討論從網頁集合形成這樣的倒排檔案過程中的幾個主要問題，即我們所說的 “預處理”。主要包括四個方面，關鍵詞的提取，“映象網頁”（網頁的內容完全相同，未加任何修改）或“轉載網頁”（near-replicas，主題內容基本相同但可能有一些額外的編輯資訊等，轉載網頁也稱為“近似映象網頁”）的消除，連結分析和網頁重要程度的計算。

關鍵詞的提取

隨便取一篇網頁的原始檔（例如通過瀏覽器的“檢視原始檔”功能），我們可以看到其中的情況紛亂繁雜。除了我們從瀏覽器中能夠正常看到的文字內容外，還有大量的HTML標記。根據天網統計，網頁文件原始檔的大小（位元組量）通常大約是其中內容大小的4倍。另外，由於HTML文件產生來源的多樣性，許多網頁在內容上比較隨意，不僅文字不講究規範、完整，而且還可能包含許多和主要內容無關的資訊（例如廣告，導航條，版權說明等）。這些情況既給有效的資訊查詢帶來了挑戰，也帶來了一些新的機遇。這裡我們只是指出，為了支援後面的查詢服務，需要從網頁原始檔中提取出能夠代表它的內容的一些特徵。從人們現在的認識和實踐來看，所含的關鍵詞即為這種特徵最好的代表。於是，作為預處理階段的一個基本任務，就是要提取出網頁原始檔的內容部分所含的關鍵詞。對於中文來說，就是要根據一個詞典Σ，用一個所謂“切詞軟體”，從網頁文字中切出Σ所含的詞語來。在那之後，一篇網頁主要就由一組詞來近似代表了，p = {t1, t2, …, tn}。一般來講，我們可能得到很多詞，同一個詞可能在一篇網頁中多次出現。從效果(effectiveness)和效率（efficiency）考慮，不應該讓所有的詞都出現在網頁的表示中，要去掉諸如“的”，“在”等沒有內容指示意義的詞，稱為“停用詞”(stop word)。這樣，對一篇網頁來說，有效的詞語數量大約在200個左右。

重複或轉載網頁的消除

與生俱來的數字化和網路化給網頁的複製以及轉載和修改再發錶帶來了便利，因此我們看到Web上的資訊存在大量的重複現象。天網在2003年的一次大規模統計分析表明，網頁的重複率平均大約為4。也就是說，當你通過一個URL在網上看到一篇網頁的時候，平均還有另外3個不同的URL也給出相同或者基本相似的內容。這種現象對於廣大的網民來說是有正面意義的，因為有了更多的資訊訪問機會。但對於搜尋引擎來說，則主要是負面的；它不僅在蒐集網頁時要消耗機器時間和網路頻寬資源，而且如果在查詢結果中出現，無意義地消耗了計算機顯示屏資源，也會引來使用者的抱怨，“這麼多重複的，給我一個就夠了”。因此，消除內容重複或主題內容重複的網頁是預處理階段的一個重要任務。

連結分析

前面提到，大量的HTML標記既給網頁的預處理造成了一些麻煩，也帶來了一些新的機遇。從資訊檢索的角度講，如果系統面對的僅僅是內容的文字，我們能依據的就是“共有詞彙假設”（shared bag of words），即內容所包含的關鍵詞集合，最多加上詞頻（term frequency 或tf、TF）和詞在文件集合中出現的文件頻率（document frequency 或df、DF）之類的統計量。而TF和DF這樣的頻率資訊能在一定程度上指示詞語在一篇文件中的相對重要性或者和某些內容的相關性，這是有意義的。有了 HTML標記後，情況還可能進一步改善，例如在同一篇文件中，<H1>和</H1>之間的資訊很可能就比在<H4> 和</H4>之間之間的資訊更重要。特別地，HTML文件中所含的指向其他文件的連結資訊是人們近幾年來特別關注的物件，認為它們不僅給出了網頁之間的關係，而且還對判斷網頁的內容有很重要的作用。例如“北大學報”這幾個字在北京大學學報社會科學版的主頁上是沒有的，因此一個僅靠內容文字分析的搜尋引擎就不可能返回該主頁作為結果。但是北京大學主頁上是用“北大學報（社）”作為連結資訊指向了北京大學學報社會科學版的主頁。因此在很好利用連結資訊的搜尋引擎中應該能返回北京大學學報社會科學版的主頁。

網頁重要程度的計算

搜尋引擎返回給使用者的，是一個和使用者查詢相關的結果列表。列表中條目的順序是很重要的一個問題。由於面對各種各樣的使用者，加之查詢的自然語言風格，對同樣的q0返回相同的列表肯定是不能使所有提交q0的使用者都滿意的（或者都達到最高的滿意度）。因此搜尋引擎實際上追求的是一種統計意義上的滿意。人們認為Google目前比天網好，是因為在多數情況下前者返回的內容要更符合使用者的需要，而不是所有情況下都如此。如何對查詢結果進行排序有很多因素需要考慮，這裡只是概要解釋在預處理階段可能形成的所謂“重要性”因素。顧名思義，既然是在預處理階段形成的，就是和使用者查詢無關的。如何講一篇網頁比另外一篇網頁重要？人們參照科技文獻重要性的評估方式，核心想法就是“被引用多的就是重要的”。“引用”這個概念恰好可以通過HTML超鏈在網頁之間體現得非常好，作為Google創立核心技術的PageRank就是這種思路的成功體現。除此以外，人們還注意到網頁和文獻的不同特點，即一些網頁主要是大量對外的連結，其本身基本沒有一個明確的主題內容，而另外有些網頁則被大量的其他網頁連結。從某種意義上講，這形成了一種對偶的關係，這種關係使得人們可以在網頁上建立另外一種重要性指標。這些指標有的可以在預處理階段計算，有的則要在查詢階段計算，但都是作為在查詢服務階段最終形成結果排序的部分引數。

查詢服務

如上述，從一個原始網頁集合S開始，預處理過程得到的是對S的一個子集的元素的某種內部表示，這種表示構成了查詢服務的直接基礎。對每個元素來說，這種表示至少包含如下幾個方面：

• 原始網頁文件
• URL和標題
• 編號
• 所含的重要關鍵詞的集合（以及它們在文件中出現的位置資訊）
• 其他一些指標（例如重要程度，分類程式碼等）

而系統關鍵詞總體的集合和文件的編號一起構成了一個倒排檔案結構，使得一旦得到一個關鍵詞輸入，系統能迅速給出相關文件編號的集合輸出。然而，如同我們在之前提到的，使用者通過搜尋引擎看到的不是一個“集合”，而是一個“列表”。如何從集合生成一個列表，是服務子系統的主要工作。從搜尋引擎系統功能劃分的角度，有時候將倒排檔案的生成也作為服務子系統的一部分功能，但我們這裡將它劃分到預處理階段中覺得更方便些。換句話講，服務子系統是在服務進行的過程中涉及的相關軟體程式，而為這些軟體程式事先準備資料的程式都算在預處理子系統中。下面來看對服務子系統的要求和其工作原理，主要有三個方面。

查詢方式和匹配

查詢方式指的是系統允許使用者提交查詢的形式。考慮到各種使用者的不同背景和不同的資訊需求，不可能有一種普適的方式。一般認為，對於普通網路使用者來說，最自然的方式就是“要什麼就輸入什麼”。但這是一種相當模糊的說法。例如使用者輸入“北京大學”，可能是他想了解北京大學目前有些什麼資訊向外釋出，想看看今年的招生政策（於是希望看的是北大網站上的內容），也可能是他想了解外界目前對北京大學有些什麼評價（於是希望看到的是其他權威網站上關於北大的訊息）。這是兩種相當不同的需求。在其他一些情況下，使用者可能關心的是間接資訊，例如“喜馬拉雅山的高度”，8848米應該是他需要的，但不可能包含在這短語中。而使用者輸入“驚起一灘鷗鷺”則很可能是想知道該詞的作者是誰，或者希望能提醒前面幾句是什麼。儘管如此，用一個詞或者短語來直接表達資訊需求，希望網頁中含有該詞或者該短語中的詞，依然是主流的搜尋引擎查詢模式。這不僅是因為它的確代表了大多數的情況，還因為它比較容易實現。這樣，一般來講，系統面對的是查詢短語。就英文來說，它是一個詞的序列；就中文來說，它是包含若干個詞的一段文字。一般地，我們用q0表示使用者提交的原始查詢，例如，q0 =“網路與分散式系統實驗室”。它首先需要被“切詞”（segment）或稱“分詞”，即把它分成一個詞的序列。如上例，則為“網路 與 分散式 系統 實驗室”（注意，不同的分詞軟體可能得出不同的結果，這裡用的是北大計算語言所的線上分詞軟體）。然後需要刪除那些沒有查詢意義或者幾乎在每篇文件中都會出現的詞（例如“的”），在本例中即為“與”。最後形成一個用於參加匹配的查詢詞表，q = {t1, t2, …, tm}，在本例中就是q = {網路，分散式，系統，實驗室}。前面講過，倒排檔案就是用詞來作為索引的一個數據結構，顯然，q中的詞必須是包含在倒排檔案詞表中才有意義。有了這樣的 q，它的每一個元素都對應倒排檔案中的一個倒排表（文件編號的集合），記作L(ti)，它們的交集即為對應查詢的結果文件集合，從而實現了查詢和文件的匹配。上述過程的基本假設是：使用者是希望網頁包含所輸入查詢文字的。

結果排序

上面，我們瞭解了得到和使用者查詢相關的文件集合的過程。這個集合的元素需要以一定的形式通過計算機顯示屏呈現給使用者。就目前的技術情況看，列表是最常見的形式（但人們也在探求新的形式，如Vivisimo 引擎將結果頁面以類別的形式呈現）。給定一個查詢結果集合，R={r1, r2, …, rn}，所謂列表，就是按照某種評價方式，確定出R中元素的一個順序，讓這些元素以這種順序呈現出來。籠統地講，ri和q的相關性（relevance）是形成這種順序的基本因素。但是，有效地定義相關性本身是很困難的，從原理上講它不僅和查詢詞有關，而且還和使用者的背景，以及使用者的查詢歷史有關。不同需求的使用者可能輸入同一個查詢，同一個使用者在不同的時間輸入的相同的查詢可能是針對不同的資訊需求。為了形成一個合適的順序，在搜尋引擎出現的早期人們採用了傳統資訊檢索領域很成熟的基於詞彙出現頻度的方法。大致上講就是一篇文件中包含的查詢（q）中的那些詞越多，則該文件就應該排在越前面；再精細一些的考慮則是若一個詞在越多的文件中有出現，則該詞用於區分文件相關性的作用就越小。這樣一種思路不僅有一定直覺上的道理，而且在倒排檔案資料結構上很容易實現。因為，當我們通過前述關鍵詞的提取過程，形成一篇文件的關鍵詞集合，p = {t1, t2, …, tn}的時候，很容易同時得到每一個ti在該文件中出現的次數，即詞頻，而倒排檔案中每個倒排表的長度則對應著一個詞所涉及的文件的篇數，即文件頻率。然而，由於網頁編寫的自發性、隨意性較強，僅僅針對詞的出現來決定文件的順序，在Web上做資訊檢索表現出明顯的缺點，需要有其他技術的補充。這方面最重要的成果就是前面提到過的PageRank。通過在預處理階段為每篇網頁形成一個獨立於查詢詞（也就和網頁內容無關）的重要性指標，將它和查詢過程中形成的相關性指標結合形成一個最終的排序，是目前搜尋引擎給出查詢結果排序的主要方法。

文件摘要

搜尋引擎給出的結果是一個有序的條目列表，每一個條目有三個基本的元素：標題，網址和摘要。其中的摘要需要從網頁正文中生成。一般來講，從一篇文字中生成一個恰當的摘要是自然語言理解領域的一個重要課題，人們已經做了多年的工作並取得了一些成果。但相關的技術用到網路搜尋引擎來有兩個基本困難。一是網頁的寫作通常不規範，文字比較隨意，因此從語言理解的角度難以做好；二是複雜的語言理解演算法耗時太多，不適應搜尋引擎要高效處理海量網頁資訊的需求。因此搜尋引擎在生成摘要時要簡便許多，基本上可以歸納為兩種方式，一是靜態方式，即獨立於查詢，按照某種規則，事先在預處理階段從網頁內容提取出一些文字，例如擷取網頁正文的開頭512個位元組（對應256個漢字），或者將每一個段落的第一個句子拼起來，等等。這樣形成的摘要存放在查詢子系統中，一旦相關文件被選中與查詢項匹配，就讀出返回給使用者。顯然，這種方式對查詢子系統來說是最輕鬆的，不需要做另外的處理工作。但這種方式的一個最大的缺點是摘要和查詢無關。一篇網頁有可能是多個不同查詢的結果，例如當用戶分別查詢“北大計算機網路”和“北大分散式系統”，"北大天網"在兩種情況下應該都作為結果返回。當用戶輸入某個查詢，他一般是希望摘要中能夠突出顯示和查詢直接對應的文字，希望摘要中出現和他關心的文字相關的句子。因此，我們有了“動態摘要”方式，即在響應查詢的時候，根據查詢詞在文件中的位置，提取出周圍的文字來，在顯示時將查詢詞標亮。這是目前大多數搜尋引擎採用的方式。為了保證查詢的效率，需要在預處理階段分詞的時候記住每個關鍵詞在文件中出現的位置。 除上述外，查詢服務返回的內容還有一些細節的支援。例如，對應一個查詢往往會有成千上萬的結果，返回給使用者的內容通常都是按頁組織的，一般每頁顯示 10個結果。統計表明，網路使用者一般沒有耐心一頁頁看下去，平均翻頁數小於2。這告訴我們將第一頁的內容組織好非常重要。如果希望使用者多用搜索引擎，就要讓第一頁的內容儘量有吸引力。

體系結構

在上述工作原理的基礎上，作為一個網路應用軟體，我們可以勾畫出搜尋引擎的體系結構，其中的大部分模組和前面的原理描述有直接的對應。這裡需要特別討論的是還沒有專門提及的“控制器”模組。網頁的蒐集，如果只是為了做些簡單的實驗，不過上萬篇網頁的話，許多矛盾都不會出現，可以用最簡單的工具（例如wget）完成。但如果是為了向大規模搜尋引擎穩定地提供網頁資料，通常需要每天蒐集上百萬網頁，而且是持續進行，情況則要複雜許多，核心是要綜合解決效率、質量和“禮貌”的問題。這就是“控制器”的作用。

所謂效率，在這裡就是如何利用盡量少的資源（計算機裝置、網路頻寬、時間）來完成預定的網頁蒐集量。在批量蒐集的場合，我們通常考慮半個月左右能蒐集到的網頁，自然是越多越好。由於網頁之間存在的獨立性，利用許多臺計算機同時來做這項工作是一個吸引人的想法。這裡需要指出三點：第一，即使是用一臺計算機來蒐集網頁，也應該注意併發性的開發和利用。由於從網上抓取一篇網頁通常需要秒量級的等待網路通訊時間，同時啟動多個抓取程序/執行緒，或者利用作業系統提供的非同步通訊機制，讓多個網路通訊時間重疊起來，讓網路通訊時間和存放網頁的磁碟訪問時間重疊起來是很有意義的。同時啟動抓取程序的數量取決於硬體條件和蒐集軟體的設計，一般情況下可以上百個，做得好也可能上千個（即上千個程序也不會造成CPU成為瓶頸）。

影響蒐集效率的另一點發生在網路的另一端，即伺服器方，它可能來不及提供所需的網頁。這除了有些Web伺服器所處的網路條件比較差，或者有太多其他人訪問外，搜尋引擎太頻繁對它們發出網頁請求也是一個重要原因。落實到技術上，就是要有一個訪問策略或者URL規劃，不要讓蒐集器啟動的抓取程序都集中在少數幾個網站上。

將蒐集活動的關注過分集中在幾個網站上，或者在一小段時間裡從一個網站抓取太多的網頁還可能引起其他的嚴重後果，即所謂“禮貌”問題。一般來講，網站的管理人員都很願意讓自己的網頁被搜尋引擎索引，從而有可能得到更多的訪問流量；但這只是問題的一方面。問題的另一方面是網站絕不希望由於搜尋引擎的“密集”抓取活動阻礙了普通使用者通過瀏覽器的訪問，使那些使用者得到這個網站訪問起來很困難的印象，從而不再光顧。不加控制的網頁抓取，給網站造成的現象有時候和製造拒絕服務（Denial of Servide, DoS）攻擊的黑客造成的現象一樣。因此，管理良好的網站常常會有一個監視器執行，監視是否有來源於單個IP地址的過分密集的訪問。一旦出現這種情況，要麼會通告該IP地址的擁有者注意行為，或者會乾脆遮蔽來自它的訪問，更有甚者還可能直接將該IP地址拉入黑名單。因此，適當地規劃網頁的抓取，限制單位時間內對一個網站抓取網頁的數量（例如每天不超過2萬個，或者至少每隔30秒才對同一個網站發出下一個網頁請求，等等），是大規模搜尋引擎必須要認真對待的問題。總之，搜尋引擎需要和網站“和睦相處”，它們是相互依存的。

所謂質量問題，指的是在有限的時間，蒐集有限的網頁，希望它們儘量是比較“重要”的網頁，或者說不要漏掉那些很重要的網頁。哪些網頁是比較重要的？也是仁者見仁，智者見智的，不可能有一個統一認可的標準。如果讓重要性和流行度等同起來，即越多人看過的網頁越重要，至少是直覺上有一定道理的。這樣，我們可以考慮一個網站從主頁開始向下，按照連結的深度將網頁組織成一層層的，上層中的網頁統計上會比下層的網頁重要些。這樣一種認識通過 PageRank得到了加強，即較靠近主頁的網頁通常PageRank值較高。這樣，首先得到儘量多的主頁，然後從主頁開始的先寬搜尋就應該是一個較好的策略。

網頁蒐集過程中還有一個基本的問題是要保證每個網頁不被重複抓取。由於一篇網頁可能被多篇網頁連結，在spider爬取過程中就可能多次得到該網頁的url。於是如果不加檢查和控制，網頁就會被多次抓取。遇到迴圈連結的情況，還會使爬取器陷死。解決這個問題的有效方法是使用兩個表，unvisited_table和visited_table。前者包含尚未訪問的url，後者記錄已訪問的url。系統首先將要蒐集的種子url放入unvisited_table，然後 spider從其中獲取要蒐集網頁的url，蒐集過的網頁url放入visited_table中，新解析出的並且不在visited_table中的 url加入unvisited_table。此方法簡單明瞭，適合在單個節點上實現。但是當蒐集子系統涉及到多個節點的時候，如何避免各個節點之間的重複工作就複雜了，還要考慮網路的通訊量、負載平衡、以及單個節點效能瓶頸等問題。

一般性指標

搜尋引擎可以歸結為資訊檢索問題，即在由網頁組成的文件集合中檢索出與使用者查詢相關的文件。因此，可用衡量傳統資訊檢索系統的效能引數—召回率（查全率／Recall）和精度（查準率／Precision）來衡量搜尋引擎的效能。

召回率指檢索出的相關文件數與文件集中所有的相關文件數的比率，它衡量檢索系統(搜尋引擎)的查全率。精度指檢索出的相關文件數與檢索出的文件總數的比率，它衡量檢索系統(搜尋引擎)的查準率。對於任一個檢索系統，召回率和精度都不可能兩全其美。召回率高，精度低。精度高，召回率低。對於搜尋引擎系統，由於一個查詢總能返回很多資訊，所以召回率一般不成問題。目前，搜尋引擎系統更關心精度，即是否為使用者提供了相關度很高的、高質量的導航資訊。

搜尋引擎系統其它的效能衡量指標還包括響應時間、支援峰值查詢能力、易用性、返回結果的有效性(是否為死鏈、重複、過時資訊)等。影響一個搜尋引擎系統性能的因素很多，主要集中在資訊蒐集策略和檢索模型，包括索引庫的更新頻率和策略、文件和查詢的表示方法、評價文件和使用者查詢相關性的匹配策略、查詢結果的排序方法和使用者進行相關度反饋的機制等。