概念位置

能力光譜是評估與選型用語，用來替代 binary checklist。它把能力拆成範圍、穩定性、成本與失敗模式：模型能做什麼、在多寬的分佈上穩定、錯的時候怎麼錯、需要多少 prompt / validator / retry 才可用。

1宣稱支援 → happy path 可用
2基礎可用 → 常見變體可用
3生產可用 → edge cases、錯誤路徑、壓力情境仍可控

可觀察訊號與例子

Function calling 的能力光譜可以用幾個訊號量化：單工具成功率、多工具選擇成功率、schema 合法率、參數語意正確率、錯誤時是否追問。某模型能輸出合法 JSON，不代表它能選對工具；能選對工具，也不代表它能填對 nested argument。

能力光譜的常見陷阱是把 demo 成功當成生產穩定。Demo 通常測 happy path，生產會遇到拼字錯、缺欄位、權限不足、工具 timeout、prompt injection、schema 演化與多語言輸入；這些才決定能力落在哪個位置。

設計責任

做模型選型或應用設計時，把「有沒有」改成「到什麼程度可用」。判準要包含成功率、覆蓋範圍、錯誤成本、監控訊號與回退路徑。下一步路由是：能力來自訓練資料時讀 Training Example Coverage；能力需要推論階段兜底時讀 Sampling Constraint。

概念位置

跟其他 eval 概念對照：

工作流：

1Day 1：定義 eval set + 初始 prompt + model
2   ↓ 跑 production 一段時間（如 2 週）
3Day 14：把當下 prompt + model freeze 成 baseline-v1
4   ↓
5新版本 prompt / model 都跟 baseline-v1 比
6   ↓ 定期（如每季）refresh
7Day 90：baseline-v2、標明 refresh 時點

設計責任

讀 eval / production AI 文章看到「frozen baseline」「baseline drift」「regression set」就是這個機制。實作判讀：

1. 為什麼必要：每次 A/B 都跟「最新版本」比、長期累積漂移完全不可見、「整體變好了沒」無從回答。Frozen baseline 是漂移的錨點。
2. 何時 freeze：production 跑穩、user 滿意度可接受時 freeze。太早 freeze 鎖到不夠好的版本、太晚 freeze 鎖不到。
3. 何時 refresh：定期（每季 / 每半年）、或當 baseline 明顯 obsolete（如 model 升級、產品大改版）。Refresh 後標明時點、舊版本仍可保留當歷史對照。
4. 跟 frozen baseline 一起的還有：regression set（failed case 永遠進、防 fix 一個壞一個）、production trace 抽樣補進 eval set（讓 eval set 不脫節）。
5. 失敗模式：baseline 跟 production 分佈差太遠（baseline 用 lab case、production 是 wild input）、跑出來分數沒參考價值。緩解：baseline 的 eval set 用 production trace 抽樣建。

完整 eval 系統設計見 4.13 Eval 設計座標系。

概念位置

Instruction-tuned model 是訓練狀態，instruction following 是行為表現。模型可能經過 SFT，仍在細格式、邊界條件或多約束任務上失敗；也可能在簡單指令上表現穩定，但遇到衝突指令或長 prompt 漏掉限制。

可觀察訊號與例子

測試訊號包含：是否輸出指定 JSON、是否只回答要求的欄位、是否避免多餘解釋、是否在資料不足時說不知道、是否遵守「不要呼叫工具」或「只讀不寫」。本地小模型常在簡單問答可用，但在多條格式限制同時存在時掉分。

設計責任

評估 instruction following 時要做 coverage 測試：格式、長度、拒答、資料不足、衝突指令、跨語言指令都要看。失敗時優先用更清楚的 prompt、few-shot、structured output 或 validator 兜底；長期穩定需求才考慮 fine-tune。

概念位置

Coverage 是訓練資料分佈的問題，常在 SFT、偏好資料、tool-use data、domain fine-tune 裡出現。它跟 prompt 範例不同：few-shot 範例只存在於當次 context，training examples 會透過訓練更新模型權重，影響模型「自然」傾向怎麼回答。

1訓練資料有覆蓋 → 模型自然輸出穩定
2訓練資料缺口大 → 靠 prompt / structured output / validator 兜底

可觀察訊號與例子

Function calling 的 coverage 可從四個面向判讀：該呼叫時是否呼叫、工具選擇是否正確、參數型別是否正確、巢狀 schema 與多工具情境是否穩定。小模型常在單一工具 + 平坦 schema 表現可用，但一進到多工具、optional field、nested object、跨語言 query 就明顯掉分，這通常是 coverage 不足而不是單純 parser 問題。

Coverage 的陷阱是只看 happy path。訓練範例如果只有成功呼叫工具，模型會傾向每次都呼叫；如果缺少「資訊不足時先追問」「使用者要求超出權限時拒絕」「工具錯誤時重試或回退」這類範例，部署後會在安全與可靠性邊界失敗。

設計責任

評估模型能力時，把支援功能改問成覆蓋範圍：支援哪些 tool schema 複雜度、哪些語言、哪些錯誤路徑、哪些反例。下一步路由是用 eval set 補齊代表性情境；如果 coverage 無法補在模型訓練層，就用 structured output、validator、retry 與 fallback 降低失敗成本。

概念位置

主流 LLM benchmark 一覽：

事實查核註：各 benchmark 的飽和狀態、前沿模型 score 持續變動、上述為 2026/5 主流觀察。引用前以 Papers with Code 或 HuggingFace Open LLM Leaderboard 當前狀態為準。

Benchmark 的常見陷阱

1. 訓練資料污染（Contamination）：benchmark 題目本身在 pretrain corpus 出現過、模型「記得」答案、看似強實際是 memorization
2. 飽和（Saturation）：前沿模型 score 接近上限、無法區分模型品質差距（HumanEval 80%→95% 看似進步、實際 5% 多半是 lucky 而非實質提升）
3. LLM-as-judge bias：用 LLM（如 GPT-4）評其他 LLM、judge 的偏好（如「冗長 = 好」）會 bias 評分
4. Single-task overfitting：模型廠商針對 benchmark 特別 fine-tune、benchmark 高分但通用能力沒提升
5. Prompt sensitivity：同個 benchmark 用不同 prompt format、score 差幾個百分點

設計責任

讀 model card / paper 看到 benchmark 數字、判讀框架：

1. 看 multiple benchmarks、不只一個：如挑 coding 模型、看 HumanEval + MBPP + SWE-bench、不只看 HumanEval
2. 跟自己任務對齊的 benchmark 才重要：你做 RAG 應用、看 retrieval benchmark；你做 chat、看 MT-Bench / Arena
3. 看「相對」、不只看「絕對」：「Model A 在 MMLU 比 Model B 高 2%」可能 noise；「A 比 B 高 10%」更可信
4. In-house benchmark 是最後檢驗：自己的真實工作流案例 > 任何公開 benchmark

概念位置

跟其他 eval 路徑的對比：

主要 use case：

1. In-house benchmark：自己工作流的真實案例、自寫 rubric、judge 評
2. Production trace eval：用 LLM tracing 蒐集的 production trace、定期 judge 跑、抓品質回歸
3. A/B test：兩個 prompt / model 變體、judge 做 pairwise 比較
4. Synthetic data quality：用大模型生 fine-tune 資料、judge 過濾低品質

設計責任

讀 eval framework / production AI app 看到「LLM as judge」「pairwise eval」「LLM evaluator」就是這 framing。寫 code 場景的判讀：

1. Judge 模型選擇：強模型當 judge（GPT-5 / Claude 4 / Gemini 旗艦）、reasoning model 更穩；judge 跟被測同家可能有 self-preference bias
2. 三大 bias 緩解：
   • Position bias：A/B pairwise 換位置跑 2 次取一致 vote
   • Verbosity bias：rubric 加「冗長不加分」明確指示、或長度 normalize
   • Self-preference bias：用 3 個不同 judge model 取多數
3. 跟 4.21 LLM-as-judge 章節 的關係：本卡是定義、章節是工程實務（rubric design、bias 緩解、calibration、trace 串接）
4. 不是萬靈丹：高 stake 任務（醫療、法律、安全）仍需 human eval；judge 的天花板 = judge 模型本身的能力

概念位置

Long context 的 effective context 跟 claimed context 落差來自三個現象：

 1Recall accuracy vs 答案位置（典型 10K context）：
 2
 3100% |█                                       █
 4     |██                                     ██
 5 80% |███                                   ███
 6     |███                                   ███
 7 60% |███          ____                     ███
 8     |███      ___/    \___                 ███
 9 40% |███    _/            \_               ███
10     |█████─/                \─────         ███
11     |
12       0      2K     4K     6K     8K    10K
13       開頭                              結尾

成因：

1. Attention weight 分佈不均勻：訓練資料中、句首 / 段首通常含關鍵資訊、模型學會偏重句首；長 context 的中段在訓練資料中相對稀疏、attention 沒學好
2. Positional encoding 設計：RoPE / ALiBi 等對長距離 attention 的衰減模式、中段 token 跟 query 距離通常較大、attention 弱
3. 訓練 context 長度的影響：模型若訓練在 8K context、推論時用 128K（用 RoPE scaling 延伸）、中段表現比訓練範圍內差更多

設計責任

讀 long-context paper / benchmark 看到「lost-in-the-middle」「U-shape recall」就是這現象。寫 code 場景的判讀：

1. 把關鍵資訊放開頭或結尾：system prompt 在開頭、最新指示在結尾（剛好是模型 attention 最強的兩處）
2. 長 context 不是「塞越多越好」：超過 effective context（典型 8-16K）後、邊際效用急降
3. RAG 比 long context 仍有價值：把相關片段 retrieve 出來放 prompt 開頭、比把整份文件塞進 100K context 效果更穩定
4. 驗證自己模型的 effective context：用 needle-in-haystack 或自製測試、看模型在 8K / 16K / 32K 表現掉到哪
5. Reasoning model 的 thinking trace 不會遇到這事故嗎？ — 仍會遇到、但 reasoning 過程會主動重新引用前文、部分緩解；不過 thinking trace 本身會擠壓 context budget、可能反而觸發 degradation

概念位置

MTEB 的 8 大任務類別：

對寫 code / RAG 場景最相關：Retrieval、Reranking 兩類（粗體）。其他類別反映通用能力、但不直接影響 RAG 應用品質。

主流 embedding model 在 MTEB Retrieval 的代表性能（2026/5 估計、會持續變動）：

事實查核註：MTEB 數字依模型版本、評估配置變動、上述為 2026/5 大致排名、引用前以 MTEB Leaderboard 當前狀態為準。

設計責任

讀 embedding model 比較看到「MTEB score」就是這 benchmark。寫 code / RAG 場景的判讀：

1. 看 Retrieval 子分數、不是 overall：MTEB overall 含 8 類、跟 RAG 場景關係最大的是 Retrieval 子分；通用 retrieval 分數高、reranking 分數高、就值得試
2. 跟自己 domain 對齊：MTEB 多為通用語料、自己 domain（如 code、medical、legal）可能跟 MTEB 落差大；in-domain benchmark 比 MTEB 更重要
3. 大小 / 速度 / 品質 trade-off：bge-large（335M）vs nomic-embed（137M）、後者跑得快、適合本地 RAG；前者品質略高、適合雲端或 latency 不敏感場景
4. MTEB 高分不代表「適合你」：高分模型可能是 instruction-tuned embedding（query 需要加特定前綴）、用法跟簡單模型不同、要看 model card

概念位置

NIH 測試的典型流程：

 11. 準備 haystack：一份長文（如 Paul Graham essays、技術文件）
 22. 在指定位置（如 50% 處）插入 needle：
 3   「The best thing to do in San Francisco is eat a sandwich at Dolores Park.」
 43. Prompt 模型：「What is the best thing to do in San Francisco?」
 54. 看模型能否抓出 needle 內容
 6
 7Variables：
 8- Context 總長度（1K、4K、16K、64K、128K、1M）
 9- Needle 插入位置（0%、10%、25%、50%、75%、90%、100%）
10
11每個 (length, position) 組合測 N 次、得到 accuracy heatmap

跟 lost-in-the-middle 的對比：

 1典型 NIH heatmap（GPT-4 128K 之類）：
 2
 3100% |████ ████████████████████████████ ████
 4 80% |████ ████████████████████████████ ████
 5 60% |
 6 40% |
 7 20% |
 8   0 +----+----+----+----+----+----+----+
 9     0%   25%   50%   75%   100%（needle 位置）
10     ↑                                  ↑
11     開頭強                             結尾強
12
13NIH heatmap 通常全綠（強模型）、但實用任務（reasoning over long context）就會出現中段塌陷

設計責任

讀 long context 模型 release notes 看到「needle in a haystack: 100%」「pass NIH up to 128K」等聲稱、要區分：

1. NIH 100% 不代表「能用 128K context」：NIH 只測單一事實 retrieve、實際 reasoning over long context 仍可能崩
2. 真實任務 benchmark：LongBench、RULER 等是更貼近實用的 long context evaluation、會暴露 lost-in-the-middle 等問題
3. 本地跑 long context 模型：先用 NIH 驗證 baseline、再用 RULER / 自己工作流 case 測 effective context
4. 判讀「我的模型實際能用幾 K」：NIH pass 的長度是上限、實用 effective context 通常是 NIH pass 長度的 1/2 到 1/4

概念位置

Perplexity 跟 cross-entropy 的關係：

換算範例（base e）：

Perplexity 主要用於：

• 預訓練評估：在 held-out 語料上算 perplexity、衡量基礎建模能力。
• 量化品質衡量：fp16 vs Q4 vs Q3 模型的 perplexity 差異、看量化造成多少品質損失。
• 領域 benchmark：在特定領域語料（code、math、医學文獻）上算 perplexity、評估模型對該領域的熟悉度。

設計責任

Perplexity 是 base model 評估標準、但對 instruction-tuned / chat 模型用處有限（chat 模型輸出風格已偏離 raw text、perplexity 不一定降）。對寫 code 場景的判讀：看到 paper 報 perplexity 是評估 pretrain 品質的訊號、實際聊天 / coding 能力要看 SWE-bench、MMLU、HumanEval 等任務式 benchmark。

本篇 framing 是「真的能跑、不只跑 demo」、所以包含：硬體預算估算、judge model 選型、bias 緩解、calibration 流程、跟 production trace 串接的延伸；術語對應 LLM-as-Judge 與 LLM Tracing。

驗證日期：2026-05-12 環境：M4 Max 64GB / 或 24GB+ VRAM PC + Ollama Judge model：DeepSeek-R1-Distill-Qwen-32B 或 QwQ-32B（reasoning model 當 judge 更穩）

為什麼用本地 LLM 當 judge

跟雲端 judge（GPT-5 / Claude 4）對比：

判讀：

• 大量 production trace eval（千筆以上）+ 隱私敏感 → 本地 judge
• 少量 high-stake eval（< 50 筆） → 雲端旗艦 judge
• A/B test 快速 iterate → 雲端（latency 重要）

硬體預算

Judge model 選擇看硬體：

注意：reasoning model 的 thinking trace 拉長 latency、跑大量 batch 要規劃時間（100 item × 60s = 100 min）。

何時不適合用本地 judge：

1. 硬體低於 M4 Pro 24GB / 4090 16GB（如 M1/M2 16GB、無獨立 GPU PC）：跑 32B reasoning model 太緊、強行跑會 swap、latency 爆 5-10×。改用 14B instruct model（如 Qwen2.5-14B Q4）作 judge、或直接走雲端 judge
2. Batch × latency > 你可接受的等待時間：100 item × 60s/item = 100 min；500 item × 120s = 17 hr。預估超過 4 hr 時改雲端 batch API
3. eval 任務太 nuanced：細粒度倫理 / 法律 / 高 stake 判讀、本地 32B distill 能力不夠、用雲端旗艦 judge 或人工 review
4. calibration 階段：第一次跑、要快速 iterate rubric、雲端 judge latency 短（5-30s）更適合 iterate

整體流程

11. 蒐集 eval dataset    → JSONL：每行一個 (input, output) 待評
22. 設計 rubric         → 評分維度、scale、明確 anti-pattern
33. 寫 judge prompt     → 4 段式（task / input-output / rubric / format）
44. 跑 harness          → 對每筆 input call judge、parse JSON output
55. Aggregate 結果      → 算平均分數、找 outlier、看 reasoning
66. Calibration（可選）  → 跟 human eval 比對、調 rubric
77. 跟 production trace 串接 → 定期跑 production sample

Step 1：蒐集 eval dataset

JSONL format（每行一筆）：

1{"id": "001", "input": "用 Python 寫 fibonacci function", "output": "def fib(n):\n    if n <= 1:\n        return n\n    return fib(n-1) + fib(n-2)"}
2{"id": "002", "input": "解釋這段 code 在做什麼：[code]", "output": "這段 code 實作了 ..."}
3{"id": "003", "input": "[bug 描述]", "output": "[suggested fix]"}

來源：

• 過往 Continue.dev / Cursor 跟 LLM 的對話 log
• Production agent 的 trace（手動 export 或 LangSmith / Phoenix dump）
• 自己 hand-craft 30-100 個典型 case

放在 data/eval.jsonl。

Step 2：設計 rubric

依任務類型設計、coding 任務的範例 rubric：

 1評分維度：
 21. Correctness（程式碼能否運作、邏輯是否正確）：1-5
 32. Style（是否符合 codebase convention、習慣命名）：1-5
 43. Completeness（是否完整解決 user request）：1-5
 5
 6評分規則：
 7- 5：完美無瑕、可直接 merge
 8- 4：小修可用、整體正確
 9- 3：方向正確、需 substantial 修改
10- 2：部分對、主要邏輯有錯
11- 1：完全錯、誤導使用者
12
13明確不加分（緩解 verbosity bias）：
14- 冗長 / verbose（同樣正確的短答 = 長答）
15- 道歉 / 開場白
16- 「我希望這有幫助」這類禮貌話
17- 過多 markdown 修飾（不加分）

Step 3：Judge prompt 模板

寫成 file prompts/judge.txt：

 1你是 LLM 輸出品質評估員、要評估 coding assistant 對使用者請求的回答品質。
 2重要：請保持公正、忽略風格偏好、聚焦在實質品質。
 3
 4User request:
 5{input}
 6
 7Assistant response:
 8{output}
 9
10評分維度（每維 1-5、加總用 overall）：
11
121. Correctness：程式碼能否運作、邏輯正確
13   5: 完美無瑕
14   4: 小修可用
15   3: 方向正確、需 substantial 修改
16   2: 部分對、主要邏輯有錯
17   1: 完全錯
18
192. Style：符合 codebase convention
20   1-5 同 scale
21
223. Completeness：完整解決 user request
23   1-5 同 scale
24
25明確不加分項：
26- 冗長 / verbose（同樣正確的短答 = 長答）
27- 道歉 / 開場白
28- 「我希望這有幫助」這類禮貌話
29- 過多 markdown 修飾
30
31請依下列 JSON 輸出（不要加額外文字、不要 markdown code fence）：
32{
33  "correctness": <1-5>,
34  "style": <1-5>,
35  "completeness": <1-5>,
36  "reasoning": "<簡短解釋、< 100 字>",
37  "overall": <1-5>
38}

Step 4：跑 harness

Python 最小可行版：

 1# judge_harness.py
 2import json
 3import requests
 4from pathlib import Path
 5
 6JUDGE_MODEL = "deepseek-r1:32b"  # 或 qwq:32b
 7OLLAMA_URL = "http://localhost:11434/v1/chat/completions"
 8
 9def load_dataset(path):
10    """Load JSONL eval dataset."""
11    with open(path) as f:
12        return [json.loads(line) for line in f if line.strip()]
13
14def load_prompt_template(path):
15    return Path(path).read_text()
16
17def call_judge(prompt):
18    """Call Ollama judge model、回 raw response text."""
19    resp = requests.post(OLLAMA_URL, json={
20        "model": JUDGE_MODEL,
21        "messages": [{"role": "user", "content": prompt}],
22        "temperature": 0.1,  # judge 用低 temperature 穩定
23        "stream": False,
24    }, timeout=600)
25    return resp.json()["choices"][0]["message"]["content"]
26
27def parse_judge_output(text):
28    """Parse judge 回的 JSON、容錯處理（reasoning model 可能加 <think> 標記）。"""
29    # 跳過 reasoning trace
30    if "</think>" in text:
31        text = text.split("</think>")[-1]
32
33    # 找 JSON 區塊
34    start = text.find("{")
35    end = text.rfind("}") + 1
36    if start == -1 or end == 0:
37        return None
38    try:
39        return json.loads(text[start:end])
40    except json.JSONDecodeError:
41        return None
42
43def run_harness(dataset_path, prompt_template_path, output_path):
44    dataset = load_dataset(dataset_path)
45    template = load_prompt_template(prompt_template_path)
46
47    results = []
48    for i, item in enumerate(dataset):
49        prompt = template.format(input=item["input"], output=item["output"])
50        raw = call_judge(prompt)
51        parsed = parse_judge_output(raw)
52
53        result = {
54            "id": item["id"],
55            "scores": parsed,
56            "raw_judge_output": raw[:500],  # 保留前 500 字便於 debug
57        }
58        results.append(result)
59        print(f"[{i+1}/{len(dataset)}] id={item['id']} overall={parsed.get('overall') if parsed else 'FAIL'}")
60
61    # 寫出 JSONL
62    with open(output_path, "w") as f:
63        for r in results:
64            f.write(json.dumps(r) + "\n")
65
66    # Aggregate
67    valid = [r for r in results if r["scores"]]
68    if valid:
69        avg = sum(r["scores"]["overall"] for r in valid) / len(valid)
70        print(f"\nAggregate: {len(valid)}/{len(results)} valid、avg overall = {avg:.2f}")
71
72if __name__ == "__main__":
73    run_harness("data/eval.jsonl", "prompts/judge.txt", "results/eval.jsonl")

跑：

1# 先確認 judge model 已 pull
2ollama pull deepseek-r1:32b
3
4# 跑 harness
5python judge_harness.py

Step 5：Aggregate 跟看 outlier

跑完後 results/eval.jsonl 含每筆評分跟 reasoning。看哪些是 outlier：

1# 找 overall < 3 的 case（低分、值得 review）
2jq 'select(.scores.overall < 3)' results/eval.jsonl
3
4# 看 reasoning 找系統性問題
5jq '.scores.reasoning' results/eval.jsonl | sort -u

判讀：

• 多數 score 4-5、少數 1-2：整體品質好、focus 在低分 case 找 fix
• 多數 score 2-3：系統性問題、改 prompt / model / agent design
• 分數分佈兩極（很多 5 很多 1）：可能是 task difficulty 分群、stratified analysis

Step 6：Calibration（可選但推薦）

跟 human eval 比對、確認 judge 對齊：

11. 從 dataset 抽 30 個（覆蓋 difficulty / score 分佈）
22. 自己 human eval（依同樣 rubric）
33. 對比 judge 跟 human 的 overall score
44. 算 Spearman correlation
5   - > 0.7：judge 對齊夠好、可信
6   - 0.5-0.7：部分問題、改 rubric
7   - < 0.5：judge 不可信、換 model 或重寫 rubric

低 correlation 的常見原因：

• Rubric 太 vague、judge 自由發揮
• Judge model 能力不夠（換更強 judge）
• Verbosity / position bias 沒緩解
• Eval task 跟 judge 訓練分佈差距大

Step 7：跟 production trace 串接（延伸）

把 4.20 LLM tracing 蒐集的 production trace export 成 JSONL、定期跑 judge：

1# 假設用 Langfuse self-host
2langfuse export --filter "user_feedback=negative" --output traces.jsonl
3
4# 轉成 eval format
5python convert_trace_to_eval.py traces.jsonl > data/eval-from-prod.jsonl
6
7# 跑 judge
8python judge_harness.py

這是 production quality engineering 閉環的本地版本、隱私敏感場景的 cost-free alternative。

失敗模式

1. Judge 不輸出合法 JSON：reasoning model 可能在 <think>...</think> 後仍加 markdown / 解釋

緩解：parse 時跳 <think> 段、容錯處理、或開 constrained decoding（llama.cpp grammar）

2. Latency 太長、batch 跑不完：reasoning model 32B 每 item 60-120s、100 item 要 2 小時

緩解：用較小 judge model（如 Qwen2.5-32B instruct、非 reasoning）、或拆 batch 並行

3. Judge bias 沒緩解：本地 judge 跟雲端 judge 都會有 verbosity / position bias

緩解：rubric 寫明、pairwise 換位置跑 2 次

4. 本地 judge 能力上限：30B distill 對 nuanced case 判讀不如雲端旗艦

緩解：critical case 加 spot human review、或混用本地（量大）+ 雲端（精選 sample）

跟其他章節的關係

• 原理層的 LLM-as-judge 設計見 4.21
• Production trace 串接見 4.20 tracing
• Reasoning model 選型見 3.8
• 隱私 / 跨雲端邊界判讀見 6.4
• Benchmark 跟 in-house eval 的層次見 4.14

本章目標

讀完本章後、你應該能：

1. 解釋 embedding model 跟 base LLM 的訓練差異。
2. 看到 MTEB / BEIR 分數時、知道對自己場景的意義。
3. 對自己 domain 選對 embedding model（通用 vs code vs multilingual）。
4. 判斷「需要 fine-tune 自己的 embedding model」的時機跟方法。

Embedding model vs LLM 的訓練差異

兩者底層架構可能類似（都用 Transformer）、但訓練 objective 完全不同：

關鍵理解：不能拿任意 LLM 的最後 hidden state 當 embedding — LLM hidden state 是為「預測下一個 token」優化、不為「相似度比較」優化。要再經過 contrastive learning fine-tune 才能當 embedding model 用。

Embedding model 的典型訓練 pipeline：

 1Stage 1: 從 base model 開始（如 BERT、RoBERTa、Mistral、Llama）
 2   ↓
 3Stage 2: Contrastive pre-training
 4   用大量 weak supervised pair（如 Reddit title-body、StackExchange QA）
 5   InfoNCE loss、batch size 大、hard negative mining
 6   ↓
 7Stage 3: Supervised fine-tune
 8   用標註好的 (query, relevant_doc) pair
 9   來源如 MSMARCO、Natural Questions
10   ↓
11Stage 4（可選）: Task-specific instruction tuning
12   讓模型懂「task description」、可針對不同 retrieval 任務切換
13   代表：bge-large、e5-mistral-7b-instruct

Stage 4 的「instruction-tuned embedding」是 2024 後流行的設計：query 前加「Represent this sentence for retrieving relevant passages:」這類前綴、embedding model 學會依任務調整向量。

選型維度

主流 embedding model 的選型維度：

1. Domain 相符

2. 大小（模型大小 / 向量維度）

3. Context window 上限

不同 embedding model 對單次 embed 的 token 上限不同：

事實查核註：本節所列具體型號（bge-large-en-v1.5、jina-embeddings-v3、nomic-embed-text-v1.5、voyage-3 等）、向量維度、context limit、訓練資料 domain、MTEB / BEIR 排名 — 都是 2026/5 主流版本的估計、各模型升級節奏快、引用前以 MTEB Leaderboard 跟對應 model card 當前狀態為準。

選擇影響 chunking 策略（見 4.1 RAG 的 chunking 段）：短 context embedding 要切細、長 context embedding 可保留更完整段落、但內部 attention 對長段中段仍可能 lost-in-the-middle。

4. Cosine similarity 設計

部分 embedding model 訓練時就 L2-normalized、用 cosine = dot product；部分沒 normalize、要自己處理：

詳細見 vector-norm 跟 dot-product 卡片。

評估：MTEB 跟自己 domain 的對齊

MTEB 是現在挑選 embedding model 最常用的 leaderboard、但要正確讀：

1. 看 Retrieval 子分數、不是 Overall：MTEB 含 8 大類、跟 RAG 最直接相關的是 Retrieval 跟 Reranking
2. 跟自己 domain 對齊：MTEB 通用 corpus、自己 domain 可能跟 MTEB 落差大
3. In-domain benchmark 才是 final test：用自己工作流的真實 query 跟 expected doc、自建小型評估集（如 100-200 對）、看候選 embedding model 的 hit rate / nDCG

In-domain 評估的最小可行流程：

1# 偽代碼
21. 蒐集 50-100 個 query + expected_doc（已知答案的對）
32. 對 candidate embedding models 各跑：
4   - embed 所有 doc（含 expected 跟 distractor、~1000 個 distractor）
5   - embed 每個 query
6   - 算 query-doc similarity、看 expected 是否在 top-5 / top-10
73. 比較 candidate 的 hit_rate@5 / hit_rate@10

跑完這個再決定用哪個 embedding model、比看 MTEB leaderboard 可靠很多。

實務選型的 constraint 優先序

上面四個維度（domain / 大小 / context / cosine 設計）跟 MTEB 評估是「品質軸」— 哪個 embedding model 最能解你的 retrieval 問題。但實際選型時，品質軸之前通常有一組工程 constraint 先砍掉大量選項，剩下的候選才進品質比較。

常見的工程 constraint 依砍選項力度排序：

1. Runtime 可用性：推論伺服器支援哪些模型？Ollama 目前原生支援 nomic-embed-text、mxbai-embed-large、snowflake-arctic-embed 等，但不支援所有 Hugging Face 模型。用 cloud API（OpenAI / Cohere / Voyage）則受 vendor 綁定跟成本約束。這一條通常砍掉最多選項。
2. 體積 / 記憶體預算：個人機器常駐 embedding model 跟 chat model 共用記憶體。137M 的 nomic-embed-text 跟 7B 的 e5-mistral 在記憶體佔用上差一個數量級。
3. 已有驗證基線：團隊或前期 demo 已用某個模型跑過、retrieval 品質已確認可用。換模型要重建 index + 重新驗證，成本不只是 MTEB 分數比較。
4. 向量維度的 storage 成本：維度影響 index 大小（n × d × 4 bytes）跟 brute-force search 延遲。768 維 vs 1024 維在小規模無感，但 100K+ chunks 時差異開始有意義。詳見 4.22 RAG storage 工程。

實務流程是：先用 constraint 1-3 收窄到 2-3 個候選，再跑 in-domain benchmark（上段的 hit rate 流程）做最終決定。直接從 MTEB leaderboard 挑最高分的模型、到實際場景才發現 runtime 不支援或體積太大，是常見的繞路。

何時該 fine-tune 自己的 embedding model

通常不該 fine-tune embedding model — 用現成的 bge-large、jina-v3 已經很好。但下列情境值得評估：

1. Domain 跟通用 corpus 差距大：

   • 醫療 / 法律 / 金融的專業術語、通用 embedding model 對「同義詞」「同概念不同表述」recall 差
   • In-domain term frequency 跟通用 corpus 差距大（如「IRA」在金融 vs 政治語境）

2. In-domain benchmark hit rate 顯著低於通用 benchmark：

   • 用 MTEB 高分模型、in-domain hit rate@5 仍 < 60%
   • 換多個候選 embedding model、所有都類似低分

3. 有足夠 in-domain (query, doc) 對：

   • Fine-tune 需要至少數千對、最好 1-10 萬對
   • 對少於 1000 對的場景、fine-tune 收益通常低於數據增強 / 提升 retrieval pipeline

Fine-tune 流程（詳細）：

Step 1：蒐集 in-domain training data

三種主流形態：

實務多從 positive pair 開始（InfoNCE loss 在 batch 內自動取其他樣本當 negative）、品質提升再進 triplet（hard negative mining）。

Step 2：選 base model

選擇看資料量跟硬體：

選擇原則：base model 在 generic benchmark 越強、fine-tune 後上限越高、但訓練成本越高。

Step 3：Loss 選擇

實務 default：MultipleNegativesRankingLoss + batch size 64-128（越大 negatives 越多、品質越高）。

Step 4：Hard negative mining

純隨機 negative（batch 內其他樣本）容易、但 hard negative（看似相關但實際無關）才能 push 模型品質：

11. 用初版 fine-tuned model 對每個 query 跑 retrieve top-50
22. 對每個 query 的 top-50：
3   - 真正 relevant doc（known positive）→ skip
4   - 其他 → 候選 hard negative
53. 篩 hard negatives（LLM-as-judge 或人工確認真的「看似相關但不對」）
64. 用 (query, positive, hard_negative) 重訓
75. Iterate 2-3 輪

Hard negative 是 embedding fine-tune 品質的關鍵差距 — 沒做的 fine-tune 通常 plateau 早、做了的可超越通用 model。

Step 5：LoRA fine-tune 而非 full fine-tune

跟 LLM fine-tune 一樣、embedding model fine-tune 也用 LoRA：

主流 framework：sentence-transformers + PEFT、Hugging Face Transformers + LoRA library。

Step 6：Evaluate

不只看 training loss、要實測：

11. Build in-domain test set（held-out、跟 training 完全分開）
22. 算 [hit_rate@K](/llm/knowledge-cards/retrieval-recall/)（query 的 expected doc 是否在 top-K retrieval result）
33. 跟「base model 未 fine-tune」對比：
4   - Fine-tune 後 hit_rate@5 提升 ≥ 10 percentage point → 成功
5   - 提升 < 5pp → fine-tune 沒效益、不如優化 retrieval pipeline
64. 確認沒崩通用能力：在 MTEB 跑、看主流 retrieval 任務沒大降

失敗模式

跟 LLM 的整合：retrieval pipeline

完整 RAG pipeline 裡 embedding model 的位置：

 1[Ingestion 階段（離線）]
 2  Documents
 3    ↓ chunking
 4  Chunks
 5    ↓ embedding model
 6  Chunk vectors → 存進 vector DB
 7
 8[Query 階段（線上）]
 9  User query
10    ↓ embedding model
11  Query vector
12    ↓ vector DB ANN search
13  Top-K chunks
14    ↓ (optional) reranking
15  Top-N chunks
16    ↓ augment LLM prompt
17  LLM response

關鍵設計決策：

1. Embedding model 一致性：ingestion 跟 query 必須用同個 model（換 model = 整批 re-embed）；chunk vectors 存進 vector DB 之後的 index 結構、維度成本與生命週期見 4.22 RAG storage 工程
2. Chunking 策略對齊 embedding context：見 4.1 RAG chunking
3. Reranking model 通常用 cross-encoder：embedding model 是 bi-encoder（query 跟 doc 分開 embed）、reranker 是 cross-encoder（query + doc 一起算）、品質更高但慢、適合在 top-50 → top-5 之間做 reranking
4. Hybrid retrieval：BM25（字面）+ embedding（語意）混用、用 RRF（Reciprocal Rank Fusion）合併、是 production 常見配置

本地 vs 雲端 embedding

寫 code 場景的判讀：

• codebase 內部 RAG（NDA / 機密 code）：本地 embedding 必選
• 個人開源專案 RAG：本地 embedding 是合理 default、簡單、free
• 公司內部 RAG（需高品質、量大）：評估 voyage-3 / OpenAI v3 vs 本地 bge-large
• 產品級 production RAG：通常雲端 API + 自己 fine-tune 的 embedding（最佳品質）

何時過時 / 何時不過時

不會過時的部分：

• Contrastive learning 是 embedding model 的核心訓練 paradigm
• MTEB 作為通用 embedding 評估的角色
• 「跟自己 domain 對齊」的 in-domain benchmark 必要性
• Bi-encoder vs cross-encoder 的分工（retrieval vs reranking）
• Hybrid retrieval（BM25 + embedding）的設計

會變的部分：

• 具體 embedding model（bge → bge-v2 → …、jina-v3 → v4 → …）
• MTEB leaderboard 排名（每月變）
• Instruction-tuned embedding 的 prompt format（標準化中）
• Embedding model 的 context window 上限（推升中）
• Long-context embedding 的研究（如 ColBERT-style late interaction）

下一章

沒 backend 的靜態場景（個人 blog / docs site）做 embedding 搜尋的 deployment 選擇見 4.16 靜態 / serverless RAG deployment。

下一章：4.13 Eval 設計座標系、看 eval 三軸八象限 meta 框架（先選軸再選工具）、再進 4.14 Benchmarking 與評估方法論 看具體 benchmark 設計。

本章寫 eval 設計的座標系：三個 binary 軸、八個象限、每個象限對應什麼工具、軸選錯的訊號怎麼識別。這層 framing 是 meta、不是具體 eval 方法——具體方法在 4.14 benchmarking 跟 4.21 LLM-as-Judge。

本章目標

讀完本章後你能：

1. 把任何 eval 需求放到三軸座標、定位象限。
2. 對每個象限選對應的 eval 工具。
3. 識別軸誤選的訊號、避免「工具對、軸錯」的常見坑。
4. 規劃 eval 路線：初期該做哪幾個象限、規模化後再補哪些。
5. 把 eval 設計跟 4.14 benchmarking / 4.20 tracing / 4.21 LLM-as-Judge 串成完整 pipeline。

三軸

Eval 設計的三個正交軸：

軸 1：Objective ↔ Subjective

• Objective：有明確 ground truth、檢驗可以寫成 deterministic check（金額對不對、SQL 跑得通不通、JSON schema 合不合法）。
• Subjective：沒有單一正確答案、需要評分或比較（語氣好不好、解釋清楚不清楚、推薦的 trip 合不合用戶）。

判讀訊號：「能不能用 Python 函數判定對錯」、能 → objective、不能 → subjective。

軸 2：Component ↔ End-to-End

• Component：測單一元件、孤立評估（retrieval 拿對 chunk 沒、tool call 參數對沒、prompt 抽出正確 entity 沒）。
• End-to-End：測完整流程、user 視角結果（user 問題有沒有被解決、訂單有沒有完成、conversation 滿意度）。

判讀訊號：「失敗時你想知道是哪一段壞掉」→ component；「你只在乎最終體驗」→ end-to-end。

軸 3：Quantitative ↔ Qualitative

• Quantitative：產出數字（accuracy / latency / cost / pass rate）、可以追蹤、可以比較、可以 alert。
• Qualitative：產出觀察（error pattern、user 抱怨、reviewer 註記）、無法直接 aggregate、但能引導 hypothesis。

判讀訊號：「結果能算平均嗎」→ quantitative；「結果是讀完才知道」→ qualitative。

三軸的正交性

這三軸是正交的、不是同義詞：

• 「Objective + component + quantitative」典型是 unit test（function 返回對不對）。
• 「Subjective + end-to-end + qualitative」典型是 user 訪談（user 整體滿意度）。
• 中間象限存在多種混合、各有對應工具。

八象限

3 個 binary 軸 = 8 象限。每個象限的常見對應工具：

不是「八個都要做」、是「先看你的問題在哪個象限、用對應工具」。

兩個最容易誤判的象限展開：

Subjective + Component + Quantitative（這個 step 輸出評分）：對應工具列「LLM-as-judge pairwise / rubric、human rating」、但 pairwise 是首選、不是 rubric——pairwise 比較讓 judge 的偏差更可控（兩個答案放在一起比、誰好誰差比較好判）、rubric 容易受 verbosity / position bias 影響。Rubric 留給「需要絕對分數而非相對排序」的場景（如要追蹤絕對品質漂移）。詳見 4.21 LLM-as-Judge 的 bias 緩解段。

Objective + Component + Quantitative（元件對嗎）：這象限最容易做、cost 也最低——deterministic check 配 component test、CI 跑、production trace 隨抽即驗。Production AI 系統若這象限沒覆蓋、bug 永遠靠 user 抱怨才發現、debug 跟 incident review 成本高。對應反例：把這象限的測試交給 LLM judge（見軸誤選一）。

軸誤選的訊號

軸選錯時、工具會給出「看起來合理但其實沒用」的訊號。三個常見軸誤選：

誤選一：用 subjective 工具測 objective 行為

例：訂單金額計算對不對、找 LLM judge 來看「這個金額合理嗎」。

• 問題：金額計算有 ground truth、應該 deterministic check（assert order.total == expected）。LLM judge 對「合理」的判斷有偏差、會放過明顯錯誤、會挑剔正確但不直觀的答案。
• 訊號：你發現自己在寫「judge prompt」描述「什麼樣的金額是合理的」、但其實該行為有客觀標準。
• 修正：把 judge prompt 翻成 deterministic check。

誤選二：用 end-to-end 工具測 component bug

例：整套系統 success rate 從 90% 掉到 80%、追了一週、結果是 retrieval 漏 chunk。

• 問題：E2E metric 告訴你「有問題」、不告訴你「在哪」。Component eval 缺失時、debug 從 trace 倒推、耗時。
• 訊號：incident 後 root cause analysis 經常超過一天、查到的東西其實 component eval 該秒抓。
• 修正：對 critical component（retrieval、tool 調用、parse 階段）加 component eval、production 持續跑。

誤選三：用 quantitative 工具找 qualitative 訊號

例：user 滿意度從 4.2 掉到 4.0、團隊看數字盯一週、不知道發生什麼。

• 問題：Quantitative metric 只告訴你「有變化」、不告訴你「為什麼」。Qualitative 訊號（user 抱怨內容、抽樣 conversation）才能浮現 hypothesis。
• 訊號：團隊看 dashboard 看了很久、卻沒人去讀 actual user feedback。
• 修正：quantitative trigger（指標漂移）、qualitative 跟進（讀樣本、找 pattern）。

Eval 演化路徑

不同階段的 LLM 應用、該優先補哪些象限不同。

階段 0：MVP（沒任何 eval）

問題：「能不能 demo 一下就好」、行為對不對全靠手測。

• 第一個該補的：Objective + End-to-end + Quantitative。最少跑 10 個 representative case、能看「跑得起來率」就好。
• 不該太早做：subjective eval、需要 judge / human rating 的東西。MVP 階段先讓系統穩定運行。

階段 1：有 user 在用

問題：production 偶爾有 bug、user 偶爾抱怨、不知道哪些是 systematic、哪些是 random。

• 第二個該補的：Objective + End-to-end + Qualitative。讀 incident、讀抽樣 trace、找 pattern。
• 第三個該補的：Objective + Component + Quantitative。對 critical component（retrieval / tool call / parse）加 component-level eval、production 跑。
• 不該做：完整 subjective rubric。先把 objective 失敗修了再說。

階段 2：要持續優化品質

問題：objective 部分已經穩、user 抱怨主要在 subjective 層（語氣、helpful 程度、推薦合不合用）。

• 第四個該補的：Subjective + Component + Quantitative。用 LLM-as-judge 給每個 step 評分、做 A/B test 比較 prompt 變動。
• 第五個該補的：Subjective + End-to-end + Quantitative。CSAT、thumbs up/down、appeal rate。
• 要做的：Subjective eval 跟 qualitative review 必須配合進行——quantitative 給出方向、qualitative 給出修法 hypothesis。

階段 3：規模化、跨團隊

問題：多個產品 / 團隊用同一套 LLM infra、eval 要 cross-cutting。

• 要做的：標準化 eval pipeline、把象限 1-7 都 cover、qualitative review 進入 ritual（每週 incident review、每月抽樣 trace 讀）。
• 重點不是「全部都有」、而是「每個象限的 owner 清楚」。

Eval 跟 Trace 的閉環

Eval 不是孤立的——它跟 4.20 LLM tracing 形成閉環：

 1[Production traffic]
 2       ↓
 3   [LLM trace]  ← 每次 call / agent step / tool 都記錄
 4       ↓
 5   ├── 即時 monitoring（latency / cost / error rate）
 6   ├── 抽樣進 eval set（人工標 + LLM judge）
 7   └── failed case 進 regression set（防止改 prompt 又壞同樣 case）
 8       ↓
 9   [Eval pipeline]
10       ↓
11   ├── Component eval（單元件 accuracy）
12   ├── E2E eval（整套 success rate）
13   └── Subjective eval（judge / human rating）
14       ↓
15   [Insights]
16       ↓
17   ├── Quantitative：metric 漂移 alert
18   └── Qualitative：error pattern → hypothesis → 修 prompt / tool / RAG
19       ↓
20   [改動進 production]
21       ↓
22   [回到 production traffic、看 metric 收斂]

Production trace 不只是 debug 工具、是 eval set 的活泉。Trace + eval 閉環的設計細節見 4.20。

跟其他 Eval 章節的分工

讀法建議：先讀本章建立座標系、再依當前痛點往對應章節展開。Subjective eval 痛點 → 4.21；自家 benchmark 設計 → 4.14；production observability → 4.20。

有效 eval 系統的四個設計條件

Eval 系統要持續產生有用訊號、必須滿足四個條件。每個條件對應一個常見退化模式、可同時當 checklist 用。

條件一：Judge 只用在 subjective 軸

LLM-as-judge 留給沒 ground truth 的 subjective 行為（語氣、helpful 程度、解釋清楚）、objective 行為（金額、JSON schema、API 參數）用 deterministic check。Judge 的 cost 比 deterministic check 高 1-2 個數量級、精度反而不如、明顯不划算。

對應反例：「全部 eval 都做成 LLM judge」——judge 被誤用在 objective 行為、cost 翻倍、精度反降。

條件二：每個 metric 有 owner、threshold、action

每個 production metric 都要明確：誰負責看（owner）、什麼數字觸發 alert（threshold）、alert 後做什麼（action）。沒這三項的 metric 是 noise。

對應反例：dashboard 上 50 個 metric 圖、沒人定期看、bug 還是靠 user 抱怨才知道。

條件三：Eval set 跟 production traffic 同步

Production trace 持續抽樣補進 eval set、每季 review eval set 跟 traffic 分佈是否一致。

對應反例：eval set 是兩年前定的、production traffic 已經漂得很遠、eval 通過不代表 user 滿意。

條件四：保留 frozen baseline

Frozen baseline 是把某個特定 prompt + 特定 model 跑 production 一段時間後 freeze 起來、每次新版本跟它比、定期 refresh 並標明時點。漂移看得見才能管理。

對應反例：每次 A/B 都跟「最新版本」比、長期累積漂移完全不可見、「整體變好了沒」無從回答。

何時過時 / 何時不過時

不會過時的部分：

• 三軸座標（objective / component / quantitative 三個 binary 軸）。
• 八象限對應工具的結構分類。
• 三類軸誤選的識別訊號跟修正。
• Eval 演化路徑（MVP → user → 優化 → 規模化）。
• Eval / trace 閉環的設計。
• 有效 eval 系統的四個設計條件。

會變的部分：

• 具體 eval framework（OpenAI Evals、Promptfoo、Braintrust、Langfuse 等會持續演化）。
• LLM-as-judge 的具體 prompt 模板跟 bias 緩解技巧。
• 各 benchmark 的權威性（半年一換）。

下一章

下一章：4.14 Benchmarking 與評估方法論、把座標系落到具體 benchmark 設計。Subjective eval 的工具見 4.21 LLM-as-Judge、production trace 怎麼接 eval 見 4.20 LLM tracing、跟 fuzzy engineering 典範的關係見 0.8（fuzzy 行為的測試本質就是 distribution metric）。

本章是 eval 設計的具體實作層——meta 層的 eval 軸選擇（先看軸再看工具的三軸座標）見 4.13 Eval 設計座標系、subjective eval 的核心工具見 4.21 LLM-as-Judge。三章合起來才是 production AI app 的完整 eval pipeline。

本章目標

讀完本章後、你應該能：

1. 看 model card benchmark 數字、判讀對自己場景的相關性。
2. 區分 capability benchmark（MMLU 等）跟 performance benchmark（tok/s 等）。
3. 跑 llama-bench 量測自己硬體 + 模型的真實速度。
4. 設計 in-house benchmark 評估自己工作流的真實品質。
5. 看到 benchmark 異常數字時、知道可能的陷阱。

Capability benchmarks：衡量模型「會什麼」

LLM benchmarks 卡片列了主流 benchmark 的覆蓋面。本節展開對寫 code 場景最相關的幾個：

Coding benchmarks 的演化

判讀建議：

1. 看 SWE-bench、別只看 HumanEval：HumanEval 早飽和、無法區分前沿模型；SWE-bench 仍有大差距、可信度高
2. HumanEval 90% vs 95% 差異不大：飽和區間的 noise 大、判斷 coding 能力靠 SWE-bench / 真實任務測
3. LiveCodeBench 避免污染：定期出新題、模型訓練 cutoff 後的題目不在 pretrain corpus、更能反映真實能力

事實查核註：本章所列 benchmark 飽和狀態（HumanEval 90%+、MMLU 85%+、GSM8K 90%+）、SOTA 數字（SWE-bench < 60%）、各模型在各 benchmark 的相對排名 — 都是 2026/5 估計、隨新模型推出快速變動、引用前以 Papers with Code 跟 HuggingFace Open LLM Leaderboard 當前狀態為準。

Reasoning benchmarks

判讀：

1. Reasoning model 在 AIME / GPQA 顯著領先 instruct model：這正是 reasoning model 的優勢區
2. MMLU 飽和：85%+ 後差別意義不大、改看 MMLU-Pro
3. GSM8K 接近飽和：90%+、改看 MATH / AIME

Long context benchmarks

判讀：聲稱「128K context」要配 RULER / LongBench 分數才知道實用、見 4.11 Long context engineering。

Performance benchmarks：衡量「跑多快」

跟 capability 並列的另一條軸 — 推論速度：

llama-bench：標準工具

llama.cpp 內建 benchmark 工具：

 1# 基本測試：純 generation 速度
 2llama-bench -m model.gguf -p 512 -n 128
 3# -p 512：prompt 512 token（測 prefill）
 4# -n 128：generate 128 token（測 decode）
 5
 6# 不同 context 長度的影響
 7llama-bench -m model.gguf -p 512,2048,8192 -n 128
 8
 9# 開 flash attention
10llama-bench -m model.gguf -p 512 -n 128 -fa 1
11
12# Speculative decoding 對比
13llama-bench -m target.gguf --draft-model drafter.gguf \
14            -p 512 -n 128 --speculative-draft 5

輸出範例：

1| model                |       size |     params | backend    | ngl |   test |              t/s |
2| -------------------- | ---------: | ---------: | ---------- | --: | -----: | ---------------: |
3| gemma3 31B Q4_K - M  |  18.45 GiB |    31.21 B | Metal      |  99 |  pp512 |    324.21 ± 1.27 |
4| gemma3 31B Q4_K - M  |  18.45 GiB |    31.21 B | Metal      |  99 |  tg128 |     28.43 ± 0.31 |

讀法：

• pp512：prefill 512 token 的 throughput（tok/s）
• tg128：generate 128 token 的 throughput（tok/s、即 tok/s）
• ± 0.31：多次跑的 std deviation、< 5% 是穩定基線

推論成本 vs 品質的 trade-off 矩陣

對自己機器跑 llama-bench 後、可以建一個矩陣：

1                     tok/s 高           tok/s 中           tok/s 低
2品質（HumanEval）
3     高              [Q4 7B coder]      [Q4 14B coder]    [Q4 30B reasoning]
4     中              [Q4 14B instruct]  [Q4 30B instruct]
5     低              [Q4 30B base]      [unused]          [unused]

對應到實際選型：

• 自動補完（高頻、低品質需求）：左上 tok/s 高的小模型
• 對話（中頻、中品質需求）：中段
• 複雜 reasoning（低頻、高品質需求）：右下大 reasoning model

In-house benchmark：自己工作流的真實評估

最重要的 benchmark 是「自己真實任務上的表現」、公開 benchmark 是粗略 filter。

建立 in-house benchmark 的步驟

 11. 蒐集真實案例
 2   - 從過往工作流挑 30-100 個有代表性的任務
 3   - 含「容易任務」「中等任務」「困難任務」三類
 4   - 每個任務記錄 (input prompt, expected output 或評分標準)
 5
 62. 定義評分機制
 7   - Objective（最理想）：unit test、exact match、能機械驗證
 8   - Semi-objective：rubric 評分、人工或 LLM-as-judge
 9   - Subjective（最後手段）：人工 A/B 偏好
10
113. 跑 candidate models
12   - 對每個模型、每個任務都跑、記錄輸出
13   - 注意推論參數一致（temperature、top-p、max_tokens 一樣）
14   - 注意 prompt 一致（chat template、system prompt）
15
164. 評分
17   - Objective：跑 test、算 pass rate
18   - Semi-objective：建 rubric、評分
19   - Subjective：人工 / LLM 評
20
215. 看分佈、不只看平均
22   - 平均 80% 可能來自「20 題滿分 + 80 題 70%」或「100 題 80%」
23   - 看 std、看哪些任務崩、針對性 debug

LLM-as-judge 的注意點

用 LLM（如 GPT-4、Claude）評其他 LLM 是省人力的方法、但有 bias：

1. Verbosity bias：judge 傾向給「答得長」的高分、即使內容沒提升
2. Position bias：A/B 比較時、judge 對 A、B 位置敏感、要做 swap 平均
3. Self-preference bias：judge 模型偏好自己風格的答案
4. Judge 能力上限：judge 模型本身不夠強、評不出兩個強模型的差距

緩解：

1. 用結構化 rubric：給 judge 明確評分標準、不只「哪個好」
2. 多 judge 取共識：用 2-3 個不同 judge model 各評、取一致 / 平均
3. Critical task 仍要人工 review：高 stake 任務不能全靠 LLM-as-judge

常見陷阱跟反例

陷阱 1：訓練資料污染

模型在 benchmark 題目上「看似強」、實際是 memorization：

判讀訊號：

• benchmark cutoff date 之前的 dataset、新模型分數異常高
• 同模型在「同 dataset 變體（rephrase）」上分數顯著低

緩解：用較新出題的 benchmark（如 LiveCodeBench 定期更新）。

陷阱 2：Single benchmark 過擬合

模型廠商針對特定 benchmark fine-tune、benchmark 高但通用能力沒提升：

判讀訊號：

• 在 benchmark A 顯著領先、在 benchmark B（測類似能力）沒差
• 同模型實際使用後評價跟 benchmark 不符

緩解：看多個 benchmark + in-house benchmark。

陷阱 3：Prompt sensitivity

同 benchmark 用不同 prompt 格式、score 差幾個百分點：

判讀訊號：

• model card 報的數字跟自己跑差很多
• 同模型不同 prompt template 結果差距大

緩解：自己跑、用一致的 prompt template；report 時明確標 prompt 版本。

陷阱 4：Sampling 設定不一致

不同模型用不同 temperature / top-p、結果不可比：

判讀訊號：

• 兩篇 paper 用同 benchmark 報不同數字、推論參數不同

緩解：對 reproduction 用 temperature=0 + greedy decoding 確保一致。

Benchmark 之間的關係跟導讀路徑

各 benchmark 在不同階段的角色：

 1研究模型能力（paper 階段）：
 2  HELM / MT-Bench / Chatbot Arena → 通用能力 baseline
 3  MMLU / GSM8K / AIME            → reasoning 能力
 4  HumanEval / SWE-bench           → coding 能力
 5  RULER / LongBench               → long context
 6
 7挑選模型（user 階段）：
 8  Open LLM Leaderboard            → 快速 filter
 9  MTEB（若 RAG）                  → embedding model
10  In-house benchmark              → final 確認
11
12監控模型（production 階段）：
13  自己工作流 KPI                  → 真實品質
14  A/B test                       → 部署前的決策
15  User feedback                  → 持續迭代

何時過時 / 何時不過時

不會過時的部分：

• Benchmark 跟自己任務對齊的必要性
• 訓練污染 / 飽和 / single-task overfit 的陷阱
• LLM-as-judge bias 的存在
• In-house benchmark 是最後 final test
• llama-bench 是量測本地推論的標準工具

會變的部分：

• 各 benchmark 的飽和狀態跟前沿 score
• 主流 benchmark 的選擇（HumanEval → MBPP → SWE-bench → …）
• LLM-as-judge model 的偏好（隨 judge model 更新而變）
• 新 benchmark 出現（特別是 reasoning / long-context 領域）

下一章

下一章：4.15 Vision in coding workflow、把 vision 維度加進 coding 工作流的設計取捨。讀完 4.10、模組四覆蓋了 LLM 作為系統元件的設計取捨（RAG、tool use、agent、應用層協議、workflow、resource planning、long context、embedding、benchmarking、vision）、寫 code 場景需要的應用層概念完整、之後可進入 模組五 PC 獨立 GPU 或 模組六 安全。

Judge 在 eval 系統中的定位：4.13 Eval 設計座標系 把 eval 分三軸八象限、判斷哪個象限該用什麼工具——judge 的位置是 subjective 軸（沒 ground truth 的行為）、不是 objective 軸（有 ground truth 用 deterministic check 更便宜更準）。讀本章前先看 4.13 的軸誤選段、避開「全部 eval 都做成 judge」的常見反模式。

本章目標

讀完本章後、你應該能：

1. 區分 LLM-as-Judge、standard benchmark、human eval 三條 eval 路徑。
2. 設計可重現的 judge rubric（input / output / rubric / reasoning 四段）。
3. 用 pairwise vs direct scoring、知道何時用哪種。
4. 緩解三大 bias（position / verbosity / self-preference）。
5. 把 production trace 餵回 judge、形成自動 eval 閉環。

為什麼需要 LLM-as-Judge

4.14 推「in-house benchmark 是 final test」、但操作層是個 gap：

主要 use case（重複 LLM-as-Judge 卡片）：in-house benchmark、production trace eval、A/B test、synthetic data quality。

Judge prompt 結構

可重現的 judge 必須四段式：

 1[Section 1: Task description]
 2你是 LLM 輸出品質評估員。要評估 coding assistant 對使用者請求的回答品質。
 3
 4[Section 2: Input + Output to evaluate]
 5User request: {input}
 6Assistant response: {output}
 7
 8[Section 3: Rubric（評分標準）]
 9評分維度：
101. Correctness（程式碼能否運作、邏輯是否正確）：1-5
112. Style（是否符合 codebase convention）：1-5
123. Completeness（是否完整解決 user request）：1-5
13
14評分規則：
15- 5：完美無瑕、可直接 merge
16- 4：小修可用、整體正確
17- 3：方向正確、需 substantial 修改
18- 2：部分對、主要邏輯有錯
19- 1：完全錯、誤導使用者
20
21明確不加分：
22- 冗長 / verbose（同樣正確的短答 = 長答）
23- 道歉 / 開場白
24- 「我希望這有幫助」這類禮貌話
25
26[Section 4: Output format]
27請依下列 JSON 輸出：
28{
29  "correctness": <1-5>,
30  "style": <1-5>,
31  "completeness": <1-5>,
32  "reasoning": "<簡短解釋>",
33  "overall": <1-5>
34}

關鍵設計原則：

1. Rubric 明確、可重現：用 1-5 scale + 每分明確定義、避免 judge 自由發揮
2. 明確列「不加分項」：vag rubric 容易讓 judge 加分長答 / 道歉 / 客套（verbosity bias）
3. 要求 reasoning：強迫 judge 寫評分理由、提升 calibration、後續可 debug
4. Structured output：用 JSON / structured output 強制格式、後續可程式化處理

Pairwise vs Direct scoring

兩種主流評分方式：

Direct scoring（直接打分）

給一個 (input, output)、judge 給絕對分數（1-5、1-10）。

優點：簡單、可看「絕對品質」隨時間改變 缺點：分數 calibration 不穩（不同 batch 跑、judge 可能 baseline drift）

Pairwise comparison（兩兩比較）

給一個 input + 兩個 output（A、B）、judge 選哪個比較好。

優點：相對比較比絕對打分穩、適合 A/B testing 缺點：需要兩個 candidates、結果是「A > B」不是「A 多好」

實務組合：

三大 Bias 跟緩解

1. Position bias（位置偏見）

Pairwise 比較時、judge 對「先出現」的 candidate 有偏好（通常偏 A）。

緩解：

• 換位置跑 2 次（A-B 跟 B-A）
• 只 count 兩次都偏 A 的為「prefer A」、不一致為「tie」
• 標準 LLM-as-Judge framework（如 MT-Bench）內建這做法

2. Verbosity bias（冗長偏見）

Judge 傾向給「長答」高分、即使內容沒比「短答」更好。

緩解：

• Rubric 明確寫「冗長不加分」「同樣正確的短答 = 長答」
• 長度 normalize：分數 = raw_score / log(length)
• 用 length-controlled benchmark（如 length-controlled AlpacaEval）

3. Self-preference bias（自家偏好）

Judge 偏好自家風格的答案（GPT 當 judge、偏好 GPT-style 輸出；Claude 當 judge、偏好 Claude-style）。

緩解：

• 用 3 個不同 family 的 judge model（如 Claude + GPT + Gemini）取多數
• 避免 judge 跟 test subject 同 model
• 用 reasoning model 當 judge（多家 reasoning model 共識更穩）

補充 bias：Format bias

Judge 對「有 markdown / 有 code block / 有結構」的答案偏好、即使內容沒比「純文字」更好。

緩解：rubric 明確寫「格式不加分、看內容」。

Calibration（校準）

Judge 不該光信、要 calibrate：

 11. 蒐集 100 個 (input, output) pair
 22. Human eval（你自己或可信 human）打 ground truth 分數
 33. Judge 跑同樣 100 個
 44. 算 agreement rate：
 5   - Pairwise：judge 跟 human 同意比例（target > 75%）
 6   - Direct scoring：Spearman correlation（target > 0.7）
 75. 若 agreement 低：
 8   - 改 rubric（更明確）
 9   - 換 judge model（更強）
10   - 改 prompt（few-shot example）
116. Calibrate 後的 judge 才能跑 production

Calibration 是「judge 評什麼」跟「人類評什麼」對齊的步驟、跳過會讓 production eval 失準。

跟 4.20 LLM tracing 的閉環

Production trace + LLM-as-Judge 形成自動 eval pipeline：

 1Production users
 2   ↓ 產生 trace
 3[LLM tracing 平台]（LangSmith / Phoenix / Langfuse / Braintrust）
 4   ↓ filter：user thumbs-down、error、long latency 等 trace
 5   ↓ sample 100 個 / day
 6[LLM-as-Judge batch run]
 7   ↓ rubric scoring
 8[Dashboard]
 9   - 哪類 query 品質下降
10   - 哪個 deployment version 品質差
11   - 哪個 user segment 體驗差
12   ↓
13觸發 alert / 改 prompt / 改 model / 回退
14   ↓ A/B test
15   ↓ Pairwise judge eval new vs old
16   ↓ Deploy 勝者

這是 production LLM 應用 quality engineering 的標準閉環。

Judge model 選型

判讀：

1. 大 stake / final QA：雲端旗艦 reasoning model
2. 大量 production trace eval：中等模型（GPT-4o / Sonnet）、cost / speed 平衡
3. 隱私敏感（user trace 不能送雲端）：本地 reasoning model（QwQ-32B / R1 distill）
4. A/B test prompt 改進：用同個 judge 跑前後比對、保持 baseline

失敗模式

1. Rubric 太 vague：judge 自由發揮、分數沒重複性

緩解：rubric 寫得像 unit test、每分有具體 criteria

2. 沒做 calibration：judge 跟 human agreement 沒驗、可能 systematically off

緩解：每次大改 rubric / 換 judge model 都重新 calibrate

3. Sample 不代表 production：只 eval easy case、production 真實困難 case 沒覆蓋

緩解：用 stratified sampling（按 difficulty / user segment / feature 抽樣）

4. Bias 沒緩解：position / verbosity / self-preference 直接 baked in

緩解：標準 framework（DeepEval / Inspect / Braintrust）內建 bias 緩解、用既有 framework 比 DIY 穩

5. Judge cost 比預期高：production trace 全跑 judge、cost 爆

緩解：sample rate < 10%、配合 LLM tracing 的 sampling

6. Over-reliance on judge：忘記 judge 也會錯、把 judge 當絕對真理

緩解：高 stake 任務仍需 spot human review、judge 是 80% 解、不是 100%

主流 framework

何時不該用 LLM-as-Judge

1. 可機械驗證：unit test、exact match、output schema validation — 用 deterministic rule 比 judge 穩
2. 極小 dataset（< 20 items）：直接 human eval、不必 judge
3. 判讀需要 domain expertise：醫療 / 法律 / 安全的 high-stake 判讀、judge 不該替代 expert
4. Judge 能力 < test subject：用 GPT-4o judge 評 o3 輸出、judge 看不懂 reasoning trace

何時過時 / 何時不過時

不會過時的部分：

• LLM-as-Judge 作為 production eval 主流方法的地位
• 四段式 judge prompt 結構（task / input-output / rubric / format）
• Pairwise vs direct scoring 的取捨
• 三大 bias 分類跟緩解方法
• Production trace → judge → action 的閉環

會變的部分：

• 主流 framework（DeepEval / Inspect / Braintrust 等）
• 各 judge model 的具體能力（每代強模型）
• Bias 的具體量化（人類 agreement 數字會隨時間 / 任務變）
• 新興 bias 跟緩解方法

下一步

下一步：模組四到此覆蓋從基礎（4.0 prompt 技術光譜 / 4.1-4.2 RAG / 4.3 tool / 4.4 agent / 4.5 HITL）、協議與編排（4.6 protocols / 4.7 workflow / 4.8 multi-agent）、production 細節（4.9-4.12 resource / artifact / long-context / embedding）、到 eval 跟 production observability 閉環（4.13 eval 框架 / 4.14 benchmarking / 4.17-4.21 harness / caching / memory / tracing / judge）的完整應用層地圖。Hands-on 端到端案例見 hands-on 子分類。可進入 模組五 看本地推論硬體、進入 模組六 看安全議題（特別是 6.6 OWASP LLM Top 10 對照、把 production eval 的安全議題對應到企業合規詞彙）、或回 4.13 Eval 設計座標系 看 judge 在 meta eval 框架中的定位。