導讀： 微博作爲全球領先的中文廣場社交平臺，擁有海量用戶與數據。在從海量數據中挖掘有價值的信息，爲業務賦能的過程中，微博的推薦算法經歷了數次升級換代，積累了許多經驗。今天跟大家分享下，在此過程中我們遇到的問題，並且在長期改進與積累的過程中，微博機器學習平臺的演進過程，以及當前架構如何更好的發揮算法的優勢，爲業務產生更多有價值的支撐。
主要內容包括：
- 微博簡介
- 相關推薦場景描述
- 微博推薦算法實踐
- 微博機器學習平臺
01 微博簡介
財報顯示：微博擁有2.4億日活DAU，5.5億月活MAU，94%的移動月活佔比。
微博利用機器學習相關的的算法策略通過對內容的合理發掘以及用戶興趣的個性化匹配，通過引導海量用戶的行爲，對優質UGC博主產生正向激勵，促進微博優質UGC的生態建設，進而提升用戶體驗。共同構建積極活躍的微博內容生態。
02 相關推薦場景描述
1. 相關推薦場景
我們今天從微博的相關推薦這個場景入手，深入聊一下微博的機器學習機制。相關推薦的場景如圖所示，它的邏輯就是用戶在點入正文頁之後，根據用戶的選擇，進行相關內容的推薦，引導用戶興趣收斂。
2. 相關推薦目標
相關推薦有兩個目標，第一個目標是個性化滿足用戶內容消費需求。
在此基礎上第二個目標是促進用戶興趣意圖收斂，減少用戶進一步搜索的行爲，提升體驗。
03 微博推薦算法實踐
我們將從三個方面進行闡述：機器學習流程、樣本與特徵，以及算法實踐。
1. 機器學習流程
item端：用戶發博後，分別經過一系列複雜的審覈與處理，將數據送入到物料庫和數據中臺中，作爲微博內容池的基礎物料。
用戶端：用戶通過瀏覽微博產生用戶行爲，經過ETL後，可以構建成機器學習服務的訓練樣本。
利用各種算法訓練提取到相關信息後，產出模型，上線到模型服務進而通過召回、排序等階段對用戶的行爲產生影響。
2. 樣本與特徵
① 樣本策略
首先，我們結合業務經驗對數據做了去噪和數據映射。爲了更好地評價相關性模型的離線效果，我們構建了一套人工標註的Benchmark數據集，指導模型迭代方向。並作爲離線指標評估基準。此外，我們在構建樣本時做了一系列的調整工作，有幾個典型的操作：例如我們在用戶側做的無效負樣本過濾，就是將最近30天不活躍的用戶曝光數據過濾掉，一方面削減負樣本的數量，一方面也減少了錯誤的負樣本給模型帶來的噪聲影響。此外，衆所周知，在實際業務中，構建樣本是dirty work，一致性層面我們花了極大精力來解決相關問題。但同樣，我們的嘗試也不完全都有效，比如在推薦流場景下效果不錯的負例優化，在我們的AB上並沒有觀測到明顯的正向提升。
② 特徵選取
特徵方面，微博有着非常豐富的特徵體系，不過我們的實際使用中只用到了幾大類，分別是ID類特徵、閱讀者特徵、發博者特徵、上下文特徵、環境特徵和物料特徵。
總的特徵選取原則是：減少人工干預，強化模型表現力。在實際模型分析中，也觀測到了符合預期的現象。ID類特徵效果最明顯，線上有超過10%的漲幅，親密度特徵單獨上AB，漲幅不明顯。但在ID特徵參與下，親密度特徵對線上效果有明顯正向作用。經模型分析後，發現模型特徵交叉得分有明顯優勢。
3. 算法實踐
① 召回
目前相關推薦的主要模型是FM&雙塔模型模型：
要注意的地方是對樣本的構建並不是常見的feature+label，也就是一個樣本對應一個label這種方式。在一個模型中用戶的正例樣本feature+負例樣本的feature拼接成的雙塔樣本，這樣不僅提升了整體可用的樣本數量，使得深度模型有機會得到更充分的訓練。還相當於對正樣本做了上採樣，平衡了正負樣本比例。
雙塔模型中，物料側參數是共享的，item側形成embedding和用戶側embedding進行cosine計算，學習目標是最大化正例負例距離，中間加了間隔閾值在裏面relu(P(D_pos|Q)-P(D_neg|Q) + margin)。深度方面，我們更深的雙塔也試過，但由於召回是非常扁平的結構，效果不變甚至下降。目前常用的是三、四層隱層。
② 模型升級
排序側的演進過程，我們和業界步調基本一致，從策略系統到統計類推薦，隨後到LR的模型排序，發展到FM，以及後來的FFM、Deep&Wide、DeepFM。整體來看，就是先擴大模型規模，再強化模型對特徵交叉的捕獲，隨後是embedding的崛起引導的更高階特徵的使用。
③ 規模提升
爲了更強的模型表達能力，我們在更加多樣化的特徵組合和豐富的場景特徵的基礎上，大規模引入了ID類特徵。從右圖可以看到隨着模型規模的越來越大，業務效果表現出了明顯的正相關。
微博的實踐經驗表明，一定情況下機器學習的規模越大，效果指標就越好。同時隨着模型維度的膨脹，模型訓練階段需要的數據量也在幾何級上升。
大規模機器學習，帶來可觀的業務收益的背後，也帶來了極大的挑戰。
④ 大規模遇到的問題
模型規模增大也帶來了一些問題，比如海量參數和梯度爆炸。
問題1：海量參數
模型太大，存不下、算不動、算的慢。
解決方案：
- 存不下 。我們通過自研的weips，也就是參數服務器來解決模型存儲的問題；如果有不瞭解的同學，可以簡單抽象爲一個帶自定義操作 ( 我們稱之爲psfunc ) 的大規模外部KV存儲。
- 算不動 。模型訓練方面，我們基於flink實現，同時爲了降低存儲和計算開銷，對算法的求解過程做了稀疏化改造，並且參數改爲低精度的類型來降低存儲開銷。
- 算的慢 。線上引擎的同學，通過指令集層面的優化，極大提升推理速度，解決了算的慢的問題。
問題2：梯度爆炸
模型不收斂，經排查出現了梯度爆炸，因爲參數比較大，裏面相加相乘的項比較多，進而導致了梯度爆炸。
解決方案：
- 首先對激活函數做了定義域的截斷，相當於模型輸入和輸出都是一定在一定範圍之內的，從表面上解決了梯度爆炸的情況，但是實質的問題沒有解決。
- 通過優化初始化參數，讓初始化的參數極度逼近於0，也就是均值是0，方差極小，來減少梯度爆炸的概率。
- 我們在優化算法的過程中同樣做了梯度的裁剪，裁剪的方式也是設置了閾值的空間，超過閾值區間，我們會拋棄梯度。過小的梯度丟棄可以降低參數同步成本，提升參數同步的速度；過大梯度丟棄可以保證模型的穩定性，防止梯度爆炸，也減少了噪聲產生的機率。
- 此外我們在大規模深度學習實踐中也發現了batch_norm，是非常有效的避免梯度爆炸的手段。
⑤ 部署Weiflow
模型訓練完了之後會進行線上部署，流程如下圖，主要是通過靈活配置來解決依賴和資源相關的問題，解決了人力消耗的問題，新人小白幾個小時就可以把流程部署完成，提高了效率。圖中是小時級模型訓練與上線，經過實際驗證，在完全一樣的配置下，相比對照組線上指標上漲35BP。
⑥ 在線機器學習
第一版，我們實現了FM這個模型，主要是FM比較簡單，支持稀疏化操作，並且FM在離線是比較成熟的模型，各方面的支持也比較完備，模型基礎好，工作量小。實現了SGD，FTRL和AdaGrad等多種優化器來保證效率，提高模型的收斂效果。訓練是基於Weiflink ( Flink 微博的實時計算框架，基於Flink開發與封裝 )，配合阿里雲從Yarn遷轉到K8s服務器，保證了穩定性。在線深度學習的開發也基本完成正在內測階段。
在線機器學習系統主要包括如下幾個部分，樣本生成服務、模型訓練服務、參數服務、模型部署服務、模型預估服務、排序服務。
我們認爲一個重要的點是在線機器學習需要把用戶行爲日誌進行拼接的，比如用戶的閱讀行爲、點擊行爲、曝光行爲等，Flink本身不支持，微博是通過二次開發進行多流拼接。拼接生成樣本後進入訓練組件，再有訓練組件將梯度參數傳遞到參數服務器上。參數服務器在解決參數存儲的同時，重點解決了熱點存儲訪問和通信效率的問題。
⑦ DOING
召回：
目前的是將用戶的行爲序列引入雙塔模型。如圖，引用MIE ( 用戶序列特徵 ) 的ID類特徵，通過預定義的操作將ID類特徵轉換成Embedding送入雙塔中訓練，基於歐氏距離來做用戶與物料的召回。行爲序列是通過卡了一段時間的樣本取得定長的樣本進行操作的。模型效果比較明顯，單路召回點擊率有兩位數提升。
排序：
FiBiNET是將原始樣本轉化成Embedding的形式，然後將Embedding通過SENET Layer得到SENET-Like Embedding，然後將兩部分分別進行內積和哈達瑪乘積，再將結果進行concat，最後送入mlp。
在相關推薦實際數據的離線驗證中，AUC有20BP的漲幅。小流量實驗也觀測到了正向效果，效果可期。但因爲我們仍然處於放量階段，考慮到可能存在的流量分桶不均、用戶分組不均等情況，在沒有實際大流量和反轉試驗前，確定性的結論不便於直接得出。不過目前來看，在相對DeepFM沒有明顯耗時劣勢的前提下，取得相當不錯的正向表現，大家隨後也可以實際嘗試下。
04 微博機器學習平臺
1. 微博機器學習平臺
① 平臺演進
平臺的支持對業務的支撐非常重要，目前機器學習平臺支持的算法越來越多，靈活性越來越好，時效性也越來越高，存儲性和穩定性都在穩步提升。目前支撐的參數規模到達萬億級，峯值到百萬QPS，模型更新達分鐘級。
② 平臺現狀
平臺對外是一站式機器學習平臺，就是通過統一交互和統一調度，將封裝了數據存儲能力和計算能力的各種物料、特徵、樣本、模型等服務，打包組合成解決方案，配合經驗的共享和規範的統一，提供給業務方使用。
③ 平臺接入
目前業務方的接入形成閉環的場景，從原始數據處理到模型推理都可以在平臺一站式完成。業務方需要重點關注模型效果和業務效果的評估。正在推進中的是AutoML的自動模型評估，以及ABTest打通，進一步完善機器學習平臺閉環，真正的一站式解決廣大同學們的痛點。使用平臺過程中，業務同學主要關注機器學習工作流和標準化的組件，提供插件化開發（weiclient、weiblink/weiflink、weilearn等插件化開發），由用戶自定義，最終沉澱爲平臺組件。
④ 工作WeiFlow
這張圖是WeiFlow的協議定義，是一個雙層的有向無環圖，雙層主要是爲了兼容異構環境和由於歷史原因導致的不同計算框架。
⑤ 典型WeiFlow
這是典型的工作流實例，可以看到圖中有多源依賴、並聯依賴、鏈路串聯依賴，基於雙層dag設計可以完成兼容來統一託管新舊作業，實現作業的平滑遷移。
⑥ 服務標準化
從業務方反饋來看，機器學習平臺可以解決業務痛點之外還可以提供一些提升效率的服務，比如指標數據統計、樣本特徵分析、Weilearn-plugin。 此外從後臺統計來看，SQL計算服務、深度學習服務、工作流服務作爲服務使用Top3，一方面體現機器學習流程中樣本、模型和工作流是剛需和常態需求。另一方面也體現平臺專注於機器學習的特點與風格。
2. 微博機器學習平臺的使用
下面看看機器學習平臺是怎麼用的：
① 計算服務
機器學習平臺提供了統一完整的SQL計算服務，一站式解決不同集羣，不同計算引擎，不同數據源的各種操作。彙集了不同的數據源，和不同的集羣的使用概覽，還有跨集羣的數據的關聯join，整體平臺構建了一組統一的邏輯數據集羣。這些對用戶都是透明的，可以更專注於業務和數據本身。
② 樣本服務
如何管理樣本呢？平臺的樣本庫不僅記錄了樣本的數據信息還有樣本管理、共享和權限控制，既提供了共享的需求，也保證了數據安全。
③ 特徵服務
平臺提供接口查詢樣本中的特徵，可以查一下目前支持什麼樣的特徵，是否也有新特徵需要上線，並且針對特徵的可用性提供了特徵完善度的統計。此外管理了數據的密級和訪問記錄，切實保障數據安全。
④ 訓練服務
依託於模型庫，模型訓練就變得很簡單了，用戶只要關注用什麼模型、模型參數、樣本輸入和特徵配置。模型訓練組件和樣本庫、模型庫聯動，支持一鍵上線和自定義模型改造。在簡化使用的基礎上，還保證了使用者極大的靈活性。
⑤ 模型服務
模型訓練好之後要進行上線，這是通過模型服務完成的，模型服務和模型訓練聯動，擁有模型一鍵上線和版本切換的能力。實際中模型迭代非常快，版本的變更和模型同步也是很複雜的事情，機器學習平臺解決了這個問題。此外支持配置共享，模型超參、特徵處理、指標信息的組內分享，提高了效率。
3. 效果指標
隨着平臺接入，結合效率提升與經驗賦能，平臺同學同業務同學共同努力帶來的漲幅十分可觀。相關推薦和新浪移動都產生了核心指標double的喜人變化。
最後，我們希望能夠"以微博之力，讓世界更美"。今天的分享就到這裏，謝謝大家。
作者介紹：
申恩兆，新浪微博算法工程師
李志然，新浪微博算法工程師
本文來自 DataFunTalk
原文鏈接：