7.8
深览指数
科技人人都是产品经理·王耀亮··AI 生成
Agent评测指南，别再“感觉还行”就上线了
本文从AI产品经理的实战视角，系统阐述了大语言模型 Agent 评测的体系化框架，核心论点是传统软件测试方法（单元测试、跑通几条Case）在Agent面前彻底失效，必须转向以“非确定性、黑盒化、错误级联”为出发点的新评测体系。文章提供了一套从类型划分、指标定义、评测集设计、评分器选择到根因定位与闭环优化的完整落地方法论，强调评测的最终目的是将不稳定的智能行为收敛成可发布的工程质量，并把“低分”转化为可执行的修复行动项。适合正在或即将负责Agent产品上线、需要建立评测流程的AI产品经理、技术负责人阅读。原文 ↗
核心观点
- ▍Agent评测不能靠“跑通一次”或“感觉还行”，因为Agent具有非确定性、黑盒化和错误级联三大特性，传统软件测试方法完全失效，必须建立体系化的评测框架。
- ▍评测体系的根本目的是将不稳定的智能行为收敛成可发布的工程质量，核心是回答三个问题：能力水位（当前基线）、变更风险（回归门禁）和优化方向（根因与行动项）。
- 01作者分享了一个客服Agent的实战案例：测试环境退款流程顺畅，上线后遇到“已发货订单”时，Agent未调用订单查询工具就直接答应退款，导致资损风险，这是典型的“假阳性”问题（答案看着像人话，但过程早就偏了）。
- 02文章将Agent划分为六种类型（知识问答型、任务执行型、推理决策型、多轮引导型、创意生成型、多Agent协作型），并强调必须根据类型定义不同的评测指标，例如任务执行型核心看“干成没”（工具选对、参数对、状态变化），而非回答通顺与否。
- 03对于对话形态Agent，作者提出“四层评测法”：Turn（单轮合理性）、Session（整段问题解决率）、Trace（执行轨迹验证）、Outcome（业务结果确认），并警告只盯着Turn平均分是“自嗨”。
- 04评测指标体系被分为三层：P0上线门禁（任务完成率、幻觉率、隐私泄露等）、P1版本对比（过程质量、效率与成本）、P2体验改善（语气自然度、情绪承接等），并引入“至少一次成功率”和“连续成功率”两个生产级关键指标。
- 05评测集设计需四路并进：专家设计Golden Set（50-200条核心场景）、扩展用例（LLM生成变异）、线上真实数据（按场景风险分层抽样）、Badcase回流（沉淀为最值钱的资产）。
- 06评分器（Scorer）的三类优先级：代码/规则Scorer（硬条件首选，稳定可复现）> LLM-as-Judge（看语义，需校准防漂移）> Human Scorer（定口径、终判、高风险），并给出“分层筛查”策略：粗筛（规则+轻量LLM）-> 精判（完整规则+LLM）-> 人工复核。
- 07根因定位（RCA）链路为：证据汇总（基于Trace）-> 范围收敛（维护“问题现象×功能模块”映射表）-> 分模块诊断 -> 责任判定 -> 结构化落盘，产出结构化的行动项直接对接工单系统。
反方 / 局限
- — 文章承认，评测体系要稳定运行，技术只占一半，另一半是跨团队协作。作者指出，PM需要能翻译不同角色的语言（研发的“准确率85%”、算法的“换大模型吧”、运营的“感觉变差了”、老板的“快点上线”），并推动“评测报告→工单→修复→回归”的闭环，否则评测报告发出来大家只会“嗯嗯不错”，评测仍是成本中心。
- — 文章隐含的局限性在于，这套体系详细但高度依赖工程化投入（Trace系统、工单系统、版本管理），对于资源有限或初创团队，完全照搬可能成本过高。同时，LLM-as-Judge的校准和防偏见问题在实践中依然棘手，作者虽给出了方法（多模型对抗、置信度路由），但未展开其复杂度和失败率。
16 分钟 · 4 卡片 · 8 资料
读原文 →