如何偵測 Claude 效能下降(附真實數據)
人們常說 Claude 在每次發布後幾週會變得不那麼聰明。
人們常說 Claude 在每次發布後幾週會變得不那麼聰明。一位開發人員在 Claude Opus 5.5 發布後的第一週開始計時 30 天,使用固定的問題、固定的 Claude Code 和公開規則,結果顯示了為什麼以前沒有人知道,以及為什麼您的代幣計數是關鍵。結論:SHIP IT。
本影片重點
- Claude 在發布後變得不那麼聰明:理論與零日計時相遇
- 即時效能下降:Opus 5.5 從發布週開始的 30 天計時
- 如何捕捉效能下降:78 個有時答對的問題
- 它能看到什麼:7.5 分,代幣計數先變動
- 盲點:Opus 5 替換和 8 個錯誤的答案鍵
翻譯文字稿
譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。
Claude 在發布後變得不那麼聰明:理論與零日計時相遇
0:00 大家都知道 Claude 在發布後幾週會變得不那麼聰明。 所以一位開發人員從發布週開始對 Opus 5.5 進行計時, 計時結果顯示,目前還沒有人能知道真相。 在這段影片中,有三個問題。 你如何捕捉到效能下降? 這個量測儀能看到什麼? Anthropic 又怎麼說? 還有倉庫裡的其中一行致謝詞讓我捧腹大笑。
0:20 我會在最後提到它。 今天是 9 月 30 日星期三,這是 The Daily Diff。 今天有三個故事,其中最主要的是一個名為 live nerf 的 GitHub 倉庫。
即時效能下降:Opus 5.5 從發布週開始的 30 天計時
0:30 數月以來,人們一直說 Anthropic 在模型發布後會悄悄地降低其效能。 常見的理論是模型被壓縮,或者以相同的名稱使用較小的模型, 或者只是思考減少。 這個倉庫稱到目前為止的所有爭論都是「感覺對感覺」。 Opus 5.5 於 9 月 22 日發布, 一週前我告訴過你它在獨立排行榜上名列前茅,同時寫的字數是中位數模型的三倍。 發布兩天半後,一位名叫 ninja hawk 的開發人員開始計時, 每天一次,持續 30 天,日誌不能被編輯。
0:59 Hacker News 的討論串達到了近 800 個讚,並像團隊聊天一樣分化。一位評論者說,在絕大多數報導的案例中,模型效能下降並非真實存在。 另一位說人們只是習慣了新的智慧水平。 而一位 Claude Code 的超級用戶現在每次都會關閉「為此會話評分」的彈出視窗, 因為給 Claude 評分似乎讓它變得更糟。 同行審查。所以,問題一,你如何捕捉到效能下降? 你從大約 2300 個困難的考試問題開始, Opus 在第一次嘗試時答對了 93%,
如何捕捉效能下降:78 個有時答對的問題
1:27 這對於偵測器來說是無用的,因為它總是答對的問題不可能分數下降。 97% 的問題總是對或總是錯, 而它只有時會答對的 78 個問題組成了評測小組。 相同的提示,沒有工具,並且使用精確匹配評分,沒有 AI 評判, 因為評判也會漂移。 它通過無頭的 Claude Code 在 Max 訂閱上運行, 因為 API 版本的價格大約是每月 1600 美元。 Claude Code 版本被固定了,因為用倉庫的話來說,
1:55 改變的測試套件看起來與改變的模型完全一樣。 統計數據來自 Anthropic 的 Evan Miller 所撰寫的論文「為評估添加誤差棒」。 所以 Anthropic 自己的數學現在正在審核 Anthropic,這是將服務條款引用回客戶支援的學術版本。 問題二,它能看到什麼? 每十天窗口,下降約七點五分。 為了證明這個裝置有效,作者故意降低了 Claude 的努力程度。 中等努力使輸出減少了大約四分之一,分數只減少了四分。
它能看到什麼:7.5 分,代幣計數先變動
2:19 低度努力使輸出減少了近三分之二, 減少了八分。 這是值得借鑑的部分。 思考減少會先體現在代幣計數上,然後才體現在答案中。 所以固定你的模型版本,記錄每個任務的輸出代幣, 並保留一些你自己的固定問題。 如果你的代理突然寫得更短,請在查看 Reddit 之前檢查你的日誌。 這是誠實的部分。
2:43 悄悄地換入舊版 Opus 5 對於裝置來說變化太小而無法檢測,並且 readme 文件在一開始就這麼說了。 審核還發現了八個看起來錯誤的答案鍵, 所以效能下降偵測器在發現效能下降之前先發現了基準測試中的錯誤。 問題三,Anthropic 怎麼說?
盲點:Opus 5 替換和 8 個錯誤的答案鍵
2:54 去年,在收到一波投訴後,Anthropic 發布了一份事後分析報告。 報告說,引用一下,我們從不因需求、 一天中的時間或伺服器負載而降低模型品質。 這篇貼文也承認有三個錯誤導致 Claude 效能下降,並且近三分之一的
Anthropic:我們從不降低模型品質
3:08 Claude Code 用戶至少一次連線到錯誤的伺服器。 所以投訴是真實的,原因出在錯誤, 這就是為什麼倉庫警告發布週可能是最糟糕的一週。 30 天中已經過了 6 天。 第一個可能檢測到的時間大約落在 10 月 24 日, 所以誠實的答案是沒有人知道,包括那些曾經確信的人。 說到沒有人發布的數字。 Lighthouse Reports 和荷蘭報紙 Trouw 發現絕大多數的
3:35 歐洲資料中心對其用電和用水量保密, 儘管歐盟法規已要求報告三年。 在荷蘭,不到四分之一的資料中心會公開數據。 僅一個微軟資料中心就使用了荷蘭大約百分之一的電力。
資料中心對其數據保密;Backblaze 公開數據
3:46 同時,Backblaze 又做了無聊的事情。 其季度硬碟統計數據涵蓋了大約 35 萬個硬碟, 故障率上升到 1.73%, 是最近一段時間的最高點。 三個 Seagate 型號沒有故障。 這就是公開基準線的樣子,一個季度接著一個季度, 持續了 13 年。 現在,談到那行致謝詞。
4:16 自述文件承認這個倉庫的很大一部分是在 Claude 的幫助下編寫的, 而 Claude 正是正在被測量的模型。 所以 Claude 幫助建立了這個檢查 Claude 是否變笨的測量儀。 這就是為什麼評分器是簡單的函數。
致謝:Claude 幫助建立了衡量標準
4:25 用作者的話說,你不應該信任作者, 無論是人類還是其他。 如果你寧願閱讀這篇文章而不是聽我說,那麼每天早上都會有免費的 diff 發送到你的收件箱,網址是 the daily diff dot dev,連結在下方。 所以,今天對即時效能下降的評定。 SHIP IT。我會 SHIP IT,因為這是我見過第一個帶有 時間戳記、公開規則手冊和明確盲點的效能下降論點。 只是在 10 月 24 日之前不要引用它。 這就是今天的差異。
4:46 我是來自 Axrisi 的 Niko。 負責任地合併。
結論:SHIP IT,在 10 月 24 日前不要引用
4:51 SHIP IT。我會 SHIP IT,因為這是我見過第一個帶有 時間戳記、公開規則手冊和明確盲點的效能下降論點。 只是在 10 月 24 日之前不要引用它。 這就是今天的差異。 我是來自 Axrisi 的 Niko。 負責任地合併。
來源
- livenerfgithub.com
- Validationgithub.com
- Hacker Newsnews.ycombinator.com
- Anthropic postmortem (Sep 2025)www.anthropic.com
- Adding Error Bars to Evals (Evan Miller)arxiv.org
- Inspect (UK AI Security Institute)inspect.aisi.org.uk
- NL Timesnltimes.nl
- Hacker Newsnews.ycombinator.com
- Backblaze Drive Stats Q2 2026www.backblaze.com
- Hacker Newsnews.ycombinator.com



