LLM-as-a-Judgeの信頼性を劇的に高める「ルーブリック型フォーム」プロンプト設計

Tech

  • ターゲット：LLMによる自動評価（LLM-as-a-judge）の実装に課題を抱えるエンジニア・プロンプトデザイナー。

  • 解決策：評価基準（Rubric）の細分化と、評価結果を構造化された「フォーム形式」で出力させることで、CoT（Chain-of-Thought）を強制し、評価の客観性と一貫性を向上させる。

  • 参照技術：G-Eval, Prometheus, 自意識的バイアスの低減。

  • 構成：隠蔽メタデータ → 開示バッジ → ユースケース → Mermaid → 初期プロンプト → 課題分析 → 最適プロンプト → まとめ。

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

LLM-as-a-Judgeの信頼性を劇的に高める「ルーブリック型フォーム」プロンプト設計

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

AIカスタマーサポートやRAGシステムの生成応答を、一貫した基準で自動採点・検品したい。 課題： 評価基準が曖昧だとLLMのスコアに「ゆらぎ」が生じ、根拠（Reasoning）と点数が乖離する「評価の不整合」が発生する。 入出力型：

  • 入力： コンテキスト、ユーザー質問、AIの生成回答。

  • 出力： JSON（各評価項目ごとの根拠、スコア、最終判定）。

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

graph TD
A["ルーブリックの定義"] --> B["評価フォームの型定義"]
B --> C["CoTによる推論実行"]
C --> D["人間との一致度分析"]
D -->|基準の厳格化| A

  1. 設計： 評価項目を分解し、5段階評価の定義（ルーブリック）を言語化する。

  2. 実行： フォーム入力形式で、各項目ごとに「根拠」を書かせてから「スコア」を出力させる。

  3. 評価： 人間の評価とLLMのスコアの相関を確認し、乖離している箇所の基準を修正する。

【プロンプトの実装案】

# Role

あなたは高品質なカスタマーサポートの評価を行うシニア・クオリティ・アナリストです。
提供された「AI回答」を、以下の「評価ルーブリック」に基づき、「評価フォーム」に従って厳格に採点してください。

# 評価ルーブリック


1. 正確性 (Accuracy): 

   - 5: 事実誤認が一切なく、提供されたコンテキストに完全に基づいている。

   - 1: 致命的な事実誤認がある、またはハルシネーションを含んでいる。

2. 共感性 (Empathy):

   - 5: ユーザーの感情に寄り添い、丁寧かつプロフェッショナルな言葉遣いである。

   - 1: 機械的で冷たい、または不適切な表現が含まれる。

# 評価フォーム (Output Format)

必ず以下のJSON形式で出力してください。
{
  "evaluations": {
    "accuracy": {
      "reasoning": "なぜそのスコアになったかの具体的な根拠",
      "score": 1-5
    },
    "empathy": {
      "reasoning": "なぜそのスコアになったかの具体的な根拠",
      "score": 1-5
    }
  },
  "final_verdict": "全体の総評"
}

# Input Data

## コンテキスト: {{context}}

## ユーザー質問: {{query}}

## AI回答: {{response}}

# 思考プロセス

ステップ1：AI回答の内容とコンテキストを照合し、事実関係を検証する。
ステップ2：ルーブリックに照らし合わせ、各項目の根拠を言語化する。
ステップ3：最後にスコアを決定する。

【評価指標と誤り分析】

自動評価を導入する際に直面する「失敗パターン」を分析します。

失敗パターン 内容 対策
寛容バイアス 評価対象のLLMに対して甘い点（全て5点等）をつける ルーブリックに「減点対象」を明記する
根拠の形骸化 スコアを決めた後に後付けで理由を書く フォーム順序を「Reasoning → Score」に固定する
長さバイアス 回答が長いだけで「丁寧」と誤認して高評価にする 文字数を除外した「情報の密度」を評価基準に入れる
JSON崩れ 出力に説明テキストが混じりパースに失敗する JSON modeの使用、またはデリミタの指定

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

分析結果を反映し、自己批判（Self-Correction）ステップを追加した高精度プロンプトです。

# Role

Professional QA Judge for AI Systems

# Mission

提供されたAI回答の品質を、客観的事実と定義された基準のみに基づいて評価せよ。主観的な好みを排除し、ルーブリックの文言に忠実に従うこと。

# 評価基準（Rubric）


- [正確性] コンテキストにない情報を「事実」として述べていないか？（減点方式）

- [完結性] 質問のすべての要素に答えているか？（加点方式）

# 実行手順（Step-by-Step）


1. [Analysis] AI回答に含まれる個別の主張を箇条書きで抽出せよ。

2. [Verification] 各主張がコンテキストに合致するか、個別に検証せよ。

3. [Drafting] ルーブリックに基づき、各項目の「良かった点」「不足点」を記述せよ。

4. [Scoring] 最後に、記述内容と矛盾しないスコアを決定せよ。

# Constraint


- 出力は必ず以下のJSONスキーマに従うこと。

- 文字列内での改行は \n を使用すること。

```json
{
  "analysis_step": {
    "extracted_claims": [],
    "fact_check_results": ""
  },
  "rubric_scores": {
    "accuracy": { "rationale": "", "score": 0 },
    "completeness": { "rationale": "", "score": 0 }
  },
  "final_decision": ""
}

【まとめ】

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

  1. Reasoning-Firstの徹底：スコアの前に必ず「根拠」を言語化させる（CoTの強制）。

  2. 評価軸の独立性：正確性と流暢性など、異なる性質の指標を混ぜずに独立した項目として採点させる。

  3. Few-shotによる「目線合わせ」：満点（5点）の例と、典型的な失敗例（2点）をFew-shotとして提示し、LLMに評価の境界線を学習させる。

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

コメント

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