14-评估环境与数据集设计LLM-as-a-Judge、失败归因、评估驱动的模型选型系列导读上一篇聊了Passk与Pass^k这对孪生指标这一篇往下走一层——指标算出来需要土壤这个土壤就是评估环境和任务数据集。内容依然基于李博杰《深入理解AI Agent设计原理与工程实践》的核心框架结合我在无人售货柜与智慧农业项目里的实践。一、为什么评估环境是个正经工程问题很多人以为评估就是写几个测试用例跑一跑。跑两周你就会发现Agent今天在A任务上变好了B任务悄悄退化了一半而你根本没测B。评估不是一个动作是一套基础设施。一套自动评估环境本质上是回答五个问题“五要素”评什么评估对象是Agent系统整体还是某个模块规划器/工具选择器/记忆对谁评评的是哪个版本哪个模型哪组配置版本管理不严评估结果就是一笔糊涂账用什么标准打分结果正确性、过程合法性、成本、延迟……上一篇的指标体系要在这里落地成可执行的判分逻辑在什么环境里评真实API太贵太慢mock环境又怕失真结果怎么消费报告给谁看阈值不过怎么拦截发布按交互形态评估环境分两类工具调用型评估环境Agent与环境通过API/工具交互输入输出结构化判分可以做成全自动。比如我们的售货柜运维Agent——给它柜机日志、库存数据、故障码看它调用哪些诊断工具、给出什么工单结论人机交互型评估环境Agent面对的是用户、是UI、是不确定的人类反馈。这类评估要么靠人工扮演用户要么靠用户模拟器用LLM扮演不同性格的用户评估成本高得多。实践中我的建议能工具化的场景坚决工具化。把人机交互中可以结构化的部分查订单、查日志、执行退款先抽成工具评估环境就清爽一大半。二、任务数据集设计评估质量的真正瓶颈模型天天在换Prompt周周在改但数据集如果设计得烂上面的一切都是空中楼阁。任务数据集设计有五个核心挑战1. 任务描述精确性“帮我处理一下退款”——这种任务描述丢给Agent做对了是运气。任务描述必须精确到初始状态、可用工具、期望终态三元组齐备。例如“用户订单A123扣款15元但柜门未开系统时间2026-08-18可用工具查订单/查柜机日志/退款/发通知期望终态完成退款并通知用户或给出拒绝理由”。2. 复杂度层次化数据集不能全是简单任务也不能全是地狱难度。建议分层L1 单步任务一次工具调用可完成查订单状态L2 线性多步3~5步固定链路查订单→查日志→退款L3 条件分支需要根据中间结果走不同路径日志显示出货成功则拒绝退款L4 开放探索目标明确、路径未知排查某类柜机故障率异常的原因。每层的通过率分开统计你才能看出Agent死在哪一层。3. 可验证性客观性任务必须能客观判分。写一封得体的客服回复没法客观判分调用退款工具且金额等于订单实付金额可以。设计数据集时优先把期望结果表达成可机检的断言实在不行再上LLM判分。4. 任务分布系统性数据集的分布要贴近真实线上分布。如果线上80%的客诉是扣款未出货你的数据集里这个类型只占10%评估分数再高也是假象。从真实日志里采样、脱敏、构造比坐在办公室拍脑袋写用例强一百倍。5. 数据质量控制金标答案要有交叉校验两人独立标注不一致的case仲裁还要定期清理过期用例——业务规则变了比如退款政策调整旧金标就成了毒数据。三、LLM-as-a-Judge让大模型当裁判结构化断言能覆盖大部分判分但总有开放性输出回复是否礼貌、解释是否清晰、推理是否合理。这时候上LLM-as-a-Judge用一个通常更强的模型按照给定的评分维度和Rubric对Agent输出打分并给出理由。它的价值在于规模化一晚上跑完3000条轨迹的人工抽检量成本可能不到一个实习生的一天。但要警惕它的三个坑位置偏差对比两个答案时偏好先出现的那个——判分时要做位置随机交换长度偏差偏好更长的回答——Rubric里明确简洁不扣分自我偏好某些模型偏爱自家风格的输出——裁判模型和被评模型最好不同源。评判者校准kappa ≥ 0.7 门槛裁判模型自己靠不靠谱要先校准。做法准备一个金标集人工标注过的一批样本让LLM裁判独立打分然后计算裁判与人类标注的一致性Cohen’s kappa。kappa ≥ 0.7 才算合格否则这个裁判不配上岗。我们团队实测过不给Rubric的裸裁判kappa只有0.5左右给了详细Rubricfew-shot示例后能稳定到0.75。裁判的钱不能省在Rubric上。四、失败归因从整条轨迹定位首个错误评估告诉你错了但不告诉你为什么错。失败归因failure attribution就是把一条失败轨迹拆开找到第一个偏离正轨的动作——后面的错误往往是第一个错误的连锁反应修第一个才有意义。举个例子退款Agent轨迹失败1. 查订单 A123 → 正确 2. 查柜机日志 → 正确 3. 发现出货电机超时故障码 → 解读正确 4. 调用退款工具金额原价15元 → 错实付12元用了券 5. 通知用户已退15元 → 连锁错误归因结论首错在第4步——金额来源选错字段。修法可以是给退款工具加参数校验实付金额必须来自订单接口的paid_amount字段而不是去改第5步的通知话术。端到端回归任务 vs 轨迹前缀回归任务端到端回归整个任务重跑看最终结果——验证修好了没轨迹前缀回归把出错前的轨迹作为前缀固定住从出错那一步开始重放——专门验证这一步修好了没速度快、定位准适合迭代单点修复。修复一个bug后的标准动作先跑轨迹前缀回归确认局部修好再跑端到端回归确认没有引入新问题。五、配对比较与模型排名模型A比模型B好这种结论单看总分容易被任务分布误导。更稳的方法是配对比较同一任务分别让两个模型跑统计A胜/B胜/平局再看不同任务层级的胜负分布。我们会发现非常常见的现象模型A在L1/L2简单任务上碾压B但在L4开放任务上被B反杀——那选谁就取决于你的业务落在哪一层。这也是为什么排行榜要看分层明细别只看总分。六、评估驱动的模型选型与成本分析选模型不是看跑分是看你的任务上的表现 × 延迟 × 成本维度关键问题能力在你的分层数据集上Pass^k多少延迟P95端到端耗时多少用户等得及吗成本单任务token成本多少日活×单成本能否覆盖毛利行为策略是否过度确认是否倾向过早结束任务Agent系统的成本账要算全不只是LLM的token成本还有工具调用成本——付费API按次计费、数据库查询占用连接、RAG检索的向量库开销。我们有个Agent曾因为不确定就再查一次的策略把第三方风控接口调爆了那天的账单很感人。从Benchmark报告到系统改进的路径是报告 → 失败归因 → 定位首错 → 修复Prompt/工具/模型→ 回归验证 → 报告。这个循环转得越快迭代越快。七、消融基础设施与AB测试双层特性开关严肃的团队会为评估搭两样基础设施消融Ablation基础设施一键开关任意组件记忆/反思/规划器/某个工具量化每个组件的贡献。没有消融你不知道系统里哪些模块是在帮忙、哪些是在帮倒忙——实测中帮倒忙的模块并不少见双层特性开关系统第一层代码特性开关——控制新功能代码是否执行秒级回滚第二层流量特性开关——控制新版本Agent暴露给多少比例的用户1% → 5% → 50% → 全量。两层配合新Agent上线就是代码开关打开 → 小流量灰度 → 观察AB指标成功率/客诉率/成本→ 逐步放量。出问题开关一关回滚完成全程不用重新部署。这在无人零售这种7×24小时、真金白银的业务里是保命的。小结自动评估环境五要素评什么、对谁评、用什么标准打分、在什么环境、结果怎么消费数据集设计五挑战描述精确、复杂度分层、可客观验证、分布贴近线上、质量控制LLM-as-a-Judge规模化判分但必须过kappa≥0.7的校准门槛失败归因盯住首个错误配合轨迹前缀回归做单点验证模型选型看能力/延迟/成本/行为策略四维成本要把工具调用算进去消融基础设施 双层特性开关让评估结论安全地转化为线上收益。评估体系搭好之后一个自然的追问出现了模型能力不达标怎么办这就进入下一层话题——模型后训练。