LLM-as-a-Judgeの精度を最大化する「評価用ルーブリック＋フォーム回答型」プロンプト設計

Tech

{“design_pattern”: “LLM-as-a-judge-optimization”, “techniques”: [“Rubric-based Scoring”, “Form-filling Pattern”, “Chain-of-Thought”, “Structured-Output”], “target_model”: “Gemini 1.5 Pro / GPT-4o”, “version”: “1.0”}

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

LLM-as-a-Judgeの精度を最大化する「評価用ルーブリック＋フォーム回答型」プロンプト設計

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

LLMの回答品質を一定基準で自動採点したいが、評価がブレたり根拠が薄かったりする課題を、構造化された評価ルーブリックとフォーム入力形式で解決する。

  • 入力型：評価対象のプロンプトと回答（Markdown/Text）

  • 出力型：構造化された評価レポート（JSONまたはMarkdownフォーム）

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

graph TD
A["ルーブリック定義"] --> B["評価フォームの構築"]
B --> C["CoTによる推論実行"]
C --> D["出力のパースと検証"]
D -->|不整合発見| A

  1. ルーブリック定義: 採点基準を曖昧な言葉ではなく「1〜5点の具体的状態」として定義する。

  2. フォーム構築: 評価者に「点数」を先に書かせず、「証拠」を先に書かせる構造を作る。

  3. CoT実行: 評価の根拠となる思考プロセスを明示的に出力させる。

  4. 検証: 評価理由とスコアに矛盾がないか、JSONスキーマに従っているかを確認する。

【プロンプトの実装案】

以下のプロンプトは、評価のバイアス（中心化傾向など）を防ぐために「思考の順序」を強制しています。

# Role

あなたは高品質な技術ドキュメントの校閲者であり、LLMの回答を客観的に評価するエキスパート評価者です。

# Evaluation Rubric (指標: 正確性)


- 5点 (Excellent): 誤りが一切なく、最新の技術動向に合致し、補足情報まで完璧である。

- 3点 (Good): 主要な事実に誤りはないが、一部説明が不十分、または冗長である。

- 1点 (Poor): 明らかな事実誤認が含まれる、または質問の意図を理解していない。

# Task Instructions

以下の手順に従い、[Target Response] を評価してください。

1. **証拠の抽出**: 回答の中から、評価の根拠となる具体的な記述を抜き出す。

2. **分析**: ルーブリックの基準に照らし合わせ、証拠がどのレベルに該当するか論理的に説明する。

3. **最終スコア**: 1〜5の整数でスコアを付与する。

# Evaluation Form (この形式で回答してください)

[Evidence]: 
[Reasoning]: 
[Final Score]: 
[Improvement Suggestion]: 

# Target Response

(ここに評価対象のテキストを挿入)

【評価指標と誤り分析】

自動評価の信頼性を担保するために、以下の観点で評価プロセスを検証します。

評価指標 失敗パターン（リスク） 対策
整合性 (Alignment) 評価文では「ひどい」と言いつつスコア「4」をつける 思考プロセス（Reasoning）をスコアの前に書かせる
幻覚 (Hallucination) 本文にない情報を根拠に減点する [Evidence]セクションで本文の直接引用を強制する
フォーマット崩れ JSON等の後続処理でエラーが出る Few-shotで出力例を提示、またはスキーマ制御を行う

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

最新LLMの「長いコンテキストの理解」と「構造化出力」の特性を最大限に活かした、実務向けの最終プロンプト案です。

# Role

Technical Content Auditor

# Task context

あなたはカスタマーサポートの自動回答精度を測定しています。
提示された「評価基準」に基づき、ステップバイステップで評価を実施してください。

# Output Schema (JSON)

{
  "reasoning_steps": [
    "step1: 文脈の理解度を確認...",
    "step2: 技術的な正確性を検証..."
  ],
  "criteria_check": {
    "accuracy": {"score": 1-5, "evidence": "string"},
    "politeness": {"score": 1-5, "evidence": "string"}
  },
  "overall_score": 0.0,
  "action_item": "改善のための具体的アクション"
}

# Detailed Rubric

## Accuracy (正確性)


- Score 5: 全ての技術用語が正確で、推奨されるベストプラクティスに基づいている。

- Score 3: 事実誤認はないが、曖昧な表現が含まれる。

- Score 1: 致命的な誤情報（ハルシネーション）を含む。

# Constraints


- 回答の前に「なぜそのスコアになったのか」の内部推論(CoT)を必ず記述すること。

- スコアは四捨五入せず、ルーブリックに従って厳格に付けること。

- JSON以外のテキストは出力しないでください。

# Target Input

PROMPT: {user_prompt}
RESPONSE: {llm_response}

# Evaluation Output (JSON)

【まとめ】

LLM-as-a-judgeを運用するための3つの鉄則：

  1. 思考を先、スコアを後に: 先に点数を決めさせると、後付けの理由（正当化）が生成されやすいため、必ず「証拠→理由→スコア」の順で出力させる。

  2. 具体的ルーブリックの提示: 「良い・悪い」ではなく「XXが含まれていれば3点」という、誰が見ても同じ判断になる客観的な基準を書き込む。

  3. Few-shotの活用: 特に「低い評価（1点や2点）」の例をFew-shotとして含めることで、LLMが陥りやすい「お世辞バイアス（高得点を付けすぎる傾向）」を抑制できる。

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

コメント

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