服務API調用統一投放接口獲取推薦數據，投放接口解析請求參數，組裝成下游推薦策略參數，對返回的推薦結果，拼裝打點參數。為了實現推薦算法的在線對比，接口實現中接入了AB實驗系統，它根據指定策略將上游請求按指定比例進行分流，通過實驗配置，靈活控制不同流量的實驗策略，算法工程師在線試驗多個算法效果，極大的提升了推薦算法的迭代速度，優化推薦效果。 推薦策略模板是整個推薦投放服務實施的核心，監聽動態配置服務，通過配置參數變更來驅動各類模板更新，迭代業務。推薦策略流程：入參補全 -> 數據召回 -> 精排 -> 格式化 -> 推薦數據補全。入參擴展模板，對入參做補充、修改，簡化業務邏輯實現；業務模板，實現推薦策略主邏輯，由各類召回組件模板和精排調用組成(可選)，一個業務模板中可以包含多個召回組件模板，組成數據召回鏈（實時點擊偏好 -> 離線偏好 -> 店鋪偏好 -> 類目偏好 -> …）；數據組件模板，通過配置從不同的數據源召回和過濾數據；數據補全模板，按業務模板召回的推薦數據項ID補全詳細的字段值；格式化模板，根據展現層樣式需求，將推薦結果封裝成展現層可加載渲染的數據格式。對于已實現的推薦策略和能夠使用現有模板組裝的推薦策略，都可以在動態配置服務平臺上通過配置發布快速實現業務迭代和新增，一定程度上實現了代碼簡化，提高業務開發迭代效率。 推薦策略 推薦策略是整個推薦邏輯的核心，比如猜你喜歡場景，有用戶實時特征做相關性的召回策略，也有用戶離線特征的相關性召回策略。并且按照一定的配比merge出結果集，再調用排序系統的lr模型做點擊率預估，這些都是需要寫在策略腳本里。 推薦存儲 主要承載了用戶特征以及離線推薦結果集，存儲系統對讀寫性能要求非常高。 1. 整條推薦鏈路希望在50ms-100ms內完成。一次復雜的推薦請求會請求上百次（以存儲中的key為單位）存儲數據，存儲需要在1ms內返回。 2. 對時延要求比較高，比如需要收集用戶的曝光行為數據做降權，同時曝光數據的量非常大，對內存有挑戰。 排序系統 排序系統的職責是對候選集進行排序，其中核心點在于模型和特征，理想情況下系統盡可能支持多的模型和特征，但是在線計算需要較小的時延，這就要求系統要平衡效果和性能，前期推薦系統可以支持LR和GBDT兩種排序模型。 線性模型公式 x是特征，θ是權重，一個模型通常有幾十維特征，這些特征的計算和存儲就成為系統最大的挑戰。 1. 控制候選集數量在千級別，候選集增長整體計算就比較慢，rt也會上升。 2. 實體（商品）特征本地存儲，每次需要排序特定數量商品，本地存儲可以極大緩解網絡壓。 3. 針對內存瓶頸，將用戶相關特征遷移到遠程，考慮每次查詢只會查幾次用戶特征數據，開銷不大。 4. 并行計算，復雜模型下，組裝特征和計算還是比較費時，為了提升rt系統進行并行計算，充分利用cpu的資源，在系統容量不變的情況下提升rt。

總結

個性化推薦所取得的成就是一個“意料之外卻情理之中”的結果。個性化用戶體驗將是大勢所趨，從搜索走向發現(推薦)，通過搜索滿足用戶主動表達的需求，通過推薦挖掘滿足用戶的潛在需求。市場營銷的核心是用戶體驗，而用戶體驗的極致是個性化，滿足每一位用戶的不同需求，以人為本的電子商務才能夠真正獲得用戶的青睞。