Anthropic 再次說明：八月到九月初，Claude 確實出問題了。
Anthropic 今天發布了一份詳細的技術報告，解釋了三個基礎設施錯誤如何導致 Claude 的回答品質急遽下降。
雖然他們似乎說了些實話，但這份報告來得有點太晚了。
Claude 究竟怎麼了？
從八月初開始，使用者就抱怨 Claude 的回答變差了。
起初 Anthropic 難以判斷這到底是正常的使用者回饋波動，還是真的出了問題。
但隨著投訴越來越多，他們終於在八月底開始調查。
Anthropic 在報告中強調：
我們從不會因為需求量、時間段或伺服器負載而降低模型品質。
使用者遇到的問題完全是由基礎設施錯誤造成的。
調查發現了三個相互重疊的錯誤，這讓診斷變得異常困難。
Anthropic 聲稱：現在，這三個錯誤都已經修復了。
三個令人頭痛的錯誤
Claude API 事件的說明性時間軸。黃色：檢測到問題，紅色：惡化程度加劇，綠色：修復已部署。
第一個錯誤：路由錯誤
8 月 5 日，部分 Sonnet 4 的請求被錯誤地路由到了為即將推出的 100 萬 token 上下文視窗配置的伺服器。
這個錯誤最初只影響 0.8% 的請求。
但 8 月 29 日的一次常規負載平衡調整，意外地讓更多短上下文請求被路由到了長上下文伺服器。
最嚴重的時候，8 月 31 日某個小時內，16% 的 Sonnet 4 請求都受到了影響。
更糟的是，路由是「黏性的」：一旦請求被錯誤的伺服器處理，後續的對話也會繼續被同一個錯誤的伺服器處理。
第二個錯誤：輸出損壞
8 月 25 日，他們在 Claude API 的 TPU 伺服器上部署了一個錯誤配置。
這導致模型會莫名其妙地輸出一些不該出現的 token，例如在英文對話中突然出現泰文或中文字符，或者在程式碼中產生明顯的語法錯誤。
有使用者可能會在英文回答中看到「สวัสดี」這樣的泰文問候語。
這個問題影響了 8 月 25-28 日的 Opus 4.1 和 Opus 4，以及 8 月 25 日到 9 月 2 日的 Sonnet 4。
第三個錯誤：XLA:TPU 編譯器錯誤
8 月 25 日，他們部署了改進 token 選擇的程式碼，但無意中觸發了 XLA:TPU 編譯器中的一個潛在錯誤。
這個錯誤確認影響了 Claude Haiku 3.5，可能也影響了部分 Sonnet 4 和 Opus 3。
編譯器錯誤的技術細節
2024 年 12 月修補程式的程式碼片段，用於解決當溫度 = 0 時意外丟失 token 的錯誤。
這個錯誤最為棘手。
Claude 生成文本時，會計算每個可能的下一個詞的機率，然後隨機選擇。
在 TPU 上，模型運行在多個晶片上，機率計算發生在不同位置，需要在晶片之間協調資料。
問題出在混合精度算術上。
模型用 bf16（16 位元浮點數）計算機率，但 TPU 的向量處理器原生支援 fp32，所以編譯器會把某些操作轉換為 fp32 來優化效能。
這造成了精度不匹配：本該在最高機率 token 上達成一致的操作，因為運行在不同精度級別而產生分歧。最高機率的 token 有時會完全消失。
程式碼片段顯示了作為 8 月 11 日更改的一部分而合併的最小化重現器，該更改是 2024 年 12 月解決「錯誤」的根本原因；實際上，這是 xla_allow_excess_precision 標誌的預期行為。
他們在修復精度問題時，暴露了一個更底層的錯誤：近似 top-k 操作的問題。
這是一個效能最佳化，用來快速找到最高機率的 token，但有時會返回完全錯誤的結果。
顯示與開發該演算法的 XLA:TPU 工程師共享的底層近似 top-k 錯誤的重現器 Slack 訊息。該程式碼在 CPU 上運行時返回正確的結果。
這個錯誤的行為令人抓狂。
它會根據無關因素而改變，例如前後運行了什麼操作，是否啟用了除錯工具。
同一個提示詞，這次可能完美運行，下次就失敗了。
最終他們發現精確 top-k 操作已經沒有以前那麼大的效能損失了，於是改用精確演算法，並將一些操作標準化為 fp32 精度。
為什麼這麼難發現？
Anthropic 的驗證流程通常依賴基準測試、安全評估和效能指標。
工程團隊會進行抽查，先部署到小型「金絲雀」組。
但這些問題暴露了他們本該更早發現的關鍵缺陷。
他們的評估根本沒有捕捉到使用者報告的品質下降，部分原因是 Claude 往往能從孤立的錯誤中很好地恢復。
隱私實踐也造成了調查困難：內部隱私和安全控制限制了工程師訪問使用者與 Claude 互動的方式和時間。
這保護了使用者隱私，但也阻止了工程師檢查那些識別或重現錯誤所需的問題互動。
每個錯誤在不同平臺上以不同速率產生不同症狀，創造了令人困惑的混合報告，沒有指向任何單一原因。
看起來就像是隨機的、不一致的品質下降。
改進措施
Anthropic 承諾將做出以下改變：
更敏感的評估：開發能更可靠地區分正常和異常實現的評估方法。
更多地方的品質評估：將在真正的生產系統上持續運行評估，以捕捉類似上下文視窗負載平衡錯誤這樣的問題。
更快的除錯工具：開發基礎設施和工具來更好地除錯社群回饋，同時不犧牲使用者隱私。
他們特別強調，使用者的持續回饋至關重要。
使用者可以在 Claude Code 中使用 /bug 命令，或在 Claude 應用程式中使用「不喜歡」按鈕來提供回饋。
網友反應
雖然 Anthropic 的透明度值得讚賞，但使用者們的反應卻可以說是相當複雜。
Denis Stetskov(@razoorka) 表示能感受到巨大的改進：
我已經能感受到巨大的改進。無論你們修復了什麼，它都起作用了。
Rajat(@DRajat33) 讚賞了透明度：
感謝澄清和細節。透明度是讓公司與眾不同的東西，無論他們的產品如何。
但更多使用者對沒有補償表示不滿。
Alexandr Os(@iamavalex) 直接要求：
公布受影響帳戶列表並立即退款。我就是其中之一。
Conor Dart(@Conor_D_Dart) 質疑：
你們會給受影響的使用者退款或補償嗎？報告影響了很多人，你們的價格可不便宜。
The City Keeps Building(@TheCity777) 簡單直接：
我們的退款呢？
peermux(@peermux) 認為：
如果你承認在八月到九月之間沒有交付商定的產品，那麼你應該提供退款，或至少提供一個月的免費服務。這將展示誠意並有助於維持信任。
Baby Yoda(@grogu836) 表示失望：
我們不會因此獲得退款？難以置信。再也不用 Claude Code 了。
還有使用者指出問題可能還沒完全解決。
tuna(@tunahorse21) 說：
它很明顯還有錯誤，你們等了一個月才承認這個問題。
Daniel Lovera(@dlovera) 則提出了更進一步的質疑，認為短上下文請求在長上下文伺服器上表現變差，說明 Anthropic 實際上是在根據需求間接降低模型品質。
Thomas Ip(@_thomasip) 則總結了三個錯誤：
tldr：
錯誤 1 - 一些請求被路由到測試伺服器
錯誤 2 - 效能最佳化錯誤導致稀有 token 被分配了高機率
錯誤 3a - 精度不匹配導致最高機率 token 被丟棄
錯誤 3b - 近似 top-k 演算法完全錯誤
[1] 技術後期診斷報告: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues