日前，由又拍雲舉辦的大資料與 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 模型可能是現階段比較適用的。