315      阿裏雲

測試__產品簡介_推薦引擎-阿裏雲

集成測試

自定義算法開發完成後，還需要經過集成測試才能正式上線。集成測試是單元測試的延伸，單元測試驗證算法內部的邏輯是否達到目的，集成測試則關注把新開發的算法加入算法流程後，整體表現是否有異常。RecEng中用於集成測試的手段是測試路徑。

客戶在RecEng中新建了一個算法流程――不妨稱之為F――後，默認F是處於“未發布”狀態的，這有兩層意思：

1.啟動離線計算API時F不會被啟動

2.F的計算結果無法被推薦API獲取

既然1，未發布的算法流程不會被離線計算API啟動，所以RecEng在產品界麵上提供了手工啟動未發布算法流程的按鈕。離線計算完成後，RecEng會將F的離線計算結果同步到在線存儲，但是由於2，推薦API是無法獲取F的計算結果的，測試流程的計算結果目前隻能通過RecEng的API調試功能在產品界麵上進行觀察，目前還不能支持以API的方式訪問測試流程的計算結果。

集成測試通過後，客戶需要在產品界麵上點擊“發布”按鈕，將未發布的算法流程發布上線，這樣才真正進入了生產，上麵說的1和2這兩條限製都會被取消掉。

另外，有的時候客戶可能需要對發布上線的算法流程進行調整，這時怎麼辦呢？

RecEng為每個已經發布上線的算法流程其實都還保存有一份線下測試版，這時客戶隻需要修正對應的線下測試版即可，按照上麵的過程，先調整算法邏輯，然後手工啟動離線計算，再在API調試中觀察計算結果。集成測試通過之後，點擊“發布”按鈕，這時會提示是否需要覆蓋線上數據，意思是需不需要用測試流程的計算結果去覆蓋之前的生產流程的計算結果，客戶可以根據實際情況自行判斷。

效果測試

集成測試隻能驗證自定義算法在算法流程中是否能夠正常工作；然而作為算法，僅僅能夠正常工作是不夠的，效果才是算法的最終目的。RecEng支持以算法流程為單位的A/B Testing，直接對最終效果進行比較，為決策提供參考。

要進行A/B Testing，必須要先明確指標；要計算指標，首先要采集日誌。下文從日誌采集開始說明。

日誌采集

在度量推薦係統的效果時，RecEng隻關心和推薦有關的行為。為了和其他無關的行為區分開來，RecEng在每次推薦API的返回結果中都附帶有一個Trace ID（該次推薦API返回的所有物品共享這一個Trace ID），客戶需要按照一定的規範把這些Trace ID埋入日誌，這樣才能利用阿裏雲推薦引擎提供的效果報表功能，具體埋點和日誌的規範細節參見日誌埋點規範

Trace ID的埋點有三個原則：

1.在推薦列表展示時，需要把對應的Trace ID埋入推薦列表中所有物品的鏈接裏

2.如果用戶點擊了包含有Trace ID的物品鏈接，需要把這個Trace ID帶入下一個頁麵，且要在新頁麵中所有該物品的鏈接裏都埋入這個Trace ID

3.如果用戶點擊了不含Trace ID的物品，或點擊了包含有其他Trace ID的物品鏈接，之前的Trace ID失效

要注意的是，不是所有的日誌中都會有Trace ID信息，Trace ID隻負責對RecEng返回的推薦結果進行跟蹤。客戶網站或應用中大部分的用戶行為可能都和RecEng並沒有關係，為了更好的刻畫用戶畫像，這些用戶行為也是需要上傳到RecEng的。

日誌埋點完成之後，把日誌通過日誌API提交到RecEng，日誌采集就算完成了。但日誌API的功能可不僅僅隻限於上傳采集的日誌。細心的用戶可能會注意到，在RecEng的業務配置界麵中，有一個不起眼的複選框：

即客戶可以通過日誌API實現離線數據上傳，要實現這個功能，一方麵需要在產品界麵上打開這個開關；另一方麵各種user、item的數據都需要從日誌API傳上來。和離線上傳不同，通過日誌API上傳user、item數據是增量方式的，每天隻需要把新增的數據發送給RecEng即可。

業務配置頁中的“自動數據預處理”複選框如果選中了，那麼在新的一天開始的時候，會自動啟動對前一天數據的離線計算任務。

效果報表

在RecEng中，與效果報表緊密相關的概念主要有三個：效果算法、效果指標、效果流程。

效果算法專門用於計算效果指標，其輸入和輸出表都是固定的，輸入表是行為表（user_behavior），輸出表則是指標結果表。效果算法的邏輯比較簡單，一般就是簡單的統計，或者在統計的基礎上進行四則運算。麻煩之處在於統計是要有統計口徑的，口徑包括時間粒度、業務粒度等。

RecEng中所有這些統計口徑都是一致的，時間上支持日、周、月三個粒度，業務上支持按場景、按算法流程統計。時間粒度的需求要靠效果算法實現：通常隻需要輸出當日指標，在周一或每月一號的時候還要額外輸出上周、上月的指標。如果效果算法中沒有包含對周指標、月指標的計算，RecEng會自動用0填充。業務粒度的需求由RecEng統一實現：RecEng會將行為表按業務粒度進行拆分之後再交給效果算法去計算，所以效果算法不需要考慮業務粒度的問題。

效果算法以行為類型為參數，不針對具體的行為類型；效果指標則需要明確行為類型。所以效果指標可以理解為效果算法+行為類型的組合。比如專門用於統計PV的效果算法，可以統計任意行為的PV，view，click，consume，都可以；但說到指標的時候一定要明確是view的PV，還是click的PV。

效果指標隻需要定義即可，選擇一個效果算法，明確行為類型就好了。定義了效果指標，我們還需要每天執行一遍效果流程（index_path），把這些指標算出來。效果流程不需要配置算法節點的流程圖，隻需要選擇效果指標就好了，RecEng會自動生成效果流程的流程圖，客戶可以通過效果計算API啟動效果流程。

最後，是關於效果報表的配置，隻需要為效果指標選擇一個展示圖表就好，比如折線圖，餅圖，柱狀圖等。效果流程計算完成後，客戶就可以在效果報表中看到了。

RecEng默認提供了一些簡單的效果算法，也預先定義了一些效果指標，客戶可以根據自己的需求開發新的效果算法，注冊到RecEng即可。

A/B Testing

A/B Testing是常見的效果測試方法，也是RecEng唯一的效果測試的手段。經過前麵的準備，現在我們可以獲知每個算法流程的效果指標，那麼，通過比較不同流程的指標，就可以進行效果優化了。

RecEng允許一個場景下存在多條推薦流程（rec_path），A/B Testing也是針對同屬於一個場景的不同推薦流程來進行的，在進行A/B Testing時，同一個場景下的每個推薦流程都會被分配一定的流量比例，這個比例是可以在產品界麵中配置的。在執行推薦API時，RecEng第一步就會按照比例隨機分配流量，把當前用戶分配到某個推薦流程中，然後再執行這個推薦流程的在線流程。RecEng在分配流量時是完全隨機的，不遵從任何規則，如某個用戶一定要分配到某一條推薦流程中這樣的規則。

無論是否開啟A/B Testing，客戶調用推薦API的參數都是完全一致的，推薦API的參數中隻包括場景參數，不需要，也不能指定推薦流程（rec_path），為了在進行效果統計時明確推薦的物品來自哪個推薦流程，所以RecEng在每次答複推薦API時會附帶Trace ID，這樣才能準確的統計出每個推薦流程的效果指標。

縱觀整個流程，使用A/B Testing的工作量主要在前期，日誌埋點、配置效果報表，完成了這些之後，使用A/B Testing其實是非常簡單的。

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

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

  下一篇： 運維和運營__產品簡介_推薦引擎-阿裏雲