蜻蜓 FM 信息流推薦探索與實踐

**導讀：**如今的推薦系統在互聯網中隨處可見，無論是刷抖音、逛淘寶還是看新聞背後都有強大的推薦系統的支持。音頻行業的內容如何分發？如何提高用戶發現音頻內容的效率？蜻蜓 FM 作爲國內首家互聯網音頻媒體平臺，在音頻行業深耕了 10 年，對此也有一些沉澱和經驗想要和大家分享。

主要內容包括：

01

場景

1. 人工推薦時期

早期蜻蜓首頁流量的分發是以模塊形式展示，每個模塊可配置橫排和豎排的個數。此時只有個性推薦模塊的內容由推薦算法生成，其他模塊則是由運營人工維護。模塊中的內容需要運營定期進行更換，展示內容的更新完全依賴人工，效率顯得很低。

爲了提高運營人工工作效率，我們引入了策略推薦。

2. 策略推薦時期

策略推薦時期運營的工作由之前每天更新模塊中的內容，變成了爲模塊綁定內容庫和選擇合適的排序策略。內容庫中的內容是由配置的分類、屬性動態生成和更新，運營爲單個模塊的配置基本可以做到了一勞永逸。

模塊之間怎麼排序？模塊中的內容排序策略怎麼選才能收益最大化？成了新的挑戰。

3. 個性推薦時期

通過數據發現個性推薦模塊效率高於其他策略推薦的模塊，首先嚐試了擴大個性推薦模塊中內容的數量，由 3 個變 6 個。驗證了對首頁整體效果有提升後，把多個模塊合併成一個信息流的個性化推薦的想法應運而生，線上 AB 實驗結果表明信息流的個性化推薦各項指標均高於多個模塊的策略推薦。信息流的形態是單排還是雙排？經過 AB 實驗，最後選擇了效果更優的雙排。

個性推薦時期運營對於少數專輯依然會有流量扶持、推廣的的述求，在個性化推薦的基礎上增加了投放系統。投放系統中還支持通過不同標題、封面對單個投放計劃生成多個創意，多個創意之間數據表現好的沉澱下來推廣到更多的場景中。運營不再侷限於選擇內容，更爲重要的是重新組織創造了內容，充分發揮出了運營在想象力、創造力上的價值。

4. 小結

首頁場景經歷人工推薦、策略推薦、個性推薦三個階段。策略推薦基本解決了人工效率問題，個性推薦進一步解放人力的同時也帶來了數據指標的顯著提升。

02

算法

伴隨着首頁場景的演進，蜻蜓的推薦算法也在不斷的完善和迭代。

1. 推薦算法流程

推薦算法的流程大致如下：內容池中達到推薦標準的內容的有幾十萬個，召回層從中選出用戶可能喜歡的幾千個進入粗排層，召回層的覆蓋度決定了整體推薦內容的覆蓋上限。粗排層從召回結果中挑選出幾百個給到精排層，粗排層主要爲了減小在線算力減輕精排的壓力。精排層選幾十個給到重排層，精排層專注於推薦的準確性。最後，重排層對推薦結果進行重新排序給到用戶，這一層兼顧準確性的同時還需要保證多樣性。

級聯結構簡單，分工明確。兼顧了覆蓋度、性能、準確性和多樣性。

2. 多路召回

熟悉了推薦的算法的大致流程後，首先，我們來了解一下多路召回。多路召回在蜻蜓主要分爲三類：基於內容、協同過濾和 Embedding 向量召回。基於內容的召回包括熱門、屬性、上新策略的召回；協同過濾包括 User Based 和 Item Based；Embedding 向量召回有 Word2vec 和 Bert。召回環節處理的數據量大，複雜度不能太高，多路召回的設計可以方便加入新的策略或者算法。我們在實踐中發現，早期建立完善指標，追蹤每路召回的效果，有助優勝劣汰；召回的效果並不是召回算法越複雜越好，不同的業務特點不一樣適合的召回也可能不一樣，比如蜻蜓當下表現最優的召回來自 ItemCF 和熱門；隨着召回的算法越加越多，新的召回需要與現有召回有差異性、互補纔會有存在的價值。召回環節還會承載業務及平臺建設的使命比如用戶和物品的冷啓動、業務流量扶持等，召回環節的好壞直接決定了後續環節的上限。

3. 粗排

接着是粗排，早期的推進系統中粗排常常用簡單的融合策略進行，實踐中發現粗排中引入算法是值得的。策略的組合較多測試周期長，雙塔模型的應用既解決了多路召回組合的效率問題，又避免了精排的性能問題。

雙塔模型擴展性好便於自由添加自定義的網絡，User 和 Item 塔解偶，同時點積的計算所需算力小。在蜻蜓爲了保障粗排推理數據的實時性，User 向量的生成及點積的計算都是實時的。粗排的加入在數據指標指標上也獲得了不錯的收益，其中信息流 UV 收聽轉化率增加了 3.54%，人均收聽時長增加了 5.44%。

4. 精排

然後是精排，精排往往在推薦系統中最受關注，精排直接對準確性負責，相對容易拿到直接的收益。我們在精排的投入相對較大，從中獲得的收益也相對頗多。蜻蜓的精排經歷了三個階段：線性模型的邏輯迴歸和 FM、樹模型的 XGBoost 以及神經網絡模型的 DeepFM。

XGBoost 迭代時間最久，其中模型參數的調優、特徵挖掘（包括交叉特徵和實時特徵的引入）、日誌數據的準確性優化以及實時排序，這些整體給在線收聽數據帶來了近 35% 的提升。XGBoost 之後我們嘗試過許多模型包括 XGBoost+LR，Wide&Deep 等均沒有取得預期的收益，在 DeepFM 上的嘗試探索則獲得了 9.3% 收聽相關指標的提升。DeepFM 順理成章地成爲了精排模型的主力，也開啓了蜻蜓推薦算法在深度學習道路上的大門。

5. 重排

最後是重排，重排跟召回一樣承載了很多業務向的目標和期許。這裏主要講一下多樣性，提升多樣性一方面希望打破推薦系統的信息繭房，另一方面也希望提升用戶的長期使用體驗。開始是通過打散策略實現，當前主要是 MMR 和 DPP 兩個算法在嘗試迭代，實驗中 MMR 表現優於 DPP，這裏簡單介紹一下。MMR(Maximal Marginal Relevance) 最大邊際相關性算法，保證相關性的同時提高多樣性。通過λ參數來調節多樣性和相關性的權重，λ越大相關性越高，λ越小則多樣性越高。

MMR 算法中有兩個相似度，用戶和物品的相似度用精排的打分值來表示，物品之間的相似度基於協同過濾的物品相似度。重排的預期是達到帕累托最優，在其他指標都不降低的情況下，提升多樣性指標。

最終也達到了預期，人均曝光專輯數量增加 8.84%，人均收聽二級分類數量提升 7.06%。

03

架構

1. 整體架構

推薦系統能高效穩定地運作，離不開優秀的架構支持。蜻蜓的推薦架構是典型的三層架構，即離線、近線、在線三層。離線層負責數據的處理、模型的訓練以及數據報表；近線層實時特徵處理、召回、粗排；在線層承載了用戶請求響應、精排、重排以及投放系統等業務邏輯。

2. 算法模型部署

算法模型如何高效地部署到線上？是算法和工程同學共同面臨的挑戰。開始的時候我們的模型預測服務和推薦 API 都是用 Golang 實現，特徵的獲取處理在推薦 API 測完成，模型預測服務負責加載模型並對對獲取的數據進行預測。在線特徵拼接處理使用 Golang，離線特徵拼接處理使用 Scala，跨語言的對齊與校驗耗費了開發很多的時間。離線和在線能否公用一套算子進行特徵的拼接與處理？爲此我們將模型預測服務切換成了 Scala 的 Play 框架，基於 Scala 開發出了一個 feature 獲取處理的庫，給 Spark 和 Play 共同使用，保證了特徵處理邏輯層面的一致性。同時，模型預測服務中增加了對多模型、多版本的支持以及模型的自動更新進一步提高了模型部署的效率。

04

展望

首頁信息流推薦從 0 到 1 建立起來，迭代、優化、完善到現在取得了不錯的增長，面向未來還有許多工作需要我們去嘗試和探索。內容方面，如何幫助新品內容一步一步變成曝款，產品、研發、運營如何合作建立出完善的內容生態系統；業務方面，信息流支持的業務越來越多包括專輯、直播、聽單、節目、廣播等，多業務如何更好的融合在一起也是一個挑戰；用戶方面，新用戶的冷啓動，沉默用戶、潛在流失用戶如何激活還有很長的路要走；算法方面，模型的訓練如何做到更加實時，多目標的排序是否有望代替單目標排序。這些都將是我們接下來探索的方向。

文章作者：

季飛

蜻蜓 FM | 推薦技術負責人

9 年推薦、搜索相關工作經驗，目前負責蜻蜓 FM 推薦、搜索等流量分發業務的架構與算法開發工作。

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

猜你喜歡