作者 | gongyouliu

編輯 | gongyouliu

我們在上一章《推薦系統(tǒng)的效果評估》中提到了推薦系統(tǒng)在線評估的重要性。我們知道了在線評估的指標才是最真實、最可靠的。一般來說，當算法工程師想優(yōu)化某個推薦算法時，會構建一個新的推薦算法，如果通過離線評估指標發(fā)現(xiàn)效果比線上的算法好，這時該怎么做呢？是直接全盤替換線上算法嗎？

答案顯然是否定的。直接取代是非常粗暴的做法，我們不能保證新算法的在線指標一定比老算法好（上一章我們講過，離線指標好的算法在線指標不一定好）。比較好的做法是同時將這兩個算法上線到產品中，通過運行一段時間來對比線上指標，看看具體的指標數(shù)據才最終決定新算法是不是更好，這就是本章要講的AB測試。

本章我們對AB測試做一個比較全面的介紹，我們會從什么是AB測試、AB測試的價值、推薦系統(tǒng)的AB測試實現(xiàn)方案等3個方面來講解AB測試技術。

AB測試在推薦系統(tǒng)算法迭代中起著非常關鍵的作用，是推薦系統(tǒng)非常核心的支撐能力，因此作者花一章的篇幅來詳細介紹AB測試相關的原理和技術。希望本章能夠幫助讀者更好地理解AB測試的原理和價值，幫助讀者在具體業(yè)務場景中用AB測試這個有效的工具來提升推薦系統(tǒng)的用戶體驗，為業(yè)務創(chuàng)造更大的價值。

16.1 什么是AB測試

AB測試的本質是分離式組間試驗，也叫對照試驗，在科研領域中已被廣泛應用(它是藥物測試的最高標準)。自2000年谷歌工程師將這一方法應用在互聯(lián)網產品以來，AB測試越來越普及，已逐漸成為衡量互聯(lián)網產品運營精細度的重要體現(xiàn)。

簡單來說，AB測試在產品優(yōu)化中的應用方法是：在產品正式迭代發(fā)版之前，為同一個目標制定兩個(或兩個以上)可行方案，將用戶流量分成幾組，在保證每組流量在控制特征不同而其他特征相同的前提下，讓用戶分別看到不同的設計方案，根據幾組用戶的真實數(shù)據反饋，科學地幫助我們進行產品迭代決策(比如你想優(yōu)化登錄頁面的海報顏色，覺得藍色比紅色好，就可以針對兩組用戶，一組海報用紅色，一組海報用藍色，其他都相同，進行AB測試)。AB測試原理如下面圖1。

AB測試是一種科學的評估手段，具備概率統(tǒng)計學理論的支撐。這里我簡單解釋一下原因。概率論中有一個中心極限定理，意思是獨立同分布的隨機變量的和服從正態(tài)分布。對于AB測試，我們比較的是兩組樣本的平均表現(xiàn)，AB測試保證A、B兩組某個因素不一樣(這個就是我們要驗證的優(yōu)化點)，A、B兩組其他很多未知影響因素一樣，當A、B兩組樣本足夠多時(這時不同樣本的同一因素是獨立同分布的隨機變量)，這兩組樣本相同因素產生的效果是滿足同一正態(tài)分布的，因此可以認為對要驗證的變量的作用是相互抵消的，這樣待驗證因素(即我們的控制變量)的影響就可以比較了，因此我們就可以通過AB測試實驗來驗證優(yōu)化是否有效。

16.2 AB測試的價值

最近幾年增長黑客的理念在國內互聯(lián)網盛行，有很多這方面的專業(yè)書出版，很多公司甚至設立了CGO(首席增長官)的高管職位。增長黑客思維希望通過從產品中找到創(chuàng)造性的優(yōu)化點，利用數(shù)據來驅動產品優(yōu)化，提升用戶體驗及收益增長，最終達到四兩撥千斤的效果。隨著公司業(yè)務規(guī)模及用戶的增長，利用數(shù)據來驅動業(yè)務發(fā)展越來越重要。增長黑客本質上就是一種數(shù)據驅動的思維，并且有一套完善的技術管理體系來科學地驅動業(yè)務發(fā)展，而這套體系中最重要的一種技術手段就是AB測試。

AB測試可以很好的指導產品迭代，為產品迭代提供科學的數(shù)據支撐。具體來說，AB測試的價值主要體現(xiàn)在如下4個方面。

16.2.1 為評估產品優(yōu)化效果提供科學的證據

前面說過，AB測試是基于概率論與統(tǒng)計學原理之上構建的科學的測試技術，有很強的理論依據。

AB測試也經歷過多年實踐的檢驗，被證明是有效的方法。前面提到過AB測試是藥物測試的最高標準，在藥品制造業(yè)得到了很好的使用和驗證。同時，各大互聯(lián)網公司都大量使用AB測試技術，為整個互聯(lián)網的發(fā)展提供了很好的榜樣和示范作用。

16.2.2 借助AB測試可以提升決策的說服力

因為AB測試是有統(tǒng)計學作為理論基礎，并且又有工業(yè)上的實踐經驗作為支撐，利用AB測試得到的結論具備極大的說服力。因此，在用數(shù)據說話上，大家在意識形態(tài)上更容易達成一致，這樣就可以讓產品迭代更快的推行下去。

16.2.3 AB測試可以幫助提升用戶體驗

任何涉及到用戶體驗、用戶增長相關的優(yōu)化思路都可以通過AB測試來驗證，通過驗證得出有說服力的結論，從而推動產品朝著用戶體驗越來越優(yōu)的方向發(fā)展。

16.2.4 AB測試可以幫助提升公司變現(xiàn)能力

搜索、推薦、廣告、會員等涉及到收益相關的產品及算法都可以通過AB測試來驗證新的優(yōu)化思路是否可以提升盈利性指標。其中盈利性指標可以根據公司業(yè)務和發(fā)展階段來定義。

總之，一切涉及到用戶體驗、用戶增長、商業(yè)變現(xiàn)的產品優(yōu)化都可以借助AB測試技術，驅動業(yè)務做得更好，AB測試是一種科學的決策方式。

既然AB測試這么重要，大家肯定想知道怎么在具體的業(yè)務場景中實現(xiàn)AB測試的能力。由于本章主要是講解推薦系統(tǒng)的AB測試，因此，我們在下面一節(jié)來具體講解推薦系統(tǒng)的AB測試實現(xiàn)方案。

16.3 推薦系統(tǒng)的AB測試實現(xiàn)方案

基于16.1節(jié)中提到的AB測試的實現(xiàn)原理，再結合推薦系統(tǒng)的特性，我們給出一種通用靈活的推薦系統(tǒng)AB測試的實現(xiàn)方案，具體實現(xiàn)原理及業(yè)務流程見下面圖2，下面我們結合該圖來具體說明其中的思路與方法。

在進行詳細講解之前，我們先對圖中4個重要概念進行說明，方便大家更好地理解圖中流程及后面的細節(jié)講解。

• uid：用戶的唯一識別id
• biz：業(yè)務標識，代表什么場景的推薦算法，比如首頁個性化、詳情頁關聯(lián)推薦等
• alg：具體的算法標識，比如協(xié)同過濾、FM、深度學習等
• url：某個算法的服務接口URL

16.3.1 AB測試的核心模塊

上圖下面綠色虛線圈中的兩個模塊就是AB測試必須具備的兩個核心模塊，下面我們來詳細說明各個模塊的功能。

• AB測試管理模塊

AB測試管理模塊的目的是讓產品經理、運營人員或者算法開發(fā)人員方便快速地創(chuàng)建AB測試實驗，增加新的AB測試分組，調整AB測試方案各個分組的比例，讓AB測試運轉起來。同時也用于管理AB測試平臺用戶創(chuàng)建、權限管理，讓用戶具備編輯、拷貝、使用AB測試實驗的能力，做到高效易用。

為了方便操作，實驗管理模塊一般會提供一個UI界面，具體的管理界面怎么做，可以根據具體業(yè)務來實現(xiàn)，一般也不會很復雜，下面圖3就是作者曾經負責的一家公司的AB測試管理界面（其中最下面的流量比例就是各種算法對應的比例，圖3這里更復雜一點，將不同召回、排序算法的組合看成是一個完整的推薦算法）。

簡單的AB測試管理模塊也可以是一個簡單的配置文件，如下面圖4。最好將這個配置文件做成一個web服務，可以在瀏覽器中訪問、修改，這樣更加方便。其實最簡單的方式是將這個配置文件作為下面要講到的AB測試分組模塊代碼工程中的一個配置文件，這個時候修改就比較麻煩了，只能算法工程師或者運維人員操作（一般產品、運營是不會修改代碼的），修改完成后還需要對AB測試分組服務進行重新發(fā)布。

• AB測試分組模塊

分組模塊的目的是根據各種業(yè)務規(guī)則，將用戶流量分為A、B兩組(或者多組)。可以說分組模塊是AB測試最核心的模塊，好的AB分組方案可以讓流量分配得更均勻隨機。復雜的AB測試場景需要具備根據用戶、地域、時間、版本、系統(tǒng)、渠道、事件等各種維度來對請求進行分組的能力，并且保證分組的均勻性和一致性。本章我們只考慮對uid進行分組的最簡單的AB測試場景，在一般情況下也夠用了。

分組模塊的難點是怎么分組才能保證用戶是真的按照AB測試管理人員配置的各個算法的比例進行分組的。這里我簡單說明一個非常簡單的實現(xiàn)方案，這個方案可以大致保證按照管理人員指定的比例進行分組，并且同一個用戶每次分到的組是不變的（只要分組比例不變）。假設有兩個推薦算法進行AB測試，分別是alg_1、alg_2，配置的比例是60%：40%。那么可以將用戶id先進行hash（字符串有hashcode方法可以獲得對應的hash值）獲得一個長整形數(shù)值d，然后計算d % 100，根據計算得到的值來進行分組。如果 d % 100 ∈ （0, 59），那么該用戶就屬于alg_1這一組，如果 d % 100 ∈ （60, 99），那么該用戶就屬于alg_2這一組。

上面這個方法也可以非常簡單地推廣到多個算法進行AB測試的場景。這里提一下，利用用戶id進行hash可能得到的結果分布不夠隨機，導致最終alg_1：alg_2 與 60%：40%差距較大，這時可以自己構造一個定制化的hash函數(shù)，具體怎么構造這里不詳細講解，讀者可以思考一下。

AB分組模塊一般是通過提供一個接口來實現(xiàn)，方便推薦系統(tǒng)web接口服務來調用，獲得用戶對應的具體的分組（算法）。下面圖5就是作者之前實現(xiàn)的一種AB分組服務接口，這個接口將產品中所有的推薦算法業(yè)務（biz）對應的分組都展現(xiàn)出來了。

16.3.2 AB測試的業(yè)務流程

上面對AB測試的核心模塊進行了簡單介紹，下面對上面圖1中標注數(shù)字的核心流程進行說明，方便大家基于數(shù)據流向更好地理解推薦系統(tǒng)AB測試的流程。圖中大部分大家應該能夠看懂，下面我們綜合講解幾個核心流程（按照圖中數(shù)字從小到大的順序，這個順序也代表了真實的數(shù)據流向順序）。

16.3.2.1 新服務注冊備案

這對應圖1中的-1代表的階段。這個階段說的是算法工程師已經實現(xiàn)了一種新的推薦算法，并且將這個算法部署好了，現(xiàn)在可以用于具體的推薦業(yè)務進行AB測試了。這時就需要將該算法相關的信息注冊到注冊中心，方便其它模塊訪問（類似產品生產好了就可以上架了，這樣顧客就可以購買了）。當然，更簡單的AB測試系統(tǒng)可以不需要注冊中心，可以通過文檔系統(tǒng)（甚至是口頭溝通）來同步信息。

16.3.2.2 配置待AB測試的算法比例

這對應圖1中的0代表的階段。這個階段說的是AB測試管理人員想進行新的AB測試了，他需要配置某個推薦場景（比如首頁個性化推薦）中各個進行AB測試的算法的比例。一般新上線的算法，我們需要配置比較低的比例（比如5%），避免新算法上線效果不好，對用戶體驗和收益帶來影響。

當某個推薦場景的新AB測試配置好了，AB測試就生效了。之后如果有新用戶來使用APP的該推薦場景，這時就進入了在線AB測試階段。

上面我們講解的兩個階段（對應圖1中標注-1、0的兩個階段）其實是AB測試的準備階段，下面將要講解的才是真正的AB測試過程。

16.3.2.3 用戶使用產品上的推薦服務

這對應圖1中的1、2兩個階段。這時用戶就會請求推薦系統(tǒng)web服務接口，這個接口的目的是將該用戶的最終推薦結果反饋給用戶，這樣用戶就可以在產品的界面上看到給他的推薦結果了。請求的過程涉及到很多服務訪問，具體我們在下面16.3.2.4、16.3.2.5兩小節(jié)中說明。

16.3.2.4 推薦接口獲取用戶關聯(lián)的算法

這對應圖1中的3、4、5、6四個階段。推薦web服務接口將uid、biz傳遞給AB測試分組模塊，分組模塊基于AB測試配置人員配置的該場景下各種算法的比例計算出該用戶對應的算法（alg），然后從服務注冊中心獲得二元組對應的算法url，最后將返回給推薦系統(tǒng)web服務接口。這一步獲取的主要信息只有兩個：一個是具體的算法alg、一個是算法對應的接口url。

16.3.2.5 推薦接口將推薦結果反饋給用戶

這對應圖1中的7、8、9、10四個階段。當推薦系統(tǒng)web服務接口有了alg、url，它就知道怎么為該用戶去請求對應的推薦列表（這里的url對應圖1上面一排最右邊的推薦系統(tǒng)服務A或者推薦系統(tǒng)服務B，具體要看該用戶被分配到哪個測試組，這里的推薦系統(tǒng)服務A、B一般只會返回包含推薦item_id的列表，并不會包含其它額外信息）。當獲得了該用戶的推薦列表后，推薦系統(tǒng)web服務會將推薦列表組裝成合適的數(shù)據結構并將最終的推薦結果在APP上展示給用戶，這樣用戶就能看到自己的推薦了。

推薦系統(tǒng)web服務接口返回的推薦結果會包含各種信息，比如物品的id、標題、海報圖、等等。總之，用戶在界面上看到的與推薦的物品相關的一切信息都會包含在接口返回的JSON結構體中。下面圖6就是返回的一種可行的數(shù)據結構。

圖6接口返回參數(shù)中包含biz、alg兩個字段，它們是用于識別具體的推薦場景（如首頁信息流推薦、詳情頁關聯(lián)推薦等）和具體的推薦算法（如內容推薦、矩陣分解、協(xié)同過濾等）。包含biz、alg主要目的是希望當用戶在前端訪問推薦系統(tǒng)時，可以將相關信息進行埋點（至少要將uid、biz、alg、item_id、time、時長等核心信息埋點），埋點后可以將信息回收至大數(shù)據平臺（數(shù)據回收相關的知識點我們在第3章中進行過完整的介紹，這里不贅述），方便后續(xù)對AB測試的效果進行評估，獲得推薦系統(tǒng)的在線評估指標（具體的評估方法及指標，參考第15章的介紹）。

到這里我們就介紹完了AB測試的具體實現(xiàn)方案和流程，整個過程和邏輯還是非常簡單的，主要涉及到的是一些工程方面的工作。在公司中，一般AB測試系統(tǒng)是工程團隊來實現(xiàn)的，算法工程師并不會參與，但推薦算法工程師知道AB測試具體的實現(xiàn)原理可以更深刻地理解怎么對推薦系統(tǒng)進行AB測試和評估。

需要注意的是，在對推薦系統(tǒng)進行AB測試過程中，我們需要關注如下3點，才能讓AB測試能力得到正確的運用，更準確地衡量各個算法的效果。

• AB測試一定要在統(tǒng)計學意義上“顯著”

AB測試是有成本的，AB測試的目的是得出正確的結論來優(yōu)化產品體驗、提升收益轉化，所以AB測試指標的提升一定要是統(tǒng)計學上“顯著”的，是真實有效的。一般來說，當每個分組的用戶規(guī)模足夠大（每個分組至少幾百個用戶）、測試時間足夠長（至少一周以上）、分組算法足夠隨機這3個條件都具備時，AB測試的結論在統(tǒng)計意義上是顯著的。具體怎么利用嚴格的數(shù)學方法計算顯著性，大家可以查閱相關資料，這里不展開講。

• 損失最小性原則

我們做AB測試的目的是優(yōu)化用戶體驗，但是有可能我們認為有效的優(yōu)化在真實上線時反而是不好的，為了避免這種情況發(fā)生對用戶體驗和收益的負面影響。我們在做AB測試時盡量用小的流量來測試新的算法或者優(yōu)化點，當數(shù)據證明優(yōu)化點是有效的，才逐步推廣到所有用戶（如按照5%->10%->20%->50%->80%->100%這樣的階段拓展新算法的占比）。實驗過程中如果數(shù)據不好，最多只影響到測試的這批少量用戶，不至于產生大的負面影響。

• 處理好AB測試與緩存的關系

互聯(lián)網公司通過大量采用緩存技術來加速查詢，同時提升整個系統(tǒng)的高性能、高可用能力。當為某個推薦模塊做AB測試時，特別要考慮緩存情況，這時可能會出現(xiàn)問題。這里舉個例子說明，如果某個用戶開始是老算法策略，如果在做AB測試時，給用戶分配到了新算法策略，如果有緩存的話，那么用戶會從緩存獲取到老算法策略，這時跟實際上用戶分配到的新算法策略不一致。最簡單的解決辦法是通過配置推薦系統(tǒng)web服務取消緩存，每次請求都回源，這樣就不會出現(xiàn)這個問題了。

總結

AB測試對于推薦系統(tǒng)在真實業(yè)務場景中提升用戶體驗、產生業(yè)務價值是非常重要的，正是AB測試（配合推薦系統(tǒng)效果評估）才讓推薦系統(tǒng)成為一個可以不斷迭代的、數(shù)據驅動的閉環(huán)系統(tǒng)。

本章我們介紹了推薦系統(tǒng)AB測試的相關知識點，大家知道了什么是AB測試，AB測試的價值以及對于推薦系統(tǒng)具體怎么做AB測試，這些知識點是推薦算法工程師必須要掌握的。本章的重點是AB測試的2個核心模塊（其中怎么進行AB分組是需要了解具體實現(xiàn)細節(jié)的）和AB測試的業(yè)務流程，有興趣的讀者還可以參考本章提供的思路自行實現(xiàn)一套簡單的AB測試系統(tǒng)。