SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

工具选对了和任务做成了,两个不同的指标

工具调用准确率衡量模型在调用工具时是否选对了函数、填对了参数。任务成功率衡量用户请求最终是否被正确完成。工具选对了不等于任务做成了——工具调用只是任务链条中的一节,调用之后还有参数值是否正确、调用顺序是否合理、调用结果是否被正确使用。

寓言

一个跑腿伙计,拿对了菜单号,端错了菜

城东大酒楼在大堂和后厨之间加了一个传菜窗口,跑腿伙计站在窗口等菜单。他的工作是:客人点单,他看菜单编号,从窗口递进后厨,再把出来的菜端到对应的桌上。掌柜为了考核伙计,在窗口装了一个记录牌,上面只记一件事——菜单编号是否递对了后厨。

头一个月,记录牌显示递对率百分之九十七。掌柜在例会上表扬了伙计。但客人投诉量翻了倍。投诉集中在端菜环节,递单环节反倒没有太大问题——伙计把糖醋鱼端到了点清蒸鱼的客人桌上,把三号桌的汤端到了八号桌,有次甚至连盘子都没端稳,半盘菜扣在地板上。

掌柜把记录牌的数据和投诉清单并排放在桌面上,看了一下午。记录牌上说递对率从百分之九十涨到百分之九十七——伙计选菜单编号确实越来越准。投诉清单上写了端错桌、扣盘子、打翻汤——跟菜单编号没关系。掌柜明白了一件事:递对菜单是第一步,递对不是端对的保证。

酒楼改了两个做法。第一,把菜单编号准确率保留在考核表里,但只作为中间指标。第二,加了一个客人满意度追踪——每张桌子吃完后让客人勾选满意还是不满意,跟菜单编号对比,算出菜单递对后客人最终满意的比例。这才是真指标。

跑腿伙计开始注意到一个规律:菜单编号越复杂,他越需要花时间核对,递对率反而越高——因为他多看了几秒。但总出错的反而是熟悉的老菜单——他扫一眼就递,编号不错,但没注意到老菜单上周改了做法,糖醋鱼换了配菜,端出去的菜客人不认。选对了工具,参数值错了。

后厨后来把指标分成了三道关口:第一关看菜单编号递对率,第二关看编号正确情况下菜和客人是否对应,第三关看客人满意率。三道关各有对应的改进措施——第一关靠培训菜单,第二关靠核对端菜流程,第三关靠客人直接反馈。

招牌上后来加了一行小字:上菜准不准,不只看递单的小窗口。客人桌子上的空盘子才是账单。

工具调用准确率

衡量模型在需要调用工具时选对函数名和填对参数格式的比例。只评估工具选择的正确性,不评估整个任务的完成质量。是任务链条中的一个中间节点指标。

任务成功率

衡量用户请求最终被正确完成的比例。覆盖从理解请求、选择工具、调用工具、使用工具结果到生成最终答案的完整链路。是端到端的用户体验指标。

故事对应

  • 记录牌上的递对率:工具调用准确率,只衡量工具选择和参数格式
  • 客人满意度追踪:任务成功率,覆盖从请求到结果的端到端链路
  • 递对不代表端对:工具选对但参数值或调用顺序出错会导致任务失败
  • 九十七的递对率加翻倍的投诉:工具调用准确率高但任务成功率低的典型场景
  • 三道关口:完整评估体系需要中间指标和端到端指标并存
  • 熟悉菜单也出错:工具选对但没注意到上下文变化,参数值错误导致失败

落到 Agent 质量评估

建 Agent 评估体系时,工具调用准确率作为调试指标保留——它能帮你定位是工具选择有问题还是后续步骤有问题。但不能用工具调用准确率替代任务成功率向客户或业务方汇报。两者之间常见的断层包括:参数值填错、调用顺序错误、工具返回结果被模型错误解读。建议在任务成功率下降时回查到工具调用准确率做归因,但永远不要只用前者代替后者做上线决策。