エージェントに複雑なタスクを投げると、ときどき最初の数手で筋の悪い方針に入り込む。それでもエージェントは律儀に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」に落とし込み、コストという実利に変換した。派手なモデル更新の話ではないが、エージェントの請求書を静かに軽くする類の仕事で、こういう地味な最適化ほど現場では効く。
一次ソース: