目次 › 第5章 › 5-2

第5章 評価とモニタリング / 想定学習時間:30〜40分 / 最終確認:2026年8月

5-2. 評価ジャッジ(LLM-as-a-judge)の仕組みと利用

1. LLM-as-a-judge とは

LLM-as-a-judgeは、評価対象のLLM出力を別のLLMに採点させる手法です。ジャッジ役のLLMには「評価基準(何を良しとするか)」「質問」「モデルの出力」(必要に応じてコンテキストや期待回答)を与え、合否や1〜5点のスコアと、その理由(rationale)を返させます。

評価手段は大きく3つあり、それぞれトレードオフがあります。

つまりLLMジャッジは「人手評価の品質」と「自動評価のスケール」の中間を埋める存在です。5-1で見た Relevance や Groundedness のような意味的な観点は、文字列処理では判定できないため、LLMジャッジが事実上の標準手段になっています。

2. MLflow 3 の組み込みジャッジ

現在の Databricks では、生成AIアプリ評価のための組み込みLLMジャッジは MLflow 3 の統合評価フレームワークの一部として提供されます。自分でジャッジ用プロンプトを設計しなくても、実績のある基準で主要観点を評価できます。代表的なものは次のとおりです。

各ジャッジが「どの入力を必要とするか」に注目してください。correctness だけは期待回答(ground truth)が必要で、relevance・groundedness・safety はリファレンスなしで動きます(5-1の分類と対応)。この違いは「正解データがない状況でどのジャッジが使えるか」という形で問われます。

3. guidelines ジャッジ:自然言語で書く独自基準

組み込みの観点に収まらない要件も、自然言語のガイドラインとして書けばジャッジに判定させられます。コードを書かずに基準を追加できるのが利点で、業務要件のレビュー観点をそのまま評価に落とし込めます。

なお、正規表現や完全一致で機械的に判定できる基準(URLを含むか、JSON形式か等)は、LLMジャッジよりも安価で再現性のあるヒューリスティック型カスタムスコアラー(5-3)が適します。「意味の判定はLLMジャッジ、形式の判定はヒューリスティック」と使い分けます。

4. mlflow.genai.evaluate() による一括評価

評価の実行には MLflow 3 の評価 API mlflow.genai.evaluate() を使います(MLflow 2 系の mlflow.evaluate() を生成AI向けに再設計した、統合評価フレームワークの中心APIです)。基本の流れは「評価データセットを用意 → アプリ(または既存の出力)とスコアラーを渡す → 結果が MLflow に記録される」です。

# 評価データセット:質問と期待回答(期待回答は correctness を使う場合に必要)
eval_data = [
    {
        "inputs": {"question": "返品は何日以内に可能ですか?"},
        "expectations": {"expected_response": "未開封なら購入後30日以内です。"},
    },
    # ... 他の評価ケース
]

import mlflow
from mlflow.genai.scorers import Correctness, RelevanceToQuery, Safety, Guidelines

results = mlflow.genai.evaluate(
    data=eval_data,
    predict_fn=my_rag_app,          # 評価対象のアプリ(質問を受け回答を返す関数)
    scorers=[
        Correctness(),               # 期待回答との一致
        RelevanceToQuery(),          # 質問への関連性
        Safety(),                    # 安全性
        Guidelines(
            name="keigo",
            guidelines="回答は敬語(ですます調)で書かれていること",
        ),
    ],
)

実行すると、各評価ケースにスコアラーごとの判定と理由が付き、結果はMLflowの実験(Run)として記録されます。UIでケースごとの合否・理由を確認でき、プロンプトやモデルを変更した前後で評価結果を比較することで、改善が本当に効いたかをデータで判断できます(回帰テストとしての利用)。

5. ジャッジの限界と人間レビューの併用

LLMジャッジは万能ではありません。既知の限界を理解した上で使います。

• バイアス — ジャッジLLMは自分と同系統のモデルの出力を高く評価しがち(自己モデル寄りバイアス)、また内容が同等でも長く詳細な回答を好む傾向(長文バイアス)が知られています
• コスト — 評価のたびにLLM推論が走るため、全件・高頻度の評価はコストがかさむ。サンプリングやヒューリスティックとの併用で抑える
• ジャッジ自身の誤り — ジャッジも確率的なLLMであり、誤判定はゼロにならない

したがって、重要な判断(リリース可否、規制対応など)は人間のレビューと併用するのが原則です。実務では、ドメイン専門家(SME)がサンプルをレビューしてジャッジの判定と突き合わせ、ジャッジが信頼できることを確認してから大規模適用する、という進め方をします(人間フィードバックの活用は5-6で扱います)。

練習問題