别只测回答正确率：AI 工作流上线前要验收什么？

本文目录

一个 AI 工作流在测试会上连续通过十个问题，不等于它已经可以上线。真实流程会遇到缺字段、过期文档、权限不足、接口超时和用户临时改口；有些回答看起来不错，却没有完成业务动作。

验收不能只测“答案像不像”，而要同时回答四件事：业务是否变好、任务是否做对、系统是否跑得稳、风险是否守得住。

第一层：业务结果

先记录改造前的基线，再谈 AI 带来的改善。不同流程关注的结果不同：

• 工单分流：平均处理时长、积压量、转错队列比例；
• 销售资料整理：会后录入时间、缺失字段、逾期未跟进数量；
• 合同初审：首轮审阅周期、重复问题数量、需要法务深度处理的比例；
• 内部知识问答：问题解决率、转人工率、重复咨询量。

这里要避免用“调用次数”“生成字数”代替业务成果。使用量只能说明有人在用，不能说明流程更快、更准或更省。

第二层：任务质量

把一条端到端流程拆成可以判断对错的节点。例如“读取邮件并创建售后工单”至少包含：意图分类、字段提取、知识检索、工具选择、参数填写和结果确认。

每个节点采用合适的评测方式：

• 有标准答案的分类和提取任务，计算准确率、召回率或字段通过率；
• 检索任务检查关键证据是否被召回，而不是只看最终文风；
• 工具调用检查工具是否选对、参数是否完整、动作是否成功；
• 开放式生成由人工使用评分规则抽检，明确什么是通过、部分通过和失败。

Agent 往往会多轮调用工具并改变外部状态，因此评测对象不只是最后一句回答，还包括完整执行轨迹。Anthropic 的 Agent 评测指南强调了轨迹、工具调用和任务结果在评测中的作用。

第三层：运行效率

质量过关后，还要看它能否以可接受的成本稳定运行。建议至少记录：

• 端到端完成率；
• 人工介入率，以及介入发生在哪一步；
• P50 与 P95 延迟，分别代表中位数和 95 分位延迟，用来避免平均值掩盖长尾等待；
• 单个成功任务的模型、检索、外部接口和人工复核成本；
• 重试率、超时率、外部系统错误率；
• 从失败到恢复或转人工所需的时间。

“单次模型调用成本”容易低估真实费用。更实用的口径是“每个成功完成的业务任务成本”，因为它包含重试、失败和人工补救。

若系统跨越多个模型与工具，统一记录操作名称、模型、用量、延迟和错误类型，会让排查更容易。OpenTelemetry 是一套统一记录日志、指标和调用轨迹的开放标准，它的语义约定为跨组件的遥测数据提供一致命名；采用现成约定通常比各团队自创字段更利于关联分析。

第四层：风险与控制

风险指标不能等上线后再补。至少应验证：

• 未授权工具调用是否被拦截；
• 敏感字段是否按规则脱敏、隔离或拒绝发送；
• 高后果动作是否经过指定审批；
• 引用和关键判断能否追溯到输入与规则；
• 审批、拒绝、重试和回退是否留下完整记录；
• 模型不可用时，原有业务能否继续运转。

NIST 的生成式 AI 风险管理框架将可信要求放在 AI 产品的设计、开发、使用和评估全过程中。对企业项目来说，这意味着评测不是上线前的一张表，而是持续运营的一部分。

一张可直接使用的验收表

不要只写“准确率达到要求”。每个指标都要有基线、门槛、证据和负责人。

指标	当前基线	上线门槛	证据来源	未通过时
端到端完成率	人工流程或旧系统数据	由业务负责人确认	回归集 + 试运行日志	缩小自动化范围
关键字段通过率	历史抽样结果	按字段风险分别设定	标注样本	保留人工复核
人工介入率	当前全人工为参照	设目标区间，不追求归零	线上流程记录	分析介入原因
单个成功任务成本	当前人工与系统成本	约定可接受上限	账单 + 工时抽样	优化模型或步骤
高风险误动作	0	必须为 0	权限与对抗测试	阻止上线
P95 延迟（95 分位）	当前流程时长	按业务等待容忍度设定	端到端追踪	降级或异步处理

门槛不必照搬别人的数字。客服辅助与付款执行的容错要求显然不同；同一指标也应按任务风险分层。

建立”上线前 + 上线后”两套评测

评测也要分阶段做。

上线前使用固定回归集，覆盖常规样本、边界情况、历史事故和恶意输入。每次调整模型、提示词、检索或工具后重跑，用同一组证据比较变化。

上线后则观察真实分布：定期抽样、收集人工修正、追踪失败集中在哪些流程节点，再把新的代表性问题补回回归集。离线评测负责拦截已知问题，线上观测负责发现未知变化。

最后，避免把所有指标压成一个总分。总分可能掩盖严重风险：质量提升两分，不能抵消一次未授权付款。业务结果、任务质量、运行效率和风险控制应分别设门槛；任何硬性风险项失败，都应暂停扩大范围。

AI 工作流的验收标准越具体，团队越容易判断该继续、缩小范围还是回到流程设计。上线不是评测的终点，而是开始获得真实证据的节点。