分析:公開ベンチマークはもはや実運用品質を予測しない――本当に機能する評価セットの作り方
リーダーボードのスコアと、実際にリリースされたシステムの信頼性との乖離は、この2年間広がり続けている。出荷可否を本当に判断できる、小規模で地味な独自評価セットを構築するための実践的な手法を紹介する。
ひとことで言うと
ベンチマークで高スコアを記録したモデルが、なぜ実運用では失敗するのか。そして開発チームはモデルをどう評価すべきか。
公開ベンチマークが測定するのは、狭く固定的で、広く公開されたタスクにすぎず、しかも学習データによる汚染や、そこを狙い撃ちした最適化が年々進んでいる。実運用の品質を左右するのは、自社のプロンプトであり、扱う文書であり、ツールのスキーマであり、許容できる失敗の範囲であって、そのいずれもリーダーボードは測っていない。現実的な答えは、実際のケースを50から300件集め、期待される挙動を記録した独自の評価セットを用意することだ。これをモデルやプロンプトを変更するたびに実行し、可能な限り厳密な照合で採点し、それが難しい場合は評価基準を明確化したモデル審査によって採点する。
要点
- リーダーボードが答えるのは、「一般的にどのモデルが優れているか」という問いだ。導入の意思決定に必要なのは、「自社のデータを使い、自社の制約下で、自社のタスクにより適しているのはどのモデルか」という問いである。両者は別の問いであり、第三者が答えられるのは前者だけだ。
- 自社のトラフィックから厳選した50件のケースは、変更を安全に出荷できるかどうかを見極める上で、どんな公開ベンチマークよりも優れた指標となる。
- 評価セットはトピックではなく、失敗した際の影響度で分けるべきだ。誤答のコストが高いケースには、専用のゲートを設けるべきである。
- まず決定論的なチェックを行い、モデルによる判定はその後にする。コードで検証できることを、判定役に委ねてはならない。
- 評価セットは生きた資産である。本番環境で起きたインシデントは、必ず新たなケースとして追加されるべきだ。
言語モデルを導入した大半のチームは、いまやある種の失望を経験している。あらゆるグラフで従来より優れた数値を示す新モデルが登場し、置き換えてみる。すると1週間もしないうちにサポートへの問い合わせが増え、社内ユーザーから「要約の質が落ちた」と報告があり、誰かがひっそりと元に戻す。
不正があったわけではない。ベンチマークのスコアは本物で、そのモデルも総合的にはおそらく高性能だ。間違っていたのは、そこから導いた結論である。リーダーボードが答えるのは、実際の導入現場では決して問われない問いだ。
ベンチマークが実際に測っているもの
公開ベンチマークには、科学には有用だが意思決定には不向きな共通の性質がある。
第一に、静的である。内容が変わるベンチマークでは時系列比較ができないため、設問は固定される。その結果、同じ問題が何千もの論文やブログ記事、リポジトリで解かれ、オープンウェブ上に公開され、ひいては学習コーパスに入り込む。これはコンタミネーション（汚染）だが、不正行為を非難しているのではない。テストを公開し、その後インターネット上のデータで学習すれば、当然の帰結として起きる。そのため、スコアは実際の能力を上回るペースで上昇していく。
第二に、範囲が狭い。多肢選択式の知識問題、競技数学、単発のコーディング問題、短形式の推論は、いずれも正当な評価手段だ。しかし、それらと「顧客が句読点もろくに付けずに送ってくるサポートメールに、存在しない返金規定をでっち上げず対応できること」との相関は弱い。そもそも、両者に強い相関があるなどと主張した者はいない。
第三に、最適化の対象になる。ある数値が業界における進歩の代名詞になれば、あらゆる学習・評価ループで目標として組み込まれる。あとはグッドハートの法則が働く。不正をする者がいなくても、全員がその数値を重視するだけで十分だ。
そして、本番環境の品質を左右する制約が捨象されている。レイテンシーの上限、コンテキスト長、ツールのスキーマ、検索品質、プロンプト、出力形式、そして特定の種類の誤りが自社にとってどれほど深刻か、といった要素である。
人間の選好に基づくリーダーボードは、こうした問題の一部を解消する一方、別の歪みを持ち込む。集計対象となる人々が取り組む課題は、あなたの課題とは異なる。また、並べて一見したときに良く映る性質、すなわち流暢な構成、自信に満ちた語り口、十分な長さが高く評価される。製品に必要なのが、簡潔かつ字義どおりで、不確かなときには回答を拒否する振る舞いなら、選好ランキングはまさに逆方向を指し示しかねない。
代替策は想像されるほど大がかりではない
チームが独自の評価セットを構築しないのは、それが途方もなく大がかりだと思い込んでいるからだ。実際は違う。有用な評価セットは通常、50～300件のケースで構成され、初版なら1日で作成できる。
ステップ1：実際のトラフィックからケースを採取する。 作り物の例ではない。ログから、実際のユーザーメッセージ、実際の文書、実際のツール呼び出し手順を抽出する。考案されたケースには、考案者自身の盲点がそのまま反映される。
ステップ2：話題ではなく、結果の重大さで層別化する。 主題別に分類したくなるが、有用な軸は、誤答によってどれほどの損害が生じるかである。
- 気づかれにくい誤答 — もっともらしく、自信に満ちているが、間違っている。最も損失の大きい分類であり、重点的にサンプリングする価値がある。
- 本来は回答を拒否すべきだったケース — 拒否または上位対応への切り替えが正しかったにもかかわらず、モデルが回答した。
- 形式の破損 — 内容自体は正しいが、後段のパーサーを壊す形式になっている。
- 表面的な問題 — 語調、長さ、順序。実害はあるが、コストは低い。
表面的なケースでは改善しても、気づかれにくい誤答のケースで悪化するモデルは、平均スコアこそ高くなるが、製品としては劣化している。これを明らかにできるのは、層別化された評価セットだけだ。
ステップ3：期待する文字列ではなく、期待する振る舞いを記録する。 多くのケースで正解ラベルとなるのは、一連のアサーションである。文書3を必ず引用する、価格には触れない、指定されたフィールドを含む有効なJSONを返す、回答を拒否する、といった条件だ。アサーションは言い換えられても有効だが、模範文字列はそうではない。
ステップ4：まず決定論的なチェックを実行する。 スキーマの妥当性、必須フィールド、禁止文字列、数値の許容誤差、引用の有無、レイテンシー、トークンコストを確認する。この段階は安価で厳密なうえ、実際のリグレッションを驚くほど多く検出できる。assertで判定できるものを、審査モデルに回してはならない。
ステップ5：残った項目だけをモデル審査にかける。 情報源への忠実性、語調、完全性、説明が実際に問いに応えているかどうか、といった項目である。審査モデルには、具体的な基準を明記したルーブリック、存在する場合は模範回答、2つの出力を比較する際には無作為化された提示順が必要だ。サンプルについて審査モデルと人間の判定一致率を報告する。一致率が低ければ、問題は審査モデルではなくルーブリックにある。
自己欺瞞に陥らず結果を読む
評価データに基づく誤った意思決定の大半は、2つの失敗パターンで説明できる。
第一は、わずかな差を有意な差として扱うことだ。100件のケースで82％から85％に変化しても、十分にノイズの範囲内である。信頼区間を報告するか、評価セットを複数回実行して分散を確認するか、勝者を決めたい衝動を抑えるべきだ。サンプリング温度だけでも、小規模な評価セットの結果は数ポイント変動し得る。
第二は、重視すべきものを平均化で消してしまうことだ。総合合格率では、失敗がどのように分布しているかが見えない。評価実行の有用な出力は単一の数値ではなく、各層の合格率と、具体的にどのケースの判定が変わったかを示す差分表である。合格から不合格に転じたケースこそがシグナルのすべてだ。必ず目を通すべきである。
評価セットを継続的にどこから得るか
初版はログから作る。長期的に使える版は、インシデントから生まれる。人間による対応が必要になった本番環境の失敗はすべて、期待する振る舞いを記録したケースを評価セットに追加して締めくくるべきだ。これにより、サポートの負荷がリグレッションの網羅性へと転換され、評価セットは一般的な品質の代替指標ではなく、自社製品に固有のものとなる。
同じ規律は検索ベースのシステムにも当てはまるが、そこではさらに一層の評価が必要になる。検索と生成を分けて評価するのだ。正しい文書がそもそも検索されなかったために回答が間違っているなら、モデルをいくら入れ替えても解決しない。にもかかわらず、エンドツーエンドのスコアはモデルに問題があると示し続ける。
それでもベンチマークが役立つ場面
以上の議論は、公開評価に価値がないという意味ではない。リーダーボードを全面的に切り捨てる反射的な態度もまた、誤りである。
公開評価は、候補を絞り込む一次選考としては妥当だ。20のモデルから本格的に試す3つを選ぶ必要があるなら、公表スコアにコンテキスト長と価格を組み合わせれば、十分に根拠のある3つを選べる。また、分野全体の傾向線としても有用である。過去2年間におけるオープンウェイトモデルと最先端モデルの相対的な動きは実在するシグナルであり、ほかの方法で把握するのは難しい。さらに、実行結果を要求することで暗記に強い耐性を持つエージェント型やリポジトリ単位のベンチマークなど、少数ながら能力の変化を真に示すものもある。
原則は限定的で、明快に述べる価値がある。何をテストするかは公開ベンチマークで決め、何をリリースするかは独自の評価セットで決める。 この順序を逆にするチームは、アップグレードによってなぜ事態が悪化したのかをユーザーに説明するため、多くの時間を費やすことになる。
よくある質問
- 公開ベンチマークは無意味なのか。
- そうではない。どの三つのモデルを試す価値があるかを大まかに絞り込んだり、業界全体の進歩を長期的に追ったりする上では有用だ。ただし、自社のタスクでのテストの代わりとして使われた瞬間、その有用性は失われる。
- ベンチマーク汚染とは何か。
- テスト項目、あるいはそれに近い内容が、モデルの学習データに含まれてしまうことを指す。公開ベンチマークの大半はオープンなウェブ上にあるため、これは既定の状態で起こり得るものであり、未知のタスクには通用しない形でスコアを押し上げてしまう。
- 評価ケースはいくつあれば十分か。
- 50件あれば大きな性能劣化を検出するには十分で、半日あれば作成できる。数百件をシナリオ別に層化すれば、似通ったモデル同士の間にある、重要ではあるが小さな品質の差も検出できる。おおよそ千件を超えると、ラベルを維持するコストが得られる情報量を上回るのが通例だ。
- あるモデルに別のモデルの出力を採点させる方法は信頼できるのか。
- 採点基準が具体的で、判定役が参照回答を見た上で判断し、回答順序や文章の長さによる偏りが制御されていれば、相対比較の手段としては十分信頼できる。しかし絶対的な品質スコアとしては信頼できず、単体テストで検証できる内容を判定役に採点させるべきではない。
- 評価はどのくらいの頻度で実行すべきか。
- プロンプトを変更するたび、モデルのバージョンを変更するたび、ツールのスキーマを変更するたびに実行すべきだ。加えて、モデルではなくデータ側で生じるドリフトを捉えるため、本番環境に対して定期的にも実行する必要がある。