搜索場景下的智能推薦演變之路

摘要：傳統的推薦手段主要仍是深度挖掘用戶行爲和內容自己類似性的價值，包括但不限於協同過濾，內容表徵+向量召回，以及各式各樣的點擊率預估模型，而後這樣的推薦行爲缺少內在的邏輯性和可解釋性，有一種知其然，不知因此然的體感。本文中，阿里巴巴高級算法專家王悅就爲你們分享了搜索場景下的智能推薦演變之路。

演講嘉賓簡介：王躍（躍神），阿里巴巴高級算法專家。浙江大學碩士畢業，阿里巴巴高級算法專家，加入阿里巴巴以來一直致力於研究搜索推薦相關技術，相關工做包括天然語言處理，查詢詞分析技術研究，知識圖譜數據構建，實體推薦等多個不一樣方向。當前是夸克瀏覽器智能推薦業務業務負責人，致力於推進推薦從傳統的用戶行爲推薦向知識化推薦的升級，從而提高用戶信息獲取信息的邊界，加快信息決策的效率。

本次分享將首先介紹神馬搜索在推薦領域有哪些應用場景，以後爲你們分享在神馬搜索的推薦系統中所作的召回和排序相關的工做。

1、概覽

場景介紹

首先爲你們介紹神馬搜索的推薦場景有哪些，好比你們在向搜索框輸入內容以前，搜索框就會提供一些預置的搜索詞，這屬於沒有搜索Query的推薦。其次，若是你們點擊網頁以後返回結果，神馬搜索會在URL下面提供一些相關的Query，這是與URL自己相關的推薦。再次，還有Query推薦和相關搜索，這中推薦的主要目的是引流，國內的搜索引擎基本上都是商業化的產品，所以經過這樣的推薦方法就可以很好地吸引一些流量進來。此外，還有體感比較好的實體推薦，以及在內容消費頁面所作的相關推薦。

推薦大體能夠分爲三個階段，首先在輸入以前，神馬搜索引擎會基於用戶畫像以及其餘的一些相關推薦技術將一些內容推薦給用戶；第二個階段就是在搜索的結果頁進行推薦；最後一個階段就是在內容頁面上作一些相關推薦。從另一個維度上來看，推薦也能夠分爲三個部分，分別爲沒有Query的推薦、有Query的推薦以及基於URL的推薦。

技術大圖

正以下圖所展現的，推薦的業務應用場景很是多，所以不管是從橫向仍是縱向上進行劃分，均可以將推薦劃分爲多個視角。而若是對於每種推薦都從頭至尾搭建一套系統，那麼成本將會很是高，而UC團隊有一套比較通用的技術體系來支撐以下圖所示的推薦相關業務。搜索場景下智能推薦的技術大圖能夠大體分爲三個部分，最底層是數據以及數據相關的梳理；其上層就是經過召回以及排序等手段對於數據進行必定的處理；最上面一層就是使用處理好的數據來支撐業務。

對於上層大部分的推薦場景而言，所採用的召回方法基本都是相同的，而所採用的排序方法每每不一樣。好比對於預置詞這種業務而言，它是沒有Query的，所以在作模型設計的時候就沒法利用這些信息。

2、召回

接下來爲你們總體地介紹一下推薦系統中的召回體系，在本次分享中只會涉及其中比較通用的4種召回方法，但實際上召回體系遠遠不止這4種，一些比較通用的召回方法沒有在本文中列出。

用戶行爲召回

在召回部分介紹的第一種方法就是用戶行爲召回，也就是去深挖用戶行爲的價值。用戶行爲的挖掘是搜索引擎推薦的重要環節，這部分會針對於用戶行爲作兩件事情。第一件事情就是從Session的角度來分析哪些Query常常會出如今一塊兒，這樣分析也會遇到一些問題，好比首先要去區分Session裏面不一樣的Query類型，在搜索引擎裏面能夠本身主動地發起一次搜索，也能夠本身去點擊一些推薦結果。可是這兩種行爲存在必定的區別，好比主動搜索和被動經過推薦來搜索是不一樣的，主動搜索行爲每每會得到較高的分數，若是在比較靠後的位置點擊了推薦結果和在相對比較靠前的位置點擊了推薦結果的行爲也是不一樣的。所以，在這裏須要對於不一樣類型的行爲作一些權重計算，同時作一些比較機器化的規則，好比在某一個Session裏面，某一個Query是用戶最後一次搜索，此時就須要去考慮這個Query是否是已經知足了用戶需求，所以會對於這些Query加必定的權重。

第二個問題就是時效性優化問題，對於一些頭部的Query而言，可能一天以內就能達到幾萬甚至十萬的量級。對於這樣的Query，一般的作法就是拉一個時間窗口去看全部Session裏面Query的狀況如何。但實際上對於這些頭部的Query沒有任何意義，由於其一天的數據就足夠分析了，所以在這種狀況下會作一些採樣；對於一些長尾的Query則會作一些時間窗口的拉長操做。第三個問題是稀疏優化，對於前面所提到的基於URL的推薦而言，一般的作法就是收集用戶點擊了URL以後又搜索了哪些Query的行爲，可是這種狀況下點擊的URL每每是很稀疏的，所以會使用URL下面自己的一些與Title類似的Doc共享推薦的List實現基於文本的泛化，或者經過類似Query共享推薦List實現基於行爲的泛化，這樣一來推薦的效果和覆蓋率都會有極大的提高。

行爲分析

下圖展現的是協同過濾算法，可是經典的協同過濾算法每每存在一些問題，好比同一個Item權重的分配而言，在行爲很是豐富的用戶和行爲較少的用戶之間，可能更加傾向於前者。

可是這樣的作法並不必定合理，所以咱們複用了集團的一些成果，作了兩點主要的改進，第一個就是儘可能地下降行爲特別豐富的用戶的比重，使得其相對比較平滑。第二個就是構建如上圖所示的菱形結構，進而達到閉環的效果，使得推薦的理由更增強烈一些。綜上所述，能夠從入度出度、行爲豐富度不一樣等閉環的結構上面作優化，來提高總體協同過濾類算法的效果。

標籤召回

基於標籤的召回與基於用戶畫像的召回很是相似，對於用戶畫像而言，如今業界比較傳統的作法就是在用戶身上打上各類各樣的標籤，好比性別、年齡以及愛好等。所以，這裏將基於標籤的召回和基於用戶畫像的召回合在一塊兒講解。這裏列舉了一個例子就是在作APP推薦時如何去分析偏長尾的標籤，好比搜索「什麼軟件拍照帶耳朵？」時可以發現很是豐富的問答數據，而且發現Faceu這款APP在答案裏面。而若是其餘的問答網站裏面反饋出了其餘的APP，就能計算出Faceu和其餘拍照APP之間存在很是強大的相關性，這樣一來能夠作一些關聯的推薦，而且能夠標註出其推薦者。

標籤召回主要包括兩個步驟，第一步就是創建比較完整的標籤體系，將標籤概括到比較稀疏的鏈路下面去。在定義好這些鏈路體系以後，第二步就能夠分門別類地去進行挖掘，這裏的挖掘相對而言仍是比較傳統的，好比先分取一些Query，而後去判斷有哪些數據，並對於已有的數據進行一些標註，作一些標籤的識別，以後進一步擴大。當咱們累積到必定量以後，就能夠嘗試藉助有監督的方法實現進一步的泛化。

知識圖譜召回

基於知識圖譜的召回是最近一段時間內在學術界比較火的方法。UC團隊在基於知識圖譜的召回方面也作了大量的嘗試，大體分析了一下有這樣幾類算法，好比文本建模算法DLA和Doc2vec，知識表示算法tranE、transH、transD以及transR，網絡關係算法DeepWalk、Node2Vec以及SNDE等。文本建模算法基本上都是無監督學習，所以沒有辦法很好地利用關係網絡，主要是利用文本信息；知識表示算法對於關係的稠密度要求很是高，若是關係稠密度沒有達到要求，那麼採樣效果就會很是差；基於深度學習的網絡關係算法便可以結合文本信息也能夠融合關係網絡。綜上所述，基於深度學習的網絡關係算法相對而言比較中庸一點，可以同時利用文本和網絡信息，總體效果也會相對好一些。

UC團隊主要針對Node2vec的基礎版本作了一些優化。之因此優化Node2vec是由於其具備深度優先和廣度優先的機制，可以使得其整個訓練過程和方向變得可控。Node2vec的過程主要能夠分爲3部分，主要就是以知識圖譜這個圖關係網絡爲基礎作隨機遊走，而且控制隨機遊走須要深度優先仍是廣度優先，深度優先會更加關注全局信息，而廣度優先則會更加關注Doc信息。UC團隊在Node2vec上面主要作了兩方面優化，一個是數據增廣，也就是增長了用戶行爲數據以及百科數據和超連接數據，將這些數據抽取出來實現層級化，這樣就可以在必定程度上解決網絡稀疏的問題。第二個優化點就是利用深度學習中一個比較好的方法，也就是利用文本信息作embedding，好比在知識圖譜裏面某一我的物有相應的描述，能夠對於這些描述信息進行切詞並embedding到網絡中來。

向量召回

基於向量的召回也是最近幾年在學術界和工業界中比較熱門的方法。向量召回的出發點就是分析輸入的Query或者用戶與候選的推薦Query之間的文本語義匹配問題。這個模型是YouTube在2016年發的一篇論文中提出的，UC團隊在此基礎上進行了改進，好比對於Query以不一樣的粒度進行切詞。此外，Query還會有一些文本特徵，好比檢索切詞、語義切詞等，還會將用戶畫像的特徵以及實時信息特徵一塊兒訓練來提高模型的性能。

下圖所展現的是向量召回的效果圖，左邊的第一列是訓練的特徵，第二列是召回的數據，第三列是真實的搜索Query。對於向量召回方法而言，有一些優化的方法，好比線上存在真實的排序狀況，那麼能夠將線上真實狀況和線下召回的狀況作一個比較，從而大體瞭解向量召回的優點狀況以及準確率如何。

3、排序

基礎相關性

在排序部分首先介紹基礎相關性。下圖中展現了一個Query例子「泰勒級數展開公式」。在線上首先會對於這個Query作切詞，切詞完成以後，每一個Token都會召回一系列的候選Doc，此時會出現一系列的問題，由於已經將Query切成Token了，因此極有可能產生的Doc結果和原始的Query是不相關的，由於切分以後沒法獲得足夠的Query信息。此時，須要藉助相關性模型大體地控制所獲取的文本與原始Query的相關性，將相關性特別低的候選Doc在這一步過濾掉。在模型設計時也會考慮一些應用的場景，好比在作實體推薦時就會將Query裏面實體的信息引入進來，進而實現共享網絡。

若是將Query分類信息引入進來就能很好地解決一些歧義的問題。

CTR預估

UC團隊在兩年前作了CTR預估的相關工做，那個時候其餘的一些方法尚未成熟，所以這部分作的相對比較簡單，主要的工做集中在樣本的選擇以及特徵的選擇上面。對於樣本選擇而言，一般會在一個推薦序列裏面將點擊過的結果做爲正樣本，將沒有被點擊過的結果做爲負樣本。在模型設計方面，比較重要的是CTR類特徵，若是這個特徵不佳就會使得整個模型的特徵打一個比較大的折扣。而UC團隊所實現的CTR預估模型可以達到小時級更新，保證線上的效果。

MAB

MAB的意思就是「多臂老虎機」，好比一個老虎機有多種能夠玩的方法，咱們一開始不知道哪一種方法才能獲勝，所以須要逐個實驗每種玩法獲勝的概率是多少，最終去肯定應該以什麼順序來玩。這和排序是很是相關的，由於在推薦時若是直接使用CTR排序可能致使一些比較好的潛在的推薦Item由於剛剛出來，沒有被不少用戶點擊過，就會致使其永遠沒法排在前面。此時就須要藉助一個探索機制來緩解這樣的問題，也就是當使用CTR排序完成以後，並不徹底按照CTR去提供排序結果，而是使得全部的推薦候選項都有必定的機率被選中。若是常常性地進行探測，那麼推薦結果也會逐漸地收斂。

小結

這裏簡單作一個總結，在本文中已經介紹了大部分的推薦算法。對於召回而言，從精準到泛化基本上能夠分爲基於檢索的召回、基於標籤的召回、協同過濾、基於知識圖譜的召回以及基於向量的召回。對於排序而言，也介紹了基礎相關性、語義相關性以及CTR預估和MAB。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。