1 前言
當今搜索功能已經成為我們網站體驗中不可或缺的一部分。無論是百度、谷歌那樣的傳統搜索網站，還是京東、拼多多之類的電商都是以搜索算法為核心，自然而然的，我們也希望打開其他類型網站或是手機app時，同樣有一個可定製化的站內搜索，以便改善用戶體驗。但站內搜索並不是直接加個搜索框這麼簡單。根據Forrester的調查研究，有高達77%的用戶在第一次訪問網站時，會立即進行站內搜索，但仍有一半網站的站內搜索功能並不能滿足用戶的搜索需求（如不提供站內搜索、不能二次搜索等）。
2 為什麼站內搜索很重要
使用戶更好地了解你的產品和服務一個好的站內搜索能夠快速地幫助用戶定位他們想要的信息，並發現高質量的內容。如用戶可以使用站內搜索篩選信息，站內搜索甚至會給用戶推薦與他搜索詞高度匹配的推薦內容。這些都可以促進用戶與網站間的互動，以便更好的了解該網站的產品和服務。
提高用戶留存率根據Forrester的調查研究，用戶在站內搜索結果不理想時，有16%的用戶會毫不留情地關掉網站，甚至去其他網站尋找，畢竟每個用戶的注意力是有限的，對於該網站來說就失去了一個與用戶建立關係的機會。有趣的是，調查還顯示，用戶網齡越高，對站內搜索結果的要求也越高。
分析並利用有價值的數據站內搜索可以讓用戶在快速找到他們所需信息的同時，引導用戶去發現他們自己可能感興趣的內容。用戶在搜索框提交的關鍵詞是非常有價值的數據，你需要抓住這個機會分析用戶搜索行為背後的動機，進而改進我們的產品和服務。搜索後臺會通過機器學習分析用戶提交的搜索關鍵詞和他們的瀏覽記錄，這樣用戶再次搜索時，站內搜索會根據他們的偏好優化搜索結果，確保對用戶最有用、最相關的信息排在最前面。
3 站內搜索的發展
各式各樣的站內搜索都是從一個簡單的搜尋引擎逐漸完善而來的。TREC(Text Retrieval Conference)，也叫文本檢索會議，它是信息檢索領域一年一度最權威的評測會議，由美國國家標準與技術研究院(NIST)主辦，旨在通過以大數據為基礎的信息檢索技術評測來促進信息檢索研究的發展。自從1991年舉辦第一屆會議起，每年的參與者都來自當今一流學府和企業科研機構。該會議包括幾個特定領域檢索（Legal、Genomics、Enterprise、Blog、Web），會議負責提供語料庫、檢索條件、問題集、以及評測辦法，參與者則需要在規定時間內構造檢索系統並提交檢索結果，由會議負責評測檢索系統的優劣，最終依據評測結果進行學術交流並發表會議論文。在最早幾屆的一次會議中，他們想找到非結構化長文檔組成的數據集的最優搜索算法，並為這個目的對搜索算法做了很多優化，其中TF-IDF算法應該是當時最優秀的排序算法的核心。
4 站內搜索的算法
顧名思義TF-IDF算法，含有兩個關鍵要素，詞頻TF與逆文檔頻率IDF。TREC用這兩個要素統計加權後獲得搜索排序，這種算法的身影如今仍出現在絕大部分搜尋引擎中。
詞頻TF(Term Frequency)，即搜索詞在一篇文檔中出現的頻率。
逆文檔頻率IDF(Inverse Document Frequency)，即搜索詞在整個語料庫中出現的頻率。
當用戶輸入一個搜索詞後，搜尋引擎首先會檢查整個文檔庫中含有搜索詞TF的文檔。一篇文檔中含有的搜索詞越多，這篇文檔的排名就越高。但這個規則也有明顯的缺點，中文裡有些只用於輔助句子表達的詞，如「那個」、「和」並不屬於文檔的核心內容，這時候就要用到另一個要素逆文檔頻率IDF了，它的作用是降低語料庫中出現頻率多的詞的權重。一個詞在語料庫中重複出現的次數越多，包含這個搜索詞的文檔的排名就越低。TF-IDF算法以及改良算法BM25算法基本就是早期搜尋引擎的查詢和排序的核心算法。這類算法主要針對非結構化長文檔而設計，如大型企業文檔、歷年法規制度，論文檢索庫等。
這裡也簡單介紹下BM25算法，它在TF計算方法中增加了一個常量k，用來限制TF值的增長極限。下面是兩者的公式：
// TF-IDFTF_Score= sqrt(tf)// BM25TF_Score = ((k + 1) * tf) / (k + tf)下面是兩種算法中，詞頻對TF_Score影響的走勢圖。從圖中可以看到，當tf增加時，TF_Score隨之增加，但BM25的TF_Score會被限制在0 ~ k+1之間。這在業務上可以理解為某個因素的影響強度不能是無限的，而是有個最大值，這也符合我們對文本相關性邏輯的理解。
不僅如此BM25還引入了平均文檔長度的概念，如果你能理解這些算法的原理，就更有助於設計自己的站內搜索。限於篇幅這次只是簡略介紹了搜索算法，且有開源免費的ElasticSearch解決方案，在算法不是大問題的前提下，剩下就是考慮站內搜索的產品設計策略。
5 站內搜索的設計：如何利用數據的多維欄位
TF-IDF算法的問題是它只適合傳統的少數場景，對於大多數網站、手機app裡的站內搜索適應很差，這種算法會把所有文檔不分類型的混在一起進行搜索。假如我們現在的數據為多維欄位，甚至還有一些由用戶行為主導的動態欄位，如瀏覽量、收藏數等。那麼如何利用這些包含豐富多維欄位的數據來優化搜索算法，使搜索排序結果準確？
一般的我們可以把站內文檔的欄位分成這幾個維度：
文檔基礎欄位：標題、正文、標籤等。這些欄位作為文檔的基礎欄位，也是站內搜索的必要欄位。用戶行為主導欄位：瀏覽、收藏、打分等通過用戶行為產生的文檔欄位，這些欄位可以輔助我們判斷一篇文檔的優質程度。站內業務策略欄位：作為業務人員，有時候會根據當前業務情況，手動調整這些策略欄位，以改變文檔在搜索結果中的排序，如置頂、精品。我們來舉個例子，一個用戶最近被推薦了一個基金， 叫【光大中小盤】，打算第二天去基金app上購買，但購買的時候，用戶只記得基金名稱裡有個【中小盤】，於是他在基金app的站內搜索輸入【中小盤】。這時候站內搜索應該把什麼排在聯想列表或是結果列表的第一位呢？
上圖為基金app中輸入【中小盤】的排序結果，在有許多【中小盤】基金的情況下，因為這個【光大中小盤】本身權重高（可能是這個基金買的人多，也可能是該app的業務策略），所以被排在了第一位。
在這個場景的搜索中，【中小盤】這個詞，有很多欄位可供我們的站內搜索用作排序判斷。
【中小盤】這個詞在「基金名稱」欄位中，還是在「基金標籤」中？【中小盤】這個詞在欄位中是第一個詞嗎，還是當中的一個詞？含【中小盤】的欄位中有多少用戶行為主導欄位？如：購買數、星級評分等。含【中小盤】的欄位包含在基金app自己的站內業務策略欄位嗎？如：近期人氣榜、高分基金榜等。以上這些欄位在進行加權後，把【光大中小盤】排在搜索結果最前面的可能性，肯定比使用TF-IDF排序算法找到【光大中小盤】的可能性大的多。所以我們應該考慮到所有多維欄位，並根據不同欄位的重要程度來設計權重。我們也可以從以下幾個方面來考慮如何排序。
匹配相關度：如果用戶輸入多個搜索詞，與用戶輸入的搜索詞相關度最高的結果，肯定要排在最前面。相近度：詞與詞彼此相近，排名更靠前。如搜索【吉野家】，那麼【吉野家快餐】應該比【吉野的家】排名靠前。搜索詞所屬欄位：處於重要欄位中的詞，排名會更高。如標題包含了搜索詞的文檔，排名肯定高於只有正文才有搜索詞的文檔。是否完全匹配：完全匹配的搜索詞，沒有任何前綴和後綴，會排在最前面。業務權重：如在某圖書app進行站內搜索，用戶首先想找的一定是作者名，其次才是書名。如搜索【太宰治】排在第一的大概率是【太宰治】(作者名)，而不應該是【太宰治】(書名)，這是業務權重的排序策略。
站內搜索加上這些排序策略後，相比經典的TF-IDF算法，搜索準確度就有了很大提高，那麼是否還能再進一步提高準確度呢？答案是可以，關鍵在於欄位的優先度。
6 站內搜索的設計：如何調整數據的多維欄位的優先度
利用數據的多維欄位，算法可以根據所有加權給每一份文檔一個打分，然後根據這個打分來排序。但這種算法還有一個致命的缺陷，就是把完全不是一類型的欄位混在一起再排序，不一定是正確的方案。
如果排序方案包含TF-IDF及瀏覽量這兩個欄位，站內搜索會怎麼排序？如果某個文檔的瀏覽量非常高，站內搜索會怎麼排序？這個文檔會排在非常靠前，即便文檔與搜索詞的相關度非常低。那麼如果某個文檔與搜索詞的相關度非常高，但瀏覽量為0，又會怎麼排序呢？這篇瀏覽量為0的文檔很可能不會出現在排序結果中。當多維欄位被混在一個公式裡，我們可能會發現搜索結果很糟糕，那麼我們應該怎麼調整呢？聰明的辦法是把所有欄位拆開來，針對自己的業務調整他們的順序即可。即不把所有欄位混在一起打一個大分，而是分別根據N個欄位計算N個分數，並連續進行N次排序。所有初始結果按照第一個欄位打分並排序，如果有結果得分並列，則這些並列的結果繼續按照第二個欄位打分並排序。如果仍有並列，那麼就繼續按照第三個欄位...直到搜索結果中每一個文檔都有自己的位置。
那麼先用哪個欄位來進行排序，成為這個排序方案的關鍵，這裡舉一個例子，用戶在基金app中的Q&A頁面中輸入【光大中小盤】想查詢相關Q&A時，他會得到如下結果：
[ {"title": "光大中小盤的年化收益率是多少？","is_top": true,"visit": 1912 }, {"title": "光大中小盤的產品代碼是多少？","is_top": true,"visit": 623 }, {"title": "光大中小盤的風險等級是哪檔？","is_top": false,"visit": 989 }, {"title": "易方達中小盤的風險等級是哪檔？","is_top": false,"visit": 1503 }]給予置頂更高權重，置頂一般是網站管理員手動添加的，表示為近期較重要的文檔。這種置頂業務策略欄位，通常情況下權重應該大於用戶行為主導欄位，如瀏覽量。其次搜索詞相關度的權重應該大於瀏覽量。如果我們對這個例子的排序結果不滿意，只需要調整欄位排序順序即可。
7 總結：一個好的站內搜索該如何設計
站內搜索應該能提高用戶留存率。站內搜索應該是可用戶個性化的，可以分析用戶的搜索記錄和網站行為，收集用戶的真實想法，以給出最佳的搜索結果，提高用戶體驗。特別是無結果的搜索詞，能更好地改進網站內容。站內搜索不一定要使用複雜的搜索算法，可以使用產品策略來調整搜索結果。站內搜索可以使用更多維度的欄位，使之能更好地進行排序。站內搜索功能應該是智能的，在穩定快速的前提下，具有錯字容錯，結果過濾，搜索聯想等功能，使用戶搜索更順暢。站內搜索應該是易維護的，用少量人力和資源即可實現強大的站內搜索資源，並提供7/24故障處理響應，保障業務不受影響。站內搜索應該是可靠的，如ElasticSearch採用集群隔離、多租戶架構等。擴展閱讀TREC官網TREC近年檢索問題集