公開ベンチマーク一位でも、本番品質は決まらない

HELMは、精度だけでなく、較正、頑健性、公平性、バイアス、毒性、効率を含む七つの指標を、可能な範囲で十六の中核シナリオへ適用しました。さらに三十の言語モデルを四十二シナリオで標準化して比較し、評価されていない領域も明示しました。[1]

本番では、正答率が同じでも価値が同じとは限りません。顧客対応なら有害表現と保留、抽出なら根拠一致、開発支援ならテスト通過と保守性が重要です。候補モデルごとに同じ業務標本を使い、品質、失敗影響、遅延、費用、再現性を同じ表で見なければ、改善した指標の裏で悪化した条件を見落とします。

評価表を作る前に、業務判断で優先する指標と、超えてはいけないガードレールを分けます。精度が上がっても重大誤答や有害出力が悪化した候補を、総合点で救済しないためです。候補間の差が利用者や失敗影響の区分で反転するなら、単一順位ではなく用途別の採用判断へ分けることがHELMの多面評価を実務へ移す条件です。[1]

ZhengらはMT-BenchとChatbot Arenaを用い、GPT-4による採点が人の選好と80%超で一致し、人同士の一致と同程度だったと報告しました。公開された評価資源には約3,000の専門家投票と約30,000の人間選好付き会話が含まれます。[2] 大量の候補応答を一定基準で比較する手段として、LLM採点は有力です。

しかし同じ研究は、回答の順序、冗長さ、自分と同系統の回答を好む傾向、推論能力の限界を分析しています。[2] したがって採点モデルの点数を正解ラベルにせず、評価基準ごとの人手標本で一致率と不一致の型を確認します。高影響の誤答、モデル間の差が小さい案件、採点理由が根拠と合わない案件は、人へ戻す層として残します。

LLM採点器は、採用前に人の評価との不一致表を作ります。回答順を入れ替える、長さをそろえる、モデル名を隠すという対照で点が動く場合、品質差ではなく採点偏りが代替説明になります。重大誤答を見逃す不一致が残る基準は自動採点へ渡さず、人手標本の再確認頻度と採点器の停止条件を所有者が決めます。[2]

Sclarらは、意味を保ったまま例示の区切りや書式を変え、複数のオープンモデルを少数例設定で評価しました。LLaMA-2-13Bでは、書式の違いだけで最大76正解率ポイントの差が生じ、モデルを大きくしたり例示数を増やしたりしても感度が残りました。[3]

一つのテンプレートで得た点数は、そのテンプレートに対する局所的な観測です。実務評価では、語順、区切り、例示、出力形式、長さが異なる妥当なプロンプト群を用意し、平均だけでなく下位成績と分散を見ます。プロンプトを変更したらモデル更新と同様に評価版を上げ、以前の合格結果を自動継承しない運用が必要です。

プロンプト耐性は、妥当な表現群の平均だけでなく、最も悪い結果と順位の入れ替わりで見ます。書式を変えたとき特定業務だけが落ちるなら、モデル全体の劣化ではなくテンプレート依存が疑われます。利用者が自由文を入力する用途へ移す場合は、固定テンプレートでの合格を引き継がず、実際の表現幅で再評価します。[3]

多面的評価、LLM採点の偏り、プロンプト書式感度は、モデル順位が評価条件から独立した属性ではないことを示します。[1] [2] [3] そこで『どのモデルが最良か』ではなく、『どの用途で、どの条件なら、どの候補を採るか』という結論単位で証拠一式を凍結し、適用期限も設定します。

結論票には、比較した候補、利用者と業務、入力標本、プロンプト群、採点基準、採点者、失敗時の影響、未評価領域を結びます。結論文に含まれない用途へ順位を広げず、候補差が小さい区分や採点不一致が多い区分は、優劣ではなく事前に定めた同等性の幅を十分な精度で満たせば同等、それ以外は判断保留として残します。標本にない利用者群は適用外と表示します。

感度欄では、採点者、回答順、回答長、プロンプト書式の一要素だけを変え、採否が反転するかを記録します。反転した場合は、候補の品質差と断定せず、どの条件を業務の代表とみなすかを別の判断として裁定します。都合のよい条件だけを最終結論へ残さないよう、全条件を保存し、複数条件の組合せと代表条件の選定理由も確認します。

人とLLM、または人同士の採点が違う案件は、平均して消さず不一致票へ送ります。まず回答を匿名化し、各採点者が根拠箇所と適用した基準を独立に示します。正解知識の違い、基準解釈、好み、見落とし、問題自体の曖昧さを別の原因コードへ分類します。不一致が解けなければ未確定のまま残します。

裁定者は、採点者の肩書やモデル名ではなく、事前に定めた基準と根拠へ戻って判定します。問題が曖昧なら候補の失点として確定せず、評価標本を修正して旧版との比較を残します。好みの差は品質差とせず、業務上どちらを要求するかを評価契約へ追記します。裁定不能なら採否の対象範囲を狭めます。

不一致票が閉じた後も、元の採点、裁定結果、原因コードを保存します。同じ原因が繰り返される場合は、採点器の重みを調整する前に、基準文、対比例、標本の曖昧さを見直します。裁定済み案件を校正標本へ加えるときは、特定候補だけに有利な例へ偏っていないかを確認し、採用理由も一行で残します。

• CLAIM：用途・条件・候補を含む採否結論を一文で固定する
• FREEZE：標本・プロンプト・採点基準・採点者を結論へ結ぶ
• DISAGREE：根拠と原因コードを付け、不一致を独立に裁定する
• REVERSE：採否を反転させる評価条件と未評価領域を記録する

最初に、利用者が本当に行う仕事から代表標本を作ります。通常例だけでなく、曖昧、情報不足、矛盾、拒否すべき依頼、重大な誤答を含めます。正解が一つでない生成課題では、具体的な評価基準と良否の対比例を置き、採点者が何を見たかを記録できるようにします。

次に、公開前の固定評価、実トラフィックを使う影運用、限定公開、運用後サンプリングを一つの流れにします。入力分布、モデル版、システムプロンプト、検索索引、採点器が変わるたびに差分評価を行い、重大失敗が増えたら戻せる条件を決めます。ベンチマークは選定表ではなく、変更を検知する観測装置として使うと価値が残ります。

評価契約には、変更を承認する責任者、失敗標本を保守する責任者、ロールバックを実行する責任者を明記します。モデル、プロンプト、索引、採点器のどれかが変わり、重大失敗のガードレールを破ったら、平均品質の改善にかかわらず直前の組み合わせへ戻します。復旧判定には本番で発生した失敗を固定評価へ加えます。

• 対象：代表業務に加え、曖昧、情報不足、矛盾、拒否、重大誤答を含める
• 採点：人手とLLMの不一致、位置・冗長性への感度、根拠との一致を記録する
• 耐性：意味を保つプロンプト変種で、平均、下位成績、順位変動を比較する
• 変更：モデル、プロンプト、索引、採点器ごとに版を持ち、別々に戻せるようにする