ハイブリッド推論エージェント：潜在思考とテキスト行動

多くのLLMエージェントについて、居心地の悪い真実があります。生成するトークンの大半は、高価な水増しにすぎないということです。数学の問題を解く推論エージェントは、「問題をもう一度読み直そう」や「ここまでで分かったのは……」といった文を、フルの推論コストをかけて平然と書き出します。実際の計算と同じ計算資源を、修辞的な前置きに費やしているわけです。潜在推論、つまりテキストではなくモデルの隠れ状態の中で思考を行う手法は、昔からわかりやすい解決策でした。ハイブリッド推論エージェントに関する新しい論文は、それがようやく実用的になったことを示しています。ただし、この分かりやすい解決策にはこの分野の誰も払いたくないコストが伴います。モデルが何を考えているのかを、もう読めなくなるのです。

私は何年もかけて、チームがChain-of-thoughtを安くしようと試行錯誤するのを見てきました。どの手法も同じ壁にぶつかります。ハイブリッド方式がなぜ違うのか、そしてなぜそれでも、静かな失敗を許容できない場所には導入しないつもりなのかを理解しておく価値があります。

テキストベースのChain-of-thoughtがトークンを無駄にする理由

Chain-of-thoughtは本当に優れた発見でした。モデルに中間ステップを書き出させるだけで、数学、論理、多段階の質問における正答率は劇的に上がります。問題は、言語が計算の記述形式としてひどく不向きなことです。言葉は情報が欠落しやすく、冗長で、そして請求額にとって決定的に重要なことに逐次的です。

モデルが解く前に「問題を言い直す」場面を考えてみてください。それは数百トークンを一つずつ生成し、それぞれがフルのフォワードパスを必要とするのに、情報量はほぼゼロです。問題文は既にコンテキストにあるからです。最新の推論モデルにはこうしたものが溢れています。現行世代の推論トレースを眺めたことがある人なら、人間のエンジニアならノイズと呼ぶであろう、自己保証、言い換え、留保の段落を見たことがあるはずです。ツール呼び出しを伴うエージェントタスクでは、さらに悪くなります。モデルはこれから行うことを実況し、実行し、そして今行ったことを実況するのです。

経済性はエージェントの規模で積み上がります。各ツール呼び出しの前に冗長な推論の前置きを付けて十回のツール呼び出しを行うエージェントは、トークン予算の80%を実況に費やすかもしれません。トークン単位で支払っているなら（そして実際に支払っているはずです）、それは現実の金額です。さらに、人間が待っているエージェントにとっては遅延にもなり、これは非常に重要です。これはより安く高速な推論ティアを求める動きと同じ圧力から来ています。ボトルネックは知能そのものではなく、知能を言葉で表現するコストなのです。

失敗した試み：切り詰め、蒸留、純粋な潜在推論

この分野は三つの方向から攻めてきましたが、どれも示唆に富む形で壊れました。

試み1：単にトークンを減らす

Budget forcing、長さペナルティ、簡潔な推論のファインチューニング。素朴なアプローチは、テキストでの思考量をモデルに減らさせることです。ある程度までは機能しますが、やがて正答率が急落します。冗長なトレースは純粋な無駄ではなく、一見冗長に見える部分の一部は構造上必要なのです。闇雲に圧縮すると、水増しと一緒に計算まで捨ててしまい、外から見てもどちらがどちらか区別できません。

試み2：純粋な潜在推論

より洗練されたアイデアは、思考トークンをまったく生成しないことです。モデルの出力埋め込みを入力に戻し、離散的な単語ではなく連続的な「思考ベクトル」を使い、答えを出す前に内部で何ステップも推論させます。COCONUTなどの研究では、この手法が一部のタスクでテキストのChain-of-thoughtに匹敵するか上回り、フォワードパスはごく一部で済むことが示されました。しかし、純粋な潜在推論にはエージェントにとって致命的な問題が二つあります。第一に、外の世界はテキストで話します。ツールのAPIは文字列の引数を取り、検索エンジンはクエリを受け取り、ユーザーは散文で答えを求めます。ベクトルだけで考えるモデルも、境界では全てを翻訳しなければならず、そして誤りはその翻訳に潜みます。第二に、これこそが議論の的になっている点ですが、思考がブラックボックスになります。推論トレースが完全に失われるのです。これは現状、モデルがなぜそうしたのかを覗ける唯一の、まあまあ使える窓です。

試み3：ポーズトークンと埋め込み的な計算

より地味な研究の流れとして、意味のない「ポーズ」トークンを挿入し、内容を増やさずにモデルへ追加の計算量を与える試みもありました。結果は良くても玉石混交で、研究室の外に出ることはありませんでした。中間トークンの存在だけでなく、その内容こそが計算の方向を制御するのに重要だと分かったのです。

実際に機能するもの：ハイブリッド推論エージェント

HybridAgentの論文は、私がもっと多くの研究に取ってほしいと思っていた現実的な立場をとっています。潜在推論とテキスト推論のどちらかを選ぶのをやめ、生成の途中でモデルに切り替えさせるのです。内部計算をするときは潜在で考え、ツールを呼び出す、その出力を読む、あるいは人間に説明する必要があるときはテキストに切り替えます。

アーキテクチャには理解に値する三つの要素があります。HybridLinkと呼ばれる軽量モジュールが遷移を担い、潜在セグメントの最終隠れ状態を、テキストモードのモデルが続きから処理できる形に変換し、その逆も行います。連続ワーキングメモリはターンをまたいだハイブリッドのコンテキスト全体を保持するので、一ターン目の潜在思考は、テキストの要約に潰されることなく五ターン目でも利用できます。学習面では二段階です。HybridSFTがバックボーンにHybridLinkとの協調をまず教え、次にHybridRLが強化学習で、各モードをいつ使う価値があるのか、そのコストに見合うのかを学習させます。

私の考えでは、これこそが本当の貢献です。難しかったのは「モデルが潜在空間で推論できるか」ではありません。それは既に分かっていました。難しいのは方針、つまりタスクのどの部分が安価で不透明な計算に値し、どの部分が高価で検査可能なテキストに値するかです。その方針を実際のタスク報酬に対して強化学習で学ばせることで、デモ止まりではなく実際に動くものが得られるのです。

報告されている数値は強力です。数学、科学、医療、検索、エージェント推論にまたがる11のベンチマークで、ハイブリッドエージェントはテキストベースと潜在ベースの両方のベースラインに対して約10%の性能向上を主張し、トークンは35〜55%削減、推論は1.8〜2.6倍高速化、コストはおよそ3分の1に削減されるとしています。単一論文のベンチマーク主張は、いつものように割り引いて考えるべきです。ベンチマークは実際のワークロードの姿をしばしば捉えられません。それでも結果の方向性は理論と一致しています。トレースの大半が水増しなら、その大半を取り除けば、主にコストが減るはずで、能力が減るわけではありません。

コードで見る潜在推論の実際

仕組みは、思うより単純です。テキストモードでは、トークンをサンプリングし、埋め込みを作ってモデルに戻します。潜在モードでは、サンプリングを飛ばし、モデル自身の出力ベクトルを、小さな射影を通すかもしれませんが、そのまま次の入力として戻します。特殊な制御トークンか学習されたゲートが、どちらのモードかを決めます。概略は次のとおりです。

def hybrid_step(hidden_state, mode_gate, hybrid_link):
mode = mode_gate(hidden_state)  # learned: LATENT or TEXT
if mode == LATENT:
# No sampling. Feed the continuous thought back in.
next_input = hybrid_link.latent_in(hidden_state)
return next_input, None  # nothing human-readable emitted
# TEXT mode: normal autoregression
logits = lm_head(hidden_state)
token = sample(logits)
next_input = hybrid_link.text_in(embed(token))
return next_input, token  # inspectable output

実際のシステムにはワーキングメモリと学習の仕組みが加わりますが、これが中核のループです。これがサービング基盤に何を意味するか注意してください。潜在ステップも依然としてフルのフォワードパスです。節約されるのはトークン数、つまり出力長、コンテキストの伸び、長いトレースによるKVキャッシュの圧迫であり、ステップごとの計算量ではありません。2倍以上の推論高速化は、主に系列が短くなり、自己回帰的なテキストのデコードが減ったことによるもので、思考がタダになったわけではありません。論文へのあるコメントでは、フォワードパスの料金は既に払っているのだから、潜在経路をテキスト生成と並列に走らせるべきだという提案もありました。これは本当に面白いアイデアで、この設計空間がまだ若いことを物語っています。

誰も払いたくない解釈性のコスト

さて、省くと職務怠慢になる部分です。推論トレースは単なるデバッグの便利機能ではなく、安全性の仕組みです。本番環境でエージェントが妙な動きをしたとき、最初にやることはトレースを読むことです。アライメント研究者が欺瞞的な振る舞いを探るとき、最終回答と矛盾する推論を探します。推論をベクトルに移してしまうと、この両方のワークフローが見えなくなります。

論文は、連続ワーキングメモリによって潜在思考が「直接検査可能」になると主張しています。私は、これを技術的には正しいが実務的には誤解を招くと分類します。ベクトルは、どの隠れ状態とも同じように検査できます。プロービング分類器、デコーダ射影、埋め込み空間での最近傍分析などです。しかし、それは研究グレードのツールであって、オンコールで使えるワークフローではありません。ログファイルを読むのと、コアダンプにデバッガを接続するのとの違いです。私たちの中には長らく解釈性に関する過剰な主張に懐疑的だった者もいますが、ワーキングメモリのバッファがあっても、根本的な非対称性は変わりません。テキストは誰にでも読めますが、潜在表現はほとんど誰にも読めないのです。

あまり語られない失敗モードもあります。サイレントなエラーの伝播です。テキストのトレースでは、誤った中間ステップは目に見え、時にはモデル自身が読み直して自己修正します。一方、誤った潜在思考はテキストの痕跡を一切残さずにワーキングメモリを伝播します。エージェントの最終回答は、潜在的な熟考が健全だった場合でも、ゴミだった場合でも、同じように流暢に見えます。本番でエージェントを運用するチームにとって、これは封じ込めと監視のトレードオフに直結します。監視が格段に難しくなるので、ハイブリッドエージェントは封じ込めの方向へ傾けさせるのです。

この論文をめぐる議論では、潜在推論が研究コミュニティの一部で、まさにこれらの理由から非公式にタブー視されていたことが指摘されました。そのタブーは明らかに終わりました。それが自動的に悪いことだとは思いません。ただ、効率の数字を喜んでいる人たちは、その効率を買うために解釈性を支払っていることを正直に認めるべきです。

論文と手元のGPUのギャップ

コード、重み、データが公開されているのは、本当に素晴らしいことです。同時に、即座の現実チェックにもなりました。数時間のうちに、公開されたモデルをローカルで動かす実務者たちが、退化した挙動を報告しました。ある量子化された8Bのビルドは、「ローマ教皇は誰か」という質問に対して、テキストモードの推論の同じ段落を延々と繰り返して止まりました。14Bのビルドは、同程度のモデルなら問題なくこなす定型的な検索と要約のタスクで、同じ段落のバリエーションを五分間もループし続けました。

量子化のアーティファクトかもしれませんし、チャットテンプレートの不一致かもしれません。全く新しいアーキテクチャへのllama.cppの対応は、いつも賭けのようなものです。ただ、ループの失敗は偶然ではないと私は疑っています。モード切り替えは学習された振る舞いであり、学習された振る舞いこそ、量子化や分布のずれで真っ先に壊れるものです。潜在とテキストの方針がわずかにずれたモデルは、派手には失敗しません。考えるのをやめる決断を、そもそもしなくなるという形で失敗します。これは誤答よりずっとタチの悪い失敗モードです。予算を無期限に燃やし続けるからです。今日エージェントのループを組んでいるなら、どの推論パラダイムを採用するにせよ、モデル呼び出しのたびに厳格なターンとトークンの予算を設けるべき理由がもう一つ増えたことになります。これはエージェント型CLIがループをどう構成しているかで論じた規律と同じものです。

使うべきか？実務家の結論

使うべきです、ただし依存先としてではなく、道標として。率直な読みはこうです。

• 効率の議論は現実的であり、構造的なものです。テキストは内部計算の媒体として不向きで、エージェントの長期化に伴い、実況にかかるトークンの負担は増える一方でしょう。何らかの形の潜在推論が、好むと好まざるとにかかわらず本番モデルに入ってくるはずです。フロンティア・ラボが採用している不透明な「推論の要約」というアプローチは、すでにその道の一歩と言えるかもしれません。
• 解釈性のコストも現実的で、しかも今のところ過小評価されています。エージェントがなぜそう行動したのかの監査を必要とするユースケース、たとえば医療、金融、その他規制の対象となる分野では、テキストのトレースは手放すと危険な機能です。
• 現在の成果物は研究グレードです。単純なプロンプトでの退化したループ、不確実な量子化の挙動、そして容易に検査できない不透明なモード切り替えの方針は、顧客向けAPIの背後に置けるものではありません。
• ハイブリッドという枠組みは正しい選択です。純粋な潜在推論はツールAPIやユーザーとの接触を生き延びられず、純粋なテキスト推論は推論の請求額との接触を生き延びられません。両者の間に学習された境界を置くことが、結局たどり着く形でしょう。

より根本的な指摘は、「言葉で考える」ことは、そもそも私たちがこれらのモデルを訓練した方法の偶然の産物であって、思考の法則ではないということです。言語が機械の思考にとって正しい粒度だという定理はありません。驚くべきは、それがこれほどうまく機能したことです。ハイブリッド推論エージェントは、その次に来るものの最初の信頼できるスケッチです。非公開で熟考し、話すことが仕事のときにだけ話すモデルです。機械の仕事をチェックする能力を失わずに、その未来を構築できるかどうか。これこそ、今のエージェント設計における最も重要な未解決の問いだと私は考えます。