搜索推薦系統是如何實現的？
用戶在搜索過程中，向用戶提供建議或者推薦，這樣的系統如何實現？
這主要涉及計算兩個query的相似度。有好幾種演算法：
1. 每個query會產生一個搜索列表，由url組成，這些url的點擊率不同，那麼每個query就可以建立成一個由url組成的向量，每個url的權重是點擊率。那麼兩個query相似度就可以用兩個url向量的相似度度量。
2. 可以根據用戶：比如搜索了這個詞的人也搜索那個詞，這個沒有上面的準確，但也可以提供一種相似度
3. 可以用query返回的url對應的網頁的內容相似度來度量。搜索推薦，最常見的實現方式是通過帶有用戶ip或者其他標識的搜索日誌來進行訓練做出的推薦。用戶搜索過哪些詞理解為一般性購物車推薦的商品購買即可。例如，某用戶，搜索過齊秦、張雨生，張學友，某用戶搜索過劉德華，張學友，黎明等等。
因為搜索其實是一個弱用戶行為，用user base冷啟動的話效果太差，所以沒必要考慮user base，直接上item base就可以了。
簡單的說，搜索建議和一般電商的also buy非常的相似，可以借鑒那邊的產品設計和演算法實現。
推薦《探索推薦引擎的秘密》系列 http://tiny4.org/blog/2011/05/recommend-enginee/通常推薦系統有兩種實現的模式：
Content Based
基於內容，或者基於屬性的辦法(不知道這麼翻譯對不對)，就是把要推薦的物品
的屬性提取出來，對象用戶的一些屬性也提取和分類出來，然後應用傳統的機器學習手段進行推薦，比如要推薦書籍，對書籍本身可以按照類型分(文藝，科學，科
幻，小說，……)，按照長短分(短篇，中篇，長篇，……)，按照文字圖片比分(圖為主，文字為主，……)等等；而用戶按照性別，年齡，所在城市等……屬性
劃分。然後就是傳統的機器學習分類問題了。這種做法是很自然而然的做法，但是缺點很顯著，每一個新用戶/物品出現的時候都要對其進行貼標籤(tagging)，然後對於新的屬性無能為力，需要人為干預改進。
Collabrative Filtering
根據用戶對目標商品/信息的喜好程度，找到和目標用戶相似的用戶，然後將待推薦的物品打分，打分的時候的權重根據和目標用戶愛好類似的用戶的相關度給出，常見的做法將用戶和物品之間的interaction做成一個矩陣，然後利用矩陣分解(SVD, Latent Factor, or ...)得出用戶的特徵矩陣和物品的特徵矩陣。CF現在大概是比較主流的辦法，Yahoo似乎做的非常好，國內比如豆瓣之類的好像也都是這麼干，具體涉及的技術，Google is your friend。由於分類是基於用戶，所以對於熱門的物品和信息，推薦分類效果往往比基於內容的辦法好很多，然而如果用戶不足，或者商品很冷門，那就不行了，也就是說對新加入的物品和用戶其實不能很自然的處理，尤其是小眾的。
從信息獲取的角度來看，搜索和推薦是用戶獲取信息的兩種主要手段。搜索是一個非常主動的行為，並且用戶的需求十分明確，在搜索引擎提供的結果里，用戶也能通過瀏覽和點擊來明確的判斷是否滿足了用戶需求。搜索引擎的核心提現的是「准」，即精確識別用戶的搜索意圖。
目前主流的搜索引擎仍然是以文字構成查詢詞（Query），這是因為文字是人們描述需求最簡潔、直接的方式，搜索引擎抓取和索引的絕大部分內容也是以文字方式組織的。因為這個因素，我們統計發現用戶輸入的搜索查詢詞也大都是比較短小的，查詢詞中包含5個或5個以內元素（或稱Term）的佔總查詢量的98%以上（例如：Query「達觀數據地址」，包含兩個元素「達觀數據」和「地址」）。
但另一方面，用戶存在著大量的需求是比較難用精鍊的文字來組織的，例如想查找「離我比較近的且價格100元以內的川菜館」、「和我正在看的這條裙子同款式的但是價格更優惠的其他裙子」等需求。一方面幾乎沒有用戶願意輸入這麼多字來找結果（用戶天然都是願意偷懶的），另一方面搜索引擎對語義的理解目前還無法做到足夠深入；所以在滿足這些需求的時候，通過推薦系統設置的功能（例如頁面上設置的「相關推薦」、「猜你喜歡」等模塊），加上與用戶的交互（例如篩選、排序、點擊等），不斷積累和挖掘用戶偏好，可以將這些難以用文字表達的需求良好的滿足起來。
在搜索引擎中加入推薦系統，有多種切入方式。簡單的做法可以基於查詢query和相關query，結合歷史的query和物品的關聯數據，使用基於規則和content-based相結合的方法進行推薦。這種方法可以滿足一般的需求，效果當然也不能要求很高。不過精準的推薦系統構建流程也都有常規的流程。
首先，對於有豐富歷史行為數據的用戶，挖掘用戶的偏好信息，把握用戶的口味，生成精準的用戶畫像，如對類別、標籤等多個維度的偏好信息。
然後，使用推薦演算法，如基於內容的推薦、協同過濾，矩陣分解等，生成用戶感興趣的物品列表。推薦系統的生成是一個複雜的系統工程，不僅包括各種各樣的演算法，還包括多模型融合、性能優化、高並發、點擊反饋、排序學習等。
最普遍的推薦系統有兩種方式UserCF和ItemCF。推薦演算法之用戶推薦（UserCF）和物品推薦（ItemCF）對比一、定義
- UserCF：推薦那些和他有共同興趣愛好的用戶喜歡的物品
- ItemCF：推薦那些和他之前喜歡的物品類似的物品
根據用戶推薦重點是反應和用戶興趣相似的小群體的熱點，根據物品推薦著重與用戶過去的歷史興趣，即：
- UserCF是某個群體內的物品熱門程度
- ItemCF是反應本人的興趣愛好，更加個性化
二、新聞類網站採用UserCF的原因：
- 用戶大都喜歡熱門新聞，特別細粒度的個性化可忽略不計
- 個性化新聞推薦更強調熱點，熱門程度和實效性是推薦的重點，個性化重要性則可降低
- ItemCF需要維護一張物品相關度的表，當物品量更新速度太快時，此表的維護在技術上有難度。新聞類網站對於新用戶可直接推薦熱門新聞即可
- 對於電商、音樂、圖書等網站而言，ItemCF的優勢更大：
- 用戶的興趣比較固定和持久；
- 不需要太過考慮流行度，只需要幫用戶發現他研究領域相關物品即可
- 技術角度考量
- UserCF需要維護一個用戶相似度矩陣
- ItemCF需要維護一個物品相似度矩陣
三、優缺點對比項目UserCFItemCF性能適用於用戶較少的場合，如果用戶過多，計算用戶相似度矩陣的代價交大適用於物品數明顯小於用戶數的場合，如果物品很多，計算物品相似度矩陣的代價交大領域實效性要求高，用戶個性化興趣要求不高長尾物品豐富，用戶個性化需求強烈實時性用戶有新行為，不一定需要推薦結果立即變化用戶有新行為，一定會導致推薦結果的實時變化冷啟動在新用戶對少的物品產生行為後，不能立即對他進行個性化推薦，因為用戶相似度是離線計算的
新物品上線後一段時間，一旦有用戶對物品產生行為，就可以將新物品推薦給其他用戶新用戶只要對一個物品產生行為，就能推薦相關物品給他，但無法在不離線更新物品相似度表的情況下將新物品推薦給用戶推薦理由很難提供可以根據用戶歷史行為歸納推薦理由
基於物品的協同過濾ItemCF
數據集欄位：
1． User_id: 用戶ID
2． Item_id: 物品ID
3． preference:用戶對該物品的評分
演算法的思想：
1． 建立物品的同現矩陣A，即統計兩兩物品同時出現的次數
數據格式：Item_id1:Item_id2 次數
2． 建立用戶對物品的評分矩陣B，即每一個用戶對某一物品的評分
數據格式：Item_id user_id:preference
3． 推薦結果=物品的同現矩陣A * 用戶對物品的評分矩陣B
數據格式：user_id item_id,推薦分值
4. 過濾用戶已評分的物品項
5.對推薦結果按推薦分值從高到低排序
原始數據：
1,101,5.0
1,102,3.0
1,103,2.5
2,101,2.0
2,102,2.5
2,103,5.0
2,104,2.0
3,101,2.0
3,104,4.0
3,105,4.5
3,107,5.0
4,101,5.0
4,103,3.0
4,104,4.5
4,106,4.0
5,101,4.0
5,102,3.0
5,103,2.0
5,104,4.0
5,105,3.5
5,106,4.0
6,102,4.0
6,103,2.0
6,105,3.5
6,107,4.0
Hadoop MapReduce程序分為四步：
第一步： 讀取原始數據，按用戶ID分組，輸出文件數據格式為
1 103:2.5,101:5.0,102:3.0
2 101:2.0,102:2.5,103:5.0,104:2.0
3 107:5.0,101:2.0,104:4.0,105:4.5
4 103:3.0,106:4.0,104:4.5,101:5.0
5 101:4.0,102:3.0,103:2.0,104:4.0,105:3.5,106:4.0
6 102:4.0,103:2.0,105:3.5,107:4.0
第二步：統計兩兩物品同時出現的次數，輸出文件數據格式為
101:101 5
101:102 3
101:103 4
101:104 4
101:105 2
101:106 2
101:107 1
102:101 3
102:102 4
102:103 4
102:104 2
102:105 2
102:106 1
102:107 1
103:101 4
103:102 4
103:103 5
103:104 3
103:105 2
103:106 2
103:107 1
104:101 4
104:102 2
104:103 3
104:104 4
104:105 2
104:106 2
104:107 1
105:101 2
105:102 2
105:103 2
105:104 2
105:105 3
105:106 1
105:107 2
106:101 2
106:102 1
106:103 2
106:104 2
106:105 1
106:106 2
107:101 1
107:102 1
107:103 1
107:104 1
107:105 2
107:107 2
第三步：生成用戶評分矩陣和物品同現矩陣
第一個mapper結果為用戶評分矩陣，結果如下：
101 2:2.0
101 5:4.0
101 4:5.0
101 3:2.0
101 1:5.0
102 2:2.5
102 1:3.0
102 6:4.0
102 5:3.0
103 6:2.0
103 5:2.0
103 1:2.5
103 4:3.0
103 2:5.0
104 5:4.0
104 2:2.0
104 3:4.0
104 4:4.5
105 5:3.5
105 3:4.5
105 6:3.5
106 4:4.0
106 5:4.0
107 3:5.0
107 6:4.0
第二個mapper生成物品同現矩陣，結果如下：
101:101 5
101:102 3
101:103 4
101:104 4
101:105 2
101:106 2
101:107 1
102:101 3
102:102 4
102:103 4
102:104 2
102:105 2
102:106 1
102:107 1
103:101 4
103:102 4
103:103 5
103:104 3
103:105 2
103:106 2
103:107 1
104:101 4
104:102 2
104:103 3
104:104 4
104:105 2
104:106 2
104:107 1
105:101 2
105:102 2
105:103 2
105:104 2
105:105 3
105:106 1
105:107 2
106:101 2
106:102 1
106:103 2
106:104 2
106:105 1
106:106 2
107:101 1
107:102 1
107:103 1
107:104 1
107:105 2
107:107 2
第四步：做矩陣乘法，推薦結果=物品的同現矩陣A * 用戶對物品的評分矩陣B
結果如下：
1 107,10.5
1 106,18.0
1 105,21.0
1 104,33.5
1 103,44.5
1 102,37.0
1 101,44.0
2 107,11.5
2 106,20.5
2 105,23.0
2 104,36.0
2 103,49.0
2 102,40.0
2 101,45.5
3 107,25.0
3 106,16.5
3 105,35.5
3 104,38.0
3 103,34.0
3 102,28.0
3 101,40.0
4 107,12.5
4 106,33.0
4 105,29.0
4 104,55.0
4 103,56.5
4 102,40.0
4 101,63.0
5 107,20.0
5 106,34.5
5 105,40.5
5 104,59.0
5 103,65.0
5 102,51.0
5 101,68.0
6 107,21.0
6 106,11.5
6 105,30.5
6 104,25.0
6 103,37.0
6 102,35.0
6 101,31.0
我覺得看你是具體需求了，如果是亞馬遜購物或者電影這種搜索推薦，可以看看協同過濾，矩陣分解這些。
如果是類似百度搜索後最下面的相關推薦的話可以試試對查詢的時序挖掘 或者直接短文本相似
我認為，搜索是搜索，推薦是推薦。搜索關注的點始終應該是分詞和排序。
搜索不是User Based、也不是Item Based，是個Term Based的玩意。分詞、新詞發現、命名實體識別、別名庫、排序系統，這些才是搜索的殺招。
推薦跟搜索應該分開。用戶的搜索行為是用來給推薦喂數據的重要途徑。在搜索里加入推薦內容，容易導致過擬合。
如果指的是搜索聯想（關鍵詞補全），可以簡單使用前綴匹配（或者一定edit distance之內）找出query集。@項亮 的回答相對其他倆人來說更貼近一些，雖然不完全...一般來說，解析搜索文本，並猜測用戶的搜索目的才是關鍵。
很少在搜索中完全照搬推薦引擎那一套的。推薦是目的，協同過濾，item/user base都是方法。這個方法不適用於搜索，因為不同人搜索的習慣是不一樣的，因此，itembase難度大大提高。比如，購物網站上，買了A的都也買B，那麼A和B就共現度很高，可以互相推薦了。但是在搜索中，A是用文本展現出來的，不同的人搜A的方式不同。
所以，文本分詞，解析query，根據不同用戶的狀態和點擊行為，然後以計算頻繁集的方式。結合數據來源的不同，猜測用戶的目的，可行性會更高。分別在阿里做過兩年推薦演算法和百度做過一年半的搜索策略，樓主提到的我並沒有做過這樣技術，但是接觸過這兩個領域，表下看法：
首先我覺得要做這個東西的主要問題是不在技術，而且上面都說得挺好了，我覺得真正要做好這個東西，主要是產品和評估，列幾點：
1、需要明確具體推薦的是什麼資源（query,氣象怪狀的阿拉丁，還是商品等等），他們展現的樣式不同，在做得比較細緻的情況下，策略也是很不同的。
2、先從產品角度說，如果是有用戶搜索query的前提下，搜索引擎不會對url或者是阿拉丁（除推薦拉丁外）做推薦的，因為搜索引擎目的是要幫用戶找到明確需求的結果，發散性質的需求一般排後面，用戶也不怎麼點。但是對query會進行推薦，也就是現在的相關搜索（relative search),一般在網頁底部 當用戶沒找到他想要的結果的時候這個很有用，比如query="去哪兒"， 出現的是去哪兒網，或者是爸爸去哪兒，講究的是多樣性。在淘寶網中，搜索頁最下面一欄也是推薦，類似。在有query的前提下，幫助用戶找到需求的還是搜索出來的結果，推薦是幫助沒找到需求的情況下去發散，這個對於準確度的要求是和搜索結果不能比的。所以你一定要找到合適的評估指標（用戶到推薦區域後，點擊率，翻頁率，換query等等要綜合去看。
3、從技術角度出發，具體結合這個產品來說，主要是途徑和媒介大概是三種：搜索結果的相關性，用戶行為日誌，以及query和資源本身的內容，每個都可以把特徵做細，最後也可以結合起來的。初期，我覺得用點擊行為比較好，用戶搜索了還搜索了什麼，或者是query點了什麼url,共同的url，相似的url是不是兩個query也相似，具體方式可以嘗試使用random walk的思想，基於這個思想的技術有一些（比如simrank＋＋），很多方法也值得調研，不列了。特別要注意，不要把這個問題變成query改寫或者是搜索，產品是不同的。題主說的不是搜索推薦吧，應該是用機器學習來完成搜索的rank
推薦閱讀：
※會游泳和不會游泳哪個溺死的概率大？
※網路遊戲的基本數據埋點都有哪些？
※假如你來設計知乎的數據分析系統，除了最基本的數據外(用戶量，DAU等等），你都會衡量什麼？
※如何開始做商業智能項目，需要注意些什麼呢？
※哪裡下載各種行業數據報告？