前面幾天已經提到多音節訓練，但真正開始整理資料時，我才發現手上的資料並不是拿來就能直接使用的。

當時手上的多音節資料主要是從 kaudian.ods 整理出來。這份資料比較像是我的文字／詞彙資料來源，我需要先從裡面找出符合目前資料格式的多音節項目，再進一步確認是否有對應的 WAV 音檔。 不過，裡面的資料格式比我預期複雜，除了我需要的台羅格式之外，還混有其他特殊的編碼方式。我的訓練資料使用 - 來區分音節，因此我先把不符合這個格式的資料排除，只留下可以進一步處理的項目。

例如：

• A-B → 保留
• A-B-C → 保留
• A B → 排除
• A／B → 排除
• 其他特殊格式 → 排除

這個篩選看起來很簡單，但其實是在先定義「什麼資料才算是我現在可以處理的多音節資料」。因為後面的模型、Tokenizer 和錯誤分析，都會依賴這個音節分隔方式。

這點也和 Day 4 提到的問題有關，當時模型就曾經把像 lí-ke 這種多音節輸入辨識成 líke，讓原本的音節邊界消失。對我的資料來說，- 不只是格式上的符號，而是我用來區分音節的重要資訊，所以在建立資料之前，就必須先把格式整理一致。

接著，我再根據篩選後的資料去尋找對應的 WAV 音檔。也就是說，這次的資料處理不是單純找一些多音節文字，而是要讓文字資料和實際存在的音檔配得起來。因為模型真正吃進去的是音訊，文字 Label 則是告訴模型「這段聲音應該對應什麼」。只要這兩邊配錯，即使訓練流程完全正常，模型學到的東西也可能不是我原本想教它的內容。

這一步看起來只是資料篩選，但對後面的訓練很重要。因為如果音檔、檔名和標籤沒有正確對應，模型收到的就可能不是我以為的訓練資料。

第二次微調：多音節訓練

整理好多音節資料後，我直接拿 V1 模型進行第二次微調。也就是說，這次不是從零開始訓練，而是在 V1 已經學到的基礎上，再加入多音節資料繼續微調。

這次建立的多音節訓練集共有 18,137 筆。和前一次主要處理單音節資料不同，這次模型開始真正使用多音節資料進行訓練。整次訓練共跑了 5 個 Epoch，最後的 Training Loss 是 0.4519。

這也讓我開始注意到，Training Loss 下降本身並不能直接代表模型在我真正關心的任務上表現良好。

辨識準確率只有 65.39%。

我看到這個數字的第一個反應就是：怎麼這麼糟糕啊？

前面的 V1 在多音節測試集上得到 70.74%，而這次已經加入多音節資料重新微調的 V2，測試結果卻只有 65.39%。這個結果沒有讓我覺得「加入多音節資料之後模型明顯變好了」，反而讓我開始重新檢查資料和訓練方向。而且這次不是單純拿單音節模型去測多音節資料，而是已經特別建立了多音節訓練集，再拿 V1 做微調。所以我開始重新想，到底哪裡出了問題。

V2，先放棄

這次實驗的結果讓我開始重新檢查自己的方向。

當時我開始覺得，既然我的目標是 CAPT (發音檢測)，那我真正想處理的應該是學習者實際發出來的聲音，而不只是最後被 ASR 辨識成什麼文字。

我當時也開始懷疑，是不是因為目前使用的資料偏向書面音，所以才讓這次多音節訓練的結果這麼慘烈。

因此，我沒有繼續在 V2 上面硬調參數，而是決定重新訓練一次。把檔名改成實際的音再去訓練。

至於 V3 重訓之後到底有沒有比較好，以及這個決定到底是不是正確的，就留到明天再講。

我是微微，明天見！