コンテンツにスキップ

LLM-as-Judge — 評価者 LLM の組み立て方#

Techniques #eval #llm-judge #review #technique updated 2026-04-13 3 min read

LLM の出力品質を別の LLM に評価させる手法。主観的な評価軸（トーン、読みやすさ、含意の適切さ）を自動化できる。ただし評価者自身にバイアスがあるため、実装には注意が要る。

基本構造#

flowchart LR
    I[評価対象の入力] --> M[対象 LLM]
    M --> O[対象の出力]
    I --> J[評価者 LLM]
    O --> J
    R[評価ルーブリック] --> J
    J --> S[スコア + 理由]

評価ルーブリックの設計#

評価者に「良いかどうか」を聞くだけでは不安定。評価軸を分解し、軸ごとに定義と満点基準を明示する。

## 評価軸
1. 事実正確性（0-5）
  - 5: 全ての事実が検証可能で正しい
  - 3: 大半は正しいが、1-2 箇所の誤り
  - 1: 複数の事実誤認
  - 0: 全体的に誤り
2. 形式遵守（0-5）
  - 5: 指定フォーマットを完全に守っている
  - ...

バイアスを減らす工夫#

1. 位置バイアスを避ける

2 つの出力を比較させる場合、AB / BA の両順で評価して平均を取る。LLM は最初に見た選択肢を優先しがち。

flowchart LR
    A[出力 A] --> P1[評価 1<br/>A→B 順]
    B[出力 B] --> P1
    A --> P2[評価 2<br/>B→A 順]
    B --> P2
    P1 --> AVG[平均スコア]
    P2 --> AVG

2. スコアだけでなく理由を出させる

score: 7 とだけ返させると、理由なしで一貫性のないスコアを吐く。reasoning → score の順で返させると、推論の一貫性が上がる。

3. モデルを変える

評価対象と評価者で別モデルを使う。同じモデルだと自己一致バイアスが出やすい。

4. 人間によるスポットチェック

評価者の判定を定期的にサンプリングして人間が確認する。評価者自身の劣化を検出する。

よくあるアンチパターン#

  • 評価者プロンプトに対象の出力を混ぜて書く: プロンプトインジェクションで評価結果が乗っ取られる
  • 主観的な語彙しか使わない: 「良い」「自然」「適切」だけではスコアが揺れる。具体的な定義が必要
  • 評価セットが小さい: 10 件で平均を出しても、ノイズに埋もれる。最低 50〜100 件欲しい

運用パターン#

プロンプト改善や新モデル導入の前後で、評価セットを回して回帰をチェックする。スコアが有意に下がったら採用を見送る。

flowchart TD
    C[変更案] --> T[評価セット実行]
    T --> R{スコア比較}
    R -->|有意に向上| A[採用]
    R -->|変化なし| X[見送り]
    R -->|低下| X

まとめ#

LLM-as-Judge は完全な代替ではなく、人間の目を補う仕組み。自動化できる部分だけ自動化し、最終判定は人間が握る運用が現実的。

関連エントリ#