OpenHands のブログに掲載されたこの記事は、LLM によってコードの生成は安価になり、今や本当のボトルネックは検証である、という主張から始まる。すなわち、変更が正しいこと、リポジトリの規約に従っていること、そしてチームが信頼し、レビューし、マージできるものであることを確認する作業である。OpenHands はその答えを検証スタックとして位置づけている。これは、コーディングエージェントが早く失敗し、人間が自信を持ってマージできる変更を生み出せるよう支援することを目的とした、階層化された検証器の集まりであり、記事はそのスタックの第 1 層として、小さく高速な クリティックモデル として実装された軌跡レベルの検証器を紹介している。
記事の中心的な論点は、そうしたクリティックの訓練シグナルをどこから得るかにある。記事によれば、これまでの学術研究では、単体テストのような検証済みの報酬が各試行の正否をラベル付けするベンチマークデータセットでクリティックを訓練してきた。しかし、人間が関与する本番環境の開発には通常そうした報酬がなく、記事は、ベンチマークのトレースだけで訓練したクリティックは本番環境にうまく移行しないと報告している。そこで OpenHands は、実世界のユーザーとエージェントのやり取りでクリティックを訓練し、ルーブリックを通じて本番環境の疎なシグナルを密な教師信号に変換している。スタックの第 2 層であるパッチレベルの層については、続編の記事に譲っている。
要点
- 記事は、AI コーディングのボトルネックがコードの生成からその検証へと移ったと述べている。
- OpenHands は自らのアプローチを、階層化された検証器から成る検証スタックとして説明している。この記事が扱うのはその第 1 層のみで、エージェントの軌跡全体（会話、ツール呼び出し、アクション）を採点するクリティックである。
- クリティックのスコアは、続行するか、停止するか、改善するかの判断、複数の試行からの選択、そして時間とともにエージェントを改善する軽量なフィードバックの収集に使えるものとして示されている。モデルが小さいため、記事によれば高速（多くの場合 1 秒未満から 1 秒程度）で、対話的なセッション中に実行できるほど安価である。
- 記事自身の測定によれば、ベンチマーク形式のデータだけで訓練したクリティックは、本番環境の結果に対する AUC が約 0.45〜0.48 とランダムより悪く、これに対して PR のマージを結果の代理指標として訓練した場合は 0.58、コードの存続を代理指標とした場合は 0.69 だった。
- 訓練パイプラインでは、各やり取りをセグメント（ユーザーのリクエスト、エージェントのアクションとツール、終了）に分割し、すべてのセグメントに、振る舞いの質と、意図の誤解、指示に従わないこと、スコープクリープといったよくある失敗モードを記述する、トレースから観察可能な 24 の「Critic Rubrics」特徴量で注釈を付ける。そのうえで、一部のセグメントを疎な結果に結び付ける。その割合は、コードの存続が約 4%、PR のマージが約 6% である。
- OpenHands は、ルーブリックの特徴量から疎な結果への回帰を行ったと報告し、ルーブリックは実際の結果を予測できること、そして何が予測に役立つかはベンチマークと本番環境で異なりうることを結論づけている。
- クリティック自体は、小さな半教師ありのマルチタスクモデルであり、密なルーブリックの特徴量と、疎な結果の代理指標からの成功を予測するよう学習する。
- SWE-bench Verified のうち結果が混在するサブセット（少なくとも 1 回の実行が成功し、少なくとも 1 回が失敗するインスタンス）において、記事は、クリティックに導かれた best-of-8 の選択が 73.8% で、ランダムな選択の 57.9% を上回ったこと、また早期停止がランダムより 17.7 ポイント高く、試行回数が 8 回ではなく平均 1.35 回で済んだことを報告している。
- これらの結果は OpenHands 自身による自社のクリティックの評価であり、記事は完全なアブレーションについては付随する論文を参照するよう読者に案内している。
- クリティックは、プログラムから利用するために（リランキング、早期停止、反復的な改善）OpenHands Software Agent SDK に統合されており、早期停止と設定可能な受け入れしきい値とともに OpenHands CLI にも統合されている。
背景
記事は自らのクリティックを、他の本番環境の検証器ではなく、これまでの学術研究にあるベンチマークで訓練されたクリティックと対比させている。また、ベンチマークで訓練されたクリティックは移行しないため実世界の教師データが必要だという中心的な主張は、OpenHands 自身の本番データと評価に基づいている。記事は、クリティックの対象となるエージェントのベンダーによって公開されたものであり、OpenHands を導入しているチームに対して、クリティックに基づく検証をワークフローに組み込むことについて問い合わせるよう呼びかけて締めくくられている。最終的な出力だけでなく軌跡を評価するという区別は、このウィキが 軌跡評価 として記録しているものと同じである。