推薦引擎的離線演算法和在線演算法初探

推薦引擎是阿里雲的一套推薦服務框架。大家可能在淘寶上很早就聽過「個性化推薦」、「千人千面」一類的詞，對於為什麼能把喜歡的寶貝準確得推給不同的買家感到好奇，希望自己也能有這樣一套推薦系統吧。這篇帖子，就以推薦引擎產品上的離線演算法和在線演算法給大家說明下，並且方便後續如果在產品使用中如果發現通用的計算規則不符合自己的場景的時候，需要做一些優化的時候，也能更好地指導怎麼調。

系統架構

推薦引擎是怎麼工作的，為什麼只需要提供一些用戶、商品、行為數據，就知道誰誰喜歡什麼呢?我們可以一起來看下文檔里的一個圖，推薦引擎的框架大概是這樣：

咱們先不討論API寫入和實時修正一段。數據從MaxCompute準備好，到最後能被調用，實時地生成推薦結果，需要經過2個步驟：要先在離線計算里計算出推薦結果，離線計算的結果會被保存到表格存儲里。第二步會通過在線演算法，對推薦結果進行加工並展示。所以，如果算的結果不對，比如推薦了個完全不相干的商品，那就查離線演算法。比如召回個數要調整，或如果召回數量過少用默認值去填充一類的需求，就要在在線演算法上下功夫（當然默認值的生成可能需要用到離線計算）。在線演算法和離線演算法是配合使用的，所以可以看到模板里也是配套的。

離線計算

我們從默認detail模板（detail_ofl）去了解離線演算法。打開這個演算法，可以看到這個演算法的流程圖是這樣：

這個圖裡的每個線表示任務的依賴。這樣看起來還不直觀，我做了下修改：

可以看到detail_ofl模板的離線計算其實是有2條主線，一條是通過crs_04和crs_02各自生成item_item_rec_list，最後通過st_cb_01整理成一張對外輸出的結果。另外一條是crs_05和crs_03生成user_item_rec_list，最後通過st_cb_02整理成一張結果表。item_item_rec_list表裡記錄了根據item來進行推薦的結果，可以理解成這兩個商品比較接近，比如啤酒和尿布的例子就是典型的item_item_rec的例子。而user_item_rec_list是針對用戶進行推薦的，比如說系統發現我和你都是跑步愛好者。有一天我買了雙不錯的鞋子，然後可以猜你可能也會喜歡。

在線計算

我們來看下detail_ofl配套的在線演算法，流程圖是：

這個圖比較簡單，先用mg_usr_itm_reclist把離線演算法的item-base和user-base推薦結果。item_item_rec_list的數據被放在前面，因為一般來說，根據item召回的結果數量會比較少但是相對比較準確。鑒於兩個union all後可能出現走item-base和user-base都會推薦同一個商品，於是接著做了個uniq_reclist進行去重。最後用一個get_top來設置召回個數（也就是最開始我們提到的問題）。

其他演算法

看好了detail模板，我們再來對比一下main模板，會發現更加簡單了。首頁推薦就是根據人進行推薦，沒有item的部分，所以其實就是detail模板的st_cb_02，計算user_item_rec_list線。對應的在線演算法里，沒有兩個表的結果的聚合去重，只有get_usr_based_rec來獲得user的召回結果，再過一下topn就好了。

然後我們再看下detail_dft，其實就是在detail_ofl基礎上，用simple_default_list計算默認的推薦列表。然後用對應的在線模板里的get_default_rec來補足。

最後我們再來看個演算法，就是快速入門裡的用電影數據進行電影推薦的例子，例子里針對對電影的評分，來篩選出每個人對電影的喜愛程度，這個數據需要用的是spl_grd_svd。而如果用了detail_ofl來算的話，會在數據離線計算的時候報錯。對比一下兩個模板，可以發現spl_grd_svd開始用的是grade_based_sm，而detail_ofl用的是ig_sm_02。ig_sm_02用的是click,search_click,consume,use,read,collect,comment,share,like,view，而grade_based_sm只選擇bhv_type=grade對應的bhv_amt作為評分進行計算。如果針對電影數據使用detail_ofl，發現裡面只有grade的操作，沒有其他的行為，會因為沒有找到用戶行為數據而報錯。

演算法類目

可以看到演算法的框架是定的，如果後面需要修改，也不是完全推翻重頭做起。可以選一個模板在其基礎上做修改。每個演算法都有各自的數據輸入、輸出，有一些演算法其實只是演算法的內部不一樣，輸入輸出，用在什麼上下游一樣。所以後面如果要根據自己的實際數據寫自定義演算法，可以先根據前面提到的，找到其中哪個步驟覺得演算法還可優化的，然後針對地寫個演算法替換。是不是看起來很像是在搭積木，用一個同樣形狀的積木來代替以前的組件。這樣一個個相同的積木，就叫做一個類目。在自定義演算法的時候，需要設置演算法的類目，也正是這個意思。

經過以上的介紹，大家應該對推薦引擎的計算邏輯有一個大致的理解。不過實踐出真知，紙上談兵不如動手做一個，你說呢~

本文使用的產品涉及大數據計算服務(MaxCompute），地址為https://www.aliyun.com/product/odps

原文

推薦閱讀：