推荐算法工程师成长2:排序模块
開一個系列,主題是推薦算法工程師成長路徑。目標是希望填補書本上的機器學習理論與業界推薦算法工程師知識體系上的gap,了解一些業界模塊的通用玩法。目標群體是針對以下用戶:
- 有一些代碼和機器學習基礎,但是沒有從業經驗的在校學生
- 剛剛入坑的算法工程師,可以對照一起探討
- 對推薦系統感興趣的其他朋友
歡迎關注一起探討,也歡迎關注我的微信公眾號: 峰池 (fengchitalk)。
前兩篇,我們分別講了推薦算法所需要的一些工程基礎,和在推薦算法的召回模塊的一些通用解法:
峰池:推薦算法工程師成長路徑0——工程基礎
峰池:推薦算法工程師成長路徑1——FM召回
接下來我們來進入排序模塊,看下排序模塊工業界常見的解法是怎么樣的。
排序模塊需要解決的問題是:怎么樣可以更準確計算用戶更喜歡的內容。具體而言問題是:
第一個問題,我們來引出排序階段的模型結構。相對于召回模型而言,排序階段的模型可能更像我們傳統意義上的深度學習模型。第二個問題,我們考慮推薦上非常重要的一個概念,叫做多目標的預估和融合。
一、排序階段的模型結構
首先我們來看排序階段的模型結構。先假定我們在排序階段的主要目標是預估用戶的點擊率。這個部分可能是推薦系統在線模塊中,與在學校學習的機器學習課程中最為類似的一個部分了。因為在這個部分我們可以假定,訓練數據集已經存儲好;且這個部分在serving的時候,不需要像召回一樣做那么多特殊的處理。
一句話簡單說明,現在排序階段的模型整體架子都是在Wide & Deep的框架下的一些變體和調整。
什么是Wide & Deep框架呢?這源于Google在16年的一篇論文,Wide & Deep Learning for Recommender Systems。這篇論文非常短,只有4頁,核心思想就是這樣一張圖:
所謂Wide Models,就是所有的特征直接預估得到最終的結果,說穿了就是我們機器學習的第一課:邏輯回歸。而Deep Models,就是我們常見的,從最開始的稀疏特征,到變換成Embedding層,到最終的全連接隱藏層,再到最終的輸出層。
而Wide & Deep Models,就是把這兩個模型結構簡單粗暴的融合在一個模型結構里,變成一個大的網絡結構。在這個網絡結構中,既有Wide的部分,也有Deep的部分。這樣的效果通常比我們單獨使用Wide 或者單獨使用Deep的網絡效果要好:比只有Wide的網絡結構效果好比較顯然,畢竟有deep的部分,擬合的效果自然會好很多;比只有Deep的網絡結構效果好,可能的解釋性在于,feature直接作用于最終的輸出結果,會強化原始的feature在最終預估結果的解釋性,尤其會使模型呈現出一種“記憶性”(同樣的feature再度出現時,wide部分的網絡更容易直接學到結果。)
Wide & Deep只是一個網絡的框架,一般而言我們會在網絡結構中做一些調整和變換,這一點在王喆的《深度學習推薦系統》中有比較系統且準確的介紹。我們在這里先插一張王喆在書中總結出來的圖,感興趣的同學可以深入研究一下。
深度學習推薦系統(全彩)
京東
¥ 96.10
去購買?
說幾個常用的Wide & Deep 模型的變體:
- Deep部分加入Attention (DIN)
- Deep部分加入用戶的點擊/購買序列,引入Sequence信息,使用類似RNN的操作方式處理Sequence序列等等 (DIEN)
排序模型整體上沒有特別“深”的模型。我個人總結下來有兩個原因:
- 原始的信息輸入都是離散特征,比如user_id或者item_id。在這種特征場景下,Embedding層結合三五層全連接已經可以足夠表征離散特征的信息了,更深層的網絡的優勢體現不出來。
- 深層的網絡inference的速度太慢。而inference的速度與效果是呈現反比的。事實上,整個推薦系統在線的部分,模塊的延時都可以和最終效果進行換算。因為如果可以在整體耗時給定的情況下,如果排序的候選增加,一般是肯定增加延時但提升效果的。相當于其他模塊的延時增加,都可以通過同樣的方式進行效果的機會成本的兌換。有時候,因為更多的網絡結構帶來的耗時的增加所帶來的收益,可能敵不過簡單的擴大排序候選帶來的收益。
未來模型方面的發展方向是:模型結構使用auto ML的方式搜索出一個合適的模型結構和模型size等等(這個方向叫做NAS, Neural Architecture Search),而不是再依賴于人手工對模型結構進行調整,就像集成電路設計最終會取代手工設計一樣。這個方向目前有一些簡單的嘗試,但可能距離大規模的工業界的應用,還需要幾年的發展時間。
二、多個目標場景的排序依據
以上我們假定的模型預估目標,是單一目標的預估場景,通常都是以點擊率為目標做預估的。但是實際上,在推薦系統落地的主要場景中,一般不只有一個目標。比如:
- 在今日頭條這樣的新聞類app中,一般除了考慮點擊率之外,還會考慮用戶在這個文章的停留時長。
- 在廣告推薦領域,一般除了考慮點擊率之外,還會考慮廣告自身的轉化率。
- 在抖音快手這樣的短視頻App中,因為產品本身是自動播放的,所以就沒有點擊率的概念,這時考慮的就是用戶是否點贊,是否會看完整個視頻等等。
這時候就涉及到兩個問題:一是多個目標如何做模型,建模和預估;二是當需要考慮多個模型輸出結果的時候,如何確定多個輸出結果的權重。
我們分開來看。
2.1 多目標建模
首先,多個目標的建模。最簡單的解法當然是,多個目標,每一個目標單獨建模。比如我們同時預估點擊率和時長:就先單獨搞一個模型預估點擊率,再單獨搞一個模型預估時長。
這樣的搞法有兩個問題:
- 資源問題,如果每一個模型單獨一個模型,需要的資源消耗肯定是比較多的,出于控制成本的角度,我們考慮模型是否可以進行合并。
- 效果問題,對于比如稀疏的目標,比如廣告轉化,可能轉化率是在千分位左右。這時候如果單獨訓練一個轉化的模型,可能效果欠佳。這時候如果有一個稍微稠密的目標,且表達的信息和用戶點擊率類似,比如點擊率(轉化相對點擊來說是用戶喜好更強的表達),這時候就可以把兩個目標一起訓練,可能在效果上還會有一些增益。
這是一個相對來說比較通用的問題,有一個專門研究這個問題的方向叫做Multitask Learning。我這里先說一個有代表性的場景:
假設我們這里有三個目標ABC,彼此目標類似,可以用類似下圖的模型結構進行學習。即三個目標有共同的shared的部分,然后又有一些specific的網絡結構。ABC三個task的樣本,會共同更新shared部分的網絡結構,同時也會更新各自獨立的網絡結構。如果效果好的話,有時候可以起到一個模型,效果比分別三個模型效果還要好的程度。
Multitask Learning 可以玩的花樣比較多,具體還是需要在實際的使用中具體調優得到。比如以下幾個點:
- 哪個結構share,哪個結構不share? 除了直接這樣hard share之外,也可以使用一些比如軟性的約束條件來進行share。
- 對于有一些目標,我覺得比較重要,我只是想讓這個目標去引導另一個目標的學習,而不想讓另外那個目標影響我原本這個目標的預估。這是一種teacher & student的模式,通過合理的loss處理以及stop gradient的應用就可以達到目標了
- 可以設計出更為復雜的網絡結構來處理multitask問題。比如MoE?or?MMoE,就是把門控結構引入Multitask 模型訓練。有點類似于把boosting的思想引入網絡結構的設計。
以上是一些網絡結構的上面的想法,我這里就不具體展開了。感興趣的同學可以通過我提出的這些關鍵詞,來進行進一步的搜索和學習。簡單而言,我們還是預期多個目標每個目標至少可以學準。
2.2 多目標融合
接下來我們來看下多個目標的融合。假設我們現在有了比較準確的目標的預估值,比如點擊率和停留時長,那怎么樣可以把這兩個預估結果比較科學的融合在一起作為最終的排序結果的依據呢?
這個問題沒有統一的回答,因為這實際上是一個產品的決策。
比方說,A這個產品的核心指標就是vv(視頻播放量,video view),那么其實可以不關心用戶對某一個視頻的觀看時長。只需要讓點擊率高的多出就行了。再比方說,B這個產品的核心指標就是讓用戶盡可能的沉浸,盡量不進行文章之間的切換,那我就需要讓用戶最終的排序按照用戶的停留時長去排序即可,這樣用戶在每一個文章之中都可以停留足夠長的時間。
更多的情況是,產品需要在多個目標之中做一個權衡。比方說,點擊率高的文章,有可能是會遇到標題黨,這時候停留時長就不長,用戶體驗也不好;而停留時長高的文章,可能因為標題封面不吸引人,用戶就根本不點進來看。所以我們需要一個方式把多個目標的預估結果平衡起來。
解決問題的辦法就是拍一個公式,把點擊率和停留時長按照某種方式配比平衡起來。比如0.3 * 點擊率 + 0.7 * 停留時長?等等。
這個融合公式的配比,決定了推薦系統最終輸出的內容的畫風和質量,與產品本身是息息相關的。
總結
以上是生活随笔為你收集整理的推荐算法工程师成长2:排序模块的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 腾讯 VS 阿里 VS 携程消息中间件设
- 下一篇: 数据仓库、数据湖、流批一体