[Day 16] 讓每次模型、參數與 Evaluation 結果都能被比較與追蹤

一開始只有幾次實驗，還可以手動記錄

但當實驗開始增加，很快就會出現一個問題：

「這個結果到底是用哪個模型、哪組參數、哪個 Dataset 跑出來的」

代表我們需要 Experiment Tracking

今天的目標，就是建立一套實驗追蹤

為什麼需要 Experiment Tracking

假設我們目前有三次實驗：

假設結果都有逐漸提升

但過了一週，我們可能已經忘記參數設置

甚至可能發現是用另一份 Dataset 跑的

這時候：

數字看起來可以比較，但其實不能直接比較

因此 Experiment Tracking 的核心不是「把數字存起來」

而是：

保存一個實驗所需要的完整上下文

一次 Experiment 到底包含什麼？

一個完整的 Experiment，可以拆成資料、模型、參數、提示詞

這些資訊合在一起，才是一個完整的 Experiment

建立第一版 Experiment Schema

先不用急著導入複雜的 MLOps 平台

我們可以先使用 JSON

這樣未來只要拿到檔案就能知道這次實驗完整的設定

建立 Experiment Logger

如果每次都手動建立 JSON

很快又會變成新的負擔

因此可以寫一個簡單的 Logger

不要只記錄 Metrics

這是 Experiment Tracking 很重要的一點

很多人只記錄準確率

但真正需要保存的是上下文

加入 Git Commit

如果專案使用 Git，還可以記錄：

這樣就可以知道：

這次 Experiment 是哪一版程式碼跑出來的

已經修改很多次，仍然可以透過記錄回到當時的程式版本

開始比較不同 Experiment

當有多個 Experiment 後就可以將它們讀取進來

轉成 DataFrame

當 Experiment 數量增加後，使用 DataFrame 會更方便

這時就開始可以真正比較實驗

每個結果都有完整的設定

建立 Baseline Comparison

每次 Experiment 最好都和同一個 Baseline 比較

但這裡仍然要注意：

不要只看單一指標

加入 Error Case

更能說明：

系統到底改善了什麼

為什麼不直接使用 MLflow

當我們談 Experiment Tracking，很自然會想到：

MLflow

MLflow 是常見的 Machine Learning 或 LLM Experiment Tracking 工具

但目前這個 30 天專案，我不會一開始就導入完整平台

原因很簡單：

• 我需要先理解概念
• 建立最小可行版本

所以：

工具可以換，但 Experiment Tracking 的概念不會變

今天的核心：Reproducibility

Experiment Tracking 最重要的價值之一就是：

Reproducibility (可重現性)

這才算是真正可以被驗證的 Experiment

全部相同，LLM 產生結果仍可能存在變動

因此：

可重現不代表每次輸出一定逐字完全相同

我們真正希望的是：

• 在合理範圍內保持一致。
• 如果需要更穩定的比較，也可以考慮控制模型生成參數與環境

今天學到什麼

今天建立的不是一個單純的 Log

而是一套：

Experiment Management 思維

每一次實驗都變成：

可以被記錄、比較、重現、驗證的工程資料

下一個自然會遇到的問題就是：

「這些結果能不能用圖表直接看」

如果每次都打開 JSON 查看，效率會非常低

因此下一篇將進一步建立：

Day 17：RAG Evaluation Dashboard 視覺化，讓系統品質一眼就能看懂