個性化推薦系統的基本結構

個性化推薦系統簡介

個性化推薦系統是針對不同的用戶進行差異化推薦的系統,目的就是幫助用戶過濾掉沒有興趣的信息,爲用戶提供一個定製感強的信息流。其實早在移動互聯網爆發以前,很多網站上就都有自己的個性化推薦系統,但是由於當時的算法,大數據,以及信息量都遠不如移動互聯網時代,因此大部分個性化推薦還是使用非常傳統的策略,有點像是傳統行業基於用戶畫像的營銷手段。目前的個性化推薦系統,指的主要是基於機器學習和深度學習算法實現的系統。

傳統推薦策略

在移動互聯網普及以前,各大公司採用的推薦策略相對簡單很多。因爲用戶的數量和用戶的行爲數據在體量上都遠遠小於移動互聯網時代,並且最關鍵的是,那個時期還是一個主編寫文章,或者頭部網友做UGC的時期,商品上也往往是比較常見的品牌商品居多。所以在當時,個性化推薦往往對用戶(user)的畫像信息和物品(item)的畫像信息進行分析,然後去做user與item的匹配。比如一個用戶畫像符合購買某個item的人羣的統計特徵,我們就會認爲這個人很可能對這個item感興趣;或者一個人看了某一篇文章,那麼和這個文章有相同tag的其他文章也有可能是該用戶該興趣的文章。

除了比較偏向統計的方式以外,還有一些比較算法類的推薦方式。比如通過關聯規則挖掘user之間以及item之間的關聯。另一種常見的挖掘user和item之間關聯的方式就是通過矩陣分解的思路,這也是比較早期的嵌入(embedding)方式。

當然即使對於個性化推薦系統,非個性化的熱門推薦也是必不可少的。只不過在這一點上,各個產品對自家業務的理解和實際需求各不相同,所以熱門推薦的類型也是五花八門。

信息過載

當移動互聯網普及以後,信息過載的現象愈發嚴重,傳統推薦策略的問題逐漸顯露。信息過載指的是一個app掌握了大量的可曝光信息,這些信息的數量遠遠大於實際需要的曝光量,因此必須要從數據庫中選出很小的一部分進行曝光。如果按照傳統推薦策略,依靠用戶畫像去做推薦,那麼很多item之間的差異很難被體現出來。隨着user-item的矩陣維度的上升,矩陣分解的推薦難度也在變大。因此需要使用各種手段將真正有用的信息從大量數據裏快速提取出來。這一階段的推薦策略迅速向機器學習和深度學習的方式傾斜。

推薦系統基本結構

目前的推薦系統,無論是電商,還是短視頻,在設計上都會遵循一個比較基本的框架。大體來說,推薦部分可以看成是先對item做召回(recall),之後再對召回的結果做一個排序(rank)。這樣得到的排序結果,就是最終曝光到用戶app上的結果。當然這個結構是最基本的結構,實際上每個產品的推薦系統肯定要比這個複雜的多。簡單介紹一個之前參與過的新聞與視頻feed流的推薦系統的大致結構:

Kafka
Redis
Spark
Fetch Result
Crawler
Item Databases
User Databases
Raw Data
Behaviour Logs
Recall Layer
Ranking Layer
UI
Recall Result
Request
  1. 通過爬蟲獲取數據,使用Kafka作爲消息隊列(MQ)將抓取的新聞和視頻放入item庫中,item庫,user庫和behaviour庫,在推薦系統中一般統稱爲物料庫。物料庫中的原始數據是基於事實得到的,未經算法處理過的原始數據,用於後續的算法推薦。
  2. 召回層包含多條召回通道,每條通道根據算法或規則需要從物料庫中獲得相應數據,之後將各自算法或規則的輸出結果作爲recall result存入數據庫作爲離線召回候選集。
  3. 排序層一般是由一到兩個點擊率(CTR)預估模型構成的,目的是將recall result中的大量候選item進行排序,從而保證優先曝光高CTR的item。排序層的排序結果將會反映到app的feed流中,通過在app中埋點,我們可以實時得到用戶對推薦結果的反饋。比如用戶是否點擊了某一個曝光的item,用戶在觀看視頻之後是否進行了分享等等。這些數據將會存入Redis作爲排序層的線上實時特徵,同時也會由Spark進行批量統計,生成每分鐘的報表並且更新raw data中的部分數據。

物料庫

我們的物料庫使用的是Spark+Hive的形式,具體數據庫的選取根據業務場景自行定義就好。物料庫中的數據一般涵蓋user畫像信息,item畫像信息,以及user behaviour log這三部分。物料庫的更新並不一定要做到完全實時的流式處理,只要能滿足線上推薦系統的更新要求就行。我之前做的這個推薦系統的物料庫的更新可以算是是秒級延遲的微批處理,而Hive中的數據大概每10分鐘才更新一次,但是這樣的更新水平已經足以滿足我們的算法更新需求了。新聞的規則召回以及相關新聞召回是更新頻率最高的兩個召回通道,也僅僅是在每小時更新一次的水平。

召回層

召回層的本質是過濾掉大量的無用信息,將海量數據過濾成幾百條的候選集,從而解決排序算法無法在線遍歷所有數據的問題。召回層往往包含多條召回通道,根據業務需要召回通道的邏輯也是五花八門。每一種召回算法最好可以有不同的功能,兼顧推薦系統的利用與探索兩個方面。利用是指基於現有數據爲用戶找到他最感興趣的相關items,特點是CTR/CVR高,或者用戶的觀看時間長,打分高等等。這部分推薦結果在很多指標上表現都很好,在召回通道上往往是由item CF等基於用戶個人歷史行爲的算法來實現。探索則是爲了避免過分利用導致用戶的興趣點被越推越窄,從而陷入一個局部無法接觸更多的可能的情況。我們在爲用戶推薦時,還要考慮到如何幫助用戶探索到他沒有瀏覽過但很可能感興趣的領域。這部分推薦結果在指標上可能不如利用型推薦結果,但是對推薦生態的整體生態健康貢獻更大,比如推薦結果的多樣性,用戶的長期粘性等等。

召回算法根據不同業務雖然差別較大,但是也有一些比較經典的方向可以參考。

規則召回

規則召回可以說是最經典的推薦方式了,最簡單的比如通過用戶畫像來判斷用戶最感興趣的領域,然後將該領域的優質item推薦給該用戶,或者很多論壇基於發帖時間和回覆,轉發,贊,踩的數量做的熱榜召回,這些都屬於規則召回的範疇。規則召回的一大優勢就是不需要進行模型訓練,因此在冷啓動或者低頻item,低活躍用戶的推薦場景下表現良好。

Embedding的流行

伴隨數據量的上升,將user或者item進行向量化的效果逐漸提升,優勢也逐漸顯現。使用embedding對user和item進行向量化,之後通過稠密向量得到的user之間或item之間的相互關係往往可以反映出更深層的聯繫。同時embedding也可以爲許多模型提供輸入的特徵。因此對於大多數推薦系統而言,user和item的embedding幾乎都是daily task類型的基礎設施。

協同過濾與item CF

協同過濾是基於item共現的情況挖掘出高頻組合,從而進行相似item的推薦。這可以算是item CF在早期非常有效的一種方式了。後續item CF的發展則是朝embedding方向深入挖掘,比較常見的有基於點擊序列數據使用word2vec進行item的embedding,或者通過矩陣分解完成的embedding。

用戶聚類和user CF

用戶聚類最初也是通過用戶畫像進行,比如視頻app可以爲用戶在各個分類下的興趣做一個打分,之後通過這些分數將用戶劃分成不同的類,也可以將一些指標進行歸一化後拼接到一個空間,之後使用k-means等聚類算法。主題模型同樣也可以應用到用戶聚類上,例如LDA

隨着embedding技術的流行,用戶聚類也開始朝向量化轉變。整個

序列化推薦

冷啓動的召回

排序層

粗排序

精排序

重排序

博客設置頁面,選擇一款你喜歡的代碼片高亮樣式,下面展示同樣高亮的 代碼片.

// An highlighted block
var foo = 'bar';

指標與評價

常見指標與用戶的體驗

評價的困難

  • 項目
    • 項目
      • 項目
  1. 項目1
  2. 項目2
  3. 項目3
  • 計劃任務
  • 完成任務

創建一個表格

一個簡單的表格是這麼創建的:

項目 Value
電腦 $1600
手機 $12
導管 $1

設定內容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

第一列 第二列 第三列
第一列文本居中 第二列文本居右 第三列文本居左

SmartyPants

SmartyPants將ASCII標點字符轉換爲“智能”印刷標點HTML實體。例如:

TYPE ASCII HTML
Single backticks 'Isn't this fun?' ‘Isn’t this fun?’
Quotes "Isn't this fun?" “Isn’t this fun?”
Dashes -- is en-dash, --- is em-dash – is en-dash, — is em-dash

創建一個自定義列表

Markdown
Text-to-HTML conversion tool
Authors
John
Luke

如何創建一個註腳

一個具有註腳的文本。1

註釋也是必不可少的

Markdown將文本轉換爲 HTML

KaTeX數學公式

您可以使用渲染LaTeX數學表達式 KaTeX:

Gamma公式展示 Γ(n)=(n1)!nN\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N 是通過歐拉積分

Γ(z)=0tz1etdt. \Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,.

你可以找到更多關於的信息 LaTeX 數學表達式here.

新的甘特圖功能,豐富你的文章

Mon 06Mon 13Mon 20已完成 進行中 計劃一 計劃二 現有任務Adding GANTT diagram functionality to mermaid
  • 關於 甘特圖 語法,參考 這兒,

UML 圖表

可以使用UML圖表進行渲染。 Mermaid. 例如下面產生的一個序列圖:

張三李四王五你好!李四, 最近怎麼樣?你最近怎麼樣,王五?我很好,謝謝!我很好,謝謝!李四想了很長時間,文字太長了不適合放在一行.打量着王五...很好... 王五, 你怎麼樣?張三李四王五

這將產生一個流程圖。:

鏈接
長方形
圓角長方形
菱形
  • 關於 Mermaid 語法,參考 這兒,

FLowchart流程圖

我們依舊會支持flowchart的流程圖:

Created with Raphaël 2.2.0開始我的操作確認?結束yesno
  • 關於 Flowchart流程圖 語法,參考 這兒.

導出與導入

導出

如果你想嘗試使用此編輯器, 你可以在此篇文章任意編輯。當你完成了一篇文章的寫作, 在上方工具欄找到 文章導出 ,生成一個.md文件或者.html文件進行本地保存。

導入

如果你想加載一篇你寫過的.md文件,在上方工具欄可以選擇導入功能進行對應擴展名的文件導入,
繼續你的創作。


  1. 註腳的解釋 ↩︎

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章