雲音樂播放頁直播推薦實戰

語言: CN / TW / HK
時間 2022-10-09 22:16:01
主題:

圖片來源：http://unsplash.com/photos/ooZfU1oyS7E

作者：TrainableLu，左馮翊

0. 引言

直播是一種高即時，強互動的內容展現形式，一般在主播向觀眾傳達內容的同時與觀眾進行互動。在泛娛樂直播產品中，直播滿足了使用者尋求陪伴，娛樂消遣、打發時間的需求，同時也滿足了主播實現盈利和獲得關注認可的需求。 iiMedia Research（艾媒諮詢）資料顯示，2020 年中國線上直播使用者規模為 5.87 億人，預計未來繼續保持增長態勢，2022 年使用者規模將達 6.6 億人。艾媒諮詢分析師認為，電競、電商、教育等新形態直播內容興起為行業注入新的發展活力。各大平臺積極推進直播與其他型別相結合，也使更多內容形態出現，吸引更廣泛的使用者群體。（資料來源：2020-2021中國線上直播行業年度研究報告） img LOOK 直播是網易雲音樂旗下一款主打音訊直播的直播軟體，依託網易雲音樂的音樂人生態，為使用者打造最具音樂屬性的直播新體驗。LOOK 直播不僅有獨立的 APP，在雲音樂 APP 也有多個入口。 本文以歌曲播放頁直播入口為例，介紹雲音樂直播個性化推薦的實踐，包括以下幾個部分：

  • 業務背景。介紹 Look 直播在雲音樂 APP 的產品形態，以及演算法推薦的目標。
  • 業務挑戰。介紹直播推薦業務的特點，以及我們遇到的挑戰。
  • 實時推薦。介紹實時推薦的方案，包含流式樣本、樣本歸因和增量訓練。
  • 多目標融合。介紹多目標融合，包含 ESMM、MMoE 和 Loss 融合。
  • 多模態探索。介紹我們在直播推薦多模態探索方面的一些進展。

1. 業務背景

LOOK 直播依託於雲音樂 APP，有著豐富的流量入口以及各種各樣的展現形式，不同入口的產品職能和使用者心智存在較大的差異。如圖 1 所示，是雲音樂直播在首頁、歌曲播放頁、評論頁的產品形態。除了這 3 個流量比較大的入口，雲音樂直播還有搜尋綜合頁、我的頁面和更多頁等入口。 img 在實際推薦的過程中，我們希望除了滿足使用者本身在內容消費上的需求以外，我們更希望能夠去推動使用者和主播發生更多的互動。在業務目標上，我們會關注 CTR、觀看時長這樣的內容項的指標；同時，也會考慮社交關係達成方面的指標，如關注轉化；另外，雲音樂直播本身也承擔了比較重要的營收職能，因此付費轉化為代表的營收指標同樣是重點。除此之外，我們還會從整個生態的角度來兼顧生產者（主播側）和消費者（使用者側)的留存問題。

2. 業務挑戰

歌曲播放頁直播入口（也稱直播播放頁）是 Look 直播在雲音樂最大的一個流量入口，它的位置非常特殊：位於歌曲播放頁的右上角。因此，歌曲播放頁直播推薦不僅有著直播推薦的共性，也有著自己的個性。 我們先來看看直播推薦的一些共性。 - 實時變化 直播推薦和商品推薦等場景有一個比較大的區別是，直播推薦的物件（即主播）是動態的、有主觀意識的，主播的情感表達等表現是會影響直播間的效率的。直播是長時間連續性的，內容會實時變化，比如主播可能在這個時刻唱歌，在下一個時刻就聊天，如果某些使用者喜歡看跳舞直播，那麼當主播不跳的時候，他們可能就退出了。如圖所示，同一個主播，在不同的時間段效率差別比較大。對於這個問題，我們將在第 3 節「實時推薦」講述如何解決這個問題。 img - 多目標 多目標由業務驅動。在電商場景，我們希望推出的商品，使用者不僅點選而且購買，如果能評論分享就更好了。在直播場景，我們希望推出的主播，使用者不僅點選而且有效觀看，如果能打賞就更好了。在雲音樂直播場景，我們可以優化的目標有點選、觀看、送禮和評論等，考慮到不同目標之間的相互影響，模型的主要優化目標是點選和有效觀看（觀看超過 30 秒）。在第 4 節「多目標融合」，我們將講述如何通過多工模型來平衡不同目標的相互影響。 - 多模態 直播推薦給使用者推薦的是主播，但不僅僅是主播。實際上，我們給使用者推薦的是一個直播間，包含直播間的入口文案、主播頭像、主播本身等。直播文案和主播頭像是吸引使用者點選直播間的重要因素，使用者進入到直播間後，直播內容是促使使用者轉化的重要因素。因此，我們需要對多模態的內容進行理解、融合，包括但不限於： 1. 文字（如直播文案、直播間彈幕等） 2. 圖片（如主播頭像、封面等） 3. 視訊（如識別主播是否在跳舞、掛機等） 4. 音訊（如識別主播是否在唱歌，在唱什麼型別的歌等） 針對這個問題，我們將在第 5 節「多模態探索」講述我們在多模態方面的一些探索。 上面講了直播推薦的一些共性，接下來我們看看歌曲播放頁直播推薦的個性。 - 只有一個展現位，且展現素材面積較小（頭像尺寸半徑只有 45px） 在商品或者資訊流等列表式推薦場景，使用者一次請求就能帶來幾條曝光，命中使用者興趣點的概率較大，而在歌曲播放頁直播場景，使用者一次請求只能曝光一條，命中使用者興趣點的概率相比小了很多。 另外，使用者不太容易感知到歌曲播放頁右上角有一個推薦位，而且不同的主播只能靠一個小頭像和短文案去識別，個性化相對較弱。因此，除了優化 Rank 模型，我們還需要在展現物料的樣式和形態上面做一些優化。 - 新使用者在有效觀看使用者和有效觀看次數中佔比大 這裡新使用者的定義是：過去 30 天內未有效觀看的使用者。我們對直播使用者進行了分層：新使用者、活躍使用者和付費用，經分析發現，新使用者在有效觀看使用者的佔比，以及在有效觀看次數的佔比，都達到了 XX% 以上。從模型的角度來分析，也就是，大部分樣本覆蓋的使用者都是新使用者，他們的直播行為不豐富，這樣就會導致模型的個性化能力比較弱（容易給新使用者推熱門主播），也不可避免地會加重該場景的馬太效應。 img

3. 實時推薦

如果把推薦系統簡單地看成是一個排序函式 f(x)，那麼可以把實時性拆成兩點： - 輸入 x 實時 - 模型 f 實時 其中，輸入 x 實時，也就是特徵實時，可以根據時效性分為三個粒度： - 毫秒級特徵：依靠客戶端在請求中填入時間、地點、場景等上下文特徵 - 秒/分鐘級特徵：依靠流式計算，做一些簡單的統計類特徵的計算和聚合使用者行為反饋資料等，比如統計主播在某個時間視窗的點選次數等 - 小時級特徵：依靠離線計算，可以進行更高階的特徵組合的工作，比如統計使用者在某個時間視窗對主播標籤的轉化率分佈情況等 而模型 f 實時，可以拆解為： - 訓練資料流式生成：曝光流、點選流等和各類行為資料實時接入，流式關聯特徵資料，生成訓練樣本 - 增量學習/線上學習：訓練資料隨著時間的推移源源不斷地加入到當前訓練流程中，以增強當前模型的擬合能力。增量學習往往在獲得一批新樣本後再進行訓練更新，而線上學習則是在每次獲得一個新樣本的時候就實時更新模型 這裡我們重點介紹下流式樣本、增量學習的具體做法。

3.1 流式樣本

我們與實時計算組合作，最早將基於 snapshot 的實時樣本在直播播放頁落地，較好地解決了線上線下特徵不一致、實時特徵容易導致穿越等問題。經過不斷地完善與優化，目前這套框架已應用於直播的各個場景、播客等各業務，取得了不錯的效果。 下面我們以直播播放頁為例，對這套框架做一個介紹。（注：可能跟目前最新的框架有所出入，但核心思想基本一致） img 整體業務流程如下： （1）線上預估請求所用到的原始特徵在旁路環境 dump 到 kafka，經過 flink 解析，按照一個格式寫入 kv （2）Flink 任務 1：將埋點與 snapshot 進行拼接

  • 將 traceid，userid，itemid 和曝光轉化(曝光為 0，轉化為 1）拼成一個 key 寫入 redis，供後面的正負樣本標記使用

  • 用曝光、轉化去關聯 kv 中的 snapshot，將能關聯上的結果寫入拼接成功的 kafka，關聯不上的結果寫入拼接失敗的 kafka （3）Flink 任務 2：進行兜底樣本拼接。消費拼接 snapshot 失敗的 kafka，去特徵 tair 叢集拿相應特徵生成 snapshot，並將結果寫入拼接成功的 kafka （4）Flink 任務 3：進行正負樣本拼接

  • 消費拼接成功的 kafka，資料延遲 M 分鐘處理（這裡的 M 如何設定，在下一節 樣本歸因 介紹）

  • 當來了一條曝光樣本，我們去 Redis 查詢是否有對應的轉化行為，如果能查到，就丟棄當前曝光樣本，否則標記當前曝光樣本為負樣本(label=0)
  • 當來了一條轉化樣本，則直接標記為正樣本(label=1)
  • 另外，為了解決埋點重複上報的問題，我們可以這樣做，當來了一條曝光樣本，我們用 traceid_userid_itemid_0 去 Redis 查詢該 key，判斷對應的 value 是否為 1，如果是則過濾掉該樣本，否則修改其 value 為 1；轉化樣本同理
  • 將上面拼接後的資料寫入 kafka（5）Flink 任務 4：消費 kafka 的樣本資料，進行特徵抽取、格式處理，並寫到 HDFS

該方案具有以下優點： - 正負樣本實時拼接，能夠支撐實時性要求高的業務需求 - 有兜底模組，在旁路環境或 snapshot 等異常情況下，可以最大補全 snapshot 特徵 - 整個樣本拼接流程都在流裡完成，只有最後使用環節才落地 hdfs，避免了 flink 頻繁寫 hdfs

3.2 樣本歸因

樣本歸因即對樣本賦予 ground truth，我們知道，轉化是有延遲的，即在點擊發生過後一段時間使用者可能才會發生轉化，且往往轉化漏斗越深，延遲的時間越長。 那麼，在對流式樣本進行歸因的時候，就會遇到實時性和準確性 trade-off 的問題。一方面，我們需要樣本儘可能實時，但是有些事件的 label 可能還沒回流，如果此時把樣本餵給模型訓練，就會導致模型預估不準；另一方面，如果要等待事件的 label 完全迴流再訓練，比如說事件的真實 label 能在一天內完全迴流，也就是我們常見的天級訓練，但此時樣本就不實時了。

上述問題也被歸納為一個延遲反饋（delayed feedback）的問題。下面我們介紹幾種解決方案。 (1）使用 Flink 進行延遲處理。首先我們要確定兩個資料流關聯的時間視窗，我們會通過離線的方式對兩份資料在不同的時間範圍內做 join，以此判斷線上需要的時間視窗。比如業務接受的最低關聯比例是 95%，並且通過離線測試確認 20 分鐘內兩個資料流可以關聯 95% 的資料，那麼就可以用 20 分鐘作為時間視窗。這裡的關聯比例和視窗時間就是在準確性和實時性之間做一個 trade-off。目前直播播放頁就是採用這種方式。 (2）不使用延遲處理的方式，而讓負樣本和正樣本都去更新模型，這種實時性最高。這樣做的話，流式樣本就會出現 False Negative 樣本，但我們可以通過 Importance Sampling 對樣本加權、False negative calibration 和 Positive-Unlabeled Learning 的方式來近似學習一個無偏的資料分佈。具體細節可以參考 Twitter 發的一篇 paper《Addressing Delayed Feedback for Continuous Training with Neural Networks in CTR prediction》。 (3）不使用延遲處理的方式，而對延遲時間（點選行為和轉化行為的時間間隔）進行建模。著名廣告公司 criteo 發表了一篇論文《Modeling Delayed Feedback in Display Advertising》就介紹了這種方法，它的主要思想是對於還未觀察到轉化的樣本，不直接將其當做負樣本，而是考慮 click 發生的時間距離當前時間的長短，給予模型不同大小的梯度。它採用兩個模型進行建模，第一個模型用於預測使用者發生轉化的概率，即轉化率模型；第二個模型用於預測使用者發生轉化的情況下，延遲時間（點選行為和轉化行為的時間間隔）的概率。

3.3 增量訓練

增量訓練並非一直增量，而是配合全量訓練，因為如果一直使用增量模型，時間長了會產生一定的偏差，偏差累積效應會影響線上效果，因此，通過定期的全量更新進行矯正是必須的。 如圖所示，左邊是分鐘級的流式樣本，通過訓練，增量地對模型進行更新；右邊是通過全量樣本對模型進行全量的 full-batch 更新。 img 另外，在增量訓練過程中，我們還會遇到如下問題： - 低頻的特徵進入模型訓練，會導致模型預估結果不置信。這種情況需要我們對特徵設定准入規則，比如設定特徵頻次過濾掉低頻特徵，或者對低頻特徵施加比較大的正則項等進行解決 - 特徵規模一直在增長，會給線上預估效能和機器記憶體帶來壓力。這種情況需要我們對特徵進行淘汰，比如淘汰長時間未更新的特徵、淘汰 L1 正則項很小的特徵等

3.4 業務效果

  • 在直播播放頁場景下，基於 snapshot 模型，5min 更新模型，相對於對照組，平均點選率提升 3.15%，平均有效觀看率提升 2.52%
  • 在首頁直播場景下，基於 snapshot 模型，T8 組 15min 更新模型，相對於對照組，平均點選率提升 6.57%，有效觀看率提升 5.06%

4. 多目標融合

直播推薦是一個典型的多目標場景，在一個使用者的行為路徑中，會經過點選、觀看、關注和打賞等過程，而且不同行為的發生有先後順序和依賴關係。比如，當用戶在歌曲播放頁的時候，如果點選右上角的直播入口，這時產生點選行為，點選之後會進入到直播間，這時會產生觀看行為，觀看一段時間後會有一定概率發生各種互動行為。使用者的每一種行為都可以成為多目標模型裡的一個目標，那麼如何建模呢？目前業界主要有以下幾種方式： - 分開建模。這種方式對於每一個業務目標，單獨訓練一個模型，線上通過組合多個模型輸出決定最終排序。這種方式的優點是分開迭代，各司其職，對於單一模型，迭代速度會更快。而缺點也很明顯，由於各個目標獨立擬合，目標之間的依賴關係資訊就會丟失，各任務之間無法共享資訊，資源使用也較多，目標一旦變多維護也比較困難。 - 聯合建模。這種方式通過一個模型同時訓練多個目標，線上進行多目標融合。這種方式的優點是各個任務之間能夠共享資訊，統一迭代方便，節省資源；缺點是模型較為複雜，各任務之間可能相互影響，模型精度可能會有所損失，影響迭代速度。 - 樣本加權。這種方式通過修改樣本權重來體現目標的重要性，比如在點選模型裡面使用時長加權、完播率加權等。這種方式的優點是簡單，易於快速上線，缺點是迭代靈活性不夠。 - LTR（Learning To Rank）。通過 LTR 的方式來對多目標建模，比如 Lambda MART 演算法。這種方法的優點是直接優化排序目標，排序效果較好，缺點是需要構造期望排序的樣本對，樣本數量大，而且有些偏序關係不容易構造，多目標之間的關係也不易調整。 目前，直播播放頁的模型目標主要有點選和有效觀看（觀看超過 30 秒），為此，我們嘗試過分開建模和聯合建模兩種方式，考慮到資源使用和維護成本等因素，我們當前的多目標模型都是聯合建模。對於多目標聯合建模，我們主要嘗試了 ESMM 和 MMoE 兩種模型，下面我們分別介紹這兩種模型。

4.1 ESMM + FM

ESMM 模型是 阿里媽媽團隊 2018 年發表在 SIGIR 上的一篇論文《Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate》，文章基於 Multi-Task Learning 的思路，主要為了解決 CVR 預估碰到的兩個關鍵問題： - 資料稀疏（Data Sparsity）。CVR 模型的訓練樣本量遠小於 CTR 模型的訓練樣本量。 - 樣本選擇偏差（Sample Selection Bias）。傳統 CVR 模型通常以點選資料為訓練集，其中點選未轉化為負例，點選且轉化為正例。但是訓練好的模型在線上使用時，則是對整個空間的樣本進行預估，而非只對點選樣本進行預估。也就是說，訓練資料與實際預測的資料來自不同分佈，這個偏差對模型的泛化能力構成了很大挑戰。 下面，我們看 ESMM 模型如何解決這兩個問題。 ESMM 的網路結構如圖所示： img 1）為了解決資料稀疏的問題，ESMM 使用了共享 Embedding，CVR 任務和 CTR 任務使用相同的特徵和特徵 Embedding。 2）為了解決樣本選擇偏差的問題，ESMM 並沒有直接使用 點選->轉化 樣本學習 CVR，而是通過 曝光->點選 和 曝光 -> 轉化 樣本來隱式地學習 CVR。在我們的場景，我們需要建模的目標是點選和有效觀看，這兩個目標涉及到的關係可以被描述為： img 可以看到，pCTR 和 pCTCVR 這兩個任務使用的是整個空間的樣本，它們有顯式的監督訊號，而 pCVR 節點只是網路結構中的變數，它沒有顯式的監督訊號。 3）ESMM 的目標函式如下 img 總結起來，就是 ESMM 通過 CTCVR 和 CTR 的監督資訊來訓練網路，隱式地學習 CVR。 在實際使用過程中，為了提取高階組合特徵，我們做了兩個如下改動： 1. 增加了一些手動構造的交叉特徵，以此提高模型的記憶能力 2. 在原有 ESMM 網路結構基礎上添加了 FM 模組 整體網路結構如下： img 在目標融合階段，我們對多個目標採用帶權乘積融合(取 log)：final_score = m * log(ctr + 0.00001) + n * log(cvr + 0.00001) 的方式進行融合打分，通過 m 和 n 的權重控制，來調整模型偏向於ctr 還是 cvr，以契合不同階段的業務需求。 採用經過改造的 ESMM 模型後，相對於基線(CTR、CVR 分開建模)，CTR 提升 7.1%，CTCVR 提升 6.4%。

4.2 MMoE

ESMM 模型實際是一種 shared-bottom 的結構，不同任務間共享底部的隱層，然後再根據任務的個數劃分出多個 tower network 來分別學習不同的目標。這種結構可以減少過擬合的風險，但是如果任務之間相關性較低，模型的效果相對會較差。 為了解決任務之間相關度降低導致模型效果下降的問題，google 在 MoE（Mixture-of-Experts）的基礎上進行了改進，提出了 MMoE：《Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts》，引入了多個 Gate 來控制不同任務不同 Expert 的權重。MMoE 的整體框架如圖所示： img 如圖所示，Gate 通常是一個線性模型 + softmax，而 Expert 通常是 DNN 等。 MMoE 與 ESMM 模型的不同點主要有： 1. 任務底層不是 shared-bottom 結構，而是通過多個 Expert 來學習不同的特徵 2. 引入與任務個數相同的門控網路（gating network），每個任務的 gating network 通過輸出不同的權重實現對 experts 的選擇性利用（加權求和）。不同任務的 gating network 可以學習到不同的 experts 的組合模式，即吸收 expert 資訊的側重點不同，因此模型捕捉到了不同任務的相關性和區別 將上面的網路結構轉換成公式，表示如下： img 經過實驗，MMoE 相比 ESMM+FM 模型，CTR 基本持平，CTCVR 提升 1.5% 。

4.3 Loss 融合

對於多工學習，存在一個問題：不同任務的資料分佈、重要性往往不一樣，那麼多個任務的 loss 如何融合？最簡單的方式，就是將各個任務的 loss 直接相加： loss = loss(task1) + loss(task2) 這種直接相加的方式存在以下幾個問題： - 不同任務 loss 梯度的量級不同，可能會導致訓練過程被某個任務主導或學偏 - 不同任務收斂速度不一致，可能導致有些任務還處於欠擬合，而有些任務已經過擬合 我們對上述融合方式進行簡單地調整，對每個任務的 loss 設定一個超引數，如下： loss = w_1 * loss(task1) + w_2 * loss(task2) 這種加權融合的方式允許我們人為調整每個任務的重要性程度，但是也存在一些問題： - 各任務在訓練過程中自己的梯度量級和收斂速度也是動態變化的，我們這裡設定的超引數會一直伴隨整個訓練週期 - 固定的權重設定可能會限制任務的學習，比如任務 A 接近收斂，而任務 B 還處於欠擬合 - 超引數依賴人為多次調參，才能找到一個相對比較好的引數

那麼多工學習中，如何更好地對不同任務 Loss 進行融合呢？

我們把多工模型的損失函式記為： img 那麼對於共享引數 W_sh 在梯度下降優化時： img 從上面的表示式可以看出： - loss 大則梯度更新量也大 - 不同任務的 loss 差異大導致模型更新速度不平衡的本質原因在於梯度大小 - 通過調整不同任務的 loss 權重可以改善這個問題 - 通過對不同任務的梯度進行處理也可以改善這個問題 因此，融合方法大體分為兩類： - 在權重 w_i 上做文章 - 在梯度上做文章 在我們的場景，我們嘗試了人工設定 loss 超參和梯度歸一化（GradNorm）兩種方法。GradNorm 的核心思路主要有兩點： - 希望不同任務對應的 Loss 量級接近 - 希望不同任務以相近的速度進行學習 GradNorm 本身不聚焦於不同任務之間的權重，而是將所有任務等同視之，它希望不同任務的更新速度能夠相對接近，從而避免了某個任務收斂了，某個任務還在收斂的路上的問題。 經過實驗，在我們的場景，基於 GradNorm 的 Loss 融合方式相比人工設定超參的方式，CTR 提升 0.6%，CTCVR 提升 0.4%。

5. 多模態探索

直播推薦實際上是一個多模態的推薦，首先呈現在使用者面前的是文案和主播頭像，除了向用戶推薦個性化的主播，對於入口樣式，我們也應該做到千人千面。直播產品形態呈現多樣式、多物料（文案、頭像）組合形態，對 CTR 預估提出了巨大的挑戰。 另外，由於主播每次更換頭像和文案，都會導致主播的資料分佈出現劇烈的變動（CTR可能會相差好幾倍）。針對這個問題，目前我們有兩個解決方案： 1. 通過實時的特徵和模型來捕捉這種資料分佈的快速變化（即前文的實時推薦） 2. 利用模型控制主播的頭像與文案來降低這種資料分佈的變化，如果主播的新頭像、文案不優於歷史的內容，模型可以主動的將內容替換為舊的內容，同時通過擴大主播的頭像、文案候選集，提升主播的點選率上限。 基於第 2 點，我們將僅對於Item（主播）進行排序的推薦方案，逐步改造為針對<主播、文案、頭像>三元組進行排序，在播放頁直播的實踐過程中取得了非常好的效果。

5.1 文案、頭像優選

在改造初期，我們分別針對頭像和文案進行了實驗來驗證方案的可行性，主要方案如下： - 通過增加通文案、主播歷史頭像來擴大主播的文案、頭像候選集 - 劃分一定的流量來對新文案、頭像進行Explore - 然後通過離線統計的方式，計算不同文案、頭像的CTR、CTCVR資料 - 最後根據統計資料對主播的文案、頭像進行輪詢 如下圖所示，紅色為優選流程。 img - 針對主播頭像，由於頭像與主播關聯性較強，很多使用者是通過頭像對主播建立的感知，所有我們沒有使用主播自身頭像以外的資料，只選取了主播的歷史頭像作為候選集。 - 針對主播文案，可選的擴充套件內容則更為豐富，除了一些通用的文案之外，主播有較為豐富的標籤，針對主播的性別、年齡，是否在唱歌、跳舞、ACG主播等等特徵，都可以新增相應的擴充套件文案，除了增加文案的豐富度外，可以細粒度的將文案和直播間內容進行匹配，出了直接提高CTR之外，對於CVR的提升也是有益的。 - 通過該流程的實踐，文案優選在播放頁、首頁均取得了非常好的效果.

5.2 文案模型+文案投放系統

在文案優選的實踐過程中我們也發現了很多問題： - 文案量少、無法持續產出高效文案，持續追蹤熱點，形成長久的高收益，擴充套件文案實際只有20多個

  • 自動化程度不夠（所有的文案均是通過硬編碼在系統中，非常不靈活），每次更新都要線上釋出

  • 文案需要通過優先順序來控制（通用文案和一些活動文案有衝突） 針對以上問題，我們將整個流程進行優化，如下圖所示。 img

  • 在文案的產出階段，我們引入了產品/策劃作為文案的生產者，產出優秀的文案加入推薦的文案池

  • 利用文案模型來實現文案的個性化推薦

  • 通過離線效果統計，以圖形化介面的方式給產品/策劃產出每天的資料反饋

  • 產品/策劃通過資料總結規律，來持續產出優秀的文案，形成整個優化的閉環 1）基於此，我們構建了文案系統2.0，讓產品、策劃可以通過Web頁面配置的形式，方便的上傳、修改文案，同時支援20多種不同的配置屬性來實現文案的定向投放，所有屬性如下所示。

  • 使用者：性別、年齡、城市等級

  • 主播：性別、年齡、特定主播、開播標籤、演算法標籤、直播型別、是否發紅包、直播間型別
  • 上下文：場景、小時、是否週末、是否節假日、是否活動、開始時間、結束時間。比如可以針對聊愈主播，在晚間22：00-02:00點之間投放某種文案，針對五一、十一等特殊節假日期間投放各種文案。

2）擁有豐富的文案池後，繼續通過簡單統計的方式來投放顯然不是最優的選擇。文案模型可以自動的的進行文案個性化投放，同時可以將所有型別的文案進行統一處理，按照文案的優化目標（而不是人為規定）進行投放。 3）文案的效果統計如下圖，通過不同的文案效果對比，產品/策劃可以瞭解使用者對於不同文案的喜愛程度，從而產出新的文案 img

通過文案模型+豐富文案池+資料反饋，我們拿到了非常好的效果。

5.3 主播文案融合模型

在當前推薦鏈路中，文案和主播的排序是分開。我們知道兩個區域性最優點的效率總是小於等於全域性最優點的，由此我們開展了下一階段的優化，將Item（主播）和文案進行融合排序，流程圖如下。 img 1. 在主播召回的結果後，針對每個主播進行文案召回 2. 針對〈主播、文案〉的pair對進行融合排序 3. 最後獲取Top1主播的優選頭像進行推薦

在實驗過程中，我們將主播和對應的文案候選池進行笛卡爾積操作後再利用精排模型進行排序，由於排序數量的上升，精排叢集的資源利用率急劇上升，現有的機器無法進行全量部署。我們分析後發現以下問題： - 排序的粒度為<主播、文案>，導致資料傳輸、解析和回包的數量量也急劇上升 - 每個主播有多個文案，會導致主播特徵多次查詢和特徵抽取（原始特徵轉換為模型輸入內容，如bucket等） - 精排部分的rt滿足需求，但cpu負載過高 - 針對以上問題，我們進行了一些優化： - 通過每次predict增加batch_size來降低cpu消耗（增大了RT） - 與精排系統之間的互動改為Item緯度，每個Item附帶一個文案ID列表的特徵，同時回包結果也改為Item緯度，每個Item附帶排序結果Top1的文案ID，降低網路傳輸（降低RT） - 模型預測過程中，先對使用者、主播、文案維度進行特徵查詢、抽取等操作，在模型predict前將文案相關特徵拼接入sample中，降低多次相同的特徵查詢和抽取消耗（降低RT） 如下圖所示，該叢集包含播放頁20%的流量，在優化其中部分流量（10%）後，在RT增長3-5ms的情況下，cpu佔用率下降了60%，使得模型可以順利全量。 img 最終，在播放頁獲得點選率（ctr）：+10.21%，有效播放率（ctcvr）：+8.48%的效果。

5.4 主播、文案、頭像融合模型

以上我們經歷了從文案、頭像優選->文案模型+文案投放系統->主播、文案融合模型。 不難發現，我們下一步的優化目標是將主播、文案融合模型改造為主播、文案、頭像融合模型。 我們在主播歷史頭像的基礎上，讓主播上傳了動態頭像，目前還在持續優化中，我相信我們可以取得非常不錯的效果。

6. 總結展望

本文以歌曲播放頁直播入口為例，介紹了我們在雲音樂直播的個性化推薦實踐。 針對業務中遇到的問題和挑戰，我們調研和設計了相應的方案去解決這些問題： - 對於直播內容會實時變化的問題，我們採用了實時推薦的方案 - 對於業務多目標的訴求，我們採用了多目標融合模型 - 對於直播推薦存在的多種模態，我們進行了多模態的探索實踐 要注意的是，沒有「最好的模型」，只有「最適合的模型」，並不是說模型越 fancy 越複雜，線上效果就會越好。比如阿里提出了 DIN 模型，是因為工程師們首先發現了資料中的「多峰分佈」、「部分啟用」的現象，而在直播場景中這個特點就不是很明顯，但直播場景也有其自身的特點，如多模態、實時性和熱點效應等。

只有深入理解業務場景，並基於使用者行為和資料提取出能表現這個場景的特徵，再對應地開發適用於這個場景的模型，才能取得最佳的效果。

參考文獻

「」