起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從工業化到智能化，未來AB實驗的終局
編輯導讀：工業化時代下的AB實驗對互聯網公司來說，它的重要性已經得到了時代的驗證。隨著工業化向智能化過渡的這一過程中，AB實驗將會迎來什么樣的結局，趨勢將會如何？本文給你答案，我們一起來看看。
前幾天讀到字節的一篇文章《9年70萬次實驗，字節跳動首次揭秘A/B測試》 ，文章內容暫且不論，主要想聊下這個標題。
實驗方面的權威著作《Trustworthy Online Controlled Experiments》將實驗平臺按成熟度分成了crawl, walk, run, fly四個階段。
中國互聯網公司中，字節與快手其實都早已進入了其中的最高階段fly，即AB實驗的大規模自動化，乃至事必AB。
這之后，筆者認為AB實驗的次數已不再是一個多么重要的數字，而平臺應該向更高的階段去發展，從工業時代進入到智能時代。
而在新的時代里，實驗的數量實際上不會上升，反而會下降。
因為平臺將對海量的實驗數據進行知識挖掘與發現，沉淀出更系統的業務知識體系，指導后續的策略迭代（可類比智能駕駛的L2階段），并最終構建出一套預測體系，在實驗之前，便對大量實驗評估出其正負向結果（L4/L5階段）。
本文將剖析工業時代實驗平臺存在的問題，并探討未來智能時代對這些問題的解決路徑。
一、工業時代的A/B實驗：單點模式下的效率與認知兩大難題
1. 工業時代實驗平臺的設計目標-單點模式
工業時代實驗平臺的特征是大規模、自動化。
平臺通過一系列通用模塊實現了各種實驗低成本、大規模的并行測試，保障實驗結果互不干擾（所謂“正交”），同時還給出詳盡的實驗數據分析及顯著性檢測以供決策。
上述模式以單個實驗作為其設計與操作的單位，每個策略單獨開實驗，單獨看效果。
更深層次地，筆者認為，整個實驗平臺以低成本測試單個想法為其設計目標。甚至AB這個名字，也側面體現了低成本的目標。
因為統計實驗其實有很多方法，A/B只是其中最簡單，理解成本也最低的一種實驗，正因如此才最有利于大規模實現，而A/B也成了實驗平臺的代名詞。
2. 單點模式下失控的成本：缺乏預判
但這個設計目標中的成本，考慮的僅是實驗的實施成本，并沒有考慮業務成本。
遺憾的是，業務成本才是總成本中的主體部分。
一個產品feature進行實驗的業務成本其實是相當高的，尤其是其中的時間成本。
一個產品idea從創意到PRD、評審、到研發、封版、發版，要經歷幾周，然后用戶更新版本，DA進行實驗分析，業務決定是否推全。
整個流程走下來，最快也要三周，經常需要一個月以上。
這樣的速度，好像與我們平時說的快速迭代并不相符。
看起來，大廠的快速迭代可能更多是通過高并發來實現的，字節9年70萬次實驗，也就是平均每天200+實驗，我好像明白了什么。
那么，如何才能降低業務成本呢？從實驗策略各階段所占的人天數來看，業務成本最主要是從研發階段才開始增加的。
所以降低成本，提升效率的關鍵問題在于預判，即在決定研發前，預判該想法能夠實驗正向的概率。
3. 單點模式下迭代的難題：難以歸因
上面的環節其實還沒有說完，一個策略往往不是上了實驗就能正向的。
業內的基本事實是，大部分實驗都是負向或不顯著的，且隨產品的不斷完善與成熟，實驗要正向變得愈加困難。
而當前期已投入大量成本時，常會選擇繼續迭代。
隨著業務與實驗的發展，負向迭代的需求也愈演愈烈，繼續推高了成本，同時又帶來了新的問題，如何確定實驗迭代的方向？
迭代方向探索這個問題，往往要基于DA對原實驗負向的歸因。
從本質上來說，實驗歸因問題，是要找到策略變量與結果變量之間缺失的因果鏈條。
即，我們通過實驗已知實驗策略A導致關鍵指標Y正向或負向的變化，希望知曉其影響路徑，比如找到中間變量B或C，有A=>B, B=>C, C=>Y。
而負向實驗迭代的問題，則是已知實驗策略A導致關鍵指標Y負向，希望找到其變體A’，能使Y正向。
目前解這類問題的一種自然思路是先嘗試歸因，理解清楚可被更直接操控的中間變量B或C后，通過調整策略為A’，來影響B或C，最終使得Y正向。
于是，我們可以把歸因視為迭代的基礎。
對于統計不顯著的實驗，是否推全要case-by-case具體分析。
但依據經驗法則：如果該feature增加了產品復雜度，提高了用戶認知成本，一般不建議推全（Occam’s Razor: 如無必要，勿增實體）。
否則各種不顯著實驗推全，產品會變得越來越復雜。
實驗歸因問題往往比較困難，有兩個難點，都與實驗分析的單點模式有關。
1）實驗歸因是個構造性問題，需要構造出中間變量
那用什么方法來構造呢？目前DA側在進行歸因時，更多是通過維度下探來進行定位，但嚴格來說定位不是歸因，未必能歸結到原因。
下探時也時常缺乏好的分析框架作為指導，采用諸如用戶畫像之類的常用維度，實際可能與問題關系不大，我把這種方法稱之為旁（yuan）敲（mu）側（qiu）擊（yu）法。
還有的采用遍歷窮舉法，將常用維度全都下探一遍，如果能找到相關的則是萬幸，找不到那對于業務方也算有了交代，之后的迭代方向就交給業務自己去拍腦袋吧。
實際上，要解決歸因問題，需對業務機制有深入理解，本質上構造出整個因果關系鏈相當于建立了一個業務模型。
這除了需要對業務具備基本認知，還需對相關實驗進行研究與歸納，從中抽象出業務模型。
2）實驗歸因常常是個欠定問題
所謂欠定是說，實驗結果之所以表現為這樣，原因可能是B1，也可能是B2或C3。
單個實驗蘊含的信息可能不充分，不能唯一確定出是哪個原因。
實際上，歸因問題常常需要一個歸納-演繹的迭代過程（如下圖），需要有新的數據輸入才能更好判斷。
這可能需要設計新的實驗，或通過更多相關實驗的研究，才能有“唯一”指向性，更嚴謹地得到結論。
因此，歸因問題不是僅靠邏輯推理就能解決的，而需要分析師經過大量實踐，刻意練習與思考。
這首先需要我們有更中心化的知識沉淀與挖掘，擺脫單點模式，將大量實驗的結果信息整合起來，才能有big picture，從中獲得洞察，有更大的自信來判斷究竟是怎么回事，并保障分析師解讀的可靠性與一致性（consistency）。
由此可見，工業時代，我們對于實驗平臺的理解，往往停留在工程系統上，更多將其理解為一個功能性與評估/驗證性的工具，因此未能很好降低業務成本，從根本上提高業務發展的效率。
提效的關鍵問題在于預判與歸因。
我們如何能在實驗前就較好預判實驗成功的概率，從一開始就排除掉一些大概率負向實驗？
同時，當負向發生時又如何更有效地找到迭代路徑？
這些問題，需要智能時代來解決。
二、智能時代的A/B實驗：網絡協同下預判與歸因雙重引擎
1. 智能時代實驗平臺的設計目標
智能時代的實驗平臺具有一個硬幣的兩面。
- 一面是工程視角下的實驗平臺，即進行實驗的基礎設施，包括流量分配，數據評估等等，主要由工程團隊來負責；
- 另一面則是業務視角下的實驗平臺，是通過實驗來最優化業務發展整體效率的工具。
因此需要配備預判與歸因兩大智能引擎，以及DA/DS的介入。
那么預判與歸因這兩個問題又該如何解決呢？
從強化學習的EE框架來看，工業時代實驗平臺上，每個實驗都是單點實驗，只有Explore（探索），沒有Exploit（利用）。
智能時代則將更多利用實驗之間的網絡協同來進行Exploit，我認為有兩個潛在的方向：
表層是數據驅動的方法，目前階段最主要是利用實驗策略的相似性進行遷移學習。
底層則從第一性原理出發，假設我們可以抽象出一些普適的，有業務意義的關鍵概念，如用戶體驗等心理變量，建立分析框架，同時結合實驗數據等各類型數據，進行分析與度量，從而預判實驗的正負向，并在同時解決歸因問題。
2. 表層策略：遷移學習
遷移學習是機器學習的一個子領域，可以最大限度地利用有標注領域的知識，來輔助目標領域的知識獲取和學習。
比如，國際象棋和中國象棋比較相近，有部分棋子相同、走法相近，計算機學會了國際象棋，運用遷移學習的方法，只用觀摩較少的棋局，就可以學會中國象棋。
遷移學習的核心在于，找到源領域和目標領域之間的相似性，并加以合理利用。
這里的源領域和目標領域，可以認為分別對應于我們已有的實驗，和正準備進行的實驗。
例如短視頻巨頭快手，目前已有不少產品，國內有主App、極速版。
字節作為App工廠，產品就更數不勝數。另一方面，同一產品內的不同產品模塊，也常有共性，比如短視頻App的不同Feed間，這些都提供了相似性。
就使用場景的不同，這里的遷移學習又可分為兩類：
1）歸納式遷移學習（inductive transfer learning）
在這種學習方法中，兩個實驗對每個個體產生的效果可以不同（源Task與目標Task可以不同）。
因為不同，就要求在目標領域中必須有一些已標注的數據，才能進行學習。
實踐中，上面提到有一些新App用戶量較小，做實驗常有不置信的問題。這一問題歷史上曾經嘗試過一些方差縮減（variance reduction）方法，但實際對方差的降幅有限，不能根本上解決問題。
更可行的思路應該是結合更大的數據集（核心App相似實驗的數據），進行多任務學習。
具體需結合實際場景，嘗試基于實例的學習算法、基于超參數的學習算法等，這里不再贅述。
2）轉導式遷移學習（transductive transfer learning）
在這種學習方法中，需假設兩個實驗對每個個體產生的效果相同。
但在不少情況下，這個假設還是過于強了，比如動圖實驗在發現頁與關注頁的表現就不一樣。
實踐中，我們需要研發一些方法來判斷該假設是否合理。
由此可知，遷移學習目前對于我們的場景仍有較大局限性。
- 首先該方法要求此前已有相似實驗，才能進行遷移，適用場景相對??；
- 其次，歸納式遷移學習需要當前實驗已有樣本，這可以解決小樣本實驗的置信問題，但不能事先進行預測。而轉導式遷移學習在不少場景下假設過強，實踐中，也需要研發方法來判斷假設是否合理；
- 最后，遷移不能解決歸因問題，不能直接帶來認知。
因此，筆者認為遷移學習可以在恰當場景下作為預測系統的重要補充，在有相似實驗的場景下，預測或能更準確。
但我們還需要研發更好的方案，作為實驗決策系統的主戰場。
3. 底層策略：業務結構模型
在給出預判問題的解決方案前，讓我們先回顧一下，產品經理是如何做類似決策的？
以產品聞名的騰訊有一套基于用戶價值的產品方法論，提倡一切以用戶價值為歸依，通過將自己帶入普通用戶，人同此心地去感受與體驗產品，思考產品對于用戶的價值。
這種方法特別強調同理心，即“一秒變小白”的能力，產品經理快速將自己對產品的所有已知信息抹除，讓自己和目標用戶具有相同的視角。
時刻審問自己：如果我是用戶，會使用這個功能嗎？一些名家的原話如下：
① 馬化騰：任何產品的核心功能，其宗旨都是能對用戶有所幫助，能夠解決用戶某一方面的需求，如節省時間、解決問題、提升效率等，而產品經理就是要將這種核心能力做到極致，通過技術實現差異化。
② 張小龍（在提到微信新上線的7.0版本時）：我在新舊版本切換使用2個月后，我就不愿意切換回舊版本了 ，所以我想想用戶會喜歡這個版本，只是需要時間來適應。
③ 張小龍：個人對用戶體驗的目標是，做到“自然”?！白匀弧笨赡苋菀讓е滦W，因此這里想強調的是，“自然”的思維方式一般是需要長期的非常理性的訓練才能獲得，而不是突然幻想自己獲得了一種使用“自然原則”的能力。
記得知乎上有個問題問“喬布斯為什么能憑直覺知道該怎么做”。
我認為沒有任何人有天生的可重復的直覺來立即成為一個領域的專業人員。
比如，對于復雜事物，如何“抽象”為一個簡單模型，是需要大量案例鍛煉的。
但是，如果經過一萬小時的有意識的朝某個方向的訓練（比如對“自然”的反復思考和實際工作練習），并且是極為理性的思維和實踐訓練，是可以獲得一些直覺的。
大量的理性訓練有助于形成一種對同類事物的識別模式，這種模式形成直覺。
比如大部分中國人其實是沒有經受過“簡單是美”的訓練的，表現在現實中，很多人其實是很難接受一套極簡主義的裝修風格的居室的。
只有當對“極簡”有反復體驗和思考，才能將“簡單是美”變成骨子里的審美觀，并體現在設計中。
俞軍公式：產品的用戶價值=（新體驗-舊體驗）-替換成本。
筆者自己高度認同上述方法論，但也認為這套方法用于實驗預判時會存在一些問題。
- 實驗正負向的問題，很需要定量思維，因為都是各種因素的權衡交互，一些定性的方法實踐中往往不能給出直接的決策建議；
- 這套方法不太scalable，按張小龍與俞軍的說法，要做好產品決策，需要經過反復思考，一萬小時的刻意練習才能練就相應的直覺，構建心理表征。所以這套方法，對人的素質與經驗要求有點高，且掌握之后，也無法高效地傳遞給他人。
我們認為，從歷史趨勢來看，未來的決策方式會更分布式、更scable，在基本的理論框架下，新的實驗不斷創造新的數據，從而不斷迭代、更新原有的決策模型。
筆者在一開始接觸產品分析時，直覺上便希望建立這樣一套決策體系（雖然被告知很難、不可能），一年后因為一些際遇，始有心得，提出一套用戶體驗（UE）結構模型。
之后近兩年的時間里，有機會時便去預測各種實驗的結果，驗證該理論，看起來它多少經受住了時間的考驗，雖然過程中需要技巧，并更完善的度量結果。
幸運的是，筆者發現，這一模型恰巧也是解決許多實驗歸因問題的關鍵所在。
歸因問題需要我們建立一個合適的分析框架作為瞄準器，而不是常規性地拆分各種常用維度，這個框架需要切近業務場景，而對于產品實驗的歸因，最直接的不就是產品交互，產品體驗的角度嘛。
所以，UE結構模型，恰好提供了這樣的工具，來幫助我們分解相關問題。
更一般地，對于各種業務場景的實驗，我們可嘗試構建相應的業務結構模型。
這個模型包括兩部分，一方面有一個合理的理論框架，連接了關鍵變量Y及其主要影響因素Bi。
然后我們考察實驗策略A如何影響B，以及最終對Y的綜合影響。
另一方面我們需要能定量刻畫Bi，通過大量實證數據，來自AB、科學實驗或是用研、用戶反饋等。
具體的業務結構模型不一而足，但不少重要的模型基于一定的心理變量，這些變量以前往往未被很好探究并賦予結構，當然我們需要這些變量有一定的信度與效度，從而是真正有意義與可測量的。
這當中最通用的有用戶體驗結構模型，用戶心智模型等。
用戶體驗更適合解決當前產品的形態優化問題。用戶需求與心智模型則更多應用于新產品的成敗這樣一個更復雜與困難的問題分析中。
在之后的一系列文章中，筆者將不揣淺陋，更詳細地闡述一些業務結構模型，來初步實現實驗的預判與歸因。
預測體系的好處是可證偽，也歡迎大家給出各種case，來驗證這種理論，更新我的認知。
#專欄作家#
作者：孟敬慈，快手數據科學家
本文公眾號：趙小洛洛洛，人人都是產品經理專欄作家。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Pexels，基于CC0協議
- 目前還沒評論，等你發揮！
