同じ回答なのに評価が変わる：LLM採点器を校正し、ドリフトを見分ける方法

昨日は合格した回答が、今日は不合格になる。プロダクトのコードもプロンプトも変えていないのに、評価ダッシュボードだけが下がる。このとき「品質が落ちた」と結論づけるのは早すぎます。

LLM を使った評価には、少なくとも二つの確率的な処理があります。被評価モデルが候補を生成し、別の LLM がその候補を採点します。候補が変わったのか、同じ候補に対する採点が変わったのか、採点器そのものが以前より厳しくなったのか。最終スコアだけでは区別できません。

必要なのは完全な決定性ではなく、変化の帰属です。リリース判断の前に「システム」「採点器」「通常のばらつき」「まだ判断不能」のどれかを示せる測定設計を作ります。

まず同じものを測っているか確認する

評価の流れを分解すると、原因が見えます。

text
テスト入力 -> 被評価システム -> 保存した候補出力 -> LLM採点器 -> 判定

候補出力を毎回作り直してから採点すると、生成側と採点側が同時に動きます。ユーザーが体験する全体のばらつきは分かりますが、採点器の再現性は分かりません。

目的ごとに実験を分けます。

この分析には候補出力の保存、または承認された再生手段が必要です。case ID、データセット版、製品版、候補出力 ID、生成設定、採点モデル、ルーブリック版、パーサー版、判定、時刻を追跡できるようにします。個人情報や機密内容は、保持期間、暗号化、マスキング、アクセス制御を含むデータ方針に従います。

LLMに聞かなくてよい条件を先に外す

JSON が正しいか、必須フィールドがあるか、指定ツールを呼んだか、数値が一致するか、引用 URL が許可リスト内か。これらはプログラムで確定できます。LLM に「全体として良いか」と尋ねるより、決定的なチェックで具体的に失敗させる方が安全です。

LLM 採点器に残すのは、要約が原文に忠実か、回答が利用者の目的を満たすか、拒否が方針を守りながら役に立つか、といった意味判断です。

OpenAI の現行評価ベストプラクティスは、実タスクに対応した eval、継続評価、人手フィードバックによる校正、そして比較や pass/fail のような制約された判定を勧めています。Graders ガイドでも、文字列チェック、類似度、モデル採点が別の手段として扱われます。API は OpenAI 固有ですが、「答えられる最も明確な測定器を使う」という設計は他の環境でも有効です。

一つの総合点にすべてを押し込むと、失敗理由が消えます。形式違反、重大な事実誤り、少し冗長という三つの問題が同じ 7.2 点になる設計では、同じリリース処理しか選べません。

採点器にも受入試験が必要

採点器を CI に置く前に、その採点器専用の評価集合を用意します。

• 誰が見ても合格、誰が見ても不合格の例
• 方針を決める必要がある境界例
• 実際の障害、問い合わせ、人手修正の例
• 品質は近いが、順序、長さ、書式、モデル名だけが異なるペア
• 流暢だが重要な誤りを含む回答と、簡潔だが正しい回答
• 実運用にある言語、タスク、長さ、リスク層
• 専門家同士でも判断が割れる例

専門家はまず独立にラベルを付けます。不一致は邪魔なノイズではありません。ルーブリックが曖昧、複数の方針が妥当、自動判定すべきでない、といった重要な情報です。

MT-Bench と Chatbot Arena の研究は、限定された構成で強い LLM 採点器と人間の高い一致を示す一方、位置、冗長性、自己優遇、推論能力の限界を報告しました。その一致率は当時のモデル、プロンプト、データの結果であり、別の採点器の精度証明にはなりません。

Large Language Models Are Not Fair Evaluatorsでは、候補の提示順だけで順位が変わり得ることが示され、順序の均衡化、複数根拠、人手介入が検討されました。さらに、12 の採点器、22 タスク、10 万件を超える評価を扱った位置バイアスの体系的研究は、偏りが採点器とタスクによって異なることを示しています。「高性能モデルを使った」は校正の代わりになりません。

再現性と偏りを別の試験で測る

固定出力を繰り返し採点する

同じ候補を同じ採点契約で複数回評価し、平均だけでなく全判定を保存します。明らかな合格例が合格と不合格を行き来するなら、二値のリリースゲートには使えません。

変動が本当に曖昧な例に集中するなら、採点プロンプトで無理に一つへ寄せるのではなく「人手確認」の領域を作る方が正確です。

A/B と B/A を両方試す

ペア比較では候補の位置を交換します。保守的には、両順序が同じ候補を選んだ場合だけ勝ちとし、食い違いは tie または review にします。大規模時に順序をランダム化しても、順序一致率は別に監視します。平均に隠すと、系統的な偏りを発見できません。

品質を変えずに表面だけ変える

内容を保ったまま、長さ、見出し、丁寧さ、候補名、強い口調だけを変えます。点数が表面に追従するなら、採点器は目的の品質ではなく好みを測っている可能性があります。

これは grader hacking の検知にも使えます。製品が長く権威的な文章を学び、自動点だけ上がるのに専門家の評価は上がらない、という状態です。

根拠がある課題には根拠を渡す

抽出、出典付き Q&A、要約忠実度、数学、tool use では、原文、参照解答、実行結果を採点器に渡します。採点理由は調査の手掛かりになりますが、正しさの証明ではありません。同じモデルが誤判定を流暢に説明することもあります。

校正は平均値の差し引きではない

人間の平均が 0.70、採点器が 0.78 だから常に 0.08 を引く、という補正では不十分です。確認すべきは運用上の意思決定です。

• 明確な不合格をどれだけ通すか
• 明確な合格をどれだけ止めるか
• 誤りが言語、タスク、長さ、リスク層に偏っていないか
• 閾値付近で判定がどれだけ反転するか
• 人間も迷う例と採点器が迷う例が一致するか

false accept と false reject のコストは同じではありません。高リスク助言を通す損失と、マーケティング文を余分にレビューする損失では、必要な境界が変わります。許容する失敗を先に定義し、そのデータから標本数、反復予算、review 幅を決めます。全タスク共通の 0.80 や反復回数はありません。

リリースには pass / fail / review の三値が扱いやすい場合があります。連続スコアは分析用に残せますが、校正データ以上の精密さを演出してはいけません。

固定アンカーを並走させる

校正後は、人手ラベルを確定した出力の安定した核を残します。現在の採点器で、実運用サンプルと並行して定期的に再採点します。

text
本番ストリーム：現在の製品出力 -> 現在の採点器 -> 製品信号
アンカー流　　：固定人手ラベル -> 現在の採点器 -> 採点器信号

本番だけが下がりアンカーが安定していれば、製品やトラフィック分布を先に調べます。アンカーでも採点器が厳しくなれば、採点モデル、ルーブリック、例示、パーサー、backend を確認します。両方が不安定なら、まだゲートに使える測定状態ではありません。

2026 年のプレプリント Who Drifted: the System or the Judge?は、人手ラベル付き固定アンカーで採点器と人間の差を監視し、本番ストリームと分離する方法を形式化しました。論文の検出率やコストはその実験条件の結果であり、導入保証ではありません。再利用できる考え方は、製品の変更は保存済みアンカーの内容を変えないが、採点器の変更はその評価を変え得る、という識別です。

アンカーの安定した核をリリースごとに書き換えてはいけません。新しい失敗例は版を付けて追加し、人手ラベルやルーブリックを変えた理由も残します。

リリースゲートは「判断不能」を扱う

判定順序を明示します。

text
1. 決定的な契約はすべて通ったか
2. 採点器は固定アンカー上で校正範囲内か
3. 固定出力の再採点は十分に安定しているか
4. 新旧差は通常のばらつきを明確に超えるか
5. 変化は高リスク層に集中していないか
6. 専門家へ送る不一致例が残っていないか

結果は、通過、ブロック、採点器調査、人手確認へ分岐します。「調査」と「人手確認」は失敗ではなく、根拠のない二値判断を防ぐ安全な状態です。

温度 0 も完全な決定性を証明しません。モデル alias、推論基盤、プロンプト組立、tool の結果、パーサーが変化源になります。OpenAI の過去のseed と system fingerprint の再現例も、対応していた当時の preview モデルで「ほぼ同じ」を目指すもので、決定性は保証しないと明記しています。現在の全モデル、endpoint、provider へ一般化はできません。

採点モデル、ルーブリック、few-shot 例、出力 schema、パーサー、集計、意思決定ポリシーを一つの版付き契約として保存します。提供される request ID や backend fingerprint も記録します。これらは違いを説明する手掛かりであって、確率システムを unit test に変える魔法ではありません。

単発スコアではなく、固定出力の再現性、人手との校正、偏り試験、固定アンカーという四つの証拠を揃えると、評価は初めて測定になります。強いゲートはいつでも結論を出すゲートではありません。根拠が不足したときに止まり、どの層を調べるべきかを示せるゲートです。