評価精度を劇的に向上させる「ルーブリック＋フォーム記入型」LLM-as-a-Judgeプロンプト

Tech

{ “version”: “1.1”, “technique”: [“LLM-as-a-Judge”, “Rubric-based Evaluation”, “Chain-of-Thought”, “Form-Filling”], “target_models”: [“Gemini 1.5 Pro/Flash”, “GPT-4o”], “context”: “Professional prompt engineering for automated quality assurance.” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

評価精度を劇的に向上させる「ルーブリック＋フォーム記入型」LLM-as-a-Judgeプロンプト

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

カスタマーサポート等のLLM生成物の品質を、多角的な評価基準（ルーブリック）に基づき、人間と同等の精度で自動採点・分析すること。 課題： 単純な採点では「根拠の欠如」や「一貫性のないスコアリング」が発生し、評価結果の信頼性が低くなる点。 入出力形式： 入力は「ユーザー質問＋回答」、出力は評価理由とスコアを含む「JSON形式」。

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

graph TD
A["設計: 評価基準とフォーム項目の定義"] --> B["実行: LLMによる評価実施"]
B --> C["評価: 人間の評価との相関/一致率の確認"]
C -->|不一致/幻覚あり| A
C -->|精度向上| D["運用: 自動モニタリングへの組み込み"]

  1. 設計: 評価項目（正確性、丁寧さ、等）ごとに、1〜5点の具体的定義を明文化する。

  2. 実行: 「思考（Reasoning）」を先に書かせるフォーム形式でLLMに評価させる。

  3. 評価: サンプルデータを用い、人間がつけたスコアとLLMのスコアが乖離していないか検証する。

【プロンプトの実装案】

# Role

あなたは、カスタマーサポートの回答品質を厳格に評価する品質管理スペシャリストです。
提示された「評価基準（ルーブリック）」に基づき、客観的な視点で回答を評価してください。

# Evaluation Rubric: [正確性]


- Score 1: 致命的な誤情報が含まれている。

- Score 2: 部分的に誤りがあるか、重要な前提条件が抜けている。

- Score 3: 概ね正しいが、表現に曖昧さがあり、誤解を招く恐れがある。

- Score 4: 正確であり、必要な情報を十分に網羅している。

- Score 5: 完璧に正確であり、補足情報も含めてユーザーの期待を上回る。

# Task Instructions

以下の「評価フォーム」の全項目を順に埋めてください。
**注意：必ず「スコア」を決定する前に、その根拠となる「分析」を記述してください（Reason-before-Score）。**

# Input Data


- ユーザーの質問: {{USER_QUERY}}

- LLMの回答: {{AI_RESPONSE}}

# Evaluation Form (Output JSON format)

{
  "analysis": {
    "factual_check": "回答内容と事実の照合結果を記述",
    "rubric_justification": "ルーブリックのどの定義に該当するか、具体的な証拠を記述"
  },
  "scores": {
    "accuracy": 0 // 1-5の整数
  },
  "improvement_suggestion": "さらに良くするための具体的な修正案"
}

【評価指標と誤り分析】

自動評価の信頼性を阻害する要因を特定し、以下の指標で監視します。

評価指標 失敗パターン（誤り分析） 対策
一致率 (Inter-rater) 人間の評価とスコアが2点以上乖離する ルーブリックの記述をより具体的に（例：〜という単語があれば3点等）修正
根拠の妥当性 スコアは正しいが、理由（Analysis）が事実無根 Chain-of-Thought（思考過程）の強制出力を強化
ハロー効果 文体が丁寧だと、内容が間違っていても高得点になる 「丁寧さ」と「正確性」の評価項目を完全に分離して定義
JSON構造維持 評価文が長すぎてJSONが壊れる response_format: { type: "json_object" } の指定とスキーマの固定

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

最新のGemini 1.5 Pro等で高いパフォーマンスを発揮する、構造化された最終プロンプトです。

# Role

QA Expert for AI generated content.

# System Logic: Rubric-based Form Filling

Evaluate the [AI_RESPONSE] based on the [CONTEXT].
You MUST fill the form in the order specified. Thinking first, then scoring.

# Rubrics


1. Accuracy (1-5): Accuracy of facts.

2. Tone (1-5): Professionalism and empathy.

# Evaluation Form Format (Strict JSON)

{
  "thought_process": {
    "evidence_extraction": "List specific parts of the response related to facts.",
    "logical_deduction": "Explain why it matches a specific rubric level."
  },
  "evaluation_results": {
    "accuracy_score": null,
    "tone_score": null,
    "overall_rational": "Summary of evaluation."
  }
}

# Input


- Context: {{CONTEXT}}

- AI_Response: {{AI_RESPONSE}}

# Execution

Evaluate now. Follow the JSON structure exactly. No conversational text before or after the JSON.

【まとめ】

実務でLLM-as-a-Judgeを運用するための3つの鉄則：

  1. Reasoning-First (思考の先行出力): スコアを出す前に、必ず証拠の抽出と分析をステップバイステップで行わせる（CoTの強制）。

  2. Rubric Orthogonality (評価軸の直交性): 評価項目同士が重複しないように設計し、特定の要素（例：丁寧さ）が他の要素（例：正確性）に影響を与えないようにする。

  3. Few-shot Calibration (例示による補正): 「この回答なら3点、この回答なら5点」という境界線の具体例を3つ以上プロンプトに含めることで、モデルのバイアスを最小化する。

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

コメント

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