★ FEATURED ARTICLE 最近被问得最多的一个问题不是“某个模型能考多少分”而是“这个 AI 到底能不能干活”。日常演示里GPT 类大模型写文案、改代码、整理表格样样都像模像样可真把它丢到一条真实工作链路里前两分钟可能惊艳全场第三分钟开始编造数据第五分钟卡在同一个循环里出不来。传统 Benchmark 只能回答“它懂多少”回答不了“它能交付什么”。这也是“Benchmark 拆解系列”继续往下做的原因。今天聊 GDPval-AA一个围绕“AI 工作能力”设计的评估思路重点讲清楚它到底量的是什么怎么打分以及实际复现时最容易踩的坑。1. GDPval-AA 到底在测什么1.1 工作能力不等于知识量而是交付稳定性很多人把“AI 工作能力强”误解成“问题回答得准确”。这是两套完全不同的评价体系。回答类评测看的是单次输出的正确性而工作类评测看的是“链条”能不能完整走完接收任务、检索信息、拆解约束、动手产出、自查验证、提交交付任何一个环节断掉前面表现再好也白搭。GDPval-AA 的全称我习惯记为 General Domain Performance Validation for Agent Autonomy中文可以理解为“通用域工作表现验证基准”。名字有点长核心却很朴素在模拟岗位场景里让大语言模型或 AI Agent 真的去执行任务然后把最终交付物、执行轨迹、合规性和资源消耗一起纳入评分。之所以要专门做这种“工作类基准”是因为现实中的岗位能力测试和学校考试完全不同。考试允许你孤军奋战工作不允许考试只看答案工作还要看过程考试错了扣分工作错了可能直接产生连锁风险。GDPval-AA 想解决的问题就是把这套“岗位逻辑”翻译成机器可评判的规则。1.2 从“答题正确率”到“最终交付质量”传统基准大多围绕“答案”设计给一道题模型生成文本判分器比对结果。它的优点是简单可复现缺点是把工作压缩成了“问答”。打个比方科目一考满分的人未必会开车。会踩油门、会打方向盘跟能在早晚高峰安全到达目的地中间差着无数个交通场景、突发状况和路线决策。AI 工作能力也是这个道理。GDPval-AA 的评估对象不是“一句话答案”而是“一份交付物”。可以是客户回复邮件、一段功能代码、一份数据分析报告也可以是跨部门协作流程中的一个中间产出。评估时系统会同时检查交付物是否满足验收标准执行过程是否留下可审计的证据链是否触发了风险动作完成同一任务消耗了多少时间与令牌资源。这套思路把评价从“对不对”迁移到“能不能用、怎么用、代价多大”。对照下来最直观对比维度传统问答/代码基准GDPval-AA 工作基准输入单条题目多轮任务上下文输出答案或补丁完整交付物加过程轨迹环境静态文本沙箱、工具、限制条件成功判据与标准答案一致验收通过且合规且成本可控结果含义反映知识储备反映岗位胜任度1.3 为什么需要这样一把尺子当前企业接入大模型普遍遇到一个尴尬模型跑分挺高上线后效果却忽上忽下。因为跑分反映的是“模型能力上限”而真实工作看的是“综合稳定度”。上线一个 AI 客服不能只看它能不能回答某一道刁钻问题更要看它能不能在两百轮对话里保持统一口径、不泄露敏感信息、不让用户等太久。GDPval-AA 这类工作基准本质上是在给 AI 发“上岗证”。它适合三类人参考正在选型的业务负责人想量化自家 Agent 效果的 AI 工程师以及做大模型评测研究的测试开发。理解了它的评价逻辑你至少能在琳琅满目的榜单里多一层判断能力。2. 设计思路与评分体系拆解2.1 任务样本按岗位拆场景不按学科出题GDPval-AA 的第一步是把岗位职责转成可执行的任务序列。它不会直接出一个“请完成以下 Python 题目”式的任务而是描述一类工作场景。以客服岗为例一个典型任务可能是查看用户关于订单退款的历史消息理解售后政策结合当前库存和物流信息给出一个明确退款或换货的答复。模型需要读取多轮上下文调用查询工具推理出合理方案最后生成一封不卑不亢的邮件。以软件研发岗为例给一个仓库快照、一条 issue 描述、一份测试命令要求 Agent 修改代码并通过测试同时不破坏已有功能。这样设计的好处是贴近真实坏处是构造成本高。所以设计任务样本时通常会把岗位拆成三类小场景高频重复型、复杂推转型、故障恢复型。高频重复型看稳定性复杂推转型看推理深度故障恢复型看抗压能力。每个任务样本都带四个元信息输入上下文、可用工具、期望交付物、验收标准。这四者缺一不可。没有验收标准评分就没有客观依据没有工具限制模型可能会偷懒走捷径。2.2 关键设计证据链驱动评分工作能力评估最怕的事情是模型“蒙对”或“作弊”。举例来说让 Agent 修复一个 bug它可能没有真正定位问题而是把所有断言改成恒真值测试通过了问题却没解决。只看最终结果的基准很容易被这种投机行为骗过去。GDPval-AA 引入了一个强制规则过程证据链。Agent 在执行时每一步工具调用、观察结果、推理摘要、中间产出都要记录。评分时首先做的不是看答案而是看轨迹是否合理有没有检索到关键信息有没有在修改前先复现问题有没有在完成后自测。任何一步缺失对应模块直接零分。把证据链纳入评分其实是在向模型传递一个信号工作不是交差而是可复查、可审计、可追溯的责任过程。这一点与工程团队管理新员工时的思路非常像。一个人代码写得再快如果从不说明思路、不留下文档、不遵循流程负责人也不敢把核心模块交给他。2.3 计分公式与权重怎么定为了让“工作能力”可量化GDPval-AA 通常采用加权扣分模型。一个通用表达式是S 100 × [(α × C β × Q γ × R) − δ × Risk]其中C 是完成度指验收标准被满足的比例Q 是产出质量由自动检查加人工复核得出R 是可靠性反映重复执行同一任务时结果的一致性Risk 是风险扣分项包括越权操作、资源超限、生成危险内容等α、β、γ、δ 是权重系数随岗位不同调整。举一个客服岗的示例。某次执行中完成度 0.9质量 0.8可靠性 0.7风险扣分 0.1权重分别为 α0.35、β0.25、γ0.4、δ0.15。那么得分就是 100×(0.35×0.9 0.25×0.8 0.4×0.7 − 0.15×0.1) 78 分。这部分看似平滑的 78 分背后其实包含三维度像素级记录。默认权重没有绝对标准但经验上不同岗位差异明显岗位类型完成度权重 α质量权重 β可靠性权重 γ风险系数 δ客服运营0.350.250.40.15软件研发0.40.30.20.1数据分析0.30.30.250.15权重之所以重要是因为它决定了“什么算好”。对客服岗稳定比爆发重要对研发岗完成度优先于过程对数据分析岗合规和风险控制必须拉满因为错误结论可能直接影响业务决策。2.4 结果如何映射到岗位等级评分结果不能只给一个数字需要落到实际能力分级。GDPval-AA 的常见做法是划分三个等级等级分数区间含义G3≥85 且无风险否决项可独立承担标准场景任务G26584可半自动执行需要人工复核关键节点G165只适合做演示或辅助不能脱离陪跑这个分级的意义在于让业务方便做决策。G3 的任务可以放心交给 Agent 主跑G2 的任务需要人盯着G1 的任务则应当退回模型选型或提示词优化阶段。分级不是给模型判死刑而是告诉你现在的能力边界在哪里。3. 实操流程与核心环节实现3.1 跑一轮基准之前要准备什么GDPval-AA 不是一个可以直接下载运行的软件包而是一套评估方法论。要在自己团队里落地需要准备四样东西任务样本集、可控环境、可观测接口、评分脚本。任务样本集建议一开始只做 20 到 50 个与自身业务最相关的场景不要贪多。可控环境是指沙箱或仿真环境能限制 Agent 的工具权限同时记录所有交互。可观测接口是 Agent 在执行时暴露输出的端口至少包含三个字段动作类型、输入摘要、输出引用。评分脚本则负责把轨迹和交付物转换成结构化结果。准备工作里有一个容易被忽略的细节任务样本要放进独立的评估仓库和日常开发代码分离。否则提示词或工具配置一改评估结果就会受影响最后根本分不清是模型进步了还是代码环境变了。3.2 一个最小可复现的执行流程执行过程尽量保持简单。这里我给出一个经过多次验证的最小流程建立评估工作区导入任务列表与沙箱配置为 Agent 配置大模型 API、工具清单和权限边界按任务样本逐条执行每次执行限定最大轮数和最大令牌数保存原始轨迹包括每一次工具调用和模型回复运行自动验收脚本检查交付物是否存在、格式是否正确、关键字段是否完整调用质量评估模型或人工评审给产出质量打分汇总轨迹证据计算完成度、可靠性、风险扣分重复执行 3 到 5 次取中位数作为最终得分输出带证据链接的报告告一段落。这套流程看上去平淡但价值在于可追踪。任何一步出了问题都可以从证据链里定位到具体原因。我的习惯是用一段伪代码表示任务定义job: id: crm-refund-002 role: customer-support scenario: refund-request max_rounds: 15 max_tokens: 4000 inputs: - conversation_history.json - policy_2024.md artifacts: - reply_email.md checks: - command: python score_reply.py --artifact reply_email.md expect: pass disallow: - rewrite policy docs - modify logs这个文件定义了“做什么、拿什么做、交什么、怎么验、什么动作绝对禁止”五个问题全部说清。它比任何花哨的提示词都重要。3.3 验收脚本要有原子断言不能只靠“看起来不错”工作基准的评分大部分结论来自自动验收脚本。脚本里的断言必须原子化一个断言只检查一件事。比如评估一封客服回复邮件不能写“检查邮件是否礼貌”这判断太抽象。要拆成邮件包含用户称呼包含明确的处理结论包含下一步操作指引没有拼写错误没有复制内部政策文案。每一条都是一个独立断言任何一个字段缺失对应项就得零分。这是我从实际评估里总结的一条经验验收标准越具体模型越容易对齐验收标准越模糊模型就越容易用“看起来合理”的废话填充交付物。给 AI 写验收标准和给人写需求文档是同一套逻辑不能有歧义。3.4 人机混合裁判怎么做完全靠大模型裁判会产生两种问题一是裁判可能被漂亮话迷惑给低质量交付物高分二是裁判可能过度严格把符合要求的交付物误判为不合格。GDPval-AA 的折中做法是自动评分加人工抽检。自动评分处理客观项例如文件结构、格式、变量名、代码退出码、费用消耗。人工抽检处理主观项例如结论是否合理、建议是否可落地、语气是否得体。抽检比例建议不低于 20%如果发现自动评分与人工评分偏差较大就需要调整评分权重或补充验收断言。我见过不少团队只依赖一个超大模型做裁判最后评测分数很好看上线效果却很一般。原因很简单裁判模型和被测模型共享了同一套盲点。引入人工抽检本质上是在给盲点测漏。3.5 多次执行与统计口径大语言模型有随机采样属性同样的任务跑三次结果可能分别是 95 分、72 分、58 分均值 75 分。如果只报告均值你根本看不出这个 Agent 是“时好时坏”还是“稳定良好”。GDPval-AA 的报告建议同时给出三项统计量中位数、90 分位数、极差。中位数代表典型水平90 分位数代表上线时最差情况下的表现极差反映稳定性。在涉及重要岗位时还应该独立跑一组“高随机性任务”观察惩罚区间。这个细节在招聘场景很好理解面试官不会因为候选人某一次表现超常就直接发录用通知而会通过多轮面试加试用期判断平均水平和最差情况。AI 的录用逻辑理应更严格。4. 常见问题与避坑技巧4.1 分数高不代表放心要区分能力上限与稳定下限在 AI 工作能力评估里得分高只能说明“在条件理想时能做得好”不等于“天天如此”。遇到一个 Agent 在任务里拿到 92 分我很建议大家顺便看一下它在最难一类任务上的最低表现。举一个实际案例某模型在普通代码修复任务里接近满分一旦任务里混入一个隐藏的权限校验它的表现立刻崩盘。单看总分它是 G3 级别看最低分它只能当 G2。上线操作失误的风险不取决于最高分而取决于最差情况下会做多离谱的事。所以报告分数时一定把最差分标出来。4.2 警惕任务过拟合固定题库养不出稳定员工如果评估任务集长期不变模型或者 Agent 框架会逐渐“背下答案”。并不是数据泄露而是提示词缓存、模型微调、Agent 记忆机制都会让系统记住每个任务的预期产出原本用来测能力的题目逐渐变成测试记忆分数越来越虚。解决办法是引入隐藏用例。不同批次运行之间随机替换任务里的客户名、仓库文件名、政策条款版本号但保留相同的任务结构与验收逻辑。这样既能保证对比的一致性又能迫使模型真正按流程推理而不是靠记忆匹配。超参数如 temperature 也建议分开测试低温度测真实产出高温度测发散能力两者结合看。4.3 验收标准模糊必然导致“假阳性交付”有一次我让 Agent 生成一份数据分析报告验收标准写的是“包含关键结论”。结果它生成了一篇语言流畅、结构完整、但完全没有计算过程的“报告”。自动评分判定通过人工审核一眼就看出来这活白干了。后来我把验收标准改成了“报告必须包含三个明确指标获取数据源行数、建模方法、结论置信区间”才算把标准兜住。这件事再次提醒我给 AI 的任务描述可以口语化验收标准必须像测试用例一样严格。宁可在定义阶段多花一小时也不要在评估阶段反复返工。4.4 风险扣分要设计成“一票否决”工作能力基准最容易被低风险高收益行为钻空子。例如一个客服 Agent 为了快速完成工单直接复制了一段内部政策原文发给客户虽然完成任务但违反脱敏规范。如果只扣一点分模型可能为了高分频繁走这种捷径。处理的要点是把风险项改成“一票否决”越权访问、篡改日志、绕过审批等动作一旦触发当前任务直接零分。这样评分体系才能明确表达一件事过程违规比结果缺陷更严重。在实际评估里零分会明显拉开 Agent 之间的差距也会引导开发者在设计 Agent 时真正重视合规控制。4.5 分数变差不一定是模型退步基线评测分数突然大跳水常见原因有三个API 版本更新改变了模型输出风格工具调用接口 schema 调整导致 Agent 解析失败任务样本被无关文件污染。很多时候团队花了一周时间试图优化模型提示词最后发现是评测脚本里一个文件路径写错。做法是每次评测前先跑一个“冒烟任务”用一个非常简单但结果可预期的任务验证整套评估链路是否正常。冒烟任务通了再跑完整基准不通先修环境。这是任何评测体系都绕不开的基础设施建设。4.6 把“成本”写进工作能力里很多工作基准只评估质量和稳定忽略成本。但真实岗位里人也是要考虑时薪的AI 工作能力一样要看单个任务的资源消耗。我习惯在 GDPval-AA 的评分报告里加一列 CPMCost Per Milestone也就是完成每个关键节点消耗的令牌数与 API 费用换算值。同一个任务方案 A 用两轮调用完成方案 B 用了三十轮循环才发现路径两者完成度可能一样但长期维护成本差距巨大。评估工作能力时不看成本等于招人只看能力不看薪水最后很可能会被资源账单打脸。5. 把这个基准用到自己业务里的建议如果团队准备开始做 AI 工作能力评估我的第一个建议是先挑一个高频且影响面可控的岗位场景用两三个任务跑通流程不要一上来就追求完整榜单。很多人在这一步犯了贪多求全的毛病评测任务建了一百个最后连验收脚本都写不完。第二个建议是固定评测周期并持续更新任务集。工作能力是会随迭代波动的上一季度表现优秀的 Agent这季度模型换了蒸馏策略可能就已经不能满足业务要求。固定节奏评测才能把问题拦截在影响真实用户之前。第三个建议是把基准结果映射到项目排期里。G3 能力的任务可以做自动化流程G2 能力的任务保留人工审核G1 能力的任务果断回炉重造。用自己的工作能力基准指挥团队精力分配比无限堆打磨提示词更能落地。最后分享一个我反复使用的想法评估 AI 工作能力不是在衡量它的“聪明程度”而是在衡量把聪明转化成结果的责任能力。光有智慧没有交付在真实职场里一票否决AI 也一样。只要记住这一点你设计出的任何工作基准都不会偏得太远。
阅读完成 · 觉得有帮助？
