エージェントに複雑なタスクを投げると、ときどき最初の数手で筋の悪い方針に入り込む。それでもエージェントは律儀に20手ほど回し続け、大量のツール呼び出しとトークンを消費してから、ようやく「できませんでした」と返してくる。この「詰んでいるのに走り続ける」時間が、自前でエージェントを回している人ほど地味に効いてくる。RLのロールアウト収集、評価バッチ、長時間ジョブでは、失敗するエピソードほど長く回りがちだからだ。

7月に出た論文 Doomed from the Start: Early Abort of LLM Agent Episodes via a Recall-Controlled Probe Cascade(Kai Ruan ら)は、この無駄を「失敗しそうな回を早めに打ち切る」ことで削る。面白いのは、打ち切りの判断材料をエージェントの外に見える振る舞いではなく、モデルの**内部状態(隠れ層の活性)**から取っている点だ。

「振る舞いを見る」派と「頭の中を覗く」派

失敗を先読みする研究には、大きく二つの流れがある。

一つは観測できる軌跡(actionやobservation、エラーメッセージなど)を読むやり方だ。同じ時期の AgentForesight がこの代表で、軌跡のprefixだけを見て「今この一手が決定的な誤りか」をオンラインで判定する7Bの監査モデルを訓練し、既存の proprietary ベースラインを Exact-F1 で上回っている。人間がログを追うのと同じ土俵で、より賢く見る路線である。

Doomed の論文はここに一石を投じる。観測される振る舞いだけを見るスコアラーは、序盤ではほぼ当てずっぽう(ラウンド1の判別性能はコイントスに近い)で、まともに効き始めるのはラウンド3〜4あたり。ところがその頃には全エピソードの3分の1以上がすでに終わっている、と指摘する。振る舞いが失敗を語り出す頃には、削れるはずだった計算はもう使い切られている。

対してモデルの隠れ状態は、1手目の時点で結末をかなり言い当てる。著者らは各ラウンドで、エージェントが行動を生成し終えた最終トークンの残差ストリーム上の隠れ状態を取り出し、そこに軽量な線形分類器(ロジスティック回帰)をかけるだけ。この内部プローブはラウンド1で、振る舞いベースのスコアラーより AUC で 0.12〜0.21 高い。しかも隠れ状態プローブに振る舞い特徴量を足しても、性能はそれ以上伸びなかった。必要な情報はすでに内部表現に書かれている、という主張だ。

イメージとしてはこうなる。

# 概念コード(考え方の説明であって、論文の公式実装/APIではない)
# 各ラウンド: 行動生成直後の最終トークンの隠れ状態を取り出す
hidden = model(input_ids, output_hidden_states=True).hidden_states[layer][:, -1, :]

# ラウンドrごとに用意した線形プローブで「この先失敗するか」を数値化
p_fail = probe_r.predict_proba(hidden.cpu().numpy())[:, 1]

# しきい値を超えたら打ち切る(τ_r は後述の較正で決める)
if p_fail > tau_r:
    abort_episode()

難しいのは「殺していい回」の見極め

失敗確率が出せても、素朴に「怪しければ止める」では成功したはずの回まで巻き添えにする。early abort の勘所は、成功エピソードをどれだけ取りこぼさずに、無駄な回だけを削れるかにある。

論文の解法は、これを「取りこぼし率(recall)を保証する打ち切りゲートの連鎖」として設計したことだ。ラウンド1〜6にそれぞれゲートを置き、各ゲートのしきい値を二項分布の下側信頼限界(Clopper–Pearson)で較正する。分布に仮定を置かない distribution-free な保証で、しかもゲートごとの保証は掛け算では全体の保証にならないため、各ラウンドの「取りこぼし予算」を検証データ上で一括最適化し、エピソード全体としての目標recallを満たすようにする。決めたカスケードは凍結し、独立データで事後保証まで検証する。

実務的に効くのは、これがツマミになっていることだ。「成功する回の9割は必ず残す(recall 90%)」と決めれば、その制約の下で削れる計算を最大化してくれる。どれだけの良い回を犠牲にしていいかというビジネス判断を、そのまま数値で指定できる。

数字で見る削減幅

Qwen-2.5-7B / Llama-3.2-3B / Qwen3-1.7B の3モデルと、TextCraft・WebShop の2環境、計24通りで評価している。24通りすべてで、実際に達成されたrecallは目標から標準偏差1つ以内に収まった。

recall目標(残す成功回)	TextCraft のトークン削減	WebShop のトークン削減
90%	60.2%	54.9%
95%	45.0%	41.5%

9割の成功回を守ったまま、生成トークンを6割前後削れる。同じ土俵で比べた「単一ゲート」方式に対しては、90% recall で 1.5〜8.8 倍の計算を節約したとする。TextCraft はレシピを辿って目標アイテムを合成する二値成否のタスクで、WebShop はテキスト上の買い物タスク。どちらも一手ごとの累積が長くなりやすく、早期打ち切りの効き目が出やすい題材だ。

どこで使えて、どこで詰むか

前提として、これは隠れ状態を読めるホワイトボックス前提の手法だ。活性にアクセスできない外部APIモデルには効かない。刺さるのは、自前でホストする open-weight エージェント、RLのロールアウト収集、評価ハーネスといった「失敗回を大量に回してしまう」場面で、そここそがコストの温床でもある。

素直に受け取れない留保も、著者ら自身が並べている。検証は事実上少数の環境・モデル規模で、タスク分布がずれれば較正の前提(交換可能性)は崩れる。活性は今回オフラインのteacher-forced再実行で抜いており、本番ではサービング側から読み出す実装が別途必要になる。較正データが少ないと到達できるrecallに上限があり(彼らの規模では約0.974が頭打ち)、そもそも全体recallの制御は経験的に検証したマージンであって定理ではない、と明記している。

とはいえ、方向性としては筋がいい。エージェントの内部表現には、本人が言葉にする前から「これは詰みだ」という信号が乗っている。それを選択的に打ち切る「reject option」に落とし込み、コストという実利に変換した。派手なモデル更新の話ではないが、エージェントの請求書を静かに軽くする類の仕事で、こういう地味な最適化ほど現場では効く。

一次ソース: