LLMのプログラミング能力を測定するコード生成ベンチマーク。HumanEval は164問のPython関数生成タスク、MBPP は974問の基本プログラミング問題で構成される。
HumanEval と MBPP（Mostly Basic Python Problems）は、LLM のコード生成能力を定量評価するための代表的ベンチマークである。
HumanEval は2021年に OpenAI が Codex 論文と共に発表したベンチマークで、164問の Python 関数生成タスクから構成される。各問題は関数シグネチャ・docstring・テストケースの3要素で定義され、モデルが生成したコードが全テストケースをパスするかどうかで正誤を判定する。
MBPP は2021年に Google Research が発表した974問のベンチマークで、HumanEval より基本的なプログラミング問題（文字列操作・リスト処理・数学計算等）を中心に構成されている。
コード生成の評価には pass@k メトリクスが標準的に使用される。これは「k回の生成試行のうち少なくとも1回正解する確率」を意味する。
| メトリクス | 意味 | 用途 |
|---|---|---|
| pass@1 | 1回の生成で正解する確率 | 実用性能の指標（最重要） |
| pass@10 | 10回の生成で少なくとも1回正解する確率 | モデルの潜在能力 |
| pass@100 | 100回で少なくとも1回正解する確率 | 理論上限の把握 |
素朴な推定（k回生成して正解率を求める）ではバイアスが生じるため、以下の不偏推定量を使用する。
n回の生成のうち c 回正解した場合:
pass@k = 1 - C(n-c, k) / C(n, k)
ここで C(a, b) は二項係数。実装では対数空間で計算し、数値安定性を確保する。
| モデル |
|---|
| HumanEval pass@1 |
|---|
| MBPP pass@1 |
|---|
| 備考 |
|---|
| GPT-4o (2024) | 90.2% | 86.8% | コード特化チューニング |
| Claude 3.5 Sonnet | 92.0% | 90.2% | SWE-Bench でも高スコア |
| DeepSeek-Coder-V2 | 90.2% | 89.4% | コード特化 MoE |
| Llama 3.1 405B | 89.0% | 84.8% | 汎用モデル最大級 |
| CodeLlama 34B | 48.8% | 55.2% | コード特化（2023） |
| GPT-3.5 Turbo | 48.1% | 52.2% | 2023年時点 |
| StarCoder2 15B | 46.3% | 54.1% | OSS コードモデル |
HumanEval と MBPP の限界を補完するため、複数の発展的ベンチマークが開発されている。
HumanEval と MBPP のテストケースを80倍以上に拡張したベンチマーク。元のベンチマークでは1問あたり平均7.7個だったテストケースを数百個に増やし、エッジケース（空入力・大規模入力・境界値等）での正確性を検証する。EvalPlus で再評価すると、多くのモデルのスコアが5〜15%低下する。
HumanEval を Python 以外の18言語（Java, C++, JavaScript, TypeScript, Rust, Go, Ruby, PHP, Swift, Kotlin, Scala, R, Julia, D, Lua, Racket, Perl, Bash）に翻訳したベンチマーク。言語間のコード生成能力差を定量化できる。
GitHub の実際の Issue と Pull Request をベースにした実世界ソフトウェアエンジニアリングベンチマーク。単一関数の生成ではなく、既存リポジトリのバグ修正・機能追加を含むため、コードベース理解・ファイル間の依存関係把握・テスト実行能力が問われる。
| ベンチマーク | 問題数 | 言語 | 評価対象 | 難易度 |
|---|---|---|---|---|
| HumanEval | 164 | Python | 単一関数生成 | 中 |
| MBPP | 974 | Python | 基本プログラミング | 低〜中 |
| EvalPlus | 164+974 | Python | エッジケース対応力 | 高 |
| MultiPL-E | 164×18 | 18言語 | 多言語コード生成 | 中 |
| SWE-Bench | 2,294 | Python | 実プロジェクトバグ修正 | 非常に高 |
| LiveCodeBench | 動的 | 多言語 | 競技プログラミング（汚染防止） | 高 |
# HumanEval の評価
lm_eval --model hf \
--model_args pretrained=bigcode/starcoder2-15b \
--tasks humaneval \
--num_fewshot 0 \
--generation_kwargs temperature=0.2,top_p=0.95 \
--output_path results/humaneval/
# pass@10 の算出（n=20回生成）
lm_eval --model hf \
--model_args pretrained=bigcode/starcoder2-15b \
--tasks humaneval \
--num_fewshot 0 \
--generation_kwargs temperature=0.8,top_p=0.95,n=20 \
--output_path results/humaneval_pass10/
pass@1 の評価では低温（temperature=0.2）で最良の結果が得られ、pass@100 では高温（temperature=0.8）で多様な生成を促すことで正解率が向上する。報告時には必ず温度設定を明記する。
単純に信頼はできない。HumanEval は1〜20行程度の短い関数生成に限定されており、実務で求められる「既存コードベースの理解」「複数ファイルにまたがる変更」「テスト作成」といった能力は測定していない。SWE-Bench や実際のコードレビューでの評価を併用すべきである。pass@1 が90%超のモデルでも、SWE-Bench Verified では30〜50%程度にとどまることが多い。
かなり深刻である。HumanEval の問題は GitHub 上で広く公開されており、2023年以降に学習されたモデルの学習データにほぼ確実に含まれている。対策として、LiveCodeBench（競技プログラミングサイトから時系列で問題を収集し、モデルの学習カットオフ以降の問題のみを使用）や EvalPlus（テストケース拡張）が推奨される。
MultiPL-E を使用する。一般的にモデルは学習データ量に比例して言語別の性能差を示す。Python > JavaScript > Java > C++ の順にスコアが高い傾向があるが、コード特化モデル（DeepSeek-Coder、StarCoder2等）では差が縮小する。Rust や Go などの比較的新しい言語では、汎用モデルとコード特化モデルの差が特に大きい。