Home 論文解説: Evaluating Large Language Models Trained on Code — HumanEvalとpass@kの原点
投稿
キャンセル

📄 論文解説: Evaluating Large Language Models Trained on Code — HumanEvalとpass@kの原点

投稿日 20/04/2026
投稿者 0h-n0
18 分読了時間

本記事は Evaluating Large Language Models Trained on Code（Chen et al., 2021; OpenAI）の解説記事です。

論文概要（Abstract）

本論文はOpenAIのCodex（GPT-3ベースのコード生成モデル）と共に、HumanEvalデータセット（164問の手書きPythonプログラミング問題）およびpass@k評価指標の数学的定義を提示した、コード生成評価の基礎論文である。docstringから関数本体を生成し、単体テストで評価するという現在の標準的な評価パラダイムを確立した。著者らはCodex（12Bパラメータ）がHumanEval pass@1で28.8%を達成し、GPT-3やGPT-Jを大幅に上回ることを報告している。さらに、温度パラメータとサンプリング数の関係を詳細に分析し、pass@kの不偏推定量を導出している。

この記事は Zenn記事: SWE-Bench Proから自作評価まで LLMコーディングベンチマーク実践ガイド の深掘りです。

情報源

  • arXiv ID: 2107.03374
  • URL: https://arxiv.org/abs/2107.03374
  • 著者: Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, Wojciech Zaremba（OpenAI）
  • 発表年: 2021年
  • 分野: cs.LG, cs.CL
  • コード: openai/human-eval

背景と動機（Background & Motivation）

2021年時点で、LLMのコード生成能力を定量的に評価する標準的な手法は確立されていなかった。既存の手法としてはBLEUスコア（参照コードとの文字列一致度）が使われることがあったが、BLEUは正しさの評価には適さない。同じ機能を実装するコードでも、変数名やアルゴリズムの選択が異なればBLEUスコアは低くなる。

著者らは「コード生成の正しさは、人間の判断ではなくテスト実行で自動的に判定すべきである」という原則に基づき、docstringから関数本体を生成させ、事前に用意した単体テストで正誤を判定する評価パラダイムを提案した。

主要な貢献（Key Contributions）

  • 貢献1: 164問の手書きPythonプログラミング問題からなるHumanEvalデータセットを公開した。各問題はdocstring、関数シグネチャ、および平均7.7個のテストケースで構成される
  • 貢献2: pass@kの不偏推定量を数学的に導出し、k回のサンプリングで少なくとも1つの正解を得る確率を推定する標準的な評価指標を確立した
  • 貢献3: Codex（12Bパラメータ、GitHubコードで学習）がHumanEval pass@1で28.8%を達成し、コード特化学習の有効性を実証した

技術的詳細（Technical Details）

HumanEvalデータセットの設計

HumanEvalの164問はすべてOpenAIのエンジニアが手書きで作成した。各問題は以下の要素で構成される。

1
2
3
4
5
6
7

{
    "task_id": "HumanEval/0",
    "prompt": "from typing import List\n\ndef has_close_elements(numbers: List[float], threshold: float) -> bool:\n    \"\"\"Check if in given list of numbers, are any two numbers closer to each other than\n    given threshold.\n    >>> has_close_elements([1.0, 2.0, 3.0], 0.5)\n    False\n    >>> has_close_elements([1.0, 2.8, 3.0, 4.0, 5.0, 2.0], 0.3)\n    True\n    \"\"\"\n",
    "canonical_solution": "    for idx, elem in enumerate(numbers):\n        for idx2, elem2 in enumerate(numbers):\n            if idx != idx2:\n                distance = abs(elem - elem2)\n                if distance < threshold:\n                    return True\n    return False\n",
    "test": "...(7 assert statements)...",
    "entry_point": "has_close_elements"
}

設計上の意図: 各問題は自己完結的であり、外部ライブラリのインポートを必要としない。これにより環境依存性を排除し、評価の再現性を確保している。問題の難易度はinterview-level（面接レベル）に設定されている。

pass@kの数学的定義

pass@kは「$n$回のサンプリングから$k$個を選んだ際に、少なくとも1つが正解である確率」の不偏推定量として定義される。

直感的な理解: モデルに同じ問題を$n$回解かせ、$c$回正解したとする。ここから$k$個をランダムに選んだときに、すべてが不正解（= 1つも正解を含まない）確率は$\frac{\binom{n-c}{k}}{\binom{n}{k}}$であるから、少なくとも1つが正解である確率は：

\[\text{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}\]

ここで、

  • $n$: 総サンプリング回数（論文では$n = 200$を推奨）
  • $c$: $n$回中の正解回数
  • $k$: 選択する候補数（$k = 1, 10, 100$等）
  • $\binom{a}{b}$: 二項係数（$a$個から$b$個を選ぶ組み合わせ数）

なぜこの推定量が不偏なのか: 素朴な推定量$\hat{p} = c/n$のk乗版$1 - (1 - \hat{p})^k$は偏りを持つ。著者らの推定量は二項係数を使うことでサンプリングの離散性を正確に反映し、不偏性を保証している。

具体例: $n = 200$回サンプリングして$c = 10$回正解した場合

\[\text{pass@}1 = 1 - \frac{\binom{190}{1}}{\binom{200}{1}} = 1 - \frac{190}{200} = 0.05 = 5\%\] \[\text{pass@}10 = 1 - \frac{\binom{190}{10}}{\binom{200}{10}} \approx 40.4\%\]

温度パラメータとpass@kの関係

著者らは温度パラメータ$T$とpass@kの関係を詳細に分析している。

graph LR
    A[温度T=0<br/>Greedy] --> B[pass@1に最適<br/>最尤系列を選択]
    C[温度T=0.2] --> D[pass@1にも有効<br/>やや多様性あり]
    E[温度T=0.8] --> F[pass@k k≥10 に最適<br/>多様な候補を生成]
    G[温度T=1.0+] --> H[品質低下<br/>ノイズが増加]

低温度（$T \leq 0.2$）: 生成の多様性が低く、毎回ほぼ同じ出力になる。pass@1の評価に適している。

中温度（$T \approx 0.8$）: 多様な候補を生成できるため、pass@10やpass@100の評価に適している。著者らの実験では$T = 0.8$でpass@100が最大化されることが確認されている。

高温度（$T > 1.0$）: ノイズが支配的になり、構文エラーや意味のないコードが増加する。

数値安定性のための実装

pass@kの計算では二項係数が非常に大きな値になるため、直接計算すると数値オーバーフローが発生する。著者らは対数空間での計算を推奨している。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import numpy as np


def pass_at_k(n: int, c: int, k: int) -> float:
    """pass@kの不偏推定量を計算する

    Args:
        n: 総サンプリング回数
        c: 正解回数
        k: 選択する候補数

    Returns:
        pass@kの推定値
    """
    if n - c < k:
        return 1.0

    return 1.0 - np.prod(1.0 - k / np.arange(n - c + 1, n + 1))

この実装では、二項係数を直接計算する代わりに乗算の連鎖として表現し、数値安定性を確保している。$\frac{\binom{n-c}{k}}{\binom{n}{k}}$を展開すると：

\[\frac{\binom{n-c}{k}}{\binom{n}{k}} = \prod_{i=0}^{k-1}\frac{n-c-i}{n-i} = \prod_{i=0}^{k-1}\left(1 - \frac{c}{n-i}\right)\]

実装のポイント（Implementation）

サンプリング数の選択: 著者らは$n = 200$を推奨しているが、API費用の観点から$n = 20$程度でpass@1を推定することも実用的である。ただし$n$が小さいと推定の分散が大きくなる点に注意が必要である。

テスト実行のセキュリティ: HumanEvalのテスト実行ではモデルが生成したコードをexec()で実行する。悪意のあるコード（ファイル削除、ネットワークアクセス等）のリスクがあるため、--confirm_run_unsafe_codeフラグが必要である。本番環境ではDocker sandboxの利用が推奨される。

エントリーポイントの指定: 各問題にはentry_pointフィールドがあり、モデルが定義すべき関数名を指定している。モデルが異なる関数名で実装した場合、テストが失敗する。

実験結果（Results）

著者らの主要な実験結果は以下の通りである（論文Table 1, Table 2より）。

モデルパラメータ数pass@1pass@10pass@100
Codex (12B)12B28.81%46.81%72.31%
Codex (300M)300M13.17%20.37%36.27%
GPT-3 (175B)175B0.00%0.00%0.00%
GPT-J (6B)6B11.62%15.74%27.74%
TabNine-2.58%--

Codexのスケーリング則: 著者らはモデルサイズとpass@1の間に明確なスケーリング則を観測している。12Bモデルは300Mモデルの2倍以上のpass@1を達成しており、パラメータ数の増加がコード生成能力に直結することが示されている。

GPT-3の結果: 175Bパラメータを持つGPT-3はHumanEvalでpass@1 = 0%を記録した。これは事前学習データにコードが十分に含まれていなかったためであり、コード特化の追加学習（ファインチューニング）の重要性を示している。

pass@1 vs pass@100: Codex 12Bのpass@1は28.81%だが、pass@100は72.31%に達する。これは「正解を生成する能力は持っているが、最尤の候補として選択する能力が不足している」ことを示唆している。著者らは「リランキング（生成候補の中から最良のものを選択する仕組み）が重要な研究方向である」と述べている。

実運用への応用（Practical Applications）

コーディングアシスタントのA/Bテスト: pass@kの指標は、GitHub CopilotやCursorなどのコーディングアシスタントの品質測定に直接応用できる。ユーザーに$k$個の候補を提示し、その中に正解が含まれる確率としてpass@kを解釈できる。

モデル評価パイプライン: Zenn記事で紹介したlm-evaluation-harnessはHumanEvalをビルトインタスクとしてサポートしている。--tasks humanevalで即座に評価できるため、自社モデルのベースライン測定に適している。

温度設定の最適化: pass@1を重視する場合は低温度（0-0.2）、候補の多様性を重視する場合は中温度（0.6-0.8）という著者らの知見は、プロダクション環境でのLLM設定に直接活用できる。

関連研究（Related Work）

  • MBPP（Austin et al., 2021）: 約1,000問のPythonプログラミングタスク。HumanEvalと並んで初期のコード生成ベンチマークとして広く利用されたが、同様に飽和が進んでいる
  • APPS（Hendrycks et al., 2021）: 競技プログラミング問題をベースにした評価セット（10,000問）。HumanEvalより難易度が高く、問題数も多いが、データ汚染への対策は含まれていない
  • AlphaCode（Li et al., 2022, DeepMind）: Codeforcesの競技プログラミングコンテストでLLMを評価した研究。大量サンプリング（100万回以上）とフィルタリングによるアプローチを採用

まとめと今後の展望

本論文はHumanEvalデータセットとpass@k評価指標を通じて、LLMコード生成の評価パラダイムを確立した基礎論文である。「テスト実行による自動評価」「温度とサンプリング数の最適化」「不偏推定量の数学的定義」といった方法論は、2026年現在でもSWE-bench、LiveCodeBench、BigCodeBenchなど後続の全てのコーディングベンチマークに継承されている。

一方で、164問という小規模さ、Python単言語、アルゴリズム問題への偏り、データ汚染への無防備さといった限界から、HumanEval単体でのモデル評価は推奨されなくなっている。後続研究が解決を目指したこれらの課題を理解するためにも、原点である本論文の理解は不可欠である。

参考文献

blog paper arxiv
HumanEval Codex pass-at-k benchmark LLM code-generation python machinelearning
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次