新模型出來了要不要換？AI 功能答錯時，換模型多半沒用（2026 除錯懶人包）

新模型一發布，主管就問「我們要不要換？」你是不是也不知道怎麼回答？這篇帶你用 10 到 20 筆失敗案例，先找出錯在哪一層再決定！

新模型發布的隔天，主管在群組裡貼了一張排行榜截圖，問：「我們的客服助理要不要換？」

這個問題每隔幾個月就會出現一次。排行榜上的分數漲了，換模型看起來是最省事的升級：改一行設定，不用動架構。可是 OpenAI 自己在 2026 年 8 月發表的文章裡，給過一個反方向的數字：同一個模型在 ARC-AGI-3 上，只換掉外面那一層執行環境，讓它保留推理過程、會壓縮 context，分數就從 13.3% 變成 38.3%。模型沒換，成績差了將近三倍。

這一層模型以外的東西，現在大家叫它 harness：系統指令、檢索、工具、權限、驗證，所有把模型接到真實工作上的裝置。我在〈Coding Agent 怎麼選〉那篇談過它對 coding agent 的意義。放到你自己的 AI 功能上，結論更直接：你的 AI 功能答錯，錯多半出在模型以外的層，換模型碰不到。

所以「要不要換」之前，要先回答另一個問題：錯在哪一層？

快速回答 AI 功能答錯，錯多半出在模型以外的層，換模型碰不到。從收到問題到交出答案，要經過資料、檢索、context、模型、工具、驗證六層，換模型主要動到的是中間的模型那一層。新模型出來時，先拿 10 到 20 筆失敗案例做反事實檢查：原模型配人工找出的正確段落跑一組，新模型配原本的檢索結果跑一組。原模型拿到對的材料就答對的題目越多，越該先修檢索和 context。

AI 功能背後有六層管線：換模型只碰得到中間一層，材料與工具出錯換模型碰不到

一個 AI 功能從收到問題到交出答案，大致會經過六層。以文件問答為例：資料庫裡要有正確的文件；檢索要把對的段落找出來；段落要被放進模型看得到的 context；模型讀完材料作答；需要時呼叫工具，例如查訂單、算金額；最後有一道驗證，攔下引用錯誤或格式不對的答案。

這張圖裡，換模型能改善的只有藍色那一格。前面三層的錯，模型拿到的材料本身就有問題；後面兩層的錯，模型就算答對了，答案也可能在工具或驗證那一步壞掉。

這不是新發現。Google 的 Sculley 等人 2015 年在 NeurIPS 發表〈Hidden Technical Debt in Machine Learning Systems〉，裡面有一張後來常被引用的圖：真實的機器學習系統裡，模型程式碼只占中間一小塊，周圍是資料收集、設定、監控和服務架構。大型語言模型把中間那塊換成了更強的東西，周圍那一圈並沒有消失。

澳洲 Deakin 大學的 Barnett 等人在 2024 年整理了三個領域的 RAG（先檢索、再生成）專案，歸納出七個常見的失敗點。其中三個發生在模型拿到資料之前：文件裡根本沒有答案、正確文件排名太後面沒被送出、合併段落時被擠掉。剩下四個才和模型讀材料、組織答案有關。他們的另一句結論也值得記下來：這種系統要上線、被真實使用之後，才驗證得完整。

從系統紀錄排查六層訊號：檢索改善能減少 49% 漏找，別把 Context 缺陷誤判成模型太弱

同一句錯話，要怎麼分辨錯在哪一層？看當時系統留下的紀錄。下表是我會先看的地方。

檢索層的修法，常常比換模型便宜得多。Anthropic 在 2024 年 9 月公開過一個實驗：替每個切塊補上一句「這段在講整份文件的哪個部分」，再搭配關鍵字檢索，前 20 個結果裡漏掉正確段落的比例從 5.7% 降到 2.9%，少了 49%；再加上重新排序，降到 1.9%。整個改善都發生在模型之前，模型一行都沒動。

Context 層最容易被誤判成模型的問題。Liu 等人 2023 年在 arXiv 發表、2024 年刊於 TACL 的〈Lost in the Middle〉發現，相關資訊放在長 context 的中段時，模型的表現明顯比放在開頭或結尾差。2025 年 7 月，向量資料庫公司 Chroma 測了 18 個模型，結論更不客氣：輸入越長，表現越差，連很簡單的任務也一樣；只要多放一段「看起來相關、其實不對」的干擾文字，表現就會下降。他們在長對話記憶的測試裡比較了兩種提示：完整版平均約 11 萬 3 千個 token，只留相關內容的版本約 300 個 token，後者的表現一致較好。

這兩份研究對「要不要換模型」的意義是：新模型的 context 視窗再大，把整份文件塞進去也不會自動變準。Context 這一層要怎麼整理，是〈Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）〉那篇的主題；這篇只需要記得，這一層的錯，換模型只能修掉一部分。

用 10 到 20 筆失敗案例做反事實檢查：分組對照材料，避免單看新模型高估效益

判斷錯在哪一層，最有效的方法是切開管線，各自換掉一個條件。我把它叫作反事實檢查：如果模型拿到的是對的材料，它還會錯嗎？如果材料不變、只換新模型，它就會對嗎？

想驗證的三件事

1. 把正確段落直接交給原模型，可以把「錯在模型之前」的案例分出來。原模型拿到對的材料就答對，代表問題在資料、檢索或 context。
2. 新模型在原本的檢索下，修不好大部分檢索層的錯。材料沒送到，模型再強也無從答起。
3. 兩組的結果合起來看，比任何一組單獨看更能決定下一步。單看新模型修好幾題，會高估換模型的價值。

前提假設

先準備 10 到 20 筆真實的失敗案例，每一筆留下：使用者的問題、預期答案、當時檢索到的段落、送進模型的完整 context、工具呼叫紀錄。只留最後一張答案截圖不夠，排查需要的是系統當時看到了什麼。然後每一筆跑兩組：

如果某一題找不到「正確段落」，文件裡根本沒有答案，這題直接記成資料層的問題，不必跑。

案例表大概長這樣（示意，以公司內部的人資問答助理為例）：

思路與程式碼

讀完兩組的結果，每一題會落在下面四格之一。

下面的程式是判讀邏輯的骨架，三段依序貼進同一個檔案，用 Python 3 直接跑，不需要安裝任何套件。真實專案裡，answer_ok 要換成呼叫你的系統、再用評分規則比對預期答案；這裡為了讓你不必花 API 費用也能跑，用模擬資料代替。以下數字全部是示意，每一題的「真正原因」與答對機率都是我設定的，用來說明怎麼讀結果，不代表任何真實系統。

第一段設定 20 筆失敗案例的真正原因，以及兩組在各種原因下答對的機率。真實專案裡你不會知道這一欄，這正是實驗要幫你推回來的東西。

import random
from collections import Counter

# Hidden root cause of each failed case (unknown in a real project; used only by the simulation).
CASES = ["data"] * 3 + ["retrieval"] * 7 + ["context"] * 4 + ["model"] * 4 + ["tool"] * 2

# Chance that each arm answers correctly, by root cause. Assumptions, not measurements.
# A = old model + correct passage pasted in by hand; B = new model + the old retrieval.
P_PASS = {
    "data":      {"A": 0.0, "B": 0.0},   # the right passage does not exist anywhere
    "retrieval": {"A": 0.9, "B": 0.1},   # the right document never reaches the model
    "context":   {"A": 0.9, "B": 0.5},   # it arrives, buried in a long context
    "model":     {"A": 0.1, "B": 0.7},   # the material is fine, the reasoning is not
    "tool":      {"A": 0.1, "B": 0.1},   # the tool call fails either way
}

第二段是兩個函式。answer_ok 決定某一組有沒有答對，註解裡寫了真實版本要怎麼改；verdict 就是上面那張四格表。

def answer_ok(cause: str, arm: str, rng: random.Random) -> bool:
    # Real version:
    #   arm A: out = call_model(OLD_MODEL, question, context=gold_passage)
    #   arm B: out = call_model(NEW_MODEL, question, context=retrieve(question))
    #   return grade(out, expected)
    return rng.random() < P_PASS[cause][arm]


def verdict(a: bool, b: bool) -> str:
    if a and not b:
        return "fix retrieval/context"
    if b and not a:
        return "new model helps"
    if a and b:
        return "either; pick the cheaper"
    return "look at data/tool/verify"

第三段跑完 20 題，印出每一題的結果和四格的統計。

rng = random.Random(7)
rows = []
for i, cause in enumerate(CASES, 1):
    a, b = answer_ok(cause, "A", rng), answer_ok(cause, "B", rng)
    rows.append((i, cause, a, b, verdict(a, b)))
for i, cause, a, b, v in rows:
    print(f"{i:>2}  {cause:<9}  A={'pass' if a else 'fail'}  B={'pass' if b else 'fail'}  -> {v}")
print(Counter(r[4] for r in rows))
print("A pass:", sum(r[2] for r in rows), " B pass:", sum(r[3] for r in rows))

結果

印出來的 20 題整理成四格：

模擬資料，示意。

只看 B 組，新模型修好了 20 題裡的 8 題，四成。如果你只做這一組，很容易得出「換模型有效」的結論，然後去簽一份更貴的合約。

把 A 組放進來，畫面就不一樣了。8 題裡有 4 題，原模型拿到正確段落也答得出來，換模型只是另一條路；真正非換模型不可的只有 4 題。另一邊，有 7 題是「材料對了就會答、換模型也救不了」，這 7 題的修法在檢索和 context。還有 5 題兩組都錯，3 題是文件裡根本沒有答案，2 題是查詢工具壞了，這些錯換什麼模型都不會消失。

回到一開始的三件事。第一，A 組答對 11 題，其中 10 題的真正原因在檢索或 context，1 題在模型：分得出來，但會有誤差，所以四格表拿來排優先順序，別當成判決書。第二，7 題檢索層的錯，新模型只修好 1 題。第三，單看 B 組的 8 題會高估換模型的價值，合起來看，該先做的是修檢索。

你可以改 P_PASS 試試看，例如把檢索層的案例從 7 題改成 2 題、模型層改成 9 題，四格的分布就會倒過來，換模型變成合理的第一步。這個實驗回答的問題很窄：對你的這批失敗案例，下一份工程時間該花在哪一層。新模型整體好不好，它不管。

新模型評估的實務流程：先跑反事實檢查並重測全部案例，比綜合成本而不只比分數

一套可以每次重複的流程，比一次漂亮的評估更有用。我會這樣安排：

平常就累積失敗案例。使用者回報、按了倒讚、人工抽查發現的錯，都存起來，連同當時的檢索結果、完整 context 和工具紀錄。沒有這份紀錄，新模型出來時你只能拿排行榜做決定。案例集多大才夠、怎麼避免反覆挑題造成的偏差，可以看〈統計與實驗設計〉。

先跑反事實檢查，再談採購。10 到 20 題就能看出大方向。A 組答對的比例高，先修檢索和 context；A 組答錯、B 組答對的比例高，換模型才有根據。

新模型要跑全部案例，包括原本答對的。換模型也會帶來新的錯。史丹佛的 Chen、Zaharia 與 Zou 比較過 GPT-4 在 2023 年 3 月和 6 月的兩個版本，判斷質數的正確率從 84% 掉到 51%，程式碼的格式錯誤也變多。OpenAI 在 2025 年 4 月推出 GPT-4.1 時，在官方提示指南裡寫明，新模型比前一代「更緊、更照字面」遵循指令，要發揮效果需要調整既有的提示。原本答對的題目會不會變錯，只有重跑才知道。

評估修復的綜合成本，不單看基準分數。新模型多修好幾題，換算成每個月多花多少 API 費用、延遲變長多少；修檢索要花幾天工程時間、之後誰維護。把幾種修法放在同一張表：

每次修正都留版本和原因。下一次出錯，才查得到當時為什麼這樣改，不必重新猜一遍。

破除三個常見誤解：排行榜分數高不代表系統變好，視窗變大仍需檢索，新模型也可能帶來新錯

誤會一：排行榜分數高，我的系統就會變好。排行榜量的是模型在固定題目上的表現。你的系統答錯，如果錯在檢索或工具，分數再高也碰不到。

誤會二：Context 視窗夠大，就不用做檢索了。Chroma 的實驗剛好相反：同樣的資訊，放在十幾萬 token 裡，比放在幾百個 token 裡更容易被漏看。視窗變大，選材料的工作還在。

誤會三：換新模型最差也就是沒進步。模型更新會改變它理解指令的方式，原本調好的提示可能突然失效。這是為什麼要拿原本答對的題目一起重跑。

可以直接換模型的四種例外條件：材料正確仍答錯、成本更省，或原模型即將停止服務

這套做法也有邊界。下面幾種情況，我會直接換：

• 反事實檢查的結果，大部分落在「A 組答錯、B 組答對」那一格。材料已經對了，原模型就是不夠。
• 新模型更便宜或更快，而重跑全部案例的結果不比原本差。這時候換模型省的是錢，品質不必賭。
• 原模型要停止服務了，你沒有選擇，只剩下「換哪一個」的問題。
• 換模型之後，可以拿掉一些外層的補丁。Anthropic 談 harness 設計時說過，harness 的每一個元件，都編碼了一個「模型自己做不到什麼」的假設；模型變強，這些假設要重新檢查。有些為舊模型加的規則、重試和檢查，新模型可能已經不需要。

剩下的情況，先找最弱的那一層。如果你的四格表裡藍框那一格最多，下一步可以讀〈Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）〉，從模型看到了什麼開始修。

新模型出來時，別拿排行榜問自己，拿你的失敗案例去問它。

模型升級前，先拿出失敗在哪一層的證據。

常見問題

什麼是反事實檢查？

以失敗案例為基準，分兩組各換一個條件，看錯在哪一層。A 組用原模型，配人工找出的正確段落；B 組用新模型，配原本的檢索結果。A 對 B 錯，修檢索或 context；A 錯 B 對，換模型有根據；兩組都對，挑便宜好維護的；兩組都錯，查資料、工具和驗證。結果會有誤差，拿來排優先順序，別當成判決書。

什麼情況可以直接換模型？

四種情況可以直接換：反事實檢查的結果大多落在「原模型拿到正確段落還是答錯、新模型答對」；新模型更便宜或更快，重跑全部案例的結果不比原本差；原模型要停止服務了；換模型後能拿掉外層的規則與補丁。換完之後，為舊模型加的規則與檢查可以重新評估是否保留。

換新模型，原本答對的題目會變錯嗎？

會。史丹佛的 Chen、Zaharia 與 Zou 比較 GPT-4 在 2023 年 3 月和 6 月的兩個版本，判斷質數的正確率從 84% 掉到 51%。OpenAI 推出 GPT-4.1 時也在提示指南寫明，新模型更照字面遵循指令，既有提示要調整。所以新模型要跑全部案例，包括原本答對的。

RAG 答錯時，要先查哪一層？

先查模型拿到資料之前的三層。Barnett 等人 2024 年整理 RAG（先檢索、再生成）專案的七個失敗點，有三個發生在這裡：文件裡沒有答案、正確文件排太後面沒被送出、合併段落時被擠掉。依序看來源文件的版本、正確文件在不在候選結果裡、段落在 context 的位置。

延伸閱讀

• Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）
• Claude Code、Codex、Gemini CLI 怎麼選？2026 三大 AI Coding 工具完整比較
• RAG、Workflow、Agent 差在哪？什麼時候真的需要 Agent？（2026 完整比較）
• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）

參考資料

Harness 與系統

• OpenAI, Codex as a platform: build on the open agent harness（2026-08-19） https://developers.openai.com/blog/codex-as-a-platform
• Anthropic, Harness design for long-running application development（2026-03-24） https://www.anthropic.com/engineering/harness-design-long-running-apps
• Sculley, D., Holt, G., Golovin, D., et al., Hidden Technical Debt in Machine Learning Systems（NIPS 2015） https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
• Barnett, S., Kurniawan, S., Thudumu, S., Brannelly, Z., & Abdelrazek, M., Seven Failure Points When Engineering a Retrieval Augmented Generation System（CAIN 2024；arXiv 2401.05856） https://arxiv.org/abs/2401.05856

檢索與長 context

• Anthropic, Introducing Contextual Retrieval（2024-09-19） https://www.anthropic.com/engineering/contextual-retrieval
• Liu, N. F., Lin, K., Hewitt, J., et al., Lost in the Middle: How Language Models Use Long Contexts（arXiv 2307.03172, 2023；Transactions of the ACL 12, 157–173, 2024） https://aclanthology.org/2024.tacl-1.9/
• Hong, K., Troynikov, A., & Huber, J.（Chroma）, Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025-07-14） https://www.trychroma.com/research/context-rot

換模型的風險

• Chen, L., Zaharia, M., & Zou, J., How Is ChatGPT's Behavior Changing Over Time?（Harvard Data Science Review 6.2, 2024；arXiv 2307.09009） https://hdsr.mitpress.mit.edu/pub/y95zitmz
• OpenAI, GPT-4.1 Prompting Guide（OpenAI Cookbook，2025-04） https://developers.openai.com/cookbook/examples/gpt4-1_prompting_guide