什麼是「模型降智」？
模型降智（Model Degradation）指的是 AI 語言模型在更新後，某些能力出現退化的現象。常見症狀包括：
- 回答變得更簡短、更表面
- 推理鏈斷裂，跳過關鍵步驟
- 指令遵循能力下降（忽略約束條件）
- 創意寫作品質下滑
- 程式碼生成準確度降低
這不是主觀感受的問題——它可以被系統性地量化與驗證。
驗證框架：五大維度
| 維度 | 測試目標 | 代表性任務 |
|---|---|---|
| 邏輯推理 | 多步推理、反事實推理 | 數學應用題、邏輯謎題 |
| 指令遵循 | 精確執行複合指令 | 格式約束、多條件生成 |
| 知識深度 | 專業領域的準確性 | 技術問答、事實查核 |
| 程式碼能力 | 生成正確且高效的程式碼 | LeetCode 題目、Debug 任務 |
| 創意與細膩度 | 語言品質、隱喻、風格控制 | 寫作風格模仿、詩歌生成 |
實際測試流程
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
記錄模板
每次測試應記錄：
| 欄位 | 範例 |
|---|---|
| 測試日期 | 2026-04-12 |
| Model ID | claude-opus-4-6 |
| Prompt ID | logic-001 |
| 原始回應 | （完整保存） |
| 評分 | 4/4 |
| 回應 token 數 | 347 |
| 延遲 (ms) | 1823 |
| 備註 | 推導完整，無跳步 |
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：排除干擾因素
在宣稱「模型降智」之前，必須排除以下因素：
| 干擾因素 | 排除方法 |
|---|---|
| Prompt 微調 | 確保 prompt 完全一致（hash 校驗） |
| Temperature 差異 | 固定為 0 |
| System prompt 影響 | 測試時清空 system prompt |
| API 路由差異 | 記錄完整的 model ID，而非別名 |
| 樣本量不足 | 每個 prompt 至少跑 5 次 |
| 評分主觀偏差 | 客觀題用自動評分；主觀題用 blind evaluation |
| 記憶偏誤 | 不要憑「感覺」，只看數據 |
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 呼叫仍可能有微小差異。單次測試不能作為結論依據。
結論
驗證模型降智的核心原則：
- 可重現 — 固定 prompt、固定參數、多次重複
- 可量化 — 明確的評分標準，而非主觀感受
- 可比較 — 縱向（時間軸）與橫向（跨模型）同時進行
- 排除干擾 — 系統性地排除非模型因素
- 統計嚴謹 — 用 p-value 而非直覺下結論
模型降智是真實存在的現象，但網路上的大量「降智」討論往往缺乏嚴謹的測試方法。用數據說話，是區分事實與感覺的唯一方式。