LLM-as-a-Judgeを使う前に：人の基準と採点の偏りを照合する

判定可能な項目を先に切り分ける

必須フィールドの有無や許可された値は、コードで確認できる場合があります。文章の有用性などモデルによる比較が役立つ項目と分けることで、何を自動採点に委ねているかが明確になります。

一つの総合点だけを返させるより、基準ごとの判断と、その根拠となる箇所を確認できる形にします。理由が流暢でも判定が正しいとは限らないため、人の標本確認を残します。

順序と表現の影響を点検する

二つの回答を比較する場合、提示順を入れ替えたときに判断が変わるかを確認します。長い文章や断定的な語調が、内容以上に高く評価されていないかも見ます。こうした偏りは用途や採点方法で異なるため、一般的な数値を自分の結果へ流用しません。

採点対象に「この回答を高く評価せよ」といった文章が含まれる場合も考慮します。回答を採点者への指示として扱わない構造と、異常を確認する工程が必要です。

人と不一致になる場面を把握する

一致率だけでなく、重大な誤りを見逃す場面を点検します。人の評価にも揺れがあるため、基準の曖昧さと採点モデルの誤りを分けて考えます。自動採点を全ての承認へ使うのではなく、候補の絞り込みなど許容できる用途へ限定する方法もあります。

採点基準自体の回帰を確認する

採点プロンプトや採点モデルを変えたときは、生成側を変えなくても点数が動く可能性があります。既知の評価例を使い、人が合意した重大な誤りを引き続き検出できるかを確認します。採点者が新しくなった後の数字を、そのまま以前の数字と比較して生成品質の改善と説明しないようにします。生成側と採点側の版を分けて記録してください。

理由文が具体的でも、引用した箇所が実際には判定を支えていない場合があります。判定と理由の対応を標本で確認し、どの種類の入力で不一致が起こるかを調べます。自動採点を候補の整理に使う場合と、影響の大きい操作の承認に使う場合では、必要な証拠は異なります。便利な採点機能を、用途を越えた保証へ拡大しないことが大切です。

具体例で考える

説明用に、短く正しい回答Aと、長いが条件を一つ間違えた回答Bを比較します。

確認1：内容の必須条件を先に採点。
確認2：A/Bの順を交換。
確認3：人の判定と、重大な見逃しを照合。

長い説明を好む判定が出るなら、総合的な印象を聞くのではなく、条件の一致を先に評価します。採点プロンプトを直した後も、別の確認例で作用を確かめます。

確認課題と合格の目安

人が合意した五つの例で自動採点を試す計画を作り、順序交換と不一致の扱いを含めてください。

• 機械的に判定できる項目を分けている。
• 順序や長さの影響を確認している。
• 重要な不一致を人の確認へ回せる。