AI 应用项目如何实现质量评测，怎样定义通过标准？

核心回答

AI 应用质量评测要从业务上的“任务完成”定义通过标准，再组合结果、过程、安全和成本性能四类检查。能程序判断的格式、数值和状态用确定性规则；开放回答用明确评分准则配合 LLM-as-Judge，再用人工标注校准；Agent 还要检查工具、权限和实际业务结果，不能只看最终回复。

发布时同时看关键用例硬门槛、相对稳定基线的变化和分层结果，并给出随机波动的不确定性。阈值根据业务损失、现状与服务目标确定，不存在所有项目统一的“达到多少分就通过”。

展开解析

1. 把业务要求写成可以判定的标准

以售后退款助手为例，一条任务的通过条件可以是：识别正确订单、遵循退款规则、金额正确、必要确认已完成，并在业务库形成相符的申请单。若用户条件不足，正确追问也可以通过；若没有权限，正确拒绝才是预期结果。

格式正确或回答礼貌不能抵消错退金额。将每条任务拆成必要条件，区分必须满足的安全与业务规则，以及表达质量等连续评分维度。任务完成标准应在评测前确定，不能看了某版本的结果再修改规则让它通过。

2. 组合评分器，各自检查擅长的部分

对象	合适的检查方式	需要防止的误判
输出格式、数值、引用存在性	JSON Schema、计算校验、引用链接或证据定位	格式合法不等于事实正确
业务动作	查询权威状态、回执和实际产物	模型宣称已完成但没有真实结果
开放式回答	分维度评分准则、模型评审与人工抽检	位置偏差、长度偏好、同源偏差
工具过程与权限	轨迹断言、审计记录、业务策略校验	最终答对却越权或产生多余副作用
稳定性与代价	多次运行、延迟、Token 和任务总费用	只统计成功请求，遗漏失败消耗

模型评审器先与业务专家标注做对照，检查哪些类别容易判错；成对比较时可交换答案位置并隐藏版本信息。重要结果附判定依据，低置信或争议样本进入人工复核，不能把评审器的自报置信度当真实概率。

3. 建立能复现的执行框架

评测运行器加载版本化数据集与初始状态，固定模型标识、提示词、工具契约、检索资料和推理配置，独立运行任务，保存轨迹并调用评分器。工具发生写入时使用隔离环境，任务之间重置数据，避免上一条样本改变下一条结果。

RAG 需要区分召回不到依据、重排丢失、上下文正确但生成错误；Agent 需要再区分选错工具、参数错误、执行失败和观察解释错误。标签能帮助定位改进方向，而不是把所有失败都记成“模型效果不好”。

4. 通过标准分为单任务和批次发布两层

单任务层按预定义条件判定是否完成，安全和关键业务约束单独判断。

批次层同时看总体任务完成率、重点分层、稳定基线上的回归、安全违规、尾延迟和每成功任务成本。单位成功成本可用本批全部运行费用除以成功任务数，失败费用也纳入；没有成功任务时直接报告该状态。

门槛可以组合绝对业务底线与相对基线变化，但必须有业务依据。试验样本中没有观察到违规，不等于真实风险为零；差异很小而区间很宽时，应报告证据不足，不能只取一次高分。对重复运行结果，区分“多次中至少成功一次”和“重复都能成功”，不要互换。

5. 离线结论还需要线上检验

离线评测用于发现问题与阻止回归；历史轨迹回放检查真实输入；小流量发布观察真实任务完成、用户修订、接管、错误副作用、延迟和成本。线上确认的失败经审读后回流，保留新任务检验泛化能力。点击率或点赞只能提供部分反馈，不能单独代表事实准确或任务完成。

追问

为什么不能只用一个综合分？

综合分会掩盖不同损失：表达得分上升可能抵消业务错误增加。可以保留综合指标便于比较，但安全、关键结果和重点场景要单独设门槛。

模型非确定，回归怎么判断？

在相同任务上配对比较版本，对关键任务重复运行，报告分层差异与不确定性；同时检查环境和评分器是否变化。无法区分噪声和改进时，结论应保持未确定。

参考资料