一年40萬次實驗，位元組跳動A/B測驗平臺是怎么煉出來的？

2012 年，剛剛建立的位元組跳動便開啟了 A/B 測驗之旅，隨著今日頭條、抖音、西瓜視頻等全線業務的使用，將 A/B 測驗應用在產品命名、互動設計、推薦演算法、用戶增長、廣告優化和市場活動等各方面決策上，據今年 4 月位元組跳動旗下火山引擎技術開放日上透露的資料顯示，位元組跳動每天同時進行的 A/B 測驗達到上萬場，單日新增實驗數量超過 1500 個，覆寫 400 多項業務，隨著公司發展，這些數字還在不斷擴大，僅最近一年就已經做了 40 萬次 A/B 測驗，

那么在位元組跳動里，支撐這些測驗的技術平臺是怎么煉出來的？我們采訪了位元組跳動 A/B 實驗平臺技術負責人王珂，通過他的回復我們可以得到一個初步的了解，王珂將在 2021 年 10 月 21-23 日 QCon 上海站分享主題為《位元組跳動 A/B 測驗平臺演進歷史及實踐》的演講，更多內容可以通過觀看演講進行了解，

InfoQ： 有說法是目前這種形式的 A/B 測驗最早出現于 1990 年代，您認為其核心原理這么多年是否有改變？

王珂： 核心原理基本沒有發生什么改變，仍然是依賴隨機采樣獲取兩個樣本集合，施加不同的策略，采集結果比較和分析，如果要說變化，更多的是應對實際的 A/B 測驗場景，在測驗方式、指標設計和顯著性分析方法等細節上有了更多的探索和演進，

InfoQ： 能否以一個簡單的例子，說明 A/B 測驗如何作業？

王珂： 簡單來說，一個 A/B 測驗生命周期大致分三個部分：A/B 測驗設計（包括測驗內容、預期收益、測驗時長、測驗流量、觀測指標等的確認）、A/B 測驗執行（利用 A/B 測驗平臺的能力完成分流、配置分發、資料回收等）、A/B 測驗結果分析（產出指標資料，顯著性分析，多維下探等，最后形成分析報告），

InfoQ：A/B 測驗適合哪些場景？能運行 A/B 測驗需要哪些必備條件？位元組跳動的 A/B 測驗平臺主要適用于什么場景？

王珂： 通常而言，可以將樣本隨機劃分為互不相關的兩組，同時施加不同策略，并可以提供量化指標衡量策略效果的，都可以進行 A/B 測驗，比較典型的如政策調整，無法隨機將民眾劃分為兩部分，一部分執行新政策一部分執行舊政策，這種就不適合進行傳統意義的 A/B 測驗，而通常會嘗試在一個城市試點新政策，通過 DID 或者 SCM 等分析方法檢驗效果，

位元組跳動的 A/B 測驗平臺立足于服務和支撐位元組跳動內各大業務線的 A/B 測驗需求，當前主要適用于演算法迭代、產品演化、智慧運營等場景，未來也會隨公司的腳步覆寫更多的場景，

InfoQ： 位元組跳動的 A/B 測驗平臺有哪幾個主要部分組成，整個平臺大概經歷了什么樣的迭代程序？

王珂： 經過多年的迭代，位元組跳動 A/B 測驗平臺由最初服務于推薦演算法迭代，到現在包含 A/B 測驗、配置發布、自動調參和探索實驗室四大部分，覆寫了 A/B 測驗的整個生命周期，

InfoQ： 資料采集部分，一般平臺使用的是埋點或日志資料，那么位元組跳動的平臺是通過什么方法實作的？

王珂： 我們的平臺也是基本基于埋點和日志資料來生產測驗資料的，在位元組跳動，埋點和日志資料匯集都有系統化的解決方案，使得我們的 A/B 測驗平臺可以比較容易的給出 A/B 測驗結果，

InfoQ： 是否有一些測驗比較復雜？位元組跳動如何降低復雜性，讓業務人員易于理解和使用？

王珂： 會遇到一些比較復雜的場景，平臺也會嘗試優化產品以降低使用門檻，一個比較典型的案例是演算法側的超參選擇，在機器學習模型中經常會遇到一些超參，需要演算法工程師憑借經驗和 A/B 測驗結果來調整這些超參的取值，傳統做法下，演算法工程師需要花幾個月的時間，通過不停的 A/B 測驗對比調整遴選合適的超參取值，為降低該場景的使用復雜性，位元組跳動的 A/B 測驗平臺通過一些統計學方法，自動化的回圈執行 A/B 測驗，分析測驗結果，預測最優解取值，協助演算法工程師尋找到合適的超參，使得調參耗時由幾個月縮減到幾個禮拜，這也就是我們的自動調參系統，

InfoQ： 人們在做 A/B 測驗時會犯哪些常犯的錯誤 / 陷阱？

王珂： 比較常見的是“連續觀測”，舉個夸張點的例子就是，一個 A/B 測驗啟動起來，使用者每天都會過來看一下是不是指標有顯著正向；直到突然有一天，指標正向了，使用者開心的關掉 A/B 測驗，撰寫上線報告，這種連續觀測，一旦顯著立即決策的做法會令使用者拿到錯誤結論的風險大幅度上升，是不可取的，因此在位元組跳動，A/B 測驗使用方式的宣講是我們需要例行去做的很重要的一個事情，

InfoQ：A/B 測驗，可能因為不同的受眾行為不同，對一家公司有效的東西不一定對另一家公司有效，那么位元組跳動的 A/B 測驗平臺如何具備普適性？

王珂： 一方面，位元組跳動的 A/B 測驗始終以平臺的方式將 A/B 測驗做合理抽象，向不同的業務場景提供測驗能力，考慮到公司較為復雜的產品矩陣，A/B 測驗平臺從誕生至今的一路迭代中始終站在 A/B 測驗最基本的抽象上，以保證其普適性，

另一方面，像指標體系等與業務場景關聯密切的資產，我們既要考慮它可能不具備普適性，而需要做到因業務而異；也要考慮到相似的業務線可能會重復建設相似的指標體系，因此，能夠“將經驗復制一份”也是我們平臺需要頻繁考慮的東西，

InfoQ：A/B 測驗平均耗費時長是多少？如何減少“延時”，以比較快的速度得到結果，這方面您們有哪些可供大家參考的經驗？

王珂： 不同場景，不同目的下，A/B 測驗需要進行的時間也會有比較大的差異，例如搜索演算法的小流量測驗是為了快速探索演算法迭代的可行性，幾天或幾個小時便能給出有價值的結果；而產品界面的變更，為了規避所謂的新奇效應，避免有些用戶出于好奇心而帶來的短期指標上揚，測驗可能會開啟幾個禮拜甚至幾個月，比較典型的 A/B 測驗通常會持續 1-3 個禮拜，

通常而言一個 A/B 測驗需要耗費多久，和 A/B 測驗內容、測驗設計有關，相比而言，減少一個 A/B 測驗消耗的時間不如提升 A/B 測驗的并發性，讓系統同時容納更多的 A/B 測驗，對產品的整體迭代效率提升更加有益，

InfoQ： 位元組跳動 A/B 測驗平臺有哪些未來規劃？

王珂： 有三個比較重要的方向是我們的 A/B 測驗平臺在當前比較關注，在未來會加大力度投入的，

一個是對 A/B 測驗分析能力的更大力度支持，開 A/B 測驗在位元組跳動相對是比較容易的，但是 A/B 測驗分析和更多有價值資訊的挖掘卻沒有那么容易，曾經有一個測驗，指標上看并沒有顯著的提升，然而在一個特殊的維度上我們發現了顯著的效果，進一步分析推理之后我們對策略進行了調整，最后還是拿到了比較大的收益，由此可見分析能力對于測驗平臺而言的重要性，

另一個是場景化支撐的能力，位元組跳動的產品矩陣復雜度越來越高，不同的業務領域對 A/B 測驗有著不同的訴求，相較于能力堆砌功能強大的巨無霸，一個清新簡潔切合業務屬性的系統對于業務迭代效率的提升更加有益，這也是我們架構演進的必經之路，

最后一個也是最重要的一個，是方法論的探索和儲備，拓寬 A/B 測驗的邊界，應對今天和明天我們在業務上會遇到的新問題，例如在社交領域如何更好的解決網路效應等，

下面是測驗資料，對于做【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！

最后： 可以在公眾號：傷心的辣條 ！ 免費領取一份216頁軟體測驗工程師面試寶典檔案資料，以及相對應的視頻學習教程免費分享！，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，

學習不要孤軍奮戰，最好是能抱團取暖，相互成就一起成長，群眾效應的效果是非常強大的，大家一起學習，一起打卡，會更有學習動力，也更能堅持下去，你可以加入我們的測驗技術交流扣扣群：914172719（里面有各種軟體測驗資源和技術討論）

喜歡軟體測驗的小伙伴們，如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！

好文推薦

轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！

面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…

面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…

什么樣的人適合從事軟體測驗作業？

那個準點下班的人，比我先升職了…

測驗崗反復跳槽，跳著跳著就跳沒了…