AI 产品的评测集怎么建：从真实失败样本开始

01 / 漂亮案例为什么不能代表产品质量

AI 产品演示通常会选择信息完整、表达清楚、结果容易判断的样本。这样的样本适合说明产品方向，却不足以决定系统能否进入真实业务。生产环境里的输入会缺字段、带歧义、相互矛盾，还可能触碰价格、合同、客户权益等高影响边界。

如果团队只保存成功案例，每次版本升级都可能得到“看起来更好了”的结论，却无法回答哪些能力退步了、哪些风险增加了、是否还能稳定完成原来的任务。

评测集的作用，是把产品承诺变成一组可以反复执行的检查。它不是研发结束时才做的考试，而应该从需求阶段就开始积累。

02 / 先定义任务，再定义什么叫正确

一个评测样本不能只有问题和参考答案。它至少需要说明任务背景、输入资料、允许使用的工具、业务规则、预期结果和不能发生的错误。

“回答是否相似”往往不是最重要的标准。对于资料提取，要检查字段是否完整、来源是否对应；对于方案建议，要检查规则是否满足、假设是否标明；对于系统动作，要检查权限、状态和执行结果；对于高风险任务，还要检查系统是否在不确定时主动停止。

同一个样本可以同时设置多个判断层次：格式是否合格、事实是否有依据、规则是否满足、业务结果是否可用、风险护栏是否触发。这样才能看见产品具体坏在什么位置。

03 / 样本要覆盖正常、边界、异常和拒绝

正常样本用于确认主流程，边界样本用于测试规则临界点，异常样本用于观察缺失、冲突和工具失败，拒绝样本用于确认系统不会执行越权或高风险请求。四类样本缺一，评测结果都会偏向理想环境。

失败样本尤其有价值。每次人工接管、客户反馈和线上异常，都可以先判断是否具有代表性，再转化为新的评测项。不是把所有错误原样收进来，而是提炼其背后的失败模式。

• 01缺少关键字段时，系统是否明确指出缺什么
• 02两个来源冲突时，是否停止并要求确认
• 03规则超过适用范围时，是否避免强行给出结论
• 04工具调用失败时，是否保留状态并安全退出
• 05请求超出权限时，是否拒绝且不泄露相关信息

04 / 给失败分类，才能知道该修哪里

同一个错误结果，原因可能完全不同。可能是模型理解偏差、知识过期、输入不完整、业务规则矛盾、接口返回异常，也可能是验收标准本身写得模糊。如果所有问题都被归为“模型不准”，团队只会不断更换模型或修改提示词。

建议为每个失败样本记录原因类别、影响程度、出现环节和责任模块。修复后不仅重测这一个样本，还要检查相同类型的其他任务，避免局部修改引发新的退步。

评测集可以分为固定集和滚动集。固定集守住已经承诺的核心能力，滚动集吸收近期真实问题。固定集保持可比，滚动集保持对业务变化的敏感。

05 / 把评测集变成发布质量门

每次更换模型、调整知识、修改规则或增加工具，都应执行同一套核心评测。结果不仅给技术团队看，也要让业务负责人确认：哪些能力保持稳定，哪些发生变化，哪些风险需要新的人工确认。

发布标准不必追求一个脱离场景的统一分数。可以根据任务影响设置不同门槛：低风险内容允许人工修订，高风险动作必须满足规则、权限和可追溯要求。未通过的能力可以限制范围或保持人工处理，而不是为了按时上线隐藏问题。

一套好的评测集，会让团队从“感觉这个版本不错”，走向“知道它在哪些任务上可以被信任”。