分享嘉賓：雷鳴 蜻蜓 FM 算法專家

內容來源：作者原創投稿

出品平臺：DataFunTalk

**導讀：**本⽂主要是分享蜻蜓 FM 最近⼏年在推薦系統中的發展和演進，從離線推薦逐步過渡到實時推薦後，作者在實際開發⼯作中，⾯對⼀些痛點和難點時，是如何進⾏思考和解決的，如何更好的將⾃⼰的業務場景特點和算法模型進⾏結合，深度理解⽤戶⾏爲和業務場景，優化⽤戶收聽體驗，以及提升流量分發效率所做出的努⼒和嘗試，推動特徵⼯程和算法模型的微服務化，特別是最近兩年全公司算法相關業務開始逐步 All In 深度學習後，如何⼀步步打造出業內領先的推薦系統。

01

背景簡介

1. 關於我們

蜻蜓 FM——中國移動互聯⽹⾳頻的領跑者, 國內⾸家⾳頻媒體平臺，以敏銳獨到的視⻆傳播世界的聲⾳業內⾸創 PUGC 專業主播⽣態，打造品質感的⾳頻內容體系上架 10 年，突破 4.5 億⽤戶，⽣態流量⽉活躍⽤戶量 1.3 億。

2. 推薦業務場景

⽬前推薦場景分佈⾸⻚ feeds 流，超級會員⻚猜你喜歡、頻道⻚ feeds 流，我聽⻚猜你喜歡等多種場景，涵蓋專輯、節⽬、聽單、直播間等多種形態。

02

推薦系統的演進

推薦系統是幫助⽤戶可以⾼效率的找到⾃⼰感興趣的內容，在我們的推薦場景的定位是幫助⽤戶更快更好的發現新的內容，⽽且保證千⼈千⾯，⽤戶在平臺在追的專輯回溯源頭基本是發⽣在⾸⻚ feeds, ⾸⻚ feeds 承接着平臺絕大部分的流量，所以⾸⻚ feeds 推薦系統的好壞⾄關重要，蜻蜓 FM 推薦系統經過⼏年的⼯程和算法不斷迭代和更新，推薦⾸⻚樣式從固定模塊推薦變爲 feeds 流推薦，推薦效率逐漸完成了從天級別的離線推薦、到分鐘級別的近實時推薦和 ms 級別的實時推薦的轉變，召回策略也逐漸從常規個性化模型到深度召回模型進⾏轉變，排序模型也從樹模型替換爲複雜的深度學習模型，並在線上取得了⼤幅的指標的提升。

03

實時推薦系統架構

什麼是⼀個好的實時推薦系統，應該⾄少滿⾜以下四點：

• 架構既能處理海量數據，⼜能及時響應⽤戶交互；

• 快速迭代推薦策略、算法；

• 優雅降級，即使在服務出現問題的時候，也能推薦出個性化的結果；

• 及時、準確、全⾯的記錄⽤戶反饋。

我們整個推薦系統由主要有四個部分組成，包括 offline 層，Pipeline 層、Online 層，業務層，其中業務層包括多個推薦場景，其中⼤部分場景使⽤的是同⼀套推薦框架，如何快速⾼效地遷移部署到其他推薦場景，是我們需要考慮的問題，每層各司其職，如何保證各⾃任務的穩定性以及保證推薦系統的實時性是⾄關重要的。

• ⼀個是如何實時獲取⽤戶的實時興趣⾮常關鍵，⽤戶通過與 app 發⽣交互，產⽣⼀些播放、收藏、搜索點擊等隱式⾏爲，從算法的⻆度準確計算出⽤戶的實時興趣，及時推薦相關內容，滿⾜⽤戶需求，從⽽可以讓⽤戶停留在平臺更多時間，產⽣沉浸式的體驗；

• 第⼆個是要從架構上要滿⾜實時性的性能要求，從⽤戶觸發推薦 - 召回 - 粗排 - 精排 - 重排，每個環節都需要保證短時間內在推薦鏈路⽣成推薦結果，以及保證架構的穩定性，特別是精排和重排環節，是最後展現內容給⽤戶的環節，實時性必須保證在 ms 級別，⽽模型越好，往往模型越複雜，模型複雜，往往會帶來線上性能壓⼒，但是好的模型，線上提升指標是巨⼤的。

04

召回層回顧

在傳統的實時推薦系統中，存在着⼀個級聯結構，在我們的推薦場景下包括專輯池、召回、精排、重排四個模塊，他們像是⼀個漏⽃⼀樣不斷篩選出⽤戶感興趣的專輯，其中召回模塊是⽐較重要的⼀個模塊，它是通過⼀些算法策略從⼗萬量級的專輯池篩選出數百量級的⽤戶感興趣的專輯投⼊到精排進⾏排序，通過減⼩專輯的量級，從⽽減輕線上排序服務性能的壓⼒。

召回層⼀般有多路召回融合⽽成，需要同時兼顧熱度、覆蓋度、相關度和新鮮度，還需要基於對業務的理解，獲取⽤戶的⻓短期的興趣，按照演變過程分爲常規個性化召回策略和深度個性化召回策略，常規個性化召回策略是指通⽤的，模型較爲簡單的，可以通過並⾏化計算得到結果的策略，⽽深度個性化召回策略需要藉助深度學習複雜模型和 GPU 平臺，以及淺層神經⽹絡、GNN, Attention, GraphEmbedding，⽂本語義等模型框架，獲取到的模型化 Embedding 結果的策略，這些策略相⽐傳統的個性化策略來說，具有更強的表徵能⼒和泛化能⼒。蜻蜓 FM 推薦系統通過最近兩年的迭代，逐漸從常規的 CF、ALS 等召回策略逐步過渡到 EGES、SRGNN，DSSM 等深度召回模型框架，不但極⼤地豐富了我們的召回來源，⽽且也從多個維度更好挖掘出⽤戶的興趣。

我們之前的召回⽅案路線是根據⽤戶的⻓短期興趣、熱度、標籤等開發多路召回策略，根據各個召回策略在線上的表現優劣分爲不同的優先級，然後以集合（topK）爲建模⽬標，按照優先級進⾏多路召回的融合，這種⽅法的優點是速度快、算⼒⼩，缺點也很明顯，從 10 萬量級到數百量級，這樣的篩選漏⽃過⼤，帶來的信息損失也⽐較⼤，⽽且我們所有融合的策略都是基於⼀些⼈⼯經驗進⾏主導，從⽽會導致召回的準確率的不⾜。

難點和挑戰：

如何提升召回階段的準確率⼀直是⼀個難點，也是我們需要解決的問題。

05

粗排層回顧

⾯對召回階段的挑戰，這邊我們的解決思路是在召回模塊和精排模塊添加⼀個名叫粗排的模塊，我們的⽬的是通過模型代替⼈⼯經驗進⾏篩選，從⽽帶來準確率提升，粗排模塊我們採⽤的是根據 DSSM 深度學習模型進⾏改進的雙塔模型，其中它的⽹絡特點是整個⽹絡結構是由⽤戶塔和物品塔組成，每個塔都有各⾃輸⼊特徵和⽹絡結構，然後通過最後⼀層輸出固定維度的 embedding 向量，然後進⾏內積計算，在線上部署時，我們可以將相對靜態的專輯 embedding 向量異步寫⼊到向量索引庫⾥，通過線上實時獲取相對動態的⽤戶 embedding 向量，然後從專輯向量索引庫中召回 topK 的相關專輯列表。

它的優點有很多：

• ⽤戶塔和專輯塔結構是解耦的，他們在最後進⾏內積計算之前沒有模型結構的交叉；

• ⽽且內積計算相關算⼒較⼩，部署線上後，性能得到保證；

• 我們可以添加⾃定義⽹絡結構，增強泛化能⼒；

• 也可以通過加⼊⽤戶實時⾏爲序列特徵，獲取⽤戶的實時興趣；

• 也可以獲得⼀定程度的排序能⼒，因爲訓練的時候使⽤了部分曝光未播放的樣本，從⽽具有⼀定程度的排序能⼒，表達能⼒強。

線上收益：

模型部署到我們⾸⻚ feeds 個性推薦後，帶來了⽐較⼤的指標提升，其中⼀級指標，包括⽤戶⼈均收聽提升了 5.44%，有效 UV-PTR 提升了 3.26%，⼆級指標包括⼈均點擊次數、ItemCTR，會員專輯 UV-PTR、PV-PTR 也帶來了不同程度的提升。

難點和挑戰：

雙塔模型的解耦的模型特點導致了它⽆法更好地使⽤⽤戶和物品的交叉特徵，從⽽限制了它的泛化和表達能⼒，接下來計劃嘗試的解決⽅案有：

• 借鑑模型蒸餾的思想，將精排的模型訓練時產⽣的預測結果部分代⼊到雙塔訓練過程中，將精排模型良好的泛化能⼒遷移到雙塔；

• 拓寬雙塔模型的寬度，當前的雙塔模型是由多層的 MLP 組成，可以在同⼀層上⾯添加 DCN，Self-attention 等具有⾼階特徵交叉能⼒的模型結構，由單塔的 MLP 變爲多塔，並在最後⼀層設置動態權重，從⽽達到增加泛化和表達能⼒的⽬的。

06

排序層回顧

上線基於 DeepFM 的深度學習排序模型：

最近兩年我們的線上排序主⼒模型⼀直是 Xgboost 模型，它具有特徵⼯程簡單，效果優秀，⽀持並⾏訓練，跨語⾔跨平臺部署的優點，我們在 Xgboost 的基礎上，迭代了⼏版，在線上指標也取得了很⼤提升，但是呢，隨着特徵維度變得越來越⼤，模型也變得越來越複雜，以及隨着我們推薦場景的不斷豐富，需要在線預測的地⽅越來越多，在線預測的性能壓⼒變得越來越⼤，性能優化的成本與我們線上獲得的收益不再是成正⽐的關係，線上性能越來越成爲我們的瓶頸，這時我們急需⼀種新的模型框架進⾏替代。

新模型替換 XGboost 同樣⾯臨着不同的困難與挑戰：

• 新的模型框架意味着之前開發 xg 所積累的經驗不再可⽤，需要從頭進⾏數據基礎設施建設，意味着成本問題；

• 這同樣也意味着⻛險，因爲 XG 模型迭代了多個版本，⽬前效果也達到了相對最優，新模型可能有達不到⽬前效果的⻛險；

• 在保證效果的同時，同樣還需要滿⾜嚴苛的線上性能要求，也就是效果與性能之間需要進⾏ trade-off。

通過⼀段時間的調研，我們決定採⽤ deepFM 深度學習排序模型，它是 2017 年華爲諾亞⽅⾈實驗室和哈⼯⼤共同推出的算法模型，⽬前已經成功應⽤在各⼤⼀線互聯⽹的推薦系統中，業界有⽐較多的成熟經驗參考，deepFM 整個算法框架主要分爲兩個部分組成，其中 FM 部分可以理解爲⼀個淺層的神經⽹絡層，它具有⼀定特徵交叉的能⼒，它使模型具有⼀定的記憶能⼒，DNN 部分可以使特徵進⾏更⾼維度的交叉，這使得模型具有⼀定的泛化能⼒，不但可以⼀定程度減⼩⼈⼯特徵挖掘的⼯作量，⽽且這兩部分的 Embedding ⽹絡層是共享的，這就⼤⼤減⼩了模型的複雜度，它更擅⻓處理⼤規模的 ID 類稀疏特徵，像我們⼏⼗萬個的專輯 ID，其實也可以作爲⼀種特徵加⼊模型中進⾏訓練，這些都是 deepFM ⽐ xgboost 有優勢的地⽅。⽽且我們也同時做了其他⽅⾯的優化的嘗試：

• 重新定製了多種適配 deepFM 的特徵庫；

• 我們前期利⽤ Spark Streaming 實時計算框架開發定製了多種實時動態序列特徵，可以更好的捕獲⽤戶的實時興趣；

• 我們把特徵⼯程和預測服務做成了統⼀的 API 接⼝供外部調⽤，並部署到我們的容器雲平臺；

• 在上線前，我們多次進⾏代碼優化，模型結構的簡化，在保證訓練效果的同時，儘量減⼩模型複雜度，同時我們還在線下多次進⾏的線上真實場景的模擬壓測，我們平均 rt 時間控制在 30ms 左右，基本滿⾜我們的性能要求。

線上收益：

我們把新模型部署在了多個推薦場景，其中⾸⻚ feeds 的個性推薦場景，⼀級指標⽤戶收聽時⻓提升 10.94%，有效 UV-PTR 提升 9.26%，有效收聽 ItemPTR 提升 7.83%，其中⼆級指標也得到很⼤提升。

同時我們也把 deepFM 部署在⾸⻚的投放場景和頻道⻚的推薦場景，可以看到上線前和上線後的指標的提升幅度都很⼤。

07

節⽬推薦上線

爲了探索推薦系統更多的可能性，我們進⾏了節⽬推薦第⼀期的探索，⽬的是挖掘觸發推薦時進⾏節⽬⾼效率召回的⽅式，包括節⽬對節⽬，節⽬對專輯，專輯對節⽬的相互影響和發現。

節⽬召回：

針對節⽬推薦的特點，⽬前我們已經開發了以下⼏種召回策略：

• 基於 GraphEmbedding 的 EGES 向量相似召回策略：針對⼀般的 Word2vec 的 embedding ⽅法⽆法對⽤戶順播節⽬序列準確獲取節⽬向量，以及新上線的節⽬⽆法獲取 embedding 的冷啓動問題，採取了基於 EGES 的圖的 embedding 訓練⽅法，在節⽬ ID 的基礎上，獲取類別 ID、tagID 等多維度的 Side-Information，通過 DeepWalk 的隨機遊⾛採樣⽅法以及 Skip-gram 的模型訓練⽅法，準確⾼效獲取節⽬的 embedding 結果，在緩解新節⽬上線的冷啓動以及中⻓尾節⽬的覆蓋度問題上，效果有了很⼤提升。

• 基於 Bert 的語義相似召回策略（覆蓋節⽬ 3 萬左右，可作爲補充策略）：基於業界先進的 Bert ⾃然語⾔預訓練模型，提取各個節⽬標題的⽂本向量，藉助近似近鄰搜索框架 faiss，爲每個節⽬標題匹配最相似的 topK 的相關節⽬，利⽤⽂本多分類的下游任務進⾏微調，使提取的節⽬標題語義向量更加準確，使效果進⼀步提升。

• 基於⼆級分類的熱播節⽬召回策略（時間窗⼝ 2 周）, 兼顧熱度和時間衰減。

• 追更策略：作爲每⽇強插策略與當前節⽬召回進⾏融合, 通過計算出⽤戶有追更狀態的專輯，向⽤戶推薦新上線的節⽬。

線上收益：

同時線上我們進⾏了專輯和節⽬的不同形式的穿插，以及如何⾼效過濾, 節⽬推薦樣式的 AB 實驗, 最終取得了第⼀階段不錯的收益，其中專輯 + 節⽬的整體收益中，⼀級指標包括⼈均收聽時⻓提升了 5%、有效收聽 UVPTR 提升了 7%，其他指標均得到了⼤幅度的提升。

改進⽅向：

當前專輯召回和節⽬召回都是各⾃獨⽴構建同構圖，最終⽣成 Embedding 向量，後⾯會考慮將專輯和節⽬表徵到同⼀個向量空間，⽤ Metapath2vec 的⽅法共同構成異構圖，基於元路徑指導圖上節點的遊⾛，採樣出序列後，經過 skip-gram ⽣成 Metapath 語義下的表徵，最後對錶徵做⼀個融合，得到節點的最終表徵。

節⽬排序上線 MMoE：

最近我們通過分析發現，⽤戶的⼈均收聽時⻓，專輯完播率，收藏專輯次數和⽤戶留存率成正相關的關係，這些隱式⾏爲在⼀定程度上影響着⽤戶的留存，我們⽬前的建模是單⽬標的預測，⽬標是通過直接提升 PTR，來間接提升⽤戶收聽時⻓，這⾥有個問題就是假如只關注專輯是否播放，那麼⽤戶播放後，可能會發現不喜歡或者專輯質量差，覺得體驗太差，⽤戶可能流失，也有可能⽤戶很喜歡，願意加⼊收藏，等有時間接着聽，間接增加⽤戶粘性和回訪率，所以我們在提⾼ PTR 的同時，還需要提升專輯的收藏轉化率，這不但可以增加留存，還可以間接的推薦⾼質量的專輯給⽤戶，提升⽤戶體驗。

同樣的這也適⽤於節⽬排序，⼆期我們開發了基於 MMOE 的多⽬標排序，其中以是否播放和是否完播作爲我們的前期的預測⽬標，MMOE 相⽐ ESMM 這種基於 Shared-bottom 的模型，不同任務的 gating networks 可以學習到不同的組合 experts 的模式，捕捉到不同任務的相關性和區別，可以減⼩受到任務差異和數據分佈帶來的影響，所以 MMoE 作爲我們⾸選的多⽬標排序模型。

這邊我們選擇了三個 Expert ⽹絡，可以看到不同 Label 對於不同的 Expert 的依賴程度是不⼀樣的，⽬前來看，兩個 task 通過 Gate ⽹絡，分別獲取了對不同 expert ⽹絡的權重，其中 Label1 對 expert2 的依賴更⼤，Label2 對 expert1 的依賴更⼤。

線上收益：

在⾸⻚ feeds 上線⼀個⽉後，在專輯 + 節⽬的全局流量的⼀級指標中，包括 UV-PTR 和⼈均播放時⻓提升在 3% 左右。

改進⽅向：

• MMoE 的⼀期特徵中，⽬前只添加了 30 多維的特徵，後期會挖掘更多的⾼效特徵，包括交叉特徵、序列特徵等。

• MMoE 的⽹絡結構中底層使⽤的簡單的 Embedding 層 concat 的形式，後期會嘗試參考 DIN，DeepFM 對現有的⽹絡結構進⾏升級改造並融合 Attention，FM 的⽹絡結構，增強泛化能⼒。

• 當前⽬標是包括是否播放，是否完播的兩個⽬標，後期會融⼊是否收藏、評論、下載等多個⽬標。

• 後期會嘗試使⽤ PLE 的多⽬標排序的新模型，相⽐ MMoE 的優點是消除了 task tower network 和其他任務的 task-specific experts 的聯繫，可以使得不同類型的 experts 進⾏各⾃更專注的學習，不互相⼲擾。

• MMOE 離線訓練時，各 task 之間的 loss 的收斂速度和⼤⼩可能不同，⽐如分類問題和迴歸問題，需要有機制可以在訓練時動態調整各 loss 的權重，⽐如 GradNorm。

• MMOE 部署上線時，各 task 的預測分值需要分別乘以對應的權重，獲得最終分值之後進⾏排序，⽬前有加法融合和乘法融合兩種⽅法，當前我們使⽤的是加法融合，也可以通過⻉葉斯優化的⽅法進⾏最優權重的尋找。

08

重排層回顧

排序模型⼀般是按照 point-wise 的⽅式進⾏訓練，很容易造成相似內容扎堆的現象，考慮到提升⽤戶體驗和內容多樣性，我們也同時嘗試了⼏種提升多樣性的⽅法和策略：

1. 動態刷新

⽬前 feeds 個性化推薦結果，在⽤戶沒有產⽣觸發推薦⾏爲的時候，理論上⽤戶的整個推薦結果是不會產⽣變化的，從數據來看，大部分⽤戶停留在前 3 ⻚，所以⽤戶在觸發推薦之前，多次觸達⾸⻚，看到的內容可能是⼀樣的，這時推薦多樣性就會大打折扣，簡單粗暴的對曝光過的專輯進⾏過濾，可能會過濾⼀些產⽣⽆效曝光的專輯，⽽且過濾⼒度過⼤，還會造成沒有優質專輯可推的局⾯。

我們的⽬的是保證⽤戶沒有觸發推薦的期間，每次打開⾸⻚ feeds，推薦結果都有⼀些變化，⼀定程度解決內容多樣性的問題。

在重排層加⼊動態刷新機制，在召回集基本不變的前提下，優先考慮在集合內部的排序上進⾏動態調整，也就是在排序打分的基礎上除以⼀個降權係數 weight，曝光次數較多的專輯，重排時後移，引⼊時間衰減，近期曝光的專輯更快後移，遠期曝光的專輯迴歸到正常序列。

2. MMR

MMR 是⼀種近似的貪⼼算法，全稱是最⼤邊緣相關模型（Maximal Marginal Relevance），第⼀個 Sim 代表是某個專輯的 rank score，第⼆個 Sim 代表該專輯與⽣成的結果集中專輯的相似度，λ越⼤，越接近原始的排序結果，λ越⼩，越強調多樣性。

同時，我們在計算結果和⼯程效率上也做了部分優化，⼀個是 mmr 是基於多輪迭代的策略，候選集個數越多，計算量越⼤，所以我們只選擇 rank score 在固定 topK 的候選集進⾏了 mmr 的計算，做了計算效率和多樣性效果的 trade-off，還有⼀個是爲了突出⽤戶興趣的實時性，我們對個別候選集進⾏了乘以 rate 係數的加權操作，將部分候選集進⾏多樣性打散後可以排在最前⾯。

3. DPP

⾏列式點過程 (Determinantal Point Process, DPP),  是⼀種基於⾏列式點過程的提升推薦多樣性的算法，並使⽤貪⼼算法推理最優的⾏列式點過程，並利⽤ Cholesky 加速⾏列式點過程的推理，我們使⽤已計算好的 word2vec 的 16 維的 embedding 向量進⾏核矩陣的構建，並做了部分⼯程上的優化。

線上收益：

經過⼀段時間的 ABtest，我們發現加權的 MMR 線上效果最好，它可以保證在其他轉化指標不下降的情況下，提升多樣性指標包括⼈均曝光⼀級類⽬、⼆級類⽬個數，均提升在 10% 以上。

改進點：

接下來會考慮使⽤ list-wise 的思路，從整體推薦列表的物品順序的⻆度進⾏考慮，融合當前物品上下⽂信息，也就是列表其他物品的特徵信息，利⽤ RNN 或者 Transformer 對每個輸⼊對應位置經過特徵融合，按照新預測的得分重新對物品排序，從⽽獲得整體列表的最⼤收益。

09

推動特徵⼯程與算法模型的微服務化

在通常的算法開發⼯作中，需要我們有快速迭代，快速試錯的能⼒，然⽽在以往的我們模型開發部署的過程中，我們經常會遇到部署效率的問題，原因是我們線上⼀般會同時部署多個模型多個版本進⾏ ABtest，每開發⼀個新的排序模型，後端同學都需要把離線的特徵拼接環節在線上進⾏復現⼀遍，其中我們的離線訓練是 scala 語⾔開發，線上是 go 語⾔開發，在這種跨語⾔跨平臺的場景下，特徵拼接極易出現線上線下不⼀致的問題，出現問題需要⼈⼯ review 逐步排查，費事費⼒不說，定位問題也⽐較困難，同時遷移部署到其他推薦場景時，還要徒增重複代碼，不但部署效率⼤⼤減低，⽽且還增加了出現問題的概率和隱患。

同樣的，解決這個問題會遇到⼀些困難和挑戰：

• 如何省去⼈⼯⽐對特徵拼接結果的過程，並保證特徵⼯程線上線下⼀致性；

• 如何進⾏特徵⼯程和模型的多版本部署、多模型擴展和熱加載；

• 如何可以提升部署效率、快速遷移部署到其他推薦場景。

解決⽅案：

• ⾸先我們進⾏了特徵⼯程配置化處理，我們把每個版本的對應特徵處理的配置⽂件存⼊到 redis 中，並分別制定 stg 和 prd 流程，⽅便 stg 線下測試後，線上部署 prd 環境；

• 通過配置中⼼實現多場景、多版本、多模型的統⼀部署和管理，通過配置中⼼可以控制讀取不同類型不同版本的模型⽂件路徑，讀取對應版本的特徵⼯程配置⽂件，⽅便進⾏⼀鍵部署和版本回退；

• 將多特徵數據來源讀取、特徵在線拼接、模型預測服務封裝成統⼀的 API 接⼝，統⼀⽤ scala 的語⾔框架實現，從⽽保證了離線訓練特徵拼接和線上特徵拼接的⼀致性；

• 將這個服務框架開發成端到端的微服務框架，部署到容器雲平臺進⾏統⼀管理，⽅便多場景遷移部署，後端通過發送 deviceID，recallSet，modelType 以及 modelVersion 就可以很⽅便的獲取⽤戶最後的專輯推薦列表。

線上收益：

• 線上部署模型效率值的提升，5 個工作日縮短至半個工作日；

• 模型從離線訓練到部署上線週期，數月縮短至數週；

• 提高模型快速迭代、快速試錯的能力；

• ‍‍整‍個框架已在上海算法平臺進行推廣，現已成功應用在推薦、搜索的多個推薦場景。

10

總結和展望

蜻蜓 FM 作爲國內⾳頻內容領域 top 級別的產品，推薦系統始終扮演着重要⻆⾊，我們也始終關注着推薦領域相關算法的前沿動態，並結合我們對於業務的深刻理解，從算法和⼯程⻆度出發，不斷進⾏摸索和實踐，並且取得了不錯的效果, 希望能給相關從業的同學以思考和啓發，同時也讓我們挖掘出很多改進的點，接下來我們也會從如何保證推薦系統的實時性、提⾼推薦內容的多樣性，保證推薦內容質量、以及提升⽤戶對推薦內容的滿意度，提升⽤戶留存等⼏個⽅向出發，不斷完善我們推薦系統和內容⽣態，以期爲⽤戶帶來更好的收聽體驗。

今天的分享就到這裏，謝謝大家。

在文末分享、點贊、在看，給個 3 連擊唄~

分享嘉賓：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3FN3Xi_h2UMfVW8bFR9-_w