Self-HPO、コーディングエージェントのHarnessと方策を同時に進化
導入
コーディングエージェントの性能は、基盤モデルの能力だけで決まるわけではありません。リポジトリの読み取り方、ツールの呼び出し方、テストの実行、エラーへの対応など、モデルとソフトウェア環境をつなぐ仕組みも結果を大きく左右します。この仕組みは一般にHarnessと呼ばれます。Self-HPOは、方策モデルとHarnessを別々の部品として固定するのではなく、相互に進化するシステムとして扱います。
仕組み:2つの段階を反復
Self-HPOは、Harnessの最適化と方策の最適化を交互に行います。
- Hステップ:Harness探索。 現在の方策が自分の失敗を分析し、どのような失敗モードが生じているかを推定したうえで、新しいHarness候補を提案します。探索は、モデルが現時点で苦手とする課題に重点を置きます。
- Pステップ:方策最適化。 選ばれたHarnessの下で、強化学習によって方策モデルを更新します。固定された環境では得られなかった行動軌跡を、学習に利用できる点が特徴です。
- 次の探索への引き継ぎ。 学習中に特に難しかったタスクを、次のHarness探索の集合として利用します。方策が変化するたびに、探索対象もその新しい弱点へ移ります。
従来の構成には2つのずれがありました。古いチェックポイント向けに調整したHarnessは、更新後のモデルの失敗を十分に引き出せない可能性があります。また、固定Harnessから得られる軌跡だけでは、方策学習の行動範囲も制限されます。Self-HPOはこのずれを反復的に縮めようとします。
実験結果
SWE-Bench Verified、SWE-Bench Multilingual、SWE-Bench Proの3つのベンチマークで、Self-HPOはHarnessだけ、または方策だけを最適化するベースラインを上回りました。Qwen3.5-35B-A3Bでは、平均解決率が57.8%から64.8%に上昇し、分布外の設定でも改善が確認されています。
部品ごとの分析も重要です。最適化されたHarnessを基盤方策と組み合わせても効果が残り、最適化された方策を基盤Harnessで動かしても効果が残りました。しかし、両方を組み合わせたときの改善幅は、それぞれの改善を単純に足したものを超えています。これは、方策の学習内容と、それを引き出す環境との間に相互作用があることを示します。
また、1回の試行で成功する信頼性を表すPass@1と、複数候補による能力の広がりを表すPass@kも改善しました。外部モデルを必須としない一方、Opus 4.8のような強力な外部モデルをHarness提案役に使うと、さらなる向上が得られると報告されています。
意義と残る論点
Self-HPOの意義は、エージェントのワークフローそのものを学習対象にした点にあります。従来は、エンジニアがツール利用の流れを設計し、その固定環境でモデルを訓練することが一般的でした。Self-HPOでは、失敗の情報が環境設計に戻され、その環境が次の方策学習を変えます。
新しいリポジトリやツール、失敗パターンへの適応に有望な考え方ですが、提示された素材だけでは、反復探索の計算コスト、強化学習の詳細、長期反復時の安定性までは分かりません。したがって現段階では、コーディングエージェントの継続改善を完成させた手法というより、方策とHarnessの協調最適化を示す実験的な枠組みと見るのが適切です。
コメント
ログイン状態を確認中…
コメントを読み込み中…