大數據

推薦系統基本概念和架構

課程地址:https://developer.aliyun.com/course/2052

一、什麼是推薦系統

(一)常見的推薦業務場景

首先給大家分享一下什麼是推薦系統,為什麼要有推薦系統。伴隨著互聯網應用的發展,人們可以涉獵到更多的資訊。比如說進入到一個淘寶的平臺,有非常多的商品,如何將適合用戶的商品去觸達他,是淘寶需要解決的一個問題。本質上,推薦系統解決的是一個信息比對的問題。怎麼樣基於用戶的信息和商品的信息去做一個更好的匹配,這是推薦系統要解決的問題。大家平時在用各種手機APP的時候,其實已經對很多的推薦場景或多或少的有些瞭解。常見的推薦業務場景有兩個。一個是基於搜索Query的推薦,還有一個是基於用戶和商品屬性的Feed流的推薦。

大家看左邊這個圖,什麼叫Query推薦,比如說我搜索一個口罩,它下面展示的肯定都是跟口罩相關的東西。可能有11萬多個口罩相關的商品,哪些排在前面,哪些排到後面,這裡需要有推薦系統。它需要根據用戶的屬性,比如說他喜歡的顏色、價格偏好等,來進行排序。如果他喜歡買貴的奢侈品,我肯定把一些貴的、性能好的口罩放在前面。如果他是一個價格敏感的用戶,我可能要把價格稍微便宜、性價比高的口罩放在前面。綜上,就是說Query推薦要基於用戶的購買偏好,還有商品的屬性去做一個匹配。

再來看右圖,Feed流推薦越來越成為很多APP跟用戶交互的主流。打開虎撲、今日頭條這樣的APP,你會發現首頁的新聞都是根據你日常的偏好去推薦的。比如說你喜歡籃球相關的新聞,它可能更多的把體育相關的內容推薦給你。基於用戶和商品的Feed流推薦,我們採用機器學習推薦模型,它既要學習用戶,也要學習商品的屬性。我們今天介紹的推薦系統架構,在用戶屬性和商品屬性的匹配過程中,底層的系統實現,更多的是偏向於基於用戶和商品屬性的Feed流推薦這樣的一個場景。
image.png

(二)個性化推薦業務流程

首先我把整個推薦業務做了一個簡圖,如下圖所示。假設我們有一個新聞平臺,用戶A進來,它有一個ID。這個平臺有成千上萬的新聞,我們把它叫item。每個item有一個ID,比如說1、2、3這樣排列下去。我們現在要把10萬個item中篩選出用戶A喜歡的新聞。我們看一下要做這件事,在底層的業務架構要有哪些模塊。在一個經典的排序推薦召回系統裡,它會有兩個模塊。第一個叫召回,第二個叫排序。召回模塊把這10萬個新聞做一個初篩,選出A可能喜歡的,比如說500個item先放到這裡,我們只知道A大致會喜歡這500個item,並不知道這500個item哪個是A最喜歡的,哪個是他第二喜歡的。接下來是排序模塊,對這500個item做一個排序,按照喜愛的順序去制定最終投放給A的item的列表。所以在整個的推薦業務中,召回模塊更多的是一個初篩,確定一個大體的輪廓和範圍。這樣的話可以加速排序模塊對於每個商品的屬性排序,用戶得到推薦反饋的效率會更高。一個專業的推薦系統需要在幾十毫秒內,即用戶一進來就可以給他推薦反饋。對Feed流的內容,用戶在網上刷一下屏幕,可能有幾十毫秒,然後我們馬上要把新推薦的item又展示出來。這是整個推薦業務的邏輯。

推薦系統可以理解為推薦算法和系統工程的總和,即推薦系統=推薦算法+系統工程。關於推薦系統,很多的書和網上的資料更多的是聚焦到這個算法怎麼做,包括很多paper都說的是最新的推薦算法。但是,當你真正動手去搭建這套業務系統,特別是在雲上去做的時候,你發現其實是一個系統化的工程。即使你知道推薦業務需要用哪些算法,你依然會面臨很多問題。比如說性能的問題、數據存儲的問題,等等。所以我們這一次分享的重點,把系統工程的問題也給大家闡述出來,既講算法也講系統,兩者結合就是一個完整的推薦系統。
image.png

二、企業級推薦系統架構

(一)企業級推薦系統要求

接下來我們看一下整個的企業級推薦系統架構。設計這樣的一個架構,有四個基本要求。第一個要求,目標客戶有百萬級MAU(monthly active user)的一個推薦業務需求的應用,每一次參與模型訓練的時候,整個的訓練樣本量可能是上億級別的。需要基於整個平臺過去一個月甚至半年的數據做一個整體的建模,因為在機器學習領域數據量越大,模型越精準。數據可以拆分為三種:用戶的行為數據、商品的行為數據、用戶商品之間的交互數據。第二個要求,它要有算法插件化部署的能力。大家知道機器學習這個領域,包括推薦領域發展特別快,每年都會衍生出一些新的算法。這些算法在整個系統中能不能做到靈活地插拔。比如說今天我用算法A,明天算法B。我可不可以方便的把算法A直接踢掉。這就是你的系統的魯棒性,包括對於算法組件化支持的能力。我們現在推出的阿里雲機器學習平臺PAI有這樣的一個能力。第三個要求,就是服務的性能問題。你是否可以做到每次請求毫秒級反饋。第四個要求,就是支持資源的彈性拓展。比如說對於一些APP,可能下班的時候大家在地鐵上刷得比較多,凌晨大家刷得很少,你的推薦模型底層的使用資源,在用戶量大的時候需要更多資源,在凌晨需要更少的資源。為了平衡成本,你能否實現底層資源的靈活拓展性。這個可能適用雲上的服務,它的一個優勢是資源的彈性。如果搭建一個企業級的推薦系統,一定要滿足上述四個基本的要求。
image.png

(二)推薦整體架構

接下來我們重點講一下推薦的整體架構。如下圖所示,最下面就是基礎數據層。我們可以看到有用戶的畫像數據,有物料本身的數據,行為數據,評論數據。用戶畫像數據可能是用戶的身高體重,過去買過的東西,購買偏好,他的學歷等等。物料數據就是說物品的價格、顏色、產地。如果是視頻的話,視頻的內容、標籤等等都屬於物料本身的數據。行為數據是指用戶和物料之間的交互。比如說用戶看了一個視頻,他點贊,收藏,投幣。這些都是用戶的行為數據。還有評論數據,第三方數據等等,可能不一定每個平臺每個產品都會有。但是基本上這三個數據,user的數據、item的數據、還有behavior的數據是一定要有的。當我們有了這三份數據之後,就會進入到數據加工存儲層。在這一層我們會做一些數據加工,比如說把用戶的特徵加工出來,把物料的特徵加工出來,把這個事件的特徵加工出來。再往上一層就是基於這些特徵去建模。我們剛才介紹了整個的推薦流程包含召回和排序這兩個重要的模塊。召回模塊中,可以有多個算法並行去做。
召回完之後你需要排序,也有很多算法,究竟選哪一種算法,後續第三節課再說。接下來,你要有一個新的策略,還不能把推薦結果直接拿到線上,要有一些過濾去重、AB測試、運營策略。比如說我昨天剛推薦給你一個小米手機,然後你就買了。我今天再推薦小米手機肯定是不合適的。最上層就是推薦業務,可以推薦一個廣告,可以推薦商品,也可以推薦用戶。比如說在社交應用中,可以把用戶推薦給用戶,讓他們互相關注。有了這一整套推薦架構,怎麼樣讓它去符合企業級推薦系統的四個基本要求,需要應用到一些雲產品。最常見的做法是,基於雲服務、雲生態去搭建這些模塊。
image.png

(三)基於PAI的推薦技術架構

在阿里雲這邊的整個的實現方案是這樣的。基於PAI的推薦平臺,在基礎數據層,我們可以提供給你網站的一些離線數據,可以存到RDS::MySQL這樣的一個數據庫裡。線上的一些行為數據,比如說你實時有一些點擊,有些關注,你可能想做一些實時的處理。你可以做Kafka。然後到上一層,數據加工層你可以用Flink做一個加工,產生一些實時的行為數據。生成了樣本之後,可以發到模型訓練層。在模型訓練層就會用到PAI的一些算法。最上面應用的時候,為了保證整個服務的彈性,我們推薦通過雲原生的方案去做,保證資源的彈性。最終在服務編排階段,你可以先調一下召回,拿到召回的結果,然後去重,拿到最終的一個給排序的樣本,然後排序的結果就會反饋給用戶。這是我們整體的技術架構。
image.png

(四)參考資料

最後,介紹一下我們給大家準備的一些資料。這第一個link它對應的是PAI團隊結合自身過去幾年在推薦領域的一些探索,總結了140頁的推薦業務的動手實踐文檔。沒有機器學習背景的人基於我們這些文檔,也可以在一週之內搭建一套企業級的推薦系統,大家如果感興趣可以去用一下。另外這一個是PAI的產品地址,我後面會基於這個產品介紹一些推薦算法。
image.png

Leave a Reply

Your email address will not be published. Required fields are marked *