Setting up development and test sets（主題）

5.Your development and test sets

回到最初的貓咪圖片的例子，你發行了一個app，使用者上傳各種事物的圖片到app上，你希望自動發現貓咪的圖片。

你的團隊從網路中獲取了很多貓咪的圖片（positive example）和其他圖片（negative example），將資料劃分成70%訓練集和30%的測試集，使用這些資料建立了一個探測器，對於訓練集和測試集都有很好的效果。

但是當你將分類器構建在app上，你發現它的效能很差！

發生了什麼？

你發現，使用者上傳的圖片和你構成資料集的圖片很不一樣：使用者使用手機上傳圖片，這些圖片解析度低、模糊且光線不足。因為你的訓練集/測試集是從網上下載的圖片，你的演算法在你所關心的分佈（手機圖片）上泛化能力不好。

在大資料時代到來前，機器學習的一個常用規則是使用隨機70%/30%來劃分訓練集和測試集。這個方法能用，但它在越來越多的應用上是一個bad idea，這些應用的訓練分佈和你期望的實際分佈是不同的。

我們通常定義：

1.訓練集：用來訓練學習演算法 2.驗證集：用來調參、選擇特徵以及做其他有關於學習演算法的決策，有時也叫做留存交叉驗證集。 3.測試集：用來評估演算法效能，但是不做引數或其他關於演算法決策的調整。

當你定義了驗證集和測試集，你的團隊會嘗試很多ideas,比方採用不同的學習演算法引數來比較哪種效能最好，驗證集和測試集能使團隊更快地觀察演算法執行的情況。

因此，你應當這麼做：

選擇驗證集和測試集來反映你未來期望得到的、並且在其上有好的表現的資料

 換句話說，測試集不能只是簡單的30%，特別是你預期未來的資料（手機上的圖片）可能和訓練集（網路上的圖片）所用的資料不同。

如果你還沒有釋出app，那可能就沒有使用者，也就不能得到那些精確反映未來預期的資料，不過你可以這樣得到近似的資料：叫你的朋友幫忙拍一些圖片發給你，然後當你的app上線後，你就能得到真實使用者資料構成的驗證集和測試集。

如果你無法獲得任何近似資料，也許你可以使用網路圖片作為開始，但需要意識到風險---這也許會讓系統的泛化能力不好。

需要通過評判來決定在驗證集和測試集的投入多少。但是不要假設訓練分佈和測試分佈相同。選擇那些你最終期望在其上執行的好的測試樣例，而不是那些你碰巧得到的資料。

6. Your dev and test sets should come from the same distribution

基於大標籤：(i)US;(ii)China;(iii)India;(iv)Other,你將貓咪app的圖片資料按四個國家分類。為了構建驗證集和測試集，我們將US和India組成驗證集，將China和Other組成測試集。換句話說，我們可以隨機將這4個部分中的2個劃分為驗證集，另外2個劃分為測試集，對嗎？

當定義好了驗證集和測試集後，你的團隊將專注於在驗證集上提升效能。因此，驗證集應該反映你最需要改進的任務：在4個圖集上都要表現良好，而不僅僅是2個。

使用不同分佈的驗證集和測試集帶來的第2個問題：這是一個團隊構建在驗證集上表現良好模型的機會，卻發現它在測試集上表現很差，這會帶來挫折，請避免它發生在你身上。

舉個例子，假設你的團隊開發了一個系統，它在驗證集上工作地很好，而不是在測試集上。如果你的驗證集和測試集來自同一個分佈，那麼關於錯誤，你會得到一個明確的診斷：它在驗證集上過擬合了。明確的改進方法是：獲取更多驗證集的資料。

但如果驗證集和測試集不在同一分佈，那你的選擇就不會很明確了。很多事情可能發生了錯誤： （1）對於驗證集發生了過擬合 （2）測試集比驗證集難。因此，你的演算法可能做得和預期的一樣好，並且沒有進一步的顯著改進也是可能的。 （3）測試集可能並不比驗證集難，也許僅僅是它們來自不同分佈。因此在驗證集上表現良好卻在測試集上表現的不好，這種情況下，在驗證集上改進效能將是一種浪費。

開發機器學習應用是很難的。如果驗證集和測試集不匹配，則會帶來額外的不確定性，即改進驗證集分佈是否也會提高測試集效能。驗證集和測試集的不匹配對於發現哪些起作用哪些不起作用帶來了困難，因此也對優化哪一部分帶來了困難。

如果你在為第三方基準問題而工作，它們的創造者可能明確要求驗證集和測試集不能來自同一分佈，相比於驗證集和測試集是否來自同一分佈，運氣，而不是技巧，將對這個基準上的效能有更多的影響。如何將學習演算法訓練在一個分佈上，並很好地推廣到另一個分佈上，是一個重要的研究課題。但如果您的目標是在特定的機器學習應用程式上取得進展，而不是取得研究進展，那麼我建議您嘗試選擇從同一分佈中提取的驗證和測試集。這會讓你的團隊更有效率。

7 How large do the dev/test sets need to be?

驗證集必須足夠大以發現不同演算法中的差別。比方說，如果分類器A的準確率為90%而分類器B的準確率為90.1%，那麼，有100個例項的驗證集可能不會發現這0.1%的差別。和我見過的其他機器學習問題相比，100個例項的驗證集很小。通常，驗證集的例項數量在1000~10000。在10000個例項的驗證集中，你將很有機會來發現這0.1%的差別。

對於成熟且重要的應用（例如廣告、網頁搜尋和產品推薦）來說，我也見過一些團隊致力於做出0.01%的改進，因為這對公司的收益來講是有直接影響的。這種情況下，為了發現更小的改進點，驗證集的數量要多於10,000。

那麼測試集的大小又是如何呢？它需要足夠大，在系統所有效能上給出一個高的可信度。一種流行的啟發式方法是使用資料的30%當做測試集，這在當你擁有數量適中的例項時是有用的（1000~10,000個例項）。但在大資料時代，我們的機器學習問題擁有超過10億資料，即使驗證/測試集中的例項的絕對數目一直在增加，分配給驗證/測試集的資料部分一直在縮小。 不需要有超出了評估演算法效能所需的範圍外的過大的資料集。

8 Establish a single-number evaluation metric for your team to optimize

分類準確率是單一數字評估標準的一個例子：你在驗證集（或測試集）上執行分類器，然後得到一個關於例項分類正確的分數。根據這個單一數字評估標準，如果分類器A的準確率是97%而分類器B的準確率是90%，那我們就說分類器A更好一些。

相反，精度（TP/(TP+FP））和召回率（TP/(TP+FN)）不是單一數字評估標準，它給出兩個資料來評估你的分類器。使用多數字評估標準來比較演算法會比較難。假設你的演算法表現如下：

在這裡，沒有一個演算法明顯表現得更好，所以它並不能立刻指導你做出選擇。

在開發階段，你的團隊會嘗試很多關於演算法結構、模型引數、特徵選擇等這樣一些想法，使用單一數字評估標準例如準確率允許你將模型按照這個標準上的效能進行排序，並且快速確定哪個表現最好。

如果你很在意精度和召回率，我建議使用一種標準方法將它們組合成單一數字，比如說可以取它們的均值作為單一數字，另外，你可以計算F1分數，這是一種改良的均值計算方法，比直接取平均表現得要好。 （   F1表示召回率和精度的調和均值，精度p，召回率r，F1=2/(1/r+1/p)=2rp/(r+p)   ）

使用單一數字評估標準能提高你從大量分類器中做出選擇的能力。它能給出所有分類器的偏好排名，因此能有一個明確的前進方向。

舉最後一個例子，假設你對於貓咪圖片分類器分別在4個關鍵需求上追蹤了準確率：(i)US;(ii)China;(iii)India;(iv)Other，你將得到4個標準，通過計算均值或加權平均這4個數字，你將得到1個單一數字標準。平均或加權平均是把多個指標合為一個的最常見的方法。

9 Optimizing and satisficing metrics

這是另一個合併多指標的方法。

假設你關心學習演算法的準確率和執行時間，你需要從以下3個分類器中做出選擇：

將準確率和執行時間放在一個單一方程中來匯出一個單一標準是很不自然的，比如：

相反你可以這麼做：首先，定義一個“可接受的”執行時間，我們說執行時間小於100ms是可接受的；然後，最大化準確率，讓分類器滿足執行時間的標準。在這裡，執行時間是一個“滿意度指標”---你的分類器必須在這個指標上足夠好，也就是說最多100ms。準確率是“優化指標”。

如果你有N個標準，如模型的二進位制檔案大小（對移動app非常重要，因為使用者不想下載大的app）、執行時間和準確率，你需要考慮設定N-1個標準作為“滿意度指標” ，即，你只是要求它們達到一個確定的值，然後定義最後一個為“優化指標”。比如說，設定二進位制檔案大小和執行時間的可接受閾值，然後在它們的約束下優化準確率。

最後舉個例子，假設你正在建立一個硬體裝置，它使用麥克風來監聽使用者說出一個特別的“喚醒詞”，然後就喚醒系統。就像Amazon Echo監聽“Alexa”、Apple Siri監聽“Hey Siri”、Android監聽“Okay Google”、百度app監聽“Hello Baidu”。你關心假正（FP）率---即使沒有說出“喚醒詞”，系統喚醒的頻率（也就是錯誤預測為正），也關心假負（FN）率---也就是當說出“喚醒詞”系統沒有被喚醒的頻率（錯誤預測為負）。對於這個系統的效能來說，一個合理的目標是在每24小時的操作中FP至多一次（滿意度指標）的情況下，最小化FN率（優化指標）。

一旦你的團隊在評估指標上進行優化，就能更快地取得進展。

10 Having a dev set and metric speeds up iterations

提前知道何種方法對於一個新問題來說效率最好是很難的。即便是有經驗的機器學習研究員，在發現滿意的方法之前也會嘗試許多方法。在建立機器學習系統時，我通常： 1.從一些如何構建系統的方法入手 2.編碼實現這些方法 3.進行實驗來告訴我這些方法的工作效果（通常我最初的那些方法都沒用！）。基於這些經驗，重新產生更多的方法，然後繼續迭代。

這是一個迭代過程，你迴圈的速度越快，取得進展就越快。這就是使用驗證/測試集和標準的重要性：每當你嘗試一個方法，在驗證集上評估這個方法的效能能讓你快速斷定你是否在一個正確的方向上。

相反，假設你沒有明確的驗證集和標準，每當你的團隊開發出一個新的貓咪分類器，你需要把它加入你的app，然後使用幾小時來感受這個新的分類器是否有改進，這非常非常慢！並且假如你的團隊將分類器的準確率從95%改進到95.1%,通過使用app，你也許不會發現這0.1%的改進。然而，通過逐步積累這0.1%個改進，你的系統將會有很多進步。擁有驗證集和標準能使你快速發現哪種方法能順利地為你帶來小（或大）的改進，因此能讓你快速決定對哪種方法進行精煉，對哪種方法進行丟棄。

11 When to change dev/test sets and metrics

在開始一個新專案時，我會快速地選擇好驗證集和測試集，因為它會給團隊一個明確的目標。

我通常要求我的團隊在少於一週的時間內（很少會更長）提出初始的驗證/測試集和標準。相比於過度地思考，提出一些不完美的東西然後快速去實施會更好。但是，一週的時間軸並不適用於成熟的應用，例如反垃圾郵件就是一個成熟的深度學習應用。我見過團隊在已經成熟的系統上花費數月來獲得更好的驗證集/測試集。

如果你後來發現最初的驗證集/測試集漏洞百出，盡一切辦法快速更改它。比如說，如果你發現驗證集+標準使分類器A排在分類器B之前，但團隊發現分類器B實際上對你的產品來說更好，這也許是一個需要你更改驗證集/測試集或評估標準的標誌。

這裡有3點原因使得驗證集/標準錯誤地將A排在靠前位置：1.實際分佈和驗證集/測試集的分佈不同 假設最初的驗證集/測試集主要包括成年貓，你釋出了app後，發現使用者在期望之外上傳了更多關於小貓的圖片，所以驗證集/測試集的分佈並不能代表實際分佈（你希望在這能有好的表現），這種情況下，更新驗證集/測試集使它具有更多代表性。2.對驗證集產生了過擬合 過度地在驗證集上評估方法所取得的進步會造成演算法最終在驗證集上過擬合。當完成開發後，需要在測試集上評估系統。如果你發現在驗證集上的效能要比在測試集上好，這是在驗證集上過擬合的標誌，在這個情況下，請獲取一個新的驗證集。

如果你需要追蹤團隊的進展，你也可以有規律地在測試集上評估系統，像是每週一次或每月一次。但不要用測試集來做出關於演算法的任何決定，包括是否回滾上一週的系統。如果你這麼做，你就開始過擬合測試集了，再也不能指望它對系統的效能給出一個完全無偏的估計（在發表研究論文或使用標準進行重要商業決策時會需要）3.標準在衡量專案需要優化方面以外的東西 假設對於你的貓咪應用，標準是分類準確率，這個標準當前將分類器A排在分類器B之前。假設你嘗試了這兩個演算法，發現分類器A偶爾會允許色情圖片通過，即使A更準確，偶爾出現色情圖片留下的壞印象意味著它的效能是不可接受的，該怎麼辦？

在這裡，這個標準無法辨別演算法B實際上比演算法A對於你的產品來說更好的事實，因此，你不能再相信這個標準來選擇最好的演算法，是時候更改標準了。例如，你可以將標準更改為嚴重懲罰使色情圖片通過的分類器。我強烈建議選擇新標準，使用新標準為團隊明確定義新目標，而不是在沒有可信標準下進行太長時間而恢復到手動選擇分類器。

在專案中更換驗證集/測試集或評估標準是很常見的。擁有初始的驗證集/訓練集和標準能使你迭代地更快，如果你發現驗證集/測試集或標準不能為你的團隊指明正確方向，沒什麼大不了的，更換它們並確保你的團隊知道新的方向。

12 Takeaways: Setting up development and test sets（小結）

• 從一個 能反映你未來期望得到的資料並且希望在它們上面表現良好的 分佈中選擇驗證集和測試集，這也許和訓練集的分佈不同。
• 如果可能的話，從同一個分佈中選擇驗證集和測試集
• 為團隊選擇單一數字評估標準來進行優化，如果你關心多個目標，考慮將它們合併成一個方程（例如平均多個誤差標準）或使用滿意度指標和優化指標。
• 機器學習是一個高速迭代的過程：在發現令人滿意的方法前可能會嘗試許多方法。
• 使用驗證集/測試集和單一數字評估標準幫助你快速評估演算法，因此更快地迭代。
• 當開始一個新應用時，嘗試快速建立驗證集/ 測試集和指標，我們說少於一週。對於成熟應用，可以花更多的時間。
• 舊的啟發式分割資料為70%/30%訓練集/測試集對於大量資料來說是不適用的，驗證集和測試集可以遠遠小於資料的30%。
• 驗證集需要足夠大來發現演算法準確率中有意義的改變，但不是必須非常大。測試集需要足夠大來給出系統最終效能的可信估計。
• 如果驗證集和標準不能再為團隊指明正確方向，快速更改它們：(i)如果過擬合驗證集，獲取更多資料 (ii)如果實際分佈與驗證集/測試集的分佈不同，獲取新的驗證集/測試集 (iii)如果標準不能評估對你來說最重要的部分，更改新的標準。

本文為個人學習中進行的翻譯，為方便自己以後回顧。

圖片來源：《Machine Learning Yearning》