如何實現多實驗并行迭代，談阿里媽媽的 A/B 測試實踐

在線服務系統的AB-test方法有很多種。搭建多個可服務集群，從物理上對流量進行隔離是比較常見的一種方式。這種方式應用于大型復雜的在線服務系統時，存在部署比較慢的問題。這種方式的典型架構如下圖所示。

QueryRewrite：改寫用戶搜索詞以期望得到更好的查詢結果。

Matching：根據用戶搜索詞，召回最符合用戶意圖的那些推廣。

Ranking：確定推廣的輸出順序，需要兼顧用戶體驗和搜索平臺的收益。

這種架構有兩個優點。

• 代碼分為了基線和實驗代碼，實驗代碼對業務的侵入性比較小。

• 實驗田的流量和基線的流量從物理上嚴格分開，嚴格控制了實驗對業務的影響。

這種架構的缺點同樣也很明顯，主要有如下幾點。

• 增加了運維的復雜性，運維需要維護多套環境。

• 每套環境接入的流量都是由單個實驗田集群的物理機器數量固定上限的，不能靈活地驗證流量擴大的情景。這會導致對小流量實驗效果

• 很好的算法，在基線上有可能無法收到好的效果。

• 實驗的流量有限，導致實驗的數量變少，而增大實驗流量又會影響業務基線。

我們在總結現有的各種實驗機制的基礎上，結合阿里媽媽的應用場景實踐出了一種高效便捷、能充分利用流量、并行多個實驗的方法。該方法也能支持系統的灰度發布，有如下幾個優點。

• 提高并發：實現多實驗并行迭代，加快迭代的速度。

• 公平對比：做到實驗效果公平、準確對比評估，即時停止不符預期的實驗；隨時擴大效果良好的實驗的流量。

• 降低門檻：提供實驗管理工具，除算法以外，其他有實驗需求的如產品、運營、前端等都可以獨立申請發布實驗。

• 建立閉環：從想法、實驗前線下評估、發布實驗、實驗進行、實驗評估、最后實驗總結，確保實驗結果的質量。

系統架構和模塊說明

一. 系統整體架構

架構整體可以劃分為三個系統，如下圖所示。

接下來對各個子系統進行詳細的介紹。

1. 實驗配置管理發布系統

此系統給用戶提供便捷的UI操作界面，方便用戶添加實驗配置流量，然后動態地在線發布。為了彌補各種不可預期的錯誤，該系統支持歷史版本的快速回滾。

2. 在線服務系統

根據用戶的實驗配置文件，進行分流處理，給各個實驗分配相應的流量。實驗分流模塊以庫的方式接入在線服務系統。在系統的流量入口處調用此分流庫。后續會詳細介紹分流的原理和作系統進行實驗的方法。

3. 日志分析展示系統

根據在線服務系統記錄的日志，統計出各個實驗的效果，供系統分析師或實驗觀察者使用。然后根據實驗的效果，使用實驗管理系統去調整各個實驗流量的占比。

二. 各模塊介紹

1. 實驗配置管理發布系統

(1) 實驗場景。廣告系統中，實驗是針對某一批廣告位或者特定頁面進行的。針對PID（標記廣告的位置信息）或頁面來對流量進行分類就成了一個強需求。將這樣一批廣告位定義為一個實驗場景。Web操作頁面上需要提供配置實驗場景的UI界面，用戶可以在這個界面上新建一個場景，指定符合某些PID要求或者URL要求的請求進入相應的實驗場景，UI界面如下所示。

在此頁面上，用戶可以方便地添加一個新場景，并指定該場景的入口PID（入口PID可以設定多個）。

(2) 實驗分層和流量切分。進入某個實驗場景后，通過分多層來達到流量的復用。每一層的流量均是流入這個場景流量的一個全集。每一層的流量可以按用戶指定的切分標記進行分桶切流。

一層可以看成是多個實驗的集合，實驗分層的原則如下：

• 相互之間沒有影響的實驗可以分到不同層。

• 相互之間有影響的實驗分到同一層。

由于互不影響的實驗被分配到了不同的層，從而達到復用流量的目的。相互之間有影響的實驗分到同一層，則保證了同一請求不會去作兩個互斥的實驗。

2. 在線服務系統

Tesla以lib庫的方式接入在線服務系統。沒有做成一個服務的形式，主要考慮到接入簡單，不增加系統復雜性和運維的工作量。

(1) 分流規則。用戶可以在各層指定不同的切分標記進行流量切分。系統會根據用戶指定的切分標記值來計算hash值。計算出的hash值對100取模再加1可以得到分桶號，每個實驗占了指定范圍的桶號，這樣便可以知道該次請求應當進行哪個實驗。這里需要注意的是，選取一個偏差較小的hash函數，我們在數10種hash函數中選取了一個最優的hash函數，將偏差控制在實驗效果統計可以忽略的范圍。

假如每一層均使用這樣的切分規則，不同層做實驗的用戶選用相同切分規則時，請求始終落入相同的桶。由于不同層的實驗之間毫無關系，為了保證實驗效果絕對可信，需要做到不同層的流量正交。為了達到這個目的，引入了layerID來作為離散因子。由于每一層layerID是固定的，也能保證同一請求兩次訪問能落到同一個實驗，從而不會造成同一用戶多次訪問，返回結果不一致的困惑。示意圖如下。

(2) 實驗參數的處理。之前講述了如何決定一次請求去作哪些實驗。這一部分介紹一個具體實驗的構成元素，以及系統如何執行實驗。一個實驗本質上是一堆抽象參數集合。每個請求被分配某個實驗之后，系統便會將該實驗的抽象參數集合，作為請求的一部分傳遞至在線服務系統的各個處理模塊。

對于系統而言，可以根據請求攜帶的參數值來決定作哪個實驗。這里需要注意的是，為了保證系統的健壯性，如果一個請求缺少了某個實驗參數的數值，系統應該設置一個抄底的值。

(3) 實驗發布。當某個實驗效果非常好時，可以動態調整該實驗的流量占比，從而迅速得到收益，并且在大流量上驗證該實驗的有效性。一旦確認該實驗效果非常良好，便可以在全流量上線。這時需要刪除該實驗，把該實驗的參數作用于全部的流量。這是通過在每個場景中設置一個初始化層來實現的。

每個場景的第一層設定為初始化層，該層會初始化需要作用于全流量的所有參數。一旦某個實驗需要在全流量上線，便可以刪除該實驗，將該實驗的參數移到初始化層去。這樣便可以避免實驗數量不斷膨脹、層數不斷增加的問題，同時也達到了在線全流量發布某個實驗的目的。

3.日志分析展示系統

實驗效果統計無疑是系統中非常重要的一個環節。對于簡單的AB-test（物理集群隔離的實驗方法），實驗數據的統計相對比較容易。對于這種復用流量，在一次請求上作多個實驗的方式，統計實驗效果相對要復雜一些。這里介紹一種相對簡單的實驗統計分析方法。每個實驗均有一個唯一的實驗ID。對于一次請求，調用分流庫后，在返回所有實驗參數的同時，會返回一個字符串，該字符串將所有作用于該次請求的實驗ID以下劃線連接起來，例如Exp1_Exp3_Exp6_Exp8_Exp9。請求同樣會把這個字符串攜帶傳輸至系統的各個模塊，在記錄系統日志時將該字符串一并記錄下來。

日志分析處理模塊以“_”為分割符把該字符串進行分割，得到多個實驗ID，利用storm等流式實時處理系統去實時統計分析各個實驗的效果，再利用實驗發布系統動態調整流量，從而獲得了文中提出的一種良性的閉環反饋。

應用實例

下面以一個簡單的廣告引擎系統接入上述平臺的例子，具體說明上述的方法。該系統共有兩個實驗點（Query Rewrite和Rank），因此可以分為兩層實驗。下面以一次請求的處理流程來簡單說明該引擎系統的工作原理。

如上圖所示，Tesla以lib庫的形式接入引擎中。引擎接收到請求后，調用Tesla的lib庫獲取對應的實驗參數信息，然后依次將實驗信息透傳給Query Rewrite和Rank。在Query Rewrite和Rank模塊中各取所需實驗參數進行相應的實驗，最后將bucketID記錄到投放日志對應的字段中，用于實驗效果統計用。

下圖是整個實驗的配置文件的示意圖。

整個引擎的實驗根據需要分為了PC和無線兩種場景，分別進行策略優化和調整。根據算法實驗的需要，在兩種場景下均分為了兩層（QR和Rank層，QR是Query Rewrite）。每一層中均包含了三個實驗。每個實驗均是一些實驗參數的集合，例如，exp 100包含的參數有qr_plan=5，qr_weight=3。Exp 103包含的參數為rank_level=2，rank_stragety=9。

使用這個配置文件，一個用戶請求發過來之后，如果根據acookie分流計算得出此請求恰好落入PC場景的exp 100和exp 103這兩個實驗，則返回的bucketID應當為100_103，參數集合為qr_plan=5，qr_weight=3，rank_level=2，rank_stragety=9。BucketID可以記錄在日志中，后續進行日志統計和分析使用。日志統計分析時按下劃線把BucketID切割開，然后用Storm進行實時統計各個實驗的情況，也可以用Hadoop進行離線的日志分析處理。對于在線引擎，各個實驗點根據實驗參數的值決定使用哪種策略和模型參數。

總結

本文參考現有的關于在線服務系統實驗方法論文基礎上，結合廣告系統的特點，實踐出了一套有效的可以復用流量支持并行實驗的方法。該方法也可以解決灰度發布的問題。該套系統極大提高阿里媽媽所有的業務線應用的實驗效率。

 

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598227&idx=1&sn=9b3e5fdce959e4ff1a5d87398e50d646&scene=0