漂亮分數，先別急著上線
昨天在 review 一個支付風控服務的模型升級方案，團隊拿著 benchmark 表來報告，準確率多了幾個百分點，平均 latency 也在可接受範圍。我的第一個問題不是模型多聰明，而是：同一批 request，換一個 harness，結果還成立嗎？
Simon Willison 整理 GPT-6 Astra 的資料，剛好把這個問題放到檯面上。ARC-AGI 3 用 OpenAI custom Provider Adapter harness 跑到 99.9%，成本是 $19K；預設 harness 則是 62.7%，成本反而是 $26K。兩個數字都是真的，但它們測到的東西不完全一樣。Adapter 可以跨 request 保留 opaque reasoning state，也能在長對話做 compaction。換句話說，99.9% 不只是模型本體的成績，也包含一套更懂得餵模型、保存狀態、整理上下文的工作流。
這沒有什麼作弊不作弊的道德問題。Production 本來就會有 prompt template、retry policy、cache、tool calling、context compaction，甚至會為不同任務準備不同 routing。問題是報告 benchmark 時，必須把模型和 harness 的貢獻拆開，否則工程團隊會把工作流優勢誤認成模型能力，最後在正式流量上付學費。
我會把驗證拆成四層。
第一層，固定模型輸入，做 harness 對照。
先建立一份不可變的 evaluation corpus，包含原始 request、工具回傳、亂數 seed、時間戳和預期輸出。至少跑三組：預設 harness、custom adapter、最小化 stateless harness。模型版本、temperature、token budget、system prompt 全部鎖定。每組不只記最後答案，還要記每一步 request、response、reasoning state 是否存在、compaction 發生幾次，以及失敗後重試了什麼。
如果 custom adapter 從 62.7% 拉到 99.9%，那就再做一個 ablation：保留 state，但關掉 compaction；保留 compaction，但每次 request 清空 state；最後只保留最普通的多輪對話。這樣才知道提升來自長期狀態、上下文壓縮，還是其他隱藏設定。沒有 ablation 的高分，對後端工程師來說只是故事。
第二層，測分布外的反例，不要只重播官方題目。
ARC-AGI 3 的 99.9% 很吸引人，但金融服務真正怕的是邊界條件。我會另外準備幾種 corpus：欄位缺失、重複 webhook、順序顛倒、工具回傳格式改一個欄位、上下文超長、同一筆交易重送三次，以及刻意混入看似合理但互相矛盾的資料。每種至少數百筆，並保留人工標註的 failure category。
8-needle benchmark 顯示 Astra 在 256K 到 512K 是 100%，512K 到 1M 降到 96.3%。這種結果不能簡化成「context window 很大所以安全」。在我們的系統裡，長上下文通常意味著更多歷史交易、更多 tool output 和更多可能互相衝突的版本。我要看的不是平均正確率，而是隨 context length 增加，錯誤率、延遲和輸出 token 是否一起上升。若 96.3% 的錯誤集中在接近 1M 的特定格式，修 prompt 可能比換模型更有效。
第三層，把成本算成每個完成任務的成本。
Astra API 每百萬 input token 是 $10，output token 是 $50。只看單次呼叫價格會漏掉最貴的部分，因為 production 還有 retry、狀態保存、compaction、工具呼叫和人工 fallback。我的 dashboard 至少會有 input token、output token、request 次數、retry 次數、cache hit rate、每次任務總成本和成功任務成本。
例如兩個 harness 都完成 1,000 個風控 case，A harness 成功 900 個、每案平均花 $0.08，B harness 成功 990 個、每案平均花 $0.15。只看 token 費用會覺得 A 比較便宜，但算每個成功 case，A 是約 $0.089，B 是約 $0.152。若錯誤案例還會觸發人工審查，B 的實際總成本可能更高，也可能因為少放過一筆詐欺交易而更值得。成本必須跟業務錯誤代價放在同一張表。
ARC-AGI 3
的數據也提醒一件事：99.9% 的 $19K 不一定比 62.7% 的 $26K 更便宜，因為兩次測試的 harness 不同，測試行為也不同。$19K 不是 Astra 的固定價格，更不是任何團隊拿到 99.9% 的保證。要能重跑，必須把完整設定、資料版本、adapter commit、API 版本和成本明細一起存檔。
第四層，先做 shadow traffic，再談切換。
離線分數過關後，讓新模型和新 harness 在 production 流量旁路執行，不影響實際決策。抽樣保存 input hash、輸出差異、延遲 p50、p95、p99、token 用量和拒答率。對支付、授信、風控這些場景，還要做 replay，確認同一筆事件在重試和服務重啟後結果一致。opaque reasoning state 如果不能安全序列化、不能設定 TTL，或跨租戶邊界保存不清楚，直接上線就是埋雷。
我會設定三個 release gate。第一，核心任務成功率必須在 stateless baseline 之上，且分布外測試不能出現新的高嚴重度錯誤。第二，p99 latency 和每個成功任務成本要在預算內，例如成本上限設為 baseline 的 1.5 倍。第三，所有失敗都能從 trace 還原到模型、adapter、tool、retry 或 compaction 的責任邊界。做不到就先不上。
最後還是要留一個反例。報導也提醒，部分指數上 Astra 不一定勝過 Fable。這代表不能因為一個漂亮的 ARC 分數，就把所有 workload 都換成 Astra。模型選型應該是 task by task 的矩陣，包含正確率、錯誤嚴重度、延遲、可觀測性、token 成本和操作複雜度。
以前做支付系統時，最難查的事故通常不是服務完全掛掉，而是某個 retry 讓結果悄悄改變。AI workflow 也一樣。Benchmark 是入口，不是驗收報告。先把模型本體、harness 和業務流程拆開，讓每一層都可重跑、可觀測、可回滾，再來討論那個 99.9% 到底值不值得。
作者：鍵盤工人