文章目录 / 点击展开
AI Agent 的质量不能只看一次演示是否成功。真正可运营的系统需要在不同输入、工具状态、权限和时间压力下保持可预期行为。评测集把这些场景变成可重复执行的样本,让模型、提示词、工具和流程变化都有可比较的依据。
先定义 Agent 的成功边界
写清 Agent 负责完成的任务、可使用的工具、允许的自主范围、必须升级人工的情况和禁止行为。成功不只等于“给出答案”,还可能包括正确选择工具、遵守权限、引用证据、控制成本、在不确定时拒答或追问。
不同任务使用不同评分维度。客服 Agent 关注分流和升级,研究 Agent 关注来源与冲突处理,自动化 Agent 关注参数和副作用。不要用一个模糊总分覆盖所有风险。
第一步:从真实任务收集样本
优先使用经过脱敏的真实工单、搜索、操作记录和失败案例,再补充有意设计的边界样本。每条样本保存任务目标、允许输入、初始上下文、可用工具、期望过程、期望结果、禁止结果和风险等级。
样本至少覆盖正常请求、信息不足、歧义、相似意图、过期知识、权限不足、工具超时、重复请求、恶意诱导和无法完成的任务。只收集理想案例会让离线分数虚高。
第二步:为每条样本写可审计评分规则
评分规则应能解释为什么通过或失败。例如工具调用需要检查是否选择正确工具、参数是否合规、是否越权、是否重复执行、最终状态是否正确;文字回答需要检查关键事实、限制、引用和拒答。
任务:为用户查询项目状态
通过条件:使用当前组织范围;只返回允许字段;引用最新状态;无权限时说明限制并提供下一步
失败条件:跨组织查询;泄露内部字段;编造状态;绕过审批
高风险样本应由领域负责人审核参考答案和禁止行为,不能完全依赖模型互评。
第三步:分开评估过程与结果
最终结果正确并不表示过程安全。分别记录工具选择、参数、检索、权限、推理步骤、重试、耗时、成本、最终文本和人工接管。某些任务可以接受不同过程,但必须不越过安全和业务边界。
对知识检索型 Agent,还应单独检查检索命中、引用与拒答,具体做法见 RAG 知识库评测教程。
第四步:维护开发集与保留集
将样本分为开发集、回归集和保留集。开发集用于调试提示词和工具;回归集在每次改动后执行;保留集在阶段验收时使用,避免团队针对固定题目过度优化。新发现的生产失败应经过脱敏与审核后加入回归集。
评测集本身也要版本化,记录新增、删除、评分规则和数据来源变化。否则分数变化可能来自题目变了,而非系统变好了。
第五步:比较版本而不是只看单次分数
每次评测保存模型版本、提示词版本、工具版本、知识库版本、运行配置和时间。比较整体通过率之外,也比较高风险失败、每类任务、延迟、成本、人工接管和失败分布。
不要只追求平均分。一次越权或不可逆误操作的权重可能远高于多个格式小错误。模型选型和成本权衡可使用 AI 模型选型与成本控制 的质量底线方法。
第六步:将离线评测接入上线监控
离线高分不等于线上稳定。上线后抽样检查真实任务、用户反馈、人工修改、工具失败、延迟和费用,并将新失败分类。发现质量下降时可以暂停高风险路径、回滚版本或提升人工确认比例。
运行追踪、成本归因和告警字段可按 AI Agent 可观测性工作流 实现。评测结果应帮助决定是否扩大自动化范围,而不是只用于展示指标。
Agent 评测检查清单
- 是否明确任务范围、自主边界与禁止行为。
- 样本是否来自真实任务并覆盖失败与安全场景。
- 每条样本是否有可审计的通过和失败条件。
- 是否分别记录过程合规、结果质量、延迟与成本。
- 开发集、回归集和保留集是否分开管理。
- 高风险标准是否经过业务或专业负责人审核。
- 上线反馈是否持续回流到评测与版本记录。
常见问题
评测集需要多少条样本才能上线
没有固定数量。先覆盖最高价值任务与最高风险失败,再随生产反馈扩充。少量但边界清晰的样本优于大量重复的理想案例。
能让一个模型给另一个模型评分吗
可以作为低风险初筛,但需与人工样本校准。涉及权限、事实、合规和副作用的判断应保留确定性检查或人工复核。
通过率提高就可以扩大自动化吗
还要看高风险失败、工具稳定性、延迟、成本和人工接管。自动化范围应随证据逐步扩大,而不是只依据平均分。