(相關資料圖)

一、背景

目前，推薦算法部支持了主站、企業業務、全渠道等20+業務線的900+推薦場景，通過梳理大促運營、各垂直業務線推薦場景的共性需求，對現有推薦算法能力進行沉淀和積累，并通過算法PaaS化打造通用化的推薦能力，提升各業務場景推薦賦能效率，高效賦能業務需求。 為什么是PaaS化：首先，我們認為PaaS化是一個比較好的解決辦法和方案，因為它提供了一種解決超級公司復雜業務的可變化、可擴展、可復用能力的基礎框架，在這樣的框架下，可以極大地釋放重復勞動力，實現業務的高效提升；其次，我們也看到一些行業中的其它玩家，他們也是在自己的業務中臺基礎上進行PaaS化，并通過PaaS化提供的能力不斷的孵化自己的創新項目，去減少他們的人力投入，減少他們的投入成本，而且他們還推出了很多用于商用的PaaS化工具，為實現更大的社會價值去創造機會；因此，我們認為PaaS化應當是我們當前會選擇的一個比較好的解決問題方法； 如何助力推薦業務能力提升：通過梳理推薦場景下的共性需求，在可變化、可擴展、可復用能力的基礎框架內，我們對業務需求進行分類和能力抽象，提供階梯化的應對策略；針對通用類需求，我們提供一站式個性化推薦能力，滿足業務快速接入的訴求；針對定制類需求，通過打造高效易用的PaaS化工具，一方面，減少算法人力的投入，另一方面，縮短業務需求交付的周期；

二、方案設計

在對推薦業務需求梳理的過程中，我們將業務方訴求歸結為以下兩個大類： 新增推薦位類業務需求 依據推薦場景劃分，大致可以分為首推、我京、商詳、購物車、短視頻、直播、頻道等推薦場景的接入； 依據個性化推薦能力劃分，大致可以分為數據接入、召回、排序、過濾/調權、多樣性、渲染等推薦算法模塊以及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.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 啄木鳥使用 啄木鳥建設好交付對應的算法人員進行使用，我們也提供了詳細的使用手冊供新人學習；

四、實踐經驗總結

在推薦算法PaaS化探索與實踐的過程中，我們作為能力的提供者和能力的使用者，一方面從能力提供者的角度出發，總結梳理出需要提供的PaaS化工具，另一方面，從能力使用者的角度出發，去評估工具是否高效易用； 作為能力的提供者：通過對業務需求的梳理及PaaS化建設者長期的業務經驗，立足現有推薦系統，通過對推薦算法的組件化，重新認識系統，重新規劃流程； 作為能力的使用者：從被動到主動，切實感知到工具對效率的提升，善于利用工具，通過PaaS化工具，輕輕松松完成復雜的業務需求，只要想干，就可以自己把握需求交付的節奏；

五、未來工作展望

我們希望在長期主義的復利下，將推薦算法PaaS化積累成一個奇跡；基于我們目前對業務需求的認知，未來，我們將從如下幾個方面不斷深耕： 5.1 場景模板分層個性化推薦能力建設 在未來一段時間里，我們會針對模板的個性化能力進行升級，基于現在基礎版的現狀下，提供進階版及高階版能力，滿足業務更多樣的訴求； 5.2 打造高效易用的PaaS化工具 5.2.1 單素材服務能力建設 首先需要闡述一下我們為什么要建設單素材服務能力，一個重要的原因是場景模板僅能支持新增推薦位需求，且該類需求不能很復雜，而對于復雜的新增推薦位需求或者是已有推薦位的迭代優化場景模板無法提供支持；基于此，我們提出了服務復用的概念，具體來說，我們計劃將單素材打造成一個一個的服務，算法人員專注的對服務進行全方位優化，而需要進行效果優化的新增推薦位需求以及已有推薦位的迭代優化則通過服務進行賦能，此舉不僅可以減少算法人力的投入，還可縮短業務需求交付的周期； 5.2.2 算法組件平臺化進一步升級 為了提升推薦算法PaaS化能力使用者的使用體驗，我們計劃將部分通用的算法能力平臺化，以擺脫目前仍然需要算法人員手動復制的操作工作，真正實現點選式的操作方法，因此，后續我們也會聯合平臺側，共同打造這樣的平臺能力，進一步釋放算法人員的重復勞動力。 ?-end-

關鍵詞：