開發與維運

推薦系統線上服務編排及架構說明

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

一、在線推理服務-架構說明

在如何構建企業級推薦系統系列課程中,前兩節課我們分別介紹了召回算法及架構、排序算法及架構。本節課我們會介紹一下如何對排序和召回算法的結果做一個服務編排,以及最終我們的模型跟現場業務是如何對接的。首先,我們介紹一下整個的框架,用戶的業務場景,特別是互聯網的推薦業務,它的高峰基本上會集中在中午和晚上。這個時候如何減少咱們的資源消耗。比如說,你的高峰需要消耗10臺機器,低谷可能用1臺機器。如果你沒有彈性的機制,在線下買,一定要買10臺機器才能滿足服務高峰的一個需求。但是,如果你使用了雲上的服務,就可以把這一套東西做到彈性。相比於你一直擁有10臺機器,會節約很多成本,這是一個推薦業務需要考慮的場景。所以在服務編排階段通常會採用雲上的這套架構去做,來應對它的業務的一個潮汐效應。
另外一個要解決的問題就是,召回和排序這樣的一個流程究竟該怎麼創建起來。我們的方案是,基於高擴展彈性業務場景,採用阿里雲ACK構建整體推理架構。調用流程分為3步。第一步,多路召回:物品協同過濾,語義召回,熱門及運營策略召回取回上千條候選集。第二步,曝光去重:基於該用戶閱讀歷史,去掉已經曝光內容,去掉基於運營策略不能推薦的內容。第三步,排序:推理模塊調用排序過程時根據用戶ID及物料ID,獲取用戶特徵及物料特徵後,分批調用PAI-EAS服務返回排序結果。右面這張圖其實講的是排序PAI-EAS在線推理服務的一個在線監控的能力。就是你要觀察排序模型的一個水位,進行動態的擴容、縮容,防止你的RT過高,或者QPS達不到業務的需求。這是整個的在線服務編排的框架。
image.png

二、線上多目標問題

最終模型上線的時候,我們還會面臨一個問題。我們設計整個架構,有的時候並不是單一目標,而是多目標的。就拿文章或視頻推薦為例,很多的客戶都希望說,不光是我推薦的視頻被用戶點擊了,用戶還需要多看一會兒,這樣的話就會規避一些標題黨。比如說有些視頻把標題起得很吸引人,但其實內容很浮躁。用戶點進去看一眼覺得沒意思就走了,這樣的話他整個的使用體驗也不好。所以它可能是多目標的,既要他點擊,也要他多看一會。針對這樣的一個多目標情況,我們該怎麼設計整套的方案,怎麼去編排整套的推薦召回應用邏輯,有兩種方案。一種是說多模型解決多目標問題。假設就是點擊和時長這兩個目標,你可以有一套推薦召回模塊專門針對點擊。
另一塊專門針對使用時長去做訓練。這兩個結果你把它融合一下,得到最終的推薦結果。但代價就會比較大,你要同時維護兩個系統,而且二者的比例也不好去量化。方案二是合併多目標成單模型,是目前採用得比較多的一個方案,也是效果相對來講會比較好的一個方案。你把目標一和目標二這兩個目標先融合成一個目標。比如說你把是否點擊和觀看時長按照一個比例去壓縮下,把它都放到0~1之間。不點擊就0,點擊就是1。然後你把觀看時長去做一個歸一化,把整個時間都縮小到0~1的區間去。這樣,你整個的區間就變成了0~2,變成一個單目標的數值。這樣的話你就可以針對這一個目標去訓練你的召回、排序模型,從而拿到最終的結果。這樣做的好處是你只需要維護一套推薦業務的建模流程,會比較方便維護,最後的效果也通常是方案二好一些。
image.png

三、參考資料

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

Leave a Reply

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