LLMによる自動評価（LLM-as-a-judge）の精度を最大化する「ルーブリック型プロンプト」の設計

Tech

{ “version”: “1.0”, “technique”: [“Chain-of-Thought”, “Rubric-based Evaluation”, “Structured JSON Output”, “Few-shot Prompting”], “model_optimization”: “Gemini 1.5 Pro / GPT-4o”, “focus”: “LLM-as-a-Judge Reliability” } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

LLMによる自動評価（LLM-as-a-judge）の精度を最大化する「ルーブリック型プロンプト」の設計

【ユースケース定義と課題】

複雑なプロンプトに対する回答の質を、客観的基準（ルーブリック）に基づき評価。評価の「ブレ」を抑え、JSON形式で解析可能なスコアを算出する。

  • 入力型：評価対象のプロンプト、生成された回答、評価基準（ルーブリック）

  • 出力型：思考プロセス、項目別評価、総合点を含むJSONオブジェクト

【プロンプト設計のループ】

graph TD
A["ルーブリック策定"] --> B["思考プロセス強制実行"]
B --> C["フォーム形式での採点"]
C -->|パースエラー/不整合| A

  1. 設計: 評価項目を定量・定性の両面から定義し、LLMに「評価者」の役割を与える。

  2. 実行: 回答を生成させ、定義したルーブリックに沿って各項目を評価。

  3. 評価: 評価根拠（Reasoning）とスコアの整合性をチェックし、プロンプトを微調整。

【プロンプトの実装案】

LLMに直接スコアを付けさせるのではなく、各項目について「証拠」を書き出させてから最後に採点させる「フォーム記入」スタイルを採用します。

### Role

あなたは厳格かつ公平なコンテンツ評価者です。
与えられた「回答」が「指示」に対してどの程度忠実で、質が高いかを以下の「ルーブリック」に基づいて評価してください。

### Rubric


1. 指示完遂度 (1-5): 全ての制約条件（文字数、トーン、形式）を守っているか。

2. 事実正確性 (1-5): 誤った情報や幻覚（ハルシネーション）が含まれていないか。

3. 論理性・構成 (1-5): 文脈がスムーズで、読者が理解しやすい構造か。

### Evaluation Form (Filling process)

以下の手順で評価を行い、最後にJSON形式で出力してください。
Step 1: 指示に含まれる「制約条件」を箇条書きで抽出する。
Step 2: 回答の中で、各制約が達成されているか証拠を挙げて確認する。
Step 3: ルーブリックの各項目について、理由を述べた上でスコアリングする。

### Input


- 指示内容: {{INPUT_PROMPT}}

- 生成された回答: {{GENERATED_RESPONSE}}

### Output Format (Strictly JSON)

{
  "analysis": {
    "constraints_extracted": [],
    "evidence_found": ""
  },
  "scores": {
    "instruction_following": {"score": 0, "reason": ""},
    "factuality": {"score": 0, "reason": ""},
    "logic_coherence": {"score": 0, "reason": ""}
  },
  "overall_score": 0
}

【評価指標と誤り分析】

自動評価において発生しやすいエラーを特定し、対策を講じます。

失敗パターン 内容 対策
中心化傾向 全ての回答に「3」を付けてしまう 1と5の定義（アンカー）を明確にする
後知恵バイアス 自分の知識で補完して「正解」としてしまう 指示文に書かれた範囲のみで評価するよう指定
ハロー効果 文章が綺麗だと、内容が薄くても高得点にする 評価項目を完全に独立させて個別に採点させる

自動評価の採点基準（ルーブリック例）

スコア 状態 判定基準
5 Excellent 全ての制約を満たし、付加価値のある洞察が含まれる。
3 Good 基本的な制約は満たしているが、一部に改善の余地がある。
1 Poor 主要な制約を無視している、あるいは致命的な誤報がある。

【改良後の最適プロンプト】

「思考の連鎖（CoT）」と「フォーム記入によるバイアス排除」を強化した最終案です。

# Instruction

以下の[Evaluation Protocol]に従い、対象の回答を評価してください。
評価は客観的証拠に基づき、推測を排除して行います。

# Evaluation Protocol


1. **Deconstruction**: 指示文を最小単位の「要求事項」に分解せよ。

2. **Verification**: 各要求事項に対し、回答内に該当する箇所があるか「Yes/No」で判定せよ。

3. **Scoring**: 判定結果に基づき、以下の基準でスコアを算出せよ。

   - 1点: 要求事項の50%未満を達成

   - 3点: 要求事項の80%以上を達成

   - 5点: 100%達成し、かつ表現が極めて適切

# Input Data


- Prompt: {{INPUT_PROMPT}}

- Response: {{GENERATED_RESPONSE}}

# Form Output (JSON Only)

```json
{
  "protocol_step_1_deconstruction": [
    "要求1: ...",
    "要求2: ..."
  ],
  "protocol_step_2_verification": {
    "要求1": {"status": "Yes/No", "evidence": "..."},
    "要求2": {"status": "Yes/No", "evidence": "..."}
  },
  "final_rubric_scores": {
    "completeness": 0,
    "accuracy": 0,
    "readability": 0
  },
  "final_justification": "..."
}

【まとめ】

  1. 「先に理由、後にスコア」: 人間と同様、LLMも先に点数を決めると理由をこじつける（後知恵バイアス）。思考プロセスを先に書かせることが不可欠。

  2. 基準の「解像度」を上げる: 「良い回答」といった抽象的な表現を避け、「〇〇が含まれていれば4点」と具体化する。

  3. JSON制約による構造化: 後続の分析（Python等での集計）を容易にするため、出力は必ずパース可能なJSON形式に固定する。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました