LLM-as-Judge

別のLLMの出力を評価するために強力なLLMを使用します。正しく実行すれば、高速で安価で人間の判断と相関があります。誤って実行すれば、バイアスがあり、矛盾していて、誤解を招きます。

使用時機

• 人間がレビューできる範囲を超えてエバルエーションをスケーリングする場合
• ルールベースのメトリクスが機能しない、要約、コード品質、有用性などのオープンエンドの出力を測定する場合
• ペアワイズモデル比較（同じ入力での A vs B）
• エージェント出力のCI チェック

使用しない場合

• 医療や法律など高リスクの決定 — 人間が必要です
• 判定者がジェネレータと同じモデルの場合 — 独自のスタイルへのバイアスがあります
• ルールで決定できる非常に短い出力 — exact_match の方が安価です
• 判定者が自身で実行できないタスク — 良いコードを書けなければ、コードの品質も判定できません

3つの一般的なパターン

1. ルビック採点

判定者が明示的な基準に対して1～5スケールで1つの出力を評価します。

const prompt = `You are evaluating a response. Rate it 1-5 on each criterion.

<user_query>${query}</user_query>
<response>${response}</response>

Criteria:
- accuracy: factually correct?
- helpfulness: addresses what the user asked?
- conciseness: no unnecessary verbosity?

Return JSON: {"accuracy": N, "helpfulness": N, "conciseness": N, "reasoning": "..."}`;

const judgment = await client.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 500,
  messages: [{ role: "user", content: prompt }],
});

評価するモデルより強力なモデルを判定者として使用してください。Opusが Sonnetを評価し、Sonnetが Haikusを評価します。

2. ペアワイズ比較

2つの出力を表示し、判定者がどちらが優れているかを選択します。最も信頼性の高いパターンです。

const prompt = `Compare two responses to the same query. Pick which is better overall.

<query>${query}</query>
<response_A>${responseA}</response_A>
<response_B>${responseB}</response_B>

Return JSON: {"winner": "A" | "B" | "tie", "reasoning": "..."}`;

位置バイアスをコントロールするために、各ペアを2回実行して順序を入れ替えます。判定を平均化してください。

3. リファレンスベース

出力を金標準リファレンスと比較します：

const prompt = `Is the generated answer equivalent to the reference answer?

<reference>${reference}</reference>
<generated>${generated}</generated>

"Equivalent" means factually consistent — wording can differ.
Return: {"equivalent": true|false, "reasoning": "..."}`;

ルビックより安価ですが、質の高いリファレンスが必要です。

既知のバイアス

バイアス	説明	軽減策
位置バイアス	判定者は最初または2番目のオプションを好む	ランダム化し、ペアを2回実行して順序を入れ替える
長さバイアス	判定者は長い応答を好む	ルビックに「簡潔性」を含める；長さで正規化する
自己選好バイアス	判定者は独自のモデルのスタイルを好む	判定者として異なるモデルファミリーを使用する
冗長性バイアス	判定者は自信のある/装飾的な言語を好む	ルビックは明示的に曖昧さにペナルティを課す
フォーマットバイアス	プロズより Markdown/箇条書きを好む	ルビックはコンテンツをターゲットにしており、フォーマットではない

バイアスを判定者プロンプトに名前を付けてください — それらを削減します：「長い応答を好まないでください；精度のみで判定してください。」

人間とのキャリブレーション

判定スコアのみを信頼してはいけません。キャリブレーション：

1. 50～200の出力をサンプリングします。人間にラベル付けさせます。
2. 同じセットに対して判定者を実行します。スコアを収集します。
3. 人間と判定者間のCohen's kappaまたはPearson相関を計算します。
4. kappa > 0.6の場合、判定者はこのタスクに対して信頼できます。< 0.4の場合は、プロンプトを書き直します。

from sklearn.metrics import cohen_kappa_score
kappa = cohen_kappa_score(human_labels, judge_labels)

四半期ごと、または判定者プロンプトやモデルを変更するたびに再キャリブレーションしてください。

判定者のプロンプト設計

1. ロール優先 — 「あなたはコードレビューの専門家です」
2. 基準を明確に — 「品質」を曖昧なままにしないでください
3. 出力フォーマットを制約 — JSONまたは固定ラベルセット
4. 推論フィールドを含める — モデルに正当性を述べさせ、無分別な判定を削減します
5. 例 — あなたの基準に対する正しい判定の2～3つのショット

構造化出力

JSON として判定を取得して集計できるようにします：

const judgment = await client.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 500,
  messages: [
    { role: "user", content: judgePrompt },
    { role: "assistant", content: "{" },
  ],
});
const parsed = JSON.parse("{" + judgment.content[0].text);

"{" をプリフィルしてから、有効なJSONにナッジします。集計する前にスキーマで検証してください。

スケールでの集計

データセットごと：

• 基準ごとの平均ルビックスコア — 簡単ですが分散を失います
• ペアワイズでの勝率 — 例えば、「モデルBは62%の時間を勝つ」
• スコア分布 — テール内の回帰を検出します（平均が OK でも、いくつかの壊滅的な出力がある場合）

信頼区間（ブートストラップ）を報告してください — 100サンプル上での2%のスコアギャップはノイズの可能性があります。

コスト管理

判定は高価です。コストを削減：

1. サンプル — 10,000ではなく200アイテムを判定します
2. 最初のパスは安価な判定者、不一致には高価な判定者
3. 判定をキャッシュ — 入力が変更されなければ、最後のスコアを再利用します
4. 判定者プロンプト上でプロンプトキャッシング （prompt-caching-ttl を参照）

アンチパターン

1. 判定者 = ジェネレータ — モデルが自身を評価します；大規模な正のバイアス
2. キャリブレーションなし — 接地されていない数字を報告しています
3. ペアワイズの位置バイアス制御なし
4. 曖昧なルビック — 「品質を1～5で評価」 — スコアはノイズが多くなります
5. シングルラン判定 — 重要な評価には複数回の実行を使用してください；分散を測定します

ベストプラクティス

1. より強力で異なるモデルファミリーを判定者として使用する
2. 比較する出力が2つある場合は、ルビックよりペアワイズ比較を選ぶ
3. 常に位置バイアスをコントロール — スワップして平均化する
4. 人間ラベルに対してキャリブレーション；Cohen's kappa > 0.6をターゲットにする
5. バイアスをプロンプトに名前を付けて軽減する
6. 推論フィールド付きの構造化JSONを返す
7. 平均値だけではなく信頼区間を報告する
8. コストを制限するためにキャッシュとサンプルを実施する