{ “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
設計: 評価項目を定量・定性の両面から定義し、LLMに「評価者」の役割を与える。
実行: 回答を生成させ、定義したルーブリックに沿って各項目を評価。
評価: 評価根拠(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": "..."
}
【まとめ】
「先に理由、後にスコア」: 人間と同様、LLMも先に点数を決めると理由をこじつける(後知恵バイアス)。思考プロセスを先に書かせることが不可欠。
基準の「解像度」を上げる: 「良い回答」といった抽象的な表現を避け、「〇〇が含まれていれば4点」と具体化する。
JSON制約による構造化: 後続の分析(Python等での集計)を容易にするため、出力は必ずパース可能なJSON形式に固定する。

