企業 LLM 評估框架：基準測試到業務指標的方法論

一、引言：為什麼「跑個 Benchmark」遠遠不夠

2026 年，幾乎每家考慮導入 LLM 的企業都會面臨同一個問題：該選哪個模型？直覺反應是去看排行榜——MMLU 排名、Chatbot Arena Elo 分數、各家廠商的技術報告。然而，任何有實際部署經驗的技術團隊都會告訴你：排行榜上的第一名，往往不是你業務場景裡的最佳選擇。

這不是排行榜的錯。學術基準測試有其嚴謹的設計目標與方法論^[1]，問題在於企業的評估需求遠比「模型 A 是否比模型 B 聰明」複雜得多。考慮以下真實場景：

一家金融服務公司需要 LLM 協助分析師撰寫投資報告。他們的評估需求包括：對繁體中文金融術語的精準理解（不是泛用中文能力）、引用數據的事實準確性（幻覺率必須低於 0.5%）、生成報告的格式一致性（符合公司內部模板）、每次生成的成本（預算有限）、API 回應延遲（分析師不願等超過 8 秒）、以及合規性（不能將客戶數據送往特定地區的伺服器）。

MMLU 分數能告訴你上述任何一個面向嗎？答案是否定的。

這正是為什麼企業需要一套系統性的 LLM 評估框架——不是取代學術基準，而是在其基礎上建構多層次、多維度、持續性的評估體系。本文將提供這套框架的完整方法論，從理論基礎到可直接套用的實踐模板。

二、評估框架的三個層次：評估金字塔

企業 LLM 評估應遵循由寬到窄、由通用到專用的三層金字塔結構。每一層的目的不同，投入的資源與時間也不同，但缺少任何一層都會導致評估結論的偏頗。

企業 LLM 評估金字塔

            /\
           /  \          第三層：業務導向評估
          / 業務 \         ROI、用戶滿意度、合規性
         / 指標  \        → 最終決策依據
        /----------\
       /   任務導向  \      第二層：任務導向評估
      /   評估測試集   \     領域測試集、Few-shot、端到端
     /                \   → 篩選候選模型
    /------------------\
   /    學術基準測試     \    第一層：學術基準評估
  /  MMLU  HumanEval    \   MMLU、HumanEval、MATH、ARC
 /   MATH  BigBench ARC  \  → 建立能力基線
/________________________\

成本遞增 ↑  |  篩選精度遞增 ↑  |  業務相關性遞增 ↑

第一層：學術基準評估（能力基線）

目的是快速建立模型的通用能力基線，淘汰明顯不合格的候選者。這一層主要依賴公開基準測試的成績，不需要企業自行投入大量測試資源。典型耗時：1-2 個工作日（主要是蒐集與比較數據）。

第二層：任務導向評估（領域能力）

目的是在企業的具體任務上測試模型表現，使用領域專屬的測試集與評估標準。這一層需要企業投入領域專家的時間來設計測試集與評分標準。典型耗時：1-3 週（含測試集設計、執行與分析）。

第三層：業務導向評估（決策依據）

目的是將模型表現轉化為業務語言——成本效益、用戶體驗、風險管理。這一層需要跨部門協作（技術團隊 + 業務團隊 + 合規團隊）。典型耗時：2-6 週（含 A/B 測試與試營運）。

接下來，我們將深入探討每一層的具體方法論與實踐細節。

三、學術基準測試深度解析

學術基準是 LLM 評估的基石。儘管它們有局限性，但理解這些基準的設計邏輯、測量目標與已知缺陷，是建構企業評估框架的必要基礎^[1][3]。

3.1 主流學術基準總覽

3.2 學術基準的已知局限

企業在參考學術基準時，必須清楚認識以下局限性：

數據污染（Data Contamination）——這是最嚴重的問題。MMLU 等公開基準的題目早已散佈在互聯網上，模型在預訓練階段可能已經「見過」這些題目^[1]。這意味著高分可能反映的是記憶能力而非真正的理解能力。2025 年後發布的模型普遍在 MMLU 上超過 85%，但在全新設計的測試集上表現差距可達 10-15 個百分點。

天花板效應（Ceiling Effect）——當多個頂尖模型都在 MMLU 上達到 88-92% 時，2-3% 的差距是否有統計顯著性？是否反映了真實能力差異？答案往往是否定的。MMLU-Pro 的出現正是為了緩解這一問題，但天花板效應會在每個基準上重複出現。

評估格式依賴（Format Sensitivity）——同一個問題用不同格式呈現（多選題 vs. 開放式問答），模型的表現可能差異 5-20%。企業的真實場景幾乎不會是四選一的多選題，因此多選題格式的分數對業務預測力有限。

語言偏差（Language Bias）——絕大多數學術基準以英文為主。繁體中文的評估資源極為稀缺，MMLU 的中文翻譯版本品質參差不齊。對於主要服務繁體中文用戶的企業而言，英文基準分數的參考價值需打折計算。

3.3 企業如何正確使用學術基準

儘管有上述局限，學術基準仍是評估流程中不可或缺的第一步。正確的使用方式是：

設定門檻而非追求排名。例如：「我們的候選模型必須在 MMLU 上達到 80% 以上，在 HumanEval 上達到 pass@1 70% 以上」——這是合理的。但「模型 A 在 MMLU 上比模型 B 高 1.2%，所以模型 A 更好」——這是不合理的推論。

關注弱項而非強項。如果一個模型在 TruthfulQA 上顯著落後於同級模型，這是一個值得警惕的信號，可能暗示該模型在事實準確性上有系統性缺陷。

交叉驗證多個基準。不要只看一個基準分數。HELM^[3] 的核心價值正是提供跨多個維度的整體評估，讓企業可以看到模型的全面輪廓而非單一面向。

四、任務導向評估設計

通過學術基準篩選出候選模型後，企業需要設計針對自身業務場景的任務導向評估。這是整個評估框架中投入產出比最高的環節——它既不像學術基準那樣泛化，也不像全面業務評估那樣昂貴。

4.1 測試集設計原則

高品質的任務導向測試集是企業最重要的評估資產。以下是設計原則：

原則一：來源於真實業務數據。最好的測試樣本是從實際業務場景中提取的。如果你評估 LLM 用於客服場景，測試集應包含真實的客戶問題（脫敏後），而非人工編造的問題。真實數據包含的長尾分佈、表達多樣性和語境複雜度，是人工數據無法複製的。

原則二：覆蓋邊界案例（Edge Cases）。模型在「正常」場景下的表現通常差異不大，真正拉開差距的是邊界案例。測試集應刻意包含：模糊指令、矛盾資訊、需要拒絕回答的場景、多語言混用、超長上下文等。建議邊界案例佔測試集的 20-30%。

原則三：分層設計（Stratified Design）。將測試集按難度、場景類型、語言等維度分層，確保每一層都有足夠的樣本量（建議每層至少 50 個樣本）。這樣可以細粒度地分析模型在不同子場景下的表現差異。

原則四：標註黃金標準答案（Gold Standard）。每個測試樣本都需要一個或多個「正確答案」作為比較基準。對於開放式生成任務，至少需要 2-3 個領域專家獨立標註的「參考答案」，以及明確的評分標準（rubric）。

4.2 Few-shot 評估策略

Few-shot 評估是衡量模型在少量範例引導下適應新任務能力的標準方法。企業在設計 Few-shot 評估時需注意以下要點：

Few-shot 評估設計模板:

System Prompt:
你是一位 [角色描述]。你的任務是 [任務描述]。
請嚴格按照以下格式輸出：[格式要求]。

示範 1（Easy）:
輸入: [真實業務輸入樣本 1]
輸出: [黃金標準答案 1]

示範 2（Medium）:
輸入: [真實業務輸入樣本 2]
輸出: [黃金標準答案 2]

示範 3（Hard / Edge Case）:
輸入: [真實業務輸入樣本 3]
輸出: [黃金標準答案 3]

測試輸入:
輸入: [待評估的測試樣本]
輸出:  ← 模型生成，與黃金標準比較

評估變項:
- 0-shot: 僅 System Prompt，無示範
- 1-shot: 1 個示範
- 3-shot: 3 個示範（推薦基線）
- 5-shot: 5 個示範（上限，更多未必更好）

關鍵發現：企業場景中，3-shot 通常是最佳的平衡點。超過 5 個示範往往會因為上下文過長而導致模型注意力分散，實際表現反而下降^[6]。同時，示範的品質遠比數量重要——一個精心設計的示範勝過五個隨意選取的範例。

4.3 領域專屬測試集範例

以下列舉不同產業的任務導向測試集設計思路：

金融服務：測試集應涵蓋——財報摘要生成（比較生成摘要與分析師手寫摘要）、數字提取準確性（從財報 PDF 中提取特定數字）、合規術語使用（是否正確使用金管會規定的標準用語）、風險提示完整性（是否遺漏重要的風險因子）。

醫療健康：測試集應涵蓋——病歷摘要生成（與主治醫師的摘要對比）、藥物交互作用查詢（與藥典對照的準確性）、拒絕回答的能力（對超出範圍的醫療建議請求說不）、醫學術語中英對照的一致性。

法律服務：測試集應涵蓋——合約條款分析（識別關鍵條款與風險點）、法規引用準確性（引用的法條是否存在且內容正確）、法律意見書的邏輯結構（論證是否完整且有說服力）、多管轄區法律差異的正確區分。

製造業：測試集應涵蓋——故障報告分析（從描述中提取故障類型與嚴重等級）、SOP 生成的完整性與安全性（是否遺漏關鍵步驟）、技術文件的翻譯品質（專業術語的一致性）、數據分析報告的圖表描述準確性。

五、業務導向指標：將模型表現轉化為商業語言

這是評估金字塔的頂層，也是最終決策的核心依據。業務導向指標的設計需要技術團隊與業務團隊的緊密協作——技術團隊理解模型能力的邊界，業務團隊定義「成功」的標準。

5.1 核心業務指標框架

5.2 成本效益分析的正確方式

企業在計算 LLM 的成本效益時，最常犯的錯誤是只比較 API 單價。正確的成本效益分析需要考慮全鏈路成本：

每個成功任務的真實成本 =

  API 呼叫成本（input tokens × 單價 + output tokens × 單價）
+ 重試成本（失敗率 × 重試次數 × 單次 API 成本）
+ Prompt 工程成本（設計與優化 prompt 的人力時間）
+ 後處理成本（解析、驗證、格式化的計算資源）
+ 人工審核成本（需人工覆核的比例 × 人工覆核單價）
+ 錯誤修正成本（幻覺或錯誤導致的後續修正成本）
─────────────────────────────────
÷ 成功任務數

關鍵洞察:
- 便宜的模型若幻覺率高 5%，人工審核成本可能抵消所有 API 節省
- 貴的模型若格式遵循率高 20%，可節省大量後處理工程時間
- 快的模型在互動場景中提升用戶體驗，間接提高任務完成率

我們在為企業客戶做模型選型時，經常發現一個反直覺的結論：單價最高的模型往往有最低的全鏈路成本。原因是高能力模型的一次成功率更高，需要更少的重試、更少的人工覆核、更少的錯誤修正。當然這不是絕對的——關鍵在於量化分析而非直覺判斷。

5.3 延遲預算的分配

延遲是用戶體驗的核心指標之一，但不同場景對延遲的容忍度差異巨大。企業需要為每個場景設定明確的延遲預算（Latency Budget），並據此選擇模型與部署架構：

即時互動場景（延遲預算 <2 秒）：聊天機器人、程式碼自動完成、即時翻譯。這類場景通常需要選擇較小的模型或使用 streaming 輸出，並可能需要犧牲部分品質來換取速度。

準即時場景（延遲預算 2-10 秒）：文件摘要、郵件草稿、資料分析。用戶願意等待幾秒鐘以獲得更好的品質。這是大多數企業場景的延遲預算區間，也是當前頂尖模型表現最好的區間。

批次處理場景（延遲預算 >10 秒）：大規模文件處理、報告生成、數據標註。延遲不是主要考量，可以使用最強的模型並在成本上尋求批次折扣^[7]。

六、LLM-as-Judge 自動化評估

LLM-as-Judge 是近兩年 LLM 評估領域最重要的方法論突破^[4]。其核心思想是：使用一個強大的 LLM（Judge Model）來評估其他 LLM 的輸出品質，從而大幅降低人類評審的成本與時間。

6.1 方法論基礎

LLM-as-Judge 的有效性建立在一個關鍵前提上：評估能力低於生成能力的門檻。也就是說，一個模型判斷「回答 A 是否比回答 B 好」的難度，遠低於它自己生成一個好回答的難度。這就像文學評論家不一定能寫出偉大的小說，但能準確判斷哪部作品更好。

研究顯示，Claude 和 GPT-4 級別的模型作為 Judge，與人類專家的一致性可達 80% 以上^[4]——這個數字已經接近人類標註員之間的一致性（通常為 65-85%）。換言之，LLM Judge 的可靠性已經與個別人類評審員相當。

6.2 評估模式

LLM-as-Judge 有三種主要評估模式，各有適用場景：

模式一：單點評分（Single-Point Scoring）

Prompt 模板:

請評估以下 AI 助手的回答品質。

[用戶問題]: {question}
[AI 回答]: {answer}

請根據以下維度分別評分（1-5 分）:
1. 事實準確性: 回答中的事實是否正確？
2. 完整性: 是否充分回答了問題的所有面向？
3. 清晰度: 回答是否結構清楚、易於理解？
4. 相關性: 回答是否聚焦於問題本身？

請先給出每個維度的簡短評語，再給出分數。
最後給出加權總分（準確性 40%, 完整性 30%, 清晰度 20%, 相關性 10%）。

輸出格式: JSON

適用場景：需要對大量回答進行快速品質評估，例如日常監控。優點是效率高、成本低。缺點是評分可能存在系統性偏差（例如傾向給中等分數）。

模式二：成對比較（Pairwise Comparison）

向 Judge 呈現同一問題的兩個回答，讓它判斷哪個更好。這種模式的可靠性通常高於單點評分，因為相對比較比絕對評分更容易且更一致。這也是 MT-Bench 和 Chatbot Arena 採用的核心方法^[4]。

模式三：參考答案比較（Reference-Based）

向 Judge 提供一個黃金標準答案，讓它評估 AI 回答與參考答案的一致性。這種模式的準確性最高，但需要事先準備黃金標準答案，成本也最高。適用於高風險場景的評估。

6.3 已知偏差與校正方法

LLM-as-Judge 存在幾種已知的系統性偏差，企業在使用時必須進行校正：

位置偏差（Position Bias）——在成對比較中，Judge 傾向偏好第一個（或最後一個）呈現的回答。校正方法：對每一對比較進行兩次評估（AB 順序和 BA 順序），取一致的結果；不一致的標記為平手。

冗長偏差（Verbosity Bias）——Judge 傾向偏好更長的回答，即使短回答更精準。校正方法：在評分標準中明確指出「簡潔性」的權重，並加入「冗長但不增加資訊量的內容應扣分」的指引。

自我偏好（Self-Preference Bias）——模型傾向偏好自己或同家族模型的輸出。校正方法：使用與被評估模型不同家族的模型作為 Judge（例如用 Claude 評估 GPT 的輸出，或反之），或使用多個不同 Judge 交叉驗證。

格式偏差（Format Bias）——Judge 可能偏好使用了 Markdown 格式、列表或粗體字的回答。校正方法：在評分前對回答進行格式正規化（strip formatting），或在指引中明確要求 Judge 忽略格式差異。

6.4 企業 LLM-as-Judge 部署建議

基於實際部署經驗，我們建議企業採用以下配置^[5]：

Judge 模型選擇：使用當前最強的通用模型作為 Judge。2026 年的建議是 Claude Opus 或 GPT-4.5 級別的模型。Judge 模型的能力必須顯著強於被評估的模型——如果被評估模型本身已是頂尖模型，LLM-as-Judge 的可靠性會下降，需要更多人類覆核。

評分標準設計：不要使用泛化的評分標準。為每個業務場景定制評分 rubric，明確描述 1-5 分各自代表什麼，並提供每個分數的具體範例。模糊的評分標準是 LLM-as-Judge 不穩定的最大來源。

人類校準循環：初期（前 200-500 個評估）應同時進行人類評審和 LLM 評審，計算兩者的一致性（Cohen's Kappa 或 Spearman 相關係數）。一致性達到 0.7 以上後，可逐步降低人類覆核比例至 10-20%。

七、人類評審協議設計

儘管 LLM-as-Judge 大幅降低了評估成本，人類評審在企業 LLM 評估中仍扮演不可或缺的角色——它既是 LLM-as-Judge 的校準基準，也是處理 LLM Judge 能力邊界之外場景的最後防線。

7.1 評審員選擇與培訓

評審員的品質直接決定評估結果的可信度。企業應從以下維度選擇評審員：

領域專業性：評估金融 LLM 的評審員必須具備金融背景；評估法律 LLM 的評審員必須具備法律背景。泛用的「標註員」對專業場景的評估品質遠低於領域專家。

校準測試：在正式評審前，所有評審員應完成一組校準測試集（20-30 個樣本，有預設正確答案）。校準測試的準確率低於 80% 的評審員應重新培訓或排除。

雙盲設計：評審員不應知道回答來自哪個模型（或是否來自人類）。所有回答應匿名化且隨機排列，避免品牌效應影響評分。

7.2 評分標準（Rubric）設計

好的評分標準應滿足以下條件：

評分標準設計清單:

□ 每個維度有 3-5 個等級（不建議超過 5 級——區分度不夠可靠）
□ 每個等級有明確的文字描述（不是只有「好 / 一般 / 差」）
□ 每個等級附帶 1-2 個具體範例
□ 維度之間沒有高度重疊（避免重複計分）
□ 包含 N/A 選項（某些維度可能不適用於特定樣本）
□ 有明確的邊界案例指引（例如「如果回答部分正確，應給 3 分而非 4 分」）

範例 — 事實準確性維度:

5 分: 所有事實陳述都可驗證為正確，無任何遺漏
      範例: [附上具體範例]

4 分: 核心事實正確，但有 1-2 處非關鍵的細節瑕疵
      範例: [附上具體範例]

3 分: 核心事實大致正確，但有 1 處可能誤導讀者的錯誤
      範例: [附上具體範例]

2 分: 包含明顯的事實錯誤，可能影響讀者判斷
      範例: [附上具體範例]

1 分: 大量事實錯誤或嚴重幻覺，回答不可信賴
      範例: [附上具體範例]

7.3 評審員間一致性（Inter-Rater Reliability）

評估人類評審品質的最重要指標是評審員間一致性。常用的量化方法包括：

Cohen's Kappa (κ)：衡量兩位評審員之間的一致性，排除隨機一致的影響。κ > 0.6 為可接受，κ > 0.8 為優秀。

Krippendorff's Alpha (α)：可處理多位評審員、缺失數據和不同量尺，是更通用的一致性指標。α > 0.667 為可接受，α > 0.8 為高度可靠。

Intraclass Correlation Coefficient (ICC)：適用於連續型評分（如 1-5 分），衡量評審員之間的絕對一致性。ICC > 0.75 為良好。

如果一致性指標低於可接受閾值，常見的解決方案包括：修訂評分標準使其更明確、增加校準會議、排除一致性特別低的評審員、增加每個樣本的評審員人數（取平均值或多數決）。

7.4 混合評估流程

最具成本效益的方案是將 LLM-as-Judge 與人類評審結合成混合流程：

第一階段：全部樣本由 LLM-as-Judge 評估，生成初步分數與評語。第二階段：LLM Judge 信心度低的樣本（例如評分在 2.5-3.5 的中間區間）由人類評審員覆核。第三階段：隨機抽取 10-15% 的 LLM Judge 高信心度樣本由人類覆核，作為品質控制。第四階段：計算 LLM Judge 與人類評審的一致性，若一致性下降至閾值以下，觸發全面校準。

這種混合流程通常可以在保持 95%+ 的評估品質的同時，將成本降低 60-80%。

八、持續評估與 A/B 測試：CI/CD for LLM Quality

LLM 評估不是一次性的活動——它必須是持續的、自動化的、嵌入到開發和部署流程中的。模型會更新、prompt 會調整、業務需求會變化，任何一個變動都可能導致品質退化。

8.1 持續評估流水線架構

LLM 持續評估流水線

┌─────────────────────────────────────────────────┐
│                    觸發條件                       │
│  Prompt 變更 │ 模型版本升級 │ 測試集更新 │ 定期排程 │
└──────────┬──────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│               測試執行層                          │
│  1. 載入測試集（版本化管理）                        │
│  2. 對每個候選配置執行推論                         │
│  3. 收集回答 + 延遲 + token 用量                  │
└──────────┬──────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│               自動評估層                          │
│  1. 確定性指標: 格式遵循率、延遲、成本              │
│  2. LLM-as-Judge: 品質分數、各維度評分             │
│  3. 自動化比較: 與基線版本的差異分析                │
└──────────┬──────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│               決策層                              │
│  IF 所有指標 >= 基線: 自動通過，可部署              │
│  IF 核心指標退化 > 5%: 自動阻擋，通知團隊           │
│  IF 邊際變化 (1-5%): 標記待人工審查                │
└──────────┬──────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│               監控與告警                          │
│  Dashboard: 即時品質指標、趨勢圖、異常偵測         │
│  告警: Slack/Email 通知品質退化                    │
│  報告: 週報/月報自動生成                           │
└─────────────────────────────────────────────────┘

8.2 回歸測試集管理

回歸測試集是持續評估的核心資產。管理要點包括：

版本化：測試集應使用版本控制系統管理（如 Git），每次修改都有記錄。歷史評估結果必須與對應版本的測試集關聯，否則無法進行有意義的趨勢分析。

持續擴充：每當生產環境中出現模型錯誤（用戶投訴、人工覆核發現的問題），應將該案例加入回歸測試集。這確保同一錯誤不會再次出現——這與軟體工程中「為每個 bug 寫一個測試案例」的原則完全一致^[5]。

分級管理：將測試集分為「核心測試集」（每次都必須跑，~100-200 個樣本，涵蓋最關鍵場景）和「完整測試集」（定期跑，~1000+ 個樣本，涵蓋所有場景）。核心測試集的執行時間應控制在 15 分鐘以內，以便融入 CI/CD 流程。

8.3 A/B 測試設計

當需要在生產環境中比較兩個模型配置時，A/B 測試是黃金標準。LLM 的 A/B 測試有幾個與傳統軟體 A/B 測試不同的要點：

分組單位：建議以用戶為單位分組（而非以請求為單位），確保同一用戶始終接受同一配置。這避免了用戶體驗的不一致性，也使得用戶層級的滿意度指標可比較。

指標選擇：主要指標（Primary Metric）應是直接的業務指標——任務完成率、用戶滿意度、轉換率。次要指標（Secondary Metrics）包括品質分數、延遲、成本。要避免「指標過多導致的多重比較問題」——預先指定 1-2 個主要指標，並據此計算所需樣本量。

樣本量計算：LLM 輸出的變異性通常比傳統功能更高，因此需要更大的樣本量。以任務完成率為例，要偵測 5% 的差異（80% vs. 85%），在 80% 統計檢定力和 5% 顯著水準下，每組需要約 900 個用戶。這意味著低流量場景可能需要 4-8 週才能達到統計顯著性。

提前終止規則：如果 A/B 測試中一個配置明顯劣於另一個（例如錯誤率高出 3 倍），應有預設的提前終止規則以保護用戶體驗。建議使用 Sequential Testing（如 CUSUM 或 Bayesian stopping rules），允許在達到預設樣本量之前做出決策。

8.4 模型退化偵測

LLM 的表現可能因多種原因隨時間退化：模型提供商的靜默更新（API 模型的版本變更）、輸入數據分佈的漂移、prompt 與新版模型的相容性變化等。持續監控需關注以下信號：

品質指標的趨勢下降：使用統計過程控制（SPC）方法，設定品質指標的控制上下限。連續 3 個監控週期低於下限，或連續 7 個週期呈下降趨勢，都應觸發告警。

延遲的異常增加：API 提供商的基礎設施變更可能導致延遲突然增加。監控 P50、P95 和 P99 延遲，任何一個指標的異常跳升都需要調查。

錯誤模式的變化：定期分析錯誤案例的類型分佈。如果出現新的錯誤模式（之前沒見過的幻覺類型），可能暗示模型行為發生了根本性變化。

九、企業決策矩陣：模型選型框架

將上述所有評估維度整合，我們可以建構一個結構化的決策矩陣，幫助企業在最終模型選型時做出理性決策。

9.1 決策矩陣模板

注：以上數字為示範用途，企業應根據自身評估結果填入實際分數。權重分配因業務場景而異——醫療場景的「幻覺率」權重可能提高至 25-30%，而內部工具的「數據合規性」權重可能降低。

9.2 決策矩陣的使用流程

步驟一：定義維度與權重。召集技術團隊、業務團隊與合規團隊，共同確定評估維度及各維度的權重。權重分配應反映業務優先級——這是一個商業決策而非技術決策。

步驟二：設定門檻。為每個維度設定最低門檻（Minimum Threshold）。例如：「幻覺率得分低於 6 分的模型直接淘汰，不論總分多高」。門檻是二元的、不可妥協的——這保護企業免受「總分很高但在關鍵維度上有致命缺陷」的模型的風險。

步驟三：執行評估並填入分數。使用前述的三層評估流程（學術基準 → 任務導向 → 業務導向），為每個候選模型的每個維度生成分數。分數應基於量化數據而非主觀印象。

步驟四：計算加權總分並排名。淘汰未通過門檻的模型，對剩餘模型計算加權總分。前 2-3 名進入最終的 A/B 測試階段。

步驟五：敏感度分析。改變權重分配（例如將成本權重提高 10%，品質權重降低 10%），觀察排名是否穩定。如果排名在合理的權重變動範圍內保持穩定，則結論是穩健的；如果小幅權重變動就導致排名翻轉，說明候選模型之間的差異不顯著，可能需要其他決策因素（如供應商關係、長期戰略契合度）來打破平手。

9.3 常見的決策陷阱

基於數十次企業模型選型的顧問經驗，以下是最常見的決策陷阱：

陷阱一：過度依賴單一 Demo。「我們在內部 demo 中問了 10 個問題，模型 A 回答得最好」——這不是評估，這是抽樣偏差。10 個問題的結果不具有任何統計顯著性。即使只是初步篩選，也至少需要 50-100 個結構化測試樣本。

陷阱二：忽略成本的長期曲線。當前的 API 定價不是一成不變的。歷史數據顯示，模型價格平均每年下降 30-50%，但新一代頂尖模型的價格往往在上市初期較高。企業應評估 6-12 個月的成本預測，而非只看當前價格。

陷阱三：把模型鎖定當作策略。「我們已經用了 X 廠商的 API，整合成本太高，不想換」——這正是供應商鎖定（Vendor Lock-in）的典型表現。最佳實踐是在應用架構中抽象 LLM 呼叫層，使模型切換成本最小化。評估應定期進行（建議每季度），而非只在初始選型時做一次。

陷阱四：迷信「最強」模型。並非所有場景都需要最強的模型。客服場景中，一個中等能力但低延遲、低成本的模型可能帶來更好的用戶體驗和 ROI。過度使用頂尖模型是一種資源浪費，就像用法拉利來送外賣。

9.4 多模型組合策略

成熟的企業 LLM 部署往往不是選擇一個模型，而是建構一個模型組合（Model Portfolio）。典型的組合策略包括：

路由策略（Router Pattern）：根據輸入的複雜度將請求路由到不同能力層級的模型。簡單問題（如FAQ查詢）使用低成本小模型，複雜問題（如多步推理）使用頂尖模型。路由器本身可以是一個輕量級的分類模型或基於規則的系統^[7]。

級聯策略（Cascade Pattern）：先由小模型嘗試回答，如果自評信心度低於閾值，升級到更強的模型。這在保持品質的同時平均降低 40-60% 的成本。

專家組合策略（Specialist Pattern）：不同領域使用不同的專用模型——程式碼生成用 Code-Llama，繁體中文生成用本地微調模型，英文分析用通用頂尖模型。這需要更複雜的架構管理，但能在每個領域都達到最佳表現。

十、結語：評估即競爭力

回到文章開頭的問題：「該選哪個模型？」如果你讀到這裡，應該已經理解這個問題本身就是不完整的。正確的問題是：「在我們的業務場景中，哪個模型（或模型組合）能以可接受的成本和風險，達到我們的品質標準？」

這個問題的答案不在任何排行榜上，也不在任何廠商的技術報告中——它只能通過系統性的、多層次的、持續性的評估來獲得。

企業 LLM 評估框架的建立不是一個技術項目，而是一項組織能力的建設^[3]。它需要跨部門的協作、持續的資源投入、以及將「品質是可量化的、可追蹤的、可改善的」作為團隊文化的一部分。

我們在超智諮詢的實踐中反覆驗證一個觀察：擁有最強評估能力的企業，往往也是 LLM 部署最成功的企業。這不是巧合。評估能力讓企業能夠快速試錯、精準迭代、果斷決策——這些正是在 AI 快速演進時代中勝出的關鍵素質。

建構你的三層評估金字塔。從學術基準開始，延伸到任務導向，最終錨定在業務指標上。建立持續評估的流水線，讓品質監控成為日常作業而非一次性事件。訓練你的團隊閱讀數據、質疑假設、用證據做決策。

這就是從「跑個 benchmark」到真正的企業級 LLM 評估的旅程。路途不短，但每一步都值得。