Feed推薦引擎動態融合、規劃、編排是怎樣的

Feed推薦引擎動態融合、規劃、編排是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

目前市面上看到的Feed流推薦引擎，應用到了的場景比較單一，除了資訊、內容的推薦，也就差不多就是好友推薦了。

雖然，實現的方式不盡相同，總體上可以分為3類模型：

1.推模式

不同于常規意義的推送，這里側重于 “推到一個地方”，存儲或緩存。比如給每個人維護一個推薦列表，以增加寫擴散的復雜度，降低讀擴散的成本，讀取feed流的性能很突出。存在的問題就是，在寫入推薦列表時的性能、存儲壓力，以及信息的及時性。

2.拉模式

需要數據的時候，主動去拉取數據。近線查詢的方式，保證了數據的及時性，降低了存儲壓力。按需加載，使用的時候才去拉取，服務性價比高。換來的代價就是，服務端進行復雜場景數據的召回、聚合、編排的壓力。沒有很好的緩存場景，尤其是在海量請求下，服務的響應能力簡直亞歷山大。

3.推拉混合

等同于結合推、拉模式各自的優點，對業務場景進行最優的場景化適配，以控制的復雜度來換取服務性能的一個平衡。

自從頭條系的產品矩陣，加速了Feed流的算法推薦進程以后。不管是今日頭條的資訊類產品，還是諸如Echo這樣的社交產品，在面對極度的信息大爆炸和用戶時間碎片化問題上，偏向于算法驅動的推薦引擎。

既然是推薦系統，那么作為 “飼料、飼養” 的feed都有哪些呢？

1.日常短語

日常短語，泛指那些少量文字，混合資源內容的形式。如微博、朋友圈、Twitter、說說等形式。

2.文章、資訊

這個最常見的，如文章、新聞資訊等。一般形式由標題、內容構成，內容是一個富文本的，混合著圖、文、資源的大量內容主體。

3.短視頻

想了想還是把短視頻單獨抽取出來了，短視頻賽道隨著抖音、快手的覆蓋，獨當一面。作為一種輕流媒體形式，越來越重要。

4.泛資源內容

可以說除了文字以外，都屬于資源內容范疇，如動圖、音頻、視頻、文件等。這個分類并不是獨立存在的，經常是混合著前幾類大量存在。獨立這個分類的最主要原因是，很多時候如果只有資源內容，對于推薦系統就是一個巨大的挑戰。牽扯到了另一領域，對于資源文件的內容識別。

由于feed流沒有固定的分頁概念，但是可以采用弱化的分頁方式。
簡化版可以進行兩段式分隔：首頁、其它頁。

第1頁：固定位置、或重要的數據、或banner位、熱門榜單等（如某要聞始終占第一位）。

第2頁（及以后所有頁）：可以根據用戶相關性進行推薦、以及隨機性的頁數內容推薦、更加豐富的多樣性嘗試。這樣處理過度也比較自然，兼容冷啟動。

由于信息流推薦的結果，不同于一般的分頁查詢，具有數據多樣性。并不能保證看到結果的一致性，比較抽象（由于朋友圈的慣性思維，你總需要不斷解釋為什么看不到xx數據）。

尤其是，對于豐富的feed內容進行編排序，同類型數據的打散、首頁特殊處理、數據穿插等等，頭疼的事情總是不厭其煩。

這個時候，就需要一個可視化模型，來驗證和調試推薦的結果展示。

#召回候選數據集的編排序：

• 第一段：用于強制的優先級，如業務或特殊要求；

• 第二段：用于真正意義上的進行動態規劃、動態編排序；

• 第三段：主要用于數據后補，防止召回數據不足時進行試錯帶來的內耗。

建議采用這種三段式的編排結構，來滿足復雜場景的編排訴求。

#基于業務場景的數據融合方案

根據具體的場景化數據形態，進行最優的數據庫選型，實現多數據源融合方案。

#推薦系統的可解釋性：

• 每一頁的推薦模型數據形態分布圖，代表了每次推薦的解釋形態；

• 左側類別，屬于召回的數據集分類（因子庫），每頁保證不少于3個因子；

• 右側色塊，表示召回的數據編排序（編排、穿插、離散）后的，子類型的時序。

看完上述內容，你們掌握Feed推薦引擎動態融合、規劃、編排是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！