歡迎光臨
每天分享高質量文章

值得借鑒:360推薦系統架構演進

 

推薦系統的核心排序演算法已經從傳統的 LR、GBDT 等模型進化到了 Deep&Wide;、DeepFM、PNN 等若干深度模型和傳統模型相結合的階段。

如何結合各個業務資料的特點,設計合適的深度推薦演算法,同時設計合理的架構保證深度學習演算法的穩定運行,成為企業在推動基於深度學習的推薦系統落地的難點。

360 人工智慧研究院的技術經理張康分享了”基於深度學習的推薦系統在 360 的應用”主題,為大家詳細闡述在 360 的各種場景下,基於深度學習的推薦系統的各種應用。

本次分享分為如下兩大部分:

  • 推薦系統相關演算法最新研究進展

  • 深度推薦系統在 360 的應用實踐

推薦系統相關演算法最新研究進展

在介紹應用系統之前,首先讓我們從抽象的層次上理解一下,在圖像領域的相關概念。

上圖是我們對推薦系統的一個分層與抽象。在頂層,我們可以理解為是一個函式。

其中 U 代表用戶、I 代表需要推薦的商品、C 代表背景關係、Y 則是我們需要優化的標的。

當然,不同的應用場景,Y 的取值會有一定的差異。如果我們的標的是點擊率的話,那麼 Y 的取值就是 0 和 1。

而如果我們要預估某個時長的話,那麼 Y 的取值就變成了實數,它對應的就是某個回歸問題。可見,根據不同的場景,定義好 Y 是至關重要的。

如果是從演算法人員的角度出發,他們會認為定義 Y、和對 F 求解的優化是非常重要的。

而在業務方的那些做產品的人看來,U 的反饋則更為重要,如果出現用戶投訴的話,那麼該演算法也就失敗了。

另外,他們也會關註 I。由於 I 的背後實際上關聯的是商家,那麼同樣要避免出現用戶對於 I 的抱怨。可見,不同角色對於此公式的關註點是不相同的。

在上面抽象圖的中間,我們一般會把頂層簡單的數學公式拆分成三個不同的演算法模塊:

  • 召回(Recall)

  • 排序(Rank)

  • 策略(或稱重排序 Rerank)

目前市面上的一些工業領域和學術界的論文,大部分會重點研究和討論 Rank,畢竟 Rank 是非常重要的。

而對於那些針對 Recall 和 Rerank 的技術而言,由於它們並不適合被抽象成為一個統一的理論架構,因此相關的論文也不多。後面我們會重點討論有關召回部分的內容。

經歷了上面兩個抽象層次,圖中的底層就需要讓推薦系統服務於“線上”了。

它由五大關鍵部分所組成:

  • ETL 對資料的清洗。不同於那些已經準備好了資料集的傳統競賽,我們面臨的是在真實的線上場景中所產生的日誌資料,它們不但“臟”,而且體量非常大。

    因此,我們需要有一個對應的資料清洗場景,以緩解系統的處置壓力。

  • Server 模塊。針對各種排序和召回的模型場景,我們需要提供實時的服務。

    因此服務端不但需要具有高性能的計算能力,同時也需要我們的架構能夠應對大規模的深度學習與計算。如有必要,還可能會用到 GPU 等硬體。

  • Platform。這裡主要是指深度學習或者機器學習的訓練平臺。在各種演算法上線之後,隨著在線學習的推進,其模型不可能一成不變。

    有的它們需要被“日更”,甚至是以分鐘為單位進行更新。因此我們需要有一個良好的深度學習平臺提供支持。

  • 測試。推薦系統在上線之後,需要被不斷的迭代與優化,因此我們需要通過測試來查看效果。

    在系統的起步階段,用戶數量迅速上升,而實驗的整體數量則不多,因此我們很容易通過對百萬級用戶的切分,來開展與流量相關的實驗。

    但是隨著業務的發展,用戶數量不再呈爆髮式增長,而我們每天又需要進行成百上千次實驗,所以我們需要選用 A/B 測試的實驗平臺,以方便演算法人員加速迭代的行程。

  • 報表。之前在與業務方合作時,我們發現:他們幾乎每個人都在通過自行編寫簡單腳本的方式獲取所需的報表,因此其工作的重覆度相當高。

    然而,由於許多報表的計算都是簡單算子的累加,如果我們擁有一個簡單且統一的平臺,就能夠幫助大家獲取常用的指標,進而加速整個系統的迭代。

從深度推薦系統的發展來看,最早出現的是傳統 LR(線性回歸)的機器學習。

之後,隨著特征交叉需求的增多,出現了非線性回歸和使用 FM 來實現二階特征交叉。

近年來,隨著深度學習在圖像領域的廣泛應用,如今大家也將它們引入到了推薦系統之中。

不過,相對於圖像領域動輒一兩百層的神經網絡深度而言,推薦系統的深度只有四到六層。

如今各家“大廠”都能夠提供諸如 FNN、DFM、以及 Google Wide&Deep; 之類的演算法,我們很難斷言哪種模型更好。

因此大家在進行模型選取的時候,應當註意自己的系統偏好,保持與業務的強關聯性。

上圖借用的是阿裡的 DIEN(Deep Interest Evolution Network),他們和我們現在的工作有著相似之處,特別是圖中虛線框里的兩個創新點。我會在後面進行著重分析。

平時,我們在閱讀各種論文時,很容易產生一種錯覺:那些作者為了突出自己的貢獻,經常會著重描寫模型上的創意,體現並抽象其核心的思想,讓大家認為該部分的占比能達到 80%。

而實驗部分都只是一些標準的資料集,經常一筆帶過。實際上,他們在模型側的工作量一般只有 20%,其他的 80% 則花在了做實驗上。

具體說來,我們可以開展如下各種實驗:

  • 在拿到原始的線上日誌資料之後,我們需要對它們做分析、統計和處理,以方便我們後期進行模型訓練。

  • 特征設計、交叉和服務,包括:是否要將特征值離散化,是否要放大時間視窗等。

  • 模型選擇,我們需要全面考慮計算的開銷,甚至要考慮自己的平臺上是否有 GPU,倘若沒有,則不應選擇過於複雜的模型。同時,我們也要根據核心演算法,制定召回和仲裁策略。

  • 最後是真正傳統意義上的實驗,包括離線評測、線上 A/B 和實驗分析等,這些都會與前面的四項有所關聯。

深度推薦系統在 360 的應用實踐

下麵,我們來討論一下深度推薦系統在 360 中幾個場景應用的落地。如圖的三款應用在技術上呈由淺入深、由簡單到複雜的遞進關係。

場景一:App 推薦

360 手機助手,類似於應用市場。圖中紅框里顯示的都是系統推薦的內容,包括:“今日熱點”和“大家都在玩”等,這些都是與用戶的個性化喜好相關的。我們直接從用戶的下載和轉化率,來判定系統推薦的效果。

套用前面提到的三個層次:

  • 抽象定義層。由於我們做的是一個離線系統,因此我們對 C 考慮並不多,主要將重點放在了 U 和 I 上。該場景下的 U 屬於億級,而 I 只有萬級,畢竟我們只需要在萬級的 App 庫里做推薦。

  • 演算法策略層。由於 I 的量級比較小,我們當時就“簡單粗暴”地直接在這個萬級用戶庫里做了用戶匹配和推薦,而並沒有執行召回策略。我們首先通過簡單的演算法做出了一個初版模型。

    為了查看效果,我們通過迭代、優化和序列預測,來預測用戶下一次會安裝哪一種 App。而 Rank 和 Rerank 部分的邏輯,由於主要涉及到各種線上的業務邏輯,因此是由業務方來完成的。

  • 架構層。它對應的是我們的天級離線中心,在特征上並不複雜,僅通過 Embedding 特征的運用就完成了。

上圖是我們對於模型的邏輯進化路徑。上圖的左側與 Google Wide&Deep; 的思路是很相似的,只不過我們用的特征非常少。

上方藍色部分是用戶 App 序列的 ID 串列,我們使每個 App 都有一個特征向量,然後做若干層的 MLP,最後做分類,從而預測某個用戶下一步可能安裝的 App。

後來,隨著與業務人員的交流,我們在模型中加入了用戶的瀏覽歷史、搜索歷史、關鍵詞特征、和 App 特征等元素,不過其本質上也都是行為的序列。

考慮到簡單的 MLP 已不太適,因此我們就嘗試採用了 RNN 的方法進行資料建模,於是就有瞭如下圖進化後的網絡:

雖然該圖的上層分類與前面類似,但是下麵的 browse 卻值得大家註意:當你把用戶的搜索行為加到自己的特征里時,請註意調整時間序列,不然很容易會導致該搜索詞變成了一個搜索系統。

即:你的本意是通過用戶的搜索詞,來反應他的興趣,並預測他要下載的 App。

但是,如果不做處理的話,就可能導致你的系統只是在模擬某個線上的搜索。

上面這張圖是將兩個模型的不同結果進行了比較。它們分別對每個 App 的 Embedding 向量進行了可視化。我們將 App 的 Embedding 向量取出,並投影到二維圖上。

我們根據 App 原來所隸屬的大類,來判斷經過模型學習後,如果能將大類拉得比較散的話,那麼效果就會更好些。

可見,在左邊 MLP 的中間,各種型別的交疊比較嚴重。而在我們換成了 RNN 模型之後,它們就顯得分散了許多。我們籍此來直觀地認為改進後的模型更好。

根據上面將 RNN 的效果與 MLP 的效果所進行的資料比較,我們可以看出:在 Top1 上的差異並不太大,僅提升了 1 個點。

當然,這可能對於線上系統的提升會反應得顯著一些,但是對於我們的離線系統,提升反應就沒那麼明顯了。這便是我們整個團隊在推薦領域的第一次試水。

場景二:360 搜索和導航

有了前面 App 推薦的經驗積累,我們嘗試的第二個專案是“常搜詞”。即:360 頁面有自己的搜索和導航,而在搜索框的下方,我們會放置六到七個用戶經常搜索、或者是時常用到的關鍵詞。

如此,用戶在打開導航時就能看到自己想看的東西,這不但減少了他們在操作上的複雜度,還提升了用戶在使用上的滿意度。

在該場景下,由於我們的導航每天都有好幾億次的 PV(Page View),因此使用該功能的用戶有著千萬級的體量,即 U 為千萬級。

同時,為了定義“常搜詞”,我們對 query(查詢)進行了清洗,過濾掉了一些非常“長尾”的 query,只留下一些有物體字的、較為明確的 query。因此,此處的 I 就根據 query 的數量被設定為了百萬級。

由於該業務本身已存在了較長時間,因此在演算法策略上也已實現一些較為完善的召回(Recall),例如:

  • 搜索詞:是根據用戶的搜索行為,召回一些新的關鍵詞。

  • URL:是根據用戶瀏覽器裡面的瀏覽記錄,再輸入一些關鍵詞。

  • 廣告:是通過滿足用戶的興趣匹配,精準地投放商業化的廣告詞。

  • 百科:是判斷用戶可能感興趣的知識,投放相應的百科詞彙。

另外在 Rank 方面,我們著手將線上系統從以前簡單的 LR+FTRL,升級並優化成為了 DNN 模型。

在架構上,由於該導航系統的特點是用戶使用頻次不高,而我們的推薦可能每天只會被早晚各用一次,因此我們的標的是天級離線更新。

其對應的特征部分,則主要是基於用戶的搜索日誌和瀏覽日誌,來進行的一些統計特征的設定。

讓我們來看看其中幾個權重比較正向的特征,例如:

  • week_freq_num 特征,描述了用戶常搜詞彙的概率分佈,即:如果某個用戶在過去一段時間視窗內成均勻的訪問趨勢,則說明這是經常性的需求。該特征比較重要。

  • global_query_uv 特征,此類全網特征能夠在一定程度上反映商品的質量。我們籍此在原有特征的基礎上擴展到成千上萬個。

在我們將模型調整成為 DNN 之後,系統的 AUC 從 7 提到 8。之後我們還增加了一些其他能夠提升 AUC 的特征。

為了細粒度地分析 DNN 模型的召回策略在上線之後所產生的影響,我們拿它與傳統的 LR+FTRL 模型進行了對比。

途中兩處 CTR 較高,它們都與用戶的搜索和瀏覽行為相關,並且能夠真正反映他們的需求。

由於此類搜索、瀏覽和 MLP 的點擊率本身就比較高,因此我們需要在此基礎上有一個量的提升。

另外在上圖中,雖然與個性化相關的廣告部分略有提升,但是 ys_mid_hist 是有所下跌的。

通過分析,我們發現該模型當時在排序時,傾向於把策略後排,其導致的結果是:用戶在界面上預設只能看到六個推薦詞,而實際上其旁邊有一個往下點的箭頭,在被點擊之後才會出現很多的詞彙。

因此,如果某些推薦詞彙被排到了第六名之後的話,那麼它們被點擊的可能性就非常小。這也說明瞭預設六個詞的重要性。

同時,這也提示了我們:在做資料時,需要重點關註那些用戶通過點擊下拉按鈕去訪問的詞彙,那些資料才更能夠說明用戶對某些詞彙的強烈需要。總的說來,我們協助業務側將 2017 年 Q1 的收入提升了 5%。

場景三:快視頻

基於前面兩個專案所積累的經驗,我們全情地投入了第三個專案—快視頻。其主要的業務形式是個性化的訊息推送,與大家手機上的通知欄推送相類似。

但是,略有不同的是:我們並非每日都定時推送,而是會根據用戶的反饋偏好,去調整推薦的數量、頻率和時間。

同時,這對於將一些尚未養成每日到我們的 App 里觀看視頻的用戶來說,能夠起到一定“拉活”的作用。

在此,我們仍然套用前面的三個層次。在頂層,由於該 App 上線之後,視頻庫的規模和用戶的數量都增長得非常迅速,因此 U 和 I 都具有千萬級。

在召回策略上,圖中列出了五種重要的召回。前三項分別是:語意、視覺和行為召回。我們統一地對它們進行了重點優化。

而在距離用戶更近的 Rank 部分,我們通過收斂,採用了 LSTM + Attention 的模型。

前面介紹過的兩個專案都僅僅是以天為單位進行更新,因此對演算法人員的壓力並不大,只需採用定時任務便可。

而在這個場景中,由於它是一個對用戶進行實時在線推薦的系統,如果採用“天級更新”頻率的話,會給用戶帶來較差的體驗。

因此無論是對召回的資料流、模型的更新、還是在線的服務,我們都認真進行了架構設計。

我們來看看剛纔提到的三個召回策略:行為、語意和視覺。在此,我們將它們統一到了 Embedding 框架之中,以便從視頻的不同角度進行描述和特征表示,而不必關心後續有關設計域值、佇列長度等問題。

通過執行統一的流程,我們能夠更直觀的體現出各種視頻在特征領域下召回的根據。

例如圖中黑體字是某個視頻的 title(標題),明顯,它是有關傳授烹飪知識的召回:

  • 就行為模型而言,它通過對用戶行為序列的協同與分割,為每個視頻分配各種特征向量。

    其特點是:會產生一定的擴散效果。即,你會在上圖中發現,該召回的前兩個結果已經不再關註烹飪,而是擴散到了其他領域。只有第三個召回才是真正有關於烹飪的。

  • 語意模型,重點關註的是視頻標題的語意表示,通過語法和語意的相似性,此類召回能夠抓住標題中關鍵性的動詞與名詞,然後進行相應的交叉和擴散等操作。

  • 視覺模型,是通過抽取視頻的特征,來實現召回。它與標題的語意關聯性不強,就算標題與烹飪無關,只要在視頻中大量出現食物的圖像,便可以表示並召回。

由上可見,我們通過不同的 Embedding,就可以實現多樣的召回策略。

下麵我們重點介紹語意模型。我們所得到的輸入資料是公司過往生成的查詢、與搜索資料,或是其他的業務線積累的標簽資料,例如由網頁標題所抽象出來的簡單標簽。

這些標簽既有自動生成的,也有通過人工修正和 rebind(重新連接)產生的。它們都具有一定的實際價值。

為了給每個 title 產生相應的表徵,我們構建了一項任務:首先是對每個句子進行分詞,以得到相應的字/詞向量,然後通過 CNN 網絡進行處理,最後對標的予以多分類、多標簽,從而預測該標簽準確性。

對於上述任務,我們除了嘗試過 CNN 模型之外,還在不改變 task 的情況下試用了雙向的 LSTM,即 bi-LSTM。接著,我們需要對該語意模型進行評測。

在此業務場景下,我們人工標出了幾千個具有良好多樣性的資料,並將其作為離線評測的指標,以此來檢查通過語意模型召回標註資料的結果相關性。上圖左側的表格就是我們測試的結果。

我們在此比較了幾種常見的語意建模的模型、及其對應的優化。表格的中間列是 Title2Tags,即通過標題來預測對應的標簽。

至於右邊列:Title2UnionTags,我們對應地發現到:如果只有單個標題,則語意往往會被遺漏。

如上圖右側的例子所示:無論是人工寫的標題,還是自動生成的,如果我們將多個標簽放到一塊兒,句子中的語意則會更準確地被改寫到。

另外我們後續對資料的清洗,也能夠提升原句子的標簽數量,進而大幅提升模型的整體效果。

上圖是我們開篇取用過的阿裡 DIEN,在其虛線框中有兩個創新點,分別是 AUGRU(即 Attention 與 GRU 的合併)和輔助的 loss。

雖然 loss 對模型的提升效果非常明顯,可惜我們在模型設計時,過於關註 Attention 的 layer 和下沉到用戶序列上的特征,因此我們將來尚有改進的空間。

上圖便是我們當時對不同排序模型的評測結果。

可見我們在系統架構的設計上,既有諸如到台服務、日誌搜集、和報表等離線部分,又有實時的在線更新。

同時,我們也與業務方的在線系統保持著實時性的交互,以便他們按需獲取推送的資料。另外在最上層,我們為業務方也提供了多種安全策略和分桶策略。

上圖便是我們從 2017 年 11 月 1 日到 2018 年 1 月 31 日的 CTR 曲線。

雖然有某些“坑點”所導致的曲線波動,但是整體趨勢還是向上的,特別是在我們更換了 Attention 模型之後,提升的幅度能夠達到 10%,進而有效地幫助業務方實現了“拉活”和保持更多的活躍用戶。

綜上所述,我們基於深度學習的推薦系統就是根據上述三個層次,一步一步地通過迭代和優化發展起來的。

 

轉載:51CTO技術棧

    赞(0)

    分享創造快樂