有信心地上線：評測驅動開發、護欄與 LLMOps

為什麼傳統軟體做法會失靈

一般的程式碼是確定性的：相同輸入給出相同輸出，所以單元測試可以斷言完全相等。大型語言模型打破了這個假設。同一段提示可能產生不同的措辭，而「正確」是模糊的——許多說法一樣好。一個修好某個案例的改動，可能悄悄弄壞另外十個。所以你不能只是肉眼看幾個例子就上線。你需要把評測（evaluation）當成一種持續、可量測的實務，而不是一次性的檢查。

P(x_t \mid x_{<t}) = \mathrm{softmax}\!\left(\frac{z_t}{T}\right)

每次都从这个带温度系数的概率分布中采样，正是同一个提示会产生不同措辞的原因。

評測驅動開發

評測驅動開發把順序顛倒過來：在你調整提示之前，先建立定義「成功」的測試集。蒐集真實（或擬真）的輸入、寫下好答案長什麼樣子，再把它變成一個評分器。現在每一次提示微調、模型抽換或 RAG 改動，都對著同一把尺來量測。你不再爭論輸出「感覺有沒有比較好」，而是開始盯著一個數字移動。

建立一個由 50 至 200 個有代表性案例組成的黃金集，包含那些以前弄垮你的棘手邊界案例。
為每個案例挑選評分器：結構化輸出用完全相符或符合結構的檢查、擷取任務用基於參考答案的指標，開放式品質則用以大型語言模型當評審（LLM-as-judge）。
在每次改動時跑完整組，並像對待任何測試套件一樣，在版本控管中追蹤分數隨時間的變化。
留意污染（contamination）與評審偏誤——大型語言模型評審是可以被騙的，所以要拿它和人工評分抽樣比對。

產品評測：離線與線上

產品評測有兩半。離線評測在發布前跑你的黃金集——快、便宜、可重複，是上線的關卡；線上評測量測上線後的產品：按讚率、任務完成率、轉接給真人的比例，以及不同提示版本之間的 A/B 測試。離線告訴你這個改動是否安全；線上告訴你使用者是否真的過得更好。一個模型可能在你的基準上獲勝，卻仍然惹惱真實的人，所以兩者你都需要。

正式環境中的護欄

護欄（guardrails）是包住每一次模型呼叫的檢查，讓壞的輸入或輸出永遠到不了使用者——或讓使用者的資料永遠到不了一個不該看到它的工具。在進來的路上，你篩檢提示注入（prompt injection）與超出範圍的請求；在出去的路上，你執行內容審核（content moderation）、用你的結構驗證輸出，並在呈現之前確認主張有檢索來源支撐。護欄是分層防禦，不是單一過濾器：假設每一層都不完美，然後把它們疊起來。

LLMOps：讓它持續存活

LLMOps 是應用上線之後的維運紀律：為每一段提示與每一個模型加上版本、為了可觀測性（observability）記錄完整的請求／回應追蹤、在真實流量上監控品質、成本與延遲，並能在某個供應商悄悄更新模型、害你評測分數下滑時立刻回滾。你所仰賴的大型語言模型可能在你腳下改變，所以要把模型當成一個有版本、被監控的相依——並讓離線評測按表定期執行，而不只是在發布時跑一次。