コーディングエージェント評価は実際の開発フローに合わせるべき

導入

コーディングエージェントの評価では、リポジトリのissueを与え、コードを変更してテストを通過できるかを測る形式が広く使われています。この形式は比較しやすい一方、開発者が実際にエージェントとどのように会話するかを十分に表しているとは限りません。Hugging Face Daily Papersで紹介された研究は、最終的なコード変更だけでなく、そこに至る対話の流れも評価対象にすべきだと論じています。

実際のセッションは単一タスクではない

研究者は、JetBrains IDE内でソフトウェアエンジニアがエージェントを利用した4782件のセッションを収集し、これをProduction Sessionsと呼びました。対話型エージェントに焦点を当てるため、ユーザーメッセージが少なくとも3回ある長いセッションを分析対象にしています。これはサンプルのおよそ3分の1です。

従来のissue由来タスクと比べ、実際のセッションには主に二つの違いがあります。

• プロジェクトのコードに関する質問、計画、レビュー、リファクタリング、実行など、要求の種類が広い。
• セッション中にユーザーがタスクの種類を切り替える。コードを理解した後に計画を求め、続いて変更と確認を依頼する、といった流れです。

さらに研究では、三つの公開インタラクションコーパスに含まれる長いセッションを比較しました。その結果、セッションの長さ、タスク種別の分布、種別間の遷移には大きな違いがありました。したがって、すべての用途に共通する「現実的な」対話分布が一つ存在するわけではありません。IDE支援なのか、issue解決なのか、別の用途なのかを明確にし、その用途の測定値に合わせてベンチマークを調整する必要があります。

SWE-TaskFlowの考え方

論文が提案するSWE-TaskFlowは、issue由来ベンチマークを捨てるのではなく、検証済みのタスクとテストを維持したまま対話の形を変えます。プロンプトを分割し、リポジトリに関する検証可能な質問を加えることで、エージェントを目標となるTask Flowへ誘導します。生成された複数の軌跡から、目標フローとの一致度が高いものをTaskFlow Alignment Scoreで選択します。

これにより、二つの評価を分けて考えられます。一つは最終変更がタスクとテストを満たすかどうか。もう一つは、会話の進み方が想定したユーザー体験に合っているかどうかです。セッション長、作業の組み合わせ、タスク間の遷移も、測定可能な評価項目になります。

多段階化はコストを変える

700件のSWE-Bench Proタスクを使った試行では、タスクを複数の手順に分けるとエージェントのコストはおよそ2倍になりました。一方、解決率には安定した変化がありませんでした。これは多ターン対話に価値がないという意味ではなく、対話プロトコルを変えるだけで資源消費が大きく変わり、成功率が自動的に上がるわけではないことを示します。

今後の評価では、pass rateだけでなく、対象とする開発フロー、対話コスト、軌跡の一致度も併記する必要があります。コーディングエージェントが支援するのは孤立した修正問題ではなく、実際の開発プロセスだからです。

出典：Hugging Face Daily Papers