推薦系統中的A/B測試，誰能詳細說下思路？
推薦系統的評價可分為在線評價和離線評價兩種方式。這裡我主要說一下在線評價的主要測試方式，A/B測試。 在線評價其實就是設計在線用戶實驗，根據用戶在線實時反饋的結果來衡量推薦系統的表現。目前最常用的在線測試方法之一是A/B測試，所謂A/B測試，簡單說來，就是為了同一個目標制定兩個方案，讓一部分用戶使用A方案，另一部分用戶使用B方案，記錄下用戶的使用情況，看哪 個 方 案 更 符 合 設 計 目 標 。它 的 核 心 思 想 是 ：1) 多個方案並行測試；2) 每個方案只有一個變數不同；3) 以某種規則優勝劣汰。其中第2點暗示了A/B測試的應用範圍：A/B測試必須是單變數。待測試方案有非常大的差異時一般不太適合做A/B測試，因為它們的變數太多了，變數之間會有很多的干擾，所以很難通過A/B測試的方法找出各個變數對結果的影響程度。顯然，A/B測試用於在推薦系統的評價中就對應於唯一的變數——推薦演算法。
注意，雖然A/B測試名字中只包含A、B，但並不是說它只能用於比較兩個方案的好壞，事實上，完全可以設計多個方案進行測試，也就是說可以同時對多個推薦演算法進行測試，A/B測試這個名字只是習慣的叫法而已。不同的用戶在一次瀏覽過程中，看到的應該一直是同一個方案。如他開始看到的是A方案，則在此次會話中應該一直向他展示A方案，而不能一會兒讓他看A方案，一會兒讓他看B方案。 同時，還需要注意控制訪問各個版本的人數，大多數情況下希望將訪問者平均分配到各個不同的版本上。什麼是 A/B 測試？ - Mil Max 的回答
http://AppAdhoc.com：吆喝科技開發的在線AB測試平台，用數據幫助開發者優化產品，是國內唯一同時支持前端（Web/H5、iOS、Android）及後端（Node.js、PHP、Java）AB測試服務的專業Saas平台。
平台特色：線上灰度發布、多維度數據統計分析、定向測試等等。
通過AB測試來優化產品的方法在海外已經被廣泛應用，現在這種代表先進生產力的方法如同GitHub、Docker、APM一樣也正在逐漸被國內廣大開發團隊所接納。AppAdhoc優化平台能夠幫助用戶提高產品的設計、研發、運營和營銷的效率，降低產品決策風險，同時也能夠幫助用戶用數據優化移動廣告，讓流量的變現價值更大。
@劉澤軍 謝邀
前面兩個回答，一個是從推薦系統方面闡述，A/B測試的分析並不到位，另外一個分析A/B測試，現在我來綜合回答一下這個問題。
A/B測試應用控制變數的思想，除了要對照的產品方案之外，要求其他的環境因素完全一致，也就是說對於樣本間的分流，要儘可能使用戶的組成成分完全一樣，例如所使用的設備類型、新老用戶佔比等等。然後獲取到不同的產品方案所產生的用戶行為數據進行對照，選出表現更佳的產品方案。
推薦系統對於內容類產品至關重要。在我看來關鍵要素有以下幾點：
1、控制變數。橫向來看，如上文所說，需要保證樣本成分一致；縱向來看，對於同一個用戶，每次使用產品時都應該被展示同一個推薦演算法，這樣ta的行為數據才有參考意義。
2、用戶行為。A/B測試最終的落腳點在於選出優勝版本，那麼就需要清晰的定義何為優勝版本——某些關鍵數據表現更佳。尤其是推薦演算法這樣的產品核心點來說，最直接的表現例如點擊率、轉化率，長遠一些的影響例如留存率，甚至最終的成單率等都有可能會受到影響。因此每次進行A/B測試之前都需要有一個明確的計劃；有時候統計的數據並不是越全面越好，根據吆喝科技服務過的用戶經驗，甚至可能會出現明明點擊率獲得了提升，最終的成單率卻下降的現象。因此更重要的是提前明確自己關注的核心點，定義好哪項數據作為優勝版本的判定依據。
3、數據可信度。近幾年數據決策的概念越來越普及，不少開發者也建立了全面的數據體系。然而A/B測試對於數據依然有特別的要求——根據統計學要求，樣本要滿足一定的體量才能夠避免偶然性的產生。A/B測試屬於先驗，也就是預判產品可能產生的影響，因此需要預判足夠準確。根據吆喝科技服務過的客戶經驗，至少需要樣本日活達到1000以上才能產出足夠可信的結論；日活躍高，數據收斂速度越快。
以上均為理論層面，在實際實踐中，實現成本可能會高於想像。尤其是對於樣本的選擇。
此前開發者比較常見的簡易方法是使用不同的渠道對比測試，這樣做的好處是成本極低，只需要打兩個不同的app包分別投放到兩個市場渠道，然後對比數據；壞處也十分明顯，就是無法控制樣本組成，有可能兩個渠道的用戶質量差別很大，這樣得出的結論幾乎是不可信的。
同樣，某個渠道的用戶不能代表所有用戶，有可能在單個渠道上獲得數據提升，推廣到全渠道上卻沒有效果，甚至會產生反效果。
然而要達到令人滿意的效果，就不得不考慮自建服務端控制分流的系統，通過自己的服務端腳本來控制每台設備要展示哪一種試驗版本。可想而知實現成本頗高，除了開發量之外，還要消耗大量的api請求。
對於ios應用來說，受到市場審核的制約，很難在產品中設置開關，發版的周期更長，甚至上一版還沒來得及上架下一版就要發布了。
除此之外，能否保證同一台設備每次都能夠展示同一個版本、如何判斷用戶到底有沒有受到試驗方案的影響、如何靈活的隨時調整樣本數量等等，越是考慮到這些細節問題，就越會發現實現成本幾乎高到不可行。
然而，這並不是說科學的A/B測試無路可走，目前市場上已經出現了一批專為產品迭代中的A/B測試服務的企業，例如吆喝科技，完美解決了樣本分流的痛點：核心的分流演算法可以保證樣本間的一致性，並且規避了自建分流系統的成本，只需要集成SDK調用若干api即可。
推薦閱讀：