多任務學習不是為了更準，而是為了看清問題

多任務學習（Multi-Task Learning, MTL）常被拿來當作提升泛化能力的手段，
但在實際做專案時，我發現它真正的價值，往往不在分數，而在於它逼你重新思考：
你現在解的，真的是一個問題嗎？

音符識別被過度簡化了

在音符識別模組中，最直覺的做法，是把輸入直接對應到一個音符類別。
看起來乾淨、端到端，但實作後很快會發現這個抽象其實不太誠實。

因為「音符」本身同時包含了多種性質，而這些性質的錯誤代價並不一樣。

實際拆解：音高、音長、附點

在作品中，我們將音符識別拆解為三個任務：

• 音高（Pitch）
  判定音名或音階位置，錯了就是錯音，語義成本最高。
• 音長（Duration）
  判定時值長短，錯誤通常影響節奏結構，而非旋律本身。
• 附點（Dotted）
  判定是否有附點，資料相對稀疏，且會放大音長的影響。

這三者目標一致，但錯誤型態、資料分佈與不確定性完全不同。

為什麼不用單一輸出？

把這些東西壓成一個輸出，等於假設它們屬於同一個錯誤空間。
但實際上，一個「音高對、音長錯」的預測，和「整個音錯掉」並不是同一種失敗。

MTL 在這裡的作用，不是變聰明，而是不再混淆這些錯誤。

MTL 帶來的真正改變

多任務架構讓我們可以：

• 共享對譜面結構與上下文的理解
• 讓不同任務各自承擔判斷責任
• 在出錯時知道是 pitch、duration 還是 dotted 出問題

錯誤不再只剩下「音符錯了」，而是可被定位的結構性問題。

這不是唯一拆法，但是一個誠實的開始

我不認為音高、音長、附點是最終答案。
你也可以進一步拆成拍點、小節結構、連音或相對時值等任務。

重點不在於拆得多細，而在於是否承認：
音符識別本來就不是一個單一問題。

結語

多任務學習的價值，不在於它一定比較準，
而在於它迫使你停止假裝問題很單純。

當你選擇 MTL，其實是在承認：
問題需要被拆開理解，而不是被壓成一個漂亮的輸出。