搜索與推薦的區別

1. 場景需求不同

搜索的場景故名思義，就是用戶提供想要尋找的內容的描述，系統返回給用戶匹配到的結果，常見的場景如文字輸入框的搜索，圖片搜索，聽音識曲，標簽篩選等，看似很多場景，其實只是用戶輸入內容的形式不同。

推薦的場景我們常見的有各大App首頁的個性化推薦（如猜你喜歡/每日歌曲推薦），選擇頁面的關聯推薦（買了還買，看了還看，買了它的用戶還買等等）等，推薦的場景更加的豐富，因為沒有用戶提供的內容的限制，場景更具多樣性，推薦方法也多種多樣，例如基于內容的推薦，基于用戶行為的推薦，協同過濾等等。

各大互聯網平臺由于服務內容不同，平臺成熟度的不同，對搜索和推薦的偏重程度也就不盡相同，但都是缺一不可。

例如對于房地產應用來說，用戶目標明確，搜索服務會帶來更大的購買力，但關聯推薦會給用戶帶來更多的選擇，同樣也是不可缺少的。

對于短視頻平臺而言，由于用戶較難通過文字或圖片提供內容的描述，那么自然會偏重推薦服務。

對于電商在初期肯定是搜索服務帶來了更多的購買率，當購買率到達瓶頸時，推薦帶來的購買率就是突破瓶頸和繼續發展的必要手段。

2. 輸入輸出不同

不論搜索還是推薦，實際上對于用戶來說，都是一個提供服務的黑盒，它能夠根據用戶/物品/場景等信息，從候選物品的池子中選出與用戶匹配的的物品列表。

不同的是對于搜索服務，還額外提供了用戶對于自己訴求的描述信息（當然可能描述的并不準確）。

輸入的區別天然的導致了用戶對于結果的不同期待：

• 個性化程度不同

  推薦系統更強調個性化，甚至更注重驚喜感。往往要在準確性和多樣性之間作出權衡；搜索系統更強調相關性，如果搜索結果與用戶的目標不符，用戶的接受程度會很差，個性化對于搜索系統來說既沒意義又有風險。

• 排的更好與搜的更全

  對于推薦系統來說，排序更加重要，因為只有最開始的推薦結果吸引了用戶，用戶才可能向后瀏覽。

  對于搜索系統來說，召回更加重要，因為用戶會主動向后瀏覽，以期望找到自己的目標，但如果最終沒有找到，也就是搜的不全，就會有很差的用戶體驗。

• 快速滿足還是持續服務

  提到搜索系統，往往會提到馬太效應，只有與用戶搜索的結果更為匹配的物品才會被呈現給用戶，讓用戶得到快速滿足，那么滿足需求的物品那么多，搜索的越準確，用戶就越不會向后瀏覽，最終點擊的熱度就只會集中在少量的物品上。這也就是為什么廣告最初誕生在搜索系統中的原因。

  提到推薦系統，往往會提到長尾效應，也就是讓用戶時刻保持新鮮感和驚喜感，考慮用戶的長期興趣，提高用戶粘性，期望留住用戶，并提供持續的服務，這也就是為什么刷短視頻停不下來的原因。

• 實時性與滯后性

  搜索的數據實時性要求是特別高的，數據常常要求秒級更新，例如一個商品已經沒有貨了就不應該被搜出來了。而推薦的數據很多是可以容忍天級更新的，由于推薦要考慮大量的用戶行為信息，一定是具有一定滯后性的。

搜索與推薦的聯系

1. 相同的本質

搜索與推薦本質上都是當前時代信息過載的產物，解決的根本思路都是通過匹配（召回）、排序為用戶在過載的信息中挑選出用戶想要的信息。只是根據業務場景的不同，在召回，排序階段考慮的側重點不同。

2. 搜索與推薦的協同作用

• 推薦中的搜索

  推薦服務中基于內容的推薦實際上相當于一種無聲的搜索，常常在實現時會采用搜索服務的中的倒排索引等技術，例如基于內容的推薦，常常是通過規則或推薦模型得到用戶感興趣的內容的標簽，然后利用搜索服務的方法進行標簽搜索和匹配即可得到最終的推薦列表。

• 搜索中的推薦

  當搜索出來符合用戶的數據量很多時，需要根據推薦服務中用戶畫像等結果幫助搜索服務匹配用戶的需求。例如周一的晚上進行搜索得到的結果列表和周五的晚上進行搜索得到結果列表就會有所差異。

推薦與搜索常常在一個頁面中協同為用戶提供服務，例如搜索引擎搜索結果頁面的關聯推薦，電商軟件搜索瀏覽頁面的相關推薦等。

架構演進與架構統一

搜索架構的演進

一般而言，一個企業的搜索引擎，由于在初始階段業務線不多，提供簡單的搜索服務即可。隨著業務的不斷增多，對搜索需求的不斷抽象和統一，逐漸可以發展為平臺階段，提供多數據源的寫入與多業務的統一搜索能力，不同業務的不同需求可以靈活配置。

等到業務線不斷增多，對接業務的工作占據了大部分的開發時間時，開發更加方便的運維與管理能力，幫入業務自助接入平臺就能夠進一步提高搜索功能開發的效率，此時搜索架構就進入到了運維更為便捷的云平臺的階段。

推薦架構的演進

對于推薦引擎，起步階段一般會采用基于內容的推薦方法，由于數據不足，企業初期會基于業務側提供的經驗規則對物品和用戶進行標注，然后通過在線匹配標簽的方式進行推薦。繼續發展，隨著業務的不斷豐富和迭代，會對推薦系統有更多的期望，當不斷修改或增加經驗規則卻滿足不了業務需求時，就需要一些基于模型的推薦方法以及個性化的推薦的服務了。再進一步，與搜索引擎一樣，推薦引擎也需要對接多個業務線，向平臺階段發展，提供統一的公共服務，通過配置滿足不同的業務線的需求。

架構統一

從上面的介紹和架構演進我們可以發現，推薦和搜索的架構有很多可以復用的地方，因而可以進行架構的統一。

1. 流程上的統一：

   不論是搜索還是推薦，都會經歷召回-排序-重排等流程，最終得到呈現給用戶的物品列表，只不過流程中各個階段的目標會不太相同。

2. 數據與數據平臺的復用：

   被搜索的物品和被推薦的物品是統一的，召回排序訓練模型時所需要的埋點數據/用戶行為數據等也是統一的，那么自然獲取數據/處理數據的平臺自然就是可以復用的。

3. 算法與算法平臺的復用：

   搜索和推薦發展到一定階段，當簡單的專家規則不再能夠支撐復雜的搜索和推薦需求時，都會發展到基于模型進行召回排序的階段，此時都需要根據用戶數據/物品數據/埋點數據進行模型訓練，只不過由于二者的訓練目標不同，訓練的模型的參數可能會不相同，但算法平臺或者大家常說的機器學習/AI平臺是可以復用的。

4. A/B Test實驗平臺的復用：

   由于業務需求的不斷變化，模型的不斷更替，通過A/B Test平臺能夠通過分流的方式拿到真實的生產環境中的用戶反饋，以幫助企業不斷驗證和優化搜索和推薦策略。

5. 配置中心的復用：

   可以通過配置中心針對不同業務和服務配置不同的搜索和推薦策略，并且提供便捷的一鍵部署能力。

所以很多公司，在業務領域上搜索和推薦分屬于不同的部門，但很多的公共的部分都有成熟的內部平臺可以快速復用。

總結

本篇文章介紹了搜索和推薦的區別與聯系，架構演進以及架構統一。我們都知道架構是因為需求的擴增而不斷演進來的，例如從服務階段發展到平臺階段，是因為要提高多業務的對接效率；從基于內容的推薦到復雜的融合在線用戶畫像和離線用戶畫像的個性化推薦，是因為簡單基于規則或標簽的推薦無法滿足用戶和業務側的需求。

所以不要在一開始被過于復雜的架構綁住手腳，可以針對自身業務的需求進行搜索/推薦的簡單架構設計，然后逐步演進和優化架構。