智能体评测集：先定义失败，再谈效果

最危险的不是效果差，而是效果在你不知道的时候变差了。改一句提示词、换一个模型、补一批知识，任何一次调整都可能悄悄拉低通过率。

一、从 40 条真实样本开始，不要从 400 条开始

我们见过太多团队卡在“先建一个完美评测集”上，三个月没上线。正确做法是先小而准：从最近两周的真实工单里挑 40 条，覆盖主要意图与边界情况。

挑选标准只有三条：真实发生、有明确正确答案、能判断对错。如果一条样本连人工都判断不了对错，就说明业务规则本身没写清楚，先回去补规则。

二、定义失败类型，比定义“好”更重要

“回答质量”太模糊。我们通常把失败分成五类，每类对应不同的修法：

• 未召回：知识库里明明有，但没检索到。修检索与切片。
• 错引用：答案对，但引用的段落不支持结论。修排序与引用约束。
• 越权：读到了不该看的数据，或回答了不该答的范围。修权限与拒答策略。
• 格式错：结构、字段、单位不符合下游系统要求。修输出约束与校验。
• 编造：知识缺失时仍然给出答案。这类最严重，通常需要强制拒答与阈值调优。

三、五个指标，够用了

不要一开始就上十几种指标。我们常用五个：任务通过率（人工判定或规则判定）、引用正确率、越权率、平均单次成本、P95 时延。前三个管质量，后两个管代价。

指标必须能拆到场景。整体通过率 90% 听起来不错，但如果客服场景 97%、合同抽取场景 71%，问题就很清楚了。

四、把评测接进变更流程

评测集只有接进流程才有价值。我们的做法是：任何提示词、模型路由、知识库结构的改动，都必须先跑一遍全量评测，输出与基线的差异报告。

1. 记录基线：当前生产版本的五个指标。
2. 跑新版本：同一批评测样本，固定温度与输出长度。
3. 看差异：不仅看总数，更看“原来对现在错”的样本，这部分才是风险。
4. 决定：差异在容忍范围内才允许灰度，灰度期间继续抽样比对。

五、评测集会过拟合，必须轮换

提示词写多了，模型会“背题”。我们每月补充 10–20 条新样本，并把 20% 的旧样本轮换出去；同时保留一份不参与调优的“盲测集”，只在版本发布前使用。

六、它能证明什么，不能证明什么

评测集能证明：这次改动没有让已知能力退步。它不能证明：产品好用、用户满意、业务指标提升。后者要靠灰度期的真实数据与人工反馈。

所以我们从不把“通过率 95%”当作交付结论，只把它当作上线的前置条件。真正的验收指标永远是业务侧的：人工接管率、处理时长、返工率。