Go back

モデル評価の落とし穴

モデル同士の能力を定量的に比較するために, ベンチマークによる評価が広く行われています. しかし, 評価スコアはプロンプトや推論設定など様々な要因によって変化するものであり, モデル評価には様々な落とし穴があります. 提案手法のベースラインとして他のモデルを評価する場合, 各モデルの能力を十分に引き出さないまま比較すると, 不公平な評価になってしまい, 不適切な結論を導いてしまうことがあります. また, 公式に報告された性能と独自評価の間に乖離が生まれることもあります.

本稿では, 評価スコアに影響する様々な要因について整理し, 評価の落とし穴に落ちないための注意点をまとめます.

LLM編

プロンプト

プロンプトの変化はスコアに影響することがあります. かつては few-shot プロンプトや CoTプロンプトが広く使われており, shot 数や例の選び方でスコアが変動することが知られていました. 最近の評価は zero-shot プロンプトが主流ですが, それでも軽微な言い換えや, 出力フォーマットの指示の仕方の違いによって, スコアに無視できない差が生じます.

他のモデルとの比較を行う場合は, 全モデルで同一のプロンプトを使うのが基本ですが, そのプロンプトが特定のモデルに有利/不利に働いていないかにも注意が必要です.

max_new_tokens

生成トークン数の上限である max_new_tokens が小さいと, 解答が途中で打ち切られて不正解と判定されてしまうことがあります. 特に推論モデルは最終解答の前に長い思考トークンを生成するため, この上限が小さいと, 思考の途中で生成が打ち切られ, 本来解ける問題を落とすことになります. モデルを評価する際は, 十分に大きな max_new_tokens を設定することが重要です.

さらに, 各サンプルの生成が終了した理由を記録し, 上限到達による打ち切りとなったサンプルの割合を確認することで, 推論の途中で生成が切れていないかをチェックできます. ただし, 同じ文の繰り返しばかりの場合は, max_new_tokens を増やしても正解には至らないため, 問題ありません.

推論パラメータ

LLM の文生成では, 推論パラメータによって生成される文が変わります. 推論パラメータとしては, temperature, top_p, repetition penalty などがあります. これらは生成文を変えるため, 当然スコアにも影響します. 基本的には, 公式のモデルカード等に記載された推奨設定を採用するのが安全です.

例えば Qwen3.5-4B のモデルカード には, 推奨される temperature や top_p などの推論設定が明記されています. モデルによっては temperature=0 (greedy decoding) が非推奨とされている場合もあり, 「決定的にしたいから greedy」という選択がスコアを下げてしまい, 本来のモデル性能を引き出せないことがあります.

なお, temperature が 0 でない場合は run ごとに生成結果が変わるため, 複数回実行して mean と std を報告するべきです.

浮動小数点の精度

LLM は, 行列積や活性化関数などの計算を繰り返すことで次トークン予測分布を計算し, トークンを生成します. 浮動小数点の精度を変えると, 計算誤差により分布が変わり, 生成されるトークン列が変わる場合があります. モデルの性能を引き出すためには, 推奨の精度で推論するのが望ましいです.

推論エンジン

HF Transformers, vLLM, SGLang など, どの推論エンジンを使うかによってもスコアが変わることがあります. エンジンごとに実装が異なる場合があるため, 同じモデル・同じ設定でも完全に同一の出力になるとは限りません. さらに, エンジンのバージョンによっても挙動が変わる場合があります.

APIプロバイダ

オープンウェイトモデルをOpenRouterなどのサービスを用いて使う場合, プロバイダによってスコアが変わることがあります. プロバイダ ごとにモデルの serving 方法が異なるため, プロバイダ によって異なるレスポンスが返ってくる場合があります. さらに, 同じ プロバイダ でも時期によって内部実装が変わる可能性があります. OpenRouterでは, プロバイダを指定する機能があるため, 評価時には プロバイダ を固定するのが望ましいです.

採点

モデルの回答の採点にも注意が必要です.

正規表現等を用いたルールベースの採点では, 軽微な言い回しの違いのせいでマッチせず, 正しい回答を不正解としてしまう場合があります.

ルールベースの採点の問題に対処するために, LLM-as-a-Judge では, LLM にモデルの出力と参照回答を与えて, より柔軟な採点を行うことができます. 一方で LLM-as-a-Judge には,

といった問題があります. 採点にはなるべく強いモデルを用い, 可能であれば人手採点との一致率を確認するのが望ましいです. また, judge に用いたモデル名も報告するべきです.

VLM編

VLMの評価では, テキストに加えて画像入力に起因する落とし穴があります.

画像フォーマット

SGLang や OpenAI API などを用いて VLM に画像を渡す際は, 画像を一旦 base64 などにエンコードして渡します. このとき, 途中で JPEG への再エンコード (非可逆圧縮) やリサイズが入ると, ピクセル値が変化し, モデルへの入力値が変わります. 文字の細かい document 画像などでは, 圧縮による劣化がスコアに影響することがあります. 対策としては, 評価パイプラインのどこで画像がどのように変換されているかを把握した上で, 可逆なPNG形式で渡すなどして, 意図しない劣化を避けることができます.

画像1枚あたりのソフトトークン数

VLM は, 画像を視覚エンコーダでソフトトークンに変換して LLM に入力しますが, 多くのモデルで, 画像1枚あたりのソフトトークン数を調整するパラメータがあります. 例えば Gemma 4 12B では, 画像1枚あたりの最大ソフトトークン数を変更できます.

一般に, PDF 画像のような細かい情報を読み取る必要があるタスクでは, 画像1枚あたりのトークン数を増やす方が性能が上がります. 逆にトークン数が小さいと, 画像の解像度が実質的に落ち, 読み取れたはずの情報が失われます. デフォルト設定のまま評価してスコアが低かった場合, それはモデルの能力ではなく設定の問題かもしれません.

エージェント編

LLMエージェントの評価では, モデル以外の構成要素が多いぶん, スコアに影響する要因もさらに増えます.

ハーネス

LLMエージェントのコンテキスト管理やツール定義などを定めるハーネスは, 実装に大きな自由度があります. 現在, OpenCodeやTerminus, mini-swe-agent など様々なハーネスが存在し, システムプロンプト, 利用できるツール, コンテキスト圧縮方法, コードのエージェントへの見せ方などの実装方法がそれぞれ異なります. 例えば Terminal-Bench の評価では, 同じモデルでもハーネスが異なると性能が大幅に異なることが示されています. エージェントベンチマークにおいて報告されているスコアが, モデルとハーネスの組み合わせによる性能であることを理解しておくことが重要です.

実行環境

エージェントの実行環境にも自由度があります. エージェントにどの程度の計算資源を与えるか, 制限時間をどう設定するか, ネットワークアクセスを許可するかなどの設定によって, スコアは変わります. 例えば, 制限時間が短すぎると, タスクに取り組んでいる途中でエージェントが打ち切られ, 本来解けたはずのタスクを落としてしまいます. その結果, エージェントの性能を不当に低く見積もってしまうことになります. また, 検索ベンチマークでは, エージェントが外部の検索エンジンを使って情報を取得することがありますが, 検索結果は時間とともに変化するため, 同じタスクでも実行時期によってエージェントが得られる情報が変わります.

まとめ

本稿では, 評価スコアに影響する様々な要因を整理しました. 推論設定から採点方法, 実行環境まで, 落とし穴は評価パイプラインのあらゆる場所に潜んでいます.

全体を通して重要なのは, 実際のデータを見ること (looking at data) です. 評価スコアを眺めて終わりにするのではなく, モデルの生成結果と採点結果を実際に確認しましょう. 解答が途中で打ち切られていないか, 正しい回答が不正解扱いされていないか, エージェントが想定外の行動をしていないか. 本稿で挙げた落とし穴の多くは, データを見ることで発見できます.

参考文献

Share this post on:
Share this post via WhatsAppShare this post on FacebookShare this post on XShare this post via TelegramShare this post on PinterestShare this post via email
Next Post
IHPCSS2026パース参加記