Intro to ML Strategy
Why ML Strategy
Orthogonalization
以機器上的旋鈕為例，各種不同旋鈕有不同的功能組合，我們希望控制一個旋鈕只會影響某功能，而不影響其他功能太多。
- 例如，Andrew 不太喜歡在 NN 上使用 early stopping，因為它同時影響 training set 上的表現 (不夠 fit data)，又想提升在 dev set 上的表現，作為一個旋鈕，它並不夠「正交」，因為它會同時影響兩件事。這並不表示 early stopping 很糟，但是若能有更為「正交」的方法，會讓你在調整 NN 時更加簡單。
When we want to:
Fit training set well on cost function, we can
- 訓練更大的網路
- 換一個更好的優化器，例如 adam
Fit dev set well on cost function
- regularization
- 準備更大的訓練資料集
Fit test set well on cost function
- 更大的 dev set
Performs well in real world
- 更換 cost function
- 更換 dev set (??不是應該是 test set 嗎)
Setting up your goal
Single number evaluation metric
若使用兩種以上的評估指標做為 target，不如只使用一種。
Example 1:
- 當你的貓貓分類器在很多不同區域，像中國、美國、印度等，有不同的錯誤率時，很難取捨各分類器的好壞。很直觀地我們可以使用平均錯誤率做為 single number evaluation metric。
Example 2:
- 以 precision 和 recall 為例，model 是需要在這兩者間作取捨的，而若 model A 的 precision 較高，而 model B 的 recall 較高，我們會難以選擇。因此不如直接用 F1-score (precision 和 recall 的調和平均數)。
團隊有了 dev set + single number evaluation metric，可以很快的選擇更好的 model，加快開發的腳步。
Satisficing and Optimizing metric
Example:
也許我們希望分類器可以 accuracy 最大，而 running time 又小於 100ms。 cost = accuracy - 0.5 * running time (這句在下面並沒有做解釋??) ，此時：
- accuracy 是一種 optimizing metric，因為我們想 maximize 精準度
- running time 是一種 satisficing metric，因為夠用就好 (只要小於 100ms 就滿足了)。
如果有 N 個 metric 是我們在意的，那麼會挑一個指標當作 optimizing metric，盡全力優化那個指標，然後剩下 N-1 個 metric 當作 satisficing metric，只要其餘 N-1 個指標達到門檻即可，我們並不在乎它比門檻好多少。如此一來，就有幾乎自動化的方法，可以挑出一個最好的分類器。而這些方法必須在 training/dev/test set 上做估算。
Train/dev/test distributions
如何設置 dev/test set?
- dev set 和 test set 盡量是在同一個 distribution
- dev set 和 test set 必須反映出未來你會得到並且重要 (希望得到良好正確率)的 data。
之後會討論如何設置 training set
Size of the dev and test sets
早期的 ML，data 數量少的話，70/30 或 60/20/20 準則就很合理；然而現今習慣使用大量 data，若有100萬筆，則 98% train，1% dev，1% test 也很合理。
Size of test set
- 大到足以提供使人信服 (能夠代表群體?)的成效，也許1萬筆或10萬筆，而這樣的數字通常遠小於所有 data 的 30%。
通常有使用 test set (而不只是 dev set)做出一個公正的評估，開發出的產品會比較使人安心，不過如果 dev set 很大，我們覺得不會太 overfit 我們的 dev set，那麼或許只有 training/dev set 也不會不合哩，不過 Andrew 並不建議這樣。
When to change dev/test sets and metrics
指標 (metric)看起來比較好，但反而使公司/客戶不爽的時候，也就是 若衡量指標不能正確的排出哪些演算法好或不好，就該換 metric 或 dev/test set 了。
- 給不同的錯誤率一個 weight (即 cost matrix?)
- 比較你的 dev/test set 和將來真實世界會收到的資料是否類似，否則換 dev/test set 或 metric。
正確的步驟是： **1. 先定義出一個能反映出你問題的衡量指標
- 然後才花心思，怎麼在各 data 的這個指標上做到最好**
這可以視為兩個旋鈕，一是定義好你想瞄準什麼目標；二是調整你該怎麼精確地達到這個目標。
就算無法定義出一個很完美的指標和 dev/test set 也沒關係，先快快設定出來，帶動專案的步調，之後發現指標或資料不適合，馬上換也沒問題。然而千萬不要太久沒有 metric 和 dev/test set，因為會延緩我們改善演算法的進度。