尧图网站建设 
Qwen3-Coder 评测实践ExecRepoBench 仓库级代码补全基准的环境搭建、多级掩码机制与端到端评估指南【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-CoderExecRepoBench 是面向真实软件开发场景的仓库级repository-level代码补全基准它从活跃的 Python 仓库中抽取 1.2K 个样本并要求模型在跨文件依赖上下文中完成被掩码的代码片段同时配套 Repo-Instruct 指令语料以提升开源大语言模型的代码补全能力。本文以 ExecRepoBench README 为骨架结合 qwencoder-eval 评测目录下的真实实现create_test_repo.py、eval.py、utils.py 等完整讲解数据下载、评测环境准备、四类补全任务的构造原理以及基于 vLLM 的生成与 pass1/编辑相似度评估全流程。读完本文你将能够在本仓库中复现 ExecRepoBench 的完整评测链路并理解其 AST 多级掩码与跨文件上下文组织的底层设计。ExecRepoBench 是什么仓库级代码补全评测的核心思想传统代码补全基准如 HumanEval 的 FIM 变体通常在单文件内构造任务而真实开发中一个函数往往依赖同仓库其他模块中定义的类、工具函数与配置。ExecRepoBench 的核心目标正是填补这一空白它以多文件协作、存在复杂跨文件依赖的活跃 Python 仓库为素材构建前缀 被掩码片段 后缀的补全样本让模型在参考了仓库其他文件内容后才能正确恢复被掩码的代码。根据 README 的 Dataset Summary该工作同时贡献了两样东西ExecRepoBench 基准包含 1.2K 条来自活跃 Python 仓库的样本用于评测仓库级代码补全Repo-Instruct 指令语料用于改善开源 LLM 在真实编程场景中的补全能力与基准配套使用。与基准配套的是基于抽象语法树AST的多级语法掩码方法不是随机挖掉几行而是按代码的逻辑单元语句 statement、表达式 expression、函数 function/block有策略地掩码从而让评测任务覆盖不同粒度的补全难度。从源码看这一思想在 prepare_multi_level_completion 中得到了完整实现下文详述。数据下载与目录结构获取 ExecRepoBench 数据集README 给出了基于 Hugging Face Git LFS 的下载方式git lfs install git clone https://huggingface.co/datasets/CSJianYang/ExecRepoBench数据集通过 Hugging Face 分发因此需要先安装并启用 Git LFS。下载完成后建议将数据目录与本仓库的评测脚本配合使用本仓库的评测脚本默认从./ExecRepoBench、./repos/、./test_set/等相对路径读取仓库与测试集见下文各脚本的默认参数实际操作时请按需将数据集软链或拷贝到对应位置或通过命令行参数显式指定路径。评测脚本目录速览本仓库中 ExecRepoBench 的完整评测实现位于qwencoder-eval/base/benchmarks/ExecRepoBench/核心文件与职责如下文件职责create_test_repo.py测试仓库环境创建、测试数据构造、正确性验证四种 action 入口eval.sh一键评测入口先生成再评估eval_models.sh带默认参数的评测调用示例eval.pyvLLM 推理生成 正确性/编辑相似度评估utils/prompt_template.py各模型家族的 FIM 提示模板utils/utils.py语言符号表、BM25、相关度排序、编辑相似度等工具create_environment.sh / test_repo_correctness.sh单仓库环境创建与正确性验证示例环境准备Miniconda 与测试仓库依赖隔离ExecRepoBench 的正确性评估需要在隔离的 Python 环境中运行每个被测仓库的测试套件因此环境准备是整个流程的第一步。README 给出的步骤为wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装 Miniconda 后通过 create_test_repo.py 的prepare_environmentsaction 批量创建环境export PATH./miniconda3/envs/vllm/bin/:$PATH python create_test_repo.py --action prepare_environments从 prepare_test_repo_environment 的实现可以看到它实际做了四件事遍历repo_root_path默认./repos/下每个仓库跳过build目录与点开头目录为每个仓库创建独立的 conda 环境conda create -p {env_dir}/envs/repo_{repo_name} python3.9 -y依次执行pip install -r requirements.txt若存在与pip install -e .安装仓库本身及其依赖统一安装评测依赖pytest pytest-cov pytest-benchmark coincidence cssutils docutils openpyxl hypothesis pycodestyle。create_environment.sh 给出了单仓库markdown-it-py的等价手动流程方便调试单个环境。每个仓库一个独立环境的隔离设计保证了某个仓库的依赖不会污染其他仓库的测试结果也避免了评测环境错误被误判为模型补全错误。验证评测环境环境创建完成后用以下命令验证所有仓库能否真正跑通测试即环境本身是否完整可用export PATH./miniconda3/envs/vllm/bin/:$PATH python create_test_repo.py --action verify_all_repo_correctness该 action 对应 evaluate_all_correctness读取test_set/test.jsonlground truth 掩码样本逐条执行还原中间代码 运行仓库测试统计 pass1。如果某仓库环境缺失依赖或仓库本身无法安装此步会提前暴露问题。此外还提供了output_environmentsaction可将每个仓库环境的pip freeze导出到{env_dir}/repo_requirements/用于复现评测环境。端到端评估eval.sh 一键评测的完整拆解标准评估命令README 给出的核心评估命令如下ROOT_DIR./ExecRepoBench MODEL_NAMEqwen2.5-coder-base-7B MODEL_DIR./qwen/Qwen2.5-Coder-7B INPUT_PATH./test_set/exec_repo_bench.jsonl OUTPUT_PATH./results/${MODEL_NAME}/generation.jsonl WORKERS64 TP1 EXTRA_ARGS-max_context_tokens 8192 -max_tokens 32768 -max_generation_tokens 1024 bash ${ROOT_DIR}/eval.sh ${MODEL_NAME} ${MODEL_DIR} ${INPUT_PATH} ${OUTPUT_PATH} ${WORKERS} ${TP} ${EXTRA_ARGS}其中eval.sh接受 7 个位置参数逐一说明参数含义默认值MODEL_NAME$1模型名称标识用于生成结果目录与提示模板匹配如qwen2.5-coder-base-空MODEL_DIR$2本地模型权重路径Hugging Face 格式含config.json空INPUT_PATH$3测试集 JSONL 路径空OUTPUT_PATH$4生成结果输出路径空WORKERS$5评估阶段并行进程数64TP$6vLLM 张量并行 GPU 数1EXTRA_ARGS$7透传给 eval.py 的额外生成参数空eval.sh 内部的两个阶段查看 eval.sh 源码它本质上是生成 评估两个阶段的封装并用结果文件是否存在作为断点续跑的判据生成阶段若${OUTPUT_PATH}不存在则执行python eval.py \ -model_name ${MODEL_NAME} -model_dir ${MODEL_DIR} \ -input_path ${INPUT_PATH} -output_path ${OUTPUT_PATH} \ -workers ${WORKERS} -generation_only \ -tensor_parallel_size ${TP} ${EXTRA_ARGS}评估阶段若${OUTPUT_PATH}.metric不存在则执行python eval.py \ -model_name ${MODEL_NAME} -model_dir ${MODEL_DIR} \ -input_path ${INPUT_PATH} -output_path ${OUTPUT_PATH} \ -workers ${WORKERS} -evaluation_only这种设计意味着生成结果一旦落盘重复运行脚本不会重复推理评测结果一旦产出也不会重复执行测试非常适合长时评测任务的中断恢复。eval_models.sh 则是把 README 中的示例命令固化为可直接运行的脚本。eval.py 的关键参数parse_args 定义了完整的参数集除eval.sh透传的参数外值得关注的有-context_order {far, close}上下文文件的排列顺序默认close将相关度最高的文件放在最靠近被掩码文件的位置-env_path默认./repo/envs/与-repo_dir默认./repos指向评测环境与仓库源码根目录-max_context_tokens默认 4096跨文件上下文预算-max_generation_tokens默认 512单条补全生成的最大 token 数-max_tokens默认 8192总序列长度上限-verbose打印每条样本的执行细节。generate_samples会读取模型config.json中的max_position_embeddings/n_positions作为模型支持的最大长度若模型上限小于-max_tokens会自动将max_tokens收敛到模型上限并把max_context_tokens设为其一半避免越界eval.py。四种补全任务与 AST 多级掩码机制源码级解析任务类型分布ExecRepoBench 的每个仓库样本按固定比例混合四类补全任务这一逻辑在 create_samples 中体现每仓库 100 个样本i从 0 到 99样本序号任务类型掩码方式说明i 3Random Single-line Completion随机掩 1 行单行级补全最简单3 ≤ i 6Random Multi-line Completion随机掩 ≤10 行连续多行补全6 ≤ i 9Random Span Completion随机掩 ≤30 字符片段级补全粒度最细i ≥ 9Grammar-based Completion基于 AST 掩码按逻辑单元block/statement/expression掩码create_prefix_suffix_codecreate_test_repo.py实现了前三种随机掩码随机行掩码与随机字符掩码都会做边界处理保证 prefix/suffix 的换行格式正确。生成的样本字段结构为repo_name、file_name、prefix_code、middle_code、suffix_code、context_code仓库内其他文件的完整内容以及fill_type。多级语法掩码从 AST 到补全任务第四类Grammar-based Completion是 ExecRepoBench 的方法核心实现在 prepare_multi_level_completion用 tree-sitter 解析被掩码文件得到 AST遍历 AST 收集 10 类节点import、comment、return 语句、if 语句、for 语句、while 语句、class 定义、function 定义、赋值语句、表达式语句按配置的采样比例随机选择一类节点如IF_STATEMENT_TYPE: 0.15、FOR_STATEMENT_TYPE: 0.15、IMPORT_TYPE: 0.1、FUNCTION_TYPE: 0.1、COMMENT_TYPE: 0.05等再从该类节点中随机挑一个作为掩码候选80% 概率直接掩整个节点若节点跨行过多10 行或位于文件边界则退化为掩节点内部的某个子节点依据节点的字节区间start_byte/end_byte切出 prefix/middle/suffix 三段。随后 create_samples 通过NODE_TYPE2LEVEL映射将 tree-sitter 节点类型归为三个逻辑层级class_definition/function_definition/if_statement/for_statement/while_statement归为blockimport_statement/return_statement归为statementassignment/expression_statement/identifier/attribute等归为expression最终形成grammar-based: block、grammar-based: statement、grammar-based: expression三类带难度的任务标签。树节点遍历依赖 tree-sitter 的游标接口实现见 traverse_tree。各语言的 AST 节点类型映射集中在 utils.py 的 language_symbols覆盖 Python、Java、C、C#、TypeScript、JavaScript、PHP例如 Python 的if_statement对应IF_STATEMENT_TYPEC 的preproc_include对应IMPORT_TYPE。这意味着多级掩码方法在原理上可推广到多语言而当前基准版本落地在 Python 仓库上。样本过滤规则为保证任务质量create_samples 会对生成的中间代码做过滤长度需大于 10 字符且小于 512 字符、不能与已有样本重复、不能包含#避免掩码注释行。同时在 prepare_test_repo_data 中通过is_valid_file排除tests/、docs/、build/目录以及setup.py、evaluate_repo.py等文件确保只有业务源码参与任务构造。跨文件上下文组织相关度排序与长度预算仓库级补全的关键在于如何把仓库上下文塞进有限的模型窗口。ExecRepoBench 的上下文组织分三步相关度打分utils.get_relevance 结合两类信号为每个仓库文件打分——(a)import 依赖解析被掩码代码的 import 语句见 extract_imports凡是定义了这些模块的文件获得加分过滤掉已安装的第三方包用 is_installed_package 判断(b)BM25 词法相似度用 BM25 实现k11.5b0.75计算每个上下文文件与被掩码代码的相似度并归一化。两者相加得到最终相关度。按相关度排序create_samples中对context_code按相关度降序排列create_test_repo.py并在推理时以-context_order close将相关度最高的文件放在最靠近被掩码文件的位置eval.py模仿人类开发者参考最相关文件的习惯。token 预算分配在 get_prompt 中先按-max_context_tokens预算依次填入上下文文件超预算的文件从右侧截断随后在max_tokens - max_generation_tokens - max_context_tokens的剩余预算内把被掩码文件的前缀从左侧截断、后缀从右侧截断各占一半。截断工具 truncate_prompt 基于 tokenizer 实现。提示模板面向不同模型家族的 FIM 格式适配由于 ExecRepoBench 用于评测多种开源代码模型get_prompt 根据model_name自动选择对应家族的 FIM 模板模板定义集中在 prompt_template.py模型家族匹配关键字模板形式Qwen2.5-Coderbaseqwen2.5-coder-base-\|repo_name\|\|file_sep\|上下文 {context}\|fim_prefix\|{prefix}\|fim_suffix\|{suffix}\|fim_middle\|CodeQwen1.5 / StarCodercodeqwen1.5-base/starcoder-repo_name/file_sep上下文 fim_prefix/fim_suffix/fim_middleStarCoder2starcoder2-## 文件标题式上下文 suffix 逐行加#注释前缀DeepSeek-Coderdeepseek-coder#文件标题式上下文 tool▁calls▁begin/tool▁call▁begin/tool▁call▁end模板指令模型如qwen2.5-coder-Cqwen2.5-coder-Cchat 模板REPO_COMPLETE_TEMPLATESYSTEM_PROMPT经apply_chat_template格式化CodeLLaMA / Granite / OpenCoder / Codestral / CodeGeeX / Yi-Coder / CodeGemma各自前缀## 文件标题式上下文 suffix 注释化的续写式 prompt其中 Qwen2.5-Coder 的仓库级 FIM 格式会在上下文部分注入|repo_name|与|file_sep|标记让模型显式感知仓库边界codeqwen-base还会为生成阶段设置file_sep作为停止符eval.py防止模型继续生成到下一个文件。生成与评估vLLM 推理、pass1 与编辑相似度推理生成generate_samples 使用 vLLM 批量推理SamplingParams(temperature0.0, top_p0.95, max_tokensargs.max_generation_tokens)即贪心解码temperature0 保证确定性。vLLM 引擎通过worker_use_rayTrue启动tensor_parallel_size支持多 GPU 张量并行。每条样本生成结果以generated_middle_code字段写回并落盘为 JSONL。正确性评估评估阶段 的核心是evaluate_correctness将prefix_code generated_middle_code suffix_code重组为完整文件把仓库源码拷贝到临时目录copy_src_to_dest用生成的代码覆盖被掩码文件避免污染原始仓库切换到该仓库的隔离 conda 环境{env_path}/repo_{repo_name}/bin运行python evaluate_repo.py超时上限 240 秒返回码为 0 记 1.0 分否则记 0.0 分并记录 stderr超时同样记 0 分并注明原因。并行评估通过multi_tasks_from_objsutils.py以-workers个进程分块执行-chunk_size控制每个 worker 处理的样本数。指标输出最终在{OUTPUT_PATH}.metrics中输出pass1正确还原通过仓库测试的样本占比esedit similarity基于 fuzzywuzzy 的fuzz.ratiocal_edit_sim对去除注释与空行的生成代码与 ground truth 计算编辑相似度衡量即使测试未通过补全内容与参考答案的贴近程度按fill_type分组的细分指标Random Single-line/Multi-line/Span与grammar-based: expression/statement/block各自的 pass1 与 es并汇总生成 LaTeX 表格字符串便于论文结果呈现eval.py。评测流程小结与注意事项将整条链路串起来一次完整的 ExecRepoBench 评测分为四步下载数据git lfs install git clone拉取数据集安装 Miniconda 并准备环境create_test_repo.py --action prepare_environments为每个仓库创建隔离 conda 环境验证环境create_test_repo.py --action verify_all_repo_correctness确认所有仓库测试可运行评测模型按 README 的 7 参数命令调用eval.sh得到generation.jsonl、generation.jsonl.results与generation.jsonl.metrics。实操中需要注意eval.sh默认从./ExecRepoBench、./qwen/、./test_set/等相对路径取数运行前请将数据布局对齐脚本预期prepare_environments要求先激活 vLLM 所在环境export PATH./miniconda3/envs/vllm/bin/:$PATH评估阶段依赖每个仓库可安装且测试可运行verify_all_repo_correctness是降低误判率的必要前置步骤生成阶段使用贪心解码若要复现论文中的多次采样请自行调整SamplingParams。引用若在你的研究或工程中使用了 ExecRepoBench 数据与方法请按 README 的 Citation 引用原始论文article{yang2024execrepobench, title{ExecRepoBench: Multi-level Executable Code Completion Evaluation}, author{Yang, Jian and Zhang, Jiajun and Yang, Jiaxi and Jin, Ke and Zhang, Lei and Peng, Qiyao and Deng, Ken and Miao, Yibo and Liu, Tianyu and Cui, Zeyu and others}, journal{arXiv preprint arXiv:2412.11990}, year{2024} }本篇指南对应的可运行脚本与全部源码证据均位于本仓库 qwencoder-eval/base/benchmarks/ExecRepoBench/ 目录可直接对照阅读与复现。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Qwen3-Coder 评测实践：ExecRepoBench 仓库级代码补全基准的环境搭建、多级掩码机制与端到端评估指南
Qwen3-Coder 评测实践ExecRepoBench 仓库级代码补全基准的环境搭建、多级掩码机制与端到端评估指南【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-CoderExecRepoBench 是面向真实软件开发场景的仓库级repository-level代码补全基准它从活跃的 Python 仓库中抽取 1.2K 个样本并要求模型在跨文件依赖上下文中完成被掩码的代码片段同时配套 Repo-Instruct 指令语料以提升开源大语言模型的代码补全能力。本文以 ExecRepoBench README 为骨架结合 qwencoder-eval 评测目录下的真实实现create_test_repo.py、eval.py、utils.py 等完整讲解数据下载、评测环境准备、四类补全任务的构造原理以及基于 vLLM 的生成与 pass1/编辑相似度评估全流程。读完本文你将能够在本仓库中复现 ExecRepoBench 的完整评测链路并理解其 AST 多级掩码与跨文件上下文组织的底层设计。ExecRepoBench 是什么仓库级代码补全评测的核心思想传统代码补全基准如 HumanEval 的 FIM 变体通常在单文件内构造任务而真实开发中一个函数往往依赖同仓库其他模块中定义的类、工具函数与配置。ExecRepoBench 的核心目标正是填补这一空白它以多文件协作、存在复杂跨文件依赖的活跃 Python 仓库为素材构建前缀 被掩码片段 后缀的补全样本让模型在参考了仓库其他文件内容后才能正确恢复被掩码的代码。根据 README 的 Dataset Summary该工作同时贡献了两样东西ExecRepoBench 基准包含 1.2K 条来自活跃 Python 仓库的样本用于评测仓库级代码补全Repo-Instruct 指令语料用于改善开源 LLM 在真实编程场景中的补全能力与基准配套使用。与基准配套的是基于抽象语法树AST的多级语法掩码方法不是随机挖掉几行而是按代码的逻辑单元语句 statement、表达式 expression、函数 function/block有策略地掩码从而让评测任务覆盖不同粒度的补全难度。从源码看这一思想在 prepare_multi_level_completion 中得到了完整实现下文详述。数据下载与目录结构获取 ExecRepoBench 数据集README 给出了基于 Hugging Face Git LFS 的下载方式git lfs install git clone https://huggingface.co/datasets/CSJianYang/ExecRepoBench数据集通过 Hugging Face 分发因此需要先安装并启用 Git LFS。下载完成后建议将数据目录与本仓库的评测脚本配合使用本仓库的评测脚本默认从./ExecRepoBench、./repos/、./test_set/等相对路径读取仓库与测试集见下文各脚本的默认参数实际操作时请按需将数据集软链或拷贝到对应位置或通过命令行参数显式指定路径。评测脚本目录速览本仓库中 ExecRepoBench 的完整评测实现位于qwencoder-eval/base/benchmarks/ExecRepoBench/核心文件与职责如下文件职责create_test_repo.py测试仓库环境创建、测试数据构造、正确性验证四种 action 入口eval.sh一键评测入口先生成再评估eval_models.sh带默认参数的评测调用示例eval.pyvLLM 推理生成 正确性/编辑相似度评估utils/prompt_template.py各模型家族的 FIM 提示模板utils/utils.py语言符号表、BM25、相关度排序、编辑相似度等工具create_environment.sh / test_repo_correctness.sh单仓库环境创建与正确性验证示例环境准备Miniconda 与测试仓库依赖隔离ExecRepoBench 的正确性评估需要在隔离的 Python 环境中运行每个被测仓库的测试套件因此环境准备是整个流程的第一步。README 给出的步骤为wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装 Miniconda 后通过 create_test_repo.py 的prepare_environmentsaction 批量创建环境export PATH./miniconda3/envs/vllm/bin/:$PATH python create_test_repo.py --action prepare_environments从 prepare_test_repo_environment 的实现可以看到它实际做了四件事遍历repo_root_path默认./repos/下每个仓库跳过build目录与点开头目录为每个仓库创建独立的 conda 环境conda create -p {env_dir}/envs/repo_{repo_name} python3.9 -y依次执行pip install -r requirements.txt若存在与pip install -e .安装仓库本身及其依赖统一安装评测依赖pytest pytest-cov pytest-benchmark coincidence cssutils docutils openpyxl hypothesis pycodestyle。create_environment.sh 给出了单仓库markdown-it-py的等价手动流程方便调试单个环境。每个仓库一个独立环境的隔离设计保证了某个仓库的依赖不会污染其他仓库的测试结果也避免了评测环境错误被误判为模型补全错误。验证评测环境环境创建完成后用以下命令验证所有仓库能否真正跑通测试即环境本身是否完整可用export PATH./miniconda3/envs/vllm/bin/:$PATH python create_test_repo.py --action verify_all_repo_correctness该 action 对应 evaluate_all_correctness读取test_set/test.jsonlground truth 掩码样本逐条执行还原中间代码 运行仓库测试统计 pass1。如果某仓库环境缺失依赖或仓库本身无法安装此步会提前暴露问题。此外还提供了output_environmentsaction可将每个仓库环境的pip freeze导出到{env_dir}/repo_requirements/用于复现评测环境。端到端评估eval.sh 一键评测的完整拆解标准评估命令README 给出的核心评估命令如下ROOT_DIR./ExecRepoBench MODEL_NAMEqwen2.5-coder-base-7B MODEL_DIR./qwen/Qwen2.5-Coder-7B INPUT_PATH./test_set/exec_repo_bench.jsonl OUTPUT_PATH./results/${MODEL_NAME}/generation.jsonl WORKERS64 TP1 EXTRA_ARGS-max_context_tokens 8192 -max_tokens 32768 -max_generation_tokens 1024 bash ${ROOT_DIR}/eval.sh ${MODEL_NAME} ${MODEL_DIR} ${INPUT_PATH} ${OUTPUT_PATH} ${WORKERS} ${TP} ${EXTRA_ARGS}其中eval.sh接受 7 个位置参数逐一说明参数含义默认值MODEL_NAME$1模型名称标识用于生成结果目录与提示模板匹配如qwen2.5-coder-base-空MODEL_DIR$2本地模型权重路径Hugging Face 格式含config.json空INPUT_PATH$3测试集 JSONL 路径空OUTPUT_PATH$4生成结果输出路径空WORKERS$5评估阶段并行进程数64TP$6vLLM 张量并行 GPU 数1EXTRA_ARGS$7透传给 eval.py 的额外生成参数空eval.sh 内部的两个阶段查看 eval.sh 源码它本质上是生成 评估两个阶段的封装并用结果文件是否存在作为断点续跑的判据生成阶段若${OUTPUT_PATH}不存在则执行python eval.py \ -model_name ${MODEL_NAME} -model_dir ${MODEL_DIR} \ -input_path ${INPUT_PATH} -output_path ${OUTPUT_PATH} \ -workers ${WORKERS} -generation_only \ -tensor_parallel_size ${TP} ${EXTRA_ARGS}评估阶段若${OUTPUT_PATH}.metric不存在则执行python eval.py \ -model_name ${MODEL_NAME} -model_dir ${MODEL_DIR} \ -input_path ${INPUT_PATH} -output_path ${OUTPUT_PATH} \ -workers ${WORKERS} -evaluation_only这种设计意味着生成结果一旦落盘重复运行脚本不会重复推理评测结果一旦产出也不会重复执行测试非常适合长时评测任务的中断恢复。eval_models.sh 则是把 README 中的示例命令固化为可直接运行的脚本。eval.py 的关键参数parse_args 定义了完整的参数集除eval.sh透传的参数外值得关注的有-context_order {far, close}上下文文件的排列顺序默认close将相关度最高的文件放在最靠近被掩码文件的位置-env_path默认./repo/envs/与-repo_dir默认./repos指向评测环境与仓库源码根目录-max_context_tokens默认 4096跨文件上下文预算-max_generation_tokens默认 512单条补全生成的最大 token 数-max_tokens默认 8192总序列长度上限-verbose打印每条样本的执行细节。generate_samples会读取模型config.json中的max_position_embeddings/n_positions作为模型支持的最大长度若模型上限小于-max_tokens会自动将max_tokens收敛到模型上限并把max_context_tokens设为其一半避免越界eval.py。四种补全任务与 AST 多级掩码机制源码级解析任务类型分布ExecRepoBench 的每个仓库样本按固定比例混合四类补全任务这一逻辑在 create_samples 中体现每仓库 100 个样本i从 0 到 99样本序号任务类型掩码方式说明i 3Random Single-line Completion随机掩 1 行单行级补全最简单3 ≤ i 6Random Multi-line Completion随机掩 ≤10 行连续多行补全6 ≤ i 9Random Span Completion随机掩 ≤30 字符片段级补全粒度最细i ≥ 9Grammar-based Completion基于 AST 掩码按逻辑单元block/statement/expression掩码create_prefix_suffix_codecreate_test_repo.py实现了前三种随机掩码随机行掩码与随机字符掩码都会做边界处理保证 prefix/suffix 的换行格式正确。生成的样本字段结构为repo_name、file_name、prefix_code、middle_code、suffix_code、context_code仓库内其他文件的完整内容以及fill_type。多级语法掩码从 AST 到补全任务第四类Grammar-based Completion是 ExecRepoBench 的方法核心实现在 prepare_multi_level_completion用 tree-sitter 解析被掩码文件得到 AST遍历 AST 收集 10 类节点import、comment、return 语句、if 语句、for 语句、while 语句、class 定义、function 定义、赋值语句、表达式语句按配置的采样比例随机选择一类节点如IF_STATEMENT_TYPE: 0.15、FOR_STATEMENT_TYPE: 0.15、IMPORT_TYPE: 0.1、FUNCTION_TYPE: 0.1、COMMENT_TYPE: 0.05等再从该类节点中随机挑一个作为掩码候选80% 概率直接掩整个节点若节点跨行过多10 行或位于文件边界则退化为掩节点内部的某个子节点依据节点的字节区间start_byte/end_byte切出 prefix/middle/suffix 三段。随后 create_samples 通过NODE_TYPE2LEVEL映射将 tree-sitter 节点类型归为三个逻辑层级class_definition/function_definition/if_statement/for_statement/while_statement归为blockimport_statement/return_statement归为statementassignment/expression_statement/identifier/attribute等归为expression最终形成grammar-based: block、grammar-based: statement、grammar-based: expression三类带难度的任务标签。树节点遍历依赖 tree-sitter 的游标接口实现见 traverse_tree。各语言的 AST 节点类型映射集中在 utils.py 的 language_symbols覆盖 Python、Java、C、C#、TypeScript、JavaScript、PHP例如 Python 的if_statement对应IF_STATEMENT_TYPEC 的preproc_include对应IMPORT_TYPE。这意味着多级掩码方法在原理上可推广到多语言而当前基准版本落地在 Python 仓库上。样本过滤规则为保证任务质量create_samples 会对生成的中间代码做过滤长度需大于 10 字符且小于 512 字符、不能与已有样本重复、不能包含#避免掩码注释行。同时在 prepare_test_repo_data 中通过is_valid_file排除tests/、docs/、build/目录以及setup.py、evaluate_repo.py等文件确保只有业务源码参与任务构造。跨文件上下文组织相关度排序与长度预算仓库级补全的关键在于如何把仓库上下文塞进有限的模型窗口。ExecRepoBench 的上下文组织分三步相关度打分utils.get_relevance 结合两类信号为每个仓库文件打分——(a)import 依赖解析被掩码代码的 import 语句见 extract_imports凡是定义了这些模块的文件获得加分过滤掉已安装的第三方包用 is_installed_package 判断(b)BM25 词法相似度用 BM25 实现k11.5b0.75计算每个上下文文件与被掩码代码的相似度并归一化。两者相加得到最终相关度。按相关度排序create_samples中对context_code按相关度降序排列create_test_repo.py并在推理时以-context_order close将相关度最高的文件放在最靠近被掩码文件的位置eval.py模仿人类开发者参考最相关文件的习惯。token 预算分配在 get_prompt 中先按-max_context_tokens预算依次填入上下文文件超预算的文件从右侧截断随后在max_tokens - max_generation_tokens - max_context_tokens的剩余预算内把被掩码文件的前缀从左侧截断、后缀从右侧截断各占一半。截断工具 truncate_prompt 基于 tokenizer 实现。提示模板面向不同模型家族的 FIM 格式适配由于 ExecRepoBench 用于评测多种开源代码模型get_prompt 根据model_name自动选择对应家族的 FIM 模板模板定义集中在 prompt_template.py模型家族匹配关键字模板形式Qwen2.5-Coderbaseqwen2.5-coder-base-\|repo_name\|\|file_sep\|上下文 {context}\|fim_prefix\|{prefix}\|fim_suffix\|{suffix}\|fim_middle\|CodeQwen1.5 / StarCodercodeqwen1.5-base/starcoder-repo_name/file_sep上下文 fim_prefix/fim_suffix/fim_middleStarCoder2starcoder2-## 文件标题式上下文 suffix 逐行加#注释前缀DeepSeek-Coderdeepseek-coder#文件标题式上下文 tool▁calls▁begin/tool▁call▁begin/tool▁call▁end模板指令模型如qwen2.5-coder-Cqwen2.5-coder-Cchat 模板REPO_COMPLETE_TEMPLATESYSTEM_PROMPT经apply_chat_template格式化CodeLLaMA / Granite / OpenCoder / Codestral / CodeGeeX / Yi-Coder / CodeGemma各自前缀## 文件标题式上下文 suffix 注释化的续写式 prompt其中 Qwen2.5-Coder 的仓库级 FIM 格式会在上下文部分注入|repo_name|与|file_sep|标记让模型显式感知仓库边界codeqwen-base还会为生成阶段设置file_sep作为停止符eval.py防止模型继续生成到下一个文件。生成与评估vLLM 推理、pass1 与编辑相似度推理生成generate_samples 使用 vLLM 批量推理SamplingParams(temperature0.0, top_p0.95, max_tokensargs.max_generation_tokens)即贪心解码temperature0 保证确定性。vLLM 引擎通过worker_use_rayTrue启动tensor_parallel_size支持多 GPU 张量并行。每条样本生成结果以generated_middle_code字段写回并落盘为 JSONL。正确性评估评估阶段 的核心是evaluate_correctness将prefix_code generated_middle_code suffix_code重组为完整文件把仓库源码拷贝到临时目录copy_src_to_dest用生成的代码覆盖被掩码文件避免污染原始仓库切换到该仓库的隔离 conda 环境{env_path}/repo_{repo_name}/bin运行python evaluate_repo.py超时上限 240 秒返回码为 0 记 1.0 分否则记 0.0 分并记录 stderr超时同样记 0 分并注明原因。并行评估通过multi_tasks_from_objsutils.py以-workers个进程分块执行-chunk_size控制每个 worker 处理的样本数。指标输出最终在{OUTPUT_PATH}.metrics中输出pass1正确还原通过仓库测试的样本占比esedit similarity基于 fuzzywuzzy 的fuzz.ratiocal_edit_sim对去除注释与空行的生成代码与 ground truth 计算编辑相似度衡量即使测试未通过补全内容与参考答案的贴近程度按fill_type分组的细分指标Random Single-line/Multi-line/Span与grammar-based: expression/statement/block各自的 pass1 与 es并汇总生成 LaTeX 表格字符串便于论文结果呈现eval.py。评测流程小结与注意事项将整条链路串起来一次完整的 ExecRepoBench 评测分为四步下载数据git lfs install git clone拉取数据集安装 Miniconda 并准备环境create_test_repo.py --action prepare_environments为每个仓库创建隔离 conda 环境验证环境create_test_repo.py --action verify_all_repo_correctness确认所有仓库测试可运行评测模型按 README 的 7 参数命令调用eval.sh得到generation.jsonl、generation.jsonl.results与generation.jsonl.metrics。实操中需要注意eval.sh默认从./ExecRepoBench、./qwen/、./test_set/等相对路径取数运行前请将数据布局对齐脚本预期prepare_environments要求先激活 vLLM 所在环境export PATH./miniconda3/envs/vllm/bin/:$PATH评估阶段依赖每个仓库可安装且测试可运行verify_all_repo_correctness是降低误判率的必要前置步骤生成阶段使用贪心解码若要复现论文中的多次采样请自行调整SamplingParams。引用若在你的研究或工程中使用了 ExecRepoBench 数据与方法请按 README 的 Citation 引用原始论文article{yang2024execrepobench, title{ExecRepoBench: Multi-level Executable Code Completion Evaluation}, author{Yang, Jian and Zhang, Jiajun and Yang, Jiaxi and Jin, Ke and Zhang, Lei and Peng, Qiyao and Deng, Ken and Miao, Yibo and Liu, Tianyu and Cui, Zeyu and others}, journal{arXiv preprint arXiv:2412.11990}, year{2024} }本篇指南对应的可运行脚本与全部源码证据均位于本仓库 qwencoder-eval/base/benchmarks/ExecRepoBench/ 目录可直接对照阅读与复现。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考