15 分鐘手工打造一套 LLM 評估集：不用 MLflow，不用平台

每次更換模型、修改提示詞（Prompt）、調整 temperature，你想知道結果會變好還是變壞，但只能把剛生成的那幾段讀一遍，憑感覺說「感覺差不多」。這套流程撐得過 Demo，卻撐不過正式上線：感覺不穩定，不同人員之間標準不一致，過了兩週你自己也記不清上次到底是什麼水準。

評估集是解藥，但它不一定要厚重。下面這套方案，一個 JSON 檔案加一個 Python 腳本，15 分鐘就能跑起來，只需要你手邊有一份真實的任務列表。

第一步：題目從哪來

**永遠不要手寫理想化的題目。** 去翻閱生產環境日誌或 Beta 用戶反饋，把最近 30 天裡「答錯了」或「用戶追問了第二遍」的請求篩選出來，每個 Case 就是一個未來的測試題。

篩選時保留三種類型：

- 答案錯誤的（有明確對錯）

- 答對但很囉嗦或很離譜的（品質問題）

- 邊界場景（超長輸入、中英混排、模糊指令）

10~20 個就足夠開始。50 個以上才是「維護一套評估」的負擔，前 20 個價值最大——它們全部來自你的真實失敗經驗。

第二步：每道題長什麼樣

一個 JSON 陣列，每題三個欄位：

{
  "id": "invoice-overflow-001",
  "prompt": "這是一張 $47.99 的帳單，套餐是 $45，請處理差額",
  "expect": {
    "contains_any": ["$2.99", "2.99"],
    "max_tokens": 200
  }
}

`expect` 是斷言層，按任務類型挑選：

- **事實性任務**（計算、提取、翻譯）：`contains_any` / `not_contains` / 精確匹配，能自動化判分的直接判定

- **格式任務**（要 JSON、要表格）：加上 `json_valid: true`，或做一次 Schema 檢查

- **風格任務**（寫文案、改寫）：別硬寫關鍵字，在 `expect_notes` 裡留一句人話，跑完後人工掃視一遍，60 秒一個 Case，比維護脆弱的關鍵字更快

關鍵原則：**能自動斷言的絕不靠人工判斷，人工判斷只留給真正主觀的部分。** 如果一半的 `expect` 你寫了又刪、不知道寫什麼，說明這類題目不適合進入當前版本的評估集。

第三步：評分與對比

腳本核心 20 行：循環每題調用一次 API，收集輸出和耗時，對 `expect` 執行斷言，輸出一個表格：

| case | 通過 | 耗時 | 備註 |

|------|------|------|------|

| invoice-overflow-001 | ✅ | 2.3s | |

| mt-fallback-zh-003 | ❌ | 4.1s | 漏了「半形括號要保留」 |

對比用法的價值就在這裡：更換模型/修改提示詞之前先跑一版，把輸出存進 `runs/20260901-before/`，改完後跑進 `runs/20260901-after/`，Diff 兩個資料夾。重點關注三類變化：

1. **以前對的現在錯了**（回歸，最嚴重，優先修復）

2. **以前錯的現在對了**（改善，先確認它為什麼對）

3. **兩邊都錯但錯法變了**（中性，記下一筆，觀察趨勢）

別追求一次覆蓋所有維度。第一版只回答一個問題：**這次改動，手邊的 Case 錯了幾道。**

三個常見的坑

**坑一：題目洩漏。** 如果線上用戶會遇到相同的提示詞，評估題裡的 Prompt 一旦出現在對外文件、錯誤訊息或日誌裡，等於開了作弊通道。題目 ID 和 Prompt 不要外洩。

**坑二：temperature=0 的假確定性。** 很多模型在 0 溫度下輸出仍有微幅波動，兩次跑分輸出不一樣，不代表模型變壞或變好。判斷「回歸」至少要連續跑 2 次，兩次都錯才記錄。

**坑三：集合只進不出。** 「連續 5 次全對且從未再出錯的 Case」移到 `archive/` 子目錄。留在主集合裡的，應該永遠是能區分模型優劣的題目，而不是全公司歷史上的所有題目。

從哪裡開始

打開今天的 API 日誌，篩選出 10 個「答得不理想」的請求，寫成 JSON，補上斷言，跑一次、存檔，評估 v0.1 就有了。下一次修改提示詞或更換模型之前先跑 v0.1，你會拿到一個數字，而不是一種感覺。這個數字，就是你和下一個版本之間的那份合約。