在推薦場景會遇到資料二八分佈的問題，20%的場景應用80%的樣本，這就導致一個問題：單一模型對大場景預估更友善。如何兼顧各場景，提升模型個人化能力是個人化建模的痛點。
業界方案：
針對業界模型存在的問題，我們提出如下解決想法：
整體想法是利用元學習在雲端為每個使用者部署一套個人化模型參數，最終達到對成本和效能沒有損失的效果。
#元學習指的是學習到通用知識來指導新任務的演算法，使得網路具有快速的學習能力。例如：上圖中的分類任務：貓和鳥、花和自行車，我們將這個分類任務定義成K-short N-class 的分類任務，希望透過後設學習，學習到分類知識。在預估finetune過程，我們希望對於狗和水獺這樣的分類任務，用很少的樣本，進行微調就能得到極致的預估效果。再舉一例，我們在學習四則混合運算時，先學習加減，後學習乘除，當這兩個知識掌握了，我們就能夠學習這兩個知識融在一起如何來算，對於加減乘除混合運算，我們並不是分開來算，而是在加減乘除的基礎上，學習先乘除後加減的運算規則，再用一些樣本來訓練這個規則，以便快速了解這個規則，以至於在新的預估數據上得到比較好的效果。元學習的思路與此類似。
傳統的學習方法，目標是學習到使得所有資料達到最優的θ，也就是全域最優的θ。元學習是以task為維度，來學習場景上的通用
，在所有場景上面loss都能達到最優。傳統的學習方法學到的θ，更靠近大場景的人群，對大場景預估更好，對中長尾預估效果一般；元學習是學習到各個場景都相近的一個點，在用每個場景的資料或新的場景的資料在這個點上微調，達到各個場景最優的一個點。所以可以實現，在每個場景中建構個人化的模型參數，達到極致個人化的目標。上述實例中是以人群為task進行元學習，也適用於使用者或item為task進行建模。
元學習有三種分類：
##Model-Agnostic Meta-Learning (MAML)是與模型結構無關的演算法，適合通用化，分為兩部分：meta-train和finetune。
meta-train有一個初始化θ，進行兩次取樣，場景取樣和場內取樣取樣。第一步，場景採樣在這一輪採樣過程中，全體樣本有十萬甚至上百萬的task，會從上百萬的task中採樣出n個task；第二步，在每個場景上，為這個場景採樣batchsize個樣本，把batchsize個樣本分成兩部分，一部分是Support Set，另一部分是Query Set；用Support Set 使用隨機梯度下降法更新每個場景的θ；第三步，再用Query Set為每個場景計算loss；第四步，將所有的loss相加，梯度回傳給θ；整體進行多輪計算，直到滿足終止條件。 其中，Support Set可以理解為訓練集合，Query Set理解為validation集合。
Finetune過程和meta-train過程很接近，θ放在具體的場景中，取得場景的support set，利用梯度下降法（ SGD），得到場景的最優參數
；使用
對task場景待評分的樣本（query set）產生預估結果。
#將元學習演算法應用在工業化的場景中會有比較大的挑戰：元學習演算法的meta-train過程涉及兩次採樣，場景採樣和樣本採樣。對於樣本而言，需要把樣本組織好，同時按照場景的順序儲存下來並進行處理，同時需要一個字典表來儲存樣本和場景的對應關係，這個過程十分消耗儲存空間和運算效能，同時需要將樣本放到worker中進行消費，這對工業化場景有非常大的挑戰。
我們有以下的解決方法：#
#首先在meta-train中實現batch內場景和樣本的選擇，每個batch內會有多條數據，每個數據屬於一個task。在一個batch內，將這些資料依照task抽取出來，抽取的樣本放到meta-train訓練過程中，這樣就解決了需要獨立維護一套場景選擇和樣本選擇的處理連結的問題。
透過實驗研究並閱讀論文，我們發現，在fine-tune以及在元學習過程中，越接近預估層，對模型的預估效果影響越大，同時emb層對模型的預估效果影響較大，中間層對預估效果也沒有很大的影響。所以我們的想法是，元學習只選取離預估層較近的參數就可以，從成本上考慮，emb層會導致學習的成本增加，對emb層就不進行元學習的訓練了。
整體訓練過程，如上圖中的mmoe的訓練網絡，我們對tower層的參數進行學習，其他場景的參數還是按照原始的訓練方式來學習。以user為維度來進行樣本的組織，每個使用者有自己的訓練數據，把訓練資料分成兩部分，一部分是support set，一部分是query set。在support set中，只學習local側的內容進行tower update，進行參數訓練；再用query set資料對整體的網路進行loss計算後梯度回傳，來更新整個網路的參數。
因此，整個訓練過程是：整體網路原訓練方式不變；元學習只學習核心網路；從成本方面考慮，embedding不參與元學習；loss=原loss 元loss；fintune時，把emb存放起來。 serving過程，用emb微調核心網絡，同時可用開關來控制元學習隨開隨關。
對於傳統的樣本儲存方式，如果在serving過程，直接進行finetune，會存在較嚴重的問題：需要在線上維護一套樣本儲存鏈路；多套線上實驗需要維護多套樣本。同時，finetune流程，用原始樣本進行finetune，樣本要經過emb層、bottom layers層以及meta-learning層，但是元學習在serving過程只需要學習meta-learning layers，不關心其他部分。我們考慮在serving過程，只保存meta-learning input 存到模型中，這樣就能節省樣本鏈路的維護，同時達到一定的效果，如果只存emb這一部分，可節省該部分的計算成本和維護成本。
我們採用如下的方法：
#把儲存放到模型的lookup table中，lookup table 會被認為是一個dense 的variables，儲存在ps中，所有的參數都會pull到worker 上，更新時，也會push到所有的variables ,這樣會增加網路的耗時。另一種方式是使用無量HashTable，HashTable是以key、value的形式存儲，key是場景，value是meta layer的input，這樣做的好處是，只需將所需要的場景的input layer從ps上進行push或pull，整體會節省網路的耗時，所以我們取樣該方法來儲存meta layer 的input。同時，如果將meta-learning layers 儲存到模型中，會使得模型變大，也會遇到過期的問題，導致和目前的模型不匹配，我們使用時間淘汰極致來解決該問題，即淘汰掉過期embedding ,這樣既使得模型變小，也能解決即時性的問題。
這個模型在serving 階段，會使用embedding，embedding輸入到bottom layers，打分數時，並不像原始的方式一樣，而是透過meta-learning layers拿到support set 中的數據，將該層的參數更新，使用更新後的參數進行評分。這個過程在GPU上無法進行計算，因此我們在CPU上執行該過程。同時，無量GPU推理做了Auto Batch合併，將多個請求進行合併，合併後的請求在GPU上進行計算，這樣處理，梯度會隨著batch的增加而變化，針對該問題，我們在batch和grad的基礎上，增加一個num維度，計算梯度時，將grad進行相加，並依照num 處理後，維持梯度的穩定性。最終實現成本和性能可控，同時實現了千境千模。
#借助框架、元件將元學習通用化，用戶在存取時，只需修改模型程式碼，使用者無需關心訓練和serving，只需調用我們已經實現好的接口，例如：support set讀寫接口、meta-train和finetune實現接口以及GPU serving適配接口等。用戶只需傳入loss、task inputs、label等業務相關參數。這樣設計，節省了演算法工程師調查、開發、實驗和試錯的成本，提升了演算法的迭代效率；同時，通用化的程式碼，可服務多個業務場景，節省人力和資源成本。
元學習在雙塔召回場景下的使用，是以使用者為維度進行建模，包括user塔和item塔。模型的優點是：可插拔，無需改動樣本和線上架構，穩定無風險；缺點是support set是前一個小時的數據，有即時性的問題。
元學習的另一個應用場景是在序列召回場景，該場景是以使用者為場景來建模，以使用者的行為序列作為support set，用戶行為序列只有正樣本，我們會維護一個負樣本隊列，採樣隊列中樣本做為負樣本，並拼接上正樣本作為support set。這樣做的好處是：即時性更強，成本更低。
最後，元學習也應用在排序場景中，如上圖的mmoe精排模型，實作方式有兩種：只使用finetune ，以及同時使用meta-train和finetune。第二種實現方式效果更優。
元學習在不同的場景中都取得了較好的效益。
每個場景有多個建議的入口，需要為每個場景建立一套召回、粗排到精排的鏈路，成本較高。尤其小場景和中長尾流量資料稀疏，優化空間受限。我們能否將一個產品內相似推薦入口的樣本、離線訓練和線上服務融合成一套，達到節省成本並提升效果的目的。
但是，這樣做也存在著一定的挑戰。在瀏覽器上搜尋谷愛凌，會出現相關搜尋字詞，點擊具體的內容並返回後，會出現結果點擊後的推薦，這兩種的流量佔比、點擊率以及特徵分佈的差異都比較大，同時在預估目標上也有差異。
如果將跨域的模型使用多任務模型，就會產生比較嚴重的問題，並不能拿到比較好的收益。
在騰訊實現跨場景建模具有較大挑戰。首先在其他企業，兩個場景的特徵能夠一一對應，但在騰訊的跨域推薦領域兩個場景的特徵無法對齊，一條樣本只能屬於一個場景，數據分佈差異大，預估目標難對齊。
針對騰訊跨域推薦場景的個人化需求，採用上述方式進行處理。對於通用特徵進行shared embedding，場景個性化的特徵自己獨立embedding空間，在模型部分，有共享的expert和個性化的expert，所有的數據都會流入共享的expert，每個場景的樣本會數據各自的個性化expert，透過個人化gate將共享expert和個人化expert融合，輸入到tower，用star的方式來解決不同場景的目標稀疏的問題。對於expert部分，可以採用任意的模型結構，例如Share bottom、MMoE、PLE，也可以是業務場景上的全模型結構。此方式的優點是：模型的通用性強，適合各類模型融合接入；由於可以直接將場景expert遷移，對原場景效果無損，實現跨場景知識遷移效果提升；融合後模型減小，訓練速度提升，同時節省成本。
我們進行了通用化建設，紅色部分是需要個人化存取的內容，例如：個人化特徵、個人化模型結構等，使用者只需寫入個人化的程式碼即可。其他部分，我們已經將整套程式碼連接到ModelZoo，可直接繼承使用，並將其封裝成機器學習平台工作流程元件，可直接運行，該方式減少了多場景學習研究和存取成本。
這種方式讓樣本量變多，模型結構變得複雜，但效率反而提升了。原因如下：由於一些特徵是共享的，融合後的特徵數比兩個場景特徵數的加和要少；由於shared embedding的功能，batch內key均值，比兩個場景的加和要小；減小了從server端pull或push的時間，從而節省了通訊耗時，整體降低了訓練耗時。
多場景的融合能使整體成本減少：離線樣本處理，能夠減少21%的成本；採用CPU追數據，會節省24%的成本，同時模型的迭代時間也會減少40%，線上訓練成本、線上服務成本、模型大小都會降低，所以全鏈路的成本降低了。同時，將多個場景的資料融合在一起，更適合GPU運算，將兩個單一場景的CPU融合到GPU上，節省的比例會更高。
跨域推薦可透過多種方式來使用。第一種，多場景單目標的模型結構，可直接使用多場景的建模架構，不建議使用tower側的star；第二種，多場景多目標的融合，可直接使用多場景的建模框架；第三種，同一個精排產品，不同目標模型融合，可直接使用多場景建模框架，不建議使用tower側的star；最後一種，同產品多個召回、粗排模型融合，目前正在進行中。
跨域推薦不僅在效果上有提升，在成本上也省了很多。
以上是騰訊TRS之元學習與跨域推薦的工業實戰的詳細內容。更多資訊請關注PHP中文網其他相關文章！
