モデルランキングは信頼できるか：データ汚染と検証可能な評価

ランキングは一度の試験を正確に記録していても、仕事に適したモデルを教えてくれるとは限りません。スコアは問題、モデルの版、指示、ツール、推論予算、採点方法に左右されます。条件を外して小数点以下の順位だけを見ると、根拠以上の結論を読み取ってしまいます。

本稿は 2026-11-14 に確認した文献を分析し、評価方法を提案します。Folkbench は今回、モデルの呼び出しやベンチマークの再実行を行っていません。数値例は方法の説明であり、実測値ではありません。何を測り、どう出題・採点し、どこまで結論づけられるかを検証可能にすることが目的です。

問題集より先に能力を定義する

知能は、一問や平均点で説明するには広すぎます。専門知識、未知の規則の発見、実行可能なコード、長期計画では必要な課題が異なります。出力形式を指定すれば指示への追従も測り、画像問題なら知覚能力も加わります。

445 件のベンチマークを調べた Measuring what Matters は、観測したスコアが意図した能力の解釈を支えるかという構成概念妥当性を扱います。BetterBench は品質を点検する枠組みを示します。有力な学会や機関の名前は文献選びの参考になりますが、課題や採点器の確認に代わるものではありません。

例えば「外部検索なしで、与えた資料から複数段階の問題を解けるか」と定義すれば検証しやすくなります。知識不足、証拠の見落とし、推論ミスも、単に賢いかどうかを問うより区別できます。

汚染は原題の暗記だけではない

直接的な汚染は、評価用の問題と答えが学習データに入ることです。類題、解説、公開された評価記録も役立つ可能性があります。公開ランキングを見ながら手法を何度も調整すると、原題で直接学習しなくても、その試験への過適合が生じ得ます。

したがって、古い問題の高得点だけで暗記を証明できず、新しい問題の低得点だけで汚染を証明することもできません。難易度、形式、分野が異なる可能性があるからです。条件をできるだけ揃え、観測できない学習データの範囲を明示します。非公開モデルの全学習データを確認できなければ、状態は不明であり、汚染なしと認定してはいけません。

LiveBench の改訂版 は継続更新される課題と検証可能な正解を使い、題名も Contamination-Limited です。LiveCodeBench は公開日付きの新しい競技プログラミング問題を収集します。特定のリスクを減らせますが、公開後の問題が将来の学習や調整に使われる可能性は残ります。

更新型の問題集では時系列比較も難しくなります。月ごとに問題が変われば、スコアの変化にはモデルと試験の両方の変化が含まれます。データの版を保存して共通問題で比較するか、固定の参照問題と新問を分けて報告します。固定問題が次第に知られていくリスクも残ります。

同じ条件を評価手順として固定する

同じ名称でも、モデルのスナップショット、接続先、推論設定は異なり得ます。実際の API ID、入手可能な版情報、日時、システム指示、サンプリング設定、出力上限、ツール、再試行条件を記録します。非公開のルーティングや内部計算予算を推測で埋めてはいけません。

共通手順でのモデル比較と、明示した予算内で各システムを最適化した比較は、別々に示せます。前者は差の原因を考えやすく、後者は導入判断に役立ちます。同じ token 上限でも、トークナイザーや内部機構が異なるため、計算量が等しいとは限りません。

HELM は場面と条件を揃え、正確性、較正、頑健性、効率などを見ます。この考え方に沿って、品質だけでなく費用、遅延、失敗も報告します。費用には失敗した試行とツール呼び出しも含め、最後の成功だけを数えないようにします。

採点器も誤差の原因になる

正解があるなら検証可能な採点を優先しますが、その正解自体も点検します。コードのテストは要件を見落としたり、特定の実装を要求したりします。文字列の完全一致は意味の正しい回答を落とす場合があります。採点器の版、答えの抽出、例外処理を固定してください。

自由回答には別の判断が必要です。Judging LLM-as-a-Judge は位置、長さ、自分の回答を好む傾向などの偏りを検討しています。匿名化、提示順の入れ替え、明確な採点基準、人による争点の再確認が役立ちます。人の好みとの一致率は事実の正答率ではありません。

誤答、形式エラー、回答拒否、タイムアウト、サービス障害を分け、主スコアへの算入方法を実行前に定めます。返ってきた回答だけで正答率を計算し、多数のタイムアウトを隠すと、サービス全体の信頼性を過大評価します。

小さな差には対応のある分析を使う

共通の 200 問で A が 160 問、B が 156 問正解したと仮定します。これは説明用の例です。差は 2 パーセントポイントですが、合計だけでは安定した差か分かりません。どの問題をそれぞれ解いたか、問題間に依存があるかも必要です。

Adding Error Bars to Evals は対応のある比較、関連した問題、実験計画を扱います。共通問題では一問ごとの差を分析します。同じテンプレートの変種はグループ化し、似た問題を独立した証拠として水増ししません。生成の反復でサンプリング変動は推定できますが、分野の偏りは補えません。

差の 95% 信頼区間と計算方法、抽出単位を示します。区間がゼロを含むなら優位性を立証したとは言えませんが、同等性を立証したことにもなりません。多数のモデルや項目を比較する場合、有意な結果を繰り返し探す影響も扱う必要があります。

検証可能な結果カード

これは編集・実験記録の提案であり、既存ランキングへの認証ではありません。機密性のある元データは管理された環境に保存し、結論を検証できる範囲の匿名化した証拠と手順を公開します。

ランキングは候補を絞るために使う

信頼できるベンチマークは候補と弱点を見つけます。最後の判断は実際の仕事に戻ります。許容できない失敗、費用と遅延、更新後の変化を確認してください。

Folkbench は総合点より先に能力別の結果を示すことを勧めます。重みを使うなら公開し、合理的に変更した場合の順位も確認します。同順位や現状では区別できないという記述は、根拠のない細かな順位より有用です。

具体例は[数学的推論の頑健性](/ja/blog/mathematical-reasoning-robustness/)と[長いコンテキストの実効的な理解](/ja/blog/long-context-effective-understanding/)を参照してください。