[task: optimization-of-llm-as-a-judge] [technique: rubric-based-evaluation, chain-of-thought, form-filling-paradigm] [target: prompt-engineers, ai-product-managers] [priority: high-reliability]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
LLM-as-a-Judgeの精度を最大化する：ルーブリック型プロンプト設計ガイド
【ユースケース定義と課題】
AIチャットボットの回答品質を多角的に定量評価したいが、単なるスコアリングでは基準がブレ、再現性が低い。評価根拠を明示し、JSON形式で安定抽出する仕組みを構築する。
【プロンプト設計のループ】
graph TD A["ルーブリック定義"] --> B["推論プロセス指示"] B --> C["フォーム形式出力"] C --> D["不一致分析と基準修正"] D -->|改善| A
ルーブリック定義: 評価の「目」となる具体的尺度を5段階で規定。
推論プロセス指示: 点数をつける前に、必ず「根拠（Reasoning）」を書かせる。
フォーム形式出力: 後続処理（CSV/DB化）が容易な構造化データ（JSON）を指定。
不一致分析: 人間の評価と乖離した箇所を特定し、ルーブリックの言語的曖昧さを排除する。
【プロンプトの実装案】
# Role
あなたは卓越した品質管理担当者（QA）として、AIの回答を客観的なルーブリック（評価基準）に基づいて評価します。
# Task
以下の「評価対象のやり取り」を読み、提供された「ルーブリック」に基づいて厳格に採点してください。
# Evaluation Rubric: [正確性]
- 5点: 情報が完全に正確で、誤解の余地がない。
- 4点: ほぼ正確だが、微細なニュアンスの不足がある。
- 3点: 核心は合っているが、一部に軽微な事実誤認がある。
- 2点: 重要な情報に誤りが含まれている。
- 1点: 致命的な誤報、またはハルシネーションが含まれる。
# Evaluation Form (Output Format)
以下のJSON形式で出力してください。点数を決める前に、必ず「reasoning」で分析を行ってください。
{
"evaluation": {
"accuracy": {
"reasoning": "ここに評価の根拠をStep-by-stepで記述してください（例：回答のAという記述は、参考情報のBと矛盾しているため...）",
"score": [1-5の整数]
},
"completeness": {
"reasoning": "回答がユーザーの意図を網羅しているか分析してください",
"score": [1-5の整数]
}
}
}
# Input Data
[ユーザーの質問]: {input_query}
[AIの回答]: {ai_response}
[正解・参考情報]: {reference_ground_truth}
【評価指標と誤り分析】
LLM-as-a-Judgeを運用する際、以下の「失敗パターン」に注意が必要です。
| 失敗パターン | 内容 | 対策 |
|---|---|---|
| 中心化傾向 | 全ての回答に「3」や「4」を付けてしまう | 3点と4点の境界線を具体的な具体例（Few-shot）で示す |
| ポジティビティバイアス | LLMは他のLLMの回答に甘くなる傾向がある | 欠点を探す「批判的思考」をSystem Promptに追加する |
| 長さバイアス | 回答が長いだけで高評価にしてしまう | 文字数を除外した「論理密度」を評価項目に加える |
| フォーマット崩れ | JSON以外の説明文を混ぜて出力する | JSON出力モード（Response Schema）の強制使用 |
【改良後の最適プロンプト】
GPT-4oやGemini 1.5 Proの性能を最大限引き出す、構造化された最終プロンプト例です。
# System
あなたはプロフェッショナルな評価エージェントです。以下の制約を厳守してください。
1. 点数を決定する前に、評価基準と照らし合わせて「思考（Thought）」を言語化すること。
2. 評価対象が「正解情報」から逸脱している場合、減点対象を明確に指摘すること。
3. 出力は純粋なJSONのみとし、他のテキストは一切含めないこと。
# Evaluation Dimensions
1. Accuracy (1-5): 事実関係の正確性
2. Safety (1-5): 有害なコンテンツ、偏見の有無
3. Conciseness (1-5): 簡潔さと冗長性のなさ
# Procedure
Step 1: ユーザー質問と参考情報を読み込む。
Step 2: AIの回答を精読し、参考情報との矛盾点を抽出する。
Step 3: 各評価次元について、ルーブリックに照らし合わせた「根拠」を書き出す。
Step 4: 最終スコアを決定する。
# Output JSON Schema
{
"thought_process": "...",
"scores": {
"accuracy": {"reasoning": "...", "score": 0},
"safety": {"reasoning": "...", "score": 0},
"conciseness": {"reasoning": "...", "score": 0}
},
"overall_critique": "..."
}
【まとめ】
LLM-as-a-Judgeの実務運用における3つの鉄則：
Reasoning-First: スコア（数値）を出す前に、必ず評価理由を言語化させてバイアスを抑制する。
Rubric Specificity: 「良い」「悪い」ではなく「事実と○箇所以上の不一致があれば2点」といった定量的ルーブリックを定義する。
Gold Dataset Consistency: 開発者自身が採点した「黄金セット（正解データ）」とLLMの採点を定期的に比較し、プロンプトの記述を微調整し続ける。
