如何更有效率地做機器學習專案：單一評估指標與正交化思維

阿亮 | LJ | Zengineer

2025/11/28 更新2025/11/28 發佈閱讀 11 分鐘

在做機器學習專案時，你是不是常遇到這種狀況：

換了模型架構、調了超參數、加了正則化、收了更多資料……
訓練一大堆版本，結果卻不知道哪個「真的比較好」？
甚至花了好幾個月在一個方向，最後發現效果幾乎沒進步？

Andrew Ng 在《Machine Learning Strategy》課程中，提出兩個非常實用的核心觀念，可以大幅提升我們做專案的效率

為專案設計一個「單一數值評估指標」（single real-number evaluation metric）
用「orthogonalization（正交化）」的思維來調整系統

這篇文章就用白話方式，整理這兩個概念，以及它們如何幫助我們更聰明地做機器學習。

一、為什麼要有「單一數值」的評估指標？

機器學習是一個非常「實驗導向」的過程：

想法 → 實作 → 訓練 → 評估 → 修改想法 → 再試

如果每次實驗之後，我們沒辦法一眼看出「新版本到底有沒有比較好」，那整個迭代速度就會變得很慢。

1. Precision、Recall 的例子：兩個指標，很難選

假設我們做了一個貓咪分類器，有兩個模型：

模型 A：Precision 較高
模型 B：Recall 較高

兩個指標都很重要：

Precision 高：被判成貓的圖片，真的就是貓（誤判少）
Recall 高：所有貓的圖片中，有很多都被抓出來（漏抓少）

問題是：

如果 A 在 precision 比較好，B 在 recall 比較好，那到底誰是「更好的模型」？

當你不只測試兩個，而是十幾個模型時，

如果要「同時看好幾個指標」來決定誰最好，其實非常低效。

2. 解法：把多個指標「合成一個數字」——F1 score

在分類問題中，常見的做法是用 F1-score 把 precision 和 recall 合在一起：

這其實就是 precision 與 recall 的 調和平均數。

好處是：

一個數字就能代表模型整體表現
同時兼顧 precision 和 recall
多個模型一排下來，誰比較好一眼就看出來

只要確定這個指標合理，那之後：

「哪個版本比較好？」

→ 看 F1-score 最大的就好。

這就是「單一數值評估指標」帶來的威力：

讓決策變得又快又清楚。

二、另一個例子：多市場的錯誤率

假設你做了一個給貓奴用的 App，有四個市場：

美國
中國
印度
其他國家

你為每個模型都記錄這四個市場的錯誤率，這樣做很合理，因為你關心各地表現是否不均。但問題是：

光看四個錯誤率，要你在模型 A、B、C 中選一個「最好」的，很不直覺。

因此，一個常見做法是：

除了追蹤每個市場的錯誤率，也計算一個「平均錯誤率」
當作這次實驗的主要評估指標

這樣：

細節層面 → 你仍然可以看到每個市場的差異
決策層面 → 用一個平均數，就可以快速決定哪個模型整體最好

重點不是指標一定要是「平均錯誤率」，而是：

你要為你的專案選擇「一個主指標」，

作為你判斷「新想法 / 新模型有沒有比較好」的唯一標準。

這個指標可以是：

F1-score
平均錯誤率
AUC
或為你的商業情境量身訂做的 cost function

只要它能真實地反映你在乎的東西，就可以。

三、機器學習策略的核心：不要瞎試，要「有策略」地試

當模型表現不夠好時，我們通常有一堆可以做的事：

收更多資料
換更大的網路
加強正則化
調學習率或 optimizer
改特徵、改架構、改損失函數……

問題是：如果沒策略，這些都只是「亂槍打鳥」。

Andrew Ng 在策略課程裡，介紹了另一個非常重要的觀念：

👉 orthogonalization（正交化）

它回答的是：

「當你的系統有問題時，你應該調哪一類的東西？」

「不同問題，是否有不同的『旋鈕』可以調？」

四、什麼是 orthogonalization（正交化）？

先看兩個生活中的類比。

1. 老電視的旋鈕：一個旋鈕只負責一件事

老式電視有很多調整畫面的旋鈕：

一個調「寬度」
一個調「高度」
一個調「畫面是否變成梯形」
一個調「畫面向左或向右移」
一個調「旋轉角度」

這是一個「好設計」：

👉 每個旋鈕的功能單一、可解釋。

反過來想像一個「壞設計」：

有個旋鈕同時控制：

0.1 × 高度 + 0.3 × 寬度 − 1.7 × 梯形程度 + 0.8 × 水平位移…

每轉一下，畫面各種亂變，你根本調不出你要的樣子。

這就是 orthogonalization 的精神：

控制項（knob）盡量「一個只影響一種東西」
讓你在調整時，可以很清楚知道「這個控制是在解哪個問題」

2. 開車：方向盤 vs 油門/煞車

開車有三個主要控制：

方向盤 → 決定往左或往右
油門、煞車 → 決定速度

這很自然，因為「方向」和「速度」是兩個不同維度。

如果有人設計一台車：

搖桿 X 軸控制：0.3 × 轉向 − 0.8 × 速度
另一控制：2 × 轉向 + 0.9 × 速度

理論上你還是可以開到你想要的方向和速度，但會 超難開。

好的設計應該是：

一個控制只負責「方向」
另一個控制只負責「速度」

這就是「正交」的概念：

👉 不同方向（方向、速度）用獨立的控制去調整。

五、把 orthogonalization 套回機器學習

對於一個監督式學習系統，要表現良好，通常要滿足四件事：

訓練集（training set）表現好
開發集 / 驗證集（dev set）表現好
測試集（test set）表現好
真實世界表現好（使用者真的滿意）

理想情況是：

不同問題，有各自對應的一組「旋鈕」，

你一看指標，就知道該調哪一類東西。

我們可以這樣拆：

1️⃣ 訓練集表現不好 → 先調「能 fit 訓練資料」的那組旋鈕

問題：

training loss 很高
模型在訓練資料上就表現不好 → 高 bias

可以調的旋鈕包括：

更大的模型（更深 / 更寬的網路）
更好的 optimization（如 Adam）
調學習率、訓練更久
改模型架構讓它更有表達能力

這一組旋鈕的目標很單純：

👉 先讓模型有能力把訓練集學好。

2️⃣ 訓練集好，但 dev set 爛 → 調「泛化能力」那組旋鈕

問題：

在訓練集效果很好
在 dev set 表現明顯變差 → 高 variance（overfitting）

這時要調的是 另一組旋鈕，例如：

增加正則化（L2、dropout 等）
收更多訓練資料
做更好的資料增強（data augmentation）
簡化模型（在某些情況下）

目標：

👉 讓模型學到不是「死背訓練集」，而是能在 dev set 也表現好。

3️⃣ Dev set 好，但 test set 爛 → 調「dev/test 設計」的旋鈕

問題：

模型在 dev set 表現很好
在 test set 卻掉下去很多

這通常代表：

你對 dev set「調太兇」，導致 dev set 不再能代表真實分佈。

要調的旋鈕是：

擴大 dev set
重新劃分 dev/test
確保 dev/test 來自同樣的資料分佈

4️⃣ Test set 好，但真實世界不行 → 調「資料分佈 & 評估指標」那組旋鈕

問題：

Test set 指標很好
但上線後，使用者不滿意，產品效果很差

這表示：

你的 dev / test 設計，或 cost function，

並沒有真的反映真實世界的需求。

此時要調的旋鈕包括：

重新定義 dev/test 的資料分佈，讓它更貼近真實使用情境
重新設計 cost function / 評估指標例如某些錯誤比另外一些錯誤「嚴重得多」，但指標沒有體現

六、為什麼 Early Stopping 是「不那麼正交」的控制？

Andrew Ng 提到，他自己比較少用 early stopping（雖然很多人用，它本身不是壞東西）。

原因是：

Early stopping 同時會影響：你對訓練集的 fit 程度（停比較早 → training loss 變大）你對 dev set 的表現（通常用來防 overfitting）

也就是說：

Early stopping 是一個「同時作用在兩個面向」的旋鈕：

既影響訓練 fit，又影響泛化。

這就像電視上有個旋鈕：

一轉同時改「寬度」又改「高度」

不是不能用，只是：

思考上比較複雜，不夠「正交」
相比之下，把「fit 訓練集」和「防 overfit」拆成不同控制，比較容易推理，也比較清楚知道自己在做什麼。

七、綜合來看：兩個概念一起用，讓你少走很多冤枉路

把前面兩個主題放在一起看：

單一數值評估指標解決的是：「我怎麼快速知道哪個模型比較好？」讓你在一堆實驗中，能清楚找到「目前最好的一個」，加速迭代。
Orthogonalization（正交化）解決的是：「當模型不夠好時，我到底該調哪一類東西？」把問題拆成「訓練集 / dev / test / 真實世界」四個層次，每個層次有對應的一組調整手段（knobs）。

結合起來，你在做機器學習專案時，就不再是：