實時增量學習在雲音樂直播推薦系統中的實踐

雲音樂技術團隊發表於2022-03-15
作者:波克

1. 直播業務背景

1.1業務背景

直播推薦業務是嵌入在雲音樂 APP 中各個地方,其中就包括最大的幾個場景歌曲播放頁的直播模組、混合在評論中的評論頁直播以及雲音樂首頁的首頁六卡直播。 如下圖所示,圖 1.1 即為播放頁上的直播模組;圖 1.2 是雲音樂首頁中首頁六卡直播模組;圖 1.3 是歌曲評論頁中的直播模組。

不同推薦位的直播承載著不同的內容使命,在首頁我們更傾向讓新使用者瞭解直播,讓老使用者快速地進入直播間觀看直播;在歌曲播放頁的直播更傾向於推薦給使用者與聽歌行為相關、與歌曲相關的直播內容;在歌曲評論頁,直播更像是另外一種形態的內容,是社交內容的補充。

同時,直播業務是雲音樂的衍生品,其推薦不同於音樂推薦,主要表現為使用者意圖不明確、直播使用者行為稀疏、實時性要求高以及存在 debias。

本文主要聚焦於直播推薦系統實時化,以場景的演算法特色為切入點介紹直播場景的優化目標,從多個角度說明為什麼直播需要實時化。同時,本文概述了推薦系統實時性的基本組成和基本解決方案。推薦系統實時性主要由特徵實時性、模型實時性和系統實時性組成。具體地,本文也以雲音樂直播場景的實時化演進來詳細介紹我們是如何去搭建整個直播實時化系統,並解決實時化過程中帶來的困難與挑戰。最後,本文也給出了在大規模場景下的線上效果和分析。

1.2 場景演算法特色

大多數平臺的直播場景,同時開播場次有限,對召回訴求不強,本質是一個對實時直播的精排或者粗排+精排的過程。

1.2.1 多目標

在推薦場景中,使用者的行為一般都不止一種,而且不同行為的發生有先後順序和依賴關係。直播推薦場景就是這樣一個相關型多目標場景,在哪裡建模也都是一個多目標的過程,比如既要點選率又要在觀看時間長,又要轉化率高,還有些粉絲親密度的問題。
圖 3 是直播的推薦的整個多目標學習過程。

使用者在首頁瀏覽直播模組時,先會發生點選,然後進入直播間產生觀看,當達到 30s 以上的時候,會產生一個目標任務:有效觀看。可能這時使用者會喜歡該主播,和主播發生互動,並關注這個主播,更甚者送禮物給主播。使用者的每一種行為都可以成為多目標模型裡的一個目標,像這種目標之間存在依賴關係的多目標模型就屬於相關型的多目標模型。這樣流程也可以轉化為一張多目標關係圖,那麼每一個任務和目標就是我們模型需要去學習的。

1.2.2 實時化

相比於傳統的個性化推薦每天更新使用者的推薦結果, 實時推薦基於使用者最近幾秒的行為實時調整使用者的推薦結果 。實時推薦系統讓使用者當下的興趣立刻反饋到了推薦結果的變化上,可以給使用者所見即所得的視覺體驗,它牢牢地抓住了使用者的興趣,讓使用者沉浸在其中。直播推薦系統更是對實時化需求非常高,大致可以從幾個角度來介紹,Item 推薦角度、資料指標、業務環境。

Item推薦角度

直播推薦是對實時線上主播的排序,是存量主播的一小部分。從下面這張平臺主播開播分佈情況圖(圖 4)可以看出,我們平臺存量主播有百萬量級,而當天開播主播只有萬量級, 同時每個主播開播的時段不一,有凌晨、早上、下午、晚上,且每個時段開播主播咖位也不同,一般來說晚上開播主播更多,咖位更大。

直播推薦的 item 就是主播,是活的貨物,這不同與歌曲推薦中的歌曲,資訊流推薦中的圖文或者視訊,主播是一個不斷變化的 item,如下面這張圖可以看出使用者每次進入直播間看到的直播內容和主播狀態都不一樣,主播可能在 pk、表演、聊天;而歌曲或者視訊是一個完全靜態的 item,且每次推薦展示都是從頭開始播放; 所以直播推薦的不僅僅是一個 item ,更是 status。

資料指標

具體的主播實時效率也能體現這一問題,某一主播在同一天內不同時刻效率變化劇烈,存在多個高峰和低谷,這可能與主播當時表現的狀態有關、也可能與直播內容相關。但是對於推薦系統來說,系統是利用歷史的資料去擬合預估未來的趨勢,如果系統不夠實時,無法獲取主播實時表現情況,那麼系統極有可能會對主播未來的趨勢擬合出現偏差,甚至可能是完全相反的結果。

業務環境

雲音樂直播業務與其他業務息息相關,牽一髮而動全身。這是因為直播業務不是固定位置的推薦,例如首頁直播收到音樂業務風格推薦的影響,會導致直播模組出現在第3、6、7位。歌曲播放頁的直播模組,會收到歌曲的影響,因為一個直播間在不同歌曲的效率是不一樣的。所以一旦其他業務有所改動,都極有可能對直播業務的資料分佈產生巨大的變化。

所以不管是從推薦的 item 、主播資料指標還是大環境,直播推薦都急需要一個實時化的推薦系統。

2. 推薦系統的實時性

推薦系統實時化性由特徵實時性、模型實時性和系統實時化組成,需要利用特徵實時化去實時獲取資料分佈;模型實時化去實時擬合資料分佈;最後基於實時系統去獲取最新模型和資料。

拋開系統實時來說,演算法同學當然更關心的是特徵實時性和模型實時性。具體來說;

  1. 推薦系統的更新速度越快,越能夠反應使用者最近的使用者習慣,越能夠給使用者進行越有時效性的推薦。
  2. 推薦系統更新的越快,模型更容易發現最新流行的資料 pattern,越能夠讓模型反應找到最新的流行趨勢。

2.1 特徵實時性

推薦系統依賴強大的資料處理能力

  • 系統“實時”地收集模型所需的輸入特徵,使推薦系統能夠使用最新的特徵進行預測和推薦
  • 使用者 T-1 時刻發生的行為(播放某首歌、觀看某個主播、打賞/付費),需要在T時刻實時反饋到訓練資料中,提供模型學習

這是一個比較常見的特徵實時化的實現框架圖,主要包括日誌系統、離線畫像、實時畫像,通過 storm、flink、kafka 完成實時資料的處理和傳輸, 並儲存在 hbase 和 redis 中,最後落盤到 hdfs 中。實時樣本的處理中間環節是通過快照系統來解決樣本的穿越問題和一致性問題。

但特徵實時性再強,影響的範圍也僅限於當前使用者,要想快速抓住系統級別的全域性的資料變化和新產生的資料 pattern,就必須加強“模型”的實時性。

2.2 模型實時性

與“特徵”的實時性相比,推薦系統模型的實時性往往是從更全域性的角度考慮問題。特徵的實時性力圖用更準確的特徵描述一個人,從而讓推薦系統給出更符合這個人的推薦結果。而模型的實時性則是希望更快的抓住全域性層面的新的資料模式,發現新的趨勢和相關性。

要加強模型實時性最重要的做法是改變模型的訓練方式,按照實時性強度排序,是全部樣本更新、增量更新、線上學習。
不同的更新方式當然也會帶來不同的效果,例如全量更新,模型會利用某時間段內的所有訓練樣本進行重新訓練,再用訓練好的新模型替代老版本的模型,這樣的訓練方式需要的訓練樣本量、訓練時間長、資料延遲長,但是樣本的準確性最高。
對於線上學習,更新速度是最快的,是增量更新的進階版,在每次獲得一個新樣本的時候就實時更新模型,但是這樣的方式會導致一個很嚴重的問題,就是模型的稀疏性很差,開啟過多“碎片化”的不重要特徵。
增量更新相對來說是一種 tradeoff 的方式,既可以減少樣本訓練時間長、資料延遲嚴重帶來的問題,又可以減少每個樣本更新帶來的模型訓練不穩定的問題,所以我們的做法也主要採用這種方式。

3. 直播精排模型的實時化演進

雲音樂直播業務的實時化一直都是分成兩條腿在走,一個特徵實時,一個是模型實時。我們最初主要是通過不斷增加各個維度的實時特徵來提升系統的實時化能力,來實時反應主播、使用者、上下文在當前的變化,使得模型能夠跟上當前的實時變化來預估未來的趨勢。另外在提升特徵實時化的同時,我們也一直在對模型結構做升級迭代,業務最初採用的是特徵工作+簡單的單模型邏輯迴歸,這個方式的核心就在於實時資料、實時交叉特徵打點⽇志的建設。迭代到現階段,我們採用的是 ESMM+DFM+DMR 模型,通過 ESMM 聯合訓練模型來解決 SSB 問題和轉化樣本的 Data Sparsity,DMR 結構來捕捉使用者長期和短期的興趣。但是,現階段還存在一些問題,特徵夠快了,模型夠複雜了,可模型更新不夠快,無法更快的抓住全域性層面的新的資料 pattern 和趨勢。

4. 實時增量模型搭建

雲音樂直播演算法團隊通過探索與實踐,總結出了一個相對成熟且行之有效的實時增量模型的訓練框架。

  • 框架左側部分是實時增量學習,右側是離線學習: 離線訓練仍然保留,它基於歷史7天的資料訓練,主要用於增量模型的熱啟動重啟。增量學習通過消費 Kafka 的實時資料流,通過 ETL 處理後,用於實時訓練模型。
  • 實時樣本累計歸因: 實時樣本處理完後儲存在 HDFS 中,實時資料流處理時,對於樣本需要做一個當天歷史樣本的累計歸因,保證樣本 label 的準確性,這裡的累計歸因取決於使用場景,例如首頁場景重複曝光率高需要做;對於重複曝光率低的場景,則無需再做。
  • 模型實時訓練: 實時增量訓練任務的訓練資料集都是當天的累計歸因過的樣本,累計樣本隨 kafka 流不斷增加。模型訓練每次都是基於最新的離線模型熱啟動重啟。 這裡的歸因樣本也取決於落地場景,部分場景無需累計歸因。
  • 模型同步: 模型按照 15 分鐘例行化匯出模型檔案同步給引擎,這裡的同步效率可以自行調節。

4.1離線模型

增量模型是在離線模型的基礎上做進一步迭代,在不改變原有模型的網路結構,增量更新模型引數,來快速抓住系統級別的全域性的資料變化和新產生的資料 pattern。

我們現有的離線主模型是一個深度興趣 ESMM-DFM 模型;該模型是借用 Wide&Deep 的思想,在 ESMM 框架下,增加特徵交叉模組、使用者興趣模組,最後通過 RestNet-DNN 來加快模型收斂。

  • ESMM 聯合訓練模型,解決 SSB 問題和轉化樣本的 Data Sparsity
  • 引入 DFM 替換 DNN,增加多特徵域互動性
  • 顯性建模 U2I 和 I2I 網路,增強使用者和主播的興趣連線
  • Output 層:ResNet-DNN 替換 Sigmoid 加快模型收斂

4.2 樣本歸因

大多數和轉化相關的正樣本 delay 現象都很明顯,這樣會導致實時資料分佈不是真實的分佈,因為在實時樣本被落下來的時候,正樣本還沒到來。正樣本 delay 是因為使用者行為上報存在天然序列,導致 label 滯後,使用者曝光日誌會最先產生,然後才會是點選再是觀看日誌,整個行為不可逆轉。所以這會產生一個問題,同一個使用者在同一頁面,曝光和點選資料先後到達時,如何確定歸因樣本 label。

業內常見的樣本歸因方式,一般有兩種,一個是 facebook 提出的負樣本 cache 歸因法,第二個就是 twitter 提出的樣本矯正法。

負樣本 cache 歸因法就是如圖所示,負樣本會先 cache, 等待潛在的正樣本到達,若後續正樣本到達,則只保留正樣本,更新模型一次。cache 的時間視窗一般是有轉化時長來確定,保證 95% 以上的轉化能完成即可。雖然這樣的做法會存在一些樣本延遲,但是樣本 label 準確性是比較高的。

Twitter 的做法:兩條樣本都會保留,都會去更新模型,這樣實時性最高,但是非常依賴樣本矯正策略。

在現有的工程框架下,我們更傾向於構造類似於 facebook 的負樣本 cache 策略,但是直接遷移使用會存在問題,我們嘗試在首頁直播模組落地,但是整體樣本 label join 率只有70%。

這就涉及到雲音樂首頁場景都會存在的一個問題,息屏現象。 因為使用者進入首頁到退出,再到重新回到雲音樂首頁,是不會重新拉流的,這就導致了使用者的點選和觀看可能遠遠大於曝光,cache 是無法等待這麼長時間的。如果直接落下實時樣本,就會導致樣本內出現同一條特徵對應著多個正負樣本 label,給模型訓練帶來太多的噪聲。

所以我們設計了樣本累計歸因的方式,cache 落樣本的方式不變,增加一個離線處理過程,對實時樣本和當天歷史樣本在做一次歸因,保證截止當前時刻內的樣本準確;這樣犧牲少量時間,換取高樣本準確性,最後使得樣本準確性從 70% 提高到 97%。

4.3 模型熱啟動重啟

如我們上文給出的實時增量學習的技術架構圖,右側的離線訓練過程是不會丟棄的,因為增量學習需要依賴離線模型做模型熱啟動重啟。離線模型熱啟動重啟的主要原因有兩點:

(1)防止模型會因為一些區域性的 pattern 而被帶偏,基於離線模型熱啟動可以對其進行矯正。

(2)如果模型訓練是 long running 的,會導致模型詞表OOV 的概率會越來越大,無法將新的ID快速加入到模型的詞典並且快速淘汰老的 ID。通過離線模型熱啟動重啟,可以同步更新模型詞表,防止 OOV。

(3)場景使然,如 4.2 所述,首頁直播場景存在嚴重的息屏現象,導致實時樣本需要做進一步的累計歸因,這樣獲得的樣本均為當前時刻的累計樣本,所以模型更新均需要在離線日更模型上做梯度下降。

因此,我們設計了天級別的離線模型熱啟動重啟和 15min 樣本級別的重啟,以解決上述三個問題。這樣既可以解決模型 long runing 帶來的 oov 問題和區域性 pattern 有偏的問題,更重要是保證進入模型訓練的樣本 label 都是準確的。

4.4 特徵准入方案

樣本和特徵作為機器學習的基石,其質量的好壞直接決定了模型效果的上限,所以做好樣本和特徵的質量保障,對實時增量學習的效果提升至關重要。上文 4.2 樣本歸因一節中,我們著力於保證進入模型訓練的樣本準確性。 本節主要以具體 case 為切入點,分別從樣本偏差特徵和低頻特徵兩個角度,介紹我們的解決方案。

Case1: 時間偏差特徵,例如 week 和 hour 這型別的特徵,增量樣本中集中於某一兩個特徵值,和離線訓練樣本分佈完全不一致。
Case2: 低頻不置信特徵,例如某主播 id 樣本只出現 2 次曝光,1 次點選,1 次轉化。 該 id 做維特徵喂入模型,從統計意義上說,該 id 點選率50%,轉化率100%。

所以我們設計了一套特徵准入方案來緩解這種現象,主要包括 feature freezing、特徵硬准入、動態 L1 正則的軟准入方式。具體方案,如圖所示。

4.4.1 Feature Freezing

機器學習演算法有一個獨立同分布的基本假設,即模型訓練的資料分佈要與預測時的資料分佈獨立同分布。一些時間特徵比如 week 和 hour,在離線批樣本中由於被充分 shuffle 過,使用這些特徵訓練出來的模型依然能保障訓練和預測獨立同分布,但是在實時流式訓練中,樣本實時順序到達的,這類特徵無法被充分 shuffle,使得模型訓練一直在訓練同一個時刻的特徵值,而預測時可能切換到下一個時刻的特徵值,導致模型泛化能力差。所以,這類時間偏差特徵不參與模型的引數更新,作為凍結節點,防止這部分特徵陷入區域性最優

4.4.2 “硬准入”

由於增量的樣本遠遠少於離線訓練樣本,所以全量特徵的頻次過濾條件不一定適用於增量特徵的頻次過濾條件。比如,全量時,某些特徵的頻次過濾數量設定為 1000,但在增量時,應該設定得小一些。全量時,使用天級別積累的樣本進行訓練,但在增量時,則使用 15 分鐘或者 1 小時內的樣本進行訓練,若仍然使用與之前全量相同的頻次過濾條件,會過濾掉近 1 小時內頻次不足 1000 的特徵,即使在後一小時內,這些特徵的頻次增加到 1000,也無法再追回已訓練樣本中的這些缺失特徵值。

對於這類低頻特徵,我們採用了兩種方式來解決,第一種方式就是硬准入策略,我們設定了兩種特徵頻次過濾條件,全量更新時採用閾值較大的全量閾值;實時增量時,採用閾值相對較小的增量閾值。並且在構建增量樣本時,之前在全量樣本構建過程中被全量閾值過濾的特徵,其頻次會被保留,等到下一次增量到來時,若全量中被過濾的這些特徵再次出現,則會將全量+當前增量的頻次作為當前特徵的頻次。這樣的話,某個特徵的頻次達到准入門檻後,才會進入模型訓練。這樣方式帶來線上點選率相對提升 0.94%,有效觀看率相對提升 0.23%

優點: 可以解決本次樣本中的特徵由於頻次過低導致學出來的權重不夠置信的問題。

缺點: 仍然會過濾掉某些低頻特徵,損失一部分有效資訊。特徵在達到准入閾值之前,出現的前 n 次都被忽略了。

4.4.2 “軟准入”

如上述“硬准入”的方案的缺點所述,硬准入會過濾掉某些低頻特徵,損失一部分有效資訊。特徵在達到准入閾值之前,出現的前 n 次都被忽略了,只有達到一定閾值後再進入訓練的設計方案會破壞樣本完整性,如全量頻次 99,增量頻次 1,閾值過濾 100,則該特徵出現的前 99 次都被忽略,僅會訓練該特徵出現的一次,導致模型訓練的穩定性差。所以我們需要更加平滑的方式。

對於“軟准入”方案,業界有兩種比較常見的做法,基於泊松分佈的特徵頻次估計和動態 L1 正則方案。

基於泊松分佈的特徵頻次估計

在離線 shuffle 後的特徵滿足均勻分佈,但對線上資料流,特徵進入訓練系統可看做泊松過程,符合泊松分佈:

$$ P(N(t)=n)=\frac{\lambda t^n e^{-\lambda t}}{n!}$$

其中 n 為當前出現的次數,t 為當前的步數,λ 為單位時間發生率,是泊松分佈的主要引數,T 為訓練總步數。\( \vec{N} \)為特徵最低門限(即最少在 T 時間內出現的次數)。

因此我們能通過前 t 步的特徵出現的次數 n,將 t 時刻當做單位時間,則 \( \lambda = \frac{n}{t} \)。 根據泊松分佈,我們可以算出剩餘 \( \frac{T-t}{t} \) 時間內事件發生大於等於 \( \vec{N}-n \) 次的概率

$$P_{\lambda_{i}}(N(\frac{T-t}{t})> \vec{N}-n)$$

每次該特徵出現時,都可按該概率 \( P_{\lambda_{i}} \) 做伯努利取樣,特徵在 t 步進入系統的概率用下式計算:

$$ P = \prod_{i=1}^{t-1} {(1-P_{\lambda i })P_{\lambda t}}$$

通過真實線上資料模擬,它能接近離線頻次過濾的效果,其 λ 是隨每次特徵進入時動態計算的。它的缺陷是:當 t 越小時,事件發生在 t 內的次數的 variance 越大,所以會以一定概率誤加或丟棄特徵。未來總的訓練步數 T 在線上學習中是未知的。頻次過濾與優化器相分離,導致不能獲得優化器的統計資訊。

動態L1正則方案

正則化是結構風險最小化策略的實現,是在經驗風險上加一個正則化項或罰項,正則化項一般是模型複雜度的單調遞增函式,模型越複雜,正則化值就越大。L1 範數是指向量中各個元素絕對值之和,也叫“稀疏規則運算元”(Lasso regularization)。範數作為正則項,會讓模型引數 θ 稀疏化, 既讓模型引數向量裡為 0 的元素儘量多。在經典的 FTRL 實現中,L1 正則對每個特徵都是一致的。 但是過大的 L1 雖然可以過濾掉極低頻的特徵,但由於約束太強,導致部分有效特徵也被 lasso,影響模型效能。

參考螞蟻的實時流技術文章提到的動態調 L1 正則方案,通過特徵頻次影響 L1 正則係數,使得不同頻次的特徵有不同的 lasso 效果。

特徵頻次和基於 MLE 的引數估計的置信度相關,出現次數越低置信度越低。如果在純頻率統計基礎上加入一個先驗分佈(正則項),當頻率統計置信度越低的時候,越傾向於先驗分佈,相應的正則係數要更大。以下是經驗公式:

$$ L_{1}(w_{i}) =L_{1}(w_{i}) * (1+ \frac{ (?∗max⁡(?−????(?????),0)) }{N} )$$
其中 C 是懲罰倍數,N 為特徵最低門限,這兩者皆為超參,freq(feaid) 是當前特徵出現的頻次(包含當前增量中出現的頻次以及歷史總頻次)。

我們也線上上環境,嘗試使用了動態調節 L1 正則的方案,最後實現在原有硬准入方案的基礎上,線上 ABTest 效果點選率相對提升1.2%; 有效觀看率相對提升 1.1%

5. 線上效果

當然除了模組帶來的效果提升,我們整個實時增量模型方案上線,也取得比較喜人的結果。結合上述樣本歸因的處理、離線模型熱啟動重啟以及特徵准入方案,我們最終在首頁直播模組推薦場景取得轉化率:平均 24 天相對提升 +5.219% ;點選率:平均 24 天相對提升 +6.575% 的效果。

並且我們針對不同的模型更新頻率進行了多種方案的測試,如下圖,ABTest t1 組為離線日更模型,每天更新替換模型檔案; t2 組為 2 小時更新模型,模型每兩個小時增量訓練; t8 組為 15 分鐘更新模型,模型每 15 分鐘增量訓練模型。 經過我們多次測試,發現模型更新越快效果更佳也更佳穩定。

線上排序結果實驗前後對比展示如下圖,部分在 base 模型中無法排到 top 3 的主播能夠在實時增量模型中被發現且排到前面來。也印證我們上文 2.2 節所說,模型的實時效能夠更快的抓住全域性層面的新的資料模式,發現新的趨勢和相關性。

6. 總結與展望

直播推薦業務有著其不同於其他業務的場景特色,推薦的不僅是一個 Item 更是 Status,進而直播推薦需要更快、更高、更強的推薦演算法來支援業務的發展。本文是第一篇落地雲音樂直播業務的實時增量學習的文章,分享我們在直播業務中如何落地實時增量學習,解決模型實時化過程中帶來的問題的一些經驗。接下來,我們會繼續朝著更快、更高、更強的推薦演算法前進,在使用者成長、使用者付費、主播成長等多個方面持續探索,致力於提供更優的使用者體驗,更優的線上效果,更好地服務業務。

參考文獻

本文釋出自網易雲音樂技術團隊,文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位,如果你準備換工作,又恰好喜歡雲音樂,那就加入我們staff.musicrecruit@service.ne...

相關文章