作者：京東零售 崔寧

1. 背景說明

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

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

2. 方案設計

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

• 新增推薦位類業(yè)務需求

1. 依據(jù)推薦場景劃分，大致可以分為首推、我京、商詳、購物車、短視頻、直播、頻道等推薦場景的接入；

2. 依據(jù)個性化推薦能力劃分，大致可以分為數(shù)據(jù)接入、召回、排序、過濾/調權、多樣性、渲染等推薦算法模塊以及AB實驗、數(shù)據(jù)分析能力；

3. 依據(jù)運營訴求劃分，大致可以分為提權，定投，非定投，定坑等扶持能力；

• 已有推薦位推薦策略迭代優(yōu)化類業(yè)務需求

1. 效果提升類業(yè)務需求：大致可以分為新增商品底池、召回新增數(shù)據(jù)源、業(yè)務標簽/特征因子接入模型、扶持類、數(shù)據(jù)分析等；

2. 用戶體驗類業(yè)務需求：大致可以分為調權/過濾、負反饋、多樣性排序、新穎性、多素材穿插等；

3. 可運營類需求：大致可以分為特殊商品流量扶持、賽馬機制、提權，定投，定坑等可運營能力；

為了更高效的支持上述業(yè)務需求，推薦算法PaaS化圍繞數(shù)據(jù)/算法組件/數(shù)據(jù)分析/算子/場景模板/服務6個PaaS化方向進行建設，以縮短需求交付周期為目標進行建設，切實提升使用者感知。

2.1 推薦算法PaaS化能力分類

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

上述分類是基于我們現(xiàn)階段對業(yè)務需求的認知，隨著推薦算法PaaS化的不斷推進，定義及分類也會不斷遷移；

2.2 推薦算法PaaS化能力建設

2.2.1 推薦算法組件化

推薦算法組件化是平臺化、配置化的前置步驟，通過組件化，我們可以將算法能力可視化，讓沉淀在代碼中的一些信息展示在公眾面前，讓算法能力成為一種真正可傳承的資產(chǎn)，高效賦能業(yè)務需求；具體而言，我們通過將算法能力抽象及封裝，集成在一個可運行的代碼包中，使用者通過算法組件的介紹及使用說明，就可以“插拔式”的應用在自己的業(yè)務領域；

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

推薦算法組件化示意圖

2.2.2 通用算法能力平臺化

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

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

場景模板列表示意圖

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

2.2.3 通用算法策略配置化

為了提升算法人員支持業(yè)務需求的效率，立足目前的推薦系統(tǒng)，同推薦架構合作，完成建設通用算子庫，包括常用的取數(shù)、召回、排序、過濾、多樣性等算子；在未來，這批通用算子可以直接進入小流量實驗驗證效果，降低算子配置的成本，提高代碼的復用度，達到縮短需求交付周期的目標；

實現(xiàn)通用算法策略配置化前后的流程對比

2.2.4 定制化算法策略低代碼開發(fā)

在支持業(yè)務需求的過程中，我們發(fā)現(xiàn)一個小小的算子開發(fā)也要耗費算法人員大量的時間，包括不限于：前期的開發(fā)溝通、策略的開發(fā)、環(huán)境部署、策略的驗證及算子上線等，我們希望將開發(fā)流程進行精簡，從而達到提效的目標，基于此，同推薦架構、平臺達成共識，建設面向算法等專業(yè)人員的低代碼開發(fā)工具，使定制化需求能夠快速的通過低代碼環(huán)節(jié)進行快速開發(fā)和發(fā)布上線；

整體思路，參考大數(shù)據(jù)的 easy studio 系統(tǒng)

2.2.5 推薦算法PaaS化工具建設

這里我們主要考慮定制類需求，比如召回新增數(shù)據(jù)源、敏感商品過濾、case排查工具等；對于定制類需求，我們希望提供一些高效易用的PaaS化工具，一方面，解放算法的重復勞動力，另一方面，縮短業(yè)務需求交付的周期；

3. 落地實施

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

3.1.1 場景模板開發(fā)

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

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

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

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

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

場景模板開發(fā)流程圖

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

在我們承接業(yè)務需求的過程中，大部分情況下，每個業(yè)務方都有自己的商品底池，面對不同的商品底池，我們需要根據(jù)商品底池的變化動態(tài)的調整召回詞表或者索引庫，假如我們想要個性化分發(fā)能力完全自動化，那就需要打造一套新的召回詞表/索引庫構建工具，基于此，我們聯(lián)合平臺側共同提出了一鍵底池/索引庫創(chuàng)建落地方案，具體來說，算法人員將模板上所需的所有召回詞表/索引庫生產(chǎn)腳本進行抽象封裝，預留入?yún)⒓俺鰠?，平臺側通過前端界面獲取具體召回詞表/索引庫創(chuàng)建的命令，并將該命令作為入?yún)⑤斎胨惴ㄈ藛T預先封裝好的代碼包，為了每天定時更新任務，同時自動創(chuàng)建BDP調度任務，代碼包的出參通過DUCC回傳給平臺側，作為后續(xù)創(chuàng)建詞表/索引庫的依據(jù)，從而完成召回詞表或者索引庫的全自動化創(chuàng)建；

一鍵底池/索引庫創(chuàng)建落地實施

3.1.3 多業(yè)務排序模型支持

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

排序模型選擇

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

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

3.2.1 需求梳理

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

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

3.2.2 啄木鳥的設計及開發(fā)

設計思路：

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

1. 啄木鳥平臺提供過濾、釋放配置入口，由jrec平臺提供；

2. 在平臺配置的長期規(guī)則可以下沉至離線，降低對線上服務資源的占用；

3. 離線過濾能夠靈活配置，且支持離線釋放，減少手工操作成本；

方案設計：

整體方案設計如下圖所示，通過平臺WEB界面配置后，數(shù)據(jù)經(jīng)DUCC流轉到離線計算任務部分，待離線計算任務完成后，導數(shù)到jimdb進行緩存，線上配置過濾服務或者ps的過濾算子后即可完成商品、類目或者是敏感詞的過濾與釋放；

啄木鳥落地實施

3.3.3 啄木鳥使用

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

4. 實踐經(jīng)驗總結

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

作為能力的提供者：通過對業(yè)務需求的梳理及PaaS化建設者長期的業(yè)務經(jīng)驗，立足現(xiàn)有推薦系統(tǒng)，通過對推薦算法的組件化，重新認識系統(tǒng)，重新規(guī)劃流程；

作為能力的使用者：從被動到主動，切實感知到工具對效率的提升，善于利用工具，通過PaaS化工具，輕輕松松完成復雜的業(yè)務需求，只要想干，就可以自己把握需求交付的節(jié)奏；

5. 未來工作展望

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

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

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

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

5.2.1 單素材服務能力建設

首先需要闡述一下我們?yōu)槭裁匆ㄔO單素材服務能力，一個重要的原因是場景模板僅能支持新增推薦位需求，且該類需求不能很復雜，而對于復雜的新增推薦位需求或者是已有推薦位的迭代優(yōu)化場景模板無法提供支持；基于此，我們提出了服務復用的概念，具體來說，我們計劃將單素材打造成一個一個的服務，算法人員專注的對服務進行全方位優(yōu)化，而需要進行效果優(yōu)化的新增推薦位需求以及已有推薦位的迭代優(yōu)化則通過服務進行賦能，此舉不僅可以減少算法人力的投入，還可縮短業(yè)務需求交付的周期；

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

為了提升推薦算法PaaS化能力使用者的使用體驗，我們計劃將部分通用的算法能力平臺化，以擺脫目前仍然需要算法人員手動復制的操作工作，真正實現(xiàn)點選式的操作方法，因此，后續(xù)我們也會聯(lián)合平臺側，共同打造這樣的平臺能力，進一步釋放算法人員的重復勞動力；文章來源地址http://www.zghlxwxcb.cn/news/detail-609017.html

到了這里，關于【實踐篇】推薦算法PaaS化探索與實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！