CodeJudgeBench: Benchmarking LLM-as-a-Judge for Coding Tasks

基本情報

• arXiv ID: 2507.10535v1 (https://arxiv.org/abs/2507.10535)
• 著者: Hongchao Jiang, Yiming Chen, Yushi Cao, Hung-yi Lee, Robby T. Tan
• 所属: ASUS Intelligent Cloud Services (AICS), National Taiwan University
• 投稿日: 2025年7月15日
• カテゴリ: cs.AI, cs.SE

簡単に説明すると

CodeJudgeBenchは、LLM（大規模言語モデル）をコーディングタスクの評価者として使用する能力を測定するベンチマークです。
従来のベンチマークは主にコード生成タスクに限定されていましたが、CodeJudgeBenchはコード生成、コード修復、単体テスト生成の3つのタスクを包括的に評価します。
26のLLMを評価した結果、最新の「thinking models」（推論時に長い思考連鎖を使用するモデル）が優れた性能を示しました。
これらは専門的に訓練されたLLM-as-a-Judgeモデルを上回りました。
しかし、すべてのモデルは応答の提示順序に敏感で、一貫性のある判断を下すことが困難であることも判明しました。
データセットはHugging Face（https://huggingface.co/datasets/mattymchen/codejudgebench ）で公開されています。

1. 研究概要

1.1 背景と動機

大規模言語モデル（LLM）は、コード生成、コード修復、単体テスト生成などの自動ソフトウェアエンジニアリングタスクで大きな進歩を遂げています。
LLMは単にコードを生成するだけでなく、他のモデルや人間が生成した応答の品質を評価する「LLM-as-a-Judge」としての役割も担うようになってきました。

LLM-as-a-Judgeには以下のような利点があります。
第一に、多様なタスクと難易度レベルにわたってモデル出力を比較する一般的なフレームワークを確立することで、LLMのスケーラブルで堅牢な評価を可能にします。
第二に、候補応答のセットから最も正確または最適な解決策を選択する自動応答ランキングを容易にし、全体的なパフォーマンスを向上させます。

しかし、コーディングシナリオにおけるLLM-as-a-Judgeの有効性は、包括的な評価コーパスの欠如により、十分に探究されていません。
既存のLLM-as-a-Judgeベンチマークは、一般的なドメイン向けに設計されており、比較的単純なコーディング問題の小さなサブセットしか含まれていません。
コーディングシナリオに特化したベンチマークでさえ、コード生成タスクのみに焦点を当てる傾向があり、現代のLLMがますます実行可能になっている幅広いコーディング活動を見落としています。

1.2 主要な貢献

本研究の主要な貢献は以下の3点です。

• 新しいベンチマークの提案：コード生成、コード修復、単体テスト生成のためのLLM-as-a-Judgeを評価するために特化した挑戦的なベンチマーク、CodeJudgeBenchを提案
• 包括的な評価：26の人気のあるLLMの性能を評価し、コーディングタスクにおけるLLM-as-a-Judgeの能力をより包括的に明らかにした
• 広範な分析：様々な分析実験を通じて、LLM-as-a-Judgeの性能に影響を与えるさまざまな要因の影響を分析し、開発のための貴重な設計提案を提供

2. 提案手法

2.1 手法の概要

CodeJudgeBenchは、3つの重要なコーディングタスク（コード生成、コード修復、テスト生成）にわたってLLM-as-a-Judgeの能力を評価します。
各データポイントは「指示、良い応答、悪い応答」の3つ組で構成されています。
LLM-as-a-Judgeは両方の応答を評価し、指示をよりよく満たすものを選択するタスクを与えられます。

CodeJudgeBenchの構築は、応答収集、応答検証、応答ペアリングの3つの主要な段階を含みます。
応答収集段階では、各コーディング問題に対してLLMプログラマー（$M_c$）から複数の応答を独立してサンプリングします。
応答検証中、収集された各応答は手動または自動の検証プロセスを通じて注釈付けされ、「良い」または「悪い」として分類されます。
最後に、1つの良い応答と1つの悪い応答をペアリングすることで、LLM-as-a-Judge（$M_j$）の評価インスタンスが構築されます。

高いタスク難易度を維持し、データ汚染リスクを最小限に抑えるため、CodeJudgeBenchはLiveCodeBench-v6に基づいて構築されています。
これは2023年5月から2025年4月の間に公開された1,055の挑戦的なコーディングコンペティション問題で構成されています。

2.2 技術的詳細

コード生成タスクでは、LLM-as-a-Judgeにコーディング問題文と2つの候補コードスニペットが提示されます。
両方ともLLMプログラマーによって生成され、1つは正しく、もう1つは誤っています。
LLM-as-a-Judgeは正しいコードスニペットを正確に識別します。

コード修復タスクでは、LLM-as-a-Judgeに元のコーディング問題文、エラーメッセージ付きの誤ったコードスニペット、および2つの候補コード修復が提示されます。
LLM-as-a-Judgeのタスクは、どの候補が正しい修正を表すかを識別することです。

テスト生成タスクでは、先行研究に従います。
参照実装に依存せずに問題文から直接単体テストを生成することに焦点を当てています。
LLM-as-a-Judgeにはコーディング問題文と2つの候補単体テストケース（入力-出力ペア）が提示されます。

各タスクにおいて、応答の正しさはLiveCodeBenchが提供する包括的な単体テストスイートを使用して検証されます。
すべての単体テストに合格する応答は「良い」として分類され、いずれかのテストに失敗する応答は「悪い」として分類されます。

2.3 新規性

CodeJudgeBenchの新規性は以下の点にあります。

第一に、既存のベンチマークとは異なり、コード生成だけでなく、コード修復と単体テスト生成という2つの追加の広く使用されているコーディングタスクを導入しています。
これにより、LLM-as-a-Judgeの能力をより包括的に評価できます。

第二に、CodeJudgeBenchは4,260サンプルで構成されており、以前のベンチマークと比較して規模が約10倍に増加しています。
データは高性能なLLM（Claude-3.7、Gemini-2.5-Flash、Gemini-2.5-Pro）を使用して生成されており、高品質で多様性があります。

第三に、LiveCodeBenchから継続的に更新される複雑なコーディング競技問題を使用することで、ベンチマークの難易度と関連性を維持しています。
これにより、CodeJudgeBenchは厳格で進化し続けるベンチマークとなっています。

3. 実験結果

3.1 実験設定

26の多様なLLMをCodeJudgeBenchで評価しました。
これには、オープンソースとクローズドソースの両方のモデル、一般ドメインのLLM、コーディングまたはLLM-as-a-Judgeタスク専用にチューニングされたモデルが含まれます。

特に、「thinking models」と呼ばれる新しいクラスのLLMを評価しました。
これらは長い思考連鎖を使用してバックトラッキング、自己検証、反省などの能力を可能にする推論モデルです。
thinking modelsには、DeepCoder-14B、AceReason-14B、Qwen3、QwQ、RM-R1などが含まれます。
Claude 3.7/4、Gemini-2.5-Pro/Flashも含まれます。

評価では、ペアワイズ比較アプローチを使用し、各サンプルペアを2回評価しました。
良い応答を最初（位置A）と2番目（位置B）の候補として交互に配置し、結果を平均化しました。

3.2 主要な結果

Thinking modelsの優位性：thinking modelsは他のモデルを一貫して上回りました。
代表的なモデルにはDeepCoder-14B、AceReason-14B、Qwen3、QwQ、RM-R1があります。
Claude 3.7/4、Gemini-2.5-Pro/Flashも含まれます。
これらのモデルはコード分析により多くのトークンを割り当て、コード応答を理解し正確に判断する能力を向上させています。
注目すべきことに、Qwen3-8Bなどの小規模なthinking modelsでさえ、Prometheus-14BやSelf-Taught 70BなどのCoTモデルを全体的な精度で上回っています。

非thinking modelsの低性能：非thinking modelsは60％未満の精度を達成しました。
これは50％のランダム推測ベースラインに近い値です。
Claude-3.5などの独自モデルやPrometheus-14BなどのLLM-as-a-Judgeタスク専用モデルも含まれます。

タスクの難易度：単体テスト生成の正しさを判断することは、LLM-as-a-Judgeモデルにとって最も困難で、次にコード生成、コード修復が最も簡単でした。
これは、コード生成とコード修復がより一般的なタスクであり、訓練中により頻繁に遭遇するためと考えられます。

3.3 既存手法との比較

CodeJudgeBenchを既存のベンチマーク（JudgeBenchやRMBench）と比較すると、すべてのモデルがCodeJudgeBenchで10-30%低い精度を示しました。
例えば、Gemini-2.5-ProはJudgeBenchで95%以上の精度を達成していますが、CodeJudgeBenchではそれより低い性能を示しています。

これは、CodeJudgeBenchが高性能なthinking modelsを使用してデータを生成し、難しいコーディング問題でも挑戦的な応答ペアを構築できるためです。
対照的に、以前のベンチマークはGPT-4oなどの弱いモデルに依存することが多く、十分に挑戦的なデータポイントを生成するのに苦労しています。

4. 実用性評価

4.1 実装の容易性

CodeJudgeBenchは、LiveCodeBenchの既存のインフラストラクチャを活用して構築されており、実装が比較的簡単です。
評価プロセスは明確に定義されており、各タスクに対して標準化されたプロトコルが提供されています。

データセットはHugging Faceで公開されており、研究者が簡単にアクセスして使用できます。
また、LiveCodeBenchから新しくリリースされた問題を組み込むことで、CodeJudgeBenchを将来的にシームレスに拡張できます。

4.2 計算効率

評価プロセスは計算効率が高く、各モデルは各データポイントに対して2回の推論（位置AとBの評価）のみを実行します。
ペアワイズ比較アプローチは、ポイントワイズ評価よりも効率的であることが示されています。

thinking modelsは長い推論チェーンを生成するため、より多くの計算リソースを必要としますが、その優れた性能により、追加のコストが正当化されます。

4.3 応用可能性

CodeJudgeBenchは幅広い応用可能性を持っています。

モデル開発：研究者はCodeJudgeBenchを使用して、コーディングタスクのためのより良いLLM-as-a-Judgeモデルを開発できます。
特に、thinking modelsの自己検証能力を活用する新しいアプローチの開発が期待されます。

自動コード評価：ソフトウェア開発環境で、複数の候補ソリューションから最適なものを自動的に選択するために使用できます。

教育ツール：プログラミング教育において、学生のコード提出物を自動的に評価し、フィードバックを提供するツールの開発に活用できます。

継続的改善：LiveCodeBenchの継続的な更新により、CodeJudgeBenchは最新のコーディング課題に対応し続けることができます。

5. まとめと所感

5.1 論文の意義

この研究は、コーディングタスクにおけるLLM-as-a-Judgeの能力を包括的に評価する初めてのベンチマークを提供しています。
thinking modelsの優位性を明確に示し、従来の非thinking modelsやCoTモデルの限界を露呈させました。

特に重要なのは、LLM-as-a-Judgeモデルが応答の提示順序に非常に敏感であり、一貫性のある判断を下すことが困難であるという発見です。
これは、実用的なアプリケーションでLLM-as-a-Judgeを使用する際の重要な課題を示しています。

また、ペアワイズ評価がポイントワイズ評価よりも優れており、前処理なしの完全な応答を提供することが最良の性能につながることも示されました。
これらの知見は、将来のLLM-as-a-Judgeシステムの設計に重要な示唆を与えています。

5.2 今後の展望

今後の研究では、以下の方向性が期待されます。

ロバスト性の向上：応答の提示順序や異なるLLMプログラマーによって生成された応答に対するロバスト性を向上させる手法の開発が必要です。

専門的な訓練：コーディングタスク専用のLLM-as-a-Judgeモデルの訓練方法を改善し、thinking modelsの利点を活用する新しいアプローチの開発が期待されます。

タスクの拡張：CodeJudgeBenchにさらに多様なコーディングタスク（例：リファクタリング、セキュリティ脆弱性の検出）を追加することで、より包括的な評価が可能になります。

実用化への道筋：LLM-as-a-Judgeの一貫性と信頼性を向上させ、実際のソフトウェア開発環境での採用を促進する研究が必要です。

CodeJudgeBenchは、コーディングタスクにおけるLLM-as-a-Judge研究の新しい基準を確立しました。
より効果的で信頼性の高い自動コード評価システムの開発を促進する重要な貢献と言えるでしょう。