智能编程模型基准评测的公平性设计与实践

一、为什么智能编程模型评测不能只看一个分数

智能编程模型的能力评测看似简单：准备一组开发任务，让模型生成代码，再统计通过测试的任务比例。但在真实实验中，最终结果不仅取决于模型本身，还会受到执行框架、提示词组织方式、上下文管理、工具调用策略、运行资源、任务时限和重试规则等因素影响。

例如，同一个模型可能通过不同的智能编程工具完成任务。某些执行框架会自动读取代码仓库结构、压缩历史上下文、修复格式错误，甚至在测试失败后主动选择相关文件；另一些框架则只负责转发模型输出。如果不记录这些差异，评测得到的实际上是“模型、工具与工程配置的综合成绩”，而不是纯粹的模型能力。

因此，一套可信的评测方案至少要回答以下问题：

1. 每个模型使用什么执行环境？
2. 所有模型是否面对完全相同的任务和测试？
3. 时间、计算资源和调用次数是否受到一致约束？
4. 模型可以运行多少次测试，是否允许反复修改？
5. 最终分数是单次结果、三次平均值，还是多次尝试中取最好结果？
6. 超时、环境故障和答案错误分别如何处理？
7. 其他团队能否根据记录复现实验？

只有这些条件明确，分数之间才具备基本的可比性。

二、先明确评测对象：模型能力还是完整系统能力

智能编程评测通常分为两种目标。

1. 模型级评测

模型级评测希望尽量隔离外部工具差异，重点观察模型的代码理解、推理和生成能力。此时应为所有模型提供相同的提示词模板、工具集合、上下文内容和执行逻辑。

这种方法的优点是变量较少，适合进行基础能力研究；缺点是统一框架可能无法发挥不同模型的最佳能力。部分模型更适合结构化工具调用，另一些模型则依赖特定的上下文组织形式。强行使用同一种执行方式，可能造成不公平的能力损失。

2. 系统级评测

系统级评测关注开发者实际能够获得的端到端效果。每个模型可以使用与自身交互特征相适配的原生执行框架，由该框架负责代码检索、文件修改、命令执行和测试反馈。

这种方法更接近真实开发场景，但评测结果代表的是完整智能编程系统，而非单独的基础模型。报告中应明确写出：

本实验衡量模型与其适配执行框架组成的端到端系统能力，结果不能直接解释为基础模型的独立能力。

如果选择原生执行框架，公平性不应被简单理解为“所有模型使用同一个工具”，而应体现为任务、预算、资源和判定标准一致。与此同时，还应补充统一框架下的对照实验，帮助读者区分模型能力与工具增益。

三、统一八小时时限时应明确边界

“每个任务最多运行八小时”只是一个起点。如果计时规则不清晰，不同实验仍可能产生巨大偏差。

1. 建议采用墙钟时间

墙钟时间是从任务开始到任务结束的真实经过时间。它应当包括：

• 模型推理等待时间；
• 文件读取与代码检索时间；
• 依赖安装与构建时间；
• 测试执行时间；
• 工具调用失败后的恢复时间；
• 模型分析错误并修改代码的时间。

如果只统计模型生成内容的时间，而忽略测试和构建过程，就会偏向频繁调用工具、反复执行测试的方案。

2. 明确计时起点和终点

推荐的起点是评测系统将任务描述、初始代码仓库和允许使用的工具交付给执行框架的时刻。终点可以是以下三种情况之一：

1. 模型主动提交最终答案；
2. 全部测试通过并满足结束条件；
3. 达到八小时上限，被系统强制终止。

任务结束后不得继续修改代码，也不能在看到隐藏测试结果后再次提交。

3. 区分任务时限与整场时限

如果任务集包含大量样本，需要说明八小时究竟是：

• 每个任务独立拥有八小时；
• 每个模型完成全部任务的总预算为八小时；
• 单次完整评测运行的总时限为八小时。

这三种规则会产生完全不同的实验结果。技术报告不能只写“默认时限八小时”，而应给出完整定义。

4. 同时限制其他资源

仅限制时间仍可能导致不公平。建议同步控制：

• CPU与内存上限；
• 可用磁盘空间；
• 并发任务数量；
• 网络访问权限；
• 模型调用次数或总输入输出量；
• 单次命令执行时限；
• 单个测试进程的资源上限。

资源限制应由外部调度器强制实施，而不能依赖执行框架自觉遵守。

四、如何正确理解单次成功率与三次运行

单次成功率通常表示：对于任务集合中的每个任务，只考察一次完整生成与执行，最终通过全部判定条件的任务占比。

假设共有 (N) 个任务，第 (i) 个任务的结果为：

[
x_i =
\begin{cases}
1, & \text{任务通过}\
0, & \text{任务失败}
\end{cases}
]

则单次运行的成功率为：

[
S=\frac{1}{N}\sum_{i=1}^{N}x_i
]

由于模型输出、工具选择和修改路径可能具有随机性，单次实验容易受到偶然因素影响。因此，可以进行三次相互独立的完整运行。设三次结果分别为 (S_1、S_2、S_3)，推荐报告平均值：

[
\bar{S}=\frac{S_1+S_2+S_3}{3}
]

同时应公布三次原始结果、标准差或取值范围，而不是只展示平均分。例如，平均值相同的两个系统，一个三次结果非常稳定，另一个波动明显，它们在生产环境中的可靠性并不相同。

必须特别注意：不能把“每个任务尝试三次，只要有一次成功就算通过”称为单次成功率。这样的统计实质上衡量了多次尝试后的至少一次成功概率，会显著提高结果。如果业务确实需要这种指标，应单独命名并与单次成功率并列展示。

五、三次独立运行怎样才算真正独立

三次运行不是简单地连续点击三次开始按钮。为了保证独立性，至少要做到以下几点：

1. 恢复初始代码状态

每次运行都必须从完全相同的代码快照开始。上一次生成的补丁、构建产物、缓存文件和测试日志不得进入下一次实验。

2. 清理执行环境

建议每次任务启动一个隔离环境，并在结束后销毁。隔离内容包括工作目录、进程、临时文件、环境变量和本地缓存。若必须保留依赖缓存以降低安装开销，应保证所有模型使用相同的缓存策略。

3. 固定或记录随机参数

如果系统允许设置随机种子，应记录每次运行的种子。如果底层推理服务无法保证完全确定性，则应如实说明。三次实验可以使用不同种子，但种子分配规则应事先确定，不能在看到结果后选择更有利的组合。

4. 避免跨运行信息泄漏

某次运行得到的隐藏测试反馈、失败原因或人工分析不能提供给后续运行。否则后续结果包含了额外学习信息，不再属于独立重复实验。

六、原生执行框架的公平使用原则

允许不同模型使用各自适配的执行框架，并不意味着可以放弃约束。建议建立一份统一的能力边界清单。

所有执行框架可以被允许执行以下通用操作：

• 读取任务描述和代码文件；
• 搜索符号、文本与目录结构；
• 新建、修改或删除任务工作区内的文件；
• 执行构建、静态检查和公开测试；
• 根据测试输出继续修改代码；
• 在规定时间内提交最终补丁。

同时应统一禁止：

• 访问隐藏测试代码；
• 查询任务的标准答案；
• 从外部网络搜索同一题目的现成补丁；
• 修改评测器或绕过测试逻辑；
• 访问其他模型的运行结果；
• 修改任务工作区之外的系统文件；
• 通过特殊进程保留跨任务状态。

对于执行框架自动完成的操作，也应记录在日志中。自动上下文压缩、代码索引、测试选择和错误恢复都可能影响结果，因此不能将其视为无关紧要的实现细节。

七、任务判定应以隐藏测试为核心

模型在开发过程中可以运行公开测试，但最终成绩应由隔离的隐藏测试决定。否则模型可能通过针对公开样例进行硬编码来获得虚假高分。

一个完整的判定过程通常包括：

1. 检查代码是否能够成功构建；
2. 执行原有回归测试，防止修改破坏既有功能；
3. 执行针对目标需求的隐藏功能测试；
4. 检查超时、异常退出和资源消耗；
5. 必要时进行静态检查或安全检查；
6. 根据预先定义的规则输出通过或失败。

测试必须在模型无法修改的独立环境中执行。不要直接信任模型工作区内的测试脚本，因为模型可能无意或有意改变这些文件。

示意性流程如下：

for each run in three_independent_runs:
    for each task in benchmark_tasks:
        workspace = create_clean_workspace(task.initial_snapshot)
        start_time = current_time()
        result = execute_agent(
            workspace=workspace,
            task_description=task.description,
            time_limit=8_hours,
            resource_policy=common_policy
        )
        patch = export_final_patch(workspace)
        score = run_isolated_hidden_tests(
            initial_snapshot=task.initial_snapshot,
            patch=patch
        )
        save_record(run, task, result, score, start_time)

这里的关键点是：智能编程系统负责生成补丁，独立评测器负责决定补丁是否通过，二者不能共享可被篡改的判定逻辑。

八、不要把所有失败都记成零分后置之不理

从排行榜角度看，失败任务都可以记为零，但从技术分析角度看，失败原因必须分类。建议至少划分为：

• 功能错误：代码能够运行，但行为不符合需求；
• 构建失败：存在语法、依赖或编译问题；
• 回归失败：目标功能可能正确，但破坏了已有功能；
• 执行超时：模型未在规定时间内完成任务；
• 资源超限：内存、磁盘或进程数超过限制；
• 框架异常：执行框架崩溃或无法解析模型输出；
• 基础设施异常：评测节点故障、存储不可用等；
• 规则违规：尝试访问禁止资源或修改评测环境。

其中，模型或执行框架自身导致的异常通常应计为失败；由评测基础设施造成且与参评系统无关的问题，则应将该样本标为无效并重新运行。两者必须通过日志和审计规则加以区分，不能由评测人员凭主观判断决定。

九、建议保留的实验记录

为了让实验具备可审计性，每个任务至少应保存以下信息：

• 任务唯一编号与代码快照摘要；
• 运行开始、结束时间和总耗时；
• 执行框架版本及配置摘要；
• 提示词模板的版本；
• 允许使用的工具列表；
• 每次模型调用的时间与输入输出规模；
• 文件修改记录和最终补丁；
• 执行过的命令及退出状态；
• 公开测试与隐藏测试结果；
• CPU、内存和磁盘使用峰值；
• 超时、重试与异常恢复记录；
• 最终失败分类。

日志中可能包含源代码、密钥或业务数据，因此还需要执行脱敏、访问控制和保存期限管理。可复现并不意味着无条件公开全部原始数据，而是要让授权审计人员能够验证实验流程。

十、评测报告应同时呈现效率和质量

单一成功率无法完整描述智能编程系统。建议在主指标之外补充：

1. 完成耗时中位数：反映典型任务速度；
2. 高分位耗时：观察复杂任务的长尾延迟；
3. 超时比例：判断系统是否经常陷入无效循环；
4. 平均工具调用次数：分析执行策略是否高效；
5. 测试执行次数：观察模型是否依赖反复试错；
6. 补丁规模：识别不必要的大范围修改；
7. 回归失败率：衡量修改的安全性；
8. 三次运行波动：反映结果稳定程度；
9. 任务类型分项成绩：区分修复、重构、功能实现和测试补全能力。

企业用户往往更关心稳定完成任务的成本和时间，而非实验室条件下的最高分。因此，质量、效率、稳定性和资源消耗应联合分析。

十一、常见但容易误导的评测方式

1. 只公布最好的一次结果

从三次运行中选择最高分，会系统性放大随机收益。除非明确将其定义为“最佳运行”，否则不应作为主要成绩。

2. 允许部分系统无限重试

如果一个系统可以不断修改直到通过，而另一个系统只能生成一次，两者的成绩没有可比性。重试次数可以不同，但必须纳入统一的总预算，并在报告中披露。

3. 不区分模型与工具贡献

使用原生框架得到高分后，不能直接断言底层模型一定更强。更严谨的结论应是：该模型与当前执行框架组合在指定评测条件下表现更好。

4. 任务集过于单一

如果任务集中于某一种语言、仓库规模或错误类型，结果只能说明系统在该分布下的能力。报告应披露任务构成，避免将局部成绩泛化为通用开发能力。

5. 评测规则在实验中途变化

修改时限、提示词、测试环境或失败处理规则后，前后结果不能直接合并。所有规则应在实验开始前冻结；若必须修改，应重新执行受影响的全部实验。

十二、形成可复现评测规范的推荐流程

一套较为稳健的实施流程可以概括为：

1. 明确评测目标是模型级能力还是端到端系统能力；
2. 冻结任务集合、初始代码和隐藏测试；
3. 定义统一的八小时时限及资源边界；
4. 为不同模型配置其适配执行框架，同时统一允许和禁止的操作；
5. 对每个任务执行三次独立运行；
6. 每次运行均从干净环境和相同代码快照开始；
7. 使用隔离的隐藏测试判定最终结果；
8. 将三次单次成功率的平均值作为主要统计量，并公开原始结果与波动；
9. 分类分析失败原因、耗时和资源消耗；
10. 保存配置、补丁、命令与测试日志，支持后续审计；
11. 在结论中明确适用范围，不将系统级结果夸大为基础模型的绝对能力。

结语

智能编程模型评测的核心不是生成一个醒目的排行榜，而是建立一套变量清晰、规则一致、过程可审计、结果可复现的方法。统一八小时时限、采用适配模型的原生执行框架以及进行三次独立运行，都可以成为合理设计，但前提是准确说明计时边界、资源限制和指标聚合方式。

尤其需要避免将“三次尝试至少成功一次”与“单次成功率的三次重复实验”混为一谈。前者衡量多次机会下的最终成功可能性，后者用于估计系统一次完成任务的平均能力。只有区分这些概念，并完整披露执行环境和统计方法，评测结果才能真正帮助开发者选择技术方案，也才能为企业落地智能编程能力提供可靠依据。