1M context 看起來很猛,但真正該量的是什麼?
最近看到一篇 DeepSeek V4 的實測文,裡面幾個數字很吸睛:500k 字摘要約 1 分鐘、200 行 bug 30 秒定位、50k 行 codebase 可以回答架構問題,還有 needle-in-haystack 的 9527 測試。
我第一反應其實是,這些都值得記錄,但還不能直接當成"模型真的可用"的證據。因為這些測試大多是單次成功,工程現場真正怕的是波動。
我現在會看三個指標
第一個是穩定命中率,不是單次命中。
同一題跑 20 次,統計 pass rate。像 9527 這種長文找針題,我會同時改位置、改干擾句、改提問方式。只要從 20/20 掉到 13/20,這個能力在 production 就要打折。
第二個是長任務退化曲線。
很多模型在前 200k token 很穩,拉到 600k 後開始掉。做法很土但有效:固定同一批任務,分 100k、300k、600k、900k 四檔去跑,觀察正確率和 latency 一起變化。
第三個是修 bug 的可重現性。
30 秒找到 bug 很亮眼,但我更在意「修完會不會引入新錯」。我會加一組 regression smoke test,至少跑 10 個核心 case,並記錄修前/修後的 fail count。
一個常被忽略的反例
我自己踩過一次:模型能正確描述 40k 行專案的模組關係,但一要求它改動跨模組 interface,失敗率直接飆高。也就是說,"看得懂" 和 "改得對" 是兩個能力。這也是為什麼只看架構問答會高估模型。
所以我現在會把評測拆成兩層:
- Read-only(摘要、檢索、架構理解)
- Write-back(修 bug、改 API、重構)
兩層分開量,才不會被漂亮 demo 帶著走。
如果你最近也在評估 V4 或其他 1M context 模型,建議先做一版自己的 checklist。工具會變,測法要留在手上。
作者:十年大博士