LLM 輸出評估指南

📏 為什麼需要評估 LLM？

💡 一句話理解 你不會不跑測試就把程式碼部署上線。AI 也一樣——不評估品質就不該上線。

工程師常見的困境

老闆：「AI 客服的回答好嗎？」
工程師：「呃⋯⋯感覺還行？」  ← 這不是工程語言

正確回答：
「Faithfulness 97.2%, Relevancy 89.5%,
 比上個月提升了 3.1 個百分點。」  ← 這才是工程語言

---

🏆 公開 Benchmark 速查

當你在選模型或向老闆報告時，這些 Benchmark 是通用語言：

Benchmark	衡量什麼	如何理解分數
MMLU	世界知識（57 學科）	90+ = 頂級，70+ = 堪用
HumanEval	Python 程式碼能力	90+ = 頂級
MT-Bench	多輪對話品質	9.0+ = 頂級（滿分 10）
GPQA	博士級科學推理	60+ = 頂級（很難的題目）
MATH	數學推理	80+ = 頂級
Chatbot Arena	人類盲測投票排名	ELO 分數，越高越好

2026 主流模型分數參考

模型	MMLU	HumanEval	MT-Bench
GPT-5.4	92.1	96.3	9.5
Claude Sonnet 4.6	91.8	95.8	9.4
Gemini 3.1 Pro	91.5	94.2	9.3
DeepSeek V4	90.3	93.7	9.2
Llama 3.1 405B	88.6	89.5	8.9

⚠️ Benchmark 分數不代表你的場景。MMLU 考的是通用知識，你的客服機器人需要的是「能根據知識庫準確回答」——這要用你自己的評估方式。更多模型比較請參考模型比較指南。

---

🔧 自建評估系統

評估的四大維度

維度	問的是什麼	分數解讀
Faithfulness（忠實度）	AI 有沒有亂掰？回答有根據嗎？（參考 AI 幻覺）	> 95% 才能上線
Relevancy（相關性）	AI 有回答到問題嗎？	> 85% 很不錯
Completeness（完整性）	回答夠完整嗎？有沒有漏掉重要資訊？	> 80% 可接受
Harmlessness（無害性）	回答有沒有不當內容？	必須 100%

LLM-as-Judge（用 AI 評估 AI）

最高效的方式——用一個強大的 LLM 當「考官」，評估另一個 LLM 的回答。

def llm_judge(question, ai_answer, reference=None, model="gpt-4o"):
    """用 GPT-4o 當考官評估 AI 回答"""

    judge_prompt = f"""你是一個嚴格的 AI 回答品質評審。
請評估以下 AI 回答的品質。

## 問題
{question}

## AI 的回答
{ai_answer}

{"## 參考答案" + chr(10) + reference if reference else ""}

## 評分標準（每項 1-5 分）
1. **準確性**：回答是否正確、有根據？
2. **相關性**：是否正確回答了問題？
3. **完整性**：是否涵蓋了關鍵資訊？
4. **簡潔性**：是否避免了冗餘和廢話？

請用 JSON 格式回答：
{{"accuracy": 1-5, "relevancy": 1-5, "completeness": 1-5,
  "conciseness": 1-5, "overall": 1-5, "reason": "簡短說明"}}"""

    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": judge_prompt}],
        response_format={"type": "json_object"}
    )

    return json.loads(response.choices[0].message.content)

# 使用範例
result = llm_judge(
    question="台灣的首都在哪裡？",
    ai_answer="台灣的首都是台北，位於台灣北部。",
    reference="台北市是中華民國的首都。"
)
print(result)
# {"accuracy": 5, "relevancy": 5, "completeness": 4,
#  "conciseness": 5, "overall": 5, "reason": "回答準確完整"}

批次評估框架

import pandas as pd

def evaluate_batch(test_cases, ai_function):
    """批次評估一組測試案例"""
    results = []

    for case in test_cases:
        # 取得 AI 回答
        ai_answer = ai_function(case["question"])

        # 用 Judge 評估
        scores = llm_judge(
            question=case["question"],
            ai_answer=ai_answer,
            reference=case.get("expected_answer")
        )

        results.append({
            "question": case["question"],
            "ai_answer": ai_answer,
            **scores
        })

    df = pd.DataFrame(results)

    # 印出統計
    print("=== 評估結果 ===")
    for col in ["accuracy", "relevancy", "completeness", "overall"]:
        print(f"{col}: {df[col].mean():.2f} / 5.00")

    return df

# 測試案例
test_cases = [
    {"question": "怎麼退貨？", "expected_answer": "7 天內無條件退貨..."},
    {"question": "運費多少？", "expected_answer": "滿 500 免運..."},
    {"question": "營業時間？", "expected_answer": "週一到週五 9-18..."},
]

results = evaluate_batch(test_cases, your_ai_chatbot)

---

📊 RAG 專用評估

如果你的 AI 系統使用 RAG，需要額外評估檢索品質。

用 Ragas 框架

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)

# 準備評估資料
eval_data = {
    "question": ["怎麼退貨？", "運費多少？"],
    "answer": ["7 天內可退貨...", "滿 500 免運..."],
    "contexts": [
        ["退貨政策：7 天內無條件退貨..."],
        ["運費規定：滿 500 元免運費..."],
    ],
    "ground_truth": ["7 天內無條件退貨", "滿 500 元免運"]
}

result = evaluate(
    eval_data,
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall]
)

print(result)
# faithfulness: 0.97
# answer_relevancy: 0.89
# context_precision: 0.92
# context_recall: 0.85

RAG 評估指標說明

指標	衡量什麼	目標
Context Precision	檢索到的段落有多少是真正相關的	> 80%
Context Recall	所有相關段落中，有多少被檢索到	> 85%
Faithfulness	AI 回答是否忠實於檢索到的內容	> 95%
Answer Relevancy	最終回答和問題的相關程度	> 85%

---

🔄 持續監控

模型上線後不是結束——品質可能隨時間退化。

建立監控流程

import logging

logger = logging.getLogger("ai_monitor")

class AIMonitor:
    """AI 回答品質持續監控"""

    def __init__(self, sample_rate=0.1):
        self.sample_rate = sample_rate  # 抽樣率 10%

    def log_interaction(self, question, answer, metadata=None):
        """記錄每次 AI 互動"""
        import random
        # 隨機抽樣評估（不是每次都評，太貴）
        if random.random() < self.sample_rate:
            scores = llm_judge(question, answer)
            logger.info(f"AI 品質抽檢: overall={scores['overall']}/5")

            # 低品質警報
            if scores["overall"] <= 2:
                logger.warning(
                    f"⚠️ 低品質回答偵測！\n"
                    f"問題: {question}\n"
                    f"回答: {answer[:100]}...\n"
                    f"分數: {scores}"
                )

監控儀表板指標

指標	監控目的	警報閾值
平均品質分數	AI 整體表現	< 3.5/5
Faithfulness	有沒有更多幻覺	< 90%
拒答率	AI 回答「我不知道」的比例	> 30%
延遲 P95	回應速度	> 5 秒
Token 成本	成本趨勢	日均超過預算 120%

---

❓ FAQ

🧠 為什麼評估 LLM 這麼難？

傳統軟體測試有明確的「對/錯」：add(1, 2) 回傳 3 就是對，回傳 4 就是錯。但 LLM 沒有這種奢侈。

三個根本性困難

1. 非確定性（Non-deterministic）：同一個問題問兩次，回答可能不一樣。即使 temperature=0，不同 API 版本、不同硬體、浮點誤差都會讓輸出飄移。

2. 沒有單一正解（No single ground truth）：「怎麼申請退貨？」可以有十種寫法都是對的。你不能用字串比對，要比對的是語意。

3. 品質是多維度的：一個回答可能「事實正確」但「太囉嗦」，或「很精簡」但「漏了關鍵資訊」。單一分數抓不住全貌。

這三個困難造成什麼問題？

• 工程師常說「這個 Prompt 改完感覺變好了」——感覺不是數據，可能只是你剛好抽到好 case。
• 換一個模型（GPT-5 → Claude 4.7）時，沒有系統化評估就只能靠人工盲測幾題，極容易 ship bug 上線。
• 老闆問「這次改動讓品質提升多少？」——你答不出來就沒預算。

---

🎭 三種評估典範（Paradigms）

選錯典範是最常見的浪費時間原因。先搞清楚你在哪一種情境。

典範	做法	適合場景	缺點
Reference-based（有標準答案）	用 BLEU、ROUGE、精確匹配比對 AI 輸出和「正確答案」	翻譯、摘要、結構化抽取	開放式對話不適用，同義句會被誤判為錯
Reference-free（LLM-as-Judge）	用強模型當考官，依 rubric 打分	客服、助理、RAG 回答	有 judge bias、成本較高
Human eval（人工）	人類直接評分或 A/B 盲測	黃金基線、關鍵決策	慢、貴、難規模化

什麼時候用哪一種？

• 抽取結構化資料（發票金額、日期）→ 用 reference-based，精確匹配就夠。
• 客服、Agent 對話、RAG → LLM-as-Judge 是主力，人工抽樣補強。
• 模型上線的最終 Go/No-Go 決策 → 一定要有人工盲測，不能全靠 Judge。

實務上，成熟團隊會混用：8 成自動化（LLM-as-Judge）+ 2 成人工抽樣 + 版本更新時做一次完整人工 A/B。

---

🛠️ 評估工具比較（2026）

市面上的評估平台這一年快速成熟，以下是我實際用過的四款對比：

工具	類型	適合誰	特色	價格
Promptfoo	開源 CLI	工程師、CI/CD	YAML 寫測試、跑 red team、測 jailbreak	免費
Langfuse	開源 + 雲端	已用 LangChain 的團隊	Tracing + Eval 一條龍、self-host 友善	免費起
Braintrust	商業 SaaS	產品團隊、PM	UI 最佳、playground 強、對比視覺化好	有免費額度
OpenAI Evals	開源框架	跑官方 benchmark	和 OpenAI 生態整合緊、template 多	免費

選型建議：

• 小團隊剛起步 → Promptfoo。一個 YAML 檔跑 100 個 case，塞進 GitHub Actions 當護欄。
• 已經有 LangChain tracing → Langfuse。省掉再接一次的工。
• 產品 PM 要看報表 → Braintrust。UI 可以直接給非工程師用。

---

💼 實戰案例：評估客服機器人

把上面的理論落地到一個具體場景。假設你要評估一個電商客服 bot。

Step 1：定義 metrics（3-5 個就夠）

不要一開始就列 15 個指標，會做不完。先抓最痛的 3 個：

1. Faithfulness（不亂掰）：回答必須基於知識庫，不能幻覺。目標 > 95%。
2. Resolution Rate（有解決問題）：使用者不需要再問第二次。目標 > 80%。
3. Tone（語氣）：禮貌、專業、不油膩。目標 > 90%。

Step 2：建立黃金資料集（golden dataset）

50 個 case 是起點，別少於這個數。組成建議：

• 20 個「日常常見問題」：退貨、運費、訂單查詢⋯⋯（從真實客服紀錄撈）
• 15 個「邊界案例」：退貨但超過 7 天、訂單沒出貨想取消、跨國訂單⋯⋯
• 10 個「對抗性測試」：問競品、問公司內部資訊、嘗試 jailbreak
• 5 個「必須拒答」：法律諮詢、醫療建議、個資外洩請求

每個 case 格式：

- question: "我買了三天但還沒出貨，想取消怎麼辦？"
  expected_behavior: "確認訂單狀態未出貨 → 說明取消流程 → 提供客服聯絡"
  must_not_contain: ["直接退款", "無法取消"]
  category: "訂單取消"

Step 3：跑評估、記錄、迭代

# 用 promptfoo 跑
promptfoo eval -c config.yaml
promptfoo view  # 打開 UI 看結果

重點是追蹤版本趨勢——v1 Faithfulness 91%，v2 改 Prompt 後 95%，v3 換模型後 97%。每次變動都對比基線，不要只看當下分數。

---

⚠️ 常見踩坑

這些坑我全踩過，分享給你省時間：

1. Judge 模型偏見（Judge Bias）

用 GPT-4 當 judge 評估 GPT-4 的回答時，GPT-4 會偏袒自己家的回答。研究顯示同模型評同模型會高估 5-10%。

解法：用「不同家」的模型當 judge。評估 GPT-5 用 Claude 當考官，評估 Claude 用 GPT 當考官。

2. Position Bias（位置偏見）

做 pairwise 比較（「A 和 B 哪個好？」）時，LLM 傾向選前面那個。

解法：每個 pair 跑兩次，A/B 和 B/A 各一次，取平均。

3. Dataset Leakage（資料集洩漏）

公開 benchmark（MMLU、HumanEval）早已被各家模型廠商「訓練過了」，分數是虛胖的。

解法：永遠準備一份私有評估集，不公開、不上傳到 OpenAI/Anthropic。這才是你真正的護城河。

4. 過度依賴單一指標

只看 Faithfulness 會得到「什麼都不回答」的 bot（拒答率飆高但 Faithfulness 100%）。

解法：至少三個指標交叉看，設「任一指標不達標就 fail」的硬規則。

---

✅ 上線前最低限度檢查清單

如果你的 AI 功能要上線 C 端使用者，這些都做完再上：

• 有 50+ 個黃金測試案例，涵蓋日常/邊界/對抗
• 至少跑過一次完整 LLM-as-Judge 評估，主要指標達標
• 做過一次人工抽樣（20 題以上），驗證 Judge 和人類一致性 > 80%
• 有「拒答率」監控——AI 亂講話比 AI 說不知道更危險
• Prompt injection 測試至少 10 個案例（參考 Prompt Engineering）
• 設好成本警報（單次對話超過 X token 觸發）
• 有回滾機制——品質跌破閾值能 30 分鐘內切回前一版
• 有抽樣記錄（10%）寫入持續監控 pipeline
• 關鍵 metric 寫進 Grafana/儀表板，PM 和老闆看得到

沒做完前三項就上線，約 70% 機率會在上線後一週內被客訴打臉——這是我看過多個團隊的實況。

---

🔗 延伸閱讀

• Prompt Engineering 指南——改 Prompt 前先會評估，才知道改得有沒有用
• LangChain 實戰——LangChain + Langfuse 是常見的評估組合
• AI Agent 教學——Agent 的評估更難，要看 trajectory 不只是最終答案
• RAG 完整指南——RAG 評估有專屬的 Ragas 框架，請讀這篇

---

❓ FAQ

用 AI 評估 AI 靠譜嗎？

研究顯示，GPT-4 級別的 LLM-as-Judge 和人類評審的一致性超過 80%，在大量評估場景中性價比最好。建議：重要決策仍做人工抽查，日常監控用 LLM Judge 自動化。

需要多大的測試集？

至少 50-100 個測試案例才能得到統計意義上有意義的結果。涵蓋常見問題、邊界案例和對抗性問題。建議持續累積，上線後每月加入真實用戶的問題。

多久評估一次？

上線前做完整評估。上線後持續抽樣（10%）。每次改 Prompt 或換模型前做完整評估。每月做一次和基線的比較。

BLEU、ROUGE 這類傳統指標在 LLM 時代還有用嗎？

有限度地有用。BLEU/ROUGE 是字面比對，同義句會被誤判為錯，開放式對話幾乎沒意義。但在翻譯、摘要、結構化抽取這類有明確參考答案的場景仍有價值，且計算成本極低（不用再呼叫 API）。務實做法：把傳統指標當「便宜的前哨」，跑失敗的 case 再送進 LLM-as-Judge 做第二層判斷。

Promptfoo、Langfuse、Braintrust 選哪個？

一句話結論：工程師主導選 Promptfoo（YAML + CLI + 免費），已用 LangChain 選 Langfuse（tracing 一條龍），產品 PM 要看報表選 Braintrust（UI 最佳）。小團隊起步建議先 Promptfoo 跑一個月，覺得不夠再升級。不要一開始就上 SaaS，會被月費綁住。

Judge model 該用哪個模型？用便宜的可以嗎？

Judge 要比被評者強，否則小模型看不懂大模型的細微差別。實務建議：被評者用 Claude Haiku/GPT-5-mini，judge 用 Claude Sonnet 4.6 或 GPT-5。如果被評者已經是頂級模型，judge 要換「不同家」的頂級模型避免偏袒。成本方面，judge 通常只跑抽樣（10%）不會太貴，一個月 $50-200 可以搞定中型產品的持續監控。

黃金資料集要多常更新？

每月至少加 10 個新 case，來源是「上個月被客訴的對話」和「上個月出現的新問題類型」。資料集會自然腐化——產品改版、政策變更、新功能上線，舊 case 可能失效。建議用 Git 管理資料集，每次更新打版本 tag，這樣未來要對比「現在的模型在三個月前的題目上表現如何」也查得到。

評估做完了，分數都達標，還是被客訴怎麼辦？

9 成情況是黃金資料集沒涵蓋到真實分布。做法：抽出被客訴的真實對話，看哪個類型是黃金資料集漏掉的，加進去，重跑評估——大概率會發現這類型的分數偏低，再針對性優化。評估不是一勞永逸，是永遠在追著真實世界跑。