evalscope を採用する前に読む: 評価バックエンド統合と Agent 評価の実際
A streamlined and customizable framework for efficient large model (LLM, VLM, AIGC) evaluation and performance benchmarking.
ひと目でわかる
- これは何？
- ModelScope コミュニティが公開している LLM 評価フレームワーク evalscope について、README とリリースノートから確認できる範囲で、何を解決し、どこでつまずき、どの代替手段と競合するのかを整理する。
- 誰に向いている？
- すでに OpenAI 互換 API や ModelScope 経由でモデルを提供しており、MMLU や GSM8K のような定番ベンチマークと TTFT、TPOT の性能測定を同じ CLI で回したいチームには向いている。逆に、評価パイプラインの全ステップを自前で制御したい場合や、依存パッケージの更新頻度を抑えたい本番運用には、RAGAS や MTEB を直接呼ぶ構成のほうが素直だ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
evalscope が埋めようとしている穴は何か
モデルを社内で提供していると、能力評価と性能測定が別々のツールに分かれがちである。精度は OpenCompass 系のスクリプト、レイテンシは locust や独自の負荷試験ツール、結果の比較はスプレッドシート、という状態になりやすい。evalscope はこの分断をひとつの CLI と Web Dashboard にまとめようとしている。README の冒頭には「one-stop LLM evaluation framework」と書かれ、`evalscope eval` の 1 コマンド例が示されている。対象は LLM だけでなく VLM、Embedding、Reranker、AIGC まで含むと明記されており、マルチモーダルモデルを扱うチームを想定していることが読み取れる。評価の種類としては、モデル能力の評価、推論性能のストレステスト、結果の可視化の 3 つが柱として挙げられている。
バックエンドを丸ごと抱え込む設計とその代償
evalscope の特徴は、評価ロジックを自前で全部持つのではなく、既存の評価基盤をバックエンドとして統合する点にある。README では OpenCompass、VLMEvalKit、RAGEval が統合先として名前を挙げられている。RAG 評価については 2026.06.02 のリリースで MTEB 2.x と RAGAS 0.4.x に更新し、Pydantic ベースの設定に統一したと説明されている。つまり RAG 評価の実体は RAGAS 側にあり、evalscope はその起動と設定の統一を担う層だと考えたほうが実態に近い。この設計の利点は、ベンチマークの追加が比較的軽いことである。2026.07.03 と 2026.08.10 のリリースでは、CharXiv、BabyVision、ERQA、WorldVQA、AutomationBench、JobBench、MiniWoB、OmniDocBench-v1.6 などが短期間に追加されている。ただし裏返しとして、バックエンド側の破壊的変更が evalscope の更新を待たないと壊れる可能性がある。RAGAS 0.4.x のようなメジャー更新への追随がリリースノートに明記されているのは、追随自体が作業項目になっている証拠でもある。
Agent 評価と性能測定は同じ枠組みに乗っている
Agent 評価は evalscope が比較的力を入れている領域である。README によれば、GSM8K や AIME、SWE-bench Agentic といったベンチマークを、差し替え可能な戦略、ツール、Docker サンドボックスを備えた多ターンの AgentLoop の中で動かし、サンプルごとの Agent Trace を記録して可視化できるとされている。2026.06.23 のリリースでは OpenCode と OpenHands のランナーが追加され、`run_agent_loop` が公開 API になったと記載されている。性能測定側では TTFT や TPOT などの指標に対応し、2026.05.27 のリリースで Trie agentic trace replay が導入され、`trie_agentic_coding`、`trie_code_qa`、`trie_office_work` の 3 つのデータセットプラグインが実際のマルチターン Agent トレースを再生する。ターンごとのトークン上限とツール呼び出しのレイテンシを模擬できると説明されており、単純な固定プロンプトの負荷試験では見えない挙動を測ろうとしている。同じリリースで `--duration` による実行時間の上限指定も入っている。
動かすまでの手順と設定の勘所
導入手順は README に明示されている。`pip install evalscope` の後、`evalscope eval --model your-model-name --api-url $OPENAI_API_BASE_URL --api-key $OPENAI_API_KEY --eval-type openai_api --datasets gsm8k --limit 5` を実行する。Python は 3.10 以上が必要だとバッジで示されている。`--eval-type openai_api` を指定するため、OpenAI 互換のエンドポイントであれば自前のサービングでも対象になる。`--limit 5` はスモークテスト用で、まず少数サンプルで疎通を確認する使い方が想定されていると読める。性能測定側では 2026.06.16 のリリースで `--data-source` が統一され、リクエスト生成が並列化されたと記載されている。結果の可視化は Web Dashboard で行い、ドキュメントの visualization のページに詳細がある。RAG 評価は RAGEval バックエンドのガイドに設定方法が分かれている。設定ファイルのキー名やスキーマの全容は README には載っておらず、各バックエンドのガイドを参照する必要がある。
再現性のために評価バージョンを固定する仕組み
2026.08.24 の v1.11.0 で「published evaluation versions」が導入され、ベンチマーク結果の再現性が確保できると説明されている。これは地味だが実務では効く変更である。ベンチマークの実装はデータの前処理や正解判定の細部が変わるだけでスコアが動くため、四半期ごとに同じモデルを測って比較する運用では、評価側のバージョンを固定できないと差分の意味が薄れる。同じリリースではレポートの意味づけの改善と、実行が途中で終わった場合の扱いの強化も挙げられている。不完全な実行の結果を完全な実行と同列に並べてしまう事故を減らす方向の変更だと考えられる。ただし、この published evaluation versions が具体的にどの単位で固定されるのか、バージョン番号の付け方や過去バージョンの保持期間については、提供された資料からは確認できない。
向かないケースと、代わりに検討すべきもの
evalscope が適さないのは、評価の各段階を自分で組み立てたい場合である。RAG 評価を例に取ると、evalscope は RAGAS 0.4.x と MTEB 2.x をバックエンドとして呼び出す層であり、指標の定義やプロンプトの細部を変えたいなら RAGAS を直接使ったほうが早い。間に一枚挟まる分、バージョン制約も増える。同様に、テキスト埋め込みの評価だけが目的なら MTEB を直接動かすほうが依存は少ない。Agent 評価についても、Docker サンドボックスを前提とするベンチマークを選ぶ以上、コンテナを動かせない環境ではその部分は使えない。逆に、OpenCompass をすでに社内標準として運用しているチームにとっては、evalscope は OpenCompass を置き換えるものではなく、その上に性能測定と Dashboard を足す位置づけになる。どちらを主軸にするかは、既存のレポート形式をどちらに寄せたいかで決まる。
ライセンスと更新コストの見積もり
ライセンスは Apache-2.0 である。特許条項を含み、改変物の配布時に変更点を示す必要がある点が MIT との違いだが、社内利用の範囲では通常大きな問題にならない。ここで注意したいのは、evalscope 本体のライセンスと、統合先バックエンドのライセンスは別物だという点である。OpenCompass、VLMEvalKit、RAGEval、RAGAS、MTEB はそれぞれ別の条件で配布されており、evalscope が Apache-2.0 だからといってそれら全体が同じ条件になるわけではない。再配布や商用サービスへの組み込みを検討する場合は、依存ツリー全体を確認する必要がある。更新コストの面では、v1.10.0 が 2026.08.04、v1.11.0 が 2026.08.24、v1.11.1 が 2026.08.31 と、1 か月に複数回のリリースが続いている。ベンチマーク追加のペースも速く、2026.05 から 2026.08 にかけて多数のベンチマークが加わっている。活発である一方、固定したバージョンで運用し、上げるタイミングを自分で決めるほうが安全である。
編集部の結論
すでに OpenAI 互換 API や ModelScope 経由でモデルを提供しており、MMLU や GSM8K のような定番ベンチマークと TTFT、TPOT の性能測定を同じ CLI で回したいチームには向いている。逆に、評価パイプラインの全ステップを自前で制御したい場合や、依存パッケージの更新頻度を抑えたい本番運用には、RAGAS や MTEB を直接呼ぶ構成のほうが素直だ。採用前に確認すべきは 3 点で、第一に `pip install evalscope` 後に `evalscope eval --model ... --api-url ... --api-key ... --eval-type openai_api --datasets gsm8k --limit 5` が自分の API エンドポイントで通るか、第二に RAGEval バックエンドを使うなら MTEB 2.x と RAGAS 0.4.x の依存が既存環境と衝突しないか、第三に Agent 評価で Docker サンドボックスが必要なベンチマークを選ぶ場合にその実行基盤を用意できるかである。
コミュニティノート