より良いモデル：より悪いツール

より良いモデル：より悪いツール この2日間、奇妙なPi（Pi.aiのことか？）の問題に悩まされ、深淵を覗き込むことになった。要するに、新しいClaudeモデルが、ネストされたedits[]配列に余分な、発明されたフィールドを含めてPiのエディットツールを呼び出すことがあるのだ。しかも、Haikuや小規模なモデルではなく、Opus 4.8だ。エディット自体は通常正しいのだが、モデルがでっち上げたキーのために引数がスキーマに一致せず、Piはツール呼び出しを拒否して再試行を求める。それだけなら、モデルが時々不正な形式のツール呼び出しを生成することは珍しくないので、それほど驚くことではない。特に小規模なモデルでは。驚いたのは、これが新しいAnthropicモデルで悪化していることで、Opus 4.8とSonnet 5の両方でこの問題が見られるが、古いモデルでは全く見られないことだ。つまり、このファミリーのSOTA（State-Of-The-Art）モデルが、この特定のツールスキーマに関しては、古い兄弟機よりも劣っているのだ。Fableについて気になる人のために言っておくと、私は意図的にテストしなかった。なぜなら、彼らが実行している分類器が私をOpusにサイレントにダウングレードするのではないかと確信が持てなかったからだ。 ツール呼び出しはテキストである LLMのツール呼び出しの内部構造をあまり詳しく見ていない人にとって、理解すべき重要なことは、ツール呼び出しは魔法ではなく、かなり粗雑なインバンドシグナリングを使用しているということだ。モデルは、トランスクリプト、システムプロンプト、および利用可能なツールのリストを受け取る。サーバーはそれを特別なマーカートークンを含む大きなプロンプトに加工する。モデルはその形式の例で訓練され、強化されているため、生成の途中でAPIまたはクライアントが「このツールをこれらの引数で呼び出す」と解釈するものを出力する。ファイル編集ツールの場合、意図された呼び出しペイロードは次のようになるかもしれない。 { "path": "some/file.py", "edits": [ { "oldText": "置換するテキスト", "newText": "置換テキスト" } ] } Harnessが引数を検証し、編集を実行し、その結果をモデルにフィードバックする。検証が失敗した場合、モデルはエラーを見て、通常は再試行する。そのフォーマットがどのように行われるかはAnthropicのモデルでは正確にはわからないが、一部の人は「ANTML」マーカーを取得しており、それらは時折公開通信にも漏れ出ている。私の知る限り、上記の呼び出しはモデルから次のようにシリアライズされて出力されるだろう。 <antml:function_calls> <antml:invoke name="edit"> <antml:parameter name="path">some/file.py</antml:parameter> <antml:parameter name="edits"> [ { "oldText": "置換するテキスト", "newText": "置換テキスト" } ] </antml:parameter> </antml:invoke> </antml:function_calls> ここで注意すべき重要な点は、これはXMLのように見えるが、実際にはXMLではないということだ。これは単にトークン化して訓練するのに便利だと見つけたものである。もう一つの注意点は、基本的なトップレベルの文字列パラメータはインラインで表示されるのに対し、オブジェクトの配列はJSONシリアライゼーションを介して実装されていることだ。これがどのように機能するかについては完全には確信がないが、そう遠くないことを示唆する兆候がいくつかある。これは後で重要になる。 モデルにこのような構造を生成させるには、非常に異なる2つの方法がある。 1. スキーマに一致する有効なJSONを生成するようにモデルに依頼し、その後検証する。 2. 無効なJSON、あるいは無効なスキーマ形状さえもサンプリングできないように、サンプラーを制約する。 2番目のアプローチは、人々が通常、文法認識型または制約付きデコーディングと呼ぶものである。サンプラーは文法に違反するトークンをマスクする。モデルが現在JSONオブジェクトの内部にいて、スキーマがoldTextとnewTextのみを許可すると述べている場合、サンプラーは「in_file」や「type」を出力するのを防ぐことができる。文法認識型デコーディングは、構文的に有効なJSONに制約するためにも、特定の列挙値やキーを強制するためにも使用できる。どのような制約もなしでは、モデルは単に学習された規約に従っているだけである。 失敗 Piのエディットツールは、1回の呼び出しで複数の正確な文字列置換をサポートしている。そのため、引数にはedits配列が含まれている。失敗したケースでは、モデルは次のようなエントリを生成する。 { "oldText": "...", "newText": "...", "requireUnique": true } あるいは、これだ。 { "oldText": "...", "newText": "...", "oldText2": "", "newText2": "" } 繰り返し試行する中で、type、id、kind、unique、requireUnique、matchCase、in_file、forceMatchCount、children、notes、cost、oldText2、newText2、oldText_2、newText_2、さらにはeditオブジェクト自体の内部にevent.0.additionalPropertiesキーまで、さまざまな発明された末尾キーのコレクションを見た。最も厄介なのは、私が検査した無効な呼び出しでは、実際のoldTextとnewTextのペイロードがバイト単位で正確だったことだ。モデルは実際には正しい呼び出しを生成していたが、オブジェクトの末尾に無意味なものを追加していたのだ。この失敗は、コンテキストにも大きく依存する。新鮮な単一ターンのプロンプト「このファイルを編集して」では、全く再現できなかった。ファイルの内容を読み込み、問題を診断し、複数行の編集を構成したエージェント的な履歴では、それを再現できた。さらに厄介なことに、すべてのトランスクリプトがその動作を示すわけではない。実際、これを再現するためにPetr Baudisのトランスクリプトが必要だった！そのユーザーのセッションで、Opus 4.8が約20%の時間失敗した。履歴から思考ブロックを削除すると、失敗率は半分になった。厳密なツール呼び出しをオンにすると、私の実行ではそれが排除された。 なぜ悪化しているのか 私の最も強い仮説は、これがランダムな劣化ではなく、訓練上のアーティファクトであるということだ。古いAnthropicモデルが訓練されていた頃、それらは（文書化されているものもあれば、そうでないものもある）いくつかのツールで訓練されていた。しかし、その訓練には、Claude Codeのようなユーザー出荷のハーネスが明白なターゲットとしてまだ存在していなかった。現代のAnthropicモデルは、そのポストトレーニングにClaude Codeまたはそれに非常に似たハーネスが含まれている可能性が高いため、おそらく異なっている。モデルは、その環境で成功したツール呼び出しがどのように見えるかを学習する。また、その環境で許容される間違いも学習する。Claude Code自体のツールは比較的フラットである。通常の編集ツールはPiのネストされたedits[]形状ではなく、file_path、old_string、new_string、およびオプションフラグ（replace_all）に近い。Claude Codeのクライアントを見ると非常に参考になる。それは、不正なツール使用、パラメータエイリアス、型変換、Unicode修復、および未知のキーのフィルタリングのためのリトライパスを含んでいる。言い換えれば、Anthropic自身のクライアントは、かなりの量の「スロップ」（不正確さ）を期待し、受け入れ、そしてほとんどサイレントにそれを修復しているようだ。もし、このようなハーネス、またはそのシミュレーションで強化学習が行われると、わずかに不正なツール呼び出しでもタスクを完了し、報酬を受け取ることができる。ハーネスはエラーを完全に吸収し、エイリアスを発明したり、余分なフィールドを追加したり、近くのパラメータ名を使用したりすることに対する勾配はほとんどない。さらに悪いことに、モデルは典型的なClaude Code編集ツールの形状に非常に強く適応してしまう可能性がある。異なるハーネスは、同じ意味的な意図を持つが異なるスキーマを持つツールを提示することができる。そのようなツールは、ますますオフディストリビューションになる可能性がある。より良く訓練されたモデルは、その事前知識が強いため、実際にはより強く抵抗するかもしれない。これは数ヶ月前の状況とはあまり変わらないが、変化である。Opus 4.5がリリースされたとき、それは他の編集ツールに例外的にうまく適応した。実際、指示が良好である限り、モデルはどのような形状のツールにも適応する可能性が高いという良い道筋に乗っていると確信していた。今、私は私たちが進んでいる道について少し心配している。代替のツールスキーマは単に馴染みがないだけでなく、特定の、寛容なツールエコロジーのために最適化されたポストトレーニングによって暗黙的に罰せられる可能性がある。そして、そのエコロジーは文書化されていない。文書化されたテキストエディタツールがあるが、このフォーマットがClaude Codeによって実際にはフォローされていないことがわかるだろう。Claude Codeが内部で何を行っているか（これはクローズドソースのハーネスである）は、あなたからは隠されている。 スロップハーネス Claude Codeは明らかにクローズドソースだが、ミニファイされたコードを見て、それが何をしているのかをある程度把握することができる。