搜索引擎-第二章:搜索引擎架構

什么是架構

本章介紹搜索引擎的基本軟件架構长豁。架構本身沒有公認的定義拓春,但通常由軟件組件、組件接口以及他們之間的關系組成钦听。架構用于描述特定級別的系統(tǒng)洒试。用于提供集成搜索和相關語言技術組件的標準的體系結構的示例是UIMA(非結構化信息管理體系結構).UIMA定義組件的接口,以簡化將新技術添加到處理文本和其他非結構化數據的系統(tǒng)中的過程朴上。

我們的搜索引擎架構用于提供系統(tǒng)重要組件及其之間關系的高級描述垒棋。 它不是代碼級描述,盡管某些組件確實對應于Galago搜索引擎和其他系統(tǒng)中的軟件模塊痪宰。 我們在本章和整本書中使用這種架構來為特定技術的討論提供背景叼架。

架構旨在確保系統(tǒng)滿足應用程序要求或目標。 搜索引擎的兩個主要目標是:

  • 有效性(質量):我們希望能夠檢索查詢可能的最相關文檔集衣撬。
  • 效率(速度):我們希望盡快處理用戶的查詢乖订。

我們也可能有更具體的目標,但通常這些目標屬于有效性或效率(或兩者)具练。 例如乍构,我們想要搜索的文檔集合可能正在發(fā)生變化; 確保搜索引擎立即對文檔中的更改做出反應既是有效問題,也是效率問題扛点。

搜索引擎的體系結構由這兩個要求決定哥遮。 因為我們需要一個高效的系統(tǒng),所以搜索引擎采用專為快速檢索而優(yōu)化的專用數據結構陵究。 因為我們需要高質量的結果眠饮,所以搜索引擎會仔細處理文本并存儲文本統(tǒng)計信息,以幫助提高結果的相關性铜邮。

我們在以下部分中討論的許多組件已經使用了幾十年仪召,并且這種一般設計已被證明是有效和高效檢索的競爭目標之間的有用折衷寨蹋。 在后面的章節(jié)中,我們將更詳細地討論這些組件扔茅。

基本構建模塊

搜索引擎組件支持兩個主要功能已旧,我們稱之為索引過程(indexing process)和查詢過程(query process)。索引過程構建了支持搜索的結構咖摹,查詢過程使用這些結構和人員的查詢來生成排序的文檔列表评姨。圖2.1顯示了索引過程的高級“構建塊”。主要組件是文本獲扔┣纭(text acquisition)吐句,文本轉換(text transformation)和索引創(chuàng)建(index creation)。

屏幕快照 2018-10-15 下午10.20.29.png

文本獲取組件的任務是識別和提供將被搜索的文檔店读。雖然在某些情況下這將涉及簡單地使用現有集合嗦枢,但文本獲取將更需要通過爬網或掃描Web,企業(yè)內部網屯断,桌面或其他信息源來構建集合文虏。除了在索引過程中將文檔傳遞給下一個組件外,文本獲取組件還會創(chuàng)建一個文檔數據存儲殖演,其中包含所有文檔的文本和元數據(metadata)氧秘。元數據是關于不是文本內容的一部分的文檔的信息,諸如文檔類型(例如趴久,電子郵件或網頁)丸相,文檔結構和諸如文檔長度的其他特征。

電子文本轉換組件將文檔轉換為索引術語(index term)或特征(feature)彼棍。顧名思義灭忠,索引術語是存儲在索引中并用于搜索的文檔部分。最簡單的索引術語是一個單詞座硕,但不是每個單詞都可以用于搜索弛作。在機器學習領域中更多地使用“特征”來指代用于表示其內容的文本文檔的一部分,其還描述了索引術語华匾。其他類型的索引術語或特征的示例是網頁中的短語映琳,人名,日期和鏈接蜘拉。索引術語有時簡稱為“術語”(term)刊头。為文檔集合索引的所有術語的集合稱為索引詞匯表(index vocabulary)。

索引創(chuàng)建組件獲取文本轉換組件的輸出诸尽,并創(chuàng)建支持快速搜索的索引或數據結構。鑒于許多搜索應用程序中的文檔數量很多印颤,索引創(chuàng)建必須在時間和空間方面都很有效您机。獲取新文檔時,索引也必須能夠有效更新。倒排索引(inverted indexes/inverted files)是迄今為止搜索引擎使用的最常見的索引形式际看。倒排索引非常簡單咸产,由每個術語對應了一個文檔列表(包含該術語的文檔)組成。它與文檔文件相反仲闽,文檔文件為每個文檔列出了它們包含的索引術語脑溢。倒排索引的許多變體都是如此,所使用的索引的特定形式是搜索引擎最重要的方面之一赖欣。

圖2.2顯示了查詢過程的構建塊屑彻。主要組件是用戶交互(user interaction),排名(ranking)和評估(evaluation)顶吮。

屏幕快照 2018-10-15 下午10.49.43.png

用戶交互組件提供進行搜索的人和搜索引擎之間的接口社牲。此組件的一項任務是接受用戶的查詢并將其轉換為索引術語。另一項任務是從搜索引擎中獲取排序的文檔列表悴了,并將其組織到顯示給用戶的結果中搏恤。例如,包括生成用于匯總文檔的片段(snippets)湃交。文檔數據存儲(document data store)是生成結果時使用的信息源之一熟空。最后,該組件還提供了一系列用于查詢查詢的技術搞莺,以便更好地表示信息需求息罗。

排名組件是搜索引擎的核心。它從用戶交互組件獲取變換后的查詢腮敌,并使用基于檢索模型的分數生成排序的文檔列表阱当。排名必須有效率,因為許多查詢可能需要在短時間內處理并且有效糜工,也必須質量高弊添,因為排名的質量決定了搜索引擎是否實現了查找相關信息的目標。排名效率取決于索引捌木,有效性取決于檢索模型油坝。

評估部分的任務是衡量監(jiān)測有效性和效率。其中一個重要部分是使用日志數據記錄和分析用戶行為刨裆。評估結果用于調整和改進排名組件澈圈。除了記錄用戶和系統(tǒng)數據之外,大多數評估組件不是在線搜索引擎的一部分帆啃。評估主要是離線活動瞬女,但它是任何搜索應用程序的關鍵部分。

詳解組件

我們現在更詳細地了解每個基本構建塊的組件努潘。 并非所有這些組件都將成為每個搜索引擎的一部分诽偷,但它們共同涵蓋了我們認為對于廣泛的搜索應用程序最重要的功能坤学。

文本獲取(text acquistion)

爬蟲(crawler)

在許多應用程序中报慕,爬蟲組件主要負責識別和獲取搜索引擎的文檔深浮。有許多不同類型的爬蟲,但最常見的是一般的網絡爬蟲眠冈。 網絡爬網程序旨在跟蹤網頁上的鏈接以發(fā)現和下載新頁面飞苇。雖然這看起來很簡單,但是在處理網絡上大量新頁面的同時蜗顽,保證上一次爬蟲訪問過的頁面修改后仍然保持新鮮布卡,這是個巨大的挑戰(zhàn)。網絡爬蟲可以限制在單個站點(例如大學)诫舅,作為站點搜索的基礎羽利。聚焦(focused)或主題(topical)網絡爬蟲使用分類技術將訪問的頁面限制為可能與特定主題相關的頁面。垂直或主題搜索應用程序會用到這種爬蟲類型刊懈,例如提供對網頁上的醫(yī)療信息的訪問的搜索引擎这弧。

對于企業(yè)搜索,爬蟲適用于發(fā)現和更新與公司運營相關的所有文檔和網頁虚汛。企業(yè)文檔爬蟲跟隨鏈接以發(fā)現外部和內部(即匾浪,限于公司內部網)頁面,但也必須掃描公司和個人目錄以識別電子郵件卷哩,文字處理文檔蛋辈,演示文稿,數據庫記錄和其他公司信息将谊。文檔爬蟲也用于桌面搜索冷溶,但在這種情況下,只需要掃描用戶的個人目錄尊浓。

信息流(feeds)

文檔流(document feeds)是用于訪問實時文檔流的機制逞频。 例如,新聞流是新聞故事和更新的源源不斷栋齿。 與必須發(fā)現新文檔的爬蟲相比苗胀,搜索引擎只需通過監(jiān)視即可從信息流中獲取新文檔。 RSS是用于新聞瓦堵,博客或視頻等內容的網絡訂閱源的通用標準基协。 RSS“閱讀器”用于訂閱使用XML格式化的RSS。閱讀器監(jiān)視這些源并在到達時提供新內容菇用。 廣播和電視流(radio and television feeds)也用于一些搜索應用中澜驮,其中“文檔”包含自動分段的音頻和視頻流,以及來自隱藏字幕或語音識別的相關文本惋鸥。

轉換(conversion)

由爬蟲找到的或由信息流提供的文檔很少以純文本形式提供泉唁。相反鹅龄,它們有各種格式,例如HTML亭畜,XML,Adobe PDF迎卤,Microso WordTM拴鸵,MicrosoPowerPoint等。大多數搜索引擎要求將這些文檔轉換為一致的文本和元數據格式蜗搔。在該轉換中劲藐,與特定格式相關聯的控制序列和非內容數據被移除或記錄為元數據。對于HTML和XML樟凄,此過程的大部分內容可以描述為文本轉換組件的一部分聘芜。對于其他格式,轉換過程是準備文檔以進行進一步處理的基本步驟缝龄。例如汰现,PDF文檔必須轉換為文本∈迦溃可以使用各種實用程序來執(zhí)行此轉換瞎饲,具有不同程度的準確性。同樣炼绘,可以使用實用程序將各種MicrosoOffice格式轉換為文本嗅战。
另一個常見的轉換問題來自文本在文檔中的編碼方式。 ASCII5是用于文本的通用標準單字節(jié)字符編碼方案俺亮。 ASCII使用7或8位(擴展ASCII)來表示128或256個可能的字符驮捍。但是,某些語言(例如中文)比英語有更多的字符脚曾,并使用許多其他編碼方案东且。 Unicode是一種標準編碼方案,它使用16位(通常)來表示世界上大多數語言斟珊。任何處理不同語言文檔的應用程序都必須確保在進一步處理之前將它們轉換為一致的編碼方案苇倡。

文檔數據存儲(document data store)

文檔數據存儲是用于管理大量文檔以及與之關聯的結構化數據的數據庫。 電子文檔內容通常以壓縮形式存儲以提高效率囤踩。 結構化數據由文檔元數據和從文檔中提取的其他信息組成旨椒,例如鏈接和錨文本(anchor text)(與鏈接相關聯的文本)。 關系數據庫系統(tǒng)可用于存儲文檔和元數據堵漱。 但是综慎,某些應用程序使用更簡單,更高效的存儲系統(tǒng)來為非常大的文檔存儲提供非城诼快速的檢索示惊。
盡管原始文檔可在Web上獲得好港,但在企業(yè)數據庫中,文檔數據存儲對于提供對一系列搜索引擎組件的文檔內容的快速訪問是必要的米罚。 如果搜索引擎必須訪問原始文檔并重新處理它們钧汹,那么檢索將花費太長時間。

文本轉換(text transformation)

解析器(parser)

解析組件負責處理文檔中的文本標記(text token)序列录择,以識別諸如標題拔莱,圖形,鏈接和新聞頭條之類的結構元素隘竭。對文本進行標記是此過程中重要的第一步塘秦。在許多情況下,標記與單詞相同动看。文檔和查詢文本必須以相同的方式轉換為標記尊剔,以便可以輕松比較它們。有許多決定可能影響檢索菱皆,這使得標記化變得非常重要须误。例如,標記的簡單定義可以是由空格分隔的字母數字字符串搔预。但是霹期,這并沒有告訴我們如何處理大寫字母,連字符和撇號等特殊字符拯田。我們應該像“apple”一樣對待“Apple”嗎历造? “on-line”是兩個字還是一個字? “O'Connor”中的撇號是否應該與“owner's”中的撇號相同船庇?在某些語言中吭产,標記化變得更加有趣。例如鸭轮,中文沒有像英語的空格符那樣明顯的單詞分隔符臣淤。

文檔結構通常由標記語言(如HTML或XML)指定。 文檔解析器使用標記語言的語法知識來識別結構窃爷。

停用詞(stopping)

停用詞組件的任務是移除標記流中的常用詞邑蒋。最常見的單詞通常是幫助形成句子結構的功能詞,但對于文本所涵蓋的主題的描述本身幾乎沒有貢獻按厘。例如“the”医吊,“of”,“to”和“for”逮京。因為它們如此常見卿堂,刪除它們會大大減少索引的大小。根據用作排名基礎的檢索模型,刪除這些單詞通常不會影響搜索引擎的有效性草描,甚至可能會有所改善览绿。盡管有這些潛在的優(yōu)勢,但很難確定要在停用詞列表中包含多少個單詞穗慕。研究中使用的一些禁用詞列表包含數百個單詞饿敲。使用這樣的列表的問題在于,使用諸如“to be or not to be”或“down under”之類的查詢進行搜索變得不可能逛绵。為避免這種情況诀蓉,搜索應用程序在處理文檔文本時可能會使用非常小的禁用詞列表(可能只包含“the”),但隨后會使用較長的列表來處理查詢文本的默認值暑脆。

詞干組件(stemming)

詞干是另一個詞級轉換。詞干組件(或詞干分析器)的任務是對來自共同詞干的單詞進行分組狐肢。分組“fish”添吗,“fishes”和“fishing”就是一個例子。通過用一個指定的單詞替換組中的每個成員(例如份名,最短的碟联,在這種情況下是“fish”),我們增加了查詢和文檔中使用的單詞匹配的可能性僵腺。事實上鲤孵,詞干化通常會在排名效率方面產生微小的改進。與停用詞組件相似辰如,可以積極地普监,保守地或根本不進行干預。積極的詞干可能會導致搜索問題琉兜。例如凯正,查詢“fishing”時得到的結果是不同種類的“fish”是不合適的。一些搜索應用程序使用更保守的詞干豌蟋,例如使用字母“s”簡單地識別復數形式廊散,或者它們在處理文檔文本時可能不會產生干擾并且專注于向查詢添加適當的詞語變體。

有些語言梧疲,例如阿拉伯語允睹,其形態(tài)比英語更復雜,因此詞干更重要幌氮。 阿拉伯語中有效的詞干成分對搜索效率產生巨大影響缭受。 相比之下,其他語言(例如中文)幾乎沒有詞語變異浩销,而且對于這些語言來說贯涎,詞干效果并不高效。

鏈接提取和分析(link extraction and analysis)

在文檔解析期間慢洋,可以容易地識別和提取網頁中的鏈接(link)和相應的錨文本(anchor text)塘雳。 提取意味著該信息被記錄在文檔數據存儲(document data store)中陆盘,并且可以與一般文本內容分開索引。 網絡搜索引擎通過鏈接分析算法廣泛使用這些信息败明,如PageRank(Brin&Page隘马,1998)。 鏈接分析為搜索引擎提供了受歡迎程度的評級妻顶,并在某種程度上為頁面的權威性(換句話說酸员,它的重要程度)提供了評級。 錨文本是Web鏈接的可單擊文本讳嘱,可用于增強鏈接指向的頁面的文本內容幔嗦。 這兩個因素可以顯著提高某些類型查詢的Web搜索的有效性。

信息提攘ぬ丁(information extraction)

信息提取用于識別比單個單詞更復雜的索引術語邀泉。 這可以像粗體中的單詞或標題中的單詞一樣簡單,但通扯鄹耄可能需要大量額外的計算汇恤。 例如,提取諸如名詞短語之類的句法特征需要某種形式的句法分析(synactic analysis)或詞性標注(part-of-speech tagging)拔恰。 該領域的研究主要集中在提取具有特定語義內容的特征的技術因谎,例如命名實體識別器(named entity recognizer),其可以可靠地識別諸如人名颜懊,公司名稱财岔,日期和位置之類的信息。

分類器(classifier)

分類器組件識別文檔或文檔部分的與類相關的元數據饭冬。 這涵蓋了一系列通常單獨描述的功能使鹅。 分類技術(classification)為文檔分配預定義的類標簽。 這些標簽通常代表主題類別昌抠,例如“體育”患朱,“政治”或“商業(yè)”。 其他類型分類的兩個重要示例是:文檔識別為垃圾郵件;識別文檔的非內容部分炊苫,例如廣告裁厅。 聚類技術(clustering)用于對沒有預定義類別的相關文檔進行分組,這些分組可以在排名或用戶交互期間使用侨艾。

索引創(chuàng)建(Index Creation)

文檔統(tǒng)計(document statistics)

文檔統(tǒng)計組件的任務僅僅是收集和記錄有關單詞执虹,功能和文檔的統(tǒng)計信息。 排名組件使用此信息來計算文檔的分數唠梨。 通常需要的數據類型是單個文檔中索引術語出現次數(單詞和更復雜的特征)袋励,索引術語出現的文檔中的位置,文檔組的出現次數(例如所有 標有“體育”或整個文件集的文件),以及以標記數量表示的文件長度(the lengths of documents in terms of the number of tokens)茬故。 所需的實際數據由檢索模型和相關的排序算法確定盖灸。 文檔統(tǒng)計信息存儲在查找表(lookup table)中,查找表是為快速檢索而設計的數據結構磺芭。

權重(weighting)

索引術語權重反映了文檔中單詞的相對重要性赁炎,并用于計算排名分數。 權重的具體形式由檢索模型確定钾腺。 加權組件使用文檔統(tǒng)計信息計算權重徙垫,并將它們存儲在查找表中。 權重可以作為查詢過程的一部分進行計算放棒,某些類型的權重需要有關查詢的信息姻报,但通過在索引過程中盡可能多地進行計算,可以提高查詢過程的效率间螟。

以前的檢索模型中使用的最常見類型之一稱為tf.idf加權逗抑。 這些權重有很多變化,但它們都是基于文檔中索引詞出現的頻率或計數(術語頻率或tf)和整個文檔集合中索引詞出現頻率的組合( 逆文檔頻率寒亥,或idf)。 idf權重稱為逆文檔頻率荧关,因為它對非常少的文檔中出現的術語賦予高權重溉奕。 idf的典型公式是log N / n,其中N是搜索引擎索引的文檔總數忍啤,n是包含特定術語的文檔數加勤。

倒排

倒排組件是索引過程的核心。 其任務是將來自文本轉換組件的文檔 - 術語信息流更改為術語 - 文檔信息同波,以創(chuàng)建倒排索引鳄梅。 挑戰(zhàn)在于有效地執(zhí)行此操作,不僅對于最初創(chuàng)建倒排索引時的大量文檔未檩,而且還在使用消息流或爬的新文檔更新索引戴尸。 倒排索引的格式是為快速查詢處理而設計的,并且在某種程度上取決于所使用的排序算法冤狡。 索引也被壓縮以進一步提高效率孙蒙。

索引分發(fā)(index distribution)

索引分發(fā)組件跨多個計算機分發(fā)索引,并可能跨網絡上的多個站點分發(fā)索引悲雳。 分發(fā)對于網絡搜索引擎的高效性能至關重要挎峦。 通過分發(fā)文檔子集的索引(文檔分發(fā) document distribution),索引和查詢處理可以并行完成合瓢。 分配標記子集(標記分發(fā) term distribution)的索引也可以支持并行處理查詢坦胶。 復制(Replication)是一種分發(fā)形式,其中索引或索引部分的副本存儲在多個站點中,以便通過減少通信延遲來提高查詢處理效率顿苇。 點對點(P2P)搜索涉及一種不太有組織的分布形式峭咒,其中網絡中的每個節(jié)點都維護著自己的索引和文檔集合。

用戶交互(user interaction)

查詢輸入(query input)

查詢輸入組件為查詢語言提供接口和解析器(parser)岖圈。最簡單的查詢語言(例如在大多數Web搜索接口中使用的語言)只有少量的運算符讹语。運算符是查詢語言中的命令鹅搪,用于指示應以特殊方式處理的文本踱讨。通常吏夯,運算符通過約束文檔中的文本如何匹配查詢中的文本來幫助闡明查詢的含義涂圆。簡單查詢語言中的運算符的示例是使用引號來指示所包含的單詞應該作為文檔中的短語出現溺拱,而不是作為沒有關系的單個單詞干旧。但是哥攘,典型的Web查詢包含少量沒有運算符的關鍵字针史。關鍵字(keyword)只是一個對指定查詢主題很重要的單詞贡定。由于大多數網絡搜索引擎的排名算法都是針對關鍵字查詢而設計的赋访,因此可能包含較低比例關鍵字的較長查詢通常效果不佳。例如缓待,查詢“搜索引擎”的結果比查詢“什么是搜索引擎中使用的典型實現技術和數據結構”的結果更好蚓耽。搜索引擎設計面臨的挑戰(zhàn)之一是為一系列查詢提供良好的結果,并為更具體的查詢提供更好的結果旋炒。

對于希望對搜索結果擁有大量控制權的人或使用搜索引擎的應用程序步悠,可以使用更復雜的查詢語言。 與SQL查詢語言(Elmasri&Navathe瘫镇,2006)一樣鼎兽,這些查詢語言不是為搜索應用程序的終端用戶設計的。布爾查詢語言(boolean query language)在信息檢索方面有著悠久的歷史铣除。 這種語言的運算符包括布爾與(Boolean AND)谚咬,布爾或(Boolean OR)和布爾非(Boolean NOT),以及某種形式的鄰近運算符(proximity operator)尚粘,它指定單詞必須在特定距離內一起出現(通常以字數計)择卦。 其他查詢語言(包括這些以及其他按照概率框架(probabilistic framework)設計運算符)允許指定與文檔結構和內容相關的特征。

查詢轉換(query transformation)

查詢轉換組件包括一系列的技術郎嫁,這些技術被設計用來在排序之前和之后提高原始查詢的效率互捌。最簡單的處理涉及文檔文本中使用的一些相同的文本轉換技術。必須對查詢文本進行標記(tokening)行剂,過濾停用詞(stopping)和詞干分析(stemming)秕噪,以此生成與文檔術語(document term)可以比較的索引術語(index term)。

拼寫檢查(spell checking)和查詢建議(query suggestion)是查詢轉換的2種技術厚宰,他們生成相似的輸出腌巾。這2種技術會給用戶的初始查詢文本呈現可選項遂填,用于糾正他的拼寫錯誤或者補充更多的查詢信息。這些技術通常利用從web應用收集的大量的查詢日志(query log)澈蝙。查詢擴展(query expansion)技術也給查詢建議或者增加額外的term吓坚,但是通常是基于文檔中term出現的分析。這個分析會使用不同的信息來源灯荧,比如整個文檔集合礁击、被檢索的文檔或者用戶電腦上的文檔。相關性反饋(relevance feedback)是一個擴展查詢的技術逗载,他基于term在文檔(被用戶認為相關的文檔)中的出現情況哆窿。
注:token是一系列attribute的組合,而term是其中一個attribute厉斟。以后遇到token和term不翻譯

結果輸出(results output)

結果輸出組件負責把排序組件返回的已排序的文檔進行展示挚躯。這個組件的任務包括生成用戶匯總檢索文件信息的snippets(片段),高亮重要的詞和段落擦秽,把結果聚類來識別文檔組码荔,把合適的廣告加到結果中。文檔可能包含不同的語言感挥,需要被翻譯成同一種缩搅。

排序(ranking)

打分(scoring)

打分組件(別名query processing)使用基于檢索模型的排序算法給每個文檔打分。一些搜索引擎的設計者會聲明他們使用的檢索模型触幼。但其他的設計者只會公開排序算法誉己,而不會公開檢索模型。排序算法使用的特征和權重域蜗,來自經驗(基于測試和評估),與主題和用戶相關噪猾;否則搜索引擎不能很好工作霉祸。

現在已經有了很多種不同的檢索模型和導出排序算法的方法。很多模型的基本打分公式如下:

屏幕快照 2018-10-17 下午11.23.59.png

qi是第i個term的查詢term權重袱蜡,di是文檔term的權重丝蹭。term權重基于特定的檢索模型,但是跟tf-idf權重類似坪蚁。第七章會討論基于BM25和query likehood檢索模型的排序算法奔穿。

打分一定要快,要在結果輸出組件限定的時間內完成敏晤。這里會有性能調優(yōu)的任務贱田。

性能調優(yōu)

性能調優(yōu)涉及到排序算法和相關的索引的設計,目標是降低響應時間增加吞吐量嘴脾。
兩種打分方式:
term-at-a-time打分方式:通過查詢term訪問index男摧,計算文檔對這個term的貢獻度蔬墩,累積文檔的貢獻度,然后繼續(xù)訪問下一個索引
document-at-a-time打分方式:同時訪問查詢term涉及的所有index耗拓,通過移動指針找到文檔所有的term計算文檔的分數
優(yōu)化的保證:
安全優(yōu)化(safe optimization):保證跟優(yōu)化前打分一樣
非安全優(yōu)化(unsafe optimization):不能保證跟優(yōu)化前打分一樣
需要根據實際情況評估優(yōu)化對排序效果的影響拇颅。

分發(fā)(distribution)

索引可以分發(fā),排序也可以乔询。一個查詢代理(query broker)負責把查詢通過網絡分發(fā)出去樟插,并把排序結果合并。代理基于索引的分發(fā)來工作竿刁。緩存(caching)是另一種分發(fā)方式黄锤,索引甚至之前的排序結果都在本地內存中。如果一個查詢或者索引term很火们妥,那么緩存起來回來會節(jié)省很多時間猜扮。

評估(evaluation)

日志(logging)

記錄用戶的查詢和反饋是最重要的事情之一,它可以用來提高搜索的質量和效率监婶。查詢日志可以用來做拼寫檢查旅赢,查詢建議和查詢緩存等。用戶的點擊惑惶、瀏覽時間等行為可以訓練排序算法煮盼。

排序分析

使用日志數據或者相關性評價來衡量排序算法的效率。

性能分析

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末带污,一起剝皮案震驚了整個濱河市僵控,隨后出現的幾起案子,更是在濱河造成了極大的恐慌鱼冀,老刑警劉巖报破,帶你破解...
    沈念sama閱讀 217,542評論 6 504
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現場離奇詭異千绪,居然都是意外死亡充易,警方通過查閱死者的電腦和手機,發(fā)現死者居然都...
    沈念sama閱讀 92,822評論 3 394
  • 文/潘曉璐 我一進店門荸型,熙熙樓的掌柜王于貴愁眉苦臉地迎上來盹靴,“玉大人,你說我怎么就攤上這事瑞妇「寰玻” “怎么了?”我有些...
    開封第一講書人閱讀 163,912評論 0 354
  • 文/不壞的土叔 我叫張陵辕狰,是天一觀的道長改备。 經常有香客問我,道長蔓倍,這世上最難降的妖魔是什么绍妨? 我笑而不...
    開封第一講書人閱讀 58,449評論 1 293
  • 正文 為了忘掉前任润脸,我火速辦了婚禮,結果婚禮上他去,老公的妹妹穿的比我還像新娘毙驯。我一直安慰自己,他們只是感情好灾测,可當我...
    茶點故事閱讀 67,500評論 6 392
  • 文/花漫 我一把揭開白布爆价。 她就那樣靜靜地躺著,像睡著了一般媳搪。 火紅的嫁衣襯著肌膚如雪铭段。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,370評論 1 302
  • 那天秦爆,我揣著相機與錄音序愚,去河邊找鬼。 笑死等限,一個胖子當著我的面吹牛爸吮,可吹牛的內容都是我干的。 我是一名探鬼主播望门,決...
    沈念sama閱讀 40,193評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼形娇,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了筹误?” 一聲冷哼從身側響起桐早,我...
    開封第一講書人閱讀 39,074評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎厨剪,沒想到半個月后哄酝,有當地人在樹林里發(fā)現了一具尸體,經...
    沈念sama閱讀 45,505評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡祷膳,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,722評論 3 335
  • 正文 我和宋清朗相戀三年陶衅,在試婚紗的時候發(fā)現自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片钾唬。...
    茶點故事閱讀 39,841評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖侠驯,靈堂內的尸體忽然破棺而出抡秆,到底是詐尸還是另有隱情,我是刑警寧澤吟策,帶...
    沈念sama閱讀 35,569評論 5 345
  • 正文 年R本政府宣布儒士,位于F島的核電站,受9級特大地震影響檩坚,放射性物質發(fā)生泄漏着撩。R本人自食惡果不足惜诅福,卻給世界環(huán)境...
    茶點故事閱讀 41,168評論 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望拖叙。 院中可真熱鬧氓润,春花似錦、人聲如沸薯鳍。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,783評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽挖滤。三九已至崩溪,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間斩松,已是汗流浹背伶唯。 一陣腳步聲響...
    開封第一講書人閱讀 32,918評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留惧盹,地道東北人乳幸。 一個月前我還...
    沈念sama閱讀 47,962評論 2 370
  • 正文 我出身青樓,卻偏偏與公主長得像岭参,于是被迫代替她去往敵國和親反惕。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,781評論 2 354

推薦閱讀更多精彩內容