在 8 月至 9 月初，由于三个独立的基础设施错误，Claude 模型的回应质量出现间歇性下降。这些问题包括上下文窗口路由错误、输出内容损坏以及一个复杂的编译器错误，导致部分用户请求被错误处理或生成异常输出。目前所有问题均已修复，公司承诺将通过更敏感的评估、更广泛的质量检查和更快的调试工具来防止未来发生类似事件。
我们需要明确声明：我们绝不会因为需求、一天中的特定时间或服务器负载而降低模型质量。用户报告的问题完全是由基础设施的错误引起的。
三个重叠的技术故障
问题的诊断尤其具有挑战性，因为三个错误的影响时间相互重叠，制造了混乱且矛盾的用户报告。
上下文窗口路由错误: 从 8 月 5 日开始，部分针对 Sonnet 4 模型的请求被错误地发送到为超长上下文窗口（1M token）配置的服务器上。由于路由具有“粘性”，一旦用户的请求被错误服务器处理，后续的对话很可能也会持续出错。该问题已于 9 月 4 日通过修复路由逻辑解决。
输出损坏: 8 月 25 日，一次错误的配置导致 TPU 服务器在生成文本时出现问题。这会使模型偶尔输出一些完全不相关的字符，例如在英文回答中插入泰语（“สวัสดี”）或在代码中产生明显的语法错误。该问题影响了 Opus 和 Sonnet 模型，并于 9 月 2 日通过回滚更改得到解决。
近似 top-k 编译错误: 8 月 25 日部署的一段代码意外触发了 XLA:TPU 编译器中的一个潜在错误。这个错误导致模型在选择下一个词时，有时会完全忽略概率最高的那个词，从而生成质量较低的回应。该问题影响了 Haiku 模型，并可能波及 Sonnet 和 Opus 的部分用户。
深入分析：一个复杂的编译器错误
为了提高效率，模型在计算中使用了一种名为“近似 top-k”的性能优化技术，用于快速找到概率最高的词。然而，这个技术本身存在一个深层错误。
这个错误的根源在于 不同精度的计算产生了冲突。模型在 16 位浮点数（bf16）下计算概率，但编译器为了优化速度，会将某些运算转换为 32 位浮点数（fp32）。这种精度上的不匹配，导致系统在判断哪个词是“概率最高”时出现分歧，最终使得最合理的词被意外地丢弃。
一个在 2024 年 12 月为修复另一个小问题而部署的临时补丁，无意中掩盖了这个更深层次的编译器错误。当我们在 8 月份移除这个临时补丁时，深层错误便暴露了出来。
为什么难以发现问题？
这些问题暴露了我们验证流程中的一些关键盲点。
- 评估不够敏感: 我们现有的基准测试和评估未能捕捉到用户实际感受到的那种零星、孤立的质量下降。
- 问题相互交织: 三个不同的错误在不同平台以不同频率出现，产生了大量混乱的报告，难以指向单一原因。
- 隐私保护限制: 出于对用户隐私的保护，工程师无法直接查看导致问题的具体用户交互内容，这使得复现和诊断错误变得非常困难。
未来如何改进？
为了防止类似事件再次发生，我们正在做出以下改变：
- 更敏感的评估: 开发新的评估方法，能更可靠地区分正常和有问题的模型实现，以便更早发现细微的质量问题。
- 更广泛的质量检查: 我们将在真实的生产系统上持续运行质量评估，以捕捉类似负载均衡错误这样的问题。
- 更快的调试工具: 我们将开发新的工具，以便在不牺牲用户隐私的前提下，更高效地调试来自社区反馈的问题。
用户的直接反馈至关重要。通过 Claude 应用中的“踩”按钮或 /bug 命令提交的具体问题案例，极大地帮助我们定位和解决了这些故障。