LLM ジャッジのスコアを信頼する前にジャッジを調整する方法

最近の作業上の質問で、キャリブレーションの前提条件が共有されました

2026 年 5 月のプレプリントでは、比較されたモデル間でキャリブレーションが共有される場合の、裁判官ベースの推定値の偏りと不安定性を調査しています。比較が間違った方向を指す可能性がある状況について説明します。 JudgeBiasBench は、複数の形式の判断バイアスを個別に研究します。これらの発見により、強力なモデルを自動的に信頼するのではなく、タスク固有のチェックが動機付けられます。

証拠: 裁判官としての LLM の推定におけるバイアスと不確実性 [1]堅牢な LLM ベースのジャッジに向けて: 分類学的バイアス評価とバイアス除去の最適化 [2]

独立したキャリブレーション セットを構築する

Rubrex は、明確なパス、明確な失敗、および困難な境界を含む代表的な出力を選択することをお勧めします。資格のある審査員に、審査員の結果を見ずに書面によるルーブリックを適用させます。人間のラベルがすべて明確であると仮定するのではなく、意見の相違や判決を記録します。

最終審査員を評価するために使用される例から、採点者のプロンプトを改良するために使用される例を分割します。同じキャリブレーション セットで繰り返し調整すると、移行を実証することなく一致をより良く見せることができます。サンプルとそのラベル履歴を保存して、将来の変更を公平に比較​​できるようにします。

意見の相違の形を調べる

バイナリ基準の場合、誤った合格と誤った失敗を区別します。序数スコアの場合は、相関関係だけではなく、大きなエラーやカテゴリ固有の混乱を検査します。審査員は査読者と同様に出力をランク付けし、体系的に過度に寛大なスコアを割り当てることができます。

品質に影響を与えてはならない場合は、回答順序、冗長性、書式設定、またはプロバイダー識別子など、考えられる迷惑な変更をテストします。ペアを反転することは便利ですが、すべてのバイアスを診断できるわけではありません。実際の候補者に似ている出力スタイル間で同じルーブリックを比較します。

実例: 正確だが簡潔

裁判官は、両方の候補者が必要な事実を含んでおり、任務が簡潔さを要求している場合でも、繰り返し詳細な回答を好みます。長さに対する暗黙の報酬についてルーブリックを確認してください。簡潔な正しい例と冗長な間違った例を追加し、保持されたセットで改訂された採点者をテストします。

裁判官に偏見を持たないよう指示するだけで、問題が解決したと思い込まないようにしてください。前後の不一致の記録を保持し、修正によって必要な詳細に対して新たな優先順位が導入されていないかどうかを検査します。

タスクが変更されたときに再調整する

モデル識別子、プロンプト、スキーマ、参照資料、およびスコアリング ルールを一緒にバージョン管理します。ジャッジのアップグレード、新しい候補モデル ファミリ、大幅なプロンプト変更、または異なるタスク配分の後に再確認してください。スコアが重要な場合、または証拠が不十分な場合は、人間によるレビューのための道を確保してください。

LLM エバリュエーター: エバリュエーター モデルの選択と確認

審査員としての LLM は、モデルを使用して別のシステムの出力に基準を適用します。このワークフローでは、評価者モデル、プロンプト、参照資料、およびスコアリング ルールが 1 つのバージョン管理された依存関係を形成します。最も能力の高いモデルや最も高価なモデルが最良の判断基準であると仮定するのではなく、タスクからレビューされたサンプルのパフォーマンスに基づいて依存関係を選択してください。

裁判官の信頼性を評価するには、予想されるラベル、評価者のラベル、説明、影響を受ける要件、意見の不一致の結果などのエラー台帳を保管してください。同じ保留されたケースについて候補の評価者を比較します。 Rubrex では、正確な要件については決定論的なチェックを行い、未解決の判断については人的エスカレーション パスを確保しておくことを推奨しています。アプリケーションが新しい種類の回答の生成を開始したら、台帳を再参照します。

よくある質問