Evaluation & Benchmarking

LLM Benchmark は 3 つのレベルに分類できます。

LLM Evaluation
├── Model Capability Benchmark
│   ├── Knowledge / Reasoning
│   ├── Mathematics / Coding
│   ├── Instruction Following
│   └── Long Context / Tool Calling
│
├── Inference Performance Benchmark
│   ├── TTFT / TPOT / ITL
│   ├── Latency / Throughput
│   ├── Concurrency / Goodput
│   └── GPU Memory
│
└── End-to-End Benchmark
    ├── Agent Task Success
    ├── RAG Quality
    ├── Tool Call Accuracy
    └── Latency / Cost / Reliability

1. Model Capability Benchmark

推論エンジンの速度ではなく、モデル自体の機能を測定するために使用されます。

一般的な評価次元:

• 知識と事実の正確さ。
• 数学的かつ論理的な推論。
• コード生成。
• 指示が続きました。
• 多言語機能。
• 長い文脈の理解。
• Tool Calling および Agent の機能。

共通指標

Pass@k

たとえば、コードに関する質問の場合:

Generate 5 Solutions

Solution 1 → Fail
Solution 2 → Fail
Solution 3 → Pass
Solution 4 → Fail
Solution 5 → Fail

今回サンプリングされた 5 つの候補のうち少なくとも 1 つは正しいため、対応する Pass@5 イベントは成功します。

正式な評価では、通常、複数の質問と複数のサンプリングに対して Pass@k がカウントされます。 n 候補が使用され、c がテストに合格した場合、標準の不偏推定を使用できます。

$$\operatorname{pass@k}=1-\frac{\binom{n-c}{k}}{\binom{n}{k}}$$

注: Pass@k は、単一の答え Accuracy と k を単純に乗算するものではありません。

レビューに関するよくある質問

• Data Contamination: テストの質問または回答がトレーニング データに入力されます。
• Benchmark Leakage: テスト セット、解答、レビュー情報が漏洩しました。
• Prompt Sensitivity: Prompt / Chat Template の違いは結果に影響します。
• Sampling Differences: Temperature と Top-p は生成時間が異なります。
• Judge Bias: LLM Judge の長さの優先、位置の優先、またはモデルの優先。

モデルを比較する場合は、評価構成を統一し、モデルのバージョン、Prompt、生成パラメータ、評価プログラムのバージョンを記録するようにしてください。

2. 共通モデル機能 Benchmark

SWE-bench

SWE-bench は、モデルまたは Agent が実際の GitHub Repository のソフトウェアの問題を処理できるようにします。

GitHub Issue
      ↓
Agent Reads Repository
      ↓
Modify Code
      ↓
Run Tests
      ↓
Resolved / Failed

HumanEvalよりも実際のソフトウェアエンジニアリングに近いです。

ただし、そのような結果は Agent Scaffold、ツールの権限、テスト環境、実行予算に大きく依存しており、基礎となるモデルに完全に起因するものではありません。

さらに、2026 年に、OpenAI は SWE-bench Verified がデータによって著しく汚染されていることを公に指摘し、代わりにより新しく信頼性の高い評価ベンチマークを使用することを推奨しました。したがって、Verified リーダーボード スコアは、最先端のコーディング能力を判断するために慎重に使用する必要があります。

3. Inference Performance Benchmark

推論パフォーマンス Benchmark 異なるハードウェア、推論エンジン、量子化スキーム、負荷の下での同じモデルの実行効率を調査します。

コア指標

TTFT および TPOT

出力 Token 番号が 1 より大きいリクエストの場合:

$$TPOT=\frac{Latency-TTFT}{OutputTokens-1}$$

ITL は隣接する出力間の遅延をカウントしますが、TPOT は通常、要求レベルの平均です。

Streaming では、この 2 つは関連していますが、同一ではありません。

異なるBenchmarkツールの測定位置と統計的口径は異なる場合があり、比較する前に式を確認する必要があります。

Goodput

Throughput が高いということは、必ずしもユーザー エクスペリエンスが優れていることを意味するわけではありません。

サーバーが 1 秒あたり 100 リクエストを完了しますが、これらのリクエストの多くは必要以上に遅延しているとします。

Goodput は、Service Level Objective (SLO) を満たすリクエストのみをカウントします。

たとえば:

SLO:
TTFT < 1 s
TPOT < 50 ms

100 requests/s total

80 requests/s meet SLO
20 requests/s violate SLO

Goodput = 80 requests/s

実際の SLO しきい値は、製品要件によって決定する必要があります。

Goodput は、システムの処理能力とユーザー エクスペリエンスの制約を組み合わせるため、Serving を生成する場合に特に重要です。

4. 推論パフォーマンステストシナリオ

ロードモデル

2 つの重要な概念:

Closed-loop Benchmark

特定の同時クライアント数を修正しました。 1 つのリクエストが完了すると、次のリクエストが開始されます。

N Concurrent Clients
       ↓
Request → Response → Next Request

Open-loop Benchmark

前のリクエストの完了を待たずに、設定されたリクエスト到着率に従ってリクエストを送信します。

5 Requests/s
10 Requests/s
20 Requests/s
...

Open-loop は、特定のリクエスト到着率に対するキューイング、レイテンシー、システム容量を調査するのに適しています。

テストに関する考慮事項

修正する必要があります:

• モデルと精度。
• GPU のモデルと数量。
• 推論エンジンのバージョン。
• 入出力Tokenの長さ分布。
• リクエストの到着率または同時実行数。
• Prefix Cacheの設定。
• Samplingパラメータ。

ウォーミングアップ、テスト期間、複数回の繰り返し測定も考慮する必要があります。

単に平均をレポートするのではなく、レイテンシについて少なくとも P50、P95、P99 をレポートすることをお勧めします。

5. End-to-End Benchmark

エンドツーエンドの評価は、アプリケーション全体が実際にユーザーの目標を達成しているかどうかに関係します。

User Request
      ↓
Application / Agent
      ↓
Retrieval / Tool Calling
      ↓
LLM
      ↓
Final Result
      ↓
Task Evaluation

一般的な指標:

モデルが適切に応答したからといって、Agent または RAG アプリケーション全体がタスクを正しく完了できるとは限りません。

6. Agent Evaluation

Agent のレビューでは、ツールの選択、パラメーター、実行パス、最終結果に焦点を当てています。

User Task
    ↓
Plan / Reason
    ↓
Select Tool
    ↓
Generate Arguments
    ↓
Execute Tool
    ↓
Observe Result
    ↓
Continue / Finish

コア指標

最も重要な原則

通常、Task Success Rate は、Tool-call Accuracy 単独よりも重要です。

たとえば、Agent ツールの選択が完全に正しいにもかかわらず、ユーザー タスクが最終的に完了しなかった場合でも、タスクは失敗とみなされます。

同時に、Steps が少ないほど必ずしも良いというわけではありません。手順を減らすことで成功率が低下することはありません。

Agent システムの場合、評価環境は、ツールの戻り値、外部ステータス、テスト データなどを含め、可能な限り再現可能でなければなりません。

7. RAG Evaluation

RAG は通常、Retrieval と Generation の 2 つの部分に分かれて評価されます。

User Query
     ↓
Retriever
     ↓
Retrieved Documents
     ↓
LLM
     ↓
Generated Answer

Retrievalインジケーター

Recall@k

たとえば、ある Query には 4 つの関連ドキュメントがあります。

Top-5 はそのうち 3 つを見つけました:

[ Recall@5=\frac34=0.75 ]

少なくとも 1 つの関連ドキュメントを見つけることだけを気にする場合は、Hit Rate@k を使用できますが、これは Recall@k とまったく同じではありません。

Precision@k

Top-5 には 3 件の関連記事があります。

[ Precision@5=\frac35=0.6 ]

MRR

Mean Reciprocal Rank は、最初の関連結果の位置に焦点を当てます。

Rank 1 → 1
Rank 2 → 1/2
Rank 5 → 1/5
No relevant result → 0

複数の Query の逆順位を平均します。

NDCG@k

Normalized Discounted Cumulative Gain 次の点も考慮してください。

• ドキュメントの関連性レベル。
• ドキュメントの並べ替え位置。

関連性の高いドキュメントが上位にランクされると、通常はより高いスコアが得られます。

一般的な値の範囲は 0 ～ 1 です。

Generationインジケーター

Faithfulness および Correctness

これら 2 つの概念は混同されやすいです。

Faithfulness は、回答が検索コンテキストに基づいているかどうかを測定します。

Correctness は、答えが事実として正しいかどうかを測定します。

たとえば、取得したドキュメントにはエラー メッセージが含まれており、LLM はこれを忠実に繰り返します。

Faithfulness → 高いかもしれない
Correctness  → おそらく低い

したがって、RAG は Faithfulness を見るだけでなく、検索ソースの品質と最終的な答えの正しさを評価する必要があります。

Ragas は、異なる評価指標として Faithfulness、Context Precision、Context Recall、Response Relevancy などを使用します。

8. 一般的に使用される評価ツール

vLLM Benchmark の例

vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --model your-model-id \
  --dataset-name random \
  --num-prompts 100 \
  --request-rate 5

この例ではランダムな合成リクエストを使用しており、予備的なパフォーマンス テストに適しています。互換性のあるモデル サービスを開始し、実行する前にモデル名が一致していることを確認する必要があります。

実際のストレス テストでは、Prompt の長さを使用し、運用環境と同様の分散を要求する必要があります。

9. 評価結果の信頼性

Benchmark の信頼性は、評価セットだけでなく実験計画にも依存します。

チェックすべき重要なポイント:

特に Agent/RAG アプリケーションでは、実際のビジネス タスクに対応する小規模な内部評価セットを確立する必要があります。

たとえば、意思決定においては、一般的なモデルのランキング リストのみに依存するよりも、100 件の実際のビジネス リクエストの方が価値があるのが通常です。

概要

最も重要な 3 つの原則:

1. の機能、速度、システムの成功率は ごとに個別に評価する必要があり、1 つの Benchmark スコアだけを調べることはできません。
2. A 公正な比較には、固定されたテスト条件 が必要です。そうでない場合、結果は比較できない可能性があります。
3. 本番システムは、最高の Tokens/s だけを追求するのではなく、品質、レイテンシー、スループット、コストの総合的なパフォーマンス に焦点を当てる必要があります。

---

参考資料

• lm-evaluation-harness
• vLLM Benchmarking
• GuideLLM
• Ragas Metrics
• DeepEval
• SWE-bench