なぜAnthropicは「考える係」と「書く係」を分けたのか

Anthropicが公開した「Advisor tool」という仕組みが、63%のコストで92%の性能を維持する、という数字とともに紹介されていた(出典)。

高知能なモデルをアドバイザー（あるいはオーケストレーター）として計画に専念させ、実行そのものは安価な軽量モデルに任せる。処理の大半を低いレートのトークンで済ませられるぶん、コストが下がるという理屈だ。コーディングやリサーチのような、計画と実行を分離できる長時間のタスクに向いているという。

数字だけを見れば、これは賢い節約術に見える。

63対92という比率の不釣り合い

正直に書くと、最初にこの数字を見たときは「性能を8%犠牲にしてコストを4割弱削った、悪くないトレードオフだ」としか思わなかった。劣化を許容した節約だと捉えていたわけだ。

ただ、比率をそろえて見直すと違和感が残る。コストを削った分だけ性能が線形に落ちるなら、63%のコストなら性能も63%前後まで落ちて当然のはずだ。92%という数字は、その予想より20ポイント以上高い。

線形の劣化では説明がつかない。

だとすれば、これは劣化を我慢した節約ではなく、計画と実行を分離したことで、実行役の軽量モデルが本来持っている実力をそのまま引き出せるようになった、という話ではないか。軽量モデルの性能が低く見えていたのは、モデルそのものの実力不足ではなく、計画まで自分で担わされていた負荷のせいだったのかもしれない。

Parryのparry_create_prツールには、mode: draftとmode: directという2つの送り方がある。

draftは、著者が管理画面で内容を確認し、送るかどうかを著者自身が判断する経路だ。いわばアドバイザー役の人間の判断を挟む。directは、push済みのブランチから即座に実PRを作成する。判断はすでに済んでいる前提で、実行だけを機械的に行う経路になる。

この2つを分けているのは、確認という重い処理と、送信という軽い処理を同じ経路で扱うと、どちらのコストも高くつくからだと考えられる。判断が必要な場面ではdraftで人間の目を挟み、判断がすでに終わっている場面ではdirectで実行だけを機械的に済ませる。

判断と実行を同じ経路で毎回両方こなそうとすると、判断が要らない場面でも律儀に判断のコストを払うことになる。Advisor toolの63対92という比率は、その無駄を削った分だと考えると辻褄が合う。

同じ構造は、ローカルLLMに実装を委譲する場面でも見られる。型定義、仕様、テストという「判断済みの設計」を先に固定しておけば、実装フェーズを担うモデルは、その設計をなぞるだけでよくなる。

ここまでは、コーディングやリサーチという、計画と実行の境目が比較的はっきりしたタスクの話だった。

判断そのものが何段階にも連鎖するような、もっと複雑なタスクでも同じ比率が保たれるかは、この記事の時点ではまだ確かめられていない。判断を挟む回数が増えるほど、アドバイザーとワーカーの間の受け渡しコストも増えるはずで、63対92という比率がどこまで崩れずに保てるのかは、今後の実測を待つしかない。