【實踐篇】推薦演演算法PaaS化探索與實踐

作者：京東零售崔寧

1. 背景說明

目前，推薦演演算法部支援了主站、企業業務、全渠道等20+業務線的900+推薦場景，通過梳理大促運營、各垂直業務線推薦場景的共性需求，對現有推薦演演算法能力進行沉澱和積累，並通過演演算法PaaS化打造通用化的推薦能力，提升各業務場景推薦賦能效率，高效賦能業務需求。

為什麼是PaaS化：首先，我們認為PaaS化是一個比較好的解決辦法和方案，因為它提供了一種解決超級公司複雜業務的可變化、可延伸、可複用能力的基礎框架，在這樣的框架下，可以極大的釋放重複勞動力，實現業務的高效提升；其次，我們也看到一些行業中的其它玩家，他們也是在自己的業務中臺基礎上進行PaaS化，並通過PaaS化提供的能力不斷的孵化自己的創新專案，去減少他們的人力投入，減少他們的投入成本，而且他們還推出了很多用於商用的PaaS化工具，為實現更大的社會價值去創造機會；因此，我們認為PaaS化應當是我們當前會選擇的一個比較好的解決問題方法；
如何助力推薦業務能力提升：通過梳理推薦場景下的共性需求，在可變化、可延伸、可複用能力的基礎框架內，我們對業務需求進行分類和能力抽象，提供階梯化的應對策略；針對通用類需求，我們提供一站式個性化推薦能力，滿足業務快速接入的訴求；針對客製化類需求，通過打造高效易用的PaaS化工具，一方面，減少演演算法人力的投入，另一方面，縮短業務需求交付的週期；

2. 方案設計

在對推薦業務需求梳理的過程中，我們將業務方訴求歸結為以下兩個大類：

新增推薦位類業務需求

依據推薦場景劃分，大致可以分為首推、我京、商詳、購物車、短視訊、直播、頻道等推薦場景的接入；
依據個性化推薦能力劃分，大致可以分為資料接入、召回、排序、過濾/調權、多樣性、渲染等推薦演演算法模組以及AB實驗、資料分析能力；
依據運營訴求劃分，大致可以分為提權，定投，非定投，定坑等扶持能力；

已有推薦位推薦策略迭代優化類業務需求

效果提升類業務需求：大致可以分為新增商品底池、召回新增資料來源、業務標籤/特徵因子接入模型、扶持類、資料分析等；
使用者體驗類業務需求：大致可以分為調權/過濾、負反饋、多樣性排序、新穎性、多素材穿插等；
可運營類需求：大致可以分為特殊商品流量扶持、賽馬機制、提權，定投，定坑等可運營能力；

為了更高效的支援上述業務需求，推薦演演算法PaaS化圍繞資料/演演算法元件/資料分析/運算元/場景模板/服務6個PaaS化方向進行建設，以縮短需求交付週期為目標進行建設，切實提升使用者感知。

2.1 推薦演演算法PaaS化能力分類

作為個性化推薦能力的提供者，我們希望通過業務賦能技術，通過推薦演演算法PaaS化，將推薦系統透明的展示給大家，在重新認識推薦系統的基礎之上，更好的推演未來；我們將推薦演演算法PaaS化分為資料/演演算法元件/資料分析/運算元/場景模板/服務共6個一級能力、20個二級能力，具體如下

上述分類是基於我們現階段對業務需求的認知，隨著推薦演演算法PaaS化的不斷推進，定義及分類也會不斷遷移；

2.2 推薦演演算法PaaS化能力建設

2.2.1 推薦演演算法元件化

推薦演演算法元件化是平臺化、設定化的前置步驟，通過元件化，我們可以將演演算法能力視覺化，讓沉澱在程式碼中的一些資訊展示在公眾面前，讓演演算法能力成為一種真正可傳承的資產，高效賦能業務需求；具體而言，我們通過將演演算法能力抽象及封裝，整合在一個可執行的程式碼包中，使用者通過演演算法元件的介紹及使用說明，就可以「插拔式」的應用在自己的業務領域；

演演算法元件化建設主要包含兩部分，一是推薦演演算法PaaS化能力建設者將推薦演演算法能力進行整合，二是推薦演演算法PaaS化能力使用者將演演算法元件應用在任何想應用的場景中，而且使用者自己就可以把握需求交付的節奏；

推薦演演算法元件化示意圖

2.2.2 通用演演算法能力平臺化

平臺化的主要目的是簡化推薦演演算法元件使用的複雜度，因此，我們對平臺工具的要求是具備可用、可視、可改的特點；值得注意的是，平臺化這裡我們可以分為兩個大類，其一是推薦能力全鏈路的平臺化，目的是能夠快速支援新增推薦位這類業務需求；其二是推薦演演算法模組的平臺化，通過這樣的平臺工具，希望能夠快速支援已有推薦位推薦策略迭代優化類業務需求；

針對推薦能力全鏈路的平臺化，我們和產品、架構、平臺側合作，通過打造豐富的推薦場景模板，並提供通用的個性化分發能力，滿足業務快速接入的訴求；具體來說，對於業務方對不同推薦場景接入的不同訴求，PaaS化專案組已經建設了諸如全站商品綜合推薦、主sku相似相關推薦、業務靈活底池推薦、全渠道門店+商品推薦、小助手商品推薦等多類通用模板，在這些模板上，推薦演演算法PaaS化依據可變化、可複用的基礎邏輯，通過提供豐富的推薦策略供業務方選擇使用，覆蓋更多新增推薦位需求；

場景模板列表示意圖

針對推薦演演算法模組的平臺化，我們計劃和平臺側合作，通過建設一批提效工具，提高演演算法同學的工作效率，縮短需求的交付週期；

2.2.3 通用演演算法策略設定化

為了提升演演算法人員支援業務需求的效率，立足目前的推薦系統，同推薦架構合作，完成建設通用運算元庫，包括常用的取數、召回、排序、過濾、多樣性等運算元；在未來，這批通用運算元可以直接進入小流量實驗驗證效果，降低運算元設定的成本，提高程式碼的複用度，達到縮短需求交付週期的目標；

實現通用演演算法策略設定化前後的流程對比

2.2.4 客製化化演演算法策略低程式碼開發

在支援業務需求的過程中，我們發現一個小小的運算元開發也要耗費演演算法人員大量的時間，包括不限於：前期的開發溝通、策略的開發、環境部署、策略的驗證及運算元上線等，我們希望將開發流程進行精簡，從而達到提效的目標，基於此，同推薦架構、平臺達成共識，建設面向演演算法等專業人員的低程式碼開發工具，使客製化化需求能夠快速的通過低程式碼環節進行快速開發和釋出上線；

整體思路，參考巨量資料的 easy studio 系統

2.2.5 推薦演演算法PaaS化工具建設

這裡我們主要考慮客製化類需求，比如召回新增資料來源、敏感商品過濾、case排查工具等；對於客製化類需求，我們希望提供一些高效易用的PaaS化工具，一方面，解放演演算法的重複勞動力，另一方面，縮短業務需求交付的週期；

3. 落地實施

3.1 案例一場景模板個性化推薦能力建設

3.1.1 場景模板開發

場景模板作為承接新增推薦位需求的一種工具，直接開放給業務方使用，針對不同推薦場景，我們建設了豐富的模板供業務方選擇使用，包括：全站商品綜合推薦、商詳、購物車、直播、短視訊等，在每個模板上，我們設定了基礎的推薦分發策略，業務方可以根據自己的需求選擇使用哪些推薦策略；下面以商品聚合tab推薦為例，介紹模板個性化推薦能力的落地實施情況；

首先，在模板建設的前期，我們會和產品共同確認類似需求的量級，作為評估是否建設模板的依據；比如說，我們評估商品聚合tab推薦這類需求在每個季度平均會存在3-4個，且該類需求對演演算法能力的要求基本相似，因此，我們認為商品聚合tab推薦是屬於通用類且比較頻繁的一類需求，需要建設模板高效承接該類需求；

其次，作為演演算法人員，我們需要針對該類需求進行演演算法能力的梳理，通過過去十幾個類似需求對推薦能力的要求，大致可以整理出一版功能完善，覆蓋度極高的演演算法方案；以商品聚合tab推薦為例，在資料接入時，大部分需求中，業務方提供的資料是包含商品池(did)、虛擬類目/品牌(vcateid)及真實類目/品牌(cate_id)的底池資料，而在召回時，往往通過冷啟和畫像兩路召回完成虛擬類目/品牌及真實類目/品牌的召回，再通過一個線性排序模型完成rank階段的打分，輔以過濾、調權及多樣性策略完成整個推薦分發能力的搭建，通過上述描述不難發現，如果大部分需求都是按照上述流程推進，那我們就可以設計完善的演演算法方案高效承接類似需求；

然後，在演演算法方案評審完成的基礎上，由架構側完成功能的開發，由平臺側完成前端頁面的開發；

最後，當再存在類似業務需求時，我們對業務方開放模板能力，業務方自己就可以通過點選式的頁面完成需求，且這個過程的進度均由業務方自己把控；

場景模板開發流程圖

3.1.2 全自動召回詞表/索引庫能力建設

在我們承接業務需求的過程中，大部分情況下，每個業務方都有自己的商品底池，面對不同的商品底池，我們需要根據商品底池的變化動態的調整召回詞表或者索引庫，假如我們想要個性化分發能力完全自動化，那就需要打造一套新的召回詞表/索引庫構建工具，基於此，我們聯合平臺側共同提出了一鍵底池/索引庫建立落地方案，具體來說，演演算法人員將模板上所需的所有召回詞表/索引庫生產指令碼進行抽象封裝，預留入參及出參，平臺側通過前端介面獲取具體召回詞表/索引庫建立的命令，並將該命令作為入參輸入演演算法人員預先封裝好的程式碼包，為了每天定時更新任務，同時自動建立BDP排程任務，程式碼包的出參通過DUCC回傳給平臺側，作為後續建立詞表/索引庫的依據，從而完成召回詞表或者索引庫的全自動化建立；

一鍵底池/索引庫建立落地實施

3.1.3 多業務排序模型支援

為了覆蓋更多業務需求，在排序模組我們主要考慮不同業務模式下對排序能力的要求，比如，在下沉場景，更多的是需要提升UCVR指標，而主站的一些業務需求希望提升使用者的UCTR指標，因此，為了兼顧多樣的業務需求，我們梳理了三個常用的模型，分別是主站的多領域排序模型，特價版的下沉排序模型以及ToB的企業排序模型，將上述三個模型整合到每個模板裡，並提供每個模型的介紹及使用說明，業務方可以根據需求的具體內容進行選擇；

排序模型選擇

3.2 案例二打造高效易用的PaaS化工具

工具的合理使用，不僅可以提高我們的工作效率，還可以使我們的工作變得更加輕鬆；這裡以我們在使用者體驗中打造的啄木鳥為例，為大家講解PaaS化工具在業務中的應用；（名詞解釋之啄木鳥：支援離線過濾/解禁自主設定的平臺化工具）

3.2.1 需求梳理

在使用者體驗模組，常常有業務需求需要對商品、類目、敏感詞等進行過濾，或者在某一段時間內進行過濾，時間過後要求再釋放出來；在沒有打造啄木鳥之前，我們接到類似需求後，會手動將商品、類目或者是敏感詞寫到一個文字中，然後再將文字push到hdfs的某一個路徑下，第二天的BDP排程任務執行時，會更新資料表，達到過濾或者釋放的目的；觀察上述流程不難發現，手動修改文字極易導致出錯，無心的刪除或者增加可能就會導致第二天的排程任務掛掉，不穩定；另外，有新人接手這樣的需求後，培訓成本極高，需要手把手教幾遍才敢把這樣的工作交給他，操作難度大；

為了解決這樣的難題，我們計劃打造一款高效易用的PaaS化工具，這樣的工具可以提供穩定的增刪改查，而且還要操作簡單，最好是一看就知道怎麼操作，基於這樣的想法，我們聯合平臺一起打造了啄木鳥；

3.2.2 啄木鳥的設計及開發

設計思路：

通過jrec平臺，能夠將所有的離線過濾/釋放進行paas化設定，平臺需要具備如下能力：

啄木鳥平臺提供過濾、釋放設定入口，由jrec平臺提供；
在平臺設定的長期規則可以下沉至離線，降低對線上服務資源的佔用；
離線過濾能夠靈活設定，且支援離線釋放，減少手工操作成本；

方案設計：

整體方案設計如下圖所示，通過平臺WEB介面設定後，資料經DUCC流轉到離線計算任務部分，待離線計算任務完成後，導數到jimdb進行快取，線上設定過濾服務或者ps的過濾運算元后即可完成商品、類目或者是敏感詞的過濾與釋放；

啄木鳥落地實施

3.3.3 啄木鳥使用

啄木鳥建設好交付對應的演演算法人員進行使用，我們也提供了詳細的使用手冊供新人學習；

4. 實踐經驗總結

在推薦演演算法PaaS化探索與實踐的過程中，我們作為能力的提供者和能力的使用者，一方面從能力提供者的角度出發，總結梳理出需要提供的PaaS化工具，另一方面，從能力使用者的角度出發，去評估工具是否高效易用；

作為能力的提供者：通過對業務需求的梳理及PaaS化建設者長期的業務經驗，立足現有推薦系統，通過對推薦演演算法的元件化，重新認識系統，重新規劃流程；

作為能力的使用者：從被動到主動，切實感知到工具對效率的提升，善於利用工具，通過PaaS化工具，輕輕鬆鬆完成複雜的業務需求，只要想幹，就可以自己把握需求交付的節奏；

5. 未來工作展望

我們希望在長期主義的複利下，將推薦演演算法PaaS化積累成一個奇蹟；基於我們目前對業務需求的認知，未來，我們將從如下幾個方面不斷深耕：

5.1 場景模板分層個性化推薦能力建設

在未來一段時間裡，我們會針對模板的個性化能力進行升級，基於現在基礎版的現狀下，提供進階版及高階版能力，滿足業務更多樣的訴求；

5.2 打造高效易用的PaaS化工具

5.2.1 單素材服務能力建設

首先需要闡述一下我們為什麼要建設單素材服務能力，一個重要的原因是場景模板僅能支援新增推薦位需求，且該類需求不能很複雜，而對於複雜的新增推薦位需求或者是已有推薦位的迭代優化場景模板無法提供支援；基於此，我們提出了服務複用的概念，具體來說，我們計劃將單素材打造成一個一個的服務，演演算法人員專注的對服務進行全方位優化，而需要進行效果優化的新增推薦位需求以及已有推薦位的迭代優化則通過服務進行賦能，此舉不僅可以減少演演算法人力的投入，還可縮短業務需求交付的週期；

5.2.2 演演算法元件平臺化進一步升級

為了提升推薦演演算法PaaS化能力使用者的使用體驗，我們計劃將部分通用的演演算法能力平臺化，以擺脫目前仍然需要演演算法人員手動複製的操作工作，真正實現點選式的操作方法，因此，後續我們也會聯合平臺側，共同打造這樣的平臺能力，進一步釋放演演算法人員的重複勞動力；