免费陕西麻将游戏|免费正宗陕西麻将
你好,游客 登錄
背景:
閱讀新聞

Google 重疊實驗框架:更多,更好,更快地實驗

[日期:2015-01-11] 來源:CSDN  作者: [字體: ]

  辛苦優化的模型與策略線上效果到底如何? 這就需要一個能夠支持線上A/B test 的一高效的線上實驗平臺。實驗流量就是資源, 如果有一千個人同時在線上做對照實驗, 資源如何分配呢? Google 重疊實驗框架:更多,更好,更快地做好線上對照實驗。

  Google是一個數據驅動型公司,這意味著所有對用戶的改動的發布,都要決策者以相應的經驗數據作為依據。這些數據大部分是由在線流量上的實驗產生的。在web的語境下,一個實驗是由一股流量(比如,用戶的請求)和在這股流量上進行的相對對比實驗的修改組成的。修改包括用戶可見的修改(比如,修改頂部廣告的背景色),以及不可見的修改,比如測試一個新的廣告點擊率(CTR)預測算法,都可以通過實驗的方式進行的。

  要支持數據驅動方法論的挑戰在于要跟上創新的速度。我們想支持進行盡可能多的實驗,如果實驗框架要限制同時進行的實驗的數量,那是絕不可被接受的。我們進行實驗是為了測試一些新的特性和挖掘一些已有特性的提升空間。對于已有特性,實驗可以學習到用戶的反應并可以對特性進行優化。試想一下,如果在搜索結果頁上的內容都是通過參數控制的,包括展示方式和算法。通過對參數設置不同的參數值進行實驗,我們可以用衡量指標(用戶體驗,收入或其它指標)來決定是否要進行哪些修改以得到最好的結果。

  對UI的修改通常會使用實驗來評價用戶反應,但需要注意的是算法的修改同樣也需要實驗。例如:假設一些團隊想測試一個新的機器學習算法來預測廣告CTR,或是測試對現有算法的調整(比如,修改學習速度或是收斂速度)。雖然線下評估可以進行一些分析后,可以縮小參數的最佳取值區間(不是最佳取值),但最終這些參數還是需要在線上流量進行評估,分析這些參數在真實的流量上的效果(因為修改可能會影響用戶的行為,并改變流量本身的模式,這是不可能在線下環境評估的)。所以,評價這些機器學習算法是需要通過線上實驗的方式進行的。

  設計我們實驗框架的目標是:更多,更好,更快。

  更多:我們需要能同時進行多個實驗的可擴展性。但是我們也需要靈活性:不同的實驗需要不同的配置和不同的流量來衡量實驗的統計意義上的效果顯著性。有些實驗只需要修改流量的一個子集,比如只是日語的流量,并需要取一個合理的流量規模。其它的實驗有可能需要修改所有的流量,并對指標造成很大影響,這種才可以在小流量上進行測試。

  更好:不合理的實驗是不應該讓它在線上流量進行的。合理的但是很差的實驗(比如,有bug的實驗或是無意中產生的很差的實驗結果)都應該能很快的被捕獲并且停止它的進行。標準化的標價指標可以讓所有的實驗進行公平的比較:比如在計算CTR指標的時間,兩個實驗應該用相同的過濾器去掉爬蟲流量。

  更快:能夠很容易并且很快地建立一個實驗。容易到非工程師不需要寫代碼就可以創建一個實驗。評價指標應該很快的被統計出來,以便分析。簡單的迭代可以很快速地進行。理想狀態是,實驗系統不僅支持實驗,并且可以控制放量,比如,以一種系統的和容易理解的方式對實驗進行放量。

  為了達到這些設計的目標,我們不僅需要實驗架構來進行更多的實驗,并且需要一些工具和指導過程來支持更多和更快的實驗。

  對于實驗架構,有兩個很明顯的選擇,或是要支持單層實驗或是要支持多因素實驗。單層實驗意味著每個請求最多只會通過一個實驗,單層實驗是很容易使用的,并且也具有靈活性,但是擴展性不足。多因素實驗在統計學上進行了大量的討論,多因素實驗中每個參數(因素)都可以被獨立地實驗,在實驗中每個參數(因素)都可以獨立地被實驗,每個實驗中只測試一個參數,這個參數會覆蓋所有其它實驗中的其它參數。每個查詢可以同時在N個實驗中,其中N是參數的個數。雖然這種方法進行了多年的研究和實踐,但對于Google的系統卻不適用,因為Google有幾千個參數,并且不能被獨立的分析。例如:要對兩個參數進行分析,一個參數是web頁面的背景色,另一個是文字的顏色,雖然“藍色”對兩個參數都是合法值,但是如果兩個參數都取“藍色”,那么頁面是不可讀的。

  本文提出的解決方案是將參數分成子集,每個參數子集包含相互不能獨立修改的參數。一個參數子集會與一個包含實驗(s)的層相關聯,不同層的實驗的流量是正交的。每個query可以在N個實驗中,其中N是層的數量 。

  實驗環境

  在討論Google的實驗之前,我們先描述一下我們實驗架構所處的環境,這樣能更清楚的理解我們實驗架構所要設計的目標和所受到的限制。

  宏觀上看,用戶通過它們瀏覽器發送請求與Google交互。請求進入Google的服務系統后,會先后被多個服務處理(運行在服務器上的程序),然后產生面向用戶的結果頁。比如,可能有一個服務決定與查詢最相關的原生搜索結果,另一個服務決定與查詢最相關的廣告(s),還有一個服務將原生搜索結果和廣告結果組織到結果頁,返回給用戶。見圖1。一方面,這種模塊化可以讓我們降低延時(不相互依賴的過程可以并行),顯然,原生的搜索過程與廣告搜索過程是相互獨立的,并能更快速的試驗(每個服務都可以獨立地進行,并且模塊化的測試可以進行更快速的發布)。另一方面,如果要求每個請求最多只進入一個實驗,那么模塊化就需要更精心地設計。可能存在的問題有流量饑餓(上游模塊的實驗可能優先處理了所有請求,導致下游模塊的實驗沒有請求),和偏置(bias)(比如,比如,上游模塊的實驗處理了所有英語的請求,導致下游模塊的實驗就只有非英語請求)。

  

圖1.2

 

  圖1:一個請求經過多個模塊的例子,信息(和時間)都是從左流向右

  每個服務都有二進制推送和數據推送。二進制推送是指發布新的程序(bug修復,性能提升,新特性,等等),它一定時期進行一次(比如,每周)。數據推送更頻繁(比如,按需或是每幾小時推送一次),并且這還涉及了推送更新的數據到相應的程序。數據推送中還包含了默認參數配置,參數是用來配置程序如何運行,比如,控制結果如何展示的服務也許有一個參數是決定頂部廣告塊的背景色。再比如,預測CTR的服務可能有參數是控制學習速度和收斂速度的。程序可能有幾百個參數。新的特性可能會添加一個或多個參數:最簡單的場景是,一個參數可以控制打開或關閉新特性,在更復雜的場景中,也許有多個參數決定新特性如果展示,有數值閾值決定新的特性是否被展示,等等。將程序和數據分離,意味著如果我們可以找到合適的分離方式,我們就可以同時得到快速影響線上服務的通路,和慢速影響線上服務的通路(程序是慢的通路,改變參數值是快速的通路)。

  一個web搜索中的實驗是指將一部分請求流量轉向一個特定的處理路徑,這個處理路徑會改變向用戶展示的內容。一個對照實驗將一部分請求流量轉向一個處理路徑,但它并不改變向用戶展示的內容。我們用數據推送來決定實驗的配置。在數據推送中,有一個文件決定程序的默認參數配置。另一個文件決定實驗所需要改變的參數的值,實驗只用指定實驗所要改變的參數,對于其它參數,都采用默認值。比如,在一個簡單實驗中,它只改變頂部廣告的背景色這一個參數,它可以改變黃色(默認值)到粉色(實驗值)。

  實驗還需要決定實驗所用的流量如何分配。最簡單的分配方式是用隨機流量,即對每個請求都進行隨機分配。但這樣做的問題是如果實驗是用戶可見的改變(比如,改變背景色),那么一個用戶可能就得到不同的用戶體驗(背景色不斷地在黃色和粉色間轉換),這會造成用戶體驗不一致。在web實驗中常用的方法是用cookie作為流量分配的依據,cookie被網站用來定位唯一用戶。實踐中,cookie是機器/瀏覽器相關的,并可能被清除。然而,雖然一個cookie不能唯一定位一個用戶,但對于連續的查詢,它可以提供給用戶一致性的用戶體驗。對于實驗流量分配,我們并不直接對每單個cookie進行分配,而是用cookie取模進行分配:用一個ID表示一個cookie,對這個ID模1000,將模相等的流量聚合為實驗流量,比如模等于42的流量(譯注:42這個例子絕對不是巧合,Hacker必讀的《銀河系漫游指南》中42是萬事萬物的答案)。假設cookie的分配是隨機的,那么隨意cookie的模數的請求數據也應該是大致相等的。在實驗配置中使用cookie的模,也可以很容易地檢查流量之間是否有沖突:實驗1可能會用cookie模1和模2,實驗2可能使用cookie模3和模4,這兩個實驗就會有相近的大小,理論上,是可以進行比較的流量。

  在數據文件中配置實驗,可以讓實驗更快更方便地創建:數據文件是可讀的,并容易手工編輯,不需要進行代碼變更,并可以由非工程師進行創建,而且配置數據的推動會比二進制程序的發布更加頻繁,它使創建僅包含已有參數的實驗更加方便快捷。

  在開發我們的實驗架構之前,我們使用一個簡單的單層實驗框架,在這個架構中,每個請求最多進行一種實驗。先分配Cookie取模的流量的實驗,再分配隨機流量的實驗。上游服務會優先分配流量,所以如果上游(即cookie取模的實驗)進行了很多實驗,那么下游可能會得不到足夠的流量,即流量饑餓問題。除了這些問題之外(包括前面提到的流量饑餓和偏置問題),單層實驗可以滿足我們設計目標中的易用和相對的靈活性。但是在Google數據驅動的文件中,單層的方法沒有足夠的可擴展性:我們無法快速地進行足夠多的實驗。

  實驗基礎設施與框架

  在本節中,我們將介紹重疊實驗框架,它在盡量保留單層實驗框架的優點(易用,快速)的同時,增加了可擴展性,靈活性,和健壯性。我們還實現了一種可控的,定義明確的逐步放量的方式。

  前面解釋過,多因素實驗并不適用于Google的實驗場景,因為實驗參數可能并不相互獨立(比如,粉色的字和粉色的背景)。有了這個限制,我們的核心思路是將參數劃分到N個子集。每個子集都關聯著一個實驗(s)層,每個請求最多會被N個實驗處理(每層一個實驗)。每個實驗只能修改自己層相關聯的參數(即在參數子集中的參數),并且同一參數不能出現在多個層中。

  一個很明顯的問題是如何劃分參數。首先,我們可以根據模塊化的程序(服務)對參數進行子集劃分,不同程序的參數可以劃分到不同的子集中(這會解決前面提到的流量饑餓和偏置的問題)。然而一個程序所有的參數并不一定要在一個參數子集中,我們可以通過分析(比如,我們知道某些參數是相互獨立的)或是通過以前實驗(比如,分析以前將參數放到一起修改的實驗)可以對一個程序的參數進行進一步劃分。

  事實上,我們設計的更加靈活,我們不止是將參數劃分子集,再將子集與層相關聯。為了解釋靈活性,我們引入了一些定義。在流量和系統參數的語境下,我們有三個關鍵的概念:

  域是指流量的一個劃分(一部分流量的意思)。

  層是指系統參數的一個子集。

  實驗是指在一個流量劃分上,進行零個或多個參數的修改,并最后改變請求處理的過程。

  域和層可以相互嵌套。域中包含層。層中包含實驗,層中也可以包含域。在一個層中嵌套域可以使這一層中的參數在嵌套域中進行進一步劃分。開始時,我們有默認的域和層,它有包含所有的流量和參數,在默認域和層中,比如我們可以:

  簡單地將參數分為三層(圖2a),這種情況下,每個請求最多只會同時在三個實驗中,每層一個,每個實驗只能修改相應層的參數。

  我們可以先將流量分為兩個域,一個域只有一個單一層(非重疊域),和一個有三個層的重疊域(見圖2b),在這種情況下,每個請求會分到非重疊域或是重疊域。請求只能在非重疊域或重疊域其中之一。如果請求在重疊域,那么請求最多在一個實驗中(這個實驗可以改變參數集合中的任意參數的值),如果請求在重疊域,那么請求最多在三個實驗中,每層一個實驗。并且對于每個實驗,只能使用對應層的參數。

  

1.2

 

  圖二:重疊分層示意圖

  這種嵌套看起來有些復雜,但它有幾個好處。1. 使用非重疊域可以讓我們同時進行改變大量參數值的組合實驗,這些實驗參數也許并不常一起使用,2. 它允許我們進行不同參數劃分方式。比如你可以劃分出三個域,一個是非重疊的,一個是有兩個層的域(即對參數集合進行一次劃分),第三個域進行其它的劃分方式(即有不同數量的層)。3. 嵌套可以更有效地利用空間,可以根據常用的參數劃分方式,和哪些跨層的實驗經常進行,注意將一個層的參數從一個層移到另一個層是很容易的,只要確認參數可以安全地與原有層的參數值重疊,并注意保證不同層的實驗會被獨立地進行,對于基于cookie取模的實驗,我們用mod=f(cookie, layer)00,而不是f(cookie)00的方式,雖然這種方式增加了復雜性,但它也增加了靈活性。對配置的修改是需要付出代價的,特別是對域的修改,修改域的流量,即是修改實驗的流量,比如如果我們將非重疊流量大小從10%修改到15%,這多出來的5%流量來自重疊域,以前經過重疊域的請求現在會經過非重疊域。

  另一個概念是發布層(Launch layers),發布層與前面介紹的實驗層有下面區別:

  發布層總是在默認域中(比如,它們有全部流量)。

  發布層是對參數的一個獨立劃分,比如,一個參數最多只能同時在一個發布層和最多一個正常層中(一個域中)。

  為了讓發布層和正常層的重復參數配合起來。在發布層中的實驗有著稍有不同的語法。特別是,在發布層的實驗會為覆蓋參數的默認值,作為新的默認值,換言之,如果沒有正常實驗層的實驗覆蓋了默認參數,那么在發布層的行為就像一個普通的實驗,但如果實驗層的實驗覆蓋了默認值,那么實驗就會用這個覆蓋的值,而不是系統的默認值,或是發布層實驗中的參數值。

  發布層的示例在圖2c, d中,通過發布層,我們能以一種標準通用的方式逐步灰度最終全量一個實驗策略,且可以跟蹤灰度過程中實驗效果變化。 通常情況下,每有一個新特性要開始全量時都需要新建一個發布層,當這個新特性最終完成全量時,再將相應的發布層刪除。并且因為發布層實驗的流量一般都比較大,所以它們可以用于測試特性之間的相互影響,雖然理論上我們可以測試正常實驗層的特性相互影響(比如,如果參數在同一層,我們可以手工設置創建實驗,如果參數在不同層,我們觀察實驗的交集流量),但因為在正常層中,實驗流量比較少,交集比較小,所以相互影響很難檢測。

  從前面我們已經了解到實驗和域都是在操作一份流量,(我們稱這種流量為“分配”的流量),為了更有效的進行實驗流量分配,我們提出了兩個不同的概念:分配類型和分配條件。

  我們在第三節討論了兩種流量分配類型,即cookie取模方式和隨機方式,還討論了為了讓層與層之間實現流量之間相互獨立,在cookie取模時加入了層id的信息(mod=f(cookie, layer)00)。我們還支持另兩種流量分配類型,用戶id取模和cookie日期取模,用戶id取模類似于cookie取模,區別僅是對用戶id取模而不是cookie,對于cookie日期取模,綜合cookie和日期的信息后再取模,采用這種方式的話,一個實驗一天內圈定的cookie是固定的,但隨著日期的變更會圈定不同的cookie。在所有的場景中,是沒有辦法配置一個實驗能使特定的cookie或是用戶必通過這個實驗。同樣,在分析實驗結果的時候也要考慮不同抽樣方式的差別。同樣注意,我們當前只支持的四種分類型,但我們也可以支持其它的流量分配類型,比如通過Hash查詢串分流。

  支持多種流量分配類型的主要目的一方面是為了保持處理的一致性,另外也希望可以覆蓋到所有可能的情況,比如因時間變化而表征出來的不同特征。基于這些原因,我們以特定的順序對不同的流量分配類型進行分流:用戶id,cookie,cookie日期,隨機。一旦這個請求被某高優先級分配方式抽中后,其它低優先級的分配方式將忽略這個請求(圖3),雖然這個順序最大化地了一致性,但它也有一個缺點,比如,在同一層中1%的cookie取模流量會比1%的隨機流量大,在極端情況下,我們會遇到流量饑餓問題。在實踐中,一層之中一般只應有一種分流類型,實驗和對比實驗必須使用相同的分流類型,最主要的影響是不同的分流類型實驗需要不同的樣本量(見5.2.1節)。

  在通過流量分配類型選擇一部分流量后,分流條件(condition)通過僅分配特定條件的流量給實驗或域,以達到更高效利用流量的目的。比如,一個實驗僅僅改變來自日語的查詢,那么實驗配置中只抽取日語的流量。我們可以基于地區,語言,瀏覽器等信息設置流量抽樣條件。有了分流條件,一個只使用“日語”流量的實驗,和一個只使用英語流量的實驗,可以使用相同的cookie取模。另一個使用分流條件的場景是灰度測試新代碼(代碼是通過二進制推送發布的),比如,在一股小流量上測試新代碼,以保證新代碼沒有bug,并與預測一致,然后才能放到大流量環境中(灰度環境中,通過錯誤日志和實驗監控方式檢查bug)。為了支持這種使用場景,我們提供了以機器或數據中心為分流條件的分配方式,它進一步限制了一個實驗的流量。雖然灰度實驗無法代替嚴格的測試,但它們是一個有用的補充,因為它既限制了潛在的錯誤,并且它讓新的代碼在真實環境中運行,從而可以遇到各種在測試環境中很難構造的真實請求。

  

圖1.4

 

  圖三:決定請求進入域,層,實驗的邏輯

  分配條件是直接在實驗(或域)的配置中指定的,這允許我們在實驗的創建時基于數據文件對流量分配沖突進行檢測。如在流量分配類型一節中提到的一樣,如果一個請求先滿足了流量分類順序中的一個類型,它不會再考慮下面的分配類型,即使它不滿足這一種分配類型的分配條件(s)。這很重要,最好以一個例子來說明,如果我們通過特定的cookie取模來得到實驗的流量,我們將會得到一個無偏的分配。考慮一下一個指定cookie取模上有兩個實驗,一個分配條件為日語流量,另一個分配條件是英語流量,而這個cookie取模剩余的流量(即不是日語和英語的流量)將不會分配給以cookie分配方式的其它實驗,這是為了避免分配順序后幾種分配方式的偏置,重要的邏輯是不再將上述剩余的流量分配給分配順序后幾種分配方式的實驗了。我們通過將有偏的剩余流量分配一個偏置id來避免偏置。

  圖3中展示了一個請求分配給域,層和實驗的邏輯。這些邏輯都以動態庫的方式實現,編譯鏈接到二進制之中,所以任何修改(比如,新的分配類型,新的分配條件,等等)都會在日常的二進制推送時集成到系統中去,動態庫保證了在整個系統內的一致性,并且從動態庫中自動可以獲取到最新的功能。

  在這個架構下,一個特性的評估和發布過程是類似如下過程的:

  在合適的模塊中,實現新的特性(包括code review,二進制推送,設置默認參數等等,如標準的工程實踐一樣)。

  創建一個灰度實驗(通過數據推送方式),以保證特性可以正常工作,如果不能正常工作,那么可能就要重寫代碼修復這個問題。

  創建一個實驗或是一組實驗(通過數據推送的方式)來評估特性。注意配置實驗涉及指定分配類型和相關的分配參數(比如:cookie取模),分配條件,和特性相關的參數。

  評估實驗指標。根據實驗結果,判斷是否要進行新一輪的實驗,即通過修改或創建新的實驗,或甚至修改代碼從根本上改變特性。

  如果特性可以發布,就進入發布過程:創建一個新的發布層和發布層實驗,逐步的放量這個實驗,并最終刪除發布完的發布層,然后將發布層實驗的相關參數設為系統默認參數。

  工具及流程

  雖然重疊架構是有能力運行更多的實驗,更快速地進行實驗,并能同步優化實驗效果,但只依靠架構還是不夠的。我們還需要工具,研究,和教育過程來支持更快速的實驗。在本節,我們討論幾個關鍵的工具和過程,以及它們如何幫助我們擴展的。

  工具

  數據文件檢查:數據文件的其一優勢是它們可以被自動檢查錯誤,這可以避免一些不合理的實驗運行。我們會自動檢查法語錯誤(所有的必填字段都有并且合法),一致性和約束錯誤(比如,id的唯一性,根據所有的參數判斷是否實驗在正確的層,是否這一層有足夠的流量來支持實驗,流量約束檢查,如果實驗要求的流量已經被另一個實驗使用了,等等,注意當可用的分配條件集合變大時,這些檢查就變的復雜了),和基本的實驗設置檢查(是否實驗有對比實驗,并且對比實驗在相同的層,是否對比實驗與實驗的流量分配方式和規模一致,等等)。

  實時監控:我們用實時監控來檢測基本的指標(比如CTR),我們通過實時監控盡快地發現某個實驗是不正常的,實驗者可以設置監控指標的期望值區間(也有這些指標的默認波動區間),如果監控指標超出了期望的波動區間,那么會觸發自動告警,然后實驗者可以修改期望區間或停止他們的實驗,或調整它們的實驗參數值,但它允許實驗者可以激進地對于可能的潛在的變化進行測試,因為錯誤或預期之外的影響會被很快檢測到。

  實驗設計與選型

  相比基本的對實驗配置的基本檢查外(比如,每個實驗都必須有一個對照實驗,它與實驗使用相同的分流條件),實驗設計和樣本量是更高級的話題。

  Sizing

  如Kohavi論文[7]中所述,樣本量應該讓實驗有足夠的統計意義,可以統計認為有意義的指標很小的變化。在本節中,我們討論以及實驗樣本量,以及實驗依賴的設置,還有一些相關的樣本量的工具。

  一個實驗的有效規模定義為:

  

 

  在工程實踐中,我們主要關注

,但要通過N個和才能影響相關的實驗指標,為了正確確定N值,我們需要知道:

 

  實驗所關注的指標是什么。

  對每個指標,我們想檢測實驗改變的敏感度(θ)值是什么。比如,實驗者想檢測到2%的點擊率變化。

  對每個指標,一個抽樣單元(N=1)樣本標準誤差是(s),實驗大小為N的標準誤差為

 

  Kohavi假設實驗與對照實驗有相同的大小,比如

=2N,那么2N必須大于等于

才能滿足最小變化檢測需求,16這個值是由置信度(1−α,通常為95%)和期望的統計功效(1−β,通常為80\%)決定的。

 

  我們的重疊架構的其一優點是我們可以在每一層創建一個大的比照實驗,這樣它可以被多個實驗共享,如果共享的對照實驗規模比實驗大的多(

,那么我們可以用

而不是2N,這樣雖然樣本量變小為

,卻有著90%的統計功效(1−β)。

 

  在確定實驗規模的過程中,更重要的問題是如何估計標準誤差s,特別是當我們使用很多比率指標y/z時(比如,覆蓋率,有多少查詢是返回廣告的(有廣告返回的查詢/全部查詢量))。問題產生于是實驗的單元與分析的單元不一致時,比如,對于覆蓋率,分析的單元是一個查詢,但對于cookie取模的實驗而言,實驗的單元是一個cookie(一系列查詢),并且我們無法假設來來自同一用戶或cookie的請求(s)之間是相互獨立的,我們的方法是計算s′,即每個實驗的標準誤差,然后以s′來表示s,在上例中,s′是每個cookie取模的標準誤差,且

對于比率指標,我們用delta方法計算s′。

 

  圖4是在不同實驗中,包括cookie取模和隨機流量實驗,對于覆蓋率指標與標準誤差呈

的關系,圖中的斜線即是s,坐標軸上的值出于保密的原因隱去了,但可以看出cookie取模的斜線比查詢的斜線陡峭,比如在相同的準確度下衡量相同的覆蓋率的變化,一個cookie取模的實驗需要比隨機流量實驗大的規模。

 

  

 

  圖四:在分配類型下計算覆蓋度的s的斜線

  因為不同的指標和不同的分配有著不同的s,那么我不應該讓每個實驗者自己去計算它, 我們提供了一個工具計算實驗者指定的關注指標和指標敏感度,分配類型(比如cookie取模或是隨機流量)和他們想要的某種流量(比如,分配條件,比如日語流量),工具就告訴實驗者他需要多大規模流量才可以支持他的要求的實驗。實驗者可以輕松地在流量大小和敏感量之間權衡,有了這個工具,我們可以認為實驗者在運行實驗之前會設置合理的實驗規模。

  為了為我們的實驗規模工具收集數據,我們一直運行一組同質測試(uniformity trials),比如,我們運行許多對比實驗或A vs. A實驗(s)。這些實驗有著不同的實驗規模和分配類型,我們可以用這些結果經驗地衡量我們指標的自然(natural)變化,并可以測試我們計算的置信區間的正確性。

  Trigging, Logging, & Counter-factuals

  回顧一下,流量分配是指分配給實驗的流量,但是一個實驗可能不會對所有分配給它的流量進行新特性服務,相反,一些實驗可能僅在某種請求時被觸發(trigger),比如一個實驗是測試何時應該顯示天氣信息,它可能會得到全部的流量 ,但只有一部分流量的查詢會觸發顯示天氣,這一部分但觸發查詢就稱為觸發集合。

  通常,我們無法僅將觸發集合的流量給實驗,因為要確定請求是否觸發,是需要運行時計算的,這種運行時的計算正是觸發無法實現成分配條件的原因(這個觸發條件很難構造對照實驗流量),所以,重要的工作是記錄事實(factual,當實驗被觸發)和反事實(counter-factual,當實驗可被觸發),反事實是在對比實驗中記錄的,比如在前面的例子中,事實(當天氣信息展示)是記錄在實驗中的,反事實是記錄在對照實驗中的。比如當這個查詢是可以展示天氣信息的(因為它是在對比實驗中,所以實際并沒展示)。這些日志對于實驗樣本量和分析實驗都很重要,因為流量中包括了沒有實驗變化的請求,這些請求會稀釋實驗的作用,在觸發集合上衡量實驗結果會更準確衡量實驗的影響。另外,通過關注于觸發集合的顯著效果,實驗流量的需求可以減少,因為實驗的有效規模是依賴于我們要想檢測的敏感度的倒數

 

  Pre- & Post-Periods

  一個預時期(pre-period)是指在先于開始實驗的一個時期,這時期與實驗有著相同的流量(比如,相同的cookie取模),但沒有實驗的效果,一個后時期(post-period)是類似的概念,區別是它是在實驗之后的,這兩個時期類似于一個對比實驗與另一個對比實驗比較,只是使用實驗的流量,預時期是保證一個實驗與它的對比實驗是實際可比的,而不受其它因素影響,比如,有未捕獲的垃圾流量或是爬蟲,后時期判斷運行實驗是有學習到的效果,這些技術僅能用于用戶id和cookie取模實驗。

  快速分析

  雖然前面提到的架構,可以同時進行許多實驗,并快速地運行一個實驗,但沒有實驗分析工具,一個真正的實驗進程是無法在本質上快速進行的。對實驗工具完整的討論已經超出了本文的范圍,但這里我們討論一個重要的設計目的。

  分析工具最重要的目標是提供實驗者要衡量它們的實驗的指標。在google,我們并不將好多個實驗指標合成一個目標函數,而是查看多個指標,以更徹底地理解用戶的體驗是如何改進的(比如,用戶可以多快解析這個頁面,點擊按鈕應如何移動,等等),注意,實時流量只能衡量發生了什么,而無法看到改變的原因。

  實驗除了正確性和完備性,對一個實驗分析工具的其它重要設計目標包括:

  正確地計算和顯示置信區間:實驗者需要知道是否他的實驗僅是沒有得到足夠的流量(置信區間太寬),或是是否觀察到的變化是統計顯著的。我們研究了很多種計算準確置信區間的方法,雖然無法完整地討論已經超出了本文范圍,僅說明一下我們考慮了delta方法和其它的經驗方法來計算置信區間:將實驗分成幾個子集,從這些子集上統計方差,并注意,一定要觀察多個實驗指標(s)和實驗(s),因為一些指標值會隨機顯示為顯著,所以一定要多檢查。

  一個好的UI,UI必須是易用的,并是易于理解的。圖形化是會有所幫助的,如果要聚合的效果在一定時期內是致的,即使是簡單的走勢圖也能對可視化有所幫助。UI也應提示不合理的比較(比如,比較兩個不同層的實驗),并且UI應該方便地更改對比的實驗,或對比的時期等等。

  支持劃分,聚合后的數值常會有誤導性,比如導致指標改變的原因也許并不是實驗(比如,CTR改變),而是因為一個混合的變化(比如,更多的商業搜索詞)。正如Kohavi所言[4],辛普森悖論的觀察與理解是很重要的。

  擴展性,它必須能方便地添加用戶自定義的指標和劃分,特別是對新特性,已經存在的指標集合和劃分可能是不夠的。

  只有一個工具提供實驗準確的指標意味著我們有唯一的一致性實現,它使用相同的過濾器(比如,移除潛在的爬蟲流量和垃圾流量),這樣,不同的團隊之間就可的CTR值就具有了可比較性。一個唯一的工具也更高效,因為計算會一次完成后,并呈現給實驗者們,而不是每個實驗者進行他們自己的計算。

  教育

  現在我們有了重疊架構和相關工具,實驗設計已經完成了進行更多、更快、更好的技術方面的要求。我們還是要討論一下人的因素。教育在促進健壯的實驗目標中是同樣重要的。在Google,有兩個過程來保證實驗是良好設計的,并且一個實驗的結果是能被理解和傳播的。

  實驗委員會

  第一個過程我們稱之為實驗委員會,它包含一組工程師,他們會審核實驗者在做實驗前提交的一個輕量級的checklist,checklist中問題包括:

  基本的實驗特性(比如,實驗測試什么?它們的假設是什么?)

  實驗的建立(比如,要修改哪些參數,每個實驗或實驗集合分別要測試的是什么?在哪一層?)

  實驗的流量分配和觸發條件(比如,使用什么分配類型和什么分配條件,在多大比例的流量觸發實驗)

  實驗分析(比如,關注哪個指標?實驗者要檢測的指標敏感度是什么?)

  實驗規模和時間跨度(即保證,給定一定的流量,實驗是有足夠的統計量來檢測指標敏感度)

  實驗設計(比如,是否要用預時期和后時期來保證,是否反事實日志正確被記錄等等)

  初次使用的實驗者會通過這些問題學習合理的實驗設計和實驗樣本量,并了解實施一個實驗背后的技術細節。有經驗的實驗者仍會發現checklist仍是有用的。不止于此,這個方法可以將所產生的更好的實驗實踐傳播出來(比如,產生了新的工具來促進實驗,產生了新的評價指標,等等),這個checklist是一個web應用,web應用對于存檔和教育都是有用的,教育作用體現在實驗者可以閱讀以往的checklist來理解相關信息。

  數據解讀

  另一個過程是討論會,實驗者們帶著他們的實驗結果與專家進行討論,討論的目標是:

  保證實驗的結果是有效的。在有些時候,即使有實驗委員會,但在實際的實驗上出錯了,或是有一些意外發生,在這些情況中,討論會中的討論就像是一個debugging的過程,有完整的開發,日志,實驗架構,指標,分析工具的專家集合是解決問題的關鍵。

  有了有效的結果后,要保證對指標集合做整體的觀察,以理解實驗結果到底如何,其它劃分數據的方法或是改變指標也許可以更進一步理解實驗的影響。一些實驗很復雜,需要實驗者追蹤地進行幾次。

  有了完整的結果集合,討論并決定整個實驗是一個正影響或負影響的用戶體驗,有了決定后,決策者可用這個數據(結合策略和戰略信息)來決定是否要發布這個實驗,或提出可能的改進建議,或是放棄。

  討論會對實驗者是一個學習如何理解實驗結果的有益之所,有經驗的實驗者通常不會犯以前犯過的錯誤,并可以預期要得到完全理解的實驗結果,需要什么數據。討論是開放的,將來要進行實驗的人,可以參加以了解運行一個實驗需要了解什么。實驗都會記錄,我們就有了一個知識庫。

  結果

  我們在2007年3月部署了我們的重疊實驗架構(以有很多工具和處理預時期和后時期的架構發布),最終衡量我們整個系統成功的指標是我們在運行更多的實驗,更好地運行,更快得到結果的能力。

  more

  我們可以用幾個標準來判斷我們是否成功地運行更多的實驗,在一個時期上一共運行了多少實驗,這些實驗中有多少發布了,有多少不同的實驗在運行實驗(見圖5)。要說明的是實驗的數目包含了對照實驗的數目。對于運行實驗人數,一些實驗是有多個擁有者的(比如,如果某人離開城市或發生了事),或是將團隊郵件列表中的成員也認為擁有者。不幸的是,我們無法輕松地知道有多少擁有者是非工程師,但有意思的是,非工程師的數據是在增加的,對分布層的數量,我們只計算了使用重疊架構的發布層的數量。在重疊實驗之前,我們用其他的一些機制發布實驗,但它們的頻率在下降。在所有的圖中,y軸上的數據出于保密的原因隱去了(它們是線性比例),但從趨勢上可以明顯地看出,我們系統支持了指數級增加的實驗,發布,實驗者。

  

 

  圖五:實驗,擁有者,發布數量在時間上的趨勢圖

  Better

  另一個衡量我們整體系統工具和系統的指標是判斷是否比以前運行實驗更好,于此我們僅有耳聞,沒有實際的數據,但我們是實驗委員會和討論組的成員,我們見過這個系統發布前后的許多實驗情況,我們觀察的結論是:

  錯誤配置的實驗變少了,盡管我們仍偶爾會遇到日志的問題(反事實)或是詭異的錯誤/失敗情況。

  被遺忘的實驗變少了(比如,有進行了實驗,卻之后忘記了分析實驗)。

  “究竟你是用什么指標衡量CTR的”或是“你用的是什么過濾器”的討論減少了,有一個權威的分析工具,討論的重點現在僅在于對指標進行解釋,而不是確保指標的定義和計算都是合理的。

  更好的合理性檢查,比如有預時期來確保實驗所用的流量是沒有問題的。

  顯然理想的結果是上述問題都不存在,但是考慮到我們有更多的實驗者,而上述問題即在下降,這已經是一個不錯的結果。

  Faster

  最后的一個衡量我們系統成功的指標是我們是否最終更快地得到數據,并更快地做出決策,對于速度,我們還是沒有具體數據,但我們可以討論對實驗速度的觀察,實驗可以分解為下面幾個階段:

  實現一個新特性并對它進行測試,這階段現在是最慢的,所以我們還建立了其它工具(不在本文范圍)來加速創建和測試原型(比如,將下面兩個步驟分離:建立可實驗的版本,和正式可發布版)

  對這個實現的特性創建一個新的實驗,這個階段要花幾分鐘或幾小時來創建,取決于參數的復雜性,和一個少的可以忽略的提交前的檢查時間(幾秒到幾分鐘),創建時的review時間同樣很短,數據推送的時間取決于二進制,時間在1-2小時(包括灰度測試時間)到半天。

  運行實驗的速度取決于實驗的規模和實驗要運行多久才能得到想要的統計顯著值。我們在實驗開始后的數小時就通常就可以對實驗的效果有大致的了解。實驗總的時間跨度取決于:實驗所需要的迭代次數,規模,和緊急性,等等。

  分析實驗的時間長短也不一定。在很多情況下,不需要自定義的分析方法,或是只需要對分析工具進行很小的擴展。在這些情況中,分析速度通常很快(數天)。但在其它情況下,需要自定義的分析方法分析的時間的長度就不一定了。

  概括才言,當前的耗時點有:實現一個實驗,在預時期的運行時間、自定義分析。這些耗時點是我們努力解決的點。

  結論

  在本文中,我們描述了重疊實驗架構、相關工具和教育過程來以進行更多實驗,更好且更健壯的實驗,和更快的實驗。我們并給出了實踐中我們的工作的結果:更多實驗,更多實驗者,更多發布,并更快速且有更小的錯誤了。雖然實際的實現是針對Google,但關于設計的討論對于任何想收集統計數據評估變化的公司都是適用的。

  下面是幾個我們要繼續改進我們實驗架構的方向,包括:

  提供加速實驗新特性的方法和推動一些特別的實驗(不是通過參數表達的實驗)。

  突破一個實驗參數被限制到一個層的規定。特別是,對于數值參數,我們添加了運算操作(比如,乘,加),它們是可傳遞的,也就是可組合的。有了這些操作符,我們可以在多個層用同一參數,只要實驗(s)都只是指定對默認值的操作,而不是覆蓋默認值。

  有的時候我們需要在很小的流量切片上運行實驗,比如小語種上(比如烏茲別克語,斯瓦希里語,譯注:斯瓦希里語是當今非洲最常用的語言之一)。在這樣的小的流量切片上進行實驗,通常很難在一個合理的時間范圍內有足夠大的規模得到統計意義上顯著的結果。

  繼續提供更多新的分配條件(和相關的驗證,以保證健壯性)以更好地對實驗空間使用支持,等等。

  我們將繼續對實驗進行創新,因為實驗越來越多,用數據驅動的決定越來越多。

  感謝:很多參與了本文的工作,并沒有以作者的身份出現。下面下一個不完全的參與者名單:Eric Bauer, Ilia Mirkin, Jim Morrison, Susan Shannon, Daryl Pregibon, Diane Lambert, Patrick Riley, Bill Heavlin, Nick Chamandy, Wael Salloum, Jeremy Shute, David Agraz, Simon Favreau-Lessard, Amir Najmi, Everett Wetchler, Martin Reichelt, Jay Crim, and Eric Flatt。Robin Jeffries, Rehan Khan, Ramakrishnan Srikant, Roberto Bayardo,他們對本文提出寶貴意見。

推薦 打印 | 錄入: | 閱讀:
相關新聞      
本文評論   
評論聲明
  • 尊重網上道德,遵守中華人民共和國的各項有關法律法規
  • 承擔一切因您的行為而直接或間接導致的民事或刑事法律責任
  • 本站管理人員有權保留或刪除其管轄留言中的任意內容
  • 本站有權在網站內轉載或引用您的評論
  • 參與本評論即表明您已經閱讀并接受上述條款
免费陕西麻将游戏 51pk10官方计划 时时彩双胆是什么意思 秒速时时选开奖网 重庆三星走势图 快乐时时计划 在ipad上怎么下载软件 pk10冠军专业单期计划 时时彩稳定赚钱思路 三公是哪三公 快乐十分助手软件下载