優雅地實作實時“看過不再推薦”

​ 在阿裡雲推薦引擎的系統設定裡，線上api擷取推薦結果（以下簡稱api）和實時算法是互相并列而又可以互動的兩條線。

​ 就“并列”而言，是因為api是由後端系統在使用者進入一個需要展現推薦清單的前端頁面時進行調用，而實時算法是由客戶定義的使用者所有有意義行為（包括進入推薦頁面）、也即日志觸發，一般來說使用者的行為日志量會遠大于api請求量。從系統設定上來說，可以看到線上api的組成算法和實時算法處于兩個不同的配置頁。

​ 而之是以說“可以互動”，是由于使用者的實時行為日志可以有效地指導api進行調整，從系統設定上來說，就是通過線上資料共享讀寫完成。這裡舉兩個小例子：

​ 1）一個線上購物網站，假設推薦引擎通過離線模組化，已了解到使用者的興趣集中在男裝、電子産品、運動用品三個類目，而這時候實時行為告訴我們目前使用者正在大量浏覽運動器械，那麼推薦系統就可以有導向性地将推薦結果中隸屬于運動用品的項目在展現位中适當提前。

​ 2）一個線上短視訊app，業務規則告訴我們客戶基本不會看相同的視訊兩次及以上，而實時行為告訴我們該使用者目前已經看過視訊a，那麼推薦系統就需要及時地在推薦結果中把視訊a去掉，以免造成重要資源位的閑置和浪費。

​ 本文将通過一個例子指導您“優雅地”實作“看過不再推薦”的業務邏輯。

​ 請注意以上兩段代碼中getkey和str2arr方法的一緻性。

​ 之是以本文标題修飾以“優雅”二字，作者私認為是由于上面的做法實作了api請求和實時日志兩條線的解耦，二者分工更加明确，實時日志為api提供資源，api一端讀取資源并決定最終的推薦邏輯，業務邏輯更加清晰。

​ 作者在分析一些已有客戶送出的代碼時發現，有一些做法是簡單地從使用者的個性化推薦結果中進行實時過濾，實作上來說就是在實時修正算法中直接修改使用者的個性化結果。這個做法的一個比較明顯的缺陷在于，實際應用中決定最終給使用者展現哪些推薦結果的邏輯可能是非常複雜的，除了個性化結果外，可能還會有一些半個性化結果（如針對使用者标簽的推薦）、營運規則（如人工強制置頂）、各種抄底政策（即使用者無個性化推薦結果的情況下展現一些非個性化推薦，比如topn規則），那麼按照以上做法勢必會導緻過濾不完全的情況存在。