如何搭建一個站內搜索引擎(一) 第1章 寫在最前

        搜索引擎,對不少人來講,熟悉又陌生。熟悉,是由於每一個人天天都能接觸到,好比百度、google、淘寶內部搜索;陌生,是由於鮮有人瞭解他的原理。數據庫

        由於工做須要,有幸參與負責了一個站內搜索的項目。因此能夠從實現的角度來說講怎麼去實現一個站內檢索系統。數據結構

    一、爲何要使用檢索系統

           可能有些人會這麼想,站內搜索我直接用數據庫的like就能夠實現。這種想法其實在實際中不太可行。首先,like語句極可能用不到搜索,所以性能低下;其次,like語句只能作比較精確的比配,相關性比較低下。好比,"我在北京玩的很好"這句話,若是你用"北京市"去搜索,確定搜不出來,用帝都也是搜索不出來的,可是,實際上"北京市"和"帝都"以及"北京"都是一個意思;最後,站內檢索系統能夠作很是複雜的rank、打散以及屏蔽策略。性能

            綜上,正確認識一個檢索系統是很是重要的。
搜索引擎

   二、實現最簡單的檢索系統

        基於此,如今給你們來說訴怎麼快速搭建一個檢索系統。google

    2.一、準備材料。

        咱們如今有3篇文本spa

D0: "it is what it is"
D1: "what is it"
D2: "it is a banana"

   2.二、整理分析文本

       搜索引擎整理信息的過程稱爲「建立索引」,常見的索引數據結構能夠有多種,好比kd-tree等,我我的認爲用的最多的數據結構當屬倒排索引(Inverted_index)。設計

    2.2.1 倒排索引的概念

            倒排索引,也常被稱爲反向索引、置入檔案或反向檔案,是一種索引方法,被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最經常使用的數據結構(來自於wiki)。code

    2.2.2 實現倒排索引

            如今去實現2.1裏面的倒排索引,能夠看出a 在D2裏面出現過,banana也在D2中出現過,is和it在D0、D一、D2都出現過,what在D0和D1出現過。因此索數據以下:對象

 "a":      {2}
 "banana": {2}
 "is":     {0, 1, 2}
 "it":     {0, 1, 2}
 "what":   {0, 1}

    2.3 搜索

  • 檢索query爲 "what is it",找到所有出現這些單詞的文本(不考慮次序)排序

  • 拉鍊:what爲{0,1}, "is"爲{0,1,2}, "it"爲{0,1,2};

  • 歸併:\{0,1\} \cap \{0,1,2\} \cap \{0,1,2\} = \{0,1\}爲{0,1},也就是D0和D1

    三、額外的考慮

    3.一、相關性的考慮

        任何一個搜索引擎都必須考慮相關性。

        好比如今文本對象是oschina的一篇博客。那麼在標題或者摘要的詞語確定比在內容中出現的更相關。好比這篇文章中標題有"搜索"關鍵字,而博客內容中有不少"相關性",很明顯這篇文章"搜索"關鍵字要比"相關性"更相關。

        如今,咱們能夠發現這篇文章出現不少"出現"這個詞語,"相關性"這個詞語則相對較少,相對這篇文章,哪一個更相關呢。"出現"顯然比"相關性"出現次數要多。可是咱們不能認爲"出現"比"相關性"更相關(這篇文章至少還有一段是描寫相關性的)。這時候須要藉助一個模型:tf-idf模型(這個模型有不少變種名字)。簡要介紹下,tf(詞頻.term frequency)爲指的是某一個給定的詞語在該文件中出現的頻率, idf(逆向文件頻率,inverse document frequency)爲一個詞語的重要性。明顯"出現的"idf要遠小於"相關性",因此能夠用 tf * idf來代表一個詞語的相關性。那麼"相關性"比"出現"更相關。

        那麼考慮這個case,2篇文章,一篇中有20個字,裏面有5個"北京",另一篇有10000字,出現8個"北京",那麼這2個哪一個更相關呢。按照tf-idf,明顯是第二個更好,可是實際上第一篇更相關。這種case能夠考慮相對詞頻,第一個tf=5/20,第二個爲8/10000。

        最後須要考慮一些特殊case,好比同義詞的case,好比"北京"和"北京市"和"帝都"說的都是北京,須要放在一塊兒考慮。一篇文章出現了"帝都",理論上它和"北京"也是相關的。

        其餘case都在後文講訴。

    3.2 召回率與準確率考慮

     

        什麼是召回率和準確率呢,下面舉個例子。假設1個query結果以下:


相關 不相干
召回數目 A B
未召回數目 C D

        那麼召回率爲  A/(A+C),即正確召回相關的數目除以全部相關的數目。

        準確率爲 A/(A+B),即正確召回的數目因此全部召回的數目。

        召回率和準確率是一對天敵。擴大召回最好的辦法是所有召回,擴大準確率最好的方法是一個都不召回。

        因此須要咱們在召回和準確上作好一個評估。

   

    3.3 rank

        排序是搜索引擎必須關注的點,降價排名,人工干預大部分作的就是這部分。你們擠破頭都像排名更加考前。對於搜索引擎而言。這部分設計策略太多。可是若是僅僅是站內檢索,咱們相對而言就簡單不少。好比咱們提早將文本標註好屬性,打好分。好比文章1字數多,文章優秀,給100分;文章2文章 湊合,只能給50分。那麼當拉鍊有文章1和文章2時候,文章1排在前面就好。

        rank策略不少,在之後的文章中會敘述。在這僅僅敘述一個時效性。


    3.四、時效性的考慮

        對於2篇博客,2個加權差很少,1篇是14年的,1篇是10年的。顯然,出14年的則更加好。那麼則須要加入一個時效性的權重。這個時候,問題又出現了,我新寫了一篇文章,可能很是爛,可是由於時效性加權比較高致使rank比較高,這種case也屬於badcase。所以須要時效性加權作一些策略,保證在正常rank的狀況下使用時效性加權。

    3.5 篩選

        搜索的結果必須能夠排序,好比按照時間排序等等。這個時候能夠藉助資源的熟悉進行排序。在之後會講到,這個地方就再也不講了。

    3.六、打散

        當咱們同時有幾家資源就可能須要打散了,好比作百度團購檢索,團購接入了美團、糯米、去哪等多家團購資源,不能由於美團資源好全面都所有出美團的,這樣不科學,因此須要有打散策略。

    3.七、人工干預

    再好的檢索系統都會有badcase,因此確定須要人工干預,好比加很名單等等,因此一個優秀的檢索系統確定得支持人工干預。

相關文章
相關標籤/搜索