Sierra 客服基准 τ-bench:gpt-4o 零售过关率 61%,连跑八次全对不到 25%

$τ$-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains

Shunyu Yao, Noah Shinn, Pedram Razavi, Karthik Narasimhan

cs.AI, cs.CL

2024-06-18

Sierra 发布 τ-bench,用模拟用户、领域 API 和政策文档专门测客服 agent。gpt-4o function calling 零售过关 61.2%、航司 35.2%,同一任务连对八次的概率掉到 25% 以下。

这篇在解决什么

现有 agent 评测多半是一次给齐信息,让模型自己跟网页或 API 对打。真上线的客服不是这样:用户一次说不全,政策写在手册里,同一诉求换种说法,终态不该变。Sierra 的 τ-bench(Tool-Agent-User Interaction Benchmark)把三件事绑在一起测:跟模拟用户多轮对话、调领域 API、按政策办事。

场景选了零售售后和航司改签。规则能写清楚,数据库能合成,任务能做成「政策加用户偏好只允许一个写库终态」。

方法

每个任务按部分可观察决策过程来建。Agent 看不见库,只能调工具读写;用户由 gpt-4-0613 扮演,只看见对话、看不见工具轨迹。领域政策放进 system prompt,例如基本舱 24 小时后不能改签。用户指令藏着身份、目标和偏好,改到只剩一种合规写库结果。

回合结束看两项相乘:终态数据库是否等于标注目标,回复里是否含必给数字。全对记 1,否则 0。对话可以千变万化,写库必须对。作者承认,没征求确认就退货也可能得 1,所以这是必要但非充分条件。

为测稳定性,提出 pass^k:同一任务独立跑 k 次,全部成功的概率。对照代码评测常用的 pass@k(k 次里至少一次过)。客服要的是每次都对,不是碰运气碰对一次。

构造分三步:人写库表、API 和政策;gpt-4 扩数据条目;人写用户指令并用 gpt-4-turbo function calling 试跑,改到无歧义。零售 115 题(500 用户、50 商品、1000 订单,写接口 7 个、只读 8 个),航司 50 题(300 航班、2000 预订,写 6、只读 7)。每题最多 30 步,agent 温度 0,用户温度 1,主表每题至少 3 次。

结果

原生 function calling 全面压过文本格式的 ReAct。gpt-4o 最好:零售 pass^1 为 61.2%,航司 35.2%,按域加权平均 48.2%。gpt-4-turbo 是 57.7/32.4,claude-3-opus 是 44.2/34.7,gpt-3.5-turbo 是 20.0/10.8。Llama-3-70B 没有原生 function calling,用文本 ReAct 只有 14.8/14.4。开源权重和闭源头牌差一截,航司明显更难。

稳定性更差。零售上 gpt-4o 平均过关超过 60%,pass^8 掉到 25% 以下。同一政策、同一目标,用户说法一抖,结果就不稳。

把政策文档从 system prompt 拿掉后,gpt-4o 零售从 61.2% 掉到 56.8%,航司从 33.2% 掉到 10.8%。零售规则接近常识,模型本来就没怎么啃手册;航司行李额跟会员舱等走,手册一撤就崩。gpt-3.5-turbo 两边几乎不动(20.0→14.5,10.8→9.6),复杂规则它消化不了。

人工看了零售 115 条 gpt-4o 轨迹(每题 1 次,失败 40 条,pass^1 记成 65.2%,和主表三次平均的 61.2% 不是同一设置)。4 条是用户指令笔误,剩下 36 条:参数填错 33.3%,信息给错或漏给 22.2%,决策类型错 25.0%,复合请求只做一半 19.4%。gpt-4o 每题平均 0.46 次幻觉 ID,gpt-3.5-turbo function calling 是 2.08,纯 Act 是 6.34。成本上,gpt-4o agent 配 gpt-4 用户,零售每题约 0.38+0.23 美元,115 题跑一轮大约 200 美元,钱几乎都花在长 system prompt 上。

模型零售 pass^1航司 pass^1加权平均
gpt-4o61.235.248.2
gpt-4-turbo57.732.445.1
claude-3-opus44.234.739.5
gpt-3.5-turbo20.010.815.4
Llama-3-70B14.814.414.6

为什么重要

这是目前最接近「真上线客服」的公开基准之一:用户在环、政策在环、用数据库终态打分,不用 LLM 当裁判。pass^k 把「平均能打」和「次次能打」拆开,后者才是客服 SLA 关心的。代码和数据已公开,后来社区也拿它当 agent 标尺。

对要上线的人,61% 的单次过关、八连低于 25%,说明单靠 function calling 还撑不起百万次对话。失败形态也具体:库存推理、一次只许调一次的写接口、复合诉求漏做。这些比「再换个更大的模型」更好下手。

局限与存疑

用户是模型装的,会算错、记漏、被 agent 带跑。作者也写了,用户不知道「换货接口整单只能调一次」,会批准先换一件。任务指令还用 gpt-4-turbo function calling 来打磨,对同类模型有隐性偏置。奖励不管有没有征求确认,政策遵守测得不完整。域只有两个客服场景,医疗税务法律只是展望。主表航司 gpt-4o 是 35.2%,去政策消融写成 33.2%,试验次数不完全对齐。

术语

原文与代码

社区讨论

相关论文

全部论文解读