G3 — Experimentation（實驗與評估）

核心概念

Experimentation 在 NCA-GENL 官方藍圖佔 22%，是僅次於 Core ML 與 Software Development 的第三大領域。它回答一個工程上最現實的問題：「我怎麼知道這個 LLM、這次 fine-tune、這個新功能到底有沒有變好？」 與傳統 ML 不同，生成式模型的輸出是開放式文字，沒有單一「正確答案」，因此評估必須分層進行。

整個領域可拆成三條主軸。第一是 Evaluation Metrics（評估指標）：用 perplexity 這類 intrinsic 指標衡量語言模型本身的擬合度，用 BLEU、ROUGE、accuracy/F1、nDCG@k 這類 extrinsic 指標衡量下游任務表現，並在自動指標不足時引入 LLM-as-a-judge 與 human evaluation。第二是 Benchmarking & Comparison（基準與比較）：透過 MMLU、HellaSwag、TruthfulQA 等公開 benchmark 橫向比較模型，同時警覺 benchmark gaming 與 train-test contamination。第三是 Online Experimentation（線上實驗）：用 A/B testing 在真實流量上驗證功能，用 hyperparameter tuning 系統化地調整 fine-tuning 設定，並以 Weights & Biases、MLflow 追蹤實驗。

核心心法是：沒有單一指標能涵蓋一切，要組合 intrinsic + extrinsic + 人類判斷，並區分離線（offline）評估與線上（online）實驗。

---

Evaluation Metrics

Intrinsic vs extrinsic LLM evaluation

定義：Intrinsic（內在）評估衡量模型「作為一個語言模型本身」的品質，與任何特定下游任務無關；最典型的是 perplexity。Extrinsic（外在）評估則把模型放進一個具體任務裡，用任務本身的指標衡量它解決問題的好壞，例如機器翻譯用 BLEU、摘要用 ROUGE、分類用 accuracy / F1、檢索用 nDCG@k / Recall@k。

原理：perplexity 衡量模型對下一個 token 預測的「不確定性」，定義為交叉熵的指數：

$\mathrm{PPL}(W) = \exp\!\left(-\frac{1}{N}\sum_{i=1}^{N} \log p(w_i \mid w_{<i})\right)$

數值越低越好，代表模型越「不驚訝」。BLEU 則是 n-gram precision 的幾何平均再乘上簡短懲罰（brevity penalty）：

$\mathrm{BLEU} = BP \cdot \exp\!\left(\sum_{n=1}^{N} w_n \log p_n\right)$

它衡量「輸出與參考譯文的 n-gram 重疊度」。ROUGE 則偏向 recall + 最長共同子序列（LCS），衡量「參考摘要被覆蓋了多少」，因此摘要任務愛用 ROUGE。

具體例子：你把同一份語料丟給兩個 base model 算 perplexity，A=12、B=18，代表 A 對這份語料的擬合更好（intrinsic）。但這不保證 A 在「客服問答」上更好用——要真正知道，得拿實際問答資料跑 F1 或人工評分（extrinsic）。

常見陷阱：(1) 高 BLEU 不等於模型「更聰明」或詞彙更豐富，它只衡量與參考文本的字面相似度，社群來源明列為高頻陷阱。(2) perplexity 只能在「同一 tokenizer、同一測試集」下比較，跨模型直接比 perplexity 常常無意義。(3) accuracy 在類別不平衡時會騙人，此時 F1 才可靠。

常考點：perplexity 是 intrinsic、越低越好；BLEU 衡量與參考文本的 n-gram 相似度，不代表語意理解或詞彙量。ROUGE 偏 recall 用於摘要，BLEU 偏 precision 用於翻譯。

LLM-as-a-judge and human evaluation

定義：當輸出是開放式長文、BLEU/ROUGE 這類字面比對失效時，需要更貼近「人會怎麼評」的方法。Human evaluation（人類評估） 是請真人依評分量表（rubric）對輸出打分或做兩兩偏好比較，被視為品質的 ground truth。LLM-as-a-judge 則用一個能力強的 LLM 依照校準過的 rubric 自動評分，以低成本、可規模化地逼近人類判斷。

原理：LLM-as-a-judge 把「評估」本身當成一個 prompting 任務：給裁判模型一份明確 rubric（例如正確性、相關性、安全性各 1–5 分），或讓它在兩個回答之間做 pairwise 偏好選擇。關鍵是 rubric 要校準——先用一小批有人工標註的樣本驗證「裁判分數」與「人類分數」的一致性，再放大使用。Human eval 雖準，但慢、貴、且有評分者間變異（inter-annotator variability），所以實務上常用「人類標一小批當校準與 ground truth，LLM-judge 跑大量」的混合策略。

具體例子：評估一個 RAG 客服機器人的答案品質，無法用 BLEU（沒有單一參考答案）。做法是寫一份 rubric（事實正確性、是否有引用來源、語氣），先請 3 位標註者對 100 題打分，確認 LLM-judge 給的分數與人類相關性夠高後，再用 LLM-judge 評 1 萬題。

常見陷阱：(1) LLM-judge 有 position bias（偏好先出現的選項）與 verbosity bias（偏好較長答案），需用交換順序、控制長度來緩解。(2) 用「同家族模型當裁判評自己」會有 self-preference bias。(3) 完全跳過 human eval、把 LLM-judge 當絕對真理，會放大裁判模型自身的偏誤。

常考點：human evaluation 是品質 ground truth；LLM-as-a-judge 需校準 rubric 並注意 position / verbosity bias，常與人工標註混合使用以兼顧規模與可信度。

---

Benchmarking & Comparison

Public benchmarks: MMLU, HellaSwag, TruthfulQA

定義：公開 benchmark 是一套固定、公開、可重現的題庫，用來橫向比較不同 LLM 的能力。三個必背的是：MMLU（Massive Multitask Language Understanding，57 個學科的多選知識題，衡量廣度知識）、HellaSwag（常識性句子接續推理，衡量 commonsense）、TruthfulQA（衡量模型是否會跟隨人類常見的錯誤迷思，即「誠實 / 抗幻覺」）。延伸還有 GSM8K（小學數學推理）、HumanEval（程式生成 pass@k）、MT-Bench（多輪對話品質）、BEIR（檢索）。

原理：benchmark 的價值在於「控制變因」——所有模型考同一份卷，分數才可比。多選題型用 accuracy；程式生成用 pass@k（生成 k 次至少一次通過測試的比率）；對話品質常用 LLM-as-a-judge（MT-Bench）。但 benchmark 是離線、靜態的，只是能力的代理（proxy），不等於真實場景表現。

下表為三大 benchmark 的對照（分數為示意，勿當真實成績）：

具體例子：要在兩個開源模型間選一個做數學家教，與其只看官網宣稱的 MMLU 平均分，不如直接看 GSM8K——因為它最貼近你的任務。

常見陷阱：(1) train-test contamination（資料汙染）——benchmark 題目外洩進訓練資料，分數虛高。(2) benchmark gaming——針對榜單過擬合，實際泛化差。(3) 拿單一平均分當萬靈丹，忽略任務對齊。

常考點：MMLU=多學科知識、HellaSwag=常識推理、TruthfulQA=抗迷思誠實。要警覺 train-test contamination 與 benchmark gaming，benchmark 只是能力的 proxy，不等於線上表現。

Domain-specific eval suites

定義：通用 benchmark 無法反映特定垂直領域（醫療、金融、法律、企業內部知識）的真實需求，因此需要 domain-specific eval suites（領域專屬評估套件）——針對該領域任務、資料與風險量身打造的測試集與指標。對 RAG 系統，常用如 RAGAS 的 faithfulness（忠實度）、context precision / recall 等指標。

原理：建構領域評估套件的步驟是：(1) 蒐集代表性的真實案例（理想上含領域專家標註的正解）；(2) 定義對該領域真正重要的指標——醫療重「事實正確 + 不可幻覺」、檢索重 Recall@k、客服重「是否引用正確來源」；(3) 納入 guardrail 指標監控安全與合規。對 RAG，評估須拆成「檢索品質」（retriever 找對文件了嗎，用 context recall）與「生成忠實度」（答案有沒有忠於檢索到的內容，用 faithfulness），才能定位問題出在哪一段。

具體例子：一個企業合約問答 RAG，整體答對率不佳。拆開看：context recall 高（檢索找到對的條款）但 faithfulness 低，代表問題在生成端——模型沒忠於檢索內容、自行腦補，應加強「只根據提供文件作答」的 prompt 約束或換更聽話的生成模型。

常見陷阱：(1) 直接套通用 benchmark 結論到垂直場景，忽略 distribution shift。(2) RAG 評估只看最終答案、不拆檢索 vs 生成，導致無法定位。(3) 企業 RAG 的關鍵實作其實是對向量庫中專有資料的存取控制與安全（社群來源點名的 enterprise RAG 陷阱），評估時也須納入權限正確性。

常考點：RAG 評估要拆成檢索品質（context recall）與生成忠實度（faithfulness）兩段；企業領域評估須納入存取控制與安全，且通用 benchmark 不可直接外推到垂直領域。

---

Online Experimentation

A/B testing for LLM features

定義：A/B testing 是線上實驗方法——把使用者隨機分成兩（或多）組，A 組用舊版（control），B 組用新版（treatment，例如新 prompt、新模型、新 RAG 設定），在同一時間比較兩組在真實流量上的指標差異，以統計方式判斷新版是否真的更好。

原理：可信的 A/B test 有四個要件。(1) 並行 + 平衡分流：兩組必須同時上線、用平衡（例如 50/50）的流量切分——這樣才能排除時間因素（週末 vs 平日、活動檔期）的干擾。順序部署（先全跑舊版再全跑新版）是錯的，因為無法區分是版本變好還是時段不同。(2) 指標分層：選一個 primary metric（如任務完成率、轉換率）作為勝負判準，同時設 guardrail metrics（如延遲、成本、拒答率、安全違規率），確保新版沒有在別處變糟。(3) 樣本數 / 統計檢定力：先估計 sample size，確保有足夠資料偵測出有意義的差異。(4) 監控：上線後持續觀察，異常即止血。

具體例子：要驗證「換上新的 system prompt」是否提升客服解決率。把 50% 流量導到新 prompt、50% 維持舊 prompt，同時跑兩週。primary metric = 一次解決率，guardrail = 平均延遲與升級轉真人率。若新版解決率顯著上升、延遲與升級率沒惡化，才放量。

常見陷阱：(1) 順序部署或不平衡分流——社群來源明確點名「A/B test 必須同時、平衡（50/50）分流，sequential 是錯的」。(2) 只看 primary、忽略 guardrail，結果延遲或成本爆掉。(3) 樣本不足就下結論（false positive）。

常考點：A/B testing 須同時並行、平衡（50/50）分流；順序部署是錯的。要同時追蹤 primary metric 與 guardrail metrics，並確保樣本數足以達到統計顯著。

Hyperparameter tuning for fine-tuning

定義：Hyperparameter tuning 是在 fine-tuning 前/中系統化地調整「不由訓練學出、需人為設定」的超參數，以在不過擬合的前提下取得最佳下游表現。LLM fine-tuning 的關鍵超參數包括 learning rate（學習率）、batch size、epochs（訓練輪數），以及 PEFT/LoRA 專屬的 rank（r） 與 alpha。

原理：各超參數的作用與權衡如下表。

原理上 LoRA 在原權重旁插入低秩分解 ( \Delta W = B A )，只訓練 A、B，rank 控制可學容量、alpha 控制縮放（有效縮放約為 alpha / r）。實務上會用 W&B 或 MLflow 做 experiment tracking，記錄每組超參數對應的 validation loss 與下游指標，再做網格 / 隨機 / 貝氏搜尋。learning rate 通常是影響最大的超參數，優先掃。

具體例子：用 LoRA 微調一個 7B 模型做法律問答。固定 batch size 與 epochs，先掃 learning rate 找到驗證 loss 最低的 1e-4，再調 LoRA rank（8→16→32）觀察是否過擬合，全程用 W&B 記錄並比較曲線。

常見陷阱：(1) epochs 設太多 → overfitting + catastrophic forgetting（喪失原本能力）。(2) learning rate 太高 → loss 發散或模型遺忘預訓練知識。(3) 只看 training loss、不看 validation/下游指標，看不出過擬合。(4) 誤把 quantization 當成提升準確率的手段——量化只省記憶體、降延遲，不會提升準確率（社群高頻陷阱）。

常考點：learning rate 影響最大、優先調；epochs 過多導致 overfitting 與 catastrophic forgetting；LoRA 的 rank 控容量、alpha 控縮放；用 W&B / MLflow 追蹤實驗。量化是省記憶體 / 降延遲，不提升準確率。