推薦系統之業務架構總覽
前言
前一篇介紹了推薦系統冷啟動的問題,既然已經cold start了,這一節就大致講下新聞推薦系統的業務架構,也就是新聞推薦系統需要有哪些模組組成,每一個模組的職責是什麼。
首先看下整個新聞推薦系統大圖,今天這篇文章就是為大家講解這張圖的具體含義和相互關係,今天主要是介紹大概最為開篇,接下來會有一系列文章介紹圖中每一部分的策略。
(畫圖不容易版權相關,轉載請註明出處~)
圖中紅色相關的形狀是兩個輸入,分別是使用者和內容,分別代表兩個路徑,表示的是當推薦系統進入一個使用者或一個內容的行為軌跡。本文把整個推薦系統按照業務路徑分成3個部分,分別是使用者資料軌跡、內容資料軌跡以及推薦列表生成,接下來分別介紹下每個環節的作用。
01
使用者軌跡
使用者軌跡方面,每次進來一名使用者首先要判斷這名使用者是否是新使用者,一旦發現是新使用者將啟動冷啟動策略,這個策略在之前的文章已經介紹過。如果使用者不涉及到冷啟動問題,則進入使用者畫像的構建流程。
使用者畫像的構建分為兩種,分別是使用者註冊標籤特徵(使用者註冊的時候獲取的特徵),還有一種是平臺行為特徵(使用者過去在平臺的一些操作日誌)
使用者註冊標籤特徵
這部分特徵是原始生成的,不需要每次使用者登入都重新計算並修改。
-
賬號註冊資訊:註冊的時候可以讓使用者填寫年齡、性別等內容、手機號等內容,同時也可以通過LBS資訊瞭解使用者的活動區域。針對這些資訊可以給使用者興趣做一個初步判斷,比如年輕的都市女性,往往有較高的消費能力,在推薦策略上可以推薦高規格的一些內容
-
身份證資訊:現在很多系統都需要實名認證,身份證號其實可以帶來很多有用的資訊,比如前兩位是省級程式碼,34位是市級程式碼,7-14位是生日程式碼,第17位是性別程式碼(奇數代表男性、偶數代表女性)
-
社交賬號登入:如果系統可以設計成支援淘寶、微信等賬號登入,也可以通過這些系統拿到部分使用者畫像資訊
-
預採集:現在很多APP,當使用者初次進入都有一個興趣愛好勾選的按鈕,這個就是為了解決冷啟動的一個手段,在推薦之前先通過使用者標記獲取使用者資訊
-
資料交換:註冊的時候其實可以拿到使用者的手機號碼,現在有很多賣資料的公司都提供使用者畫像資料的交易,只要提供手機號就能獲取特別全的使用者資料(這個貌似是個黑產業)
平臺行為特徵
需要每次使用者登入都記錄的特徵
-
使用者歷史的瀏覽記錄,比如使用者關注了哪些類目的新聞,比如體育新聞或者娛樂新聞
-
使用者在平臺上的一些反饋,評論、點贊、收藏都資訊
-
使用者的LBS變化資訊,比如使用者經常往返於北京和杭州,這些資訊需要實時抓取
獲取了以上使用者的特徵資訊,做彙總就可以入“使用者總庫”,這個使用者行為資料庫將對接下來的模型訓練起到重要作用。
02
內容軌跡
內容軌跡指的是每次平臺新增新聞內容時的操作。新聞內容不同於其它推薦場景,對於內容的安全審查是非常重要的。如果出現不健康內容,對於平臺會有很大的傷害,具體策略日後詳細講解。執行完內容審查,要開始對內容進行打標,標籤分兩種,分別是內容自身特徵以及平臺行為特徵。
注:新聞推薦的更多是傾向於文章標題推薦,而安全審查更多地針對文章內容
內容自身特徵
內容自身的屬性,不需要頻繁更新
-
內容所屬類別,可以分多個級別標記,比如可以標為體育,體育下一級還可以標為籃球,這個標註是依靠演算法實現。比如關鍵詞提取或者主題模型
-
內容主體識別,標記出文章包含哪些主體,比如下面這句話“費德勒是個出色的網球運動員”。可以找出“網球”、“運動員”、“費德勒”這3個主體
-
文章的釋出時間、釋出者等資訊,以及是否有地理相關性的特徵
平臺行為特徵
平臺行為特徵指的是新聞內容在平臺上歷史被點選、點贊、收藏、轉發等資訊。
03
推薦候選集生成軌跡
當收集了內容以及使用者特徵後,就組成了所有平臺上的內容總庫以及使用者總庫,可以將這兩個元件合併構建出模型訓練集。訓練集彙總了所有平臺上的某某文章被某某閱讀點選過的全部行為日誌,這樣就可以通過演算法訓練一個模型用來新聞推薦。
演算法有很多形式可以選擇,這個在未來的章節詳細介紹
有了內容推薦模型後,要進行的操作就比較簡單了,為使用者預測出他感興趣的模型。有的同學會說,既然有了模型那麼對每個使用者在全網所有文章的興趣點預測一次,取topN不就可以了?通常推薦系統不會這麼做,因為每個使用者對每個文章都算一下興趣度計算量非常大,而且很難在使用者進入新聞終端時快速拿到預測結果。
通常的做法是先通過召回策略篩選出部分推薦候選集,再通過內容推薦模型對候選集進行預測並排序,這樣就可以大大減少計算量。
召回策略候選集可以通過使用者畫像標籤從內容總庫中快速查詢獲得。
通過內容推薦模型對召回候選集資料進行預測,拿到使用者感興趣的文章排序列表,就可以推送給使用者。以上是本文的介紹,略過了中間的很多策略,待後續文章補充。
參考文獻:http://lusongsong.com/info/post/9829.html
相關文章
- 推薦系統工程架構架構
- Netflix推薦系統(Part two)-系統架構架構
- 【推薦系統篇】--推薦系統之之特徵工程部分---構建訓練集流程特徵工程
- 【推薦系統篇】--推薦系統之訓練模型模型
- 推薦系統技術概覽
- 【推薦系統篇】--推薦系統之測試資料
- 微服務架構之「 監控系統 」微服務架構
- 推薦系統論文之序列推薦:KERL
- 如何構建推薦系統
- 【推薦系統篇】--推薦系統介紹和基本架構流程架構
- 推薦系統[八]演算法實踐總結V0:騰訊音樂全民K歌推薦系統架構及粗排設計演算法架構
- 問題解決:構建基於深度學習架構的推薦系統!深度學習架構
- 業務單系統架構設計心得(一)架構
- 今日頭條推薦系統架構設計實踐(附下載)架構
- 【推薦系統】評估指標總結指標
- 系統架構設計之-任務排程系統的設計架構
- 第四正規化程曉澄: 推薦系統的架構演進架構
- 魅族推薦平臺架構架構
- MySQL架構與業務總結圖MySql架構
- 推薦系統之冷啟動問題
- 【轉】推薦系統演算法總結(一)演算法
- 推薦系統 embedding 技術實踐總結
- 推薦系統概述
- python 推薦系統Python
- 趣頭條 業務架構師 40-60K 歡迎推薦和轉發架構
- 從單體到微服務,軟體架構演化總覽微服務架構
- 《推薦系統實踐》筆記 01 推薦系統簡介筆記
- 推薦系統入門之使用協同過濾實現商品推薦
- 分散式系統架構之構建你的任務排程中心分散式架構
- Twitter推薦引擎架構設計分析架構
- 對話推薦系統 | (1) 任務定義
- 系統設計:使用Scala、Spark和Hadoop構建推薦系統SparkHadoop
- 推薦系統之資訊繭房問題
- 解決方案架構、系統架構和企業架構區別架構
- 業務架構架構
- 推薦系統一——深入理解YouTube推薦系統演算法演算法
- Flutter框架分析(一)--架構總覽Flutter框架架構
- 微服務架構下的系統整合微服務架構