LLM-as-a-Judge

別のLLMパイプラインの出力を判定するLLMを使用した信頼性の高い自動評価器を構築します。各判定者は、エラー分析で特定された単一のバイナリ(合格/不合格)失敗モードを対象とします。

LLM-as-Judge とコードベースの評価器の使い分け

各失敗モードに適切な評価器タイプを選択します:

コードベースの評価器を使用する場合は、失敗が客観的かつ決定論的な場合です:

• JSON/SQLシンタックスの有効性、正規表現/文字列マッチング、構造的制約、実行エラー、論理チェック。
• これらは高速で低コスト、決定論的で解釈可能です。

LLM-as-Judge を使用する場合は、失敗が解釈または細微な判断が必要な場合です:

• トーンの適切さ、要約の忠実性、応答の有用性、説明の明確さ、創意的な品質。
• これらはアプリケーションとは異なる別のLLMを必要とします。

各失敗モードには独自の専用評価器を設けます。複数の判定基準を単一のジャッジプロンプトに組み合わせないでください。これは曖昧性を生み出し、診断を困難にします。

完全なワークフロー

1. プロンプトテンプレートの作成
2. ラベル付きデータの分割(トレーニング / 開発 / テスト)
3. プロンプトの反復的改善(開発セットでTPR/TNRを測定)
4. 成功率の推定と補正(テスト + ラベルなしデータ)

---

ステップ1: ジャッジプロンプトの作成

よく構造化されたジャッジプロンプトには、4つの重要な要素があります。完全な注釈付き例については references/prompt-template.md を参照してください。

1. 明確なタスクと評価基準

1つのよく定義された失敗モードに焦点を当てます。曖昧なタスクは信頼性の低い判定につながります。

• ❌ 「このメールは良いですか?」
• ✅ 「トーンは高級品購入者ペルソナに適切ですか?」

2. 正確な合格/不合格の定義

エラー分析からの失敗説明に基づいて、合格(失敗なし)と不合格(失敗あり)が何であるかを定義します。境界条件について具体的に説明してください。

3. 少数ショットの例

明確に合格し、明確に不合格となるラベル付き例を含めます。これらは判定者の決定境界を調整します。人間によってラベル付けされたトレースから引き出すのが最適です。

• 初期の例には、エッジケースではなく明確なケースを使用します。
• バイナリ判定の場合は、少なくとも1つの合格例と1つの不合格例を含めます。
• より細かい段階を使用する場合(例: 1〜3の重大度)、スケールのすべてのポイントについて例を含めます。

4. 構造化された出力形式

判定者は一貫した機械可読形式で応答します:

{
  "reasoning": "決定についての1〜2文の説明。",
  "answer": "Pass"
}

reasoning フィールドが最初に来ます。これは判定前に思考の連鎖を促導し、精度を向上させます。

---

ステップ2: ラベル付きデータの分割

判定者の設計は分類器の訓練に似ていますが、「訓練」はプロンプトエンジニアリングを通じて行われます。人間によってラベル付けされたトレースを3つの分割されていないセットに分割します:

セット	目的	典型的な配分
トレーニング	プロンプト内の少数ショット例の候補プール	10〜20%
開発	プロンプトを反復的に改善。人間ラベルとの一致を測定	40〜45%
テスト	判定者精度(TPR/TNR)の最終的で偏りのない測定	40〜45%

主要なルール:

• 開発例はプロンプトに含まれてはいけません。 これは汎化測定を保証します。
• テスト例はプロンプトが確定するまで保持されます。 開発中に確認しないでください。
• コンテキスト内学習は通常、1〜8個のよく選ばれた例の後に飽和します。より多くのデータを評価に配分します。
• 開発とテストの両方に十分な合格と不合格の例が含まれている必要があります。理想的には各30〜50個です。
• 分割間で例を再利用するとオーバーフィッティングと精度の水増しにつながります。

〜100個のラベル付きトレース(合格50個、不合格50個)がある場合、合理的な分割は: トレーニング10個、開発40個、テスト50個です。

---

ステップ3: プロンプトの反復的改善

これはコアループです。分類器の調整と考えてください。ただし、パラメータを調整するのではなくテキストを修正することです。

改善ループ

1. ベースラインプロンプトを作成します。上記の4つの要素を使用し、トレーニングセットからのいくつかの例を含めます。
2. 開発セットで判定者を実行します。 各判定を人間の基準事実と比較します。
3. TPRとTNRを使用して一致を測定します:
   • TPR = (実際の合格で正しく合格と判定されたもの) / (合格と判定された総数)
   • TNR = (実際の不合格で正しく不合格と判定されたもの) / (不合格と判定された総数)
4. 一致していない部分を検査します。 誤った合格(判定者は合格、人間は不合格)と誤った不合格を確認します。曖昧な基準または見落とされたエッジケースを特定します。
5. プロンプトを改善します: 合格/不合格の定義を明確にし、トレーニングからより良い少数ショット例に交換し、代表的なエッジケースを追加します。
6. TPRとTNRが許容可能なレベルで安定するまで繰り返します。

TPRとTNRを使用する理由(精度/再現性ではなく)

最終的な目標はパイプラインの真の合格率を推定することです。判定者がこれを誤推定する方法は2つだけです: 実際の合格を見落とす(観察率を低下させる)か、実際の不合格を合格させる(これを膨らませる)か。TPRとTNRはこれら2つのエラーモードを直接捉えます。

停止の時機

TPRとTNRが満足のいくレベル(通常>90%)に達したときに停止します。実際の失敗を見落とすことは、偽陽性にフラグを立てるより高価かもしれません。アプリケーションのリスク許容度に合わせてしきい値を調整します。

一致が停滞した場合

• より強力なLLMを使用します 。より大きなモデルは微妙なエラーを解決できるかもしれません。
• 基準を分解します 。複雑な失敗をより小さな原子的チェックに分割します。
• ラベル付きデータを改善します 。特にエッジケースを含む、多様で高品質な例を追加します。
• ラベルの品質を確認します 。時々、問題は一貫性のない、または不正確な人間ラベルです。

オートメーション(例: DSPy)の前に手動の反復をお勧めします。これは失敗モードと判定者の行動の両方についての直感を構築します。プロンプトを書くことで、仕様を外部化することができます。

---

ステップ4: 真の成功率の推定

プロンプトを確定した後、凍結してテストセットで実行しTPRとTNRを取得します。次に、判定者をラベルなしの本番トレースで偏り補正を使用して実行します。

完全な手順、式、Pythonコード、および信頼区間の計算については references/success-rate-estimation.md を参照してください。

クイックリファレンス

1. テストセットで判定者の精度を測定します → TPR、TNR
2. ラベルなしデータで生の成功率を観察します → p_obs = k/m
3. Rogan-Gladen公式を使用して偏りを補正します:

   θ̂ = (p_obs + TNR - 1) / (TPR + TNR - 1)    [0,1にクリップ]
   

4. ブートストラップ信頼区間 。テストセットラベルを B 回再サンプリングし、毎回補正率を再計算し、2.5パーセンタイル/97.5パーセンタイルを取得します。

TPR + TNR - 1 ≈ 0の場合、判定者はランダムチャンスより優れておらず、補正は無効です。

主要なインサイト

TPRの改善(判定者が真の成功を特定する能力)は信頼区間を最も狭めます。判定者エラーは主に不確実性を膨らませるのではなく、補正推定値をシフトさせます。

---

一般的な落とし穴

1. プロンプトから例を省略します。 具体的な例がなければ、判定者は根拠を持ちません。これが最も一般的な間違いです。

2. 単一のプロンプトで複数の基準を評価します。 複雑なメトリクスをより狭く、具体的なプロンプトに分割して、より良い一致と診断可能性を実現します。

3. 一致検証をスキップします。 判定者が「単に機能する」と仮定しないでください。ドメイン固有の基準にはプロンプト改善と人間によるラベル付き検証が必要です。

4. ラベル付きトレースへのオーバーフィッティング。 少数ショット例が評価セットにも表示される場合、TPR/TNRは膨らみます。プロンプトで使用されたトレースはすべて開発とテストから除外する必要があります。

5. 判定者を再度訪問しません。 本番データはドリフトし、新しい失敗モードが出現し、LLM更新は動作をシフトさせます。定期的に再検証します。

6. 判定者モデルのバージョンを固定しません。 CIパイプラインでは、正確なモデルバージョン(例: claude-sonnet-4-5-20250929)を固定して、予告なしの更新によって結果が変動するのを防ぎます。

---

長ドキュメントの考慮事項

長ドキュメントパイプラインからの出力を判定する場合:

• 完全なドキュメントを判定者に供給しないでください。関連部分のみを使用します(例: 要約の出所となるソース段落)。
• チャンクレベルの評価を検討し、チャンクごとの判定を集約します。
• 判定者は完全なコンテキストを見ないので、「正確」が何を意味するのかについてルーブリックを特に明確にします。

---

CI統合

継続的統合では、参照出力を持つキュレートされた入力例のゴールデンデータセットを構築します。パイプライン変更ごとに:

1. すべてのゴールデン入力をパイプラインで実行します。
2. 自動評価器スイート(コードベース + LLM-as-Judge)で出力を評価します。
3. 判定者モデルのバージョンを固定してCIフリッカーを防ぎます。
4. コア機能、既知の失敗モード、およびエッジケースをカバーする例を含めます。

これは回帰をキャッチしますが、本番全体の精度を予測しません。その目的はパイプラインが進化するにつれて安定性を確保することです。