本文要处理的问题当模型与产品按周迭代时怎么用一套可复用的评估口径判断一次发布是否真的改善了用户的日常任务。一、问题发布会上的能力指标和用户手里的任务不是一套账一场开发者大会可以给出二十项更新覆盖新模型、编程与办公能力、智能体工具以及一项全新产品。发布会结束之后重度用户的反馈却集中在另一处影响每天使用的问题没有消失。这里其实有两套彼此独立的度量。一套是能力指标纸面性能、推理效率、把吞吐量统一折算之后的横向对比。这套指标描述的是上限通常取一批公开任务上的表现。另一套是任务完成率用户当天要交付的东西有没有按时按质做完。它依赖具体的任务集、上下文长度、并发情况以及额度余量。能力指标上涨任务完成率未必跟着动。原因往往不在算力而在任务集被换掉了——新的评测集更容易出分而用户手里那批任务还是原来那一批。同一次更新还会带进另一个变量使用额度。在算力紧张的阶段订阅套餐的新用户注册一度暂停随后可用额度又被收紧。对评估系统来说这意味着历史基线在用户没有做任何操作的情况下发生了变化。如果评估口径不把额度写进去两次发布之间的对比就会失真。用户感知到的变慢有时是模型本身的问题有时只是同样的时间窗里可调用的量变少了。能力指标描述的是上限任务完成率描述的是日常。二、方案任务集、指标、阈值三层分离工程上把评估拆成三层每层只对上一层负责。任务集层固定一批贴近真实交付的任务标注输入、上下文长度与验收标准指标层同时输出质量分、完成耗时、重试次数与额度消耗阈值层为每项指标设定回归边界超出即拦截发布。目录结构release-eval/├── tasks/ # 固定任务集与验收标准│ ├── registry.yaml│ └── fixtures/├── metrics/ # 指标计算│ └── collect.py├── gate/ # 回归阈值与拦截规则│ ├── thresholds.yaml│ └── decide.py└── report/└── render.py评估配置eval:task_set: v3repeats: 3metrics:quality_scorelatency_p50_mslatency_p90_msretry_countquota_usedbaseline: last_releasenormalize:throughput: truecontext_length: truedimensions:task_familycontext_bucketrepeats 这个字段不能省。同一批任务只跑一次得到的是那一瞬间的状态跑三次取分位数才能把机器抖动和真实回归分开。normalize 里的两项同样关键。把吞吐量和上下文长度折算到同一基准之后再比才不至于拿短上下文的成绩去解释长任务的表现。三、指标口径口径不统一的后果是两份看起来都很完整的报告放在一起没法比。| 指标 | 计算方式 | 需要注意的地方 || 质量分 | 固定验收标准下的人工或规则判定 | 判定标准要外置不能写在脚本里 || 完成耗时 | 任务开始到验收通过的时长 | 取分位数均值容易被长尾拉偏 || 重试次数 | 单次任务内的返工轮数 | 与质量分同看单独看会误判 || 额度消耗 | 单个任务消耗的可调用量 | 跨版本对比的前提是任务集不变 || 稳定性 | 同一批任务三次跑分的波动幅度 | 波动过大时先修采集再谈优化 |口径外置成配置文件之后调整口径不再需要改动采集代码历史数据也能按新口径重算。四、验证评估系统的问题往往不是准不准而是稳不稳。同一批任务在同一个版本上连跑三次结果差异过大说明评估本身有问题。checks:name: 采样稳定性rule: stdev(three_runs) / mean(three_runs) 0.10name: 任务集覆盖rule: covered_families configured_familiesname: 额度口径一致rule: all(r.quota_used_unit “token” for r in results)name: 基线可比rule: baseline.task_set current.task_setname: 回归拦截rule: drop(quality_score) 0.02基线可比这一条容易被跳过。任务集一换历史分就不再有参照意义此时应当重建基线而不是拿新旧数字直接相减。五、踩坑记录坑一用单次跑分代表一个版本。 只看一次评估就下结论误区在于波动被当成了信号。正确做法是固定任务集多次采样后取分位数。坑二跨任务族直接比耗时。 不同任务族的上下文长度和调用次数差异很大原值直接比较会得出误导性结论。可比的前提是同一任务族、同一时间窗、同一口径。坑三把额度消耗排除在指标之外。 额度收紧之后同样的任务要消耗更多轮次才能完成如果报告里只有耗时没有额度回归定位就会找错方向。坑四把发布清单当验收清单。 清单记录的是做出来的功能验收记录的是任务通过率。两者混用会出现功能全在、体验没变的局面。反例只看能力指标就放行gate {“score”: bench.score, “pass”: bench.score baseline.score}正例能力指标与任务完成率同时进闸门runs repeat_eval(task_set“v3”, repeats3)gate {“quality_p50”: percentile(runs, “quality_score”, 50),“latency_p90”: percentile(runs, “latency_p50_ms”, 90),“quota_delta”: delta(runs, “quota_used”, baseline“last_release”),“pass”: percentile(runs, “quality_score”, 50) baseline.quality_p50 - 0.02,}部署时还有一处细节评估入口的地址用 your-domain.test 这类占位域名统一管理按环境分发到不同执行节点否则单点故障会同时污染多个版本的样本。六、小结从发布会上的能力指标到用户手里的任务完成率中间隔着一整套评估口径。评估系统的价值不在于把分数刷多高而在于让不同版本、不同任务族、不同额度窗口的结果能够放在同一张表里比较。顺序也应当反过来先固定口径再谈优化。