我们复盘过十几起验收失败的案例，几乎没有一起是因为模型能力不够。争议集中在三个句型：「你说的这个场景不在我们理解范围内」「这几十条答得不对怎么算」「上线以后效果又掉了怎么办」。
这三句话指向同一件事：验收标准没有在开工前变成可执行的条款。下面是我们现在固定使用的验收口径，可以直接抄进项目文档。
三类典型争议
- 范围漂移：合同写「智能客服」，实际包含售前咨询、售后工单、退款政策三类完全不同难度的任务，双方对「做好了」的预期自然不同。
- 样本选择权：谁出题谁占优。开发方出的题偏向系统擅长的题型，业务方出的题偏向真实长尾，两者的通过率可以相差三十个百分点。
- 上线即终点：验收一次通过后无人跟踪，三个月后业务方反馈「不如刚上线」，但没有任何数据能证明是数据漂移还是需求变了。
验收四要素
我们要求每个 AI 项目在启动会上就确定四项内容，并写进项目文档的同一页：
- 场景清单：逐条列出系统要处理的任务类型、输入形式与预期输出形式，明确哪些不在范围内。
- 评测集：业务方提供真实问题样本，双方共同标注标准答案，样本量与配比固定，验收时不得临时更换。
- 指标与阈值：每个指标给出定义、计算方式与合格线，避免「准确率」这类词被各自解释。
- 退化处理：约定上线后出现效果下降时的判定流程与响应时限。
| 指标 | 定义 | 常见合格线参考 |
|---|---|---|
| 任务成功率 | 评测集中输出被判定为「可接受」的比例 | 按场景难度分档设定 |
| 关键字段准确率 | 结构化输出中关键字段完全正确的比例 | 高于任务成功率 |
| 拒答恰当率 | 知识库无答案时正确拒答的比例 | 95% 以上 |
| P95 时延 | 95% 请求的首字或整体响应时间 | 按交互形态设定 |
| 人工复核负担 | 每千次任务需要人工核对的分钟数 | 随迭代应持续下降 |
评测集怎么定才不作废
评测集的质量决定了验收的可信度。我们的做法是三条：来源真实（来自工单、群聊或搜索日志，不由模型生成）、配比固定（正常样本、边界样本、应拒答样本按约定比例）、留出盲测（保留 20% 样本只由业务方持有，验收时现场抽取）。
盲测这一条经常被抵制，理由是「不透明」。但正是它让验收结果具备可辩护性——它保护的不只是甲方，也包括认真做事的乙方。
上线之后：持续验收
AI 系统的效果不是常数。数据分布会变，上游业务系统会改，模型版本会升级。我们建议按月或按季度复跑同一套评测集，形成趋势曲线，并把三类原因分开记录：
- 数据漂移：真实提问的分布发生变化，原评测集不再代表现状；
- 上游变更：接口字段、知识库口径调整导致输入质量下降；
- 能力问题：模型或提示词层面的缺陷，需要重新调优。
分开记录的价值在于归责清晰：第一类由业务方主导补充样本，第二类由系统集成方修复，第三类才是模型与工程侧的责任。没有这个分类，所有下降都会被笼统归为「AI 不行」。
常见问题
问：AI 项目的验收标准应该包含哪些指标？
至少四项：任务成功率、关键字段准确率、应拒答样本的拒答率、P95 响应时延。另外建议单列人工复核负担，用于判断系统是否只是把工作量从一线转移到了审核岗。
问：评测集应该由谁出？
业务方提供真实问题，双方共同标注标准答案，开发方负责建立可复现的评测流程。如果评测集完全由开发方生成，往往会偏向系统擅长的题型，导致验收通过但上线后口碑不佳。
问：上线后效果下降，责任怎么界定？
在合同里约定退化处理条款：区分数据漂移、上游系统变更与模型能力问题三类原因，明确监控指标、告警阈值与响应时限。这样争议会从「谁的责任」变成「属于哪一类」，处理起来快得多。
最后一句经验：验收标准写得越具体，项目前期的争论越多，交付后期的争论越少。这个交换几乎总是划算的。
本文方法来自天辰平台智能体与知识库交付项目，已在多个行业项目中复用。