跳轉到

LLM Evaluation 進階：Cost-Aware 評估、線上 A/B 與離線指標的對齊

這是 LLM Evaluation 實務 的進階篇，2026-06-21。基礎篇已涵蓋 RAG 評估、Agent Trajectory、Golden Dataset 與 LLM-as-Judge 偏誤。本頁往前推進兩個常被省略的主題：把「成本」納入評估決策，以及離線評估與線上 A/B 怎麼不失真地對齊。

實證標記：〔論文〕= 出自學術論文；〔框架〕= 出自框架或平台官方文件；〔實務〕= 業界慣例或本人整理。

從「答對幾分」到 Cost-Quality 權衡

大多數離線評估只看品質分數，但實際部署時工程師面對的決策更像這樣：〔實務〕

  • 用更強的模型把 faithfulness 從 0.83 推到 0.87，值得嗎？
  • 同預算下，routing 能讓 80% 查詢走小模型，整體品質能維持嗎？
  • 每次 eval run 本身要花多少 token？能長期負擔嗎？

成本不是評估的副產品，是評估的一個維度。 忽略成本的評估，給出的建議只在「預算無限」的假設下才成立。

Cost-Aware 評估的三個切入點

1. 在固定品質門檻內最小化成本

把問題倒過來問：「在品質 ≥ 門檻的前提下，最便宜的配置是什麼？」〔實務〕

做法： 1. 把所有候選配置跑過 golden set，記錄品質分數 + token 用量（in/out）。 2. 根據模型定價換算每千次查詢成本。 3. 畫出 quality–cost scatter plot：x 軸成本，y 軸品質，標出 Pareto frontier。 4. 設定業務決定的品質下限，在下限以上挑最便宜的配置。

配置 Faithfulness Cost / 1000 queries (USD) 備註
Strong model (full) 0.91 4.20 基準
Mid model + rerank 0.87 0.95 Pareto 優選
Mid model (no rerank) 0.81 0.55 剛過門檻，最便宜
Weak model 0.72 0.18 低於門檻，不選

〔實務〕品質門檻是業務決策，不是技術決策——「faithfulness 0.80 夠用嗎？」要問產品，不要由工程師單方面設定。

2. 評估本身的 Token 預算

LLM-as-judge 呼叫次數一多，eval pipeline 本身的成本可能超過推理本身。〔實務〕

  • 長鏈 agent trace 評估：每條 trace 呼叫 judge 多次，成本呈超線性上升。
  • 解法：先用規則 / 快速指標篩一遍，只把模糊 case 送 judge。 典型做法：70% 用確定性指標（精確比對、格式驗證），30% 用 LLM judge，整體成本可壓縮 60–70%。
  • 進一步選項：蒸餾 judge——用強模型做少量標注，再 fine-tune 一個小分類器當 judge，推理成本可低一至兩個數量級。〔實務〕

3. Routing 評估：評路由決策本身

若系統有模型 routing（難題走強模型、簡單查詢走弱模型），光看端到端品質不夠，還需要：〔實務〕

  • 路由準確率：哪些 query 應走強模型，路由器有沒有判對？
  • 成本節省 vs 品質降損：routing 省了多少錢，品質跌了多少？
  • 降級的失敗模式：哪類 query 被路由到弱模型後會系統性出錯？

〔實務〕路由評估需要一份含難度標記的 golden set——同一批 query 同時用兩個模型跑，人工或強 judge 標記哪些「必須走強模型」。沒有難度標記就無法有意義地評估路由。

離線評估與線上 A/B：角色分工

兩者是互補工具，不是替代關係：〔實務〕

離線評估 線上 A/B
用途 快速迭代、回歸把關 驗證真實業務影響
速度 快（分鐘級） 慢（需累積流量，數天至數週）
成本 低 高（需維護兩套流量、承擔錯誤暴露）
指標 代理指標（judge 分、quality score） 業務指標（轉換率、留存、CSAT）
最大風險 代理指標和真實用戶行為脫鉤 真實用戶暴露在較差版本

合理分工：離線做迭代與篩選；只有重大改動才上 A/B。以下情況必須上線驗證：〔實務〕 - 換底座模型（不只調 prompt） - 改動影響超過約 10% 的 query 流量 - 預期有顯著提升的功能（而非保守的「不差就好」）

如何設計線上 A/B 實驗

護欄指標（Guardrail Metrics）

定義兩種指標：〔實務〕

  • Primary metric（最大化）：如 CSAT、任務完成率、點閱。
  • Guardrail metric（不能讓它變差）：如 P95 latency、error rate、cost per query。

沒有護欄指標，A/B 很容易「主指標漲，但延遲爆掉」。護欄指標只要觸破，即使 primary 贏了也要 rollback。

統計功效與多次偷看問題

不要跑到 p = 0.05 才停——線上實驗的 repeated peeking（重複看結果）會讓 false positive 率大幅提升。〔論文〕

  • 事前算好需要多少樣本才有足夠功效（統計功效分析），再開始跑。
  • 考慮 Sequential testing（如 mSPRT、anytime-valid inference），才能安全地提前停止或延長。〔論文〕

分群分析防止整體遮蓋細節

整體指標贏了，不代表所有用戶都受益。結果要拆 subgroup 看：〔實務〕 - 新用戶 vs 老用戶 - 簡單 query vs 複雜 query - 不同語言 / 地區 / 功能入口

整體贏但特定子群輸，上線前要明確決定能否接受該權衡。

離線與線上指標的對齊

根本問題：代理指標不等於業務指標

LLM judge 的分數只是業務成果的代理（surrogate），兩者的相關性需要被主動驗證，而不能假設存在。〔實務〕

常見「代理失效」的情形： - Faithfulness 高，但用戶覺得回答不自然、不愛用。 - 在 golden set 上 judge 分高，但在真實長尾 query 上出問題（golden set 沒有充分代表真實分布）。 - 模型 A 在 judge 上勝過模型 B，但 A 的回答較長，部分源自 verbosity bias 而非真實品質差異。

校準代理指標的做法

  1. 定期抽人工標注：從線上流量中抽樣，真人打分，和 judge 分數做相關分析。相關性過低時，judge 的信度不足，應重新設計 rubric 或換 judge 模型。〔實務〕
  2. 回測大 A/B 的結果：大的 A/B 實驗（有真實業務指標）完成後，回頭看當時的離線指標有沒有正確預測方向。方向對說明代理有效；方向錯要重新設計離線評估。〔實務〕
  3. 方向一致比數字準確更重要：代理指標的核心用途是篩選配置的排名，而非告訴你絕對值。「A 比 B 好」比「A 得 0.83」重要。

〔實務〕每隔一段時間（新模型上線或業務目標調整時）重做一次 offline-online calibration：跑幾個已有 A/B 結論的變體，確認離線分數的方向性預測仍然準確。這是讓離線評估長期可信的最重要維護動作。

整合的評估決策流程

1. 快速離線篩選（品質 + 成本）
        ↓ 只有通過品質門檻且在 Pareto frontier 上的配置
2. Golden set 回歸測試（確認沒有退步）
        ↓ 通過
3. Shadow test 或小量流量（offline-online 對齊確認）
        ↓ 方向一致
4. 線上 A/B（含護欄指標、預算樣本量、subgroup 分析）
        ↓ 主指標贏、護欄沒觸破
5. 全量上線

離線評估是速度，線上 A/B 是真相。兩者都需要，只是用在對的階段。〔實務〕

延伸閱讀（本站）

來源