摘要：傳統的推薦手段主要還是深度挖掘使用者行為和内容本身相似性的價值，包括但不限于協同過濾，内容表征+向量召回，以及各式各樣的點選率預估模型，然後這樣的推薦行為缺乏内在的邏輯性和可解釋性，有一種知其然，不知是以然的體感。本文中，阿裡巴巴進階算法專家王悅就為大家分享了搜尋場景下的智能推薦演變之路。
以下内容根據演講視訊以及PPT整理而成。
點選檢視阿裡巴巴AI智能專場直播
演講嘉賓簡介：王躍（躍神），阿裡巴巴進階算法專家。浙江大學碩士畢業，阿裡巴巴進階算法專家，加入阿裡巴巴以來一直緻力于研究搜尋推薦相關技術，相關工作包括自然語言處理，查詢詞分析技術研究，知識圖譜資料建構，實體推薦等多個不同方向。目前是誇克浏覽器智能推薦業務業務負責人，緻力于推動推薦從傳統的使用者行為推薦向知識化推薦的更新，進而提升使用者資訊擷取資訊的邊界，加快資訊決策的效率。
本次分享将首先介紹神馬搜尋在推薦領域有哪些應用場景，之後為大家分享在神馬搜尋的推薦系統中所做的召回和排序相關的工作。
一、概覽
場景介紹
首先為大家介紹神馬搜尋的推薦場景有哪些，比如大家在向搜尋框輸入内容之前，搜尋框就會提供一些預置的搜尋詞，這屬于沒有搜尋Query的推薦。其次，如果大家點選網頁之後傳回結果，神馬搜尋會在URL下面提供一些相關的Query，這是與URL本身相關的推薦。再次，還有Query推薦和相關搜尋，這中推薦的主要目的是引流，國内的搜尋引擎基本上都是商業化的産品，是以通過這樣的推薦方法就能夠很好地吸引一些流量進來。此外，還有體感比較好的實體推薦，以及在内容消費頁面所做的相關推薦。
推薦大緻可以分為三個階段，首先在輸入之前，神馬搜尋引擎會基于使用者畫像以及其他的一些相關推薦技術将一些内容推薦給使用者；第二個階段就是在搜尋的結果頁進行推薦；最後一個階段就是在内容頁面上做一些相關推薦。從另外一個次元上來看，推薦也可以分為三個部分，分别為沒有Query的推薦、有Query的推薦以及基于URL的推薦。
技術大圖
正如下圖所展示的，推薦的業務應用場景非常多，是以無論是從橫向還是縱向上進行劃分，都可以将推薦劃分為多個視角。而如果對于每種推薦都從頭到尾搭建一套系統，那麼成本将會非常高，而UC團隊有一套比較通用的技術體系來支撐如下圖所示的推薦相關業務。搜尋場景下智能推薦的技術大圖可以大緻分為三個部分，最底層是資料以及資料相關的梳理；其上層就是通過召回以及排序等手段對于資料進行一定的處理；最上面一層就是使用處理好的資料來支撐業務。
對于上層大部分的推薦場景而言，所采用的召回方法基本都是相同的，而所采用的排序方法往往不同。比如對于預置詞這種業務而言，它是沒有Query的，是以在做模型設計的時候就無法利用這些資訊。
二、召回
接下來為大家整體地介紹一下推薦系統中的召回體系，在本次分享中隻會涉及其中比較通用的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。對于向量召回方法而言，有一些優化的方法，比如線上存在真實的排序情況，那麼可以将線上真實情況和線下召回的情況做一個比較，進而大緻了解向量召回的優勢情況以及準确率如何。
三、排序
基礎相關性
在排序部分首先介紹基礎相關性。下圖中展示了一個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。
阿裡雲開發者社群整理