311      財經資訊

全流程規範__產品簡介_推薦引擎-阿裏雲

前麵已經提到，全流程規範化是RecEng實現客戶自定義功能的基礎。

日誌埋點規範

環境準備好之後，最重要的對接工作接入客戶日誌，即讓客戶的日誌滿足RecEng的日誌埋點規範。日誌埋點規範定義客戶終端產品需要采集的內容，以及實時上報日誌的格式要求。RecEng支持兩條日誌上報通道，實時上報和離線上報。實時上報通過Restful API提交，離線上報按照數據格式規範的格式提交到MaxCompute（原ODPS）。日誌埋點規範包括通過Restful接口提交的日誌格式，不包括MaxCompute上離線日誌表的格式。

一般情況下要遵從RecEng的日誌埋點規範需要升級客戶的終端產品，但在客戶已有推薦服務的情況下可以暫不進行終端升級，詳見下麵的說明。

日誌埋點規範包括內容和格式兩方麵的要求。RecEng將用戶行為分為三類，第一類是交易行為，即用戶的這類行為能夠給網站或APP，也就是RecEng的客戶帶來收益的行為。對電商來說，交易行為是商品購買；對音樂或視頻類網站來說，交易行為是音樂或視頻的播放或下載。

第二類行為稱作準備行為，它們雖然不能直接給網站帶來收益，但是這些行為是實現交易的必要前提，比如用戶對物品的瀏覽、點擊、搜索、收藏等。客戶需要區分這些行為，因為不同行為對交易的影響是不同的，細粒度的區分有助於更好的分析用戶興趣，達到更好的推薦效果。

第三類是與交易無關的行為，比如用戶在網站上點擊了其他網站的廣告，跑掉了，這類行為RecEng不關注。

日誌埋點規範在內容方麵要求客戶記錄交易行為和準備行為，並且在記錄用戶行為日誌時區分開這兩種行為。和通常的日誌一樣，日誌埋點規範也要求記錄行為發生的一些上下文參數，比如時間，用戶，物品等信息。此外為了便於計算由推薦服務帶來的轉換率，日誌埋點規範要求客戶記錄traceid。traceid將用戶在推薦坑位的點擊與最終成交關聯起來，用於判斷成交是否是由推薦服務帶來的。traceid由RecEng在返回實時返回推薦結果時返回，細節詳見日誌埋點規範。

客戶如果不按照日誌埋點規範記錄traceid，唯一的影響是不能使用RecEng提供的效果報表功能，不影響推薦業務的正常使用。

如前所述，客戶如果不在意效果報表，且之前已有推薦服務正在運行，且日誌內容滿足日誌埋點規範的要求，可以在現有的推薦服務器上對日誌遵照日誌埋點規範進行格式轉換，暫不升級終端產品，快速體驗RecEng。

數據格式規範

數據格式規範定義了離線和在線計算所使用時的數據格式，其中離線數據的格式相對複雜一些，在線數據的格式相對簡單。

離線數據規範

RecEng中，離線流程（rec_path->offline_flow）和效果流程（index_path）都是在離線計算的，離線數據規範中定義了這兩類流程的數據規範。一般情況下，離線計算的輸入和輸出都是MaxCompute（原ODPS）表，所以離線數據規範其實上是一組MaxCompute表的格式規範，包括接入數據、中間數據和輸出數據三類數據的格式規範。

接入數據指客戶離線提供的用戶、物品、日誌等數據，RecEng最關注的是日誌數據，其次是物品數據，最後是用戶數據。日誌數據離線和在線基本上一致，日誌埋點規範中已有說明，參見規範的詳細定義即可。物品數據由類別、屬性和關鍵字幾部分組成，其中類別和關鍵字含義明確，都很好理解；屬性是多值字段，按key-value格式組織，如果有多個屬性，都在屬性字段裏按照規範格式列出即可。RecEng要求這三個字段不全為空。

用戶數據類似，有一個叫做tags的多值字段，同樣按照key-value格式組織，和物品數據的屬性字段不同的是，tags字段可以為空。

為了讓RecEng了解物品的屬性字段和用戶的tags字段中各個key-value的數據類型，客戶還需要補充兩張數據結構說明表，分別解釋物品的屬性字段中每個key-value的數據類型，以及用戶的tags字段中每個key-value的數據類型。當客戶提供的物品數據、用戶數據的內容沒有變化時，這兩張表可以一直沿用。

如果客戶要自定義離線算法，需要了解中間和輸出數據格式規範。RecEng定義了十多張離線MaxCompute（原ODPS）表的格式，涵蓋離線流程和效果流程中所有用到的接入表、中間表和輸出表，這些表被統稱為標準表。所有離線計算的算法都必須以標準表作為輸入輸出表；對於效果流程中的算法，還需要將計算結果輸出到RDS中，方便實時展示。

在線數據規範

RecEng的在線計算包括在線流程（rec_path->online_flow），以及實時修正流程（mod_path）兩部分。

不像離線算法，天然以MaxCompute（原ODPS）表作為輸入和輸出，在線程序的輸入數據可以來自多個數據源，如在線的表格存儲（原OTS），以及用戶的API請求，又或者是程序中的變量；輸出可以是程序變量，或者寫回在線存儲，或者返回給用戶。

出於安全性考慮，RecEng提供了一組SDK供客戶自定義在線代碼讀寫在線存儲（Table Store），不允許直接訪問，所以需要定義每類在線存儲的別名和格式。

對於需要頻繁使用的在線數據，無論其來自在線存儲還是用戶的API請求，RecEng會預先讀好，保存在在線程序的變量中，客戶自定義代碼可以直接讀寫這些變量中的數據。

綜上，在線數據規範定義的是在線程序所使用的數據集的規範。這裏的數據集是一個抽象的概念，可以是在線存儲中的表的格式規範，也可以是在線程序中某個全局或局部變量的結構定義，稱之為標準數據集。規範會定義各個標準數據集的可讀寫性，當客戶自定義程序違背了讀寫性要求時，將無法通過代碼審查，不能上線。

算法規範

在RecEng中，算法是把數據串接起來的邏輯。這裏的數據指離線的標準表，或在線的標準數據集。算法除了輸入輸出數據之外，通常還會包括一係列參數，RecEng的算法模型如下圖所示：

更確切的說，輸入數據指的是算法需要處理的信息，輸出數據是算法處理後的結果，而參數，則是算法為了在不同的輸入數據上都能取得比較好的效果而提供的一組可供算法使用者調整的開關。從麵向對象的角度看，如果我們把算法看成對象，那麼算法參數是算法本身的屬性，而輸入輸出數據則定義了算法的接口。

為了簡化算法流程的定義，RecEng要求每個算法隻能有一份輸出數據，不限製輸入數據的數目。

所謂符合RecEng規範的算法，就是以這些標準表或標準數據集作為輸入輸出數據的算法。具有完全相同的輸入數據、輸出數據的算法是同類算法，RecEng定義了一組常用的算法類別，能滿足大部分需求，未來還允許客戶自定義算法類別。RecEng的算法規範，指的就是上麵的算法模型，以及這一組算法類別。

RecEng隻要求同類算法具有相同的輸入輸出數據，即接口相同；不要求同類算法的參數相同，參數是算法的內部屬性，RecEng算法規範對此不做要求。

客戶在自定義算法時可以把算法參數注冊到RecEng中，在使用自定義算法時RecEng會自動將這些自定義參數展示出來，方便客戶調整。

RecEng不設算法版本的概念，如果要升級現有算法，RecEng的方法是把新版本的算法注冊為新算法，注冊之後就可以使用。老版本的算法可以在無人使用後下線。目前在刪除算法時還不能提示算法是否正在被使用，正式上線的版本會完善這些功能。

算法流程

在概念解釋一節中大致介紹了算法流程的概念，包括兩種流程，推薦流程（rec_path）和實時修正流程（mod_path），本節進一步介紹這些流程的技術細節。算法流程中使用的數據和算法遵從數據格式規範和算法規範。

RecEng中的算法流程

RecEng中的算法流程是一個有向無環圖，圖中節點為算法，算法A到算法B的邊則表明算法A的輸出是算法B的輸入。由於算法規範要求每個算法隻有一份輸出數據，所以算法流程圖中可以不標明數據節點。

RecEng提供可視化界麵用來編輯這個有向無環圖，這個過程就是自定義算法流程。RecEng還預先實現了一組相對標準的推薦算法供客戶使用，若客戶覺得係統提供的這些算法不滿足需求，可以遵循算法規範自行開發，並注冊到RecEng即可使用。

RecEng中的算法流程包括離線流程（rec_path->offline_flow）、在線流程（rec_path->online_flow）、數據修正流程（data_mod_path），和用戶修正流程（user_mod_path），這些算法流程都支持客戶自定義，即支持通過可視化界麵來編輯算法流程的有向無環圖。

在RecEng中還包括一個效果流程（index_path），和上麵幾個算法流程不同，客戶在定義效果流程時隻需要選擇效果指標即可，RecEng會自動根據客戶選擇的指標生成算法流程，不需要通過可視化界麵進行編輯。

在RecEng中，推薦流程（rec_path）屬於場景（scn），客戶可在場景下新建推薦流程，每個推薦流程由離線流程（offline_flow）和在線流程（online_flow）組成，是相對獨立的兩個部分。所以每個rec_path由兩個有向無環圖組成。

實時修正流程（mod_path）則屬於業務，兩類mod_path各自最多隻有一個實例，所以每個業務下最多隻有兩個實時修正流程的有向無環圖。

考慮到實際實現的一些因果關係，下麵的介紹按照離線流程（rec_path->offline_flow），實時修正流程（mod_path），在線流程（rec_path->online_flow）的順序進行，即在介紹推薦流程（rec_path）的中間插入了實時修正流程（mod_path）。

離線流程（rec_path -> offline_flow）

離線流程整體示意圖：

上圖，以及本節各流程圖元素說明：

• 橘黃色雙曲邊矩形表示接入數據表
• 黃色雙曲邊矩形表示中間數據表
• 藍色雙曲邊矩形表示輸出數據表
• 藍色單曲邊矩形表示輸出模型
• 青色方框表示計算邏輯

離線流程從用戶輸入的用戶、物品、日誌數據開始，經過簡單的處理後生成用戶/物品的原始特征，接下來是推薦的核心算法，計算用戶和物品的關係，生成用戶/物品耦合特征。所謂耦合特征，指包含了用戶對物品興趣的特征，即利用耦合特征可以計算出用戶對每個物品的興趣偏好。接下來就是計算用戶的候選推薦集合，以及物品的相似物品集合。

對於一般的客戶，可被推薦物品不是特別多，到這裏基本上就可以了，也就是左邊藍色虛線框內的基本推薦流程。基本推薦流程通過分析用戶行為，給用戶展示其最感興趣的物品，即興趣是其優化的目標。

如果客戶可被推薦的物品非常多，或者客戶的優化目標不是用戶對物品的興趣，而是其他指標，比如轉換率，成交金額等，可以引入右側紅色虛線框中的排序建模流程，針對優化目標建立起每個用戶的模型，並基於此生成推薦候選集。

排序建模流程需要的樣本從用戶日誌中根據優化目標抽取，排序模型方麵目前RecEng隻提供了基於Logistic Regression的Learning to Rank模型，未來會加入更多的排序模型，如曾經在聚劃算導購業務中大放異彩的biLinear模型等。

最終，offline_flow的所有計算結果會被導入在線存儲，保存在離線計算結果表中。

實時修正流程（mod_path）

mod_path整體流程示意圖：

mod_path由兩個並列的流程，數據修正流程（data_mod_path）和用戶修正流程（user_mod_path）組成。

客戶將需要更新的實時輸入，如新上線物品，或已下線物品通過數據修正API提交到數據修正線程，數據修正流程將這些信息保存到在線存儲中，供在線流程（rec_path->online_flow）使用。

客戶還可以通過實時日誌，在用戶信息修正線程中實時分析用戶的感興趣物品和不感興趣物品，優化推薦效果。目前由於在線程序都由Node.js編寫，在線學習能力較弱，未來會引入專門的實時計算平台，屆時可以實現真正意義上的online training。

實時修正流程都是可選的，最終產出的結果供在線流程（rec_path->online_flow）在響應用戶的推薦請求時使用。

每個實時流程，包括實時修正流程（mod_path）和下文的在線流程（online_flow），都工作在獨立的線程中，隻不過有的線程是後台定時線程（如用戶修正流程，不斷輪詢實時日誌），有的線程是事件觸發線程（如數據修正流程，當有API請求時才會工作，處理完成就結束了）。RecEng將每個實時處理線程都分成了三個階段，如下圖所示：

參數解析階段負責讀取和解析處理時需要用到的參數，包括API傳入的參數，實時日誌，係統配置等；執行處理階段是實時處理流程的核心，負責實現實時流程的業務；輸出階段則把實時流程處理的結果輸出出去，可以是在線存儲，也可以以返回給用戶。幾個階段之間的參數傳遞由在線數據規範定義，圖中以CTX（上下文環境變量）代表，下一節中的CTX含義與此相同。

為簡化客戶自定義開發，聚焦業務，以上三個階段中，RecEng隻允許客戶自定義第二階段的程序，參數和輸出的工作都由RecEng承擔，這也提高了係統的安全性。

在線流程（rec_path -> online_flow）

online_flow負責響應來自終端產品（用戶）的推薦API請求，圖中“表格存儲（原OTS）離線計算結果表”正是offline_flow的最終輸出，屬於不同rec_path的offline_flow產出的表格存儲離線計算結果表不同，online_flow以這種方式和offline_flow一起組成rec_path。

在推薦處理線程的參數解析階段，除了讀取參數，RecEng還做了這麼幾件事：

1. 檢查請求是否來自測試用戶，並記錄在CTX（上下文環境變量）中。測試用戶指訪問測試路徑的用戶，詳見“測試”一節中關於“測試路徑”的說明。

2. 對有A/B Testing需求的場景，根據客戶的A/B Testing流量配置分配rec_path，並記錄在CTX中

3. 從離線計算結果表中讀取當前用戶的相關數據，包括用戶特征，推薦候選集；如果API請求參數中包括物品id，那麼把與該物品相似的物品也都讀取出來

在執行處理階段，客戶自定義算法從CTX中獲取RecEng預先讀好的數據，判斷當前對應的rec_path，選擇相應的算法進行處理，通常是對離線計算結果進行過濾和排序；如果客戶定製了實時修正，在這個過程中可以利用實時修正的結果進行計算，並將最終結果寫回CTX。返回階段的代碼將客戶自定義算法處理結果返回給請求用戶，完成推薦。

效果流程（index_path）

RecEng中，效果流程是不需要客戶配置的，隻需要選擇效果指標即可。關於效果指標和效果報表的自定義開發、配置，詳見效果報表。

最後更新：2016-11-23 16:04:08

  上一篇： 部署和接入__產品簡介_推薦引擎-阿裏雲

  下一篇： 自定義算法開發__產品簡介_推薦引擎-阿裏雲