日前，由又拍雲舉辦的大數據與 AI 技術實踐｜Open Talk 杭州站沙龍在杭州西溪科創園順利舉辦。本次活動邀請了有贊、個推、方得智能、又拍雲等公司核心技術開發者，現場分享各自領域的大數據技術經驗和心得。以下內容整理自有贊數據智能團隊負責人尹越現場分享：
尹越，有贊數據智能團隊負責人，與團隊成員一起承擔有贊搜索、推薦、客服機器人、智慧零售、風控、會員營銷等多場景的數智化建設的職責。
大家好，我是來自有贊的尹越，今天主要和大家分享有贊數據智能團隊在個性化推薦能力的演進與實踐。我將首先介紹有贊公司和我們團隊，其次是分享下我們從事的業務以及遇到的問題，最后聊下有贊推薦技術是如何逐步演進的。
有贊數據智能團隊
有贊是一家零售科技服務公司，致力於協助商家經營移動社交電商和全渠道新零售，服務好每一個商家的上門客戶。我所在的有贊數據智能團隊曾負責線上場景的有贊微商城，現在負責線下零售，包括零售門店網店的有贊零售業務，涉及醫美行業的有贊美業和涉及線下教育的有贊教育。
有贊數據智能團隊本身是一個直接面向業務的團隊，我們的主要職責是負責引領有贊數據智能進程，涉及的業務包括推薦與搜索、風控、精准營銷、智能會員以及智慧零售。
有贊推薦業務及場景
業務場景
推薦業務：涉及微商城、零售線上門店、教育、精選、分銷、有贊客、愛逛，其中有贊精選是面向 C 端的平台業務，有贊分銷是面向 B 端商家選貨的平台業務，有贊客是面向網紅主播選貨的 CPS 平台業務，愛逛則是視頻直播平台。
場景：有贊提供幫助商家在自己微頁面進行裝修的自定義插件，覆蓋商詳頁、購物車、付款成功、營銷活動頁等核心交易鏈路。此外，還有商家和消費者進行溝通的提升商品轉化率的客服商品推薦場景。
展示形式：可以分為下拉的瀑布流推薦、廣告 banner 推薦，以及綜合了消費者的歷史瀏覽行為、店鋪熱銷行為和猜你喜歡等多種推薦形式的推薦櫥窗。
標的物：涉及商品推薦、優惠券推薦、店鋪筆記推薦以及視頻推薦。
模式：分只推薦商家店鋪內部的店內推薦、涉及其他店鋪內商品的跨店推薦，還有前文提到的有贊精選的 2C 平台推薦和有贊分銷的 2B 平台推薦。
場景示例
我們可以先通過測試店鋪了解有贊的商家是如何經營自己的店鋪的。如上圖所示，商家可以通過后台管理，從店鋪級別、商品級別、訂單級別、數據以及資產等不同的維度實現整個核心交易鏈路的日常經營管理。
裝修組件支持個性化推薦插件功能。如上圖所示，右側是一個微頁面裝修的部分，商家可以通過自己的需求配置如積分商城、知識付費等不同插件，組成自己所需要的微頁面；也可以根據自己的需求，選擇當前場景所需要適配的推薦規則。
有贊推薦系統的問題與挑戰
店內商品豐富度差異大。有贊主要是服務商家運營私域流量，不同的商家店內商品的數量會相差很大。有的商家可能多一點，成百上千；而有的商家商品較少，可能只有幾個。當商品數量非常少的時候，或許我們的推薦價值沒有那么地明顯，這是一個問題。
跨店用戶行為比較少。這涉及到當前 SaaS 經營模式的一個限制，即很難產生跨店的行為。它並不像淘寶、京東是一個平台型的產品，消費者可以很容易在不同的店鋪之間逛來逛去。
業務場景復雜度高。有贊推薦業務既有面向 C 端的，也有面向 B 端的，還有面向客服場景的。整個業務場景以及團隊需要對接的業務方相對較多。
業務需求量大。復雜的業務場景和對接的眾多業務方，使得對團隊推薦業務接到的需求量比較大。
埋點數據易缺失。我們的日志信息多在業務前端進行埋點，可能業務前端在進行其他功能升級的時候，會造成推薦相關的埋點數據丟失。
有贊推薦技術演進
既然問題出現了，我們總要解決問題，下面我們看一下有贊的推薦技術到底是如何一步一步演進，解決這些問題的。
有贊推薦系統 1.0：豎井式架構
最底層的基礎數據主要是業務數據和原始日志數據。業務數據一般是業務寫在 MySql 當中的，比如說商品的原始信息、店鋪的原始信息；日志數據包括商家在 B 端的操作行為日志以及消費者在 C 端的消費行為日志。
第二層是離線數倉層，這里包括了三部分：數倉 ODS 層大部分是將原始業務的數據在數倉中做一個表的映射，做一些簡單的清洗與補全；數倉DW 層會將下面的異構的 ODS 層數據以通用的格例如以星型模型或者以其他的寬表形式，整合成適合上游業務方使用的中間層數據表表；數倉 DM 層更貼近於業務，進行一些指標的聚合等相關的操作。
第三層是推薦相關的一些功能分層，首先看召回與特征這一層：在 1.0 版本不同的業務線會有獨立的存儲介質以及存儲表，比如說像有贊精選和有贊分銷都有自己的 HBase 表，還有一些特征可能自己存在在 MySql 當中，彼此之間也沒有去通用。
第四層是線上服務層，在 1.0 版本當中，有贊的推薦系統沒有單獨抽離出一個獨立的系統，而是把我們的業務邏輯與業務方的 Java 代碼相對緊密地耦合在一起，將不同業務當中的召回、排序都嵌入在業務代碼當中。我們當時使用的算法模型是傳統的邏輯回歸，通過 SparkPi MLlib進行訓練，再在通過 Java 在線上動態加載 PM 模型產生的排序效果。再往上是業務的前端跟業務的后端進行對接，前端負責展示和埋點相關的工作。
豎井式架構的缺陷
可用的輔助系統相對較少。例如離線數倉生成不同的 Hive 表會需要有任務調度的有贊 DP 系統，我們需要有贊的 Meta 系統查到不同的 Hive 表，相當於一個數據字典知道有哪些表、哪些表有哪些字段。而為了分區效果以及對比做 AB 試驗，在有贊 Bi 當中，數據組和算法組需要自己開發報表分析業務效果。
還有一個明顯的缺陷是如果有新業務進來，起碼從召回與特征層就要重新進行特征的制作。我可能需要單獨抽出一個服務和業務方、前端進行對接。整個開發周期非常長，重復工作非常多。例如同樣的商品，可能近 7 天銷量、近 7 天退款率等一些數據很有可能在不同業務方會存多份，這個造成數據使用上的冗余。
有贊推薦系統 2.0：集中式架構
2.0 時期將之前 1.0 的豎井模式轉變為了集中模式，架構上帶來了很多變化：
基礎數據層引入實時數據
基礎數據中除了離線數據外新引入了實時數據。引入實時數據的好處在於當消費者搜索、瀏覽或者購買以后，基本上能在秒級別捕獲到他的行為日志。當時我們是通過 Druid 做實時數倉，將行為日志落在 Druid 當中，提供上游的推薦引擎進行調用。
召回與特征層
為減少不同業務對於同樣特征數據使用的冗余的開發，我們盡量將不同業務方都可以使用到的特征，統一地存儲在同樣的 HBase 表當中。在模型選擇上，我們也從傳統的機器學習模型遷移到了TensorFlow 架構下的模型服務，然后通過 TFServing 向線上提供模型的推理服務。
Java 版本推薦引擎
在新的架構中，我們抽象出了專門的 Java 版本的推薦引擎，並按照不同的功能進行分層，即觸發——召回——粗排——精排——干預。精排過程中會調用前文提到的TFServing 的服務，進行商品等其他標的物的精排打分，最后的干預更偏向於業務，例如將某些店鋪內的商品打散或者要對一些條件進行過濾，是一個干預重排層。
業務場景更復雜
相較而言，2.0 版本對接的業務場景會更多，除了之前的有贊精選，像有贊微商城、有贊零售、有贊教育以及有贊客等，各個業務場景會通過新的系統接入。
輔助系統更完善
新增更標准化的記錄埋點方案的埋點平台，專門用來做算法實現好壞的 ABTest 系統以及幫助我們管理實時調度任務的有贊 RP 平台。
有贊推薦系統 2.5：半開放式架構
雖然 2.0 版本比 1.0 好了很多，很多開發工作做到了資源復用，但仍有一些問題是沒有解決的。Java 版本的推薦引擎中主要是提供一個對外的接口，而前端的展示以及埋點依然要業務方的前端進行開發，這會給后續追蹤業務效果以及 ABTest 實驗所必須強依賴的日志信息的埋點准確性帶來很大程度的挑戰。
我們之前遭遇過埋點和上線測試都驗好了，但因為業務方其他功能升級引起埋點某些字段丟失，最終導致后期效果沒有辦法跟蹤，不得不推動業務方反向把埋點再補全的事情。在實際開發的過程當中，這非常影響開發效率和對接效率。
為了解決這些問題，我們在推薦引擎與具體業務場景對接之間，新增加了一個推薦的前端服務化組件。這樣就把推薦各展示位的展示形式、如何埋點、和后面的推薦引擎以什么樣的參數去交互等問題，和業務方的前端完全隔離。只要前端告知是哪一個業務（所需要的是瀑布流模式、橫排滑動模式還是其他模式的展示形式）、場景 ID 以及必要的參數信息就行了。這里可能通過七八行代碼就可以快速對接一個推薦業務場景，一天對接、一天測試，第三天就上線了。事實上，我們已經成功通過有贊雲開放平台向很多商家用戶提供了該版本推薦引擎服務，幫助商家可以在非有贊域內的頁面展示自己的商品。
此外，2.5 版本中輔助系統同步啟用了有贊的算法平台，包含訓練板塊的 Sunfish 以及管理線上 TFServing 的分流與高可用的小盒子。
有贊推薦系統 3.0：開放式架構
上圖呈現的 3.0 版本是有贊推薦團隊希望當前推薦架構的方向。目前有贊對接的商家從中等體量到大體量都有，而大商家對在各個場景都有定制化需求：教育類的商家希望自己的商品可以按照教育課程、上課人群的年齡或者課程的級別要求進行關聯推薦，而有一些商家又希望一定要自己設定的某幾個商品出現在某些展位前。面對這種定制化需求多樣的問題，如果是單靠有贊推薦團隊自己去開發、不斷的迭代，成本是非常高的，而且也不太現實。所以我們希望能夠通過不同的環節開放出更多的組件與插件，滿足商家自己在不同場景的個性化需求，從而達到一個有贊推薦系統整體的開放式效果。
目前整個推薦業務迭代過程中需要在多個平台之間來回切換，我們也希望后續能夠有統一的推薦管理平台的方式，整合多個管理系統的功能，一站式解決整個推薦業務的對接。
召回、排序演進
召回和排序是推薦系統當中比較關鍵的兩個環節，我們詳細展開介紹。
召回演進
目前召回部分的召回源大概分為四大類：I2I、U2I、T2I、兜底。
I2I：商品找商品的召回模式
-
FPGrowth，挖掘不同商品之間的關聯性
-
Item-CF ，Item-base 協同過濾的算法
-
I2T2I，通過標簽將不同的商品之間建立關系
-
GraphSAGE，基於圖卷積的標的物進行向量化的召回模式
-
標題相似，將標題通過 Bert 產生標題向量，在標題向量之上基於局部敏感哈希做向量相似進行的召回
-
頭圖相似，將商品的頭圖通過圖片分類模型抽取出圖片對應的向量，在頭圖的向量上進行頭圖相似的一些召回
U2I：人找商品的召回模式
-
DMP 召回源，指的是通過消費者的性別、年齡等一些用戶維度的屬性和商品進行關聯
-
U2T2I，和 I2T2I 類似，也是通過標簽建立用戶跟商品之間的關系
-
User-CF，基於用戶和用戶之間相似的協同過濾
T2I：通過標簽去找商品的召回模式
我們有基於商品的類目分類模型，基於產品詞、標題產品詞的抽取模型，以及用戶在搜索過程當中搜索詞和商品之間的點擊購買關系所產生的關系模型。這一類召回源主要會用在前文提到的實時召回以及此前沒有用戶行為的場景
兜底的策略
當上述所有模式都失效且無法獲得任何上下文的時候，不能什么也不推薦，總得有一個兜底的策略，所以會有熱銷、爆款。
排序演進
最后跟大家分享一下有贊排序算法的演進過程。1.0 版本采用的是相對比較傳統的基於邏輯回歸的一個排序算法，2.0 版本初期在使用深度學習框架之后，引入了相對比較簡單的入門級的 Wide & Deep 的模型。在經歷了多版本的迭代、對比多個多任務學習框架后，我們最后選用了阿里巴巴在 2018 年提出的 ESMM 模型，它可以把 CTCVR 以及 CTR 同時作為訓練目標去訓練。
當然在這些模型的嘗試過程當中，我們也在不同業務場景使用了其他的一些模型方式去做嘗試。比如我們在有贊分銷業務中曾經嘗試過基於 ListWise 的 Learning to rank 的 LambdaMart 模型；而客服對話場景可能會更偏搜索，我們為了捕獲兩個搜索問句以及答案標題之間的語句相關性，我們使用了 PairCNN 相關的深度學習模型，最后發現 ESMM 模型可能是現階段比較適用的。