ReviewBench：AIコードレビュー用のオープンベンチマーク

エージェント型コードレビューは、開発プロセスにおいて不可欠な要素となっている。これにより、プルリクエストをチェックしたり、問題を発見したり、コードがリリースされる前にどの部分に注意を払うべきかを決定することができる。

しかし、既存のAIレビュアーの品質は測定が難しい場合があり、それがあなたを助けるかどうかを知る前に、そのレビュアーの長所を把握する必要があります。あるレビュアーはより多くの問題を明らかにし、あるレビュアーはノイズが少なく、またあるレビュアーは重要な問題を発見する能力が高い一方で、他のレビュアーは小さな改善も明らかにします。ワークフロー内で異なることを行うには、コードレビューが必要になることもあります。

そのため、レビュアーが実際にどのように比較するかを理解することが重要である。何が異なるシステムによって捉えられ、何が見落とされるのか、そして彼らがどのようなトレードオフを行うのかだ。良いコードレビューベンチマークは、実際のpull requestの多様性を反映し、幅広いレビュー結果を収集し、重大度、カテゴリー、精度・再認の好みに基づく意味のある分析を支援するものでなければならない。 コードレビューエージェントを構築するチームにとって、ベンチマークはまた、変更が実際の運用環境での体験を向上させる可能性があるかどうかを確実に追跡できるオフライン信号も提供するべきである。既存のベンチマークはしばしば、ラベルの品質、カバレッジ、そして実世界のコードレビューをどれだけよく表現しているかの間で妥協を迫るが、これらの要素を統合する厳密で再現可能な評価方法論の余地が生じている。

そのギャップを解消するために、ReviewBenchという新しいオフラインコードレビューベンチマークを構築しました。今すぐ使用できる状態です。このベンチマークは、GitHub上の1億万件以上の実際のプルリクエストを参考に、言語、リポジトリのサイズ、プルリクエストのサイズ分布をモデル化しています。多源金銭セットと一貫した評価基準を用い、シニアエンジニアによって独立して検証されています。同様に重要なのは、ReviewBenchの助けを借りて、Copilotコードレビュー（CCR）のオフライン評価が、生産実験の方向性を予測する能力が向上し、測定された改善がユーザーにとって有意な成果であるという確信を高めることです。

この記事では、ReviewBenchがどのように構築されるか、信頼性の高い基準とスコアリングがどのように確立されるか、そして自分のコードレビューシステムを導入して結果を提出する方法について説明します。

私たちが作ったもの

現実的で包括的なAIコードレビューエージェントのベンチマーク

GitHubのプルリクエスト

言語、リポジトリのサイズ、変形形状によって分布を分析する。

代表ベンチマークコーパス

219件の公開Pull Requestが19言語で行われ、実質的なレビューケースは保持されながら、GitHub全体の配布に合わせられている。

マルチソースゴールドセット

• 人間のレビュアー
• フロンティアLLM
• 静的解析

構造化された結果

すべての検出結果には、重大度とカテゴリーがラベル付けされており、ユーザーがカスタマイズできるセットを提供します。

深刻度

• 重要
• 中型
• 低い

カテゴリー

• 正確性
• セキュリティ
• 信頼性
• 維持可能性
• テスト
• ......

評価指標

4つの指標により、既知の問題と新たに発見された問題の両方を測定する。

• 基礎に立つ精度
• 基礎的な記憶
• 拡張精度
• 拡張された記憶

客観的な評価

改善度を測定し、エージェント間で客観的に比較する。ユーザーが自分のニーズに最も適したレビュアーを選べるように支援する。

私たちが信頼性を保つ方法

ルーブリックから専門家の検証、製造チェックまでの可視性のあるチェーン

発表用評価基準

すべての結果に対する明確な基準。

人間がラベルを付けた開発データセット

シニアエンジニアが基準値を定める。

校正済み評価器

人間の判断に沿って。

均一なラベル付け

すべての情報源で同じ基準です。

発行された契約

ベンチマークの品質に関する専門家による監査。

可視化可能なエンドツーエンド

96.6％の同意

シニアエンジニアがリリース前に、独立してゴールド・トゥルーポジティブをマークした。

生産を予測するオフライン信号

ベンチマークの動きはオンライン実験で確認されます。

• 改善点はオンライン上で現れる傾向があります
• 回帰現象はオンラインでも現れる傾向がある

ReviewBenchがどのように機能するか

私たちのベンチマークは5つの原則に基づいて構築されています：

1. デモセットではなく、代表的なpull requestです

103.9百万件のGitHubプルリクエストを分析し、コードレビュー作業負荷の実世界における分布を明らかにした。ReviewBenchには、19種類の言語を含む187の公開オープンソースライセンスリポジトリからの219件のプルリクエストが含まれており、その言語とリポジトリの規模の分布はGitHub全体とよく一致している。完全なベンチマークデータセットは公開されている。

この分布に対して一つの意図的な調整を行います。言語とリポジトリのサイズはGitHubを直接反映しますが、プルリクエストのサイズはレビュー可能な中間部分および端部分に重みがかかります。これにより、小さく単一ファイルの変更が過度に多くなることを減らし、レビュー品質が最も重要であるより実質的な複数ファイルのプルリクエストをより多く保持するようになります。

クイックコーパススナップショット：

2. 広範な真実の発見、独立して判断される

人間のレビュアーでもモデルでも、プルリクエストに含まれるすべての価値ある内容を特定できるわけではありません。より広範で信頼性の高いゴールドセットを構築するために、私たちは3段階のプロセスを採用しています：

• さまざまな情報源から候補者の結果を集める。私たちは、実際の人間レビュアーからの結果、著者が後続コミットメントから推測される問題点、決定的分析ツール、そして様々なモデルファミリーに属する複数のフロンティアLLMからの結果を収集しています。
• 意味論的に重複する発見を同一と認定する。同じ根本的な問題を特定する発見を統合し、プロダクター間の合意を許さずにカバレッジを拡大することで、ゴールドセットを人為的に膨らませたり、ある一つの情報源の限界に依存させたりすることを防ぐ。
• 共有された評価基準に基づいて結果を検証する。 結果の出所が正しいかどうかは決定しない。ある結果が真実であり、関連性があり、非単純的である場合にのみ、真の陽性とみなされる。私たちはClaude Sonnet 5をLLM評価器として使用し、すべての提出物に対して一貫した評価基準を適用する。透明性と再現性のために、評価基準とその適用に使用された審査員の情報も公開する。

3. 既知の問題と新たに発見された問題の両方を測定する指標

ほとんどのベンチマークは、固定されたゴールドセットに対する精度と再現率を報告します。ReviewBenchは2つのカテゴリーに分けて6つの指標を報告します：

• 基準に基づく精度、再検出率、F1スコアは、既存のゴールドセットのラベルのみを使用します。これにより、厳格で同等な比較が可能になります。すでに知っている問題の中で、エージェントがどれだけ見つけたか、そしてその発見のうちどれだけが既知の問題に対応しているかが明らかになります。
• 追加された精度、再検出率、F1スコアは、ゴールドセットに含まれない結果も評価します。審査員は、マッチしない結果が正しい陽性か陰性かを独立して判断し、ゴールドセットの製作者が指摘しなかった有効な問題に対して審査員に評価を与えることができます。

レビューエージェントがより能力を高めるにつれて、その区別はより重要になります。システムが創作者が予期していなかった問題を発見するようになると、固定されたゴールドセットは必然的に不完全になります。拡張された指標により、ReviewBenchはその行動を自動的にペナルティすることなく、それを認識できるようになります。拡張された想起能力が各エージェントが発見する内容に基づいて分母を拡大するため、私たちは「グラウンドド・リコール」をクロスシステム比較の目次として、拡張された指標を各システム別の診断手段として使用します。

4. 異なるレビュー希望に応じた設定可能な評価

唯一の最適なレビュー体験というものは存在しない。一部の開発者は重要な問題にのみ焦点を当てたいと思うかもしれないが、他の人々は軽微な非障害的な発見も重視する。ある人々はより広範なカバレッジを好むが、他の人々は精度と最小限のノイズを優先する。また、セキュリティやプライバシーに重点を置いたレビューといった特別なニーズを持つ人もいる。

ReviewBenchでは、結果をセービリティとカテゴリーによって分けることができ、精度と再検出率は異なる動作の好みを反映します。ユーザーはFβスコアにおけるβ値を調整することで、より広いカバレッジのための再検出率や、ノイズが少ない精度のための精度に重視度を変えることができます。これらの好みが変わるにつれて、ランキングはそれに応じて再ランク付けされ、ユーザーが自身のレビューの優先順位に最も合致するシステムを見つけるのに役立ちます。

5. 内部監査を受け、再現性のある評価が行われている

リリース前に、ベンチマークデータセットの構築に参加していないシニアエンジニアに、全てのグロウントラッシュ結果を一から再ラベル付けするよう依頼しました。彼らの真偽陽性判断は、ReviewBenchと96.6％一致しました。各評価で使用されるベンチマークデータセット、評価ツール、マッチャーをバージョンアップすることで、同じベンチマーク設定の下で結果を比較でき、ベンチマークが変更された際に再検証することができます。 検証方法、合意度の測定値、そして妥当性に与える可能性のある脅威についても公開しているため、読者はベンチマークの品質がどのように評価されるか、また不確実性が存在する場所が何であるかを把握できます。

Explore ReviewBench

ReviewBenchの研究プレビュー版が、ReviewBenchウェブサイトを通じて利用可能になりました。ここでは、完全なベンチマークを調査したり、コードレビューエージェントを比較したり、自分のエージェントを使って評価し、改善を行うことができます。

ReviewBenchを使えば、以下のことができます：

• 完全なベンチマークデータセットを探索しよう。 ReviewBenchデータセット全体が公開されており、プルリクエスト、調査結果、ラベル、深刻度、カテゴリーのアノテーションも含まれています。これにより、どのシステムが評価されているかを正確に確認し、ベンチマーク結果を再現することができます。
• リーダーボード上でシステムを比較する。完全なベンチマークデータを使用したコードレビューエージェントの結果が、全体的な性能、深刻度、カテゴリー、および異なる精度・再認率の好みに関する視点を持つ共通のリーダーボード上で公開される。
• 自分のエージェントを持って、ヒルクライムに挑もう。完全なベンチマークデータセット、評価方法論、LLMジャッジプロンプト、ジャッジモデルの設定、および自動実行者が公開されているため、自分のコードレビューエージェントを評価し、その強みと課題を確認し、同じベンチマーク設定で改善を続けることができます。

私たちがReviewBenchをどのように使用したか

私たちはReviewBenchを使用して、Copilot code review（CCR）を何度も実施しました。これにより、進捗を測定したり、問題点を発見したり、有望な変更を優先することができる一貫した方法が確立されました。時間が経つにつれて、これによって製品の改善に役立ちました。ReviewBenchの最も価値のある利点の一つは、製品への変更が実際の運用でどのように機能するかについて、早期にオフラインの信号を提供することができる点です。A/Bテスト前にReviewBenchで評価された実験において、オフラインの変更は、後に実際の運用で見られる結果と同じ方向に一致していました。

最近のライトレベルの実験が、このより広範なパターンの具体的な例を示しています。私たちは、単一の実行に依存するのではなく、複数の独立したモデル実行を一つのレビューに統合したマルチモデルアンセムレビューを導入しました。ReviewBenchでは、より高い精度、再検出率、コメント量、そしてレビューのコストが低くなることが予測されました。

オフラインとプロダクションの結果を比較するため、対応するオンライン信号を使用します。アドレス率は、精度に対応するオンラインの指標であり、diff、スレッド、反応、解決状態、レビュー後のコードに基づき、LLMが開発者に対応するコード変更を行うよう促したCCRコメントの割合です。再想起については、まだどれだけ追加の人間によるレビューが必要かを測定します。

オンラインのA/BテストはReviewBenchが予測した方向に進んだ：解決率（精度）は8.0％上昇し、再検出率は13.6％上昇し、コメント量は61％上昇した。一方で、レビューのコストは8.0％下がった。これらはすべて、生産管理を基準としたものである。

ただし、コメントの量だけではコメントの質を把握することはできません。より重要な発見は、軽度のニットとは全く異なる意味を持ちます。ReviewBenchのセリジーレベルの評価もこれを捉えています：オンラインでの262％に対し、重要なコメントが227％増加すると予測され、またより適度なコメントや少ないニットへと広がる傾向も見られました。

生産実験を実施する前に、迅速で再現可能なシグナルを得ることができます。オンライン実験はユーザーの影響度を測る最終的な指標ですが、ReviewBenchを使うことで、どの変更が価値があるかについてより高い信頼感を持つことができます。

自分の実行結果をどう提出するか

1. GitHubでログインする 上に ReviewBench ウェブサイト。
2. エージェントを登録してください。 コンテナイメージ、設定、そして自分のモデルキーを提供してください。私たちがジャッジを提供します。
3. テストセットで試してみてください。 25-PRのテストセットに対して実行し、各PRの詳細を確認しながら設定を調整し続けてください。
4. 最後の実行を行ってください。準備ができたら、219件のPull Requestを全て実行してください（3ラウンド）。評価は他のすべての案件と同じ審査員によって行われます。
5. リーダーボードに公開します。 メンテナーが提出をレビューし承認するまで、お名前のスコアはプライベートのままです。スコアがエージェントの現在のリーダーボードスコアを上回る場合、またはこのエージェントの初めてのリーダーボード記録である場合にのみ、リーダーボードに公開されます。

ReviewBenchをご覧になり、自分のシステムを評価し、私たちの仮定に挑戦し、ベンチマークの改善に貢献してほしい。研究者や実務家と協力して、コードレビュー評価をより開かれた、信頼性の高い、有用なものにし、最終的にAIコードレビューの発展に寄与することに喜びを感じている。

謝辞

ReviewBenchはGitHubとMicrosoftを横断したチームの努力の成果でした。それを作成した研究者やエンジニアに感謝します。方法論を設計し、Pull Requestを整理し、ゴールドセットと評価パイプラインを構築し、誰でも実行できるベンチマークになるようにした人々です。

ReviewBench：AIコードレビューのオープンベンチマークという記事が、GitHubブログに最初に掲載されました。