项目 Benchmark 是怎样构建的，使用哪些指标？

核心回答

项目 Benchmark 是一套能重复运行的业务任务、初始环境、评分规则和执行记录，不是随便收集一些问题再让模型打分。我会先确定项目要完成哪些任务，再从真实请求和失败案例分层取样，为每条任务写清成功条件，固定模型、工具、数据版本与运行预算，最后用相同口径比较基线和新方案。

指标以端到端任务成功率为主，再结合任务特点看事实正确性、必要工具及参数、异常恢复、越权操作，以及延迟和费用。比如代码修复要看缺陷是否消除且原有功能未回归；问答要看证据是否支持答案；建单要看最终记录是否正确。

一条任务需要保存什么

除用户输入外，还要保存该任务依赖的上下文、数据快照、权限和初始状态、允许使用的工具及成功判据。多轮任务要包含对话条件，而不是只截取最后一句。

评分标准可以是参考答案、关键事实、结果文件、数据库断言或可执行测试，不必强行规定唯一措辞。建立一份能通过评分的参考结果，可以反过来检查任务是否可解、评分器是否把合法答案误判为失败。

数据怎样构建与划分

真实日志覆盖常见业务，历史失败案例覆盖薄弱点，人工构造补足罕见但影响大的条件，例如权限变化、工具超时、信息不足和相互矛盾的上下文。合成数据用于补充表达和组合，采用前仍要检查题目与预期是否成立。

先去重，再按任务来源、时间或相近问题分组划分开发集和保留测试集，避免同一任务的改写版本分别进入两边。开发集用于调整Prompt和流程，保留集用于判断能否泛化。既看整体结果，也单独看任务类型、难度与高影响失败，防止均值掩盖问题。

样本量取决于覆盖范围、结果波动和希望识别的差异，没有适合所有项目的固定条数。可以先用一组代表任务跑通流程，再随着真实失败和新能力扩充；调整过数据或评分规则后应保留版本，不能把不同口径的百分比直接比较。

怎样得到可信的对比

每次运行从相同初始状态开始，记录模型与Prompt版本、工具实现、检索数据、预算和评分器版本。隔离上次运行遗留的文件、缓存与业务记录，外部服务波动则分别记录，避免把环境故障全算成模型能力下降。

先运行基线，再用同一组任务比较新版本。对波动明显的任务安排多次尝试，报告成功次数和运行次数；若允许重试，重试次数和费用也纳入同一预算。能力评测关注还能解决哪些难题，回归评测则保护已经解决的任务，两套结果可以分别报告。

指标怎样解释

任务成功率是满足完整成功条件的运行数除以有效运行总数；部分步骤得分帮助诊断，不能代替整体完成率。延迟看端到端分布和尾延迟，成本包含失败与重试，安全指标同时看越权漏检与正常请求误拒。

开放性结果可采用明确评分维度的模型裁判，并用人工标注样本校准；可程序验证的内容优先程序检查。失败后保留任务ID、轨迹和分项结果，才能知道改进来自哪一步，而不只是看到一个总分变化。

常见追问

能直接拿公开榜单当项目Benchmark吗？ 公开基准适合了解通用能力和选择初始方案，但项目工具、数据和验收条件不同，仍需业务任务集。

测试集是不是越难越好？ 一味堆难例会偏离真实流量，一味收集容易任务又看不到能力差异。应保留业务分布结果，并单列挑战集和关键风险集。

参考资料