この動画は、AnthropicのClaude AIモデルが一時期性能低下を起こした技術的な問題について詳細に解説している。2024年8月から9月にかけて発生した3つの重大なインフラバグが重なり合い、ユーザーからの「Claudeがバカになった」という報告につながった事例を分析。コンテキストウィンドウのルーティングエラー、出力破損、TPUコンパイラーの問題という3つの技術的障害について、その原因と修正過程を詳しく検証している。また、Anthropicが研究用GPUを確保するためにAPI処理の計算コストを削減しようとした背景についても考察を加えている。
先週のAnthropic問題とその後の展開
先週な、わいはAnthropicの問題について深く掘り下げて取材したんや。特に、Claudeがめちゃくちゃアホになったみたいに振る舞ってたんがなあ。ありがたいことに、今回は珍しくAnthropicが実際に出てきて、そういうことが起こったって認めてくれたんや。
でもな、この認定をしたんは数日後のことで、この障害が何週間も続いてたことを3回も確認した後やったんやで。3つの別々の大きな問題が重なり合って、Anthropicのモデルのほとんどが長い間、めちゃくちゃアホになってもうたんや。そしてついに、裏で起こってる詳細を全部隠しとくんはベストな判断やないかもしれんって決めたんやな。
わいは先週の動画でこのことについてめちゃくちゃ文句言うたんやけど、Anthropicが反応してくれたんはほんまにありがたいことや。彼らは実際に時間をかけて、Claudeモデルをめちゃくちゃアホにしてしもうた最近の3つの問題について話し合う記事を出してくれたんや。
これはわいがAnthropicから見たことないレベルの透明性やで。普通、彼らの透明性っちゅうんは、研究とか、いろんなミスアライメントテストのベンチマークとかに限られてるんや。彼ら自身のインフラについて、裏でどんな問題があったかとか、実際にエンジニアがやってる仕事について語ったり、何が失敗したかとか、もっと重要なのは「なぜ」失敗したかについて、こんなに深く話すんを見たことがないんや。
めちゃくちゃはっきりしとくけど、Claudeモデルは今は期待通りに動いてるみたいやで。それでも返金はしてくれへんねんけどな、これはイラつくわ。そして将来また問題が起こらへんっちゅう保証もないんや、これは怖いでホンマ。このバグの深刻さと、どんだけ長く続いてたかを考えると、実際に何が悪かったんかの情報を得られたんはありがたいことや。
今日のスポンサー紹介
そうは言うても、わいも返金もらえへんし、誰かがわいのクラウドコードの請求書をカバーせなあかんのや。ちゅうことで、今日のスポンサーからの簡単な話をしてから、本題に入るで。
今日使ってるAIコーディングツールのほとんどには根本的な問題があるんや。それらは内側から作られてるんやなくて、外側から作られてへんっちゅうことや。何を言うてるんかって？
わいらが使ってるツールのほとんど、Cursor、クラウドコード、その他のツールは、既存のもんの内側に作られてるんや。CursorはVS Codeの内側に作られてる。クラウドコードはターミナルの内側に作られてる。それらは作られた殻によって制限されてるんや。
もしそうやなかったらどうやろう？もし誰かが全体のシェルを再考して、外側からよりええ体験を作って、ほんまにすごいもんを作れるとしたらどうやろう？その答えがあるんや、それが今日のスポンサー、Warpや。
彼らはオールインワンのエージェント開発環境を作ったんや。ターミナルからコードツールまで、その他いろいろ全部や。ターミナル体験そのものが魔法みたいやで。ターミナルでええ自動補完と履歴管理があるだけでもめちゃくちゃクールや。
そしてCommand Iを押すと、今度はコードに対していろんなことをするように頼めるんや。ホットキーでコンテキストを添付できる。ホットキーで全部をナビゲートできる。これはほんまにパワーユーザーと開発者、つまりわいらに焦点を当ててるんや。そしてその結果、根本的に違う感じがするんや。
これがどっかに詰め込まれてるっちゅう感じは全然せえへん。このやり方で構築するためのええ体験になるように、ツール全体が作られてるっちゅう感じがするんや。
これはわいがWarpを使って立ち上げた実際のプロジェクトや。これはわいの定番の画像生成ツールを作るように送った実際のプロンプトや。そして結果は素晴らしいで、なぜなら結果は全部GPT-5を使ってるからや。GPT-5を使わなあかんわけやないんやけどな。あなたが欲しがる主要なモデル全部にアクセスできるんや。でも、それらのモデルのどれでも150回の無料リクエストがもらえるっちゅう事実は、それだけでもかなりええ取引やで。
まだめちゃくちゃクールやで。何でも聞けるし、コマンドを実行する必要があったら実行するし、必要なかったらせえへん。明らかに、Next.jsやTailwindみたいな現代のツールも知ってるけど、知らんツールを使ってるんやったら、ルールやMCPサーバーに追加できるんや、それは全体にグローバルや。
だから、MCPサーバーについて学んだことに基づいて、bashコマンドを生成して実行させることができるんや。それはめちゃくちゃ便利やし、MCPが実際にわいにとって価値があるもんに感じさせてくれるんや。多くのエンジニアがWarpに移行してる理由があるんや。ただ単に生産性が上がるんや。今すぐsoy.link/warpでチェックして、コードtheoで最初の月を70%オフで手に入れてや。
3つの最近の問題のポストモーテム
最近の3つの問題のポストモーテムや。これはClaudeの応答を断続的に劣化させた3つのバグに関する技術レポートや。以下で、何が起こったか、なぜ修正に時間がかかったか、何を変更してるかを説明するで。
8月から9月初めにかけて、3つのインフラバグがClaude の応答品質を断続的に劣化させたんや。わいらは今、これらの問題を解決したし、何が起こったかを説明したいと思ってるんや。
なぜ今それをしたいんか、特に理由はないと思うで。絶対にないわ。
8月初めに、多くのユーザーがClaude からの劣化した応答を報告し始めたんや。これらの最初の報告は、ユーザーフィードバックの通常の変動と区別するんが困難やったんや。8月末までに、これらの報告の頻度と持続性の増加によって、わいらは調査を開始することになったんや。それが3つの別々の推論バグを発見することにつながったんや。
これについてはっきりさせとこう。バグは8月初めに始まったんや。彼らは全部ただの悪いフィードバックやと思い込んでて、性能が劣化したことを確認できるeval や ツールや チェックを何も持ってなかったんや。
LLMが非決定論的やっちゅうことはわいも知ってるで。これらのもんのどれでも結果を保証することはできへんっちゅう事実もよう分かってる。でも、バックグラウンドで十分なテストを実行してほしいと思うわ。ただのランダムチェックとか、1日に10回でも実行して、出力がどんな感じかを見て、正しい応答の規則性が下がってるかどうかを確認するとかな。
彼らは本当に、内部でベンチを実行してる人が誰もおらんかったんかな？劣化に気づく人がな？これは怖いで、ほぼ1ヶ月も続いてたんやからな。8月初めにはほとんど無視してて、8月末になってようやく頻度の増加によってもっと深く調べるようになったんや。
はっきり言うと、わいらは需要、時間帯、サーバー負荷によってモデル品質を下げることは絶対にないんや。
彼らは研究者により多くのGPUを与えるために、うっかりモデル品質を下げてしまうんやけどな。これについてはこれから話すで。でも、この場合にユーザーが報告した問題は、インフラバグだけが原因やったんや。
彼らがこれらのバグを引き起こした推論変更をしてた理由は、絶対に詳しく調べる価値があるで。でも最初に言うとくけど、わいの前回の動画での仮定のいくつかは間違ってたんや。
わいはかなり自信を持って、彼らがそれを修正しようとする試みがより多くのバグを引き起こしてるみたいやって主張してたんや。どうやらそうやなかったみたいやし、そのことについてはすぐに詳しく説明するで。
わいらはユーザーがClaude に一貫した品質を期待してることを認識してるし、インフラ変更がモデル出力に影響を与えへんことを保証するために極めて高い基準を維持してるんや。
今回の事件では、わいらはその基準に達してなかったんや。以下のポストモーテムでは、何が悪かったか、なぜ検出と解決がわいらが望んでたより長くかかったか、同様の将来の事件を防ぐために何を変更してるかを説明するで。
わいらは通常、わいらのインフラについてこのレベルの技術的詳細を共有することはないんや。そうやな、しとらんわな。でも、これらの問題の範囲と複雑さが、より包括的な説明を正当化したんや。同感や。
これをやってくれてありがとう。これが流行になってほしいわ。これらの詳細を隠す理由なんてないで。この情報を共有することで何かを失うわけやないんやから。なんでこんなに長く待ったんかわからんわ。投資ラウンドが終わるまで待ってたみたいに感じるで。マジで、この情報を隠すんは意味分からんわ。
Claudeを大規模に提供する方法
わいらはファーストパーティAPI、Amazon Bedrock、Google CloudのVertex AI を通じて、何百万人ものユーザーにClaude を提供してるんや。わいらはClaude を複数のハードウェアプラットフォーム、すなわちAWS Trainium、Nvidia GPU、GoogleのTPUにデプロイしてるんや。このアプローチは、世界中のユーザーにサービスを提供するために必要な容量と地理的分散を提供してるんや。
各ハードウェアプラットフォームには異なる特性があって、特定の最適化が必要なんや。これらの違いにもかかわらず、わいらはモデル実装に厳格な同等基準を持ってるんや。わいらの目標は、どのプラットフォームがリクエストにサービスを提供してても、ユーザーが同じ品質の応答を得られることや。
これは特に面白いで、なぜならわいは他のプラットフォーム全部がAnthropicより少し信頼性があるっちゅうことに気づいてるからや、特にこの問題の後はな。
もしOpen Routerについてまだ詳しくなくて、この動画を見てるんやったら、Open Routerについて詳しくなっとくべきや。例えば、Claude Sonnet 4で使える様々なプロバイダーを全部表示してくれるんや。ここで見ると、Bedrockが実際にかなり速くて、本当にええアップタイムを持ってることが分かるで。
今はちょっと違うけど、Bedrock側では修正したみたいやな。Google Vertexもかなり安定したスループットを持ってて、本当にええアップタイムや。そしてAnthropicは全プロバイダーの中で最も遅い速度を持ってるんや。今はアップタイムがまともやけど、それが常に保証されてるわけやないで。たった2日前でも、99.6%やったんやからな。ちょっと怖いわ。
そう、アップタイムは保証から程遠いんや。Open Routerでクールなんは、その時点でどれが最も信頼性があるか、または最も信頼性がないかに応じて、異なるプロバイダー間でトラフィックを自動的にバウンスしてくれることや。全部同じコストやから、誰が気にするんや。とは言え、Anthropicに問題があるときは、他のプロバイダーにホップできるし、そっちはおそらく問題ないやろう。
彼らのカバレッジに戻るけど、ここに面白い情報があるんや。特に、最後の文や。この複雑さは、インフラ変更が全プラットフォームと設定で慎重な検証を必要とすることを意味してるんや。
たぶん、これらの変更が実際に他のプラットフォームにも悪影響を与えたっちゅうことやな。確実やないけど、そうやない可能性は低いと思うで。
問題発生のタイムライン
彼らが説明するタイムラインがここにあるで。黄色は劣化、赤は、緑は修正を表してる、彼らが抱えてた3つの異なる問題についてや。
8月5日から、コンテキストウィンドウルーティングエラーがあって、Sonnet 4リクエストの約1%に影響してたんや。これは残酷やで。100回に1回の確率でリクエストが間違った場所にルーティングされて、パフォーマンスが悪くなるんやからな。
この理由は、クラウドモデルに100万トークンのコンテキストウィンドウが最近導入されたことやったんや。トークン量を増やしたり、コンテキストサイズを増やしたりしたときのモデルのパフォーマンスにあまり注意を払ってへんかったら、パフォーマンスは非常に速く下がるんや。これは「干し草の山の中の針」問題と呼ばれてるけど、それよりもずっと広範囲なんや。
モデルにより多くのコンテキストを与えると、その出力の品質が下がるんや。わいの仮定では、Claw Force Onnetの100万トークンバージョンは、おそらく一般的にそれほど理想的やないパフォーマンスを持ってたんやと思う。100万トークンを処理できるようにするために彼らが行った変更が、一般的にそれをよりアホにしたんや。そして、ここで詳しく説明されてるバグは、100万トークンをはるかに下回ってても、そのバージョンにトラフィックを送ってしまうっちゅうもんやったんや。
それから8月25日に、出力破損エラーが始まったんや。8月26日には、彼らがやったtop Kみたいなコードハックが色々なもんを壊してしもうたんや。8月29日に、ロードバランサーの変更によって、Sonnet 4リクエストの16%が間違ってルーティングされることになったんや。そして8月29日から9月4日まで、それらの問題が持続してたんや。
彼らは破損した出力問題を9月2日に少し早く修正することはできたけど、この他のバグは9月12日まで時間がかかったんや。だから、これらのもんを修正するのにしばらく時間がかかったんやな。
バグの詳細分析
これらの異なるバグについて話そうや。これらのバグの重複する性質が、診断を特に困難にしたんや。最初のバグは8月5日に導入されて、Sonnet 4への約1%のリクエストに影響してたんや。
8月25日と26日のデプロイメントから、さらに2つのバグが発生したんや。初期の影響は限定的やったけど、8月29日のロードバランシング変更が影響を受けるトラフィックを増加させ始めたんや。これによって、多くのユーザーが問題を経験する一方で、他のユーザーは通常のパフォーマンスを見続けることになって、混乱と矛盾する報告を生み出したんや。
第一の問題：コンテキストウィンドウルーティングエラー
3つの重複する問題や。最初のやつはコンテキストウィンドウルーティングエラーや。8月5日に、一部のsonnetリクエストが、今後の100万トークンコンテキストウィンドウ用に設定されたサーバーに誤ってルーティングされたんや。このバグは最初は1%のリクエストにしか影響してなかったんや。
でも8月29日に、日常的なロードバランシング変更が、意図せずに短いコンテキストリクエストが100万コンテキストサーバーにルーティングされる数を増加させてしもうたんや。
8月31日の最も影響を受けた時間では、Sonnetリクエストの16%が影響を受けたんや。この期間中にリクエストを行ったクラウドコードユーザーの約30%が、少なくとも1つのメッセージが間違ったサーバータイプにルーティングされて、劣化した応答を受けたんや。
Amazon Bedrockでは、誤ってルーティングされたトラフィックは全Sonnet 4リクエストの2%でピークを迎えて、8月27日から9月16日の間に、Google CloudのVertex AIでは0.004%未満のリクエストで不正なルーティングが影響したんや。
繰り返すけど、他のプロバイダーにも影響はあったけど、Anthropicよりもかなり少なかったんや。まだ陰謀論には早いで。わいの陰謀についてはすぐに話すから。
注目すべきは、一部のユーザーがより深刻な影響を受けたっちゅうことや。わいは間違いなくその時にめちゃくちゃ悪い体験をしてたから、ほぼ確実にその一人やったと思うで。
わいらのルーティングはスティッキーやから、リクエストが間違ったサーバーによってサービスされると、その後のフォローアップも同じ間違ったサーバーによってサービスされる可能性が高いっちゅうことを意味してたんや。
これは、コンテキストをキャッシュしてる場合に、それが読み込まれるのを長く待つ必要がないようにするためや。だから、わいがメッセージを送って、応答を得て、それからまた送ると、同じサーバーに当たる可能性が高いんや。
だから、すでに直前に言ったことのコンテキストをキャッシュしてて、それに応じて続けられる可能性が高いんや。それはええことや。でも、当たったサーバーが悪くて、今度は悪いサーバーにスタックしてしまうんはええことやないで。
解決：わいらは短いコンテキストと長いコンテキストのリクエストが正しいサーバープールに向けられることを保証するためにルーティングロジックを修正したんや。
わいらは9月4日に修正をデプロイしたんや。わいらのファーストパーティプラットフォームとGoogle CloudのVertex AIへのロールアウトは16日までに完了して、AWS Bedrockは18日までに完了したんや。
第二の問題：出力破損
問題その2、出力破損や。8月25日に、わいらはClaude API TPUサーバーに誤設定をデプロイして、トークン生成中にエラーを引き起こしたんや。
ランタイムパフォーマンス最適化によって引き起こされた問題が、コンテキストに対してめったに生成されるべきやないトークンに高い確率を時々割り当ててしもうたんや。例えば、英語のプロンプトに対してタイ語や中国語の文字を生成したり、コードで明らかな構文エラーを生成したりとかな。
LLMがどうやってもんを生成するかまだ理解してへんかったら、めちゃくちゃ簡単で、あんまりええやないけど概要を説明するで。
わいが「4つの異なるプログラミング言語でadvent of codeの解決策を生成して」みたいなプロンプトを取るとするやろ。これが13のトークンに分割されてるのが見えるはずや。トークンっちゅうのは、あなたのテキストとモデルが生成する出力の両方が分解される方法や。これらすべてを、このパラメータの巨大な混沌としたウェブにマッピングするためにな。
わいがちょうど単語を追加したことに注目してや、なぜならadvent of codeを間違って綴ってたからや。adventive codeやなくて、advent of codeやったんや。そして、これをadvent of codeに変更したにもかかわらず、まだ同じ数のトークンやった。それらはほとんど音節みたいなもんやけど、そんなにはっきりした分割やないんや。
今度は最後のスペースを削除してみよう。12になったで。クールやな。そして、出力するときも同じことが起こるんや。生成されたコードを取って、信頼できるモデルに投げてみよう。Grok 4 fast。もうあんまり速くないけどな。これをトークナイザーに投げてみよう。
そうすると、めちゃくちゃ多くに分割されてるのが分かるで、なぜならソースコードには多くのトークンがあるからや。次の部分を生成できるように分解できる方法が必要やからな。
だから、モデルの動作方法は、しばしば数十億、場合によっては数兆のパラメータを持ってるっちゅうことや。だから、「the cat elephant」みたいな単語があったら、入力を渡して、それから応答するのに最も可能性の高いトークンが何やと思うかを選ぶんや。これは、そのクレイジーなデータのウェブの内側に持ってるパラメータなんや。
そして、重み付けされた、他のすべてのトークンへのマッピングがあるんや。だから、これらの潜在的なパスのそれぞれに0.5、0.8、0.2みたいな数字があるんや。そして、現在の生成の他のすべてのトークンが、どのポイントがどこに向かうかの重みを変更するんや。
あなたは効果的に、前の用語に基づいて最も可能性が高いと思うことに基づいて、これを通って移動してるんや。だから、例えば「the cat sits on elephant」から、最も可能性の高い次のもんは「cat」やった0.8。catから色んな異なるもんにルーティングがあるけど、「sits on elephant」に行くのが最も可能性が高いと思ってるんや。
そして、それがテキスト生成が起こる方法のめちゃくちゃおおまかなやり方や。そして、これらの重みはすべて、前の入力に基づいてテキスト生成が最も可能性の高い方向に行く方向を決定する数学で決定されるんや。
だから、ここでの問題は、次のトークンが何であるべきかを決定する確率計算に悪い数学があったっちゅうことや。そして、その破損が、あなたの応答に特定の可能性の低いトークンを忍び込ませる結果になったんや。だから、英語の質問への英語の応答の真ん中で、応答の真ん中にこれらのランダムな文字を得るかもしれんのや。
この破損は、8月25日から28日のOpus 4.1と4へのリクエストと、8月25日から9月2日のSonnet 4へのリクエストに影響したんや。サードパーティプラットフォームはこの問題の影響を受けなかったんや。
これはここでは非常に重要な詳細やで、なぜなら今度はいくつかの陰謀に入り始めるからや。100万トークンのやつ以外に、Anthropicがしてた変更は全部、非常に特定の目標を念頭に置いてたんや。リクエストあたりの計算を減らすことや。
リクエストが取る計算量を減らす最も簡単な方法は、実際のモデルをよりアホにして、より安く動作させることや。理想的には、そんなことはせえへん。そして理想的には、Anthropicもそうやない。そして、めちゃくちゃはっきりさせとくけど、彼らはモデルをアホにするつもりはなかったんや。
彼らはリクエストごとに必要な計算を減らすつもりやったんや。そして、ここで陰謀が始まるんや。わいは他の動画でAnthropicについてちょっと話したことがあるんやけど、彼らは研究側のためにより多くのGPUが必要なんや。
研究チーム、モデル訓練チーム、データチーム、Anthropicの他のすべてのチームは、APIで構築してるわいら開発者とGPUを奪い合ってるんや。今、AnthropicはAPIからの負荷を処理するために必要なGPUの量を減らしたがってたんや。
もしリクエストに必要な計算で1%の勝利みたいなもんを見つけることができたら、それは彼らが自分らの研究のために解放したGPUがめちゃくちゃ多いっちゅうことや。そして、それは明らかに彼らの特定の重要な目標の一つなんや。どんなコストを払ってでも、わいらがAnthropicでやってる仕事のために、どうやってGPUを解放できるかっちゅうことや。
そして、彼らがしてる変更の数を見ると、このタイムラインがこんなに混沌としてる理由やけど、彼らがこれをどれだけ必死にやろうとしてるかがわかるで。あらゆる角度で彼らができる方法を見つけて、研究に使えるより多くの割り当てを解放することを期待して、必要な計算量を削減する方法を見つけてるんや。
それが、これらの変更の多くがちょっと急いで出されたような理由でもあるんや。これは問題3で特にはっきりすると思うで、approximate top K XLA TPU miscompilationや。
第三の問題：approximate top K XLA TPU miscompilation
8月25日に、わいらはテキスト生成中にClaudeがトークンを選択する方法を改善するコードをデプロイしたんや。この変更は、XLA TPUコンパイラーの潜在的なバグを意図せずに引き起こして、Claude Haiku 3.5へのリクエストに影響することが確認されたんや。わいらはまた、これがクラウドAPIのSonnet 4とOpus 3のサブセットにも影響を与えた可能性があると信じてるんや。サードパーティプラットフォームはこの問題の影響を受けなかったんや。
彼らは実際にこのバグをより詳細に分解してくれたんや。これらの問題の複雑さを説明するために、XLAコンパイラーバグがどのように現れたか、そしてなぜそれが診断するのに特に困難であることが証明されたかをここに示すで。
Claudeがテキストを生成するとき、可能な各次の単語の確率を計算して、それから確率分布からランダムに選択するんや。わいらは意味のない出力を避けるためにtop pサンプリングを使ってるんや、.99や.999みたいな閾値に達する累積確率を持つ単語だけを考慮するんや。
TPUでは、わいらのモデルは確率計算が異なる場所で起こる複数のチップで実行されるんや。これらの確率をソートするために、わいらはチップ間でデータを調整する必要があって、これは複雑なんや。
同じリクエストを同時に複数の異なるGPUで解決する問題は馬鹿げてるで。特に、中国への輸入禁止の混沌の歴史を考えるとな。多分また別の機会にビデオにするわ。絶対的な混沌やったで、ほんまに。そして、それがこれらのバグが起こり始めた層なんや。
2024年12月に、わいらのTPU実装が温度がゼロのときに最も確率の高いトークンを時々落とすことを発見したんや。わいらはこのケースを修正するためのワークアラウンドをデプロイしたんや。典型的なゼロ除算やな。これは、top P 0、つまり温度がゼロのときのハックや。
奇妙なjaxの問題のため、probs max 1よりも大きいprobsが可能なんや。それは全部falseや。だから、わいらは各行のトップlogitを手動で常に保存するんや。これは、温度を最低にしたときに処理するために彼らがした数学や。
温度は、テキスト生成中にモデルの予測のランダム性を制御するパラメータや。より高い温度は、より創造的で多様な出力につながって、フレージングの複数のバリエーションや、フィクションの場合は答えのバリエーションも可能にするんや。
より低い温度は、最も可能性の高いフレージングと答えに固執する、より保守的で決定論的な出力になるんや。温度は、ユーザーが言語モデルに、最も可能性の高い予測だけを選択するんやなくて、珍しい、一般的やない、または驚くべき単語の選択と順序を探求することを奨励できるようにするんや。
わいの小さな図でもう一度説明すると、最も可能性の高い異なるパスを下ってトークンをたどっていくと、それぞれのもんで最も高い数字を下っていくから、ちょっと決定論的なもんになるんや。ここのギャップはほとんど関係ないで。実際、2番目のやつがちょっと大きいな。だから、0.99989対0.99987やとしよう。
温度をゼロまで下げるか、温度の概念がなかったら、常に最良のやつを選ぶだけや。でも温度は効果的にランダム化させて、「いや、本当に近いもんを選ぶのもオーケーや」って言わせるんや。これで出力により多くのバリエーションを得ることができるんや。
ほとんどのモデルプロバイダーは、top Pや温度を1.0や0.8に設定してるんや。通常、この数学をするときにどのくらいの wiggle roomを与えるかを決定する数字や。そして、彼らがした間違いは、ここでの数学が壊れてるように見えることや。
根本原因は混合精度演算を含んでたんや。わいらのモデルは、16ビット浮動小数点数であるBF16で次のトークン確率を計算するんや。しかし、ベクタープロセッサは32ビットフロートであるFP32ネイティブなんや。XLAであるCPUコンパイラーは、いくつかの操作をFP32に変換することでランタイムを最適化できるんや。
その最適化パスは、デフォルトでtrueに設定されるXLA allow access precisionフラグによって守られてるんや。これがミスマッチを引き起こしたんや。
最も確率の高いトークンについて合意すべきやった操作が、異なる精度レベルで実行されてたんや。精度のミスマッチは、どのトークンが最も確率が高いかについて合意しないことを意味してたんや。これによって、最も確率の高いトークンが時々考慮から完全に消えてしまうことがあったんや。楽しいな。
8月26日に、わいらは精度の問題を修正し、top P閾値に達する確率の制限での処理方法を改善するために、サンプリングコードの書き直しをデプロイしたんや。
でも、これらの問題を修正する際に、わいらはより厄介なもんを暴露してしもうたんや。ここに、2024年12月に回避されてたバグを根本原因とした8月11日の変更の一部として出現した最小限の再現器を示す新しいテストファイルコードスニペットがあるで。
現実には、これはXLA allow access precisionフラグの期待される動作なんや。わいらの修正は、根本原因を解決したと信じてたため、12月のワークアラウンドを削除したんや。
これによって、最も確率の高いトークンを素早く見つけるパフォーマンス最適化である、approximate top K操作のより深いバグにつながったんや。近似は時々完全に間違った結果を返したけど、特定のバッチサイズとモデル設定でだけやったんや。12月のワークアラウンドが意図せずに問題をマスクしてたんや。
これは明らかに彼らがここに忍び込ませたSlackのスクリーンショットや。彼らはそれに応じて名前を付けてるな。Vercelで実行してるんかな？いや、Google Cloudやけど、Next.jsは使ってるんやな。すまん、そういう詳細について nerdy になってしもうた。
バグの動作はイライラするほど一貫してなかったんや。それは、前後にどんな操作が実行されたかとか、デバッグツールが有効になってたかどうかとか、関係のない要因によって変わったんや。
デバッグをオンにすると違う動作をするバグが最高やな。楽しいで。同じプロンプトが一つのリクエストでは完璧に動作して、次では失敗するかもしれんのや。
調査中に、わいらはまた、正確なtop K操作がもはや以前持ってた禁止的なパフォーマンスペナルティを持ってないことも発見したんや。
わいらはapproximateからexact top Kに切り替えて、FP32精度でいくつかの追加操作を標準化したんや。モデル品質は交渉の余地がないんや。だから、わいらは軽微な効率への影響を受け入れたんや。
彼らがついにこれを言葉にしてくれて嬉しいわ。わいはこのコメントを彼らに守らせるつもりや。
なぜ検出がこんなに困難やったか
なぜ検出がこんなに困難やったんや？わいらの検証プロセスは通常、安全性evalとパフォーマンスメトリクスと並んで、ベンチマークに依存してるんや。
エンジニアリングチームはスポットチェックを実行して、最初に小さなcanaryグループにデプロイするんや。これらの問題は、わいらがもっと早く特定すべきやった重要なギャップを暴露したんや。
わいらが実行したevaluationは、ユーザーが報告してた劣化を単純に捉えてなかったんや。部分的には、Claudeは孤立した間違いからよく回復するからや。
わいら自身のプライバシー慣行も、報告の調査に課題を生み出したんや。わいらの内部プライバシーとセキュリティ制御は、エンジニアがいつ、どのようにClaude とのユーザーインタラクションにアクセスできるかを制限してるんや。特に、それらのインタラクションがフィードバックとしてわいらに報告されてない場合はな。
これはユーザーのプライバシーを保護するけど、バグを特定したり再現したりするために必要な問題のあるインタラクションをエンジニアが調べることを妨げるんや。
プライバシーと信頼性はしばしば対立するもんで、これはそのええ例やな。とは言え、彼らは内部でそれを捉えることができたはずや。
各バグは異なるプラットフォームで異なる率で異なる症状を生み出したんや。これが、単一の原因を指し示さない混乱した報告のミックスを作り出したんや。それはランダムで一貫しない劣化のように見えたんや。
ユーザーとしても、そんな感じやったで。わいはこの期間中にClaudeでめちゃくちゃ変な問題があったんや。
より根本的に、わいらはノイズの多いevaluationに過度に依存してたんや。わいらはオンラインでの報告の増加を認識してたけど、これらをわいらの最近の変更のそれぞれに接続する明確な方法が欠けてたんや。
8月29日に否定的な報告が急増したとき、わいらは他の標準的なロードバランシング変更との接続をすぐには作らなかったんや。
これはちょっと許し難いな。
彼らが何をするつもりか
わいらがわいらのインフラを改善し続ける中で、わいらはまた、上で議論されたようなバグを評価し、防ぐ方法も改善してるんや。わいらがClaudeを提供するすべてのプラットフォームでな。ここがわいらが変更してることや。猫は無視してや。彼にはニーズがあるんや。
変更1、より敏感なevaluation。任意の問題の根本原因を発見するのを助けるために、わいらは動作してる実装と壊れた実装をより確実に区別できるevaluationを開発したんや。わいらはモデル品質により注意を払うために、これらのevaluationを改善し続けるで。
変更2、品質eval。わいらは定期的にわいらのシステムでevalを実行してるけど、コンテンツウィンドウロードバランスエラーみたいな問題を捉えるために、真のprodシステムでより継続的に実行するで。
コンテキストウィンドウ、同じことや。分かるやろ。
そして変更3、より速いデバッグツール。わいらはユーザーのプライバシーを犠牲にすることなく、コミュニティソースのフィードバックをより良くデバッグするためのインフラとツールを開発するで。さらに、ここで開発されたいくつかのbespoke toolsは、もし発生するとしたら、将来の類似の事件での修復時間を短縮するために使用されるで。
また、ここでは影響を受けた顧客への返金について何も言及されてないことに注目してや。クラウドコードユーザーの30%以上が影響を受けたけど、その結果として金や何かを返してもらった人は約0%やったんや。
evalとモニタリングは重要やけど、これらの事件は、Claudeからの応答が通常の基準に達してないときに、ユーザーからの継続的なシグナルも必要やっちゅうことを示してるんや。
観察された特定の変化の報告、遭遇した予期しない行動の例、異なる使用ケースでのパターンは、すべてわいらが問題を特定するのに役立ったんや。ユーザーが直接フィードバックを送り続けることが特に役立つんや。
クラウドコードで/bugをコマンドとして使うか、クラウドアプリの親指を下にするボタンを使ってそうすることができるで。
開発者と研究者は、わいらの内部テストを補完するモデル品質を評価する新しくて面白い方法をよく作るんや。わいらはあなたのもんをシェアしてもらいたいんや。彼らに直接連絡することができるで。
彼らに変更してもらいたいことがあるんや。これらのことが起こってる間により透明であってほしいと思うし、このタイプの投稿をもっと頻繁にしてほしいと思う。そして最も重要なのは、実際に人々に返金するとか、みんなのクラウドコード購読を謝罪として2週間延長するとかして、これをより良く所有する方法でこれを所有してほしかったっちゅうことや。
彼らがここでより良く所有するためにできたことがたくさんあったんや。そして、彼らがそれらの機会を取らなかったことに驚いてるけど、同時に、Anthropicはわいらが頼ることができる実際のツールであるのと同じくらい光学会社でもあるんや。
だから、彼らがここで光学ルートを取ったことは驚くことやないんや。とは言え、この記事はAnthropicでの重要な変化を表してるんや。これは、わいが彼らから以前には絶対に期待してなかったレベルの透明性や。
彼らがついにここに出てきてこれをやってくれたことはめちゃくちゃありがたいし、彼らがこれを続けることを本当に奨励したいから、あまり意地悪になりたくないんや。
わいらがLLMの非決定論的で信頼できない混沌の上により多くのもんを構築していく中で、それらを提供してる会社が、彼らが提供してるもんと、彼らが提供してるもんで何が悪かったかについて本当に透明であることがこれまで以上に重要になってるんや。なぜなら、これのどれも決定論的やないからや。
わいらは何を期待すべきかわからんのや。だから、もんが期待されるもんより少ない場合、彼らはその上でより多くのコミュニケーションをすることで過度に補償する必要があるんや。
Anthropicは歴史的にこれをしてこなかったんや、なぜなら彼らはまだ人々が頼るツールであることに慣れてないからや。彼らは本当に心の底では研究会社なんや。そして、わいがそれを愛し、尊敬してるのと同じくらい、わいらは今Anthropicをインフラ会社として頼ってるんや。
そして、彼らはプレートに足を踏み入れて、これらのことが起こったときにそれらを所有する必要があるんや。これについては他に何もないわ。これが有用な分解やったことを願ってるで。みんながどう思うか教えてや。そして次回まで、またな。
コメント