如何驗證LLM降智

什麼是「模型降智」？

模型降智（Model Degradation）指的是 AI 語言模型在更新後，某些能力出現退化的現象。常見症狀包括：

• 回答變得更簡短、更表面
• 推理鏈斷裂，跳過關鍵步驟
• 指令遵循能力下降（忽略約束條件）
• 創意寫作品質下滑
• 程式碼生成準確度降低

這不是主觀感受的問題——它可以被系統性地量化與驗證。

驗證框架：五大維度

實際測試流程

Step 1：建立基準測試集（Benchmark Suite）

設計一組固定的 prompt，涵蓋五大維度。關鍵原則：prompt 必須完全固定，不可修改。

以下是每個維度的範例 prompt：

1.1 邏輯推理

Prompt: 一個房間裡有 100 個人。99% 離開了。要讓剩下的人佔房間裡人數的 2%，需要再回來幾個人？

預期正確答案：需要再回來 49 人。
推導過程：
- 100 人中 99% 離開 → 剩下 1 人
- 設需回來 x 人，則房間內有 1 + x 人
- 1 / (1 + x) = 2% = 0.02
- 1 + x = 50 → x = 49

1.2 指令遵循

Prompt: 請用正好 5 個句子描述量子糾纏。
每個句子必須以不同的母音字母（A, E, I, O, U）開頭。
不要使用「粒子」這個詞。
最後一句必須是反問句。

評分標準：
- 正好 5 句（±0）
- 5 個不同母音開頭
- 未使用禁用詞
- 末句為反問句
- 滿分 4 分，每違反一項扣 1 分

1.3 知識深度

Prompt: 解釋 Raft 共識演算法中 Leader Election 的 split vote 問題，
以及 randomized election timeout 如何降低其發生機率。
請包含具體的 timeout 範圍建議值。

評分標準：
- 正確描述 split vote 成因（1 分）
- 正確說明 randomized timeout 機制（1 分）
- 給出合理的 timeout 範圍，如 150-300ms（1 分）
- 提及 term number 的角色（1 分）

1.4 程式碼能力

Prompt: 用 Python 實作 LRU Cache，支援 get(key) 和 put(key, value)。
要求 O(1) 時間複雜度。不要使用 collections.OrderedDict。

評分標準：
- 使用 HashMap + Doubly Linked List（1 分）
- get 和 put 均為 O(1)（1 分）
- 正確處理 capacity 滿時的淘汰（1 分）
- 程式碼可直接執行且通過邊界測試（1 分）

1.5 創意與細膩度

Prompt: 以海明威的風格寫一段 100 字以內的短文，主題是「等待」。
要求：短句為主，不使用形容詞超過 3 個，包含一個具體的感官細節。

評分標準（主觀 1-5 分）：
- 風格還原度
- 感官細節的鮮明程度
- 用字精煉程度

Step 2：執行測試與記錄

測試參數控制

測試配置:
  temperature: 0          # 消除隨機性
  max_tokens: 2048        # 統一上限
  system_prompt: ""       # 不使用 system prompt
  重複次數: 5             # 每個 prompt 跑 5 次取平均
  API 版本: 記錄具體日期與 model ID

記錄模板

每次測試應記錄：

Step 3：數據分析方法

3.1 縱向比較（同模型不同時間）

範例數據：Claude Opus — 邏輯推理維度

日期          分數 (滿分20)    平均 token 數    平均延遲
2026-01-15    18              412             2100ms
2026-02-20    19              398             1950ms
2026-03-18    17              356             1780ms
2026-04-12    16              301             1620ms

分析要點：

• 分數是否呈下降趨勢？
• token 數減少是否伴隨品質下降？（可能是回答變簡略）
• 延遲降低 + 品質降低 = 可能使用了更小的模型或更激進的量化

3.2 橫向比較（不同模型同一時間）

範例數據：2026-04-12 — 程式碼能力維度

模型                  分數 (滿分20)    首次可執行率
Claude Opus 4.6       18              100%
Claude Sonnet 4.6     16              90%
GPT-4o                15              85%
Gemini 2.5 Pro        17              95%

3.3 統計顯著性檢驗

僅憑幾次測試不能下結論。使用 paired t-test 或 Wilcoxon signed-rank test 驗證差異是否顯著：

from scipy import stats

# 同一組 prompt 在兩個時間點的分數
scores_before = [4, 4, 3, 4, 4, 3, 4, 4, 4, 3]  # 平均 3.7
scores_after  = [3, 4, 3, 3, 2, 3, 4, 3, 3, 3]  # 平均 3.1

t_stat, p_value = stats.ttest_rel(scores_before, scores_after)
print(f"t = {t_stat:.3f}, p = {p_value:.4f}")

# p < 0.05 → 差異具統計顯著性，可以認為模型能力確實下降
# p >= 0.05 → 不能排除隨機波動，需要更多數據

Step 4：排除干擾因素

在宣稱「模型降智」之前，必須排除以下因素：

Step 5：自動化監控（Optional）

建立持續監控管線，定期自動執行測試：

# benchmark_runner.py — 簡化示意
import anthropic
import json
from datetime import datetime

client = anthropic.Anthropic()

PROMPTS = json.load(open("benchmark_prompts.json"))

def run_benchmark(model_id: str):
    results = []
    for prompt in PROMPTS:
        response = client.messages.create(
            model=model_id,
            max_tokens=2048,
            temperature=0,
            messages=[{"role": "user", "content": prompt["text"]}]
        )
        results.append({
            "date": datetime.now().isoformat(),
            "model": model_id,
            "prompt_id": prompt["id"],
            "response": response.content[0].text,
            "tokens": response.usage.output_tokens,
        })
    return results

# 每週執行，結果寫入 CSV/DB 做趨勢追蹤

常見誤判案例

誤判 1：「回答變短了 = 降智」

回答變短可能是模型優化了簡潔性。只有在回答變短且遺漏關鍵資訊時，才算降智。

誤判 2：「我的 prompt 不 work 了 = 降智」

模型更新可能改變了對 prompt 的理解方式。先嘗試微調 prompt，如果多種合理表述都退化，才傾向於降智。

誤判 3：「一次測試不好 = 降智」

即使 temperature=0，不同 API 呼叫仍可能有微小差異。單次測試不能作為結論依據。

結論

驗證模型降智的核心原則：

1. 可重現 — 固定 prompt、固定參數、多次重複
2. 可量化 — 明確的評分標準，而非主觀感受
3. 可比較 — 縱向（時間軸）與橫向（跨模型）同時進行
4. 排除干擾 — 系統性地排除非模型因素
5. 統計嚴謹 — 用 p-value 而非直覺下結論

模型降智是真實存在的現象，但網路上的大量「降智」討論往往缺乏嚴謹的測試方法。用數據說話，是區分事實與感覺的唯一方式。