pass@k:代码评测分数怎么算

黎 浩然/ 11 10 月, 2026/ 大语言模型/LARGELANGUAGEMODEL/LLM, 机器学习/MACHINELEARNING, 研究生/POSTGRADUATE, 计算机/COMPUTER/ 0 comments

代码模型的pass@10高于pass@1,可能只是多了九次尝试机会。pass@k关心的是:给每道题生成k份候选,至少一份通过测试的机会有多大。它不直接告诉你默认展示的那一份是否正确,也不替你解决“如何选中正确候选”。

文章目录
  1. 同一题的10份候选,怎样算
  2. 用组合数复算,不运行模型代码
  3. 为什么不直接算1−(1−c/n)ᵏ
  4. 整套题,先逐题再平均
  5. 分数背后还要看生成和测试条件
  6. 资料来源

同一题的10份候选,怎样算

假设对一道虚构题目生成10份候选,其中2份通过测试。记录n=10、c=2。候选可以内容相同,但这里按生成样本的索引计数,不擅自去重。

1
通过
2
通过
3
未通过
4
未通过
5
未通过
6
未通过
7
未通过
8
未通过
9
未通过
10
未通过
原创候选池示意:10份样本中2份通过,标签为人工构造。选3个样本索引共120种组合,其中64种包含通过样本。

从10份候选中等概率、不放回地选3份,共有C(10,3)=120种选法。完全没选中通过样本的组合有C(8,3)=56种。因此至少包含一个通过样本的比例为1−56/120=8/15,约53.33%。这就是该候选池给出的单题pass@3估计。

一般写成 1 − C(n−c,k) / C(n,k),要求n≥k。若未通过的样本不到k份,任意这样的子集都包含通过样本,估计值为1;若c=0,估计值为0。k=1时退化为c/n。

用组合数复算,不运行模型代码

以下原创Python示例使用精确分数表示比例,适合这个小计数例子。代码已运行,核对了常用k值和零通过的边界;另外枚举n=1至10的所有440组合法(n,c,k),与逐个子集统计的结果比较一致。

from math import comb
from fractions import Fraction

def pass_estimate(n, c, k):
    if not (n >= 1 and 0 <= c <= n and 1 <= k <= n):
        raise ValueError("require n>=1, 0<=c<=n, 1<=k<=n")
    if n-c < k:
        return Fraction(1,1)
    return 1-Fraction(comb(n-c,k),comb(n,k))

assert pass_estimate(10,2,1) == Fraction(1,5)
assert pass_estimate(10,2,3) == Fraction(8,15)
assert pass_estimate(10,2,5) == Fraction(7,9)
assert pass_estimate(10,0,3) == 0
assert pass_estimate(10,2,10) == 1
for k in [1,3,5,10]:
    print(k, round(float(pass_estimate(10,2,k)),6))
k 单题估计 含义
1 20% 随机取一份
3 约53.33% 三份中至少一份通过
5 约77.78% 五份中至少一份通过
10 100% 这批十份里确实有通过样本

最后一行只是这批已观察样本的估计,不保证下一批必然出现正确候选。代码仅计算人工标签,没有下载模型、生成程序或执行候选程序;较大评测应关注数值实现,不把教学用组合数实现直接当成生产评测器。

为什么不直接算1−(1−c/n)ᵏ

若知道一次独立生成的真实通过概率p,k次独立尝试至少一次通过的概率是1−(1−p)ᵏ。但c/n只是有限样本对p的估计,不是已知p。

本例代入c/n=0.2与k=3,会得到1−0.8³=0.488,和8/15不同。前者用估计值代入非线性公式;后者统计观察池中不放回选择的子集。两者不应混用。HumanEval原始论文给出了组合数估计及其分析;无偏性的解释依赖同一生成设置下独立同分布的采样假设。

如果每次失败后都读测试反馈并修改提示,再生成下一份,那是带反馈的修复流程,应单独报告。不能让独立采样的公式掩盖流程和预算已经改变。

整套题,先逐题再平均

评测总分通常先得到每道题的估计,再对题目平均。不要把所有候选的通过数直接汇总,尤其当不同题生成的数量不一样时:汇总会给样本多的题更大权重。

用k=1的例子看得更清楚:题A生成10份、全部通过;题B生成100份、全部失败。按题平均是(1+0)/2=50%,把候选混在一起则是10/110≈9.09%。两个数字回答的不是同一个问题。正式比较仍建议保持各题生成预算一致。

分数背后还要看生成和测试条件

2021年的《Evaluating Large Language Models Trained on Code》以arXiv预印本形式公开,并发布HumanEval项目。这里引用它的指标定义,不把历史模型成绩当成当前排名,也不复现模型实验。

比较时至少记录模型版本、提示、每题采样数、k、采样配置、测试版本以及超时与失败的计数规则。若产品只展示一个候选,还应另测实际选择策略的成功率。能用评测测试判定“至少一份通过”,不代表日常使用时也知道该选哪一份。

通过有限测试也不是对所有输入正确的证明。把pass@k与任务成本、首次可用率、失败类型一起看,更容易判断多次生成究竟带来什么。

English version

资料来源

Evaluating Large Language Models Trained on Code (2021 preprint); HumanEval; 官方指标计算实现.

支持

如果这篇文章对你有帮助,欢迎支持本站。

微信支持二维码,点击查看大图
微信
支付宝支持二维码,点击查看大图
支付宝
Buy Me a Coffee,点击支持本站
Buy Me a Coffee

二维码可点击放大。更多支持方式见支持页面。

Share this Post

Leave a Comment

您的邮箱地址不会被公开。 必填项已用 * 标注

*
*