【2026 最新】AI 模型降智怎麼查？用 10 題 Shadow Eval 分清回歸、塞車與路由漂移

當你懷疑 AI 模型降智，常見的錯不是測得太少，而是把所有變化都怪到「模型大腦」。同一個聊天產品還包含入口、模型路由、reasoning effort、工具權限、上下文、快取與服務容量；其中任何一層改變，都可能讓今天的答案不像昨天。

2026 年 9 月 10 日，Reddit 同一天出現要求重跑 benchmark、追問 Astra 是否降級與額度消耗的討論；但這些都是使用者自述，不能證明供應商暗中修改模型。同一週的 OpenAI 狀態紀錄也列出 ChatGPT Pro／Plus 錯誤率升高事件，那只能證明服務曾出狀況，仍不能反推答案品質變差的原因。

這篇不替任何「stealth nerf」傳聞背書，而是教你建立一套每天可重跑的 10 題 Shadow Eval：保留首日基準、每個條件跑三次、盲評新舊答案，再用診斷樹把模型回歸、服務塞車、路由漂移、設定改變與配額成本拆開。你最後得到的不是一張驚豔截圖，而是一份可以交叉檢查的事件紀錄。

先說結論：AI 模型降智先別猜，先做 Shadow Eval

Shadow Eval 可以翻成「影子評測」：它不取代你平常的工作，而是在旁邊用同一組小題庫，定期量測產品或模型的行為。就像冰箱裡放一支溫度計；你不是每天拆壓縮機，而是先看溫度是否持續偏離。

請先記住本文的錨點：

降智證據 ＝ 同一題庫 × 鎖定變因 × 重複試跑 × 盲評。

少任何一項，結論就只能叫「線索」

• 只有一張壞答案截圖：是線索，不是回歸證據。
• 同一題連跑三次仍不穩：先證明有變異，還沒證明原因。
• 同題、同設定、同版本的配對結果持續退步：才值得升級成回歸警報。
• 只有延遲、錯誤或額度改變：另列服務與成本事件，不要混進品質分數。

OpenAI 的評測最佳實務也建議使用任務特定資料、記錄所有設定並持續評測，而不是憑感覺挑範例。若你要先學完整的產品 Eval 與 grader 概念，可搭配 AlphaLab 的AI Evals 七步教學；本文只處理更窄的一題：原本好用的模型突然變差時，怎麼找出是哪一層在動。

為什麼「今天變笨」其實有五種來源？

你看到的是一個答案，背後卻至少有五層。把它們想成餐廳：主廚是模型，但訂單內容、指定火候、分店、廚房塞單與會員額度都會改變用餐體驗。

1. 題目與上下文漂移：prompt、附件、系統指令、訊息順序或工具 schema 變了。即使只是格式差異，也可能改變結果。
2. 設定漂移：reasoning effort、最大輸出、工具權限、搜尋開關或產品模式不同。它們不是模型名稱，卻會影響可用計算與行為。
3. 路由漂移：你請求的是一個會移動的 alias，或產品介面在背後選擇不同路徑。只有回傳欄位或官方文件可見時，才有資格說路由「已被觀察到」；看不到時只能標記為待查假說。
4. 服務容量變化：錯誤率、逾時與延遲在某個時段升高。這可解釋可用性變差，卻不自動等於模型能力下降。
5. 模型或產品行為回歸：前三類控制後，原本會通過的任務仍持續失敗。這才是 Shadow Eval 要抓的核心警報。

快取也要單獨看。以 OpenAI API 為例，官方Prompt Caching 文件說明它用來降低相同前綴的處理延遲與成本，回應會提供 cached tokens 等使用量資訊；快取命中本身不是答案品質分數。若快取、KV 與工作節點路由是你的主要問題，另讀Agent KV Cache 擴充教學，不要把基礎設施指標硬翻成「智力」。

10 題 Shadow Eval 怎麼選？只放你真的在乎的任務

這 10 題不是公開排行榜的縮小版，也不是用來選出「宇宙最強模型」。它是一組個人煙霧警報器：每一題都來自你反覆做的真實工作，而且有可觀察的成功條件。這和10 題模型路由 Eval的差別在於，後者替不同任務選模型；Shadow Eval 則固定原本的工作，追蹤同一體驗有沒有偏離。

1. 精確擷取：從你提供的文件抓 6 個指定欄位；逐欄對答案。
2. 格式轉換：把一段資料變成固定 JSON；用 parser 驗證欄位與型別。
3. 長文定位：從長附件找出三處關鍵資訊；要求附原段落或頁碼。
4. 可核算推理：放一題你能手算的成本、比例或排程題；驗證答案與步驟。
5. 限制寫作：指定語氣、受眾、長度與禁用詞；逐項勾選。
6. 忠實改寫：縮短內容但不得新增事實；檢查遺漏與幻覺。
7. 程式或工具：在固定小專案修一個有測試的 bug；以測試結果為準。
8. 模糊需求：故意少給一個關鍵條件；通過標準是先提問，不是自作主張。
9. 指令遵循：放入彼此容易混淆的優先順序；核對是否遵守有效指令。
10. 你的高價值任務：可能是讀圖、研究摘要或客戶回覆；只選失敗真的會讓你重做的工作。

每題 rubric 只寫三件事：必須做到、重大失敗、可接受差異。例如「找出合約日期」的重大失敗是日期錯誤；用條列或短句只是可接受差異。先寫 rubric 再看答案，才不會因為新答案比較長、比較有自信就給高分。

可直接複製的 Shadow Eval 工作表

先複製下列欄位到試算表。不要只存最終分數；原始輸入、輸出與 request ID 才能讓你回頭查案。

run_id	UTC_time	entry	entry_version	requested_model	returned_model
task_id	prompt_hash	file_hash	request_body_hash	tool_schema_hash
settings_hash	effort	tools_enabled	service_tier	status	latency_ms
input_tokens	cached_tokens
output_tokens	reasoning_tokens	request_id	blind_label
pass_fail	critical_failure	failure_type	notes

entry 是 ChatGPT 網頁、手機 App、Codex 或 API；requested_model 是你選的名稱，returned_model 則只記系統實際回傳的值。OpenAI 的API 文件建議保存 x-request-id，也允許你送出自訂 X-Client-Request-Id 方便追查；request ID 能協助客服定位請求，但不代表它揭露了隱藏的模型快照。

若你當次使用的入口沒有顯示某個欄位，請填 not_visible，不要猜。看不到回傳模型時，你能證明的是「這個入口的體驗改變」，不能直接證明模型權重或後端路由改了。

AI 模型降智檢查：六步保存 baseline 並做盲評

步驟 1：先問「我到底要證明什麼？」

痛點：如果問題只是「它是不是變笨」，任何壞答案都能被塞進結論。解法：把假說寫成可被推翻的一句話，例如：固定 API snapshot 與 effort 後，任務 03、07 的重大失敗率高於首日 baseline。驗證：結果若只出現在網頁入口或尖峰時段，就必須拒絕這個模型層假說，改查產品與服務層。

步驟 2：凍結完整請求，不只凍結 prompt

痛點：你以為題目相同，附件版本、訊息歷史或工具權限其實已不同。解法：保存完全展開的 system／user 訊息、附件位元組、工具 schema、設定與入口版本，並計算 SHA-256。驗證：兩次試跑的 prompt hash 與 file hash 必須相同；不同就標記為 context drift，不進模型回歸比較。

步驟 3：首日保留真正的 baseline

痛點：沒有舊輸出，就無法證明「比以前差」。解法：模型或產品剛符合需求時，立刻保存 10 題輸入、三次原始輸出與 rubric。API 若有官方列出的 dated snapshot，可在可用時鎖定；OpenAI 的API 說明提醒，模型行為可能隨 snapshot 改變，並建議搭配 pinned version 與 eval。驗證：模型頁沒有列出的 snapshot 絕對不要自行拼日期；只有 moving alias 時，結論應寫成「目前 alias 的行為觀察」。

步驟 4：新舊條件各跑三次，交錯順序

痛點：LLM 輸出本來就有變異，單次好壞容易被運氣放大。解法：每題每個條件先跑三次，把三個 A 與三個 B 隨機交錯，例如 A-B-B-A-A-B，並保留逾時與錯誤，不要靜默重試後刪掉。驗證：三次只是個人 canary 的起始值，不是統計學保證；結果分裂時，把該題擴到五次以上，或先修正含糊 rubric。

步驟 5：遮掉身份，再做 A/B 配對

痛點：知道哪份是新模型，評分者很容易先有期待。解法：移除模型、日期與 request ID，隨機改成 A／B；客觀題先跑 parser、單元測試或答案鍵，主觀題再用詳細 rubric 做盲評。若用另一個 AI 當 judge，把 A/B 與 B/A 都評一次，兩個順序一致才記勝方，否則記平手。驗證：先用一小批人工標註校準 judge，避免位置與篇幅偏誤。

步驟 6：把品質、可用性與成本分成三張帳

痛點：額度掉得快、回答慢、內容錯，常被混成一句「降智」。解法：品質帳記 pass／fail 與失敗類型；可用性帳記錯誤、TTFT、總延遲與服務狀態；成本帳記 token、cache、配額或費用。驗證：只有品質帳在鎖定條件後持續退步，才進入模型回歸調查。想更深入做成本 A/B，可參考RTK Claude Code 配對評測的控制變因設計。

診斷樹：回歸、塞車、路由漂移，分別長什麼樣？

• hash 不同：先判為 prompt／context 漂移。修正後重跑，不比較舊分數。
• effort、工具或輸出上限不同：先判為設定漂移。這也是effort 工作簿為什麼要把模式與 token 分開記。
• 品質大致穩定，但錯誤與延遲集中在同一時段：判為服務層疑點；對照供應商 status history，保存 request ID 後再查。
• moving alias 變差、可鎖定的 snapshot 穩定：可把路由或 alias 行為列為強假說；仍以官方可見 metadata 為界，不推測未公開後端。
• 同 snapshot、同輸入、同設定跨時段持續失敗：升級為「此任務集的回歸警報」，附原始 paired 結果回報供應商。
• 品質穩定，但 token／配額變高：先列為成本、計量或輸出行為疑點，核對輸入輸出長度、reasoning effort、mode、cache 與產品用量規則；不要用成本變化推論智力。

若你用的是多供應商 gateway，路由紀錄還要包含 provider、attempt、fallback reason 與最終成功路徑；LiteLM 教學示範的是這一層的責任邊界。Shadow Eval 不需要先蓋一套大型平台，但每多一層自動 fallback，就多一個必須留下的 receipt。

一個示意案例：壞答案不等於模型回歸

以下是方法示意，不是 AlphaLab 對任何模型的實測結果。假設任務 03 是從長合約找續約日，首日三次都通過；一週後，聊天網頁三次有兩次漏答，API 的固定 snapshot 三次仍通過。

1. 先比 hash：附件與 prompt 相同。
2. 再比設定：網頁看不到 effort 與路由，API 設定則已鎖定。
3. 再看時段：網頁失敗時伴隨錯誤或高延遲，隔天離峰恢復。
4. 最後寫結論：「聊天產品在該時段的任務 03 體驗退步；固定 API snapshot 未重現。服務／產品層優先待查，現有證據不足以歸因模型能力。」

反過來，若固定 snapshot、相同 effort 與同一份附件，在不同時段仍反覆漏答，且舊 snapshot 同步配對能通過，才有較強的模型版本回歸證據。這仍只代表你的 10 題任務集，不代表全世界所有用途都退步。

常見的 6 個 Shadow Eval 陷阱

1. 事後挑題：只留下新模型答錯的題，會把結果變成檢控材料。題庫與門檻要在試跑前凍結。
2. 把 temperature 0 當成完全確定：生成仍可能有變異；重現性研究也支持重複試跑，但不要把特定研究的次數當成所有任務的定理。
3. 把長答案當好答案：盲評只看 rubric；格式漂亮不能抵銷事實錯誤。
4. 偷偷丟掉逾時：逾時是可用性結果。保留它，但不要直接算成知識錯誤。
5. 把私有題庫調教到洩漏：常用題可以當 canary，另留幾題 sealed holdout；這只能降低洩漏風險，不能證明完全沒有訓練污染。
6. 結論寫得比證據大：「我的 10 題在某入口退步」是可審計句子；「供應商把模型砍爛」不是。

截至 2026 年 9 月，OpenAI 使用者要多記哪些欄位？

若你在 Responses API 執行 Shadow Eval，至少保存請求的 model 與回應的 model、service_tier、usage.input_tokens_details.cached_tokens、usage.output_tokens_details.reasoning_tokens、request ID、UTC 時間、狀態與延遲；欄位只在回應實際提供時記錄。reasoning effort 的可用值與預設值依模型而異，測試時要明確指定並以當天模型頁為準。

以 GPT-6 Astra 為例，應直接查閱最新的官方模型頁，不要從舊文章猜 snapshot 或設定。AlphaLab 的GPT-6 Astra 跨入口指南負責解釋 ChatGPT、Work、Codex 與 API 的產品邊界；本文的工作表則負責記下「你實際走了哪個入口」。

公開狀態頁是輔助證據，不是無罪證明：它呈現彙總狀態，未必涵蓋你的模型、地區、方案或功能。若要向支援團隊回報，附 UTC 時間、request ID、入口、model、tier、錯誤與延遲分布，比「今天很笨」更容易被查。

常見問題 FAQ

1. 10 題真的足以證明 AI 模型降智嗎？

不能。10 題是貼近個人工作流的早期警報器，只能支持「這組任務、這個入口、這段時間」的結論。要做供應商級或全域能力判斷，需要更大的代表性樣本與統計設計。

2. 為什麼每題先跑三次？

因為一次太容易受隨機變異影響。三次是兼顧成本的 pilot heuristic，不是通用樣本數定理；三次結果不一致，就增加次數或改善題目與 rubric。

3. 我只有 ChatGPT 訂閱，沒有 API，也能做嗎？

可以，但歸因上限較低。用全新對話、固定附件、同一入口與相近時段重跑，保存畫面與可見設定；看不到 snapshot、effort 或路由時就標記不可見，只能描述產品體驗。

4. 模型名稱相同，不就代表版本相同嗎？

不一定。alias 可能是會移動的產品名稱。若要主張已鎖定基礎模型版本，請使用官方當下明列且可呼叫的 dated snapshot；否則只描述 alias 行為。請同時記 requested 與 returned model，也不要把回傳字串解讀成官方未承諾的內部版本。

5. 快取 miss 會讓答案變差嗎？

不能只靠 miss 下結論。快取欄位先用來解釋輸入處理的延遲與成本；答案品質仍要回到同題、同設定的 rubric 與重複結果。

6. status 頁全綠，就能排除塞車嗎？

不能完全排除。公開狀態是彙總訊號，你仍要看自己的錯誤、延遲、模型、tier、地區與 request ID；但也不能因個人變慢就反推全站故障。

7. 可以全交給另一個 AI 盲評嗎？

可以輔助，不能不校準。先用 deterministic tests，主觀題再讓 judge 做 A/B 與 B/A 雙順序評分；拿一小批人工標註檢查它是否偏好位置、篇幅或特定語氣。

8. 什麼情況值得公開說「回歸」？

當範圍寫得夠精確。至少說明題庫、日期、入口、模型／snapshot、設定、重複次數與失敗類型，並公開原始 paired 結果。較穩妥的句型是：「在這組任務與控制條件下，我觀察到可重複的回歸。」

給新手的 7 點檢查清單

1. 從真實工作挑 10 題，不臨時出題。
2. 先寫成功條件與重大失敗，再看答案。
3. 保存 prompt、附件、工具與設定的 hash。
4. 首日與候選條件各跑三次，結果不穩就加跑。
5. 遮掉模型身份，做配對盲評。
6. 品質、可用性、成本分開記帳。
7. 先排除輸入、設定、服務與路由，再談模型回歸。

若這套 canary 之後要進入團隊部署流程，再把它接到AI 模型 Canary Promotion Controller，設定自動 gate、hold／promote／rollback 與稽核紀錄；個人版 Shadow Eval 的任務，是先把可重跑的證據做對。