Claude 再次解释：八月到九月初，它确实出问题了。
刚刚，Anthropic 今天发布了一份详细的技术报告，解释了三个基础设施 bug 如何让 Claude 的回答质量断崖式下降。
虽然他们像是说了些实话，但这份报告来得有点太晚了。
Claude 到底怎么了？
从八月初开始，用户就开始抱怨 Claude 的回答变差了。
起初 Anthropic 很难分辨这到底是正常的用户反馈波动，还是真的出了问题。
但随着投诉越来越多，他们终于在八月底开始调查。
Anthropic 在报告中强调：
我们从不会因为需求量、时间段或服务器负载而降低模型质量。
用户遇到的问题完全是基础设施 bug 导致的。
调查发现了三个相互重叠的 bug，这让诊断变得异常困难。
Anthropic 声称：现在，这三个 bug 都已经修复了。
三个让人头疼的 Bug
Illustrative timeline of events on the Claude API. Yellow: issue detected, Red: degradation worsened, Green: fix deployed.
第一个 bug：路由错误
8 月 5 日，部分 Sonnet 4 的请求被错误地路由到了为即将推出的 100 万 token 上下文窗口配置的服务器。
这个 bug 最初只影响 0.8% 的请求。
但 8 月 29 日的一次常规负载均衡调整，意外地让更多短上下文请求被路由到了长上下文服务器。
最严重的时候，8 月 31 日某个小时内，16% 的 Sonnet 4 请求都受到了影响。
更糟的是，路由是「粘性的」：一旦请求被错误的服务器处理，后续的对话也会继续被同一个错误的服务器处理。
第二个 bug：输出损坏
8 月 25 日，他们在 Claude API 的 TPU 服务器上部署了一个错误配置。
这导致模型会莫名其妙地输出一些不该出现的 token，比如在英文对话中突然蹦出泰文或中文字符，或者在代码中产生明显的语法错误。
有用户可能会在英文回答中看到「สวัสดี」这样的泰文问候语。
这个问题影响了 8 月 25-28 日的 Opus 4.1 和 Opus 4，以及 8 月 25 日到 9 月 2 日的 Sonnet 4。
第三个 bug：XLA:TPU 编译器错误
8 月 25 日，他们部署了改进 token 选择的代码，但无意中触发了 XLA:TPU 编译器中的一个潜在 bug。
这个 bug 确认影响了 Claude Haiku 3.5，可能也影响了部分 Sonnet 4 和 Opus 3。
编译器 bug 的技术细节
Code snippet of a December 2024 patch to work around the unexpected dropped token bug when temperature = 0.
这个 bug 最为棘手。
Claude 生成文本时，会计算每个可能的下一个词的概率，然后随机选择。
在 TPU 上，模型运行在多个芯片上，概率计算发生在不同位置，需要在芯片之间协调数据。
问题出在混合精度算术上。
模型用 bf16（16 位浮点数）计算概率，但 TPU 的向量处理器原生支持 fp32，所以编译器会把某些操作转换为 fp32 来优化性能。
这造成了精度不匹配：本该在最高概率 token 上达成一致的操作，因为运行在不同精度级别而产生分歧。最高概率的 token 有时会完全消失。
Code snippet showing minimized reproducer merged as part of the August 11 change that root-caused the “bug” being worked around in December 2024; in reality, it’s expected behavior of the xla_allow_excess_precision flag.
他们在修复精度问题时，暴露了一个更底层的 bug：approximate top-k 操作的问题。
这是一个性能优化，用来快速找到最高概率的 token，但有时会返回完全错误的结果。
Reproducer of the underlying approximate top-k bug shared with the XLA:TPU engineers who developed the algorithm. The code returns correct results when run on CPUs.
这个 bug 的行为令人抓狂。
它会根据无关因素而改变，比如前后运行了什么操作，是否启用了调试工具。
同一个提示词，这次可能完美运行，下次就失败了。
最终他们发现 exact top-k 操作已经没有以前那么大的性能损失了，于是改用精确算法，并将一些操作标准化为 fp32 精度。
为什么这么难发现？
Anthropic 的验证流程通常依赖基准测试、安全评估和性能指标。
工程团队会进行抽查，先部署到小型「金丝雀」组。
但这些问题暴露了他们本该更早发现的关键缺陷。
他们的评估根本没有捕捉到用户报告的质量下降，部分原因是 Claude 往往能从孤立的错误中很好地恢复。
隐私实践也造成了调查困难：内部隐私和安全控制限制了工程师访问用户与 Claude 交互的方式和时间。
这保护了用户隐私，但也阻止了工程师检查那些识别或重现 bug 所需的问题交互。
每个 bug 在不同平台上以不同速率产生不同症状，创造了令人困惑的混合报告，没有指向任何单一原因。
看起来就像是随机的、不一致的质量下降。
改进措施
Anthropic 承诺将做出以下改变：
- 更敏感的评估：开发能更可靠地区分正常和异常实现的评估方法。
- 更多地方的质量评估：将在真正的生产系统上持续运行评估，以捕捉类似上下文窗口负载均衡错误这样的问题。
- 更快的调试工具：开发基础设施和工具来更好地调试社区反馈，同时不牺牲用户隐私。
他们特别强调，用户的持续反馈至关重要。
用户可以在 Claude Code 中使用 /bug 命令，或在 Claude 应用中使用「thumbs down」按钮来提供反馈。
网友反应
虽然 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) 说：
它很明显还有 bug，你们等了一个月才承认这个问题。
Daniel Lovera(@dlovera) 则提出了更进一步的质疑，认为短上下文请求在长上下文服务器上表现变差，说明 Anthropic 实际上是在根据需求间接降低模型质量。
Thomas Ip(@_thomasip) 则总结了三个 bug：
tldr：
bug 1 - 一些请求被路由到测试服务器
bug 2 - 性能优化 bug 给稀有 token 分配了高概率
bug 3a - 精度不匹配导致最高概率 token 被丢弃
bug 3b - approximate top-k 算法完全错误
[1]技术后期诊断报告: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
