完整程式碼可在 GitHub 專案中找到：Finetune-30-days-demo / day-4

在做實驗時，常常會遇到這樣的情況：模型表現和上次不同，但卻不確定差異到底來自參數調整，還是因為資料集被悄悄修改過。這提醒我們，資料品質往往比演算法更關鍵。

延續 Day 3 的基準實驗，今天把焦點轉向資料層。因為如果缺乏清楚的版本紀錄、分布檢查與錯誤清理，那麼任何訓練結果其實都站在不穩定的基礎上。換句話說：資料管理的缺口，會直接讓實驗失去可重現性、可比較性與可解釋性。

資料版本管理

沒有版本管理，實驗很快會陷入混亂：今天新增幾筆樣本、明天刪掉一些，但過一週就完全忘記細節，導致結果難以比較。

為此，我在 app/data_manager.py 中新增了 DataVersionManager：

manager = DataVersionManager()
manager.create_version(dataset, "v1_raw", "原始資料")
print(manager.list_versions())

會自動生成 metadata，像這樣：

{
  "versions": {
    "v1_raw": {
      "description": "原始 SST-2 資料",
      "num_samples": 500,
      "summary": {...},
      "distribution_analysis": {...}
    }
  },
  "current_version": "v1_raw"
}

這讓我們能追蹤每次改動，並和模型表現建立關聯。未來還能支援版本差異比較、快速切換，甚至刪除無用版本以節省儲存成本。

偏差與不平衡

如果一個類別在資料集中佔了絕大多數，模型可能會「偷懶」，只學會預測多數類別，看似準確率很高，但實際泛化能力與公平性都很差。

因此，我們需要先 量化資料分布的偏差，才知道是否要進一步調整，並決定是否採用 oversampling 或 class weight 等方法修正。

在 app/data_utils.py 中，我實作了簡單的分布分析：

{
  "total_samples": 500,
  "label_counts": {"0": 245, "1": 255},
  "imbalance_ratio": 1.04,
  "is_balanced": true
}

接下來還能擴充更多衡量指標（如 KL Divergence、Gini Coefficient），並透過圖表或自動生成 class weight 配置，加快修正流程。

錯誤資料檢測

錯誤資料就像沙子掉進精密機械，不需要很多，就足以讓訓練結果變得不穩定。重複樣本會讓模型過度偏向某些答案，空值或亂碼會讓 loss 異常震盪。

在 data/cleaning/validator.py 中，我加入了自動檢查：

• 空值檢查
• 文本長度限制（過短/過長）
• HTML / 亂碼清理
• 重複樣本去重

並輸出詳細報告與建議：

{
  "total_samples": 1000,
  "issues": {
    "length_violations": [{"index": 331, "length": 4}],
    "duplicate_entries": []
  },
  "recommendations": [
    {
      "priority": "medium",
      "issue": "發現 1 筆長度異常",
      "action": "建議調整文本長度限制或截斷/擴充文本"
    }
  ]
}

後續還可以增加語言檢測、正則驗證，甚至做到自動修正與人工複核的整合。

目前的功能還只是基礎，但在真實專案裡，資料管理往往需要更強的追蹤、比較與治理能力，例如版本差異比較、完整的 metadata 報告、更豐富的分布指標、圖表視覺化、更多錯誤檢測規則，甚至與 CI/CD 串接，做到「版本差異 → 模型差異」的映射。Day 4 讓資料從一次性使用提升到可追蹤、可比較、可驗證，雖然這些功能看似簡單，但 版本管理、分布分析、錯誤清理 往往決定了一個實驗能不能真正走得長遠。