VLMEvalKit を採用する前に確認したい評価パイプラインの実態
Open-source evaluation toolkit of large multi-modality models (LMMs), support 220+ LMMs, 80+ benchmarks
ひと目でわかる
- これは何？
- 220 以上の LMM と 80 以上のベンチマークを 1 コマンドで回すことを狙った評価ツールキット。生成ベース評価と LLM による回答抽出という設計を、実際に導入する立場から読み解く。
- 誰に向いている？
- 既に自前の LMM 推論コードを持ち、複数ベンチマークのデータ準備と回答抽出の実装コストに困っているチームは、vlmeval を評価ハーネスとして試す価値がある。逆に、モデル側の前処理を細かく制御したい場合や、評価結果の再現性を完全に固定したい場合は、生成ベース評価と LLM 抽出という設計が合わないことがある。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ベンチマークごとのデータ準備をなくすという発想
LMM の評価は、モデルを動かすことより周辺作業のほうが重い。ベンチマークごとに画像や動画の配置規則が違い、回答形式も違い、採点スクリプトも別々に配布されている。VLMEvalKit が解こうとしているのはこの部分で、README は「one-command evaluation of LVLMs on various benchmarks, without the heavy workload of data preparation under multiple repositories」と説明している。対象は LMM そのものを開発する研究者に限らない。API 経由で GPT-4V や Claude、Gemini を呼び、自社ユースケースに合うモデルを選定したい応用側のチームも想定読者に入る。リポジトリの topics に chatgpt、claude、gemini、gpt-4v が並んでいるのはそのためで、ローカルの PyTorch モデルだけを対象にしたツールではない。Python パッケージ名は vlmeval で、ライセンスは Apache-2.0。評価結果は OpenVLM Leaderboard として公開されており、Hugging Face 上に Spaces と評価レコードのデータセットが用意されている。
生成ベース評価と LLM 抽出という二段構え
VLMEvalKit はすべての LMM に対して生成ベースの評価を採用し、exact matching と LLM ベースの回答抽出の両方で結果を出す。ここが設計の中心で、モデルに選択肢の確率を出させるのではなく、まず文章を生成させ、そこから回答を切り出す。README の recent changes には can_infer_option と can_infer_text の改良が触れられており、多肢選択ベンチマークでは徐々に LLM による選択肢抽出へ処理が回されるようになり、経験的にわずかな性能改善につながったとされている。つまり採点の一部を外部の LLM に委ねる構造である。利点は、回答形式が崩れたモデルでも救済できること。欠点は、抽出器の挙動が変われば同じ生成結果でもスコアが動きうることだ。ベンチマーク間の比較を長期にわたって追う場合、この層のバージョンを記録しておかないと、モデルの改善と抽出器の変更を切り分けられなくなる。
thinking モードと長文応答をどう扱うか
2025-09-12 付の変更は、実運用で問題になりやすい 2 点に対応している。ひとつは thinking モードを持つモデルの扱い。環境変数 SPLIT_THINK=True を有効にすると、既定では <think>...</think> タグの中身を解析し、出力の thinking キーに格納する。より細かい制御が必要な場合はモデルごとに split_think 関数を用意でき、README は InternVL の実装を例として挙げている。ドキュメントの表現を借りれば、thinking モードのモデルでは精度のために強く推奨される。もうひとつは 16k や 32k を超える長い応答で、予測ファイルを TSV 形式で保存できるようになった。理由も明記されていて、.xlsx のセルは 32,767 文字までという制限があるため、長文を出すモデルではデータが切り詰められる恐れがある。環境変数 PRED_FORMAT=tsv で切り替える。どちらも既定の動作ではなく、環境変数を明示的に設定して初めて有効になる点に注意したい。
config.py への登録と分散推論のスイッチ
モデルを追加するときの入口は vlmeval/config.py で、ここにカスタムモデル設定を書く。README によれば、大規模モデルや thinking モデルの評価を速めるため、LMDeploy を使ったマルチノード分散推論に対応しており、InternVL 系、QwenVL 系、LLaMa4 が対象になる。VLLM 経由では QwenVL 系と LLaMa4 が対象とされている。有効化は config.py のカスタムモデル設定に use_lmdeploy または use_vllm フラグを追加する形で、設定ファイルを書き換える運用になる。動画ベンチマークのダウンロード経路を変えたい場合は環境変数 VLMEVALKIT_USE_MODELSCOPE を設定すると modelscope から取得できる。設定の流儀が環境変数と config.py の 2 系統に分かれているので、チームで使うならどちらをどこに書くかを最初に決めておかないと、評価条件が人によってずれる。
向かないケース: 採点を自前で固定したいとき
このツールキットが常に正解とは限らない。採点の一部を LLM による回答抽出に委ねる設計は、抽出器のモデルやプロンプトが変わればスコアが動くことを意味する。規制産業や社内の品質基準のように、同じ入力から同じ数値が出ることを厳密に求められる場面では、LLM 抽出を挟む経路そのものが監査上の説明コストになる。また README にあるとおり、評価は生成ベースで統一されているため、選択肢の対数確率を使った評価や、モデル内部の隠れ状態を分析する用途には向かない。加えて、対応モデルとベンチマークの一覧は頻繁に更新されており、新しく追加された項目については実装の成熟度が均一とは限らない。リポジトリの更新履歴を見る限り、多くの対応はコントリビュータ単位で追加されている。自分の使いたいベンチマークがどの程度検証されているかは、採用前に個別に確認する必要がある。
LM Evaluation Harness との設計の違い
比較対象として分かりやすいのは EleutherAI の lm-evaluation-harness で、あちらは言語モデルを中心に据え、タスク定義とスコアリングの形式を揃えることで再現性を重視する。採点はタスクごとに定義された指標で機械的に行われることが多く、評価条件を YAML などの設定に固定して配布する文化がある。VLMEvalKit は逆で、マルチモーダルなベンチマークを大量に取り込み、モデル側の出力形式の揺れを LLM 抽出で吸収する方向に振っている。多数のモデルを同じ土俵で並べ、リーダーボードとして公開することを優先した設計だと言える。どちらが優れているという話ではなく、固定した採点手順が欲しいなら lm-evaluation-harness、画像や動画を含む幅広いベンチマークを素早く横断したいなら VLMEvalKit という住み分けになる。
ライセンスと更新コストの見積もり
ライセンスは Apache-2.0 で、特許条項を含む寛容なライセンスとして知られるが、同梱されるベンチマークデータや評価対象モデルの重みには別の条件が付くことがある。ライセンス表示はリポジトリのコードに対するもので、データセットやモデル配布元の条件は各自で確認する必要がある。ここは法的助言ではないので、社内規定に照らした判断は法務に委ねてほしい。更新コストの面では、既定ブランチ main への push が継続しており、2025-06-21 の v0.3rc1 が最新のタグ付きリリース、その前が 2025-03-24 の v0.2、2024-06-29 の v0.2rc1 という間隔である。タグ付きリリースは年単位に近い間隔で、その間にも対応モデルとベンチマークが追加され続けている。バージョンを固定して運用するか、main を追い続けるかを最初に決めておかないと、評価結果の比較が成立しなくなる。
編集部の結論
既に自前の LMM 推論コードを持ち、複数ベンチマークのデータ準備と回答抽出の実装コストに困っているチームは、vlmeval を評価ハーネスとして試す価値がある。逆に、モデル側の前処理を細かく制御したい場合や、評価結果の再現性を完全に固定したい場合は、生成ベース評価と LLM 抽出という設計が合わないことがある。導入前に確認すべきは 3 点で、第一に vlmeval/config.py に自分のモデルを登録できるか、第二に thinking モードを使うモデルなら SPLIT_THINK=True と split_think 関数の実装が必要になるか、第三に長い応答を出すモデルなら PRED_FORMAT=tsv を設定しても .xlsx の 32,767 文字制限を回避できる構成になっているか。この 3 点を自分のモデルで確かめてから、ベンチマークの採点を既存パイプラインと突き合わせるのが現実的な順序になる。
コミュニティノート