📄 ICLR 2025論文解説: JudgeBench --- LLM-as-Judgeの評価ベンチマーク

論文概要（Abstract）

JudgeBenchは、LLMを評価者（Judge）として使用する際の信頼性を体系的に測定するベンチマークである。著者らは、知識（Knowledge）、推論（Reasoning）、数学（Math）、コーディング（Coding）の4領域にわたる350問の困難な応答ペアを構築し、客観的な正解ラベルに基づいてLLM-based Judgeの判定精度を評価する。論文の実験結果では、GPT-4oのような強力なモデルでもランダム推測をわずかに上回る程度の精度しか達成できないことが報告されており、現行のLLM Judge手法の限界が明らかにされている。

この記事は Zenn記事: LangGraphマルチエージェントRAGの評価フレームワーク設計と協調品質の定量化 の深掘りです。

情報源

• 会議名: ICLR 2025（International Conference on Learning Representations）
• 年: 2025
• URL: https://arxiv.org/abs/2410.12784
• 著者: Sijun Tan, Siyuan Zhuang, Kyle Montgomery, William Y. Tang, Alejandro Cuadron, Chenguang Wang, Raluca Ada Popa, Ion Stoica（UC Berkeley）
• 発表形式: Poster
• GitHub: https://github.com/ScalerLab/JudgeBench

カンファレンス情報

ICLR（International Conference on Learning Representations） は機械学習分野における最高峰の国際会議の1つである。ICLR 2025では11,565件の投稿に対して採択率は約32%であり、競争率は高い。JudgeBenchはPosterとして採択されている。ICLR 2025では213件のOral発表と85件のSpotlight発表が選ばれており、Posterを含めた全体の採択数は約3,700件である。

技術的詳細（Technical Details）

困難な応答ペアの構築パイプライン

JudgeBenchの核心は、既存の困難なデータセットを「Judgeにとって判定困難な応答ペア」に変換するパイプラインにある。著者らは以下の手順で応答ペアを構築している。

1. 応答サンプリング: 強力なLLM（GPT-4oまたはClaude-3.5-Sonnet）を用いて、各問題に対し$k$個の応答を生成する
2. 正解判定: 各応答を客観的な基準（数学なら数値一致、コーディングならテスト通過）でグレーディングする
3. 困難ペア選定: 正解応答と不正解応答のペアを構築し、表面的には区別しにくいが客観的正解が明確なペアを選択する

\[\text{Pair}(q) = \{(r_{\text{correct}}, r_{\text{incorrect}}) \mid r_{\text{correct}} \in R_{\text{pass}}(q), \, r_{\text{incorrect}} \in R_{\text{fail}}(q)\}\]

ここで、

• $q$: 入力された質問
• $R_{\text{pass}}(q)$: 質問$q$に対する正解応答の集合
• $R_{\text{fail}}(q)$: 質問$q$に対する不正解応答の集合

評価プロトコル

各応答ペアは2回評価される。応答の提示順序を入れ替え（Position Swap）、両方の順序での判定を集約して最終的な判定とする。これにより、LLM Judgeに知られているPosition Biasの影響を緩和している。

\[\text{Agreement}(J, q) = \mathbb{1}\left[J(r_A, r_B) = J(r_B, r_A) = \text{label}(q)\right]\]

ここで、

• $J$: LLM Judge関数
• $\mathbb{1}[\cdot]$: 指示関数（条件が真なら1、偽なら0）
• $\text{label}(q)$: 質問$q$の客観的正解ラベル

データセット構成

領域	問題数	ソースデータセット
Knowledge	154	MMLU-Pro
Reasoning	98	GPQA, ARC-Challenge
Math	56	MATH, GSM8K
Coding	42	HumanEval, MBPP
合計	350	-

GPT-4o生成ペアが350組、Claude-3.5-Sonnet生成ペアが270組の2つのスプリットが用意されている。

アルゴリズム

from dataclasses import dataclass
from typing import Literal

@dataclass
class ResponsePair:
    """JudgeBench応答ペア

    Attributes:
        question: 評価対象の質問
        response_a: 応答A
        response_b: 応答B
        label: 客観的正解ラベル（"A" or "B"）
    """
    question: str
    response_a: str
    response_b: str
    label: Literal["A", "B"]

def evaluate_judge(
    judge_fn: callable,
    pairs: list[ResponsePair],
) -> float:
    """JudgeBenchによるLLM Judge評価

    Position Swapを行い、両順序で一致した場合のみ正解とする。

    Args:
        judge_fn: LLM Judge関数（2つの応答を受け取りA/Bを返す）
        pairs: 評価対象の応答ペアリスト

    Returns:
        Agreement Rate（0.0-1.0）
    """
    correct = 0
    for pair in pairs:
        # 順序1: A, B
        verdict_1 = judge_fn(pair.response_a, pair.response_b)
        # 順序2: B, A（Position Swap）
        verdict_2 = judge_fn(pair.response_b, pair.response_a)
        # 順序2の結果を反転して比較
        verdict_2_flipped = "B" if verdict_2 == "A" else "A"

        if verdict_1 == pair.label and verdict_2_flipped == pair.label:
            correct += 1

    return correct / len(pairs)

査読者の評価（Peer Review Insights）

JudgeBenchはICLR 2025にPosterとして採択されている。OpenReviewでの公開レビューによると、主な評価ポイントは以下の通りである。

• 強み: 客観的正解に基づく評価フレームワークの設計が高く評価されている。従来のベンチマーク（MT-Bench、Chatbot Arena等）が主観的な人間の好みに依存していたのに対し、JudgeBenchは事実的・論理的正確性に基づく客観的評価を可能にしている点が新規性として認められている。
• 強み: 4領域にわたる包括的な評価と、Position Swap手法によるバイアス緩和が体系的である点も評価されている。
• 課題: データセットサイズ（350問）の妥当性や、特にCoding領域（42問）のサンプル数が統計的に十分かという指摘がなされている。

実装のポイント

JudgeBenchを自身の評価パイプラインに組み込む際の実装上の注意点を以下に示す。

1. Position Swapの実装: 応答ペアの順序を入れ替えて2回評価する必要がある。応答順序をランダムにするだけでは不十分であり、両方の順序で一貫した判定が得られるかを検証する必要がある。
2. プロンプトテンプレートの選択: 論文ではVanilla、Arena-Hard、PandaLM、Prometheus 2、JudgeLM、AutoJ、Skywork-Criticの7種類のプロンプトテンプレートが評価されている。用途に応じたテンプレート選択が精度に影響する。
3. Reward Modelとの比較: Prompted JudgeだけでなくReward Model（InternLM2、GRM-Gemma等）との比較も可能であり、用途に応じた手法選択が求められる。
4. API並行制御: run_judge.pyでは--max_workersパラメータで並行リクエスト数を制御できる。レートリミットを考慮した設定が必要である。

Production Deployment Guide

JudgeBenchの知見をプロダクション環境のLLM-as-Judge評価パイプラインに適用するための構成を以下に示す。

AWS実装パターン（コスト最適化重視）

JudgeBenchの評価手法（Position Swap + 複数ドメイン評価）をプロダクションのLLM Judge品質監視に適用する場合のAWS構成を示す。

コスト試算の注意事項: 以下は2026年2月時点のAWS東京リージョン料金に基づく概算値である。最新料金はAWS料金計算ツールで確認を推奨する。

構成	トラフィック	主要サービス	月額概算
Small	~100 eval/日	Lambda + Bedrock + DynamoDB	$50-150
Medium	~1,000 eval/日	ECS Fargate + Bedrock Batch	$300-800
Large	10,000+ eval/日	EKS + Karpenter Spot + Bedrock Batch	$2,000-5,000

Small構成: Position Swap含め200 calls/日をLambda（256MB, 120s timeout）で処理し、DynamoDB On-Demandに保存する。Medium構成: Batch APIで50%削減、ElastiCacheでプロンプトキャッシュ。Large構成: Spot Instancesで90%、Batch APIで50%、Prompt Cachingで30-90%のコスト削減を併用する。

Terraformインフラコード

Small構成（Serverless）: Lambda + Bedrock + DynamoDB

# JudgeBench LLM-as-Judge 評価パイプライン - Small構成
# 2026年2月時点の設定

resource "aws_iam_role" "judge_lambda" {
  name = "judgebench-eval-lambda-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "judge_lambda_policy" {
  name = "judgebench-eval-policy"
  role = aws_iam_role.judge_lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["bedrock:InvokeModel"]
        Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-sonnet-*"
      },
      {
        Effect   = "Allow"
        Action   = ["dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:Query"]
        Resource = aws_dynamodb_table.eval_results.arn
      }
    ]
  })
}

resource "aws_dynamodb_table" "eval_results" {
  name         = "judgebench-eval-results"
  billing_mode = "PAY_PER_REQUEST"  # On-Demand
  hash_key     = "eval_id"
  range_key    = "timestamp"
  attribute { name = "eval_id"; type = "S" }
  attribute { name = "timestamp"; type = "S" }
  server_side_encryption { enabled = true }
}

resource "aws_lambda_function" "judge_evaluator" {
  function_name = "judgebench-evaluator"
  runtime       = "python3.12"
  handler       = "handler.evaluate"
  role          = aws_iam_role.judge_lambda.arn
  timeout       = 120  # Position Swap含む2回呼び出し
  memory_size   = 256
  filename      = "lambda.zip"
  environment {
    variables = {
      DYNAMODB_TABLE = aws_dynamodb_table.eval_results.name
      BEDROCK_MODEL  = "anthropic.claude-3-5-sonnet-20241022-v2:0"
    }
  }
  tracing_config { mode = "Active" }
}

Large構成（Container）: EKS + Karpenter + Spot Instances

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "~> 20.31"
  cluster_name    = "judgebench-eval-cluster"
  cluster_version = "1.31"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnets
  cluster_endpoint_public_access = false
}

resource "kubectl_manifest" "karpenter_nodepool" {
  yaml_body = yamlencode({
    apiVersion = "karpenter.sh/v1"
    kind       = "NodePool"
    metadata   = { name = "judgebench-spot" }
    spec = {
      template = { spec = { requirements = [
        { key = "karpenter.sh/capacity-type", operator = "In",
          values = ["spot", "on-demand"] },
        { key = "node.kubernetes.io/instance-type", operator = "In",
          values = ["m5.large", "m5a.large", "m6i.large"] }
      ]}}
      limits     = { cpu = "100", memory = "200Gi" }
      disruption = { consolidationPolicy = "WhenEmptyOrUnderutilized" }
    }
  })
}

resource "aws_budgets_budget" "monthly" {
  name         = "judgebench-monthly"
  budget_type  = "COST"
  limit_amount = "5000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"
  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["ops@example.com"]
  }
}

運用・監視設定

CloudWatch Logs Insights クエリ:

# コスト異常検知: 1時間あたりのBedrock呼び出し回数
fields @timestamp, @message
| filter @message like /bedrock/
| stats count(*) as invocation_count by bin(1h)
| filter invocation_count > 500

CloudWatch アラーム + X-Ray設定（Python）:

import boto3
from aws_xray_sdk.core import xray_recorder, patch_all

patch_all()  # boto3自動計装
xray_recorder.configure(service="judgebench-evaluator")

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

def create_bedrock_alarm(sns_topic_arn: str) -> None:
    """Bedrockトークン使用量スパイク検知アラームを作成"""
    cloudwatch.put_metric_alarm(
        AlarmName="judgebench-bedrock-token-spike",
        MetricName="InputTokenCount",
        Namespace="AWS/Bedrock",
        Statistic="Sum",
        Period=3600,
        EvaluationPeriods=1,
        Threshold=500000,
        ComparisonOperator="GreaterThanThreshold",
        AlarmActions=[sns_topic_arn],
    )

@xray_recorder.capture("evaluate_pair")
def evaluate_pair(pair: dict, bedrock_client: boto3.client) -> dict:
    """応答ペアの評価（X-Rayトレース付き）"""
    subsegment = xray_recorder.current_subsegment()
    subsegment.put_annotation("domain", pair["source"])
    verdict_1 = invoke_judge(bedrock_client, pair["response_a"], pair["response_b"])
    verdict_2 = invoke_judge(bedrock_client, pair["response_b"], pair["response_a"])
    result = {
        "agreement": verdict_1 == pair["label"] and flip(verdict_2) == pair["label"],
    }
    subsegment.put_metadata("result", result)
    return result

Cost Explorer自動レポート（Python）:

import boto3
from datetime import datetime, timedelta

def daily_cost_report(sns_topic_arn: str) -> dict:
    """日次コストレポートを取得し$100超過でSNS通知"""
    ce = boto3.client("ce", region_name="us-east-1")
    end = datetime.utcnow().strftime("%Y-%m-%d")
    start = (datetime.utcnow() - timedelta(days=1)).strftime("%Y-%m-%d")
    response = ce.get_cost_and_usage(
        TimePeriod={"Start": start, "End": end},
        Granularity="DAILY",
        Metrics=["UnblendedCost"],
        Filter={"Tags": {"Key": "Project", "Values": ["judgebench"]}},
        GroupBy=[{"Type": "SERVICE", "Key": "SERVICE"}],
    )
    total = sum(
        float(g["Metrics"]["UnblendedCost"]["Amount"])
        for r in response["ResultsByTime"] for g in r["Groups"]
    )
    if total > 100:
        boto3.client("sns", region_name="ap-northeast-1").publish(
            TopicArn=sns_topic_arn,
            Subject="JudgeBench Cost Alert",
            Message=f"Daily cost exceeded $100: ${total:.2f}",
        )
    return {"date": start, "total_cost": total}

コスト最適化チェックリスト

アーキテクチャ選択:

• トラフィック量に応じた構成を選択（~100/日: Serverless、~1,000/日: Hybrid、10,000+/日: Container）
• 非リアルタイム評価にはBatch処理構成を検討

リソース最適化:

• EC2/EKSノード: Spot Instances優先（最大90%削減）
• Reserved Instances: 1年コミットで最大72%削減
• Savings Plans: Compute Savings Plansで柔軟な割引
• Lambda: メモリサイズをPower Tuningで最適化
• EKS: Karpenterによるアイドル時自動スケールダウン
• NAT Gateway: VPCエンドポイントで代替しコスト削減

LLMコスト削減:

• Bedrock Batch API使用（非同期評価で50%削減）
• Prompt Caching有効化（同一テンプレート再利用で30-90%削減）
• モデル選択ロジック（簡易評価にはHaikuクラス、困難な評価にはSonnetクラスを使い分け）
• トークン数制限（応答の最大トークン数を制限）
• 評価結果キャッシュ（同一ペアの再評価を回避）

監視・アラート:

• AWS Budgets: 月次予算アラート（80%到達時に通知）
• CloudWatch アラーム: Bedrock呼び出し回数・トークン使用量
• Cost Anomaly Detection: 自動異常検知の有効化
• 日次コストレポート: Cost Explorer + SNS通知
• X-Ray: 評価パイプラインのレイテンシ監視

リソース管理:

• 未使用リソースの定期削除（CloudWatch不要ロググループ等）
• タグ戦略: Project=judgebench, Environment=prod/devを全リソースに付与
• ライフサイクルポリシー: S3評価データの90日後Glacier移行
• 開発環境の夜間自動停止（EventBridge + Lambda）
• DynamoDB TTL: 古い評価結果の自動削除

実験結果

著者らが報告している主要な実験結果を以下に示す。GPT-4o生成ペアに対するAgreement Rateの比較（論文Table 1より引用）である。

モデル	Overall	Knowledge	Reasoning	Math	Coding
o1-preview	75.4%	-	-	-	-
o1-mini	65.7%	-	-	-	-
Claude-3.5-Sonnet	64.3%	-	-	-	-
GPT-4o (Vanilla)	~50%	-	-	-	-

著者らは以下の知見を報告している。

• o1-previewが最高精度: Chain-of-Thought推論を内蔵するo1-previewが75.4%で最高のAgreement Rateを達成している
• GPT-4oはランダム推測に近い: Vanillaプロンプトを使用した場合、GPT-4oの精度はランダム推測をわずかに上回る程度であると報告されている
• Solver-Judge乖離: Coding領域ではSolver（問題を解く能力）がJudge（判定能力）を一貫して上回り、Math領域ではJudgeがSolverを上回るという非対称性が確認されている
• 自己評価の困難さ: Claude-3.5-SonnetはGPT-4o生成ペアに対しては64.3%を達成するが、自身が生成したペアに対しては44.8%に低下するという自己評価バイアスが報告されている

実運用への応用

JudgeBenchの知見は、マルチエージェントRAGシステムの評価フレームワーク設計に直接的に応用可能である。

LLM-as-Judge品質監視への適用:

• Zenn記事で解説されているLangGraphベースのマルチエージェントRAGでは、各エージェントの出力品質をLLM Judgeで評価する設計が採用されている。JudgeBenchの結果は、単一のLLM Judgeに依存する評価が不十分であることを示しており、Position Swap手法やマルチドメイン評価の導入が品質向上に寄与する

プロダクション視点での示唆:

• Judge選択: o1クラスの推論特化モデルをJudgeとして使用することで精度が向上する。ただしコストとレイテンシのトレードオフを考慮する必要がある
• ドメイン別最適化: 4領域で精度が大きく異なるため、評価対象のドメインに応じたJudge選択やプロンプトテンプレートの使い分けが推奨される
• 自己評価回避: 同一モデルで生成と評価を行うと精度が低下するため、生成モデルとJudgeモデルは異なるモデルファミリーを使用すべきである

まとめ

JudgeBenchは、LLM-as-Judgeの信頼性を客観的基準で体系的に測定する初のベンチマークとして、評価フレームワーク設計に重要な示唆を与えている。著者らの実験では、現行の最先端モデルでもJudge精度は75%程度にとどまり、特に自己評価やCoding領域での判定に課題があることが報告されている。マルチエージェントRAGシステムの品質保証において、単一Judge依存からの脱却、Position Swapによるバイアス緩和、ドメイン別のJudge最適化が実践的に求められる。

参考文献

• Conference URL: https://arxiv.org/abs/2410.12784
• OpenReview: https://openreview.net/forum?id=G0dksFayVq
• Code: https://github.com/ScalerLab/JudgeBench
• Dataset: https://huggingface.co/datasets/ScalerLab/JudgeBench
• Leaderboard: https://huggingface.co/spaces/ScalerLab/JudgeBench
• Related Zenn article: https://zenn.dev/0h_n0/articles/88cd951a1ec060