OpenCompass を採用する前に確認すべき評価パイプラインの実像
OpenCompass is an LLM evaluation platform, supporting a wide range of models (Llama3, Mistral, InternLM2,GPT-4,LLaMa2, Qwen,GLM, Claude, etc) over 100+ datasets.
ひと目でわかる
- これは何？
- OpenCompass は 100 以上のデータセットと多数のモデルを組み合わせて LLM を評価する Python 製プラットフォームである。設定ファイルの構造変更と推論の並列化という 2 つの論点から、導入判断に必要な境界を整理する。
- 誰に向いている？
- 既存のベンチマーク群を自前のモデルにまとめて当てたいチーム、とくに推論を複数タスクで並列に流したい規模の評価を行うチームには向いている。逆に、単一データセットを少量のプロンプトで確認したいだけの場合や、評価設定を長期間固定して再現性だけを重視する運用には重い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OpenCompass が埋めるのは「比較の再現性」という穴
LLM の評価で厄介なのは、モデルそのものより周辺の条件である。プロンプトの整形、few-shot の例示、回答の抽出、採点の基準が少し違うだけでスコアは動く。OpenCompass が解こうとしているのはこの問題で、README では「コンパスのように複雑な評価の風景を案内する」と説明されている。対象は、Llama3、Mistral、InternLM2、GPT-4、LLaMa2、Qwen、GLM、Claude といったモデルを、100 以上のデータセット上で同じ手順に載せて測りたい利用者である。研究目的でベンチマークを回す人だけでなく、自社モデルのリリース前に社内の複数モデルを横並びにしたいチームも想定されている。評価そのものを新しく設計するツールではなく、既存のベンチマークを決まった手順で流すための土台だと考えると位置づけがはっきりする。
設定ファイルを分割し、タスクとして推論と評価を分ける
構造は比較的素直である。configs 以下にデータセット、モデル、summarizer の設定を置き、それらを組み合わせて評価タスクを記述する。0.4.0 でこの 3 種類の設定が opencompass パッケージ内へ集約されたため、以前の ./configs/datasets、./configs/models、./configs/summarizers を参照する書き方は更新が必要になる。実行の流れは推論と評価が分かれている。GenInferencer がモデルに回答を生成させ、その結果に対して評価器を走らせる。2026.03.20 の変更で、複数タスクの並列推論と evaluation watching が入り、完了した推論タスクを監視しながら後続の評価を起動できるようになったと release notes は述べている。該当実装として opencompass/tasks/openicl_infer_concurrent.py と opencompass/tasks/openicl_eval_watch.py が示されている。評価器側では CascadeEvaluator があり、複数の評価器を順に適用して独自の判定手順を組める。
インストールと最初の設定で触るファイル
導入はドキュメントの installation ページに従う形で、Python パッケージとして入れる。pip install opencompass が基本のコマンドになる。設定を書くときの出発点は examples ディレクトリで、たとえば examples/eval_mmbench_vlmevalkit.py や examples/eval_mmmu_pro_vlmevalkit.py がマルチモーダル評価の例として README に挙げられている。マルチターンの指示追従を測る場合は opencompass/configs/datasets/MultiIF/MultiIF_gen.py が参照先として示されている。モデル側の接続は opencompass/models 以下に実装があり、openai_response.py、litellm_api.py、gemini_sdk_api.py、claude_sdk_api.py がそれぞれ OpenAI Responses API、LiteLLM AI Gateway、Gemini SDK、Anthropic SDK に対応する。プロンプトを加工せずそのまま渡したい場合は RawPromptTemplate を使い、docs/en/notes/rawprompttemplate.md に説明がある。API モデル、ChatML 形式のデータセット、モデル側でのプロンプト追記に対応するとされている。
0.4.0 の設定統合は過去の資産を壊しうる
最も見落としやすい制約は設定ファイルの場所である。0.4.0 より前の構成で書かれた社内の評価設定は、パッケージ内の configs を指すように書き換えないと動かない。README も breaking change として明示している。これは単なるパスの問題ではなく、設定をリポジトリ側でバージョン管理していたチームほど影響が大きい。もう一点、評価の再現性はデータセット側の実装に依存する。同じベンチマーク名でも採点ロジックが更新されれば過去のスコアと単純比較はできなくなる。リリースは 0.5.2、0.5.3、0.5.4 と数か月間隔で続いており、機能追加のペースは速い。長期の比較表を維持したいなら、評価に使ったコミットを固定して記録する運用が要る。
LM Evaluation Harness との設計の違い
比較対象として分かりやすいのは EleutherAI の LM Evaluation Harness である。あちらはタスク定義とモデル呼び出しを 1 つのコマンドにまとめ、単一のベンチマークを素早く回すことに重心がある。OpenCompass は推論と評価を別タスクに分け、並列推論と監視を挟む構成を取る。多数のデータセットとモデルの組み合わせを一括で流し、結果を summarizer で集約する用途に向く。逆に、1 つのデータセットを数十プロンプトだけ試したい場合、この分離は設定の記述量として跳ね返ってくる。マルチモーダル評価では VLMEvalKit との統合が入り、OpenAI 互換 API 経由の推論と VLMEvalKit 公式の指標で採点できると README は説明している。テキスト専用の評価基盤としてだけ見ると、この統合の分だけ構成要素が増える点は把握しておきたい。
ライセンスと更新コストの見積もり
ライセンスは Apache-2.0 で、特許条項と変更点の明示を含む一般的な許諾条件が付く。社内ツールへの組み込みや改変自体はこの条件の範囲で判断できるが、同梱される各データセットのライセンスは別に確認が必要である。評価データの中には研究用途に限られるものがあり、OpenCompass 側のライセンスがそれを上書きすることはない。更新コストは、設定の場所が変わった前例がある以上、固定バージョンで運用するか追従するかを最初に決めておくべきである。0.5.x 系では API モデルの接続先が増え、推論の並列化や繰り返し出力の検出ツール tools/analyze_repeat.py が追加された。これらの機能を使うほど、更新時の確認範囲は設定ファイル全体に広がる。
導入を決める前に確かめる 3 つの点
第一に、使いたいデータセットが configs 内に存在し、その評価器が自分の求める採点基準と一致するか。第二に、モデルの接続方式が opencompass/models の実装で賄えるか。独自 API を叩く必要があるなら、既存実装を参考に自前で書く前提になる。第三に、比較したい過去のスコアがどのバージョンで出たものか。0.4.0 の設定統合を跨いだ比較表は、そのままでは接続できない。評価は一度きりの作業ではなく、モデルを差し替えるたびに繰り返す。OpenCompass を選ぶという判断は、この反復の手順を設定ファイルとして固定できるかどうかの判断でもある。
編集部の結論
既存のベンチマーク群を自前のモデルにまとめて当てたいチーム、とくに推論を複数タスクで並列に流したい規模の評価を行うチームには向いている。逆に、単一データセットを少量のプロンプトで確認したいだけの場合や、評価設定を長期間固定して再現性だけを重視する運用には重い。導入前に確認すべきは、自分の設定ファイルが 0.4.0 以降の opencompass パッケージ内の configs を参照しているか、そして使うデータセットの評価器が CascadeEvaluator を必要とするかどうかの 2 点である。
コミュニティノート