天天看點

多場景多任務統一模組化在網易雲音樂的算法實踐

一、背景介紹

多場景模組化是一項與業務緊密結合的算法優化工作,其核心在于思考如何處理多個業務場景之間的差異性和共性。

1. 雲音樂推薦場景介紹

雲音樂的核心場景包括每日推薦,每天更新 30 首歌曲,以清單形式呈現;還有流式推薦、實時更新,和每日推薦一樣都是直接為使用者推薦歌曲;此外還有歌單推薦,包括首頁推薦歌單以及 MGC 歌單。

多場景多任務統一模組化在網易雲音樂的算法實踐

2. 主推薦場景差異化

這些場景特點各異,旨在滿足使用者不同的個性化推薦需求。可以看到,在過去一段時間,這些場景一直由專人專項持續優化。這樣做的優點是能使模型更貼合業務場景和特點,充分發揮模型效果,提升場景忠實使用者的體驗。

這種做法也存在弊端。其一,長期專人專項優化可能導緻技術棧出現較大差異;其二,技術共享和共建節奏會被拖慢。

多場景多任務統一模組化在網易雲音樂的算法實踐

3. 新增場景愈多

我們面臨的挑戰不僅是要承接越來越多新的場景,滿足更多使用者個性化音樂訴求并帶來增量,同時還要思考如何更好地承接和持續優化這些新場景。

多場景多任務統一模組化在網易雲音樂的算法實踐

4. 模組化目标

開展多場景工作的目标主要有兩個:一是用一個模型服務所有推薦場景,取得更好的效果,聯合模組化使用者在任意場景消費後産生的資料,精準模組化使用者真正感興趣的底層興趣表征;二是用一個模型服務所有場景,有效降低機器成本和人力成本,提升研發效率,促進技術共建達到更高水準。

多場景多任務統一模組化在網易雲音樂的算法實踐

5. 模組化難點

第一個難點是雙跷跷闆問題,由多任務跷跷闆和多場景跷跷闆構成,兩者耦合時平衡難度加大。另一個難點,可用西方故事“格力娅如何戰勝大衛”來描述,即如何用一個通用的大模型打敗每個場景專有的小模型,其中難點衆多,将在後續介紹中詳細闡述。

多場景多任務統一模組化在網易雲音樂的算法實踐

二、整體架構

1. 系統架構

此次雖主要談及算法層面的多場景模組化,但更重要的是,在算法層面之外,我們對從資料層到場景層再到頂層任務的整個系統架構進行了統一建構,摒棄了原先零散、不統一、不規範的技術及相應資料等,在此基礎上建構了統一的模型架構。

多場景多任務統一模組化在網易雲音樂的算法實踐

2. 模型架構

此架構與業界現有的多場景模組化整體架構差異不大,但其中融入了音樂場景特有的業務特點以及我們的思考。例如,針對音樂推薦中老歌持續被消費這一強業務特點,我們做了很多長期多興趣的表征,并與即時性交叉且進行動态更新。同時,我們希望将業務背後沉澱的音樂、較高價的電梯大廈知識傳遞到更頂層,服務于水面之上的多個業務場景。

多場景多任務統一模組化在網易雲音樂的算法實踐

3. 整體概述

整體架構可以概述為三個關鍵詞:自底向上、求同存異和去僞存真。求同存異是此次分享中最想強調的點,因為多場景工作更多是如何以最小代價固化沉澱真正有價值的共性部分,同時以快速靈活的方式保留差異部分,兩者有機結合才能完成多場景統一大模型的建設。

多場景多任務統一模組化在網易雲音樂的算法實踐

三、關鍵子產品

1. 統一模型模組化

在參考了業界衆多已有的多場景模組化工作後,我們完成了整體架構的設計。對重要區域進行了分色塊标記,友善了解。例如,底層有藍色和黃色色塊,總體遵循公私域分離設計結構。在公域部分,抽取多個場景共享的特征和表達,黃色部分則更多是場景特有的東西。可以看到圖中有多個紫塔并聯,每個紫塔代表一個場景特有的知識。在其之上是常見的 MMOE 架構,用于多個場景不同目标的多任務學習輔助。

多場景多任務統一模組化在網易雲音樂的算法實踐

2. 公域網絡設計

公域更多表達的是業務場景共有的特性、使用者公共的興趣或其長短期興趣中不變的部分。那麼求同如何實作?這更多考驗算法工程師面對零散業務特性和不同邏輯時,如何提取公約數。這裡分享四個要點:一是通用的輸入結構;二是特征的最大公約數;三是共享共建;四是輕量高效。共享共建和輕量高效可能基于團隊文化,強制要求做到更好以服務大模型。在算法層面,更強調保留公共核心特征。這裡也列舉了一些核心點,比如通過消融實驗找出并保留必要核心特征,能砍則砍,盡量減輕建構大模型前的負擔。

多場景多任務統一模組化在網易雲音樂的算法實踐

3. 多場景效果分析

基于此思考,我們進行了多次疊代,并及時基于 AB 測試分析以驗證公域架構設計的有效性。将使用者按活躍等級分為 0 - 10 級共 11 個檔次,0 級使用者最不活躍,10 級最活躍。從圖中可以看出,橫軸是各人群對應的提升幅度,0 - 3 級提升幅度明顯最大。此資料旨在論證,通過良好的公域結構設計,能有效表達并沉澱使用者特征,使低活使用者受益更多。

多場景多任務統一模組化在網易雲音樂的算法實踐

4. 私域網絡設計

公域工作相對基礎,而私域則較為複雜。私域的核心點在于保留每個場景最特殊、最有價值的部分特征,強調參數隔離、梯度隔離,每個塔互相不幹擾,輸入特征完全不同。這些特征來源于每個場景特有的特性挖掘,例如某業務場景的封面特征或流式場景基于使用者實時回報産生的信号等。

多場景多任務統一模組化在網易雲音樂的算法實踐

5. 場景私有網絡 SEN

為應對私有場景差異大的問題,設計了 SEN 場景私有網絡這一通用邏輯,便于接入新場景和合并老場景時提高複用率和整體疊代效率。求同存異中的求同主要是針對公域網絡設計,而存異則是針對私域網絡設計,主要展現在:一是私有場景的私有特征是不對齊的;二是某些私有特征很重要但易過拟合;三是存在分布漂移問題。我們參考了 Transformer 類的一些設計,進行組合,來解決這些問題。

多場景多任務統一模組化在網易雲音樂的算法實踐

6. 跨域多任務模型

接着是雙跷跷闆問題中的多任務跷跷闆,下圖中列舉了幾個核心場景及其面臨的任務。

多場景多任務統一模組化在網易雲音樂的算法實踐

基于場景特有任務,我們設計了 task master 邏輯。對于有任務的場景保留梯度,對于無任務的場景通過 subgradient 方式停止梯度,避免影響對應 SEN 網絡的學習。這保證了多場景、多梯度之間,場景與場景、任務與任務以及場景對應特有任務之間盡可能隔離。

多場景多任務統一模組化在網易雲音樂的算法實踐

7. 模型輕量化設計

在音樂推薦場景中,使用者行為序列特别是長期行為序列非常重要,引入 LSTM 加 session 切分提取使用者長期興趣特征曾帶來顯著提升,但此特征和對應的網絡結構對模型消耗大。在疊代多場景、多任務統一大模型時,我們找到了一個相對更輕量化的方式,即層次 attention 網絡。

多場景多任務統一模組化在網易雲音樂的算法實踐

從資料對比來看,雖然層次 attention 在某個核心名額上有輕微負向,但從全局來看是一種權衡,犧牲局部小收益換取未來全局更大的收益,提升了整體的疊代效率。

多場景多任務統一模組化在網易雲音樂的算法實踐

四、應用效果

模型上線後效果顯著,核心推薦場景紅心率提升 10% 以上,衆多小場景核心名額提升 15% 以上,直接帶動次留相對提升 1%。模型還落地到網易集團其他業務,新客絕對值提升 0.2%,次留絕對值提升 0.2%。同時,模型上線後替換了原有的零散和不統一的技術棧,整體效率也有所提升,并節省了資源消耗。

多場景多任務統一模組化在網易雲音樂的算法實踐

五、展望

在現有整體模型統一的基礎上,我們希望将模型進一步複雜化,服務于網易雲音樂更多業務線,不僅限于音樂推薦,還包括播客、直播等,以各種合作的形式發揮模型最大效果。

多場景多任務統一模組化在網易雲音樂的算法實踐

六、問答環節

Q1:新模型可以加入新的域和任務嗎?

A1:可以,場景的私域網絡 SEN 中,一個網絡對應一個場景,新增場景隻需在私有網絡增加對應的塔,較為靈活。

Q2:裡面疊代 5 次是指一周推選 5 次嗎?

A2:并非如此,是指離線完整訓練模型嘗試新方向,離線訓練效率提升使得疊代速度加快。

Q3:統一模型較大,多人在模型上疊代是否會有沖突或效率降低?

A3:目前的做法是預先區分好疊代方向,不同同學負責重疊度最低的方向,且因同學負責業務不同,重疊性進一步降低。雖幹擾減少,但也存在問題,如因他人工作提升加入新點,個人收益可能不如單獨 AB 時多。此時強調增量 AB,大量 DIFF 比較。這是目前實踐,仍在思考提升合作效率的方法。

Q4:拆分私域特征的必要性如何看待?

A4:私域特征複用度低,多為場景特有且重要,建議不混用到公域側,實踐中混用效果不理想。

Q5:多場景樣本是否複用?

A5:是的,所有場景樣本合在一起訓練,若不優化離線訓練效率,訓練耗時會大幅增加。

Q6:層次 attention 是将長短序融合再和短序融合嗎?

A6:是的,先對長序做 attention,再和短序做 attention。

Q7:公域特征為何對不活躍使用者提升大?

A7:音樂場景衆多,但使用者通常隻用一兩個功能,多場景模組化能覆寫全推薦域樣本,改變使用者底層表達,對類似使用者冷啟更好,不再隻适配單點場景特性。

Q8:新場景私域增量,私域訓練後公域那塊的場景綜合所有的,如果新場景上來是直接全量訓練還是增量訓練?

A8:新場景上來直接全量訓練,因補充新樣本存在差異性,直接增量訓練可能不穩定。

Q9:全量樣本更新是全冷啟還是熱啟?

A9:做全量更新。

Q10:上了一個私域塔,公域塔上層模型都得微調,如何影響對其他任務的評估?

A10:上了新私域塔通常直接做 AB,目前推薦域用一個實驗評估,新增私域塔未觀測到對其他場景的負向影響,因新增多為小場景,核心場景通常非新增量帶來。

Q11:對于私域特征混用不好的效果如何看待?

A11:因差異性大,如同豬飼料給牛吃會生病。

Q12:不同場景正負樣本的定義是否有差異?

A12:有差異,樣本分布差異大,做實驗時觀測到部分場景樣本量大會對其他場景産生負向影響,通過離線多次采樣疊代找出較好混合比例以表征全場景使用者。

Q13:不同場景量級差異大嗎?

A13:較大,做采樣會有資訊丢失,但會保留能共同模組化且對整體有收益的部分。

Q14:Loss 上有什麼考慮?

A14:多任務層因 task master 設計影響較小,多場景層通過獨立每個場景的子塔設計保證樣本隔離。

Q15:對于 list、wise、pointwise 這些不同樣本的 loss 設計,這種架構怎麼設計?

A15:目前主要是 pointwise 架構,listwise 邏輯更傾向于在 pointwise 基礎上做二次偏序校正,用于多任務層的偏序表達。

Q16:跨場景模組化後,各場景的推薦會趨同嗎?

A16:目前未出現此現象,底層召回有差異,且不同場景激活的子塔參數分布差異大。

Q17:不同場景的樣本回報延遲會不同嗎?

A17:會,實時場景較快,日更場景較慢,統一做統一時間的批量處理。

Q18:上層和輸出塔有分場景設計的必要嗎?

A18:視業務而定,若業務中某場景某任務非常重要且對其他場景影響可控,可單獨設計輸出塔,目前無統一方法論。

Q19:有歌曲和視訊,能做多長期模組化嗎?

A19:目前主要在歌曲域做多場景模組化,歌曲和視訊差異大,跨域模組化方案更複雜。

Q20:長層次 attention 隻是處理短序列嗎?

A20:不是,長短序列一起處理,短序列可視為 target,長序列視為序列。

Q21:提到統一實驗,如果兩個體量相當的私域一個漲一個跌,如何評估?

A21:先看總量,再看私域場景漲跌情況,總量最重要。

Q22:Task mask 如何解決場景和任務之間的耦合?

A22:A 場景有 A 任務,B 場景無 A 任務,建構樣本時混合 A、B 場景樣本,訓練 B 場景時 mask 掉 A 任務的梯度。

Q23:長序列和短序列多長?

A23:長序列有上萬的長期序列和幾百的中長期興趣序列。

Q24:層次 attention 可以再講解一下嗎?

A24:短序列做 target attention 的 target,長序列做序列。

Q25:如果場景量級不同,采樣大場景會丢失資訊嗎?如何平衡?

A25:會丢失部分資訊,取決于丢失部分對整體的影響,保留能共同模組化且有益的部分。

Q26:上層網絡的分場景設計的思路

A26:受前輩 star 工作影響,設計理念相同,分公域和私域專家,私域為場景私有網絡 SEN,每個場景有獨有網絡,公域設計基于使用者層面的共同興趣表達,而非場景層面。

Q27:關于任務在不同場景中轉化率分布不同,用同一輸出塔可能導緻問題,是否有必要為每個場景的任務分别拆出輸出。

A27:通過私域場景獨立塔保持資訊偏置,保證小場景 COPC 穩定,且梯度隔離可保證 COPC 準确,公域梯度回傳基于使用者公共興趣不受場景轉化率影響。

更多資訊,點選全場景直播解決方案-航天雲網解決方案

繼續閱讀