学习笔记 | 11 月 5 日 · 怎么证明它变好了
- 2026-11-07 03:53:12
「感觉这次好多了」不是结论
前五期讲完了结构与上线，剩下最后一块：怎么证明一次改动是变好还是变坏。
大多数人靠感觉：试几个例子，觉得顺了，就发布。这条路有三个坑：
- 只看个例：拿一个刚调好的例子验证，当然通过。
- 只测简单任务：复杂的、需要澄清的、注定失败的那批，从来没进过测试。
- 基线不一致：两次对比，温度不同、工具版本不同、连任务都换了。
结论就是：没有固定任务集的改动，本质上是在赌。
今天讲三件事：怎么定指标、怎么建任务集、怎么判断掉点归谁。
先定指标，别急着跑
指标至少分三层，混在一起看会得出错误结论：
- 单步：给固定上下文，它选的工具和参数对不对。最便宜，最能定位。
- 任务：端到端成功率、平均步数、平均成本。
- 业务：用户有没有采纳、有没有返工、有没有投诉。
这里有个常被忽略的点：看分布，不要只看平均。
平均成功率 80% 听起来不错，但如果失败的 20% 全部集中在「带附件的邮件」这一类，那这个 Agent 对这类用户就是不可用的。所以报表里至少要有三样：成功率、P95 延迟、失败任务的类型分布。
还有一个细节：单次成功不代表稳定。同一个任务跑五次，成功几次？这个数字（pass@5 或 5 次取多数）比单次结果诚实得多。
二十条真实任务，胜过两百条编的
任务集最容易犯的错，是自己坐在那编。编出来的任务又干净又典型，跑分很好看，上线就崩。
正确做法是从真实日志里采样，按类型分层：
- 简单：一步能完成的，考基本功。
- 多步：有依赖、要按顺序来的，考规划。
- 需要澄清：信息不全、必须追问的，考分寸。
- 注定失败：无解的，考它会不会及时放弃。
数量不用多，20 到 50 条就够。关键是每条都要有判定标准，而不是「标准答案」。
一条任务长这样：
id T-014输入 上周的 12 个素材文件必须 三段齐全 / 每条 ≤40 字必须 不含素材之外的事实禁止 出现「已完成」但素材没有判定 规则 + 人工抽查
「必须」和「禁止」这两栏是重点。写清楚它们，判定才能自动化；只写「输出一份好周报」，就只能靠人一次次读。
谁来判对错：规则、裁判、人
三种判定方式，成本从低到高：
规则判定。 字数、格式、必含字段、禁用词，全部能用代码判。能规则化的，绝不要用模型——又快又稳。
模型当裁判。 开放式输出只能靠它，但要防三个已知偏差：位置偏差（更偏爱第一个）、长度偏差（更偏爱长的）、自恋偏差（更偏爱自己家模型写的）。对策是打乱顺序、成对比较、给明确的评分维度。
人工抽查。 不用全看，按类型抽 10%，专挑失败的和边界情况看。
一个务实的组合：规则兜底 + 裁判打分 + 人工抽检。三层都过了，才算这条任务通过。
跑分要能归因，不然只是热闹
每次改动都跑同一套任务集，输出一份对比：
v3 20 条 3 次取多数成功率 16/20 → 17/20 +1平均步数 6.2 → 5.8 -0.4平均成本 0.31 → 0.24 元 -23%失败集中 T-007 / T-013
看这份表，先问三个问题：
- 涨的是哪几条？如果只涨了一条，很可能是运气，不是改进。
- 跌的是哪几条？掉点集中在同一类任务，说明改动碰到了那类任务的假设。
- 成本降了，成功率没掉吗？掉了就是拿质量换钱。
归因也要固定顺序：先看是不是模型换了，再看提示词，最后看工具。三者混在一起改，掉点了你也不知道该退哪个。
还有个工程细节：温度设 0 也不保证完全一样（硬件和并行计算会带来微小差异）。所以关键结论要跑三次取多数，别拿单次结果下判断。
给周报 Agent 建一套最小评测
三步，半天能做完：
- 攒 20 条任务：从过去两周的真实素材里挑，覆盖四类。
- 写判定：能用规则的用规则（三段、40 字、禁用词），判不了的列成人工检查项。
- 写个跑分脚本：读任务集 → 逐条跑 → 记录结果 → 输出对比表。
跑分脚本不需要框架，一个 JSON 任务文件加一个循环就够：
for task in tasks:out = run_agent(task.input)score = rule_check(out) + judge(out)record(task.id, score, tokens, ms)report(baseline, current)
从今天起，任何改动都跑一遍。跑不动的时候，就说明你的任务集太重了——减到 20 条，不要减到 0 条。
今日三句话
评测集是 Agent 的护栏；没有它，每次改动都是在赌。 - 20 条真实任务 + 明确判定标准，胜过 200 条编出来的样例。
看分布不看平均；掉点要能归因到模型、提示词或工具，混着改等于没改。
明日预告：六期收尾——把这条线画成一张能贴在墙上的地图。
