Codex 配 TaoToken：复现 HumanEval 的 pass@k 评估-北京尧图网络

复现 Codex 那篇《Evaluating Large Language Models Trained on Code》时HumanEval 的 164 个问题本身不难理解难的是把采样脚本的通道真正配通。原文里 Codex-12B 单样本解决了 28.8% 的问题k100 时能到 70.2%但你自己跑的时候会发现Key 散落在不同账号、Base URL 多一个/v1、模型 ID 从别处抄来直接 404。我用 TaoToken 做统一接入通道把 Codex 模型的采样请求指到它的兼容地址再跑完整个 HumanEval 流程最后拿到自己的 pass1 和 pass100。下面按复现顺序写一遍配置部分直接可复制。1. HumanEval 到底在测什么164 个手写问题与 passk1.1 数据集结构和单元测试HumanEval 是 OpenAI 为了评估代码生成模型的功能正确性而手写的数据集一共 164 个问题。每个问题包含一个函数签名、一段文档字符串、函数主体占位和平均 7.7 个单元测试。这些测试不是检查输出文本像不像参考答案而是直接执行函数、断言返回值所以“看着对”没用必须跑过测试才算对。复现时你要把每个问题组装成一个提示标题、签名、文档字符串连起来丢给模型生成补全。生成结果不是完整程序而是从文档字符串后面继续写函数体。收集到答案后在本地沙箱里运行单元测试判定这一份样本是否通过。1.2 原文结论里的两个关键数字原始论文报告了两个层次的结果Codex-12B 每个问题只生成一个样本时通过率 28.8%每个问题生成 100 个样本、只要其中任何一个通过单元测试就算解决通过率提升到 70.2%。作为对比GPT-3 接近 0%GPT-J-6B 是 11.4%。复现这个流程你不需要重新训练模型只需要拿到一个能跑 Codex 系列模型的 API 通道然后用官方 human-eval 仓库里的评估逻辑把采样、执行、统计三步串起来。最花时间的不是公式而是把通道配对Base URL 填错、Key 前缀多了空格、模型 ID 不在列表里都会让脚本停在请求阶段。2. 复现前的准备确认模型 ID拿到 TaoToken Key2.1 打开模型广场确认可用的 Codex 模型写采样脚本之前先确认你能用哪个模型 ID。不同通道对模型 ID 的命名不一样直接用论文里的code-cushman-001或code-davinci-002这种历史名字去请求现代接口大概率返回 model not found。所以第一步是打开 TaoToken 的模型广场看当前列表里 Codex 相关模型叫什么、是不是支持chat.completions接口。这一步对应原文里“从模型中采样符元”的前置条件你先得有一个能采样的模型入口。模型广场列出的 ID 就是脚本里model参数的取值来源不要从旧博客或截图里抄一个固定写法。2.2 创建 Key并分清官网地址和 Base URL注册并登录后在控制台创建 API Key把生成的字符串复制到本地环境变量。注意两个地址不要混用官网落地页只用来注册、创建 Key、看模型广场、看用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end填进 Codex CLI 或 Python 脚本里的 Base URL 是https://taotoken.net/api末尾不带/v1我在第一次配置时把 Base URL 写成了带/v1的完整 OpenAI 风格地址结果所有请求返回 404。后来才意识到TaoToken 的兼容通道地址已经在内部处理了版本路径外面再加/v1反而多余。3. 把 Codex 的采样通道指向 TaoToken3.1 Codex CLI 的 config.toml 里配置 model_provider如果你用 Codex CLI 来跑验证而不是自己写 Python 脚本可以修改~/.codex/config.toml增加一个自定义 provider。Codex CLI 本身支持model_provider配置块把 Base URL 指向 TaoToken 即可model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后导出环境变量export TAOTOKEN_API_KEYYOUR_API_KEYYOUR_MODEL_ID替换成 2.1 节在模型广场查到的实际 IDYOUR_API_KEY替换成你在 TaoToken 创建的 Key。env_key指定的是 Codex CLI 读取环境变量的名字这里用TAOTOKEN_API_KEY你也可以换成自己习惯的变量名。3.2 Python 采样脚本中的 stop 序列与温度复现 HumanEval 的核心是批量采样我用的是官方 human-eval 仓库的思路但把请求层改成 OpenAI SDK 的chat.completions。你需要安装openai库然后创建客户端from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://taotoken.net/api, ) stop_sequences [\nclass, \ndef, \n#, \nif, \nprint] response client.chat.completions.create( modelYOUR_MODEL_ID, # 以模型广场列表为准 messages[ {role: user, content: prompt}, ], temperature0.8, max_tokens512, stopstop_sequences, ) generated_code response.choices[0].message.content这里的stop参数对应原文里的停止序列。原始论文在采样时遇到\nclass、\ndef、\n#、\nif、\nprint就停止生成因为模型如果继续写下去可能在同一段补全里塞进多个函数定义导致单元测试无法定位被测函数。复现时不要省略这一步否则你收集到的样本会混入大量无关代码。温度设置也要按原文来pass1 用 0.2pass100 用 0.8。原论文专门做了温度实验结论是 k 值越大、温度越高效果越好因为较大的温度能提高样本多样性而 passk 只关心是否有一个样本通过。如果你复制别人的脚本但没改温度得到的 pass1 可能偏低但 pass1 的最佳温度 0.2 和 pass100 的最佳温度 0.8 是原文报告的数字不需要你自己再搜一遍。4. 算 passk公式、单元测试与本地执行4.1 用组合数公式估算 passk拿到一批生成结果后你不能直接认为“通过数 / 总样本数”就是 passk因为 k 是从 n 个采样里随机抽出的子集大小正确率要用组合数做无偏估计。OpenAI 官方 human-eval 仓库提供了一个简洁实现import math def pass_at_k(n, c, k): n 个样本中有 c 个通过测试估算 passk 的期望值。 if n - c k: return 1.0 return 1.0 - math.comb(n - c, k) / math.comb(n, k)对每个 HumanEval 问题你生成 n 个样本比如 n100跑完单元测试后统计通过的样本数 c代入这个函数就得到了该问题在当前 k 下的估算通过率最后对 164 个问题取平均。注意math.comb在 Python 3.8 之后才有如果你的环境版本低需要用scipy.special.comb替代。4.2 单元测试在本地执行报错再贴回对话模型生成的 Python 代码不能直接在你的生产环境或业务机器上执行。HumanEval 的 164 个问题本身是独立函数但生成结果可能是错的、有副作用的甚至包含恶意逻辑。正确的做法是把生成代码和单元测试一起放到本地沙箱、Docker 容器或单独的虚拟环境里运行只收集“通过 / 失败”的布尔结果。如果某个样本运行报错把完整 traceback 贴回对话让模型根据报错修改函数实现。这里有个边界要守住TaoToken 只负责模型请求的接入它不会替你执行代码也不应该直连你的数据库或服务器。你负责本地执行结果再回到脚本里统计。5. 复现时最常见的三个报错401、模型 not found 和多 /v15.1 401 的第一反应是查 Key而不是换通道如果你在跑脚本时收到 401优先检查三件事按照出现概率排序。第一Key 是否复制完整。控制台生成的 Key 是一整段字符串复制时容易漏掉末尾几个字符或者带了一个看不见的换行符。第二环境变量有没有真正生效。如果你在.env文件里写了 Key但代码用os.getenv读取时没有提前加载文件读到的是None。第三Key 是否发到了正确的请求头里。用 OpenAI SDK 时SDK 会自动处理Authorization头但如果你自己写requests脚本需要手动加上headers { Authorization: fBearer YOUR_API_KEY, Content-Type: application/json, }这三个原因都排除后再看是不是 Base URL 写错。5.2 模型 not found 和多余 /v1 的排查模型 not found 通常是模型 ID 和当前模型广场列表不一致。原始论文里的 Codex 模型名字是历史命名你在 TaoToken 的模型广场里查到的才是实际的 ID。修这个问题只需要回到 TaoToken 对照列表不要凭记忆硬填。多/v1的问题表现为请求返回 404而不是 401。填 Base URL 时写成https://taotoken.net/api/v1会把请求打到不存在的路径上正确写法是https://taotoken.net/api末尾不要加版本号。这一点在 Codex CLI 和 Python 脚本里同样适用。6. 跑完 164 题之后对账、归档与下一步6.1 在 TaoToken 控制台核对这次评估的调用量完整跑一次 pass100 意味着要生成 164 × 100 16400 个样本即使每个样本只算几十个 token累积起来也远超个人免费额度。跑完评估后回到 TaoToken 控制台核对一下这次评估的请求次数和 token 消耗确认没有超出 Coding Plan 的预算范围。如果你只是想验证通道是否配通不需要跑完整 pass100先用 pass1 跑 5 个问题看一下日志里的模型回复和单元测试结果确认输出符合预期再放量跑全量。6.2 后续深挖模型对话验证和 Claude Code 接入评估跑完后你可以用 TaoToken 模型对话把同一个模型 ID 再测一条消息确认它和脚本里用的是同一个入口。若要长期在编程工具里使用可以打开 Coding Plan 查看套餐余量如果你后续打算把 Claude Code 也接到同一个 API Key 上接入文档在这里Claude Code 配置文档。复现完 HumanEval 你就会发现大部分时间不是花在“理解 passk”上而是花在“让采样脚本稳定跑通”上。把 Key 放在环境变量里、Base URL 保持https://taotoken.net/api、模型 ID 以模型广场为准这三个位置对了剩下的就是等待 16400 个样本跑完然后把数字和论文里的 28.8%、70.2% 做对比。如果你的结果和论文差距明显先检查温度和 stop 序列再检查采样数量是不是真的到了 100这两处是最容易悄悄出错的地方。

Codex 配 TaoToken：复现 HumanEval 的 pass@k 评估

相关推荐

微电网虚拟惯性控制仿真技术与应用实践

永磁同步电机转矩分解技术与Maxwell实现

【uni-app项目实战】心理健康服务平台（三）

更多资讯

Wazuh 5.x SCA 自定义策略迁移指南：从 4.x 格式到 PCRE2 与 YAML 新规范的完整实战

Cilium Hubble Relay 节点状态协议解析：relay.proto 中的 NodeStatusEvent 与 NodeState