StopLoss、コーディングエージェントに失敗の予測と早期停止を教える

導入

コーディングエージェントは、長く動かし続ければ必ず成功に近づくわけではありません。検証に失敗する経路へすでに入っていても、ファイル編集、ツール呼び出し、テスト実行を続けることがあります。そこで別のフロンティアモデルに常時監視させると、監視そのものの推論コストが、早期停止による節約を打ち消す可能性があります。

StopLossは、この問題を小型の外部モニターで解決しようとします。金融のストップロス注文に着想を得た名称の通り、エージェントを修正したり問題を解き直したりするのではなく、最終的に失敗する可能性が高い実行を早めに終了させます。

仕組み

• 最終結果から学習する：完了済みのエージェント軌跡と、検証器による最終的な合否を利用します。軌跡の早い段階にある局所的なウィンドウにも最終結果を対応付け、失敗につながりやすい操作パターンを学習します。
• 小型モデルでリスクを採点する：約7B〜8B規模の言語モデルが、直近のツール操作を1回のフォワード計算で読み、失敗リスクをスコア化します。全履歴を毎回読み直したり、大型モデルに自由形式の審査をさせたりする必要はありません。
• しきい値で中止する：成功実行をもとにしきい値を校正し、スコアが基準を超えた時だけ中止します。モニターは実行器の外側に配置できるため、既存エージェントの再訓練や構造変更を求めません。
• 汎用ジャッジと比較する：同じウィンドウを読む6種類の汎用モデル判定器と比較し、SWE-bench VerifiedとSWE-bench Proの一部で、GPTおよびClaudeの実行器を評価しました。

結果と意味

結果による教師信号を使うことで、最初のチェック時にはほぼ偶然に近かった失敗予測が、有用なシグナルへ改善しました。StopLossの1回あたりのチェック費用は、比較対象の汎用ジャッジよりおよそ1〜2桁低い水準です。SWE-bench Verifiedでは、全タスクを完走させる場合と比べ、成功実行の99%を維持しながら、保持された解あたりのコストを4.5%削減しました。より高コストなProサブセットでは最大31%、Qwen3-8Bをバックボーンに使った場合は48%の削減が報告されています。4つの設定すべてで、保持された解あたりのコストは各ジャッジ方針を下回りました。

重要なのは、大型モデルを小型モデルに単純置換した点だけではありません。実行器は問題解決に集中し、モニターは追加投資を続ける価値があるかを判定するという役割分担が示されています。長いツール実行を伴う開発タスクでは、失敗認識を高価な自由形式推論から高速なリスク採点へ変えられます。

一方、早期停止には誤判定のリスクがあります。新しい実行器、検証器、タスク分布ではしきい値の再校正が必要になり、学習軌跡の偏りは他の環境への汎化にも影響します。したがってStopLossは、検証を置き換える万能な失敗証明器ではなく、保守的なコスト最適化レイヤーとして捉えるのが適切です。コード、モデル、データの公開は、異なるエージェントやベンチマークでの追試を容易にします。

出典：Hugging Face Daily Papers