知識蒸餾在推薦系統的應用

點擊上方,選擇星標置頂,天天給你送乾貨git

做者 | 張俊林算法

本文轉載自知乎 https://zhuanlan.zhihu.com/p/143155437微信


隨着深度學習的快速發展,優秀的模型層出不窮,好比圖像領域的ResNet、天然語言處理領域的Bert,這些革命性的新技術使得應用效果快速提高。可是,好的模型性能並不是無代價的,你會發現,深度學習模型正在變得愈來愈複雜,網絡深度愈來愈深,模型參數量也在變得愈來愈多。而這會帶來一個現實應用的問題:將這種複雜模型推上線,模型響應速度太慢,當流量大的時候撐不住。
知識蒸餾就是目前一種比較流行的解決此類問題的技術方向。通常知識蒸餾採起Teacher-Student模式:將複雜模型做爲Teacher,Student模型結構較爲簡單,用Teacher來輔助Student模型的訓練,Teacher學習能力強,能夠將它學到的暗知識(Dark Knowledge)遷移給學習能力相對弱的Student模型,以此來加強Student模型的泛化能力。複雜笨重可是效果好的Teacher模型不上線,就單純是個導師角色,真正上戰場擋搶撐流量的是靈活輕巧的Student小模型。好比Bert,由於過重,很難直接上線跑,目前不少公司都是採起知識蒸餾的方法,學會一個輕巧,可是由於被Teacher教導過,因此效果也很好的Student模型部署上線。

知識蒸餾典型方法
目前知識蒸餾已經成了獨立研究方向,各類新技術層出不窮。可是若是粗略概括一下的話,主流的知識蒸餾技術有兩個技術發展主線:Logits方法及特徵蒸餾方法。

咱們先簡單說明下Logits方法的思路。在介紹以前,首先得明白什麼是Logits。咱們知道,對於通常的分類問題,好比圖片分類,輸入一張圖片後,通過DNN網絡各類非線性變換,在網絡接近最後一層,會獲得這張圖片屬於各個類別的大小數值   ,某個類別的   數值越大,則模型認爲輸入圖片屬於這個類別的可能性就越大。什麼是Logits? 這些彙總了網絡內部各類信息後,得出的屬於各個類別的彙總分值   ,就是Logits, i表明第i個類別,   表明屬於第i類的可能性。由於Logits並不是機率值,因此通常在Logits數值上會用Softmax函數進行變換,得出的機率值做爲最終分類結果機率。Softmax一方面把Logits數值在各種別之間進行機率歸一,使得各個類別歸屬數值知足機率分佈;另一方面,它會放大Logits數值之間的差別,使得Logits得分兩極分化,Logits得分高的獲得的機率值更偏大一些,而較低的Logits數值,獲得的機率值則更小。上圖中的公式   ,就是一個變體的Softmax公式,若是把T拿掉或令T=1,則是個標準的Softmax公式,   就是第i個類別的Logits數值,   是Logits數值通過Softmax變換後,歸屬於第i個類別的機率值。
知道了什麼是Logits後,咱們來講什麼是Logits蒸餾方法。假設咱們有一個Teacher網絡,一個Student網絡,輸入同一個數據給這兩個網絡,Teacher會獲得一個Logits向量,表明Teacher認爲輸入數據屬於各個類別的可能性;Student也有一個Logits向量,表明了Student認爲輸入數據屬於各個類別的可能性。最簡單也是最先的知識蒸餾工做,就是讓Student的Logits去擬合Teacher的Logits,即Student的損失函數爲:
其中,   是Teacher的Logits,   是Student的Logits。在這裏,Teacher的Logits就是傳給Student的暗知識。
Hinton在論文「Distilling the Knowledge in a Neural Network」中提出了稱爲Softmax Temperature的改進方法,並第一次正式提出了「知識蒸餾」的叫法。Softmax Temperature改造了Softmax函數(公式參考上圖),引入了溫度T,這是一個超參數。若是咱們把T設置成1,就是標準的Softmax函數,也就是極端兩極分化版本。若是將T設大,則Softmax以後的Logits數值,各個類別之間的機率分值差距會縮小,也便是強化那些非最大類別的存在感;反之,則會加大類別間機率的兩極分化。Hinton版本的知識蒸餾,讓Student去擬合Teacher通過T影響後Softmax獲得的,其實也是讓Student去學習Teacher的Logits,無非是加入T後能夠動態調節Logits的分佈。Student的損失函數由兩項組成,一個子項是Ground Truth,就是在訓練集上的標準交叉熵損失,讓Student去擬合訓練數據,另一個是蒸餾損失,讓Student去擬合Teacher的Logits:
H是交叉熵損失函數,   是Student模型的映射函數,   是Ground Truth Label,   是Teacher的Logits,   是Student的Logits,   是Softmax Temperature函數,   用於調節蒸餾Loss的影響程度。
通常而言,溫度T要設置成大於1的數值,這樣會減少不一樣類別歸屬機率的兩極分化程度,由於Logits方法中,Teacher可以提供給Student的額外信息就包含在Logits數值裏。若是咱們在蒸餾損失部分,將T設置成1,採用常規的Softmax,也就是說兩極分化嚴重時,那麼相對標準的訓練數據,也就是交叉熵損失,二者等同,Student從蒸餾損失中就學不到任何額外的信息。
另一種大的知識蒸餾思路是特徵蒸餾方法,如上圖所示。它不像Logits方法那樣,Student只學習Teacher的Logits這種結果知識,而是學習Teacher網絡結構中的中間層特徵。最先採用這種模式的工做來自於自於論文:「FITNETS:Hints for Thin Deep Nets」,它強迫Student某些中間層的網絡響應,要去逼近Teacher對應的中間層的網絡響應。這種狀況下,Teacher中間特徵層的響應,就是傳遞給Student的暗知識。在此以後,出了各類新方法,可是大體思路仍是這個思路,本質是Teacher將特徵級知識遷移給Student。由於介紹各類知識蒸餾方法不是咱們的主題,這裏不展開了,咱們儘快切入主題。
知識蒸餾在推薦系統中的三個應用場景
咱們知道,工業界常見推薦系統通常有三個級聯的過程:召回、粗排以及精排。召回環節從海量物品庫裏快速篩選部分用戶可能感興趣的物品,傳給粗排模塊,粗排環節一般採起使用少許特徵的簡單排序模型,對召回物料進行初步排序,並作截斷,進一步將物品集合縮小到合理數量,向後傳遞給精排模塊,精排環節採用利用較多特徵的複雜模型,對少許物品進行精準排序。其中,粗排環節根據具體應用可選可不選。
那麼,在這種串行級聯的推薦體系中,知識蒸餾能夠應用在哪一個環節呢?假設咱們在召回環節採用模型排序(FM/FFM/DNN雙塔等模型),那麼知識蒸餾在上述三個環節均可採用,不一樣環節採用知識蒸餾的目的可能也不太相同。也就是說,精排、粗排以及模型召回環節均可以採用知識蒸餾技術來優化現有推薦系統的性能和效果,這裏的性能指的線上服務響應速度快,效果指的推薦質量好。
1)精排環節採用知識蒸餾
爲什麼在精排環節採用知識蒸餾?咱們知道,精排環節注重精準排序,因此採用儘可能多特徵,複雜模型,以期待得到優質的個性化推薦結果。可是,這同時也意味着複雜模型的在線服務響應變慢。若承載相同流量,須要增長在線服務並行程度,也就意味着增長機器資源和成本,好比,DNN 排序模型相對LR/FM等非深度模型,在線推理速度降低明顯。此時,咱們面臨兩難選擇:要麼上簡單模型,可是付出的代價是推薦效果不如複雜模型好;要麼上覆雜模型,雖然說效果是提升了,可是要付出額外的機器等資源及成本。有什麼技術方案可以在二者之間作個均衡麼?就是說,但願找到一個模型,這個模型既有較好的推薦質量,又能有快速推理能力。咱們能夠實現這一目標麼?能夠的,在精排環節上知識蒸餾模型便可。
上圖展現瞭如何在精排環節應用知識蒸餾:咱們在離線訓練的時候,能夠訓練一個複雜精排模型做爲Teacher,一個結構較簡單的DNN排序模型做爲Student。由於Student結構簡單,因此模型表達能力弱,因而,咱們能夠在Student訓練的時候,除了採用常規的Ground Truth訓練數據外,Teacher也輔助Student的訓練,將Teacher複雜模型學到的一些知識遷移給Student,加強其模型表達能力,以此增強其推薦效果。在模型上線服務的時候,並不用那個大Teacher,而是使用小的Student做爲線上服務精排模型,進行在線推理。由於Student結構較爲簡單,因此在線推理速度會大大快於複雜模型;而由於Teacher將一些知識遷移給Student,因此通過知識蒸餾的Student推薦質量也比單純Student本身訓練質量要高。這就是典型的在精排環節採用知識蒸餾的思路。至於具體蒸餾方法,後文會介紹。固然,你也能夠根據前文介紹的經典知識蒸餾方案,本身試着想一想應該怎麼作。
對於精排環節來講,我以爲,知識蒸餾比較適合如下兩種技術轉換場景:
一種是排序模型正在從非DNN模型初次向DNN模型進行模型升級;在超大規模數據場景下,從非DNN模型切換到DNN模型,切換成本和付出的時間因素可能比你預想得要高,尤爲是線上服務環節,切換到DNN模型致使大量增長在線服務機器成本,這對於不少公司來講是沒法接受的。若是在作模型升級的時候採起知識蒸餾方案,致使的效果是:相對線上的非DNN模型,即便上一個蒸餾小模型,效果也多是有提高的,同時在線服務佔用資源能降下來(相對直接上個複雜DNN模型),在線服務速度快,因此能夠明顯下降模型升級的成本,這樣能夠相對容易地切換到DNN版本排序模型上來。
第二種狀況是:目前儘管線上已經採用了DNN 排序模型,可是模型還很是簡單,這個也有利用知識蒸餾優化效果的空間;這種情形下,現有在線模型的服務速度多是足夠快的,由於在線服務模型還比較簡單,即便換成Student小模型,在這方面估計也差不太多。可是,能夠期待經過知識蒸餾提高線上模型的推薦質量。咱們能夠離線訓練一個複雜可是效果明顯優於線上簡單DNN排序模塊的模型做爲Teacher,而後經過知識蒸餾,訓練一個能夠代替目前線上模型的Student小模型。若是這樣,是有可能在響應速度不降的前提下,模型效果上有所提高的。因此,感受這種狀況也比較適合採用蒸餾模型。
而對於其它情形,好比目前線上已有較爲複雜的DNN排序系統的業務或者公司,至因而否要上知識蒸餾,則須要面臨一個權衡:採用知識蒸餾,線上服務模型從複雜模型切換成小模型,確定能夠明顯提升線上QPS,減小服務資源,效率提高會比較大;可是,有可能推薦質量比線上的大模型會有下掉。因此,業務場景是否接受這種指標的臨時降低?這個問題的答案決定了不一樣的選擇,在有些業務場景下,這是須要好好考慮考慮的。不一樣業務環境可能會做出不一樣的選擇。
2)模型召回以及粗排採用知識蒸餾
在模型召回環節,或者粗排環節,採起知識蒸餾的方案,是很是天然的一個想法拓展,並且很是合算。目前,這塊基本看不到徹底公開細節的技術資料,因此本文我重點談談在這塊可能採用的技術,和幾位同窗討論出若干可能的方案會列在後面,感興趣的同窗能夠嘗試一下,在這裏是很容易做出收益的,因此特別值得關注與嘗試,相信這塊用好了,會對完成你的KPI有幫助。
這裏所謂的合算,怎麼理解呢?由於召回或者粗排環節,做爲精排的前置環節,有本身承擔的獨特職責,須要在準確性和速度方面找到一個平衡點,在保證必定推薦精準性的前提下,對物品進行粗篩,減少精排環節壓力。因此,這兩個環節自己,從其定位來講,並不追求最高的推薦精度,就算模型效果比精排差些,這也徹底不成問題,畢竟在這兩個環節,若是準確性不足能夠靠返回物品數量多來彌補。而模型小,速度快則是模型召回及粗排的重要目標之一。這就和知識蒸餾自己的特色對上了,因此在這裏用是特別合算的。
那麼,召回或者粗排怎麼用蒸餾呢?若是咱們如上圖所示,用複雜的精排模型做爲Teacher,召回或粗排模型做爲小的Student,好比FM或者雙塔DNN模型等,Student模型模擬精排環節的排序結果,以此來指導召回或粗排Student模型的優化過程。這樣,咱們能夠得到知足以下特性的召回或者粗排模型:首先,推薦效果好,由於Student通過複雜精排模型的知識蒸餾,因此效果雖然弱於,可是能夠很是接近於精排模型效果;其次,Student模型結構簡單,因此速度快,知足這兩個環節對於速度的要求;再次,經過Student模型模擬精排模型的排序結果,可使得前置兩個環節的優化目標和推薦任務的最終優化目標保持一致,在推薦系統中,前兩個環節優化目標保持和精排優化目標一致,實際上是很重要的,可是這點每每在實作中容易被忽略,或者因條件所限沒法考慮這一因素,好比非模型召回,從機制上是沒辦法考慮這點的。這裏須要注意的一點是:若是召回模型或者粗排模型的優化目標已是多目標的,對於新增的模型蒸餾來講,能夠做爲多目標任務中新加入的一個新目標,固然,也能夠只保留單獨的蒸餾模型,徹底替換掉以前的多目標模型,貌似這兩種思路應該都是能夠的,須要根據具體狀況進行斟酌選擇。
由以上分析,可見,召回或粗排環節的知識蒸餾方案,看上去貌似是爲召回和粗排環節量身定製的推薦系統優化技術選項,對於召回或者粗排優化來講,應該是必試的一個技術選項。

下面咱們討論下在推薦系統裏,在各個環節採用知識蒸餾的可能的具體方法。精排蒸餾有三篇公開文獻可供參考,而召回或粗排方面的蒸餾技術,不多見相關公開資料,因此後面列的多數是我和幾位同窗討論的方案,除個別方法有實踐結果外,大多方法仍處於設想階段,目前並未落地,因此不能保證有效性,這點還須要注意。網絡


精排環節蒸餾方法app

目前推薦領域裏,在精排環節採用知識蒸餾,主要採用Teacher和Student聯合訓練(Joint Learning)的方法,而目的是經過複雜Teacher來輔導小Student模型的訓練,將Student推上線,增快模型響應速度。
如上圖所示,所謂聯合訓練,指的是在離線訓練Student模型的時候,增長複雜Teacher模型來輔助Student,二者同時進行訓練,是一種訓練過程當中的輔導。從網絡結構來講,Teacher和Student模型共享底層特徵Embedding層,Teacher網絡具備層深更深、神經元更多的MLP隱層,而Student則由較少層深及神經元個數的MLP隱層構成,二者的MLP部分參數各自私有。對於全部訓練數據,會同時訓練Teacher和Student網絡,對於Teacher網絡來講,就是常規的訓練過程,以交叉熵做爲Teacher的損失函數。而對於Student網絡來講,損失函數由兩個部分構成,一個子項是交叉熵,這是常規的損失函數,它促使Student網絡去擬合訓練數據;另一個子項則迫使Student輸出的Logits去擬合Teacher輸出的Logits,所謂蒸餾,就體如今這個損失函數子項,經過這種手段讓Teacher網絡加強Student網絡的模型泛化能力。也即:
H是交叉熵損失函數,   是Student模型的映射函數,   是Ground Truth Label,   是Teacher的Logits,   是Student的Logits,   用於調節蒸餾Loss的影響程度。
這個模型是阿里媽媽在論文「Rocket Launching: A Universal and Efficient Framework for Training Well-performing Light Net」中提出的,其要點有三:其一兩個模型同時訓練;其二,Teacher和Student共享特徵Embedding;其三,經過Logits進行知識蒸餾。對細節部分感興趣的同窗能夠參考原始文獻。
愛奇藝在排序階段提出了雙DNN排序模型,能夠看做是在阿里的rocket launching模型基礎上的進一步改進。如上圖所示,Student和Teacher共享特徵Embedding參數層,Student模型在損失函數中加入了擬合Teacher輸出階段的Logits子項,這兩點和rocket launching是相似的。主要改進有兩點:首先,爲了進一步加強student的泛化能力,要求student的隱層MLP的激活也要學習Teacher對應隱層的響應,這點一樣能夠經過在student的損失函數中加子項來實現。可是這會帶來一個問題,就是在MLP隱層複雜度方面,Student和Teacher是至關的,咱們說過,通常知識蒸餾,老師要比學生博學,那麼,在這個結構裏,Teacher相比student,模型複雜在哪裏呢?這引出了第二點不一樣:雙DNN排序模型的Teacher在特徵Embedding層和MLP層之間,能夠比較靈活加入各類不一樣方法的特徵組合功能,經過這種方式,體現Teacher模型的較強的模型表達和泛化能力。
愛奇藝給出的數據對比說明了,這種模式學會的student模型,線上推理速度是Teacher模型的5倍,模型大小也縮小了2倍。Student模型的推薦效果也比rocket launching更接近Teacher的效果,這說明改進的兩點對於Teacher傳授給Student更強的知識起到了積極做用。更多信息可參考: 雙 DNN 排序模型:在線知識蒸餾在愛奇藝推薦的實踐。

召回/粗排環節蒸餾方法
上面介紹了阿里和愛奇藝在精排方面的兩個知識蒸餾應用工做,目前知識蒸餾應用在推薦領域的公開資料不多,雖然說上面兩個工做是應用在精排,目的是加快線上模型推理速度,可是稍微改進一下,也能夠應用在召回模型以及粗排模型。
假設咱們打算使用上述方案改造召回或者粗排模型,一種直觀的想法是:咱們基本能夠直接參照rocket launching的方案稍做改動便可。對於粗排或者召回模型來講,通常你們會用DNN雙塔模型建模,只須要將粗排或召回模型做爲Student,精排模型做爲Teacher,二者聯合訓練,要求Student學習Teacher的Logits,同時採起特徵Embedding共享。如此這般,就可讓召回或粗排模型學習精排模型的排序結果。快手曾經在AICon分享過在粗排環節採起上面接近rocket launching的蒸餾技術方案,並取得了效果。
因雙塔結構將用戶側和物品側特徵分離編碼,因此相似愛奇藝技術方案的要求Student隱層學習Teacher隱層響應,是很難作到的。粗排尚有可能,設計簡單網絡DNN結構的時候不採起雙塔結構便可,召回環節幾無可能,除非把精排模型也改爲雙塔結構,可能才能實現這點,但這樣可能會影響精排模型的效果。
可是,問題是:咱們有必要這麼興師動衆,爲了訓練召回或粗排的蒸餾模型,去聯合訓練精排模型麼?貌似若是這樣,召回模型對於排序模型耦合得過於緊密了,也有必定的資源浪費。其實咱們未必必定要二者聯合訓練,也能夠採起更節省成本的兩階段方法。
1)召回蒸餾的兩階段方法
在專門的知識蒸餾研究領域裏,蒸餾過程大都採起兩階段的模式,就是說第一階段先訓練好Teacher模型,第二階段是訓練Student的過程,在Student訓練過程當中會使用訓練好Teacher提供額外的Logits等信息,輔助Student的訓練。
私覺得,精排環節貌似仍是聯合訓練比較好,而召回或粗排環節採起兩階段模式估計更有優點。爲何這麼說呢?你能夠這麼想:若是咱們的目的是但願訓練一個小的Student精排模型,貌似沒有太大的必要採起兩階段訓練過程,由於不管是聯合訓練也好,仍是兩階段訓練也好,反正一大一小兩個模型都須要完整訓練一遍,消耗的資源相似。而若是聯合訓練,則還能夠應用特徵embedding共享、隱層響應學習等更多可選的技術改進方案。因此貌似沒有太大必要改爲兩階段的模式。
可是,若是是召回模型或粗排模型做爲Student,則狀況有所不一樣。首先,好比隱層響應等技術手段,原本召回或粗排Student模型就沒法使用(粗排若是不用雙塔,而是簡單DNN模型,仍是能夠的),因此聯合訓練相對兩階段訓練增長的好處不明顯。至於Student和Teacher特徵Embedding共享,若是是在兩階段模式下,則能夠改成使用Teacher訓練好的特徵Embedding初始化Student的特徵,這樣貌似損失也不大,因此兩階段模式相對聯合訓練模式,在效果方面並沒有明顯劣勢。另外,由於咱們但願召回或者粗排模型學習精排模型,而通常而言,咱們可以拿到一個已經訓練好的精排模型,好比最近上線的精排模型,既然這樣,咱們能夠直接用當前已訓練好的精排模型,讓它把用於召回模型的訓練數據跑一遍,給每一個訓練數據打上Logits信息,而後,就能夠按照與聯合訓練徹底同樣的方式去訓練召回蒸餾模型了,優化目標是Ground Truth子目標和Logits蒸餾子目標。上圖展現了這一過程。這樣作,明顯咱們節省了精排Teacher的聯合訓練迭代成本。不過,這種方法是否有效不肯定,感興趣的同窗能夠嘗試一下,不過推論起來應該是能保證效果的。
上面的方法,仍是模仿精排蒸餾方式,無非改爲了相對節省資源的兩階段模式。這裏咱們關心另一個問題:對於召回蒸餾Student模型來講,是否必定要優化那個Ground Truth子目標?這可能要分狀況看。按理說,蒸餾模型帶上Ground Truth優化目標確定效果要好於不帶這個子目標的模型。若是咱們的召回模型或者粗排模型是單目標的,好比就優化點擊,那麼明顯仍是應該帶上Ground Truth優化目標。可是,事實上,極可能咱們手上的召回模型或粗排模型已是多目標的了,那麼這種狀況下,其實蒸餾Student模型就沒有太大必要帶Ground Truth優化目標,由於多目標已經各自作了這個事情了。這種狀況下,獨立優化蒸餾目標,而後將其做爲多目標的一個新目標加入召回或粗排模型比較合適。
因此,咱們下面介紹的方案,就拋掉Ground Truth優化目標,單獨優化蒸餾目標。若是根據蒸餾Student模型是否須要參考Teacher提供的Logits信息來對方法進行分類,又能夠進一步劃分爲參考Logits信息的方案,和不參考Logits信息的方案。按理說,參考Logits信息效果應該好些,可是,這樣Student仍然對Teacher有依賴,而不參考Logits信息的方案比較獨立,基本不須要精排模型的直接介入,所需信息直接能夠在常規的推薦系統Log裏拿到,實現起來更具簡單和獨立性。並且,若是精排模型已是多目標的,可能很難得到那個Logits數值,可是咱們可以拿到精排模塊的排序結果,這意味着Student在優化蒸餾目標的時候,就已經朝着多目標進行優化了,是一種在召回或粗排進行非精細化多目標方向優化的一種簡潔手段,因此有額外的好處。若是出於上述目的,此時明顯用非Logits方案更從容。綜合而言,從效果考慮,應該考慮引入Logits,從獨立性和簡潔性角度,能夠參考非Logits方案。這可能與現實場景相關。
2)Logits方案
在召回或者精排採用知識蒸餾,此時,精排模型其實身兼二職:主業是作好線上的精準排序,副業是順手能夠教導一下召回及粗排模型。因此,其實咱們爲了讓Teacher可以教導Student,在訓練Student的時候,並不須要專門訓練一遍Teacher精排模型,由於它就在線上跑着呢。並且咱們拋開了Ground Truth優化子目標,因此不須要Teacher對訓練數據都過一遍,而只須要多作一件事情:線上精排模型在輸出排序結果的時候,對於當前判斷<User,Item,Context>實例,除了給出是否點擊等判斷外,只要把對應優化目標的Logits數值輸出,並計入Log便可。這樣,召回或粗排模型能夠直接使用訓練數據中記載的Logits,來做爲Student的訓練數據,訓練蒸餾模型,上圖展現了這一過程。因此,綜合看,這種Logits方案,是更節省計算資源的方案。固然,上述都是個人我的推論,實際效果如何,還須要作對比實驗才能說明問題。
3)Without-Logits方案
另一類方法能夠進一步減小Student對Teacher的依賴,或適用於沒法獲得合理Logits信息的場合,即Student徹底不參考Logits信息,可是精排做爲Teacher,怎麼教導Student呢?別忘了,精排模型的輸出結果是有序的,這裏面也蘊含了Teacher的潛在知識,咱們能夠利用這個數據。也就是說,咱們可讓Student模型徹底擬合精排模型的排序結果,以此學習精排的排序偏好。咱們知道,對於每次用戶請求,推薦系統通過幾個環節,經過精排輸出Top K的Item做爲推薦結果,這個推薦結果是有序的,排在越靠前的結果,應該是精排系統認爲用戶越會點擊的物品。
那麼,咱們其實能夠不用Logits,粗排或者召回環節的Student的學習目標是:像精排模型同樣排序。這時,精排模型仍然是Teacher,只是傳給召回或粗排模型的知識再也不是Logits,而是一個有序的列表排序結果,咱們但願Student從這個排序結果裏面獲取額外的知識。若是這樣的話,對於目前的線上推薦系統,不須要作任何額外的工做,由於排序結果是會記在Log裏的(也能夠用推薦系統在精排以後,通過Re-ranker重排後的排序結果,這樣甚至能夠學習到一些去重打散等業務規則),只要拿到Log裏的信息,咱們就能夠訓練召回或粗排的Student蒸餾模型。
也就是說,對於召回或者粗排模型來講,它看到了若干精排的排序結果列表,精排模型的知識就蘊含在裏面,而這能夠做爲Student模型的訓練數據來訓練蒸餾模型。很明顯,這是一個典型的Learning to Rank問題。咱們知道,對於LTR問題,常見的優化目標包括三種:Point Wise、Pair Wise和List Wise。因而,咱們能夠按照這三種模式來設計召回模型或粗排模型的蒸餾學習任務。其中,下面文中提到的Point Wise方式咱們已親試有效,至於Pair Wise和List Wise蒸餾,仍需實驗才能證實是否有效。

Point Wise蒸餾

在Point Wise優化目標下理解召回模型蒸餾,就是說,咱們把精排模型的有序輸出結果做爲訓練數據,把學習目標看做一個二分類問題,經過這種方式試圖學習精排模型的排序偏好。這種狀況下,分類模型的正負例如何設定呢?咱們不能把精排模型輸出結果列表裏用戶行爲過的Item做爲正例,由於這樣你等於在學好比點擊或者互動等用戶行爲模型,而不是在學精排模型的排序偏好。通常而言,能夠這麼作:假設精排每次返回N個結果,咱們取列表前Top K的排序靠前的結果,將其指定爲正例,位置K以後的例子,做爲負例。意思是經過排名最高的一部分數據,來學習精排模型的排序偏好。這樣,咱們就能夠拿這些非標註的排序結果來訓練召回模型。固然,這裏的K是個超參,怎麼定更合理,可能須要實驗來肯定。上圖展現了這一作法。
經過這種方式,咱們就可讓召回模型從精排模型的排序列表中學到排序偏好知識,達成知識蒸餾的目標。這種作法,有個能夠改進的點:上述切分正負例的方法,並未強調物品排序位置。好比假設K值取5,就是排名前5的物品做爲正例,以後的做爲負例。正例中排名Rank 1的物品,和排名Rank 4的物品,都各自做爲一條正例,沒有差異。可是,咱們知道,Rank 1應該排名比Rank 4更高,但模型訓練過程並無利用這個信息。咱們能夠經過對正例引入Loss Weight的簡單處理方法來引入這一信息,好比引入一個跟位置相關的Weight函數:
其中,Rank Position是Item的排名名次,將其做爲變量引入函數,以此映射函數的數值做爲正例的Loss Weight,負例Loss Weight權重與常規訓練同樣,可認爲缺省Loss Weight權重爲1。在具體設計這個函數的時候,指導思想是:但願這個函數能作到,排名越靠前的正例,對應的Loss Weight越大。將這個Loss Weight引入損失函數中,就可讓模型更關注排名靠前的物品。好比,咱們能夠這麼定義函數:
這裏,Position是排名位置,好比Rank Position=1,則Position=1;Rank Position=4,則Position=4;經過這種定義,就能使得排名靠前的正例,對應的Loss Weight越大,而a能夠做爲調節權重,來放大或者縮小排名位置的影響。固然,這裏還能夠引入其它各類花樣的Loss Weight定義方法。
熱門微博嘗試了上述思路FM版本的蒸餾召回模型(多目標召回模型基礎上增長蒸餾召回目標),線上AB測試效果,在時長、點擊、互動等多個指標都有2+%到6+%之間的不一樣程度的提高做用,目前正在嘗試更多變體模型。

Pair Wise蒸餾
若是咱們用Pair Wise Loss的方式來看待召回模型優化問題,能夠這麼思考:精排的排序結果是有序列表,在列表內隨機任意抽取兩個Item,都能維持序關係。那麼很明顯,咱們能夠構形成對的訓練數據,以Item爲正例,以排在Item後面任意某個Item做爲負例,以此方式構造訓練數據來訓練模型。在推薦領域,最經常使用的Pair Wise Loss是BPR損失函數,因而咱們能夠如法炮製,如上圖所示,假設對於排在第三位的Item做爲正例,能夠抽取排名在其以後的Item,構造足夠多的成對訓練數據,以此目標來優化召回模型,使得模型能夠學會Item間的序列關係。
對<Pos,Neg>成對的訓練數據,BPR損失函數但願某個預測系統可以對正例的得分要高於負例的得分,具體計算方法如上圖所示,由於是個基礎概念,此處不展開介紹。
論文Ranking Distillation: Learning Compact Ranking Models With High Performance for Recommender System 提出了使用Point Wise和Pair Wise Loss來使用Teacher的輸出結果訓練Student的方法,文中說貌似上面這種BPR的Loss會致使Student訓練不穩定有時不收斂,因此這種模式還須要進一步探索成功路徑。Ranking Distillation裏採用的Point Wise Loss方式是比較成功的,不過和上文介紹的Point Wise有個區別:對於Teacher輸出的結果,選擇Top K的Item做爲正例,沒有選取負例;另外Student引入了Ground Truth做爲Loss子項。文中還提出了幾種比較有意思的Position Loss Weight方法。對具體細節感興趣的同窗能夠參考。

List Wise蒸餾
Point Wise Loss將學習問題簡化爲單Item打分問題,Pair Wise Loss對可以保持序關係的訓練數據對建模,而List Wise Loss則對整個排序列表順序關係建模。List Wise Loss常常被用在排序問題中,可是有個現實困難是訓練數據很差作,由於排序列表裏每一個Item的價值須要人工標註。
咱們來考慮下召回蒸餾模型的List Wise Loss優化目標怎麼作的問題。既然咱們能拿到大量精排給出的有序列表,貌似咱們是不缺訓練數據的,可是這裏隱藏着個潛在的問題,問題等會咱們再說。咱們先說個應用案例,Instagram的推薦系統在初排階段採用知識蒸餾的方法,使用精排做爲Teacher來指導Student的優化,Student的優化目標用的是NDCG,這是一種很是經常使用的List Wise Loss函數,對Instagram推薦系統感興趣的同窗能夠參考文章: Instagram 推薦系統:每秒預測 9000 萬個模型是怎麼作到的?
不過遺憾的是,上述文章並未說明是具體怎麼作的,只能靠咱們本身來摸索一下。其實細想一下,在這裏用NDCG來學習精排輸出的有序列表,這面臨待解決的問題:用NDCG是有前提條件的,有序列表中的每一個Item,都須要帶有一個價值分。好比對於搜索排序來講,最相關Item是5分,次相關Item是4分,相似這種分數,這通常是人工標註上的,而List Wise Loss就但願排序系統可以將列表總體得到的價值分最大化。上面咱們提到存在的問題就是:精排系統只給出了Item之間的排序關係,每一個Item並無提供對應的價值分。
那麼,若是想用NDCG或者相似的其它List Wise 損失函數,怎樣才能獲得列表內每一個Item的價值分呢?人工打標註顯然是不現實的。這裏,感受能夠利用一下精排系統輸出的Logits信息,假設咱們能夠設計一個函數:
這個函數以Logits分數爲輸入變量,將其映射到好比1分到5分幾檔上,Logits得分越大,則對應檔次分越高。若是咱們能作到這點,就可使用List Wise損失函數來訓練召回或粗排模型了。這個函數定義有各類可能的方法,這裏不展開,各位有興趣的同窗能夠試試。
若是咱們想更簡單點,不用Logits分數,那麼有更加簡單粗暴的方法,好比強行將有序列表排在Top 5的Item設置成5分,排在6到10位置的Item賦予4分…..相似這種。這等價於這麼定義F函數的:
這個公式充分展現了工業界的簡單暴力算法美學,我相信相似的公式充斥於各大公司的代碼倉庫角落裏。
聯合訓練召回、粗排及精排模型的設想
若是咱們打算把知識蒸餾這個事情在推薦領域作得更完全一點,好比在模型召回、粗排以及精排三個環節都用上,那麼其實能夠設想一種「一帶三」的模型聯合訓練方法。
如上圖所示,咱們能夠設計一個很複雜可是效果很好的排序模型做爲Teacher,而後和召回、粗排、精排三個Student聯合訓練,精排Student可使用Logits以及隱層特徵響應等各類手段優化,追求效果好前提下的儘量速度快,召回和粗排Student則追求在模型小的前提下追求效果儘量好。由於排序Teacher比較複雜,因此可以提供儘量好的模型效果,經過它來帶動三個環節蒸餾模型的效果,而模型速度快則是蒸餾方法的題中應有之意。
這樣作有很多好處,好比能夠一次訓練,多環節收益;再好比能夠最大程度上保持推薦系統各個環節的目標一致性等;作起來又不太難,因此看上去是個可行的方案。
最後,概括下全文,推薦系統在各個環節採起知識蒸餾方法,是可能達到提高推薦質量的同時提升推薦系統速度的,一箭雙鵰,比較容易產生效益,因此是值得深刻探索及應用的。
致謝:上面列的不少想法是在和幾位同窗的討論中造成或完善的,感謝微博機器學習佘青雲、王志強等同窗提出的思路和建議。

本文分享自微信公衆號 - 視學算法(visualAlgorithm)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。機器學習