ClickHouse发布Agentic Analytics基准：28模型对比评测

我们从 ClickHouse 内部分析代理 DWAINE 的生产流量中选取了 201 个真实分析问题，并对 28 个模型进行了基准测试，这些模型涵盖各个供应商层级，包括专有和开放权重模型，测试对象是我们数据仓库的合成但真实的重建。DWAINE，ClickHouse 的内部分析代理，并针对我们数据仓库的合成但真实的重建，对涵盖每个供应商层级（专有和开放权重）的 28 个模型进行了基准测试。

之前的工作如Spider、Spider 2.0、WikiSQL、BIRD专注于衡量模型将文本转换为 SQL 的能力。虽然有用，但它只衡量了问题的一小部分。文本到 SQL 的基准测试通常可以将模型宣布为整体赢家，适合任何人。但对于代理式分析，最佳模型的标准更依赖于上下文。我们相信，最近的大多数模型在这一领域总体上更有能力。

在撰写本文时，Hex 发布了DataBench，这与我们对代理式分析的看法非常一致。我们强烈推荐阅读他们的文章。

此基准测试不仅旨在成为当前模型能力的时点快照，而且旨在成为一个框架，可用于针对您自己的数据仓库评估模型性能，并评估哪个模型适合您。

本文解释了我们是构建它的，我们发现了什么，以及如何从您自己的数据仓库流量中构建相同的东西。

所有 28 个模型的通过率。没有中型或小型模型进入前 11 名，仅靠前沿层级并不能保证，而开放权重模型领先。

跳到结果。

代理式分析与文本到 SQL

文本到 SQL 是在给定模式的情况下，将自然语言问题翻译成单个 SQL 查询。它是 NLP 中基准测试最多的任务之一，十年来这些基准测试基于四个共同的假设：

1. 模式事先提供给模型
2. 模型只有一次机会
3. 存在单个黄金查询
4. 评分是与该黄金查询的执行匹配

然而，在现实世界的用例中，代理式分析极大地挑战了这里的假设。代理仍然必须将自然语言问题转化为 SQL，但其他三个假设消失了：它自己发现模式，它需要多少轮就进行多少轮，并且没有黄金查询可以匹配，因为答案是注释者一致同意的结果集。

代理能够自行探索和发现模式，制定计划，并运行多个查询来制定答案。这种风格的代理式分析现已投入生产，在许多数据平台中，包括 ClickHouse Cloud，简单的文本到 SQL 不再代表实际工作。

对这个循环进行基准测试测试了 LLM 的一些更不透明的品质，需要一个专门构建的基准。以下是我们在设计基准测试时提出的三个要求：

• 个性化：没有单一的最佳模型适合所有人。基准测试应支持任何公司使用他们自己的问题、他们自己的数据仓库。
• 模式感知：难度在于真实数据仓库的大小和多跳连接结构，而不是紧凑的手工模式。抽象掉模式的基准测试衡量的是错误的东西。
• 可重放性：为了公平比较模型，相同的问题必须按需在同一仓库状态上运行，而实时生产系统无法保证这一点。

方法论

生产级数据仓库的形态

企业数据仓库很少是原始表的堆积。不同的组织遵循不同的模式，使用不同的工具，复杂程度也各不相同。这就是为什么我们认为能够自己运行基准测试很重要。

我们将以我们数据仓库的结构为例进行说明。

我们的原始表通过 dbt 建模成分层模型。

的mart 层（dbt_marts_general）涵盖产品使用和计费：扁平化、反规范化的表，每行对应一个实体或实体周期，JOIN 已完成，列已整理。针对它的典型问题是单表上的过滤和聚合。对于基准测试，此层有 235k 行，其中 144k 在 usage_history 中。

的维度层（dbt_dds）源自 Salesforce，涵盖 CRM 侧：账户、机会、线索、联系人、支持案例，全部采用经典星型模式，实体在 dim_* 表中，事件在 fct_* 表中。使用 dbt_dds 表回答问题需要多跳实体解析连接：将名称解析为组织，按键连接到其账户，然后从那里到机会、案例或服务。dbt_dds 有更多的表和列（865 列中的 746 列），并引入了查找和连接正确表的难度。

合成数据仓库：左侧是扁平化 mart，右侧是 dbt_dds 维度 CRM 层，仅通过组织标识符连接。

为基准测试构建合成数据仓库

DWAINE（数据仓库 AI 自然语言专家）是我们的内部分析助手。员工用自然语言提出业务问题，它通过查询我们的数据仓库来回答。在典型的工作日，它会处理大约 100 条消息，分布在 30 到 60 个对话中，来自数十个不同的用户。

DWAINE 使用Langfuse进行检测，我们记录每次交互：用户的问题、代理运行的 SQL、结果集、最终答案。从中，我们得到了一系列生产复杂度的真实分析问题。

然而，数据仓库和问题包含敏感数据，如客户名称和计费数据，因此永远不能按原样发布。

为确保隐私，我们构建了一个合成数据仓库。

这是数据仓库的重建，所有实体保持内部一致性，但匿名。没有真实的名称或数据保留，但关系和规模是真实的。问题也更新以匹配新实体。

这样，我们可以满足上述要求：

• 个性化：数据和问题代表我们业务的真实世界
• 模式感知：重建保持了真实模式的结构（在我们的案例中：两个 dbt 风格层中的 18 个表和 865 列）
• 可重放：确定性种子意味着每次评估都在同一仓库上运行，只需一条命令。

这个合成仓库的构建是基准测试框架的核心部分。它旨在供任何人复用，因此你可以将其应用于自己的问题和仓库。

整理、匿名化和种子生成

DWAINE 中的原始问题都不能直接成为基准测试项。我们通过三道关卡传递每个候选问题：

1. 整理会剔除根本不是问题的痕迹：粘贴的转录、HTML 转储、批量实体名册。然后，它使用零样本分类器剔除仅在上下文中才有意义的问题，将自包含的问题与依赖早期对话的问题（如“那些客户呢？”）区分开来。
2. 匿名化用确定性的 Faker 值替换结构化 PII（电子邮件、Salesforce ID、UUID、云账户标识符、内部 URL 等）。自由文本名称没有可靠的结构，因此我们将其作为零样本提取任务，故意偏向过度提取，并对照精选的兜底列表清理结果。计费数字按保持比例的问题特定因子缩放。
3. 验证会重新扫描每个匿名问题，如果任何真实的结构化令牌存活，则构建硬性失败。泄漏不能悄悄通过。

重要的是，匿名问题仍然会命名特定实体（例如，组织、账户 ID、电子邮件域名）。每个问题的指代对象必须存在于合成数据仓库中，否则问题无法回答，但又不能过于显眼（否则查找起来太简单）。因此，我们通过大海捞针式构造进行种子生成：将问题引用的每个实体以问题使用的确切标识符植入，然后将针埋藏在现实的合成群体中，涵盖十二个云区域、十个行业、按层级划分的收入以及十八个月的每日历史、漂移、噪声和使用峰值。

从最初的 501 个候选问题开始，经过整理步骤后剩下 475 个。模式兼容性关卡（问题能否仅从重建的模式回答？）将其降至 243 个。真实答案委员会（在下一节中描述）将其削减至 204 个。最后，法律审查又移除了三个，留下我们将评估的 201 个问题。

答案从何而来？

衡量答案是否正确需要知道正确答案，而data-agent-mnist开始时并不知道。

所使用的问题来自真实流量，并且没有附带经过验证的答案。相反，来自三个不同提供商（Claude Opus 4.8、GPT-5.5、Gemini 2.5 Pro）的三个模型各自独立解决每个问题，对仓库运行相同的完整智能体循环。如果至少两个模型通过独立路径达到相同结果，该结果即成为真实答案。如果所有三个模型最终得到不同答案，则该问题因不可靠回答而被舍弃（在上一节中注明，委员会分歧导致我们舍弃了 39 个问题）。

然而，一致同意并非验证，我们必须认识到这并非完美解决方案。两个模型可能以相同方式出错。提供商多样性减少了这种可能性，但并未消除，因为三者共享训练数据和推理习惯。我们的真实答案中略超半数（51.7%）是全票通过，其余以二比一多数通过。我们不知道委员会多久会一致认为某个错误答案。

对我们而言，为所有问题提供人工审核的答案是一个未来目标，并在基准测试框架中支持其他人这样做。

我们还认识到，两个答案可能一致但形式不同。一个答案可能命名一个列total_dollar_usage，另一个可能命名monthly_spend，例如。列链接步骤提供了一个映射，裁判可以使用它来确保等价性（列链接、行对齐、数值容差）。这被证明至关重要，因为我们的测试中 84.9% 的评分结果集仅通过链接映射匹配。

用 LLM 陪审团解决偏见

每个候选答案不是由单个 LLM 评判，而是由三席 LLM 组成的陪审团小组评分。Anthropic、OpenAI、Google 各占一席，且小组排除候选答案所属的模型家族，因此没有模型为自己评分。

多数投票决定；三方分歧计为平局。对候选答案的结果集相对于真实答案进行相同的列链接等价性检查，其判决作为权威数据信号与模型的书面结论一起传递给裁判。

候选答案如何评分？列链接等价性检查将结果集与真实答案进行比较，其判决作为数据信号与书面答案一起到达小组；每个席位派出其提供商中最强且不是候选答案的裁判，并由多数投票决定。

测量 LLM 陪审员的偏见

一个合理的问题是，某个提供商的模型是否可能对自己的答案有正面偏见。我们通过将小组中每个提供商的偏好投票率与来自不同提供商的答案进行比较来审计这一点。

我们注意到，提供商在宽容度上往往不同，但整体偏见不大。总体而言，OpenAI 评判更为宽松，而 Google 是最严厉的裁判。

将每个席位以其自身均值为中心，并比较其对自己家族的投票与其他席位对同一家族的投票，组内残差为 +0.9、0 和 +1.2 分。没有席位过度偏袒自己的家族以改变多数投票。小组是宽容的，而非偏袒的。

左：按裁判席位和候选提供商划分的偏好投票率（最后一列：该席位的总体宽容度）。右：每个席位经宽容度调整的组内残差；阴影带为 ±2 分。宽容度的差异远大于组内偏见。

测量污染

像Spider和WikiSQL这样的基准测试自 2018 年以来就公开了金标准 SQL，并且它们已被证明存在于训练集中（我们下面精确测量了这一点）。Spider 2.0 也继承了其前辈相同的污染压力。

前沿模型可以从记忆中完成这些文本到SQL基准测试中的问题。向最强的记忆模型展示Spider中一个问题的前60%，它能以0.89的词级相似度完成它，几乎逐字逐句。这带来了一个挑战：随着时间的推移，这些基准测试不再测试泛化能力，而是开始衡量记忆能力。

为了测试对Data Agent MNIST的记忆情况，我们用三种工具探测了所有28个模型：

• 完成度探测。 向模型展示基准测试问题的前60%，指明数据集名称，并请求其精确完成问题。生成内容与真实续文之间的词级相似度衡量记忆程度。
• 实体恢复探测。 仓库中的实体是随机的Faker抽取，没有世界知识先验，因此从记忆中回答一个指定组织的ID是不可能的。在公共基准测试上，一个有能力的模型可以从记忆中回答探测问题。
• 阳性对照。 只有当工具能检测到实际存在的污染时，阴性结果才有意义，因此相同的完成度探测也运行在自2018年以来公开且带有黄金SQL的Spider上，该基准已被证明被记忆。

曝光梯度：每个模型在三个Spider分割和Data Agent MNIST问题上的平均完成相似度，按公开时间排序。无论模型记住了Spider的什么内容，在Data Agent MNIST上，每条线都坍缩到噪声底。所有28个模型的实体恢复为零（650次尝试中0次成功）；两个内联推理者被排除在完成度指标之外。

Data Agent MNIST的问题、答案和数据并非公开。每个模型都处于词重叠噪声底（总体平均0.064；1200次完成中仅有1次达到0.5相似度），实体恢复在所有模型和所有项目中均为零：在650次尝试中，从未产生过仓库中的任何组织标识符。

在Spider开发集上，最常引用的公共分割中，最强记忆者得分0.89，且曝光梯度在单个模型内部清晰（董事会领导者得分为Spider开发集0.69，Spider训练集0.43，测试集0.17，该测试集仅在2024年发布，以及Data Agent MNIST 0.06）。

我们还在私有测试集中嵌入了一个金丝雀字符串，作为检测基准是否最终出现在训练语料中的另一种可能方式。并且，由于该基准是作为可重复使用的框架而非静态实体构建的，我们可以随时从新流量中铸造一个全新的、未受污染的实例。

结果

截至撰写本文时，基准测试中包含了28个模型。所有28个模型均使用相同的代理框架、提示词和仓库运行。

我们按以下4个维度进行排名：

• 通过率：回答正确问题的百分比
• 令牌/成本：总的输入和输出令牌数（以及当前公共API定价下的估计美元成本）
• 墙钟时间：从提示到回答的中位时间（以秒为单位）

通过率

在下图中，模型按通过率。

令牌与成本

在下图中，模型按它们的令牌使用量排序。

在下图中，模型按它们的成本排序（基于截至2026年8月模型提供商公开的API定价）。

挂钟时间

在下图中，模型按它们每个答案的中位数挂钟时间排序。黄色条形显示每个答案的中位数挂钟时间，而额外的灰线显示较长运行问题的p90上限。

找到表比连接它们更重要

在201个问题中，83个需要维度CRM层（dbt_dds）。回答这些问题需要发现正确的表并解决多跳连接，所以我们预计这是区分模型的地方。但事实并非如此。

在下图中，模型按总体通过率排序。黄色条形显示83个维度CRM层（dbt_dds）问题的通过率。灰色条形显示它们在其他问题（非dbt_dds）上的通过率。

左图：每个模型在dbt_dds问题上的通过率与其在其他问题上的通过率对比，并标注差距。右图：在这些问题上，每个模型的SQL触及dbt_dds层的频率。

大多数最新模型似乎同样擅长处理平面和规范化的表结构。在排行榜的下方，平面与规范化之间的差距扩大，明显偏好平面表——这些模型大多是较小和/或较旧的，显示出明显的代际改进。

这些较旧/较小模型的失败通常早于连接发生。排名上半部分的模型在需要dbt_dds表的问题上，有87%到98%的时间能发现这些表。排名下半部分的模型则根本无法可靠地找到这些表。Gemini 2.5 Pro下降了20个百分点，发现率为55%；Gemini 2.5 Flash下降了9个百分点，发现率为47%。

我们看到排行榜上有两个异常值，都来自Google。Gemini 3.5 Flash（总体表现较低）在每个需要规范化表的问题上都使用了规范化表——这是排行榜上唯一一个发现率为100%的模型——但没有使用它们，导致下降了7个百分点。Gemini 3.1 Pro在平面表上的通过率几乎接近排行榜最佳，其规范化表发现率与同行相当，但同样未能使用它们，导致下降了5个百分点。

我们认为这些异常值有助于说明在您自己的数据仓库上运行自己的基准测试的必要性。我们可以概括地说“大型前沿模型性能最佳”，或“较小的中端模型性能足够好且成本更低”，尽管这些说法通常正确，但并不意味着“随便选择该类别的任何型号都会表现良好”。您确实需要自己运行测试，并创建特定模型的候选清单。

规划是主要的失败模式

当模型给出答案而我们判定错误时，我们将失败标记为五种模式之一：FM1无尝试，FM2错误计划，FM3错误数据，FM4错误实现，FM5运行时错误。

在下表中，每个模型占一行，每个单元格是该模型失败中属于某种模式的百分比，因此每行总和为100。n列是失败次数。例如，DeepSeek v4 Pro有45次失败，其中69%（31次）是FM2类型。这有助于显示模型失败的模式。

每个模型的失败按五种失败模式划分。行是该模型失败的百分比，而不是其问题的百分比，总和为100；模型失败的频率是排行榜的任务。这里排除了回合限制的运行，视为"预算耗尽"。

FM2（错误计划）是最常见的，对于每个有大量失败次数的模型，占其失败的53%到82%。

FM5（运行时错误）几乎不存在。只有四个模型记录到任何此类错误，并且只有Gemma 4 31B超过2%，因此现代模型很少编写无法执行的SQL。

FM1（未尝试）则是另一回事。它通常不存在，但越往排行榜底部越常见。对于Gemini 2.5 Flash达到34%，Gemini 2.5 Pro为27%，Qwen3-Coder 30B为23%，这些模型都位于底部三分之一，而前十名中有七个模型完全没有此类失败。最高发生率出现在较旧和/或较小的模型中，但并非绝对，因为GPT-5.5和5.6在此组中也有3%到5%的失败。

Fable 5.1（排行榜领先者）在FM3（错误数据）方面表现突出，占其失败的28%，而周围模型为19%到23%。这是排行榜上最高的比率，同时其FM2占比在前十名中最低，为57%：它计划得很好，然后选择了错误的字段或粒度。

这些结果表明，SQL语法和执行不再是现代模型的瓶颈。对于代理式分析，数据建模和模式上下文更为重要。

针对正确任务选择正确的模型

从结果来看，我们能否得出结论：前沿模型最适合代理式分析？

仅就通过率而言，层级是成立的：排名1到12都是前沿层级的模型，没有中层或小层模型能达到他们的水平。但层级并不说明模型的成本。在该顶级组中，每个问题的价格相差8倍。排名第二的模型（DeepSeek V4 Pro）仅比领先者（Fable 5.1）低2个百分点，但成本低75%以上。

在顶级模型之外，考虑DeepSeek V4 Flash。其得分为65.7%，比Fable 5.1低11个百分点，但成本低52倍（完整运行1美元，而Fable 5.1为52美元）。而且速度也更快。

运行我们完整的201个问题基准，使用DeepSeek V4 Flash费用为1美元，而使用Fable 5.1则需要52美元，但正确性牺牲了11个百分点。

选择不仅是前沿模型之间的比较，也不是前沿模型与中级模型的比较。您需要评估您的用例可容忍的正确性水平，以及您愿意为最后几个百分点支付多少费用。

此外，失败模式分析指出了在模型之外可以支持性能的地方。错误计划是每个模型最常见的失败，占失败的53%到82%，而廉价的模型在其他方面的表现并没有明显更差。如果计划是普遍的瓶颈，那么购买一个好的计划并廉价执行是显而易见的架构：将最强的模型放在制定计划的地方，让低成本的模型执行它。

我们还没有对分工架构进行基准测试。这是我们最感兴趣的后续工作：我们能否缩小差距，使得成本仅为其五十分之一的模型成为生产默认选择？

在您自己的数据仓库上运行此测试

data-agent-mnist并不是对当今模型的固定评分，也不与ClickHouse的使用绑定。它是一个可复用的框架，任何人均可用来针对自己的环境对模型进行基准测试。

该框架包括一个仪表化助手（任何跟踪捕获问题、运行SQL和结果的追踪）、一个建模的仓库模式，以及用于注释和评判的API访问，涵盖若干前沿模型。

如本文所述，为自己重现基准测试有多个阶段：挖掘和整理流量；通过硬失败验证进行匿名化；合成重建模式并植入问题引用的每个实体；通过提供者多样化的委员会恢复地面真实值；使用从不给自己的家族评分的评审小组进行评分。每个阶段都是一个脚本，完整的评估从单个命令重放，针对确定性的仓库进行。

通过运行基准测试，目标不是说哪个模型普遍最好，而是哪些模型最适合您在代理之后用于生产环境，针对您的工作负载。我们的结果表明，对我们来说，判别因素是维度CRM层；您自己的仓库将有自己的判别因素，只有亲自运行才能发现它是什么。当新的前沿模型发布时，您可以将其作为候选加入，并与您当前的选择进行对等比较。

接下来是什么

当然，新模型不断发布，我们打算继续更新结果，以观察情况如何变化。我们计划后续增加对一个模型内不同推理级别的测试功能，以及分体模型架构。

我们还将撰写一份关于测试方法的完整白皮书。

我们还发布该框架以便您自己运行基准测试，我们非常期待听到您的测试结果。请通过我们的Slack社区或Git仓库联系我们！