高度な評価

高度な評価（Advanced Evaluation）

このスキルは、LLMを評価者（ジャッジ）として使用し、LLM出力をプロダクションレベルで評価するための手法をカバーします。学術論文、業界の実践、実装経験から得られた研究知見を統合し、信頼性の高い評価システムを構築するための実践可能なパターンを提供します。

重要な洞察：LLM-as-a-Judgeは単一の手法ではなく、それぞれ異なる評価コンテキストに適したアプローチ群です。適切なアプローチを選択し、既知のバイアスを軽減することが、このスキルが開発する中核的な能力です。

いつアクティベートするか

以下の場合にこのスキルをアクティベートしてください：

• LLM出力に対するLLM-as-Judgeシステムを構築する場合
• 複数のモデル応答を比較して最適なものを選択する場合
• 評価チーム全体で一貫した品質基準を確立する場合
• 一貫性のない結果を示す評価システムをデバッグする場合
• プロンプトやモデル変更のためのA/Bテストを設計する場合
• LLM評価者または人間/LLMハイブリッド評価者のためのルーブリックを作成する場合
• 自動評価と人間による評価の相関を分析する場合

他のスキルが担当する隣接作業では、このスキルをアクティベートしないでください：

• 一般的な決定論的チェック、回帰スイート、プロダクション品質ゲート、成果指標：evaluation
• 自律ループガバナンス、固定ルーブリック、ロールバック、PR承認境界：harness-engineering
• 評価ツールのツールAPI契約：tool-design

中核的概念

評価の分類（Evaluation Taxonomy）

正解データ（ground truth）が存在するかどうかに基づいて、2つの主要なアプローチから選択します：

直接スコアリング（Direct Scoring） — 客観的な基準（事実の正確性、指示への従順性、毒性）が存在する場合に使用します。単一のLLMが、定義された尺度で1つの応答を評価します。明確に定義された基準では中程度から高い信頼性を達成します。スコアキャリブレーションのドリフトや、尺度解釈の一貫性のなさに注意してください。

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

バイアスの状況（Bias Landscape）

すべての評価システムで、以下の系統的なバイアスを軽減します：

位置バイアス（Position Bias）: 最初の位置にある応答が優先的に扱われます。位置を入れ替えて2回評価し、多数決または一貫性チェックを適用することで軽減します。

長さバイアス（Length Bias）: 品質に関係なく、より長い応答が高いスコアを得ます。長さを無視するように明示的にプロンプトし、長さで正規化したスコアリングを適用することで軽減します。

自己増強バイアス（Self-Enhancement Bias）: モデルは自身の出力を高く評価します。生成と評価に異なるモデルを使用することで軽減します。

冗長性バイアス（Verbosity Bias）: 不必要であっても、過剰な詳細が高いスコアを得ます。無関係な詳細にペナルティを課す、基準固有のルーブリックで軽減します。

権威バイアス（Authority Bias）: 正確性に関係なく、自信に満ちたトーンが高いスコアを得ます。エビデンスの引用を要求し、事実確認レイヤーを追加することで軽減します。

メトリクス選択フレームワーク

評価タスクの構造にメトリクスを一致させます：

タスクタイプ	主要メトリクス	二次メトリクス
二値分類（合格/不合格）	再現率、適合率、F1値	Cohenのκ係数
順序尺度（1-5評価）	Spearmanのρ, Kendallのτ	Cohenのκ係数（重み付け）
ペアワイズ選好	一致率、位置の一貫性	信頼度キャリブレーション
マルチラベル	Macro-F1, Micro-F1	ラベルごとの適合率/再現率

絶対的な一致率よりも、系統的な不一致パターンを優先します。なぜなら、特定の基準で人間と一貫して意見が異なる評価者は、ランダムノイズがある評価者よりも問題であるためです。

評価アプローチ

直接スコアリングの実装

直接スコアリングは、明確な基準、キャリブレーションされた尺度、構造化された出力形式の3つのコンポーネントで構築します。

基準定義パターン:

Criterion: [名前]
Description: [この基準が測定するもの]
Weight: [相対的な重要度、0-1]

尺度のキャリブレーション — ルーブリックの詳細度に基づいて尺度の粒度を選択します：

• 1-3：中間オプション付きの二値、最も低い認知負荷
• 1-5：標準的なリッカート尺度、粒度と信頼性の最良のバランス
• 1-10：各レベルに詳細なルーブリックがある場合のみ使用。キャリブレーションが難しいため

直接スコアリングのプロンプト構造:

あなたは応答品質を評価する専門の評価者です。

## タスク
以下の各基準に対して評価を実施してください。

## 元のプロンプト
{prompt}

## 評価する応答
{response}

## 基準
{for each criterion: name, description, weight}

## 指示
各基準について：
1. 応答内から具体的なエビデンスを見つける
2. ルーブリックに従ってスコアを付ける（1-{max}尺度）
3. エビデンスを用いてスコアを正当化する
4. 1つの具体的な改善点を提案する

## 出力形式
スコア、正当化、要約を含む構造化JSONで応答してください。

スコアリングプロンプトでは、スコアの前にエビデンスを要求します。これにより、評価者は数値を出す前に、観察可能な出力特徴に判断を基づかせる必要があります。

ペアワイズ比較の実装

すべてのペアワイズ評価に位置バイアス軽減を適用します：

1. まず決定論的事前チェックを実行：両方の候補が同じスキーマ、ソースエビデンス要件、スコープ制約を満たしていることを確認します。
2. 1回目の評価パス：応答Aを最初の位置、応答Bを2番目の位置に配置。
3. 2回目の評価パス：応答Bを最初の位置、応答Aを2番目の位置に配置。
4. 一貫性チェック：パス間で不一致の場合、信頼度を下げてTIE（引き分け）を返します。
5. 最終判定：一貫した勝者に平均信頼度と明示的なタイブレークの理由を付与。

ペアワイズ比較のプロンプト構造:

あなたは2つのAI応答を比較する専門の評価者です。

## 重要な指示
- 応答が長いからといって優先しないでください
- 位置（1番目か2番目か）に基づいて応答を優先しないでください
- 指定された基準に従って品質のみに焦点を当ててください
- 応答が真に同等である場合、引き分けは許容されます

## 元のプロンプト
{prompt}

## 応答A
{response_a}

## 応答B
{response_b}

## 比較基準
{criteria list}

## 指示
1. 最初に各応答を独立して分析する
2. 各基準でそれらを比較する
3. 信頼度レベルを添えて全体的な勝者を決定する

## 出力形式
基準ごとの比較、全体的な勝者、信頼度（0-1）、および推論を含むJSON。

信頼度キャリブレーション — 信頼度を位置の一貫性にマッピングします：

• 両方のパスが一致：信頼度 = 個々の信頼度の平均
• パスが不一致：信頼度 = 0.5、判定 = TIE

ルーブリック生成

ルーブリックを生成して、自由形式のスコアリングと比較して評価のばらつきを減らします。正確な分散削減量は、対象の評価セットで測定されない限り、ワークロード固有として扱います。

以下のルーブリックコンポーネントを含めます:

1. レベル説明: 各スコアレベルの明確な境界
2. 特性: 各レベルを定義する観察可能な特徴
3. 例: 各レベルの代表的なテキスト（オプションですが価値あり）
4. エッジケース: 曖昧な状況のガイダンス
5. スコアリングガイドライン: 一貫した適用のための一般原則

ユースケースに応じた厳格さのキャリブレーションを設定します：

• 寛大（Lenient）: 合格基準が低く、イテレーションを促進する場合に適切
• バランス（Balanced）: 典型的なプロダクション期待値
• 厳格（Strict）: 安全クリティカルまたはハイステークス評価のための高い基準

ルーブリックをドメインに適応させます — ドメイン固有の用語を使用します。コード可読性のルーブリックは、変数、関数、コメントに言及します。医療精度のルーブリックは、臨床用語とエビデンス基準を参照します。

実践的なガイダンス

評価パイプラインの設計

プロダクション評価システムを以下のレイヤーで構築します：基準ローダー（ルーブリック + 重み） -> 一次スコアラー（直接またはペアワイズ） -> バイアス軽減（位置入れ替えなど） -> 信頼度スコアリング（キャリブレーション） -> 出力（スコア + 正当化 + 信頼度）。完全なビジュアルレイアウトについては、評価パイプラインダイアグラムを参照してください。

意思決定フレームワーク：直接 vs ペアワイズ

以下のディシジョンツリーを適用します：

客観的な正解データは存在するか？
+-- はい -> 直接スコアリング
|   例：事実の正確性、指示への従順性、フォーマット準拠
|
+-- いいえ -> 好みや品質判断か？
    +-- はい -> ペアワイズ比較
    |   例：トーン、スタイル、説得力、創造性
    |
    +-- いいえ -> 参照ベースの評価を検討
        例：要約（ソースと比較）、翻訳（参照と比較）

評価のスケーリング

高負荷の評価には、以下の戦略のいずれかを適用します：

1. LLMパネル（PoLL）: 複数のモデルを評価者として使用し、投票を集約して個々のモデルのバイアスを低減します。より高価ですが、ハイステークスの決定に対してより信頼性が高くなります。

2. 階層的評価: 高速で安価なモデルをスクリーニングに使用し、高価なモデルをエッジケースに使用します。スクリーニングしきい値のキャリブレーションが必要です。

3. 人間参加型（Human-in-the-loop）: 明確なケースは自動化し、低信頼度の決定は人間のレビューに回します。自動評価を時間の経過とともに改善するためのフィードバックループを設計します。

例

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

入力:

プロンプト: 「地球上の季節の原因は何ですか？」
応答: 「季節は地球の傾いた地軸によって引き起こされます。地球が太陽の周りを公転するにつれて、
異なる半球が一年の異なる時期により直接的な日光を受けます。」
基準: 事実の正確性（重み：1.0）
尺度: 1-5

出力:

{
  "criterion": "事実の正確性",
  "score": 5,
  "evidence": [
    "地軸の傾きを主な原因として正しく特定している",
    "半球ごとの日照量の違いを正しく説明している",
    "事実誤認は存在しない"
  ],
  "justification": "応答は季節の原因を正しい科学的推論で正確に説明しています。地軸の傾きと日照量の分布への影響の両方が正しく記述されています。",
  "improvement": "完全性のために、具体的な傾きの角度（23.5度）を追加してもよいでしょう。"
}

例2：位置入れ替えを伴うペアワイズ比較

入力:

プロンプト: 「初心者に機械学習を説明してください」
応答A: [専門用語を使った技術的な説明]
応答B: [アナロジーベースのシンプルな説明]
基準: ["明確さ", "アクセシビリティ"]

1回目のパス（Aが先）:

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

2回目のパス（Bが先）:

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

（注：Bが最初の位置にあったため、勝者はAになっています）

マッピングされた2回目のパス:

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

最終結果:

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

例3：ルーブリック生成

入力:

criterionName: "コード可読性"
criterionDescription: "コードがどれだけ理解しやすく保守しやすいか"
domain: "ソフトウェアエンジニアリング"
scale: "1-5"
strictness: "balanced"

出力（省略版）:

{
  "levels": [
    {
      "score": 1,
      "label": "悪い",
      "description": "コードは多大な努力なしでは理解が困難",
      "characteristics": [
        "意味のある変数名や関数名がない",
        "コメントやドキュメントがない",
        "深くネストされた、または複雑なロジック"
      ]
    },
    {
      "score": 3,
      "label": "普通",
      "description": "コードはある程度の努力で理解可能",
      "characteristics": [
        "ほとんどの変数に意味のある名前が付いている",
        "複雑なセクションに基本的なコメントが存在する",
        "ロジックは追跡可能だが、よりクリーンにできる"
      ]
    },
    {
      "score": 5,
      "label": "優秀",
      "description": "コードは即座に明確で保守可能",
      "characteristics": [
        "すべての名前が説明的で一貫している",
        "包括的なドキュメントが存在する",
        "クリーンでモジュール化された構造"
      ]
    }
  ],
  "edgeCases": [
    {
      "situation": "コードは構造化されているが、ドメイン固有の略語を使用している",
      "guidance": "一般的な読者ではなく、ドメイン専門家にとっての可読性に基づいてスコア付けする"
    }
  ]
}

ガイドライン

1. スコアの前に常にエビデンスを要求する - エビデンスファーストのプロンプトは、判断の監査を容易にし、根拠のない数値スコアリングを減らします

2. ペアワイズ比較では常に位置を入れ替える - シングルパス比較は位置バイアスによって歪められます

3. 尺度の粒度をルーブリックの詳細度に一致させる - 詳細なレベル説明なしで1-10尺度を使用しないでください

4. 客観的基準と主観的基準を分離する - 客観的には直接スコアリング、主観的にはペアワイズ比較を使用します

5. 信頼度スコアを含める - 信頼度を位置の一貫性とエビデンスの強さにキャリブレーションします

6. エッジケースを明示的に定義する - 曖昧な状況が評価のばらつきを最も大きく引き起こします

7. ドメイン固有のルーブリックを使用する - 汎用ルーブリックは汎用的で（あまり有用でない）評価を生成します

8. 人間の判断に対して検証する - 自動評価は、人間の評価と相関する場合にのみ価値があります

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

10. イテレーションのために設計する - 評価システムはフィードバックループによって改善されます

注意点（Gotchas）

1. 正当化なしのスコアリング：スコアに根拠がなく、デバッグが困難です。スコアの前に常にエビデンスベースの正当化を要求してください。

2. シングルパスのペアワイズ比較：位置が入れ替えられていない場合、位置バイアスが結果を歪めます。常に位置を入れ替えて2回評価し、一貫性を確認してください。

3. 過負荷な基準：複数のものを同時に測定する基準は、信頼性の低いスコアを生成します。1つの基準 = 1つの測定可能な側面を強制してください。

4. エッジケースガイダンスの欠如：明示的な指示がないと、評価者は曖昧なケースを一貫性なく処理します。明確な解決ルールとともに、ルーブリックにエッジケースを含めてください。

5. 信頼度キャリブレーションの無視：信頼度の高い誤った判断は、信頼度の低い判断よりも悪質です。信頼度を位置の一貫性とエビデンスにキャリブレーションします。