1.視訊網站：mooc慕課https://mooc.study.163.com/university/deeplearning_ai#/c
2.詳細筆記網站(中文)：http://www.ai-start.com/dl2017/
3.github課件+作業+答案：https://github.com/stormstone/deeplearning.ai
2.2 清楚标注錯誤的資料 Cleaning up Incorrectly labeled data
- 1.标記錯誤的樣本
-
- 1-1.訓練集
- 1-2.開發集/測試集
- 2.是否值得修正錯誤的樣本
- 3.修正開發集/測試集樣本
- 4.兩點建議
你的監督學習資料由輸入 x x x和輸出标簽 y y y構成。如果你觀察一下你的資料，會發現有些輸出标簽錯誤，那麼是否值得花時間去修正這些标簽呢？
1.标記錯誤的樣本
如上圖，在貓分類問題中，圖檔是貓， y = 1 y=1 y=1；不是貓， y = 0 y=0 y=0。
假設你看了一些資料樣本，發現倒數第二張圖檔其實不是貓，是以這是标記錯誤的樣本。“标記錯誤的樣本”表示你的學習算法輸出了錯誤的 y y y值。
對于标記錯誤的樣本，在你的訓練集或者測試集中 y y y的标簽，人類給這部分資料加的标簽，實際上是錯的。上圖中實際上是一隻狗，是以 y y y其實應該是0，也許做标記的那人疏忽了。如果你發現你的資料有一些标記錯誤的樣本，你該怎麼辦？
1-1.訓練集
首先，我們來考慮訓練集。
事實證明，DL算法對于訓練集中的随機錯誤是相當健壯的（robust）。有時可能做标記的人沒有注意或者不小心，按錯鍵了。隻要這些錯誤樣本離随機錯誤不太遠，如果錯誤足夠随機，那麼放着這些錯誤不管可能也沒問題，而不要花太多時間修複它們。
DL algorithms are quite robust to random errors in the training set.
當然你浏覽一下訓練集，檢查一下這些标簽，并修正它們也沒什麼害處。有時候修正這些錯誤是有價值的，有時候放着不管也可以，隻要總資料集總足夠大，實際錯誤率可能不會太高。我見過一大批ML算法訓練的時候，明知訓練集裡有些錯誤标簽，但最後訓練出來也沒問題。
提醒一下，DL算法對随機誤差很健壯，但對系統性的錯誤就沒那麼健壯了。
是以比如說，類似上圖中的例子，如果做标記的人一直把白色的狗标記成貓，那就成問題了。因為你的分類器學習之後，會把所有白色的狗都分類為貓。但随機錯誤或近似随機錯誤，對于大多數DL算法來說不成問題。
1-2.開發集/測試集
其次，如果是開發集和測試集中有這些标記出錯的樣本呢？
如果你擔心開發集或測試集上标記出錯的樣本帶來的影響，一般建議你在錯誤分析時，添加一個額外的列（如下圖，上一節課使用過該統計表），這樣你可以統計标簽 y y y錯誤的樣本數。
如上圖，比如說你想統計一下對100個标記出錯的樣本的影響，是以你會找到100個樣本，其中你的分類器的輸出和開發集的标簽不一緻。有時對于其中的少數樣本，你的分類器輸出和标簽不同，是因為标簽錯了，而不是你的分類器出錯。
假設在98号樣本中，你發現标記的人漏了背景裡的一隻貓，是以在 “Incorrectly labeled” 列打個勾，來表示98号樣本标簽出錯了。
假設100号樣本實際上是貓的畫，而不是一隻真正的貓，也許你希望标記資料的人将它标記為 y = 0 y=0 y=0，而不是 y = 1 y=1 y=1，然後再在 “Incorrectly labeled” 列打個勾。
最終，正如上節課中介紹過的，當你統計出其他錯誤類型的百分比後（8%是狗，可能43%屬于大貓，61%屬于模糊），你還可以統計因為标簽錯誤所占的百分比 6%，這就解釋了為什麼你的學習算法做出和資料集裡的标記不一樣的預測。
2.是否值得修正錯誤的樣本
現在問題是，是否值得修正這6%标記出錯的樣本。
我的建議是，如果這些标記錯誤嚴重影響了你在開發集上評估算法的能力，那麼就應該去花時間修正錯誤的标簽。但是，如果它們沒有嚴重影響到你用開發集評估成本偏差的能力，那麼可能就不應該花寶貴的時間去處理。
那麼如何判斷是否影響開發集上評估算法能力呢？
可以通過看3個數字來确定是否值得去人工修正标記出錯的資料。
例1
-
整體的開發集錯誤率 Overall dev set error – 10%
假設我們的貓分類系統達到了90%整體準确度，是以有10%錯誤率，那麼你應該看看錯誤标記引起的錯誤數量或者百分比。
-
錯誤标記引起的錯誤數量或者百分比 Errors due incorrect labels – 0.6%
現在6%的錯誤來自标記出錯，是以10%的6%就是0.6%。最後你應該再看看其他原因導緻的錯誤
-
其他原因導緻的錯誤Errors due to other causes
你的開發集上有10%錯誤，其中0.6%是因為标記出錯，剩下的占9.4%，是其他原因導緻的，比如把狗誤認為貓，或者大貓圖檔，或者圖檔模糊。
根據上面的分析，有9.4%錯誤率需要集中精力修正，而标記出錯導緻的錯誤是總體錯誤的一小部分而已。是以如果你一定要這麼做，你也可以手工修正各種錯誤标簽，但也許這不是當下最重要的任務。
例2
再看另一個例子。
假設你在學習問題上取得了很大進展，錯誤率不再是10%了，而是降到了2％，但總體錯誤中的0.6%還是标記出錯導緻的。是以現在，如果你想檢查一組标記出錯的開發集圖檔，那麼其中很大一部分，0.6%除以2%，實際上變成30%占比而不是6%了。而現在其他原因導緻的錯誤是1.4%。當測得的那麼大一部分的錯誤都是開發集标記出錯導緻的，修正開發集裡的錯誤标簽似乎變得更有價值。
如果你還記得設立開發集的目标的話，開發集的主要目的是，你希望用它來從兩個分類器 A A A和 B B B中選擇一個。
Goal of dev set is to help you select between two classifiers A & B.
是以當你測試兩個分類器 A A A和 B B B時，一個在開發集上一個有2.1%錯誤率，另一個有1.9%錯誤率，但是你不能再信任開發集了，它無法告訴你 A A A這個分類器是否比 B B B這個好，因為0.6%的錯誤率是标記出錯導緻的。
現在你就有很好的理由去修正開發集裡的錯誤标簽，因為在例2中标記出錯對算法錯誤的整體評估标準有嚴重的影響。而例1中标記出錯對你算法影響的百分比還是相對較小的。
3.修正開發集/測試集樣本
現在如果你決定要去修正開發集資料，手動重新檢查标簽，并嘗試修正一些标簽，這裡還有一些額外的方針和原則需要考慮。
- 首先，我鼓勵你不管用什麼修正手段，都要同時作用到開發集和測試集上。
我們之前讨論過為什麼開發和測試集必須來自相同的分布。開發集确定了你的目标，當你擊中目标後，你希望算法能夠推廣到測試集上，這樣你的團隊能夠更高效的在來自同一分布的開發集和測試集上疊代。如果你打算修正開發集上的部分資料，那麼最好也對測試集做同樣的修正以確定它們繼續來自相同的分布。
Apply same process to your dev and test sets to make sure they continue to come from the same distribution
- 其次，我強烈建議你要考慮同時檢驗算法判斷正确和判斷錯誤的樣本。
要檢查算法出錯的樣本很容易，隻需要看看那些樣本是否需要修正，但還有可能有些樣本算法判斷正确，那些也需要修正。如果你隻修正算法出錯的樣本，你對算法的偏差估計可能會變大，這會讓你的算法有一點不公平的優勢，我們就需要再次檢查出錯的樣本，但也需要再次檢查正确的樣本，因為算法有可能因為運氣好把某個東西判斷對了。在這種特例裡，修正那些标簽可能會讓算法從判斷對變成判斷錯。這第二點不是很容易做，通常不會這麼做，原因是，如果你的分類器很準确，那麼判斷錯的次數比判斷正确的次數要少得多。假設有2%出錯，98%是對的，是以更容易檢查2%資料上的标簽，然而檢查98%資料上的标簽要花的時間長得多，是以通常不這麼做，但也是要考慮到的。
Consider examining examples your algorithm got right as well as ones it got wrong.
- 最後，如果你進入到一個開發集和測試集去修正這裡的部分标簽，你可能會，也可能不會去對訓練集做同樣的事情。
修正訓練集中的标簽其實相對沒那麼重要，你可能決定隻修正開發集和測試集中的标簽，因為它們通常比訓練集小得多，你可能不想把所有額外的精力投入到修正大得多的訓練集中的标簽，這樣其實是可以的。你的開發集和測試集來自同一分布非常重要。但如果你的訓練集來自稍微不同的分布，通常這是一件很合理的事情。
Train and dev/test data may now come from slightly different distributions.
4.兩點建議
最後我講幾個建議：
首先，深度學習研究人員有時會喜歡這樣說：“我隻是把資料提供給算法，我訓練過了，效果很好”。這話說出了很多DL錯誤的真相，更多時候，我們把資料喂給算法，然後訓練它，并減少人工幹預，減少使用人類的見解。但我認為，在構造實際系統時，通常需要更多的人工錯誤分析，更多的人類見解來架構這些系統，盡管DL的研究人員不願意承認這點。
其次，不知道為什麼，我看一些工程師和研究人員不願意親自去看這些樣本，也許做這些事情很無聊，坐下來看100或幾百個樣本來統計錯誤數量，但我經常親自這麼做。當我帶領一個ML團隊時，我想知道它所犯的錯誤，我會親自去看看這些資料，嘗試和一部分錯誤作鬥争。我想就因為花了這幾分鐘，或者幾個小時去親自統計資料，真的可以幫你找到需要優先處理的任務，我發現花時間親自檢查資料非常值得，是以我強烈建議你們這樣做，如果你在搭建你的ML系統，想确定應該優先嘗試哪些想法，或者哪些方向。