模型评测为什么一做工具调用基准就开始高分低可用：从 Trajectory Scoring 到 Outcome Verification 的工程实战

离线分数很好看为什么线上还是频繁把工具调错很多团队给模型接入搜索、工单、支付或 CRM 工具后都会先做一套tool calling benchmark。表面上看只要模型把工具名和参数拼对离线分数就会迅速上涨。⚠️ 可一进真实链路系统仍会出现“查到了旧单号”“多调一步把状态改坏”“结果正确但成本翻倍”这类问题。离线87%的轨迹通过率并不等于线上就真的可用。图 1工具调用评测最容易美化的是轨迹分而不是最终业务结果根因往往不在模型不会选工具而在评测只检查“像不像参考答案”。 真实生产里同一个任务可能存在多条合法调用路径相反看起来轨迹很像的调用也可能因为参数缺一个时间窗、缺一个租户 ID最终把错误状态写进系统。只盯着trajectory match评测奖励的就会是“表面相似”而不是“结果正确且副作用可控”。 真正该核对的不只是调用顺序还包括结果验真和额外成本工具调用场景里最常见的误判有两类。第一类是模型多调了无关工具答案仍然勉强正确于是被高分放过。第二类是轨迹文本几乎一致但关键参数槽位偏了一位最后把错误数据写入外部系统。 这也是很多团队为什么离线榜单很好看线上回滚工单却越来越多的原因。图 2一旦评测不核对执行后状态错误调用就会被轨迹相似度掩盖评测方式离线得分真实成功率额外调用率主要盲区只看参考轨迹一致率88.4%61.2%23.7%奖励表面相似调用轨迹 参数槽位校验82.6%72.9%14.1%不核对副作用状态轨迹 结果验真 成本惩罚79.8%81.5%6.3%维护成本更高️ 更稳的做法是把评分拆成意图、参数、结果和预算四层更适合生产的做法是把一次工具调用拆成四层打分。✅ 第一层看工具意图是否正确第二层看参数槽位是否完整第三层直接核对执行后的目标状态第四层再惩罚无意义的额外调用和重试。若工具具有写操作还应在sandbox或dry-run环境里回放避免评测集本身污染业务数据。defscore_tool_run(expected,actual):intent_okfloat(actual.tool_nameexpected.tool_name)arg_scorecompare_args(expected.args,actual.args)outcome_okfloat(verify_state(expected.post_state,actual.post_state))extra_penalty0.2*max(actual.extra_calls,0)score0.35*intent_ok0.25*arg_score0.30*outcome_ok-extra_penaltyifactual.has_side_effectandnotoutcome_ok:return0.0returnround(max(score,0.0),4)某客服工单链路在引入Outcome Verification后离线总分反而从86%降到80%但线上误改状态率从4.7%降到0.9%。 这个结果很有代表性真正可靠的工具评测通常不会让分数更漂亮却会让错误更难藏在“看起来差不多”的轨迹里。图 3把结果状态和预算一起纳入评分后评测才能约束真实执行行为 接下来 3 到 6 个月工具调用评测会从静态对答案转向可执行验真接下来3到6个月工具调用评测的分水岭不会是谁写了更多参考轨迹而是谁先把executable benchmark、状态快照和副作用回放接起来。 只要评测还停留在文本比对层模型就总能靠“说得像”骗过分数却骗不过真实系统。笔者认为Tool Calling最难的部分从来不是生成一段函数名而是把一次外部动作安全地落到正确状态。 你们现在更头疼的是参考轨迹太僵硬还是结果验真太难接进评测流水线如果这篇文章对你有帮助欢迎点赞、收藏和关注。图 4可上线的工具评测不是更会比文本而是更会验证执行后的世界状态