评测集建设与离线/在线的鸿沟

三条线只能互相佐证，不能互相替代。 它们两两之间的背离各自对应一个明确的诊断：

这张表是本章最常被引用的东西——任何一个「这个改动要不要上」的问题，标准答案都是先说清楚你打算用哪条线来判。

① 输入分布不同 —— 最常见，也最容易被忽略，因为它不报错。检查方法很朴素：把评测集和线上采样的 query 各自统计长度分布、轮次分布、意图分布，摆在一张表里看（开篇那张表就是这么来的）。一个下午能做完，但绝大多数团队从来没做过。

② 判据不同 —— 离线判「要点命中」，用户判「有没有帮我把事办了」。要点全命中但结论埋在第三段，离线满分线上被骂。而且这个偏差会随着你对着判据优化而不断放大。

③ 上下文不同 —— 承接四种上下文失败形态（污染 / 干扰 / 混淆 / 冲突）。离线是一次干净的单轮调用；线上是第 7 轮，前面堆了 3 次工具返回、1 次压缩、和一条用户中途改主意的指令。只测第一轮的评测集，一种都测不出来。

④ 数据泄漏 —— 最隐蔽。典型形态是评测集和调 prompt 用的例子同源，或者更常见的，prompt 是对着评测集一轮轮调出来的。此时分数上涨里有多少是真提升，你分不清。

不是一个评测集，是三个，跑的频率和拦截权限都不同：

判据：能进门禁集的，必须是「错了就该拦住发布」的用例。 把「锦上添花」的题放进门禁，结果一定是门禁天天红、所有人学会无视它——一个从不亮绿灯的门禁等于没有门禁。

1. 线上真实失败（最贵、最值钱）。每一条都是花了真实代价换来的。
2. 线上真实成功流量的分层抽样。它保证的不是难度，是分布——开篇故障缺的就是这一类。
3. 领域专家写的边界样例。覆盖罕见但后果严重的情况：越权、敏感、法规、极端数值。
4. 模型批量扩写。最便宜。

铁律：第 4 类只能用来扩写，不能用来打底。 用模型生成的题去测模型，你测到的是「两个模型共同认为重要的部分」。真正会翻车的地方，恰恰是两个模型有共同盲区的地方——而合成数据在那里是空白的。所以听到「我们评测集有 5000 条」，第一句该问的是「谁标的」。

• 评测集 ≠ 开发集。 开发集随便看、随便对着它调 prompt；评测集只在跑分的时候看，不允许逐条读着改 prompt。
• 评测集与微调训练集必须异源（承接第 4 章的口径）。同源切分出来的评测集，测的是记忆不是能力。
• 留一份保留集（holdout），从不参与任何迭代，只在重大版本前跑一次。它是回答「我们这半年是真变好了，还是只是把门禁集刷穿了」的唯一手段。

第一步，先算置信区间。 单个比例的样本量公式：

反过来算：n=100、基线 80% 时，95% 置信区间大约是 ±7.8 个百分点。 涨 2 个点连半个置信区间都没走出去。

第二步，别用独立比例的算法。 上面那个 ±7.8pt 是「两组独立样本」的口径，而评测通常是同一套题、两个配置各跑一遍——这是配对数据。配对检验只关心结论发生翻转的那些题：

举例：100 题里 90 题结论相同，剩下 10 题 A 对 B 错 6 条、A 错 B 对 4 条——远不显著；9 比 1 才开始有话说。同样 n=100，配对检验能分辨的差异比独立比例小得多——「评测集不大也能用」的前提，就是你得会用配对检验。

第三步，模型自己也是方差源，而且 2026 年你按不住它。

按已冻结的口径 7，Opus 4.7+ / Sonnet 5 上传非默认的 temperature / top_p / top_k 会直接返回 400 —— temperature=0 这条老路已经没了。这意味着单次跑分不再是「确定性结果」，而是一次采样。正确做法是：

K = 3~5
for cfg in [baseline, candidate]:
    for seed in range(K):
        scores[cfg][seed] = run(eval_set, cfg)
report  mean(scores[cfg]) ± std(scores[cfg])          # 每个配置报均值和方差
mcnemar(correct[baseline], correct[candidate])        # 只看结论翻转的题

一句话：没有配对检验、没有方差的「涨了两个点」不是结论，是噪声。

LangChain《State of Agent Engineering》（调研期 2025-11~12，n=1340）：

可观测已经是基础设施，评测还不是。 这个落差就是本章存在的理由——大部分候选人能讲清楚 trace 长什么样，讲不清楚一个分数在什么条件下才配当决策依据。

面试里问「多少条起步」，标准答案不是一个数字，是先问处在哪个阶段：

这里有一个值得如实写出来的分歧：

• Anthropic 官方口径倾向 volume over quality——「更多题目 + 稍差一点的自动判分」优于「少量题目 + 高质量人工判分」，并鼓励用模型批量扩写测试用例；
• **实践派主流（Hamel Husain、LangChain 官方 checklist）**主张 20–50 条手工确认的胜过几百条没人看过的合成数据。

这两条不矛盾，差在「判分是谁做的」。 Anthropic 那条成立的前提是判分由代码做（精确匹配、schema 校验、单测）——此时每条样本边际成本接近零，多多益善。一旦判分要靠人或靠 judge，每条都有标注成本和噪声，小而精就重新占优。

可直接引用的判据：判分越便宜越可靠，评测集就越该大；判分越贵越主观，评测集就越该小而准。

• 别把评测集当期末考试。 分数绝对值几乎没有意义，有意义的是同一套题在两个版本之间的差值。跨评测集比分数（「我们 92 分，他们 88 分」）是纯粹的噪声。
• 别让评测集只增不减。 定期把「最近所有版本都 100% 通过」的用例降级到冒烟集——它们已经失去区分度，只在消耗预算。这和行业级 benchmark 的饱和是同一个现象，只是发生在你自己的仓库里。
• 别忘了把 effort 档位当成评测矩阵的一个维度。 提档位会改变输出 token 数、工具调用次数和成本——换档位和换模型一样，要走完整回归。
• 给评测集编版本号，并和跑分结果绑在一起存。 改了集合却不改版本号，历史分数曲线就全废了。

• 「你们上线前怎么评测的？」（开场，几乎必问）
• 「评测集多少条？从哪来的？」（第一刀：有没有真建过）
• 「离线分很高但上线效果差，可能是什么原因？」（第二刀：有没有真踩过）
• 「换个模型评测集涨了两个点，你敢发吗？」（第三刀：有没有统计直觉）

沿用 Q2-25 的五步骨架，落到评测这件事上：

① 澄清   这个应用的失败长什么样？是答错、答漏、还是答得对但没用？
② 基线   现在的分数是多少，在多大的集合上，什么判据
③ 加挂   我要加什么（更大的集合 / judge / 线上采样），代价是什么
④ 评测   我怎么知道这个改动真的有效——配对检验 + 方差
⑤ 演进   线上失败怎么回流成新用例

暴露只读过：

• 「我们建了评测集，用 GPT 打分，准确率 92%」——只有分数，没有分布、没有来源、没有区间。
• 「评测集有 5000 条」——一被问「谁标的」就露馅。
• 「上线前跑一遍就行」——把评测当验收，不当回归。
• 「涨了两个点，效果挺明显的」——没有统计直觉，这是最容易被一句话问倒的地方。

证明真做过：

• 能说出评测集的来源构成（多少来自线上失败、多少来自抽样、多少是专家写的、多少是扩写的）。
• 能说出评测集分布和线上分布的差在哪，以及是怎么发现的。
• 能说出门禁集和全量集的区别，以及为什么某条用例进了门禁、某条没进。
• 能说出一次因为评测集没覆盖而漏到线上的问题，以及事后补了哪条用例——这是数据飞轮真实运转的唯一证据。
• 被问到「涨两个点」时，反问「多少条题上涨的两个点、是不是同一套题配对跑的、重跑几次方差多大」。这一句反问的杀伤力，大于前面所有回答。