建站
咨詢
售后
建站咨詢
新聞中心
【稿件】 推薦系統(tǒng)的核心排序算法已經(jīng)從傳統(tǒng)的 LR、GBDT 等模型進化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和傳統(tǒng)模型相結合的階段。
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于做網(wǎng)站、網(wǎng)站設計、遼陽網(wǎng)絡推廣、微信小程序定制開發(fā)、遼陽網(wǎng)絡營銷、遼陽企業(yè)策劃、遼陽品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供遼陽建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
如何結合各個業(yè)務數(shù)據(jù)的特點，設計合適的深度推薦算法，同時設計合理的架構保證深度學習算法的穩(wěn)定運行，成為企業(yè)在推動基于深度學習的推薦系統(tǒng)落地的難點。
2018 年 11 月 30 日-12 月 1 日，由 主辦的 WOT 全球人工智能技術峰會在北京粵財 JW 萬豪酒店隆重舉行。
本次峰會以人工智能為主題，360 人工智能研究院的技術經(jīng)理張康在推薦搜索專場與來賓分享"基于深度學習的推薦系統(tǒng)在 360 的應用"的主題演講，為大家詳細闡述在 360 的各種場景下，基于深度學習的推薦系統(tǒng)的各種應用。
本次分享分為如下兩大部分：
- 推薦系統(tǒng)相關算法***研究進展
- 深度推薦系統(tǒng)在 360 的應用實踐
推薦系統(tǒng)相關算法***研究進展
在介紹應用系統(tǒng)之前，首先讓我們從抽象的層次上理解一下，在圖像領域的相關概念。
上圖是我們對推薦系統(tǒng)的一個分層與抽象。在頂層，我們可以理解為是一個函數(shù)。
其中 U 代表用戶、I 代表需要推薦的商品、C 代表上下文、Y 則是我們需要優(yōu)化的目標。
當然，不同的應用場景，Y 的取值會有一定的差異。如果我們的目標是點擊率的話，那么 Y 的取值就是 0 和 1。
而如果我們要預估某個時長的話，那么 Y 的取值就變成了實數(shù)，它對應的就是某個回歸問題?？梢?，根據(jù)不同的場景，定義好 Y 是至關重要的。
如果是從算法人員的角度出發(fā)，他們會認為定義 Y、和對 F 求解的優(yōu)化是非常重要的。
而在業(yè)務方的那些做產(chǎn)品的人看來，U 的反饋則更為重要，如果出現(xiàn)用戶投訴的話，那么該算法也就失敗了。
另外，他們也會關注 I。由于 I 的背后實際上關聯(lián)的是商家，那么同樣要避免出現(xiàn)用戶對于 I 的抱怨?？梢?，不同角色對于此公式的關注點是不相同的。
在上面抽象圖的中間，我們一般會把頂層簡單的數(shù)學公式拆分成三個不同的算法模塊：
- 召回（Recall）
- 排序（Rank）
- 策略（或稱重排序 Rerank）
目前市面上的一些工業(yè)領域和學術界的論文，大部分會重點研究和討論 Rank，畢竟 Rank 是非常重要的。
而對于那些針對 Recall 和 Rerank 的技術而言，由于它們并不適合被抽象成為一個統(tǒng)一的理論架構，因此相關的論文也不多。后面我們會重點討論有關召回部分的內(nèi)容。
經(jīng)歷了上面兩個抽象層次，圖中的底層就需要讓推薦系統(tǒng)服務于“線上”了。
它由五大關鍵部分所組成：
- ETL 對數(shù)據(jù)的清洗。不同于那些已經(jīng)準備好了數(shù)據(jù)集的傳統(tǒng)競賽，我們面臨的是在真實的線上場景中所產(chǎn)生的日志數(shù)據(jù)，它們不但“臟”，而且體量非常大。
因此，我們需要有一個對應的數(shù)據(jù)清洗場景，以緩解系統(tǒng)的處置壓力。
- Server 模塊。針對各種排序和召回的模型場景，我們需要提供實時的服務。
因此服務端不但需要具有高性能的計算能力，同時也需要我們的架構能夠應對大規(guī)模的深度學習與計算。如有必要，還可能會用到 GPU 等硬件。
- Platform。這里主要是指深度學習或者機器學習的訓練平臺。在各種算法上線之后，隨著在線學習的推進，其模型不可能一成不變。
有的它們需要被“日更”，甚至是以分鐘為單位進行更新。因此我們需要有一個良好的深度學習平臺提供支持。
- 測試。推薦系統(tǒng)在上線之后，需要被不斷的迭代與優(yōu)化，因此我們需要通過測試來查看效果。
在系統(tǒng)的起步階段，用戶數(shù)量迅速上升，而實驗的整體數(shù)量則不多，因此我們很容易通過對***用戶的切分，來開展與流量相關的實驗。
但是隨著業(yè)務的發(fā)展，用戶數(shù)量不再呈爆發(fā)式增長，而我們每天又需要進行成百上千次實驗，所以我們需要選用 A/B 測試的實驗平臺，以方便算法人員加速迭代的進程。
- 報表。之前在與業(yè)務方合作時，我們發(fā)現(xiàn)：他們幾乎每個人都在通過自行編寫簡單腳本的方式獲取所需的報表，因此其工作的重復度相當高。
然而，由于許多報表的計算都是簡單算子的累加，如果我們擁有一個簡單且統(tǒng)一的平臺，就能夠幫助大家獲取常用的指標，進而加速整個系統(tǒng)的迭代。
從深度推薦系統(tǒng)的發(fā)展來看，最早出現(xiàn)的是傳統(tǒng) LR（線性回歸）的機器學習。
之后，隨著特征交叉需求的增多，出現(xiàn)了非線性回歸和使用 FM 來實現(xiàn)二階特征交叉。
近年來，隨著深度學習在圖像領域的廣泛應用，如今大家也將它們引入到了推薦系統(tǒng)之中。
不過，相對于圖像領域動輒一兩百層的神經(jīng)網(wǎng)絡深度而言，推薦系統(tǒng)的深度只有四到六層。
如今各家“大廠”都能夠提供諸如 FNN、DFM、以及 Google Wide&Deep 之類的算法，我們很難斷言哪種模型更好。
因此大家在進行模型選取的時候，應當注意自己的系統(tǒng)偏好，保持與業(yè)務的強關聯(lián)性。
上圖借用的是阿里的 DIEN（Deep Interest Evolution Network），他們和我們現(xiàn)在的工作有著相似之處，特別是圖中虛線框里的兩個創(chuàng)新點。我會在后面進行著重分析。
平時，我們在閱讀各種論文時，很容易產(chǎn)生一種錯覺：那些作者為了突出自己的貢獻，經(jīng)常會著重描寫模型上的創(chuàng)意，體現(xiàn)并抽象其核心的思想，讓大家認為該部分的占比能達到 80%。
而實驗部分都只是一些標準的數(shù)據(jù)集，經(jīng)常一筆帶過。實際上，他們在模型側的工作量一般只有 20%，其他的 80% 則花在了做實驗上。
具體說來，我們可以開展如下各種實驗：
- 在拿到原始的線上日志數(shù)據(jù)之后，我們需要對它們做分析、統(tǒng)計和處理，以方便我們后期進行模型訓練。
- 特征設計、交叉和服務，包括：是否要將特征值離散化，是否要放大時間窗口等。
- 模型選擇，我們需要全面考慮計算的開銷，甚至要考慮自己的平臺上是否有 GPU，倘若沒有，則不應選擇過于復雜的模型。同時，我們也要根據(jù)核心算法，制定召回和仲裁策略。
- ***是真正傳統(tǒng)意義上的實驗，包括離線評測、線上 A/B 和實驗分析等，這些都會與前面的四項有所關聯(lián)。
深度推薦系統(tǒng)在 360 的應用實踐
下面，我們來討論一下深度推薦系統(tǒng)在 360 中幾個場景應用的落地。如圖的三款應用在技術上呈由淺入深、由簡單到復雜的遞進關系。
場景一：App 推薦
360 手機助手，類似于應用市場。圖中紅框里顯示的都是系統(tǒng)推薦的內(nèi)容，包括：“今日熱點”和“大家都在玩”等，這些都是與用戶的個性化喜好相關的。我們直接從用戶的下載和轉化率，來判定系統(tǒng)推薦的效果。
套用前面提到的三個層次：
- 抽象定義層。由于我們做的是一個離線系統(tǒng)，因此我們對 C 考慮并不多，主要將重點放在了 U 和 I 上。該場景下的 U 屬于億級，而 I 只有萬級，畢竟我們只需要在萬級的 App 庫里做推薦。
- 算法策略層。由于 I 的量級比較小，我們當時就“簡單粗暴”地直接在這個萬級用戶庫里做了用戶匹配和推薦，而并沒有執(zhí)行召回策略。我們首先通過簡單的算法做出了一個初版模型。
為了查看效果，我們通過迭代、優(yōu)化和序列預測，來預測用戶下一次會安裝哪一種 App。而 Rank 和 Rerank 部分的邏輯，由于主要涉及到各種線上的業(yè)務邏輯，因此是由業(yè)務方來完成的。
- 架構層。它對應的是我們的天級離線中心，在特征上并不復雜，僅通過 Embedding 特征的運用就完成了。
上圖是我們對于模型的邏輯進化路徑。上圖的左側與 Google Wide&Deep 的思路是很相似的，只不過我們用的特征非常少。
上方藍色部分是用戶 App 序列的 ID 列表，我們使每個 App 都有一個特征向量，然后做若干層的 MLP，***做分類，從而預測某個用戶下一步可能安裝的 App。
后來，隨著與業(yè)務人員的交流，我們在模型中加入了用戶的瀏覽歷史、搜索歷史、關鍵詞特征、和 App 特征等元素，不過其本質(zhì)上也都是行為的序列。
考慮到簡單的 MLP 已不太適合，因此我們就嘗試采用了 RNN 的方法進行數(shù)據(jù)建模，于是就有了如下圖進化后的網(wǎng)絡：
雖然該圖的上層分類與前面類似，但是下面的 browse 卻值得大家注意：當你把用戶的搜索行為加到自己的特征里時，請注意調(diào)整時間序列，不然很容易會導致該搜索詞變成了一個搜索系統(tǒng)。
即：你的本意是通過用戶的搜索詞，來反應他的興趣，并預測他要下載的 App。
但是，如果不做處理的話，就可能導致你的系統(tǒng)只是在模擬某個線上的搜索。
上面這張圖是將兩個模型的不同結果進行了比較。它們分別對每個 App 的 Embedding 向量進行了可視化。我們將 App 的 Embedding 向量取出，并投影到二維圖上。
我們根據(jù) App 原來所隸屬的大類，來判斷經(jīng)過模型學習后，如果能將大類拉得比較散的話，那么效果就會更好些。
可見，在左邊 MLP 的中間，各種類型的交疊比較嚴重。而在我們換成了 RNN 模型之后，它們就顯得分散了許多。我們籍此來直觀地認為改進后的模型更好。
根據(jù)上面將 RNN 的效果與 MLP 的效果所進行的數(shù)據(jù)比較，我們可以看出：在 Top1 上的差異并不太大，僅提升了 1 個點。
當然，這可能對于線上系統(tǒng)的提升會反應得顯著一些，但是對于我們的離線系統(tǒng)，提升反應就沒那么明顯了。這便是我們整個團隊在推薦領域的***次試水。
場景二：360 搜索和導航
有了前面 App 推薦的經(jīng)驗積累，我們嘗試的第二個項目是“常搜詞”。即：360 頁面有自己的搜索和導航，而在搜索框的下方，我們會放置六到七個用戶經(jīng)常搜索、或者是時常用到的關鍵詞。
如此，用戶在打開導航時就能看到自己想看的東西，這不但減少了他們在操作上的復雜度，還提升了用戶在使用上的滿意度。
在該場景下，由于我們的導航每天都有好幾億次的 PV（Page View），因此使用該功能的用戶有著***的體量，即 U 為***。
同時，為了定義“常搜詞”，我們對 query（查詢）進行了清洗，過濾掉了一些非?！伴L尾”的 query，只留下一些有實體字的、較為明確的 query。因此，此處的 I 就根據(jù) query 的數(shù)量被設定為了***。
由于該業(yè)務本身已存在了較長時間，因此在算法策略上也已實現(xiàn)一些較為完善的召回（Recall），例如：
- 搜索詞：是根據(jù)用戶的搜索行為，召回一些新的關鍵詞。
- URL：是根據(jù)用戶瀏覽器里面的瀏覽記錄，再輸入一些關鍵詞。
- 廣告：是通過滿足用戶的興趣匹配，精準地投放商業(yè)化的廣告詞。
- 百科：是判斷用戶可能感興趣的知識，投放相應的百科詞匯。
另外在 Rank 方面，我們著手將線上系統(tǒng)從以前簡單的 LR+FTRL，升級并優(yōu)化成為了 DNN 模型。
在架構上，由于該導航系統(tǒng)的特點是用戶使用頻次不高，而我們的推薦可能每天只會被早晚各用一次，因此我們的目標是天級離線更新。
其對應的特征部分，則主要是基于用戶的搜索日志和瀏覽日志，來進行的一些統(tǒng)計特征的設定。
讓我們來看看其中幾個權重比較正向的特征，例如：
- week_freq_num 特征，描述了用戶常搜詞匯的概率分布，即：如果某個用戶在過去一段時間窗口內(nèi)成均勻的訪問趨勢，則說明這是經(jīng)常性的需求。該特征比較重要。
- global_query_uv 特征，此類全網(wǎng)特征能夠在一定程度上反映商品的質(zhì)量。我們籍此在原有特征的基礎上擴展到成千上萬個。
在我們將模型調(diào)整成為 DNN 之后，系統(tǒng)的 AUC 從 7 提到 8。之后我們還增加了一些其他能夠提升 AUC 的特征。
為了細粒度地分析 DNN 模型的召回策略在上線之后所產(chǎn)生的影響，我們拿它與傳統(tǒng)的 LR+FTRL 模型進行了對比。
途中兩處 CTR 較高，它們都與用戶的搜索和瀏覽行為相關，并且能夠真正反映他們的需求。
由于此類搜索、瀏覽和 MLP 的點擊率本身就比較高，因此我們需要在此基礎上有一個量的提升。
另外在上圖中，雖然與個性化相關的廣告部分略有提升，但是 ys_mid_hist 是有所下跌的。
通過分析，我們發(fā)現(xiàn)該模型當時在排序時，傾向于把策略后排，其導致的結果是：用戶在界面上默認只能看到六個推薦詞，而實際上其旁邊有一個往下點的箭頭，在被點擊之后才會出現(xiàn)很多的詞匯。
因此，如果某些推薦詞匯被排到了第六名之后的話，那么它們被點擊的可能性就非常小。這也說明了默認六個詞的重要性。
同時，這也提示了我們：在做數(shù)據(jù)時，需要重點關注那些用戶通過點擊下拉按鈕去訪問的詞匯，那些數(shù)據(jù)才更能夠說明用戶對某些詞匯的強烈需要?？偟恼f來，我們協(xié)助業(yè)務側將 2017 年 Q1 的收入提升了 5%。
場景三：快視頻
基于前面兩個項目所積累的經(jīng)驗，我們?nèi)榈赝度肓说谌齻€項目—快視頻。其主要的業(yè)務形式是個性化的消息推送，與大家手機上的通知欄推送相類似。
但是，略有不同的是：我們并非每日都定時推送，而是會根據(jù)用戶的反饋偏好，去調(diào)整推薦的數(shù)量、頻率和時間。
同時，這對于將一些尚未養(yǎng)成每日到我們的 App 里觀看視頻的用戶來說，能夠起到一定“拉活”的作用。
在此，我們?nèi)匀惶子们懊娴娜齻€層次。在頂層，由于該 App 上線之后，視頻庫的規(guī)模和用戶的數(shù)量都增長得非常迅速，因此 U 和 I 都具有***。
在召回策略上，圖中列出了五種重要的召回。前三項分別是：語義、視覺和行為召回。我們統(tǒng)一地對它們進行了重點優(yōu)化。
而在距離用戶更近的 Rank 部分，我們通過收斂，采用了 LSTM + Attention 的模型。
前面介紹過的兩個項目都僅僅是以天為單位進行更新，因此對算法人員的壓力并不大，只需采用定時任務便可。
而在這個場景中，由于它是一個對用戶進行實時在線推薦的系統(tǒng)，如果采用“天級更新”頻率的話，會給用戶帶來較差的體驗。
因此無論是對召回的數(shù)據(jù)流、模型的更新、還是在線的服務，我們都認真進行了架構設計。
我們來看看剛才提到的三個召回策略：行為、語義和視覺。在此，我們將它們統(tǒng)一到了 Embedding 框架之中，以便從視頻的不同角度進行描述和特征表示，而不必關心后續(xù)有關設計域值、隊列長度等問題。
通過執(zhí)行統(tǒng)一的流程，我們能夠更直觀的體現(xiàn)出各種視頻在特征領域下召回的根據(jù)。
例如圖中黑體字是某個視頻的 title（標題），明顯，它是有關傳授烹飪知識的召回：
- 就行為模型而言，它通過對用戶行為序列的協(xié)同與分割，為每個視頻分配各種特征向量。
其特點是：會產(chǎn)生一定的擴散效果。即，你會在上圖中發(fā)現(xiàn)，該召回的前兩個結果已經(jīng)不再關注烹飪，而是擴散到了其他領域。只有第三個召回才是真正有關于烹飪的。
- 語義模型，重點關注的是視頻標題的語義表示，通過語法和語義的相似性，此類召回能夠抓住標題中關鍵性的動詞與名詞，然后進行相應的交叉和擴散等操作。
- 視覺模型，是通過抽取視頻的特征，來實現(xiàn)召回。它與標題的語義關聯(lián)性不強，就算標題與烹飪無關，只要在視頻中大量出現(xiàn)食物的圖像，便可以表示并召回。
由上可見，我們通過不同的 Embedding，就可以實現(xiàn)多樣的召回策略。
下面我們重點介紹語義模型。我們所得到的輸入數(shù)據(jù)是公司過往生成的查詢、與搜索數(shù)據(jù)，或是其他的業(yè)務線積累的標簽數(shù)據(jù)，例如由網(wǎng)頁標題所抽象出來的簡單標簽。
這些標簽既有自動生成的，也有通過人工修正和 rebind（重新連接）產(chǎn)生的。它們都具有一定的實際價值。
為了給每個 title 產(chǎn)生相應的表征，我們構建了一項任務：首先是對每個句子進行分詞，以得到相應的字/詞向量，然后通過 CNN 網(wǎng)絡進行處理，***對目標予以多分類、多標簽，從而預測該標簽準確性。
對于上述任務，我們除了嘗試過 CNN 模型之外，還在不改變 task 的情況下試用了雙向的 LSTM，即 bi-LSTM。接著，我們需要對該語義模型進行評測。
在此業(yè)務場景下，我們?nèi)斯顺隽藥浊€具有良好多樣性的數(shù)據(jù)，并將其作為離線評測的指標，以此來檢查通過語義模型召回標注數(shù)據(jù)的結果相關性。上圖左側的表格就是我們測試的結果。
我們在此比較了幾種常見的語義建模的模型、及其對應的優(yōu)化。表格的中間列是 Title2Tags，即通過標題來預測對應的標簽。
至于右邊列：Title2UnionTags，我們對應地發(fā)現(xiàn)到：如果只有單個標題，則語義往往會被遺漏。
如上圖右側的例子所示：無論是人工寫的標題，還是自動生成的，如果我們將多個標簽放到一塊兒，句子中的語義則會更準確地被覆蓋到。
另外我們后續(xù)對數(shù)據(jù)的清洗，也能夠提升原句子的標簽數(shù)量，進而大幅提升模型的整體效果。
上圖是我們開篇引用過的阿里 DIEN，在其虛線框中有兩個創(chuàng)新點，分別是 AUGRU（即 Attention 與 GRU 的合并）和輔助的 loss。
雖然 loss 對模型的提升效果非常明顯，可惜我們在模型設計時，過于關注 Attention 的 layer 和下沉到用戶序列上的特征，因此我們將來尚有改進的空間。
上圖便是我們當時對不同排序模型的評測結果。
可見我們在系統(tǒng)架構的設計上，既有諸如到臺服務、日志搜集、和報表等離線部分，又有實時的在線更新。
同時，我們也與業(yè)務方的在線系統(tǒng)保持著實時性的交互，以便他們按需獲取推送的數(shù)據(jù)。另外在最上層，我們?yōu)闃I(yè)務方也提供了多種安全策略和分桶策略。
上圖便是我們從 2017 年 11 月 1 日到 2018 年 1 月 31 日的 CTR 曲線。
雖然有某些“坑點”所導致的曲線波動，但是整體趨勢還是向上的，特別是在我們更換了 Attention 模型之后，提升的幅度能夠達到 10%，進而有效地幫助業(yè)務方實現(xiàn)了“拉活”和保持更多的活躍用戶。
綜上所述，我們基于深度學習的推薦系統(tǒng)就是根據(jù)上述三個層次，一步一步地通過迭代和優(yōu)化發(fā)展起來的。
【原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為.com】
文章標題：一路打怪升級，360推薦系統(tǒng)架構演進
文章URL：http://fisionsoft.com.cn/article/djepphs.html
