advanced-evaluation

高度な評価

このスキルでは、LLM を審判として利用し、LLM の出力を評価するための本番環境向けの手法を扱います。学術論文、業界の実践、実装経験から得られた知見を統合し、信頼性の高い評価システムを構築するための実践的なパターンを紹介します。

重要なポイント：LLM-as-a-Judge は単一の手法ではなく、それぞれ異なる評価コンテキストに適した手法の集合です。適切な手法を選び、既知のバイアスを軽減することが、このスキルで身につける中核的な能力です。

有効化するタイミング

次の場合にこのスキルを有効化してください。

• LLM の出力を対象とする LLM-as-a-Judge システムを構築するとき
• 複数のモデルの応答を比較して、最適なものを選ぶとき
• 評価チーム全体で一貫した品質基準を確立するとき
• 結果に一貫性が見られない評価システムの問題を調査するとき
• プロンプトやモデルの変更に対する A/B テストを設計するとき
• LLM または人間と LLM のハイブリッド審判向けに、専用の評価基準を作成するとき
• 自動評価と人間による評価の相関を分析するとき

次のような、他のスキルが担当する関連作業では、このスキルを有効化しないでください。

• 一般的な決定論的チェック、回帰テスト一式、本番環境の品質ゲート、成果指標：evaluation。
• 自律ループのガバナンス、固定された評価基準、ロールバック、PR 承認の境界：harness-engineering。
• 評価ツールのツール API コントラクト：tool-design。

中核となる概念

評価の分類

正解データの有無に応じて、主な 2 つの手法から選択します。

直接スコアリング — 事実の正確性、指示への準拠、有害性など、客観的な基準がある場合に使用します。単一の LLM が、定義された尺度に基づいて 1 つの応答を評価します。基準が明確に定義されている場合、中程度から高い信頼性を実現できます。スコアのキャリブレーションのずれや、尺度の解釈の不一致に注意してください。

ペア比較 — トーン、スタイル、説得力など、主観的な好みを評価する場合に使用します。LLM が 2 つの応答を比較し、より優れた方を選択します。主観的なタスクでは、ペア比較の方が自由形式の直接スコアリングよりも、人間の好みとの相関が高いことがよくあります（claim-advanced-evaluation-position-swap）。位置バイアスと長さバイアスに注意してください。

バイアスの全体像

あらゆる評価システムで、次の体系的なバイアスを軽減してください。

位置バイアス：最初に提示された応答が優遇されます。提示位置を入れ替えて 2 回評価し、その後、多数決または一貫性チェックを適用して軽減します。

長さバイアス：品質にかかわらず、長い応答ほど高く評価されます。長さを無視するよう明示的に指示し、長さで正規化したスコアリングを適用して軽減します。

自己評価バイアス：モデルは自らの出力を高く評価します。生成と評価に異なるモデルを使用して軽減します。

冗長性バイアス：不要な場合でも、過剰な詳細が高く評価されます。無関係な詳細を減点する、評価基準に特化したルーブリックを使って軽減します。

権威バイアス：正確性にかかわらず、自信に満ちた口調が高く評価されます。根拠の引用を必須にし、ファクトチェック層を追加して軽減します。

指標の選択フレームワーク

評価タスクの構造に合わせて指標を選択します。

タスクの種類	主な指標	副次的な指標
二値分類（合格／不合格）	再現率、適合率、F1	Cohen のカッパ係数
順序尺度（1～5 の評価）	Spearman の順位相関係数、Kendall の順位相関係数	Cohen のカッパ係数（重み付き）
ペアごとの選好	一致率、位置の一貫性	確信度のキャリブレーション
マルチラベル	マクロ F1、マイクロ F1	ラベルごとの適合率／再現率

絶対的な一致率よりも、体系的な不一致のパターンを優先して確認してください。特定の基準で人間と一貫して異なる評価をする審判は、ランダムなノイズを生じさせる審判よりも問題が大きいためです。

評価手法

直接スコアリングの実装

明確な基準、調整された尺度、構造化された出力形式の3つの要素で、直接スコアリングを構築します。

基準の定義パターン：

Criterion: [Name]
Description: [What this criterion measures]
Weight: [Relative importance, 0-1]

尺度の調整 — ルーブリックの詳細さに応じて尺度の粒度を選びます：

• 1〜3：中立の選択肢を含む二値尺度で、認知負荷が最も低くなります
• 1〜5：標準的なリッカート尺度で、粒度と信頼性のバランスが最も優れています
• 1〜10：レベルごとの詳細なルーブリックがある場合に限り使用します。尺度の調整が難しくなるためです

直接スコアリングのプロンプト構成：

You are an expert evaluator assessing response quality.

## Task
Evaluate the following response against each criterion.

## Original Prompt
{prompt}

## Response to Evaluate
{response}

## Criteria
{for each criterion: name, description, weight}

## Instructions
For each criterion:
1. Find specific evidence in the response
2. Score according to the rubric (1-{max} scale)
3. Justify your score with evidence
4. Suggest one specific improvement

## Output Format
Respond with structured JSON containing scores, justifications, and summary.

スコアリング用プロンプトでは、スコアの前に根拠を示すよう求めます。これにより、判定者は数値を出す前に、観察可能な出力の特徴に基づいて判断しなければならなくなります。

ペアワイズ比較の実装

すべてのペアワイズ評価で、提示順によるバイアスを軽減します。

1. まず決定論的な事前チェックを実行します。両方の候補が同じスキーマ、ソースの根拠に関する要件、範囲の制約を満たしている必要があります。
2. 1回目の判定：回答Aを先に、回答Bを後に提示します。
3. 2回目の判定：回答Bを先に、回答Aを後に提示します。
4. 一貫性チェック：判定結果が一致しない場合は、信頼度を下げたうえでTIEを返します。
5. 最終判定：判定結果が一致した場合は、信頼度の平均値と、明示的なタイブレークの根拠を提示します。

ペアワイズ比較のプロンプト構成：

You are an expert evaluator comparing two AI responses.

## Critical Instructions
- Do NOT prefer responses because they are longer
- Do NOT prefer responses based on position (first vs second)
- Focus ONLY on quality according to the specified criteria
- Ties are acceptable when responses are genuinely equivalent

## Original Prompt
{prompt}

## Response A
{response_a}

## Response B
{response_b}

## Comparison Criteria
{criteria list}

## Instructions
1. Analyze each response independently first
2. Compare them on each criterion
3. Determine overall winner with confidence level

## Output Format
JSON with per-criterion comparison, overall winner, confidence (0-1), and reasoning.

信頼度の調整 — 信頼度を提示順の一貫性に対応付けます：

• 両方の判定結果が一致する場合：信頼度 = 個別の信頼度の平均
• 判定結果が一致しない場合：信頼度 = 0.5、判定結果 = TIE

ルーブリックの生成

自由形式のスコアリングと比べて評価のばらつきを抑えるため、ルーブリックを生成します。分散の正確な低減幅は、対象の評価セットで測定しない限り、作業ごとに異なるものとして扱います。

ルーブリックに含める要素：

1. レベルの説明：各スコアレベルの明確な境界
2. 特徴：各レベルを定義する観察可能な特徴
3. 例：各レベルを代表するテキスト（任意ですが、あると有用です）
4. 境界事例：曖昧な状況に関する指針
5. スコアリングのガイドライン：一貫して適用するための一般原則

ユースケースに合わせて厳格さを調整します：

• 寛容：合格基準を低く設定し、反復を促す場合に適しています
• 標準：一般的な本番環境での期待水準です
• 厳格：安全性が重要な評価や、リスクの高い評価で求められる高い基準です

ルーブリックは分野に合わせ、分野固有の用語を使います。コードの可読性に関するルーブリックでは変数、関数、コメントに触れます。医療の正確性に関するルーブリックでは、臨床用語とエビデンス基準を参照します。

実践的なガイダンス

評価パイプラインの設計

本番環境の評価システムは、次のレイヤーで構築します：基準ローダー（ルーブリック + 重み） -> 主スコアラー（直接またはペアワイズ） -> バイアス軽減（提示順の入れ替えなど） -> 信頼度スコアリング（調整） -> 出力（スコア + 根拠 + 信頼度）。全体の図は評価パイプライン図を参照してください。

判断フレームワーク：直接評価かペアワイズ比較か

次の判断ツリーを適用します：

Is there an objective ground truth?
+-- Yes -> Direct Scoring
|   Examples: factual accuracy, instruction following, format compliance
|
+-- No -> Is it a preference or quality judgment?
    +-- Yes -> Pairwise Comparison
    |   Examples: tone, style, persuasiveness, creativity
    |
    +-- No -> Consider reference-based evaluation
        Examples: summarization (compare to source), translation (compare to reference)

評価のスケーリング

大量の評価を行う場合は、次の戦略のいずれかを適用します：

1. LLM のパネル（PoLL）：複数のモデルを判定者として使い、投票を集約することで個々のモデルのバイアスを軽減します。コストは高くなりますが、リスクの高い判断では信頼性が高まります。

2. 階層型評価：高速で低コストのモデルをスクリーニングに使い、境界事例には高コストのモデルを使います。スクリーニングのしきい値を調整する必要があります。

3. 人間参加型：明確な事例は自動化し、信頼度の低い判断は人間によるレビューに回します。自動評価を継続的に改善するためのフィードバックループを設計します。

例

例1：正確性の直接スコアリング

入力：

Prompt: "What causes seasons on Earth?"
Response: "Seasons are caused by Earth's tilted axis. As Earth orbits the Sun,
different hemispheres receive more direct sunlight at different times of year."
Criterion: Factual Accuracy (weight: 1.0)
Scale: 1-5

出力：

{
  "criterion": "Factual Accuracy",
  "score": 5,
  "evidence": [
    "Correctly identifies axial tilt as primary cause",
    "Correctly explains differential sunlight by hemisphere",
    "No factual errors present"
  ],
  "justification": "Response accurately explains the cause of seasons with correct
scientific reasoning. Both the axial tilt and its effect on sunlight distribution
are correctly described.",
  "improvement": "Could add the specific tilt angle (23.5 degrees) for completeness."
}

例2：提示順を入れ替えるペアワイズ比較

入力：

Prompt: "Explain machine learning to a beginner"
Response A: [Technical explanation with jargon]
Response B: [Simple analogy-based explanation]
Criteria: ["clarity", "accessibility"]

1回目の判定（Aを先に提示）：

{ "winner": "B", "confidence": 0.8 }

2回目の判定（Bを先に提示）：

{ "winner": "A", "confidence": 0.6 }

（注：勝者はAです。Bが先に提示されたためです）

2回目の判定結果の対応付け：

{ "winner": "B", "confidence": 0.6 }

最終結果：

{
  "winner": "B",
  "confidence": 0.7,
  "positionConsistency": {
    "consistent": true,
    "firstPassWinner": "B",
    "secondPassWinner": "B"
  }
}

例 3：ルーブリックの生成

入力：

criterionName: "Code Readability"
criterionDescription: "How easy the code is to understand and maintain"
domain: "software engineering"
scale: "1-5"
strictness: "balanced"

出力（抜粋）：

{
  "levels": [
    {
      "score": 1,
      "label": "Poor",
      "description": "Code is difficult to understand without significant effort",
      "characteristics": [
        "No meaningful variable or function names",
        "No comments or documentation",
        "Deeply nested or convoluted logic"
      ]
    },
    {
      "score": 3,
      "label": "Adequate",
      "description": "Code is understandable with some effort",
      "characteristics": [
        "Most variables have meaningful names",
        "Basic comments present for complex sections",
        "Logic is followable but could be cleaner"
      ]
    },
    {
      "score": 5,
      "label": "Excellent",
      "description": "Code is immediately clear and maintainable",
      "characteristics": [
        "All names are descriptive and consistent",
        "Comprehensive documentation",
        "Clean, modular structure"
      ]
    }
  ],
  "edgeCases": [
    {
      "situation": "Code is well-structured but uses domain-specific abbreviations",
      "guidance": "Score based on readability for domain experts, not general audience"
    }
  ]
}

ガイドライン

1. 必ずスコアを付ける前に根拠を求める - 根拠を先に示すプロンプトは、判断の監査を容易にし、根拠のない数値評価を減らします

2. ペアワイズ比較では必ず位置を入れ替える - 1 回だけの比較では位置バイアスによって結果が歪みます

3. 尺度の細かさをルーブリックの具体性に合わせる - 各レベルの詳細な説明がない場合は、1～10 の尺度を使わないでください

4. 客観的な基準と主観的な基準を分ける - 客観的な基準には直接評価を、主観的な基準にはペアワイズ比較を使用します

5. 信頼度スコアを含める - 位置の一貫性と根拠の強さに基づいて調整します

6. エッジケースを明確に定義する - 曖昧な状況は、評価のばらつきが最も大きくなる原因です

7. 分野に特化したルーブリックを使用する - 汎用的なルーブリックでは、汎用的で（有用性の低い）評価が生まれます

8. 人間の判断と照らし合わせて検証する - 自動評価に価値があるのは、人間による評価と相関する場合に限られます

9. 体系的なバイアスを監視する - 基準、回答の種類、モデルごとに不一致のパターンを追跡します

10. 反復を前提に設計する - 評価システムはフィードバックループによって改善されます

注意点

1. 根拠のない採点：スコアに根拠がなく、デバッグが困難になります。必ずスコアを付ける前に、根拠に基づく説明を求めてください。

2. 1 回だけのペアワイズ比較：位置を入れ替えないと、位置バイアスによって結果が歪みます。必ず位置を入れ替えて 2 回評価し、一貫性を確認してください。

3. 基準の詰め込みすぎ：一度に複数の要素を測定する基準では、信頼できるスコアを得られません。1 つの基準につき、測定可能な側面を 1 つにしてください。

4. エッジケースの指針不足：明確な指示がないと、評価者は曖昧なケースを一貫性なく扱います。明確な解決ルールとともに、エッジケースをルーブリックに含めてください。

5. 信頼度の調整を無視すること：信頼度の高い誤った判断は、信頼度の低い判断よりも問題です。位置の一貫性と根拠の強さに基づいて信頼度を調整してください。

6. ルーブリックの乖離：品質基準の変化やモデルの性能向上に伴い、ルーブリックの調整がずれていきます。定期的にルーブリックを見直し、新たに人手でラベル付けした例を基準としてスコアレベルを再設定してください。

7. 評価プロンプトへの敏感さ：評価プロンプトのわずかな文言の変更で、スコアが大きく変動することがあります。評価プロンプトをバージョン管理し、プロンプトの変更をデプロイする前に回帰テストを実行してください。

8. 制御されていない長さバイアス：簡潔さが好まれる場合でも、長い回答ほど一貫して高く評価されます。評価プロンプトに長さを考慮しないよう明示的な指示を加え、長さを揃えたテストペアで検証してください。

統合

このスキルは、評価者の設計とバイアス軽減を担います。隣接するスキルは、より広範な品質ゲートとインフラを担います。

• evaluation：一般的な決定論的チェック、回帰テストスイート、品質ゲート、本番環境の監視。
• context-fundamentals：評価者用プロンプトのコンテキスト構造。
• tool-design：評価ツールのスキーマとエラー処理。
• context-optimization：大量の評価におけるトークンとレイテンシの効率化。
• harness-engineering：自律ループ向けの評価者インターフェースの固定とガバナンス。

参考資料

内部資料：

• LLM-as-Judge の実装パターン - 参照するタイミング：評価パイプラインを一から構築するとき、または LLM ジャッジを CI/CD に統合するとき
• バイアス軽減手法 - 参照するタイミング：評価結果に一貫性のない採点パターンや疑わしい採点パターンが見られるとき
• 指標選定ガイド - 参照するタイミング：評価の信頼性を検証する統計指標を選ぶとき
• 評価パイプラインの図 - 参照するタイミング：多段階評価システムのアーキテクチャを設計するとき

外部の調査資料：

• Eugene Yan：LLM 評価者の有効性を評価する - 参照するタイミング：LLM 評価の最新動向を調査するとき
• LLM-as-a-Judge の評価（Zheng ほか、2023） - 参照するタイミング：位置バイアスと MT-Bench の手法を理解するとき
• G-Eval：GPT-4 を用いた NLG 評価（Liu ほか、2023） - 参照するタイミング：思考の連鎖による評価スコアリングを実装するとき
• 大規模言語モデルは公平な評価者ではない（Wang ほか、2023） - 参照するタイミング：評価出力における体系的なバイアスを診断するとき

このコレクション内の関連スキル：

• evaluation - 評価の基礎概念
• context-fundamentals - 評価プロンプトのコンテキスト構造
• tool-design - 評価ツールの構築

---

スキルのメタデータ

作成日：2025-12-24 最終更新日：2026-05-15 作成者：Agent Skills for Context Engineering Contributors バージョン：2.1.0