智能体分析基准第二轮:GPT-6与Claude新模型
有效阅读仅保存在当前浏览器,用于「为你」推荐;暂停或清除记录。
DataHot 速览
Agentic Analytics Benchmark第二轮新增GPT-6 Astra、Luna、Sol以及Claude Opus 5.5、Claude Sonnet 5.5五个模型,均在34款模型榜单中部落于彼此1分以内。基准仍使用201道题、每题60轮预算和三家评委投票,结果比较通过列链接器处理列名差异。Sonnet 5.5在轮数、成本和截断运行方面变化最大。此次还更新了测试框架:固定查询引擎版本和时区、调用前检查凭证、将数值容差配置化,并修复宽结果集的列链接问题。
为什么值得关注:数据从业者可了解当前分析Agent/Text-to-SQL智能体在真实数仓上的能力排名与评估方法,以及基准可复现性设计。
本文目录 10 节
译文
AI 逐段翻译本文中使用的术语
- 排行榜:在60轮预算下,按201个问题上的通过率排名的34个模型。它是冻结的:新模型会使用相同的问题、仓库和评委加入。
- 轮次:一次模型调用。一轮可以发出多个SQL查询。每个问题的预算是60轮。
- 轮次受限(TL):在未作答的情况下用尽了60轮预算的运行。它计为失败。
- 评委小组:三位模型评委,每个提供商一个席位,对每个答案进行投票。候选模型自己的模型从不给它评分。
- 列链接器:两个正确答案可能以不同方式命名列。当一个答案的列包含另一个答案的列时,共享列按名称匹配,不调用模型。否则会询问一个小模型哪些列对应,并在该映射上运行结果比较。
- 维度CRM层(dbt_dds):仓库的规范化表。201个问题中有83个需要它们,找到它们是第一篇文章的主要区分因素。
自第一篇文章以来的变化
这篇第一篇文章运行了一个智能体循环(模型编写SQL、读取结果,并决定何时作答),预算为60轮,使用确定性结果比较,以及每个提供商一个席位的评委小组,其中没有模型给自己的答案评分。这些都没有改变。本文新增了五个模型。
测试框架也发生了变化。它在以下地址公开:github.com/ClickHouse/data-agent-mnist,与排行榜运行所用的代码树同步,并且自第一篇文章链接的版本以来:
- 引擎和时区固定。排行榜清单记录查询引擎版本和会话时区,在不同版本或时区上运行会被拒绝。一次静默的引擎升级曾翻转了一个问题的标准答案,而这正是可重复基准存在的意义所在。
- 凭据预检。 候选模型、评委和列链接器将触及的每个提供商都会在首次付费调用之前进行检查,因此失效的评委凭据会停止运行,而不是一次一个问题地降低评分。
- 数值容差作为配置。 比较器不再假定是货币。舍入和容差是模型配置中的评分部分,货币值作为默认值。
- 针对宽结果集的链接器修复。 当一个答案的列包含另一个答案的列时,共享列按身份映射,不调用模型。该修复仅向前生效;已发布的排行榜未重新评分。
- 一个带不确定性的评委模型。 对缓存的评委投票使用多面Rasch模型,给出候选能力、评委严厉度和同族系数及自助法区间,离线从结果文件计算。
- 用于实验的钩子。 第二个语料库只需一个环境变量,因此开发集可以与冻结的排行榜并存。每个运行器都接受一个门控回调,它可以向查询结果附加一条注释。
- LibreChat运行器。 运行器在与直接循环相同的问题、仓库和评委小组上对LibreChat智能体评分:在完整排行榜上,该产品在相同模型上得分为69.7%,而直接循环为66.2%,在噪声范围内。
第一篇文章中的污染探测在所有五个新模型上运行。它们中没有一个能从问题前缀中恢复匿名实体名称(每个均为0/25),并且它们与我们问题的补全相似度处于与排行榜其余部分相同的低区间。五个模型中唯一带有Spider对照的模型Sonnet 5.5,在Spider dev上恢复了81%的实体名称,而在我们的问题上为7%,这告诉我们该探测在存在记忆时是敏感的。
34个模型的排行榜
在下图中,模型按60轮预算下的通过率排名。五个新行以蓝色显示。
60轮预算下的排行榜,34个模型。亮黄色标记了六个与领先者在统计上持平的模型;在201个问题上,95%区间约为±6到7个百分点。轮次和SQL是每个问题的中位数。TL是模型在预算内从未完成的问题数。蓝色条形标记自第一篇文章以来新增的五个模型。
排行榜的顶部与第一篇文章相比没有变化。所有五个新增模型都进入第9至15名之间,并且所有五个模型都在每个问题上得出结论,TL列显示即使对前沿模型来说这也不是理所当然的。
GPT-6系列
GPT-6 Astra、Luna和Sol通过排行榜上其他OpenAI席位的相同OpenAI兼容路径运行,采用默认推理力度。它们的通过率跨度从68.7%到69.7%,区间重叠,略低于GPT-5.5(70.4%),高于GPT-5.6(67.7%)。这里没有GPT-6变体领先其前代。所有三个模型都在预算内回答了每个问题,呈现出排行榜通常的失败形态:首先是计划错误,没有运行时错误。
默认力度是一个注意事项。第一篇文章在Gemini系列上展示了预算形状的旋钮对数字的影响有多大,而GPT-6支持一种排行榜上没有任何模型运行过的“xhigh”力度。在该扫描运行之前,“默认力度下的GPT-6”是这些行的标签。
Claude Opus 5.5
Opus 5.5以69.7%进入,比Opus 5高2.0个百分点,在噪声范围内,与Kimi K2.6和GPT-6 Sol持平。与Opus 5一样,它在每个问题上都得出结论,循环略短:中位数为4轮和6次查询,而Opus 5为5轮和7次查询。
Claude Sonnet 5.5
Sonnet 5.5是五个中最有趣的:准确率略有变化,其他一切变化很大。
准确率。 68.7%(201个中138个),而Sonnet 5为62.2%。在相同问题上配对比较,它赢31个输18个,净胜13个,p值约为0.09:有方向性,但不显著。它与GLM-5.2和GPT-6 Astra持平,比Opus 5高一个百分点,比Opus 5.5低一个百分点。
增益在哪里。 在需要维度CRM层(dbt_dds)的83个问题上,Sonnet 5得分为62.7%,Sonnet 5.5得分为73.5%;在其余问题上,分别为61.9%和65.3%。增益出现在多跳问题上,而且不是因为更频繁地找到表:两个模型在约89%需要维度层的问题上发现了它。它更好地使用了它们。
在83个维度(dbt_dds)问题上与另外118个问题相比、34个模型在60轮时的通过率,以及每个模型的SQL在多大程度上触及了维度层。除了Opus 5.5之外,每个新行在维度问题上都保持或有所提升,而Opus 5.5在这类问题上的得分比其余问题低2分。
效率。这是我们看到最大改进的地方。Sonnet 5在201次运行中有16次触及了60轮上限,因此其通过率比其在已完成运行中的通过率低5分。Sonnet 5.5零次触及上限,平均每个问题3.5轮,而对比对象为9.1轮;每个答案中位耗时13.7秒,而对比对象为26秒;按标价计算完整运行成本为10.39美元,而对比对象为14.40美元:每个问题约5美分,而对比对象为7美分。
每个问题的实际耗时,34个模型,按中位数(刻度线)排序;条形为第90百分位数。GPT-6 Sol和Sonnet 5.5是榜单上最快的行之一。Astra是新行中最慢的,中位数为46秒,第90百分位数超过90秒。
失败形态。在Sonnet 5.5的63次失败中,75%是计划错误,19%是数据选择错误,6%是实现错误。没有未尝试和运行时错误。Sonnet 5有5%未尝试和15%实现错误。Sonnet 5.5总是尝试并且更经常正确计算;当它失败时,它失败在计划上。
图景相同,但底线更高
第一篇文章中的两项发现在新增五个模型后依然成立。
规划仍然是主要的失败模式。对于每个新模型,计划错误都是最大的桶,并且不存在运行时错误。对于这一类模型,SQL执行已被解决;剩下的是决定要计算什么。
按模式划分的每个模型已结束失败的占比,34个模型,排除受轮次限制的运行。对于每个新行,计划错误都是最大占比,从51%(Astra)到75%(Sonnet 5.5),并且这五个模型都没有产生运行时错误。Astra以27%的数据选择错误和13%的未尝试而突出;Opus 5.5和Sonnet 5.5总是会尝试。
在顶级组内,价格仍然跨越八倍,而中端正在缩小差距。在第一张榜单上,一个家族中的廉价席位是那个耗尽预算的:Sonnet 5在16个问题上触及上限,而Opus 5为零,Gemini 3.5 Flash为28个。Sonnet 5.5打破了这一模式。它运行整个榜单的成本约为Opus 5的五分之一,没有截断的运行,并且结果与它相差不到一分。
每个问题的平均标价成本与通过率对比,30个模型,对数刻度。Sonnet 5.5刚好位于成本前沿的右侧,每个问题约5美分。GPT-6 Astra、Luna、Sol和Opus 5.5被略去:它们通过一个网关运行,该网关的使用记录无法可靠地区分缓存和非缓存输入,因此来自它们的标价成本对GPT-6来说太低,对Opus 5.5来说太高。
上次我们说过,你必须自己运行基准测试来选择模型。五个新的前沿模型之后,这仍然是建议:顶线分数几乎没有变化,而实际改变的属性(轮次、成本、截断)正是排行榜数字所隐藏的。
在你自己的数据仓库上运行这个
这里没有任何内容是我们仓库或ClickHouse特有的。测试框架与第一篇文章描述的相同:一个经过插桩的助手、一个建模的仓库模式、一个经过策展和匿名化且带有委员会真值的问题集,以及一个评审小组,其中没有模型给自己的答案评分。添加一个模型只需一个注册表条目和一条命令,而引擎固定意味着重新运行可以复现榜单。
你的仓库会有自己的判别器。我们的是一个维度CRM层;你的可能是一个缓慢变化的维度、一个半结构化事件表,或者一个没人写下来的命名约定。找到它的唯一方法是在你的模式上、用你的问题运行基准测试,并查看模型在哪里失败。
下一步
GPT-6系列的推理努力扫描,以便在不止一个努力水平上比较这三个变体。第一篇文章中的分角色架构问题(最强的模型规划,最便宜的模型执行)仍然是我们最感兴趣的后续工作。紧随本文之后的是一篇关于标记失败和排名表的配套文章。
代码
- 测试框架:github.com/ClickHouse/data-agent-mnist,Apache 2.0。examples/下的两个工作示例从已发布的树中使用三个API密钥运行。
这篇内容对你有用吗?
反馈只用于改善内容筛选,不等同于收藏